青龙系统架构最佳实践
青龙系统架构演进过程中，从高可用，高性能，数据一致性，用户体验四个方面，积累了丰富的经验，确保了青龙系统在发展过程赢得了公司内外的口碑。
高可用
每年“双十一”都是网购狂欢节，假设当天哪个电商系统出现系统不可用，那几乎是灾难性的，不仅会导致用户快速流失，而且，公司将承受重大损失，甚至在未来竞争中失败。即使对于创业公司，在当前获取用户如此昂贵和竞争如此激烈的情况下，系统不可用的代价也是非常大的，会遭到用户的抛弃而失败。
青龙系统作为京东后台物流系统，系统高可用也同样重要，因为，即使在平时，物流系统出现不可用的情况，会造成订单时效履约失败，极大影响用户体验，这也是无法接受的；同时，系统不可用也会导致数十万员工无法正常工作，对于效率极大影响，公司损失也非常大。我们在研发过程中，对于系统高可用，也积累了丰富经验，主要包括：合适的架构方案；大系统小做，服务拆分；并发控制，服务隔离；灰度发布；全方位监控报警；核心服务，平滑降级。
首先是选择合适的架构方案。互联网系统一般可以分为前端应用系统和后端数据库系统，前端应用系统实施分布式集群部署技术上是比较成熟的，后端数据库系统实现异地多活技术难度很大，目前也只有阿里，京东这样的公司才真正实现。因此，对于大多数应用，前端应用双机房集群部署，后端数据库系统采取成熟的主备从的模式，也就是单个机房作为写入，备库在另外机房，可以快速进行切换，读库双机房部署，是优选的方案。对于这个架构方案，存在跨机房写延长的问题，可以根据场景利用异步的方式进行解决，一般也是没有问题的。对于青龙系统来讲，也有些特别，利用分拣中心的本地服务器和操作人员的设备，实现离线生产，进一步提高可用性。
大系统小做，服务拆分，是互联网应用的特点，也符合敏捷交付的理念。对于传统软件，如Windows，Office等，都要经过一个漫长的需求，研发，测试，发布周期，在“唯快不破”的互联网时代，这显然是无法满足业务要求的，即使最后上线，也可能因为周期太长而不再适用了。因此，对一个互联网服务，一般会首先完成最核心的功能，快速进行上线，不断进行迭代，后续再进行辅助功能跟进。对于核心功能，随着用户数的增加，会不断进行服务拆分，如何进行拆分，拆分到什么样的粒度，是不是微服务是解决问题的银弹？这些都要根据实际的应用场景来评估，绝不是越细越好，而是要达到一个优雅的平衡。
并发控制，服务隔离。并发控制，现在已经成为互联网服务基本要求，在应用程序端和数据库端，也都有成熟的方案，如果忽略，可能造成灾难性的后果。对于重要的服务，还要进行隔离，例如同一个服务，要提供给内部调用，公司级调用和公司外开放服务调用，开放服务调用者我们一般认为是不可靠的，甚至有可能是恶意的，如果不进行隔离，开放服务调用有可能使得服务资源占满，对内也无法提供服务。从技术上，可以是硬件级隔离，全部隔离，也可以是前端应用的隔离。
灰度发布也是互联网服务的一大利器，有了灰度发布，才使得快速迭代成为可能，并且，很多服务因为各种原因线下也是很难测试的，只能在线上测试。如果没有灰度发布，只能全量发布，就存在较长测试周期问题，如果没有重复勉强上线，就存在很大的系统崩溃的风险。按照用户，区域进行灰度发布是比较常用的方法。
全方位监控报警，可以分为技术层面和业务层面，技术层面包括对CPU，内存，磁盘，网络等的监控，业务层面，包括对处理积压量，正常的业务量等。做到全方位监控，才有可能在影响用户之前，提前解决问题，提升系统可用性。否则，等用户发现问题，在很大的压力下，技术团队更难处理，导致系统不可用时间加长。
最后就是，核心服务，平滑降级。任何技术手段，都不可能保障100%可用，并且，即使能够做到，其代价也是巨大，不经济的，因此，对于核心服务来讲，能够平滑进行降级，提供基础的服务，也是非常重要的。对于青龙系统来讲，就利用分拣中心本地服务器和操作人员的设备，研发了离线生产系统，来应对集中服务万一不可用的情况。
高性能
对应互联网服务来说，高性能是必须的，用户的响应一般都要求是秒级，而一个用户操作都包含多个服务调用，对应服务接口响应的要求都是毫秒级。对应青龙系统来讲，支持物流操作人员有十万余人，每个操作提升一秒，那么就能节约三个人员，意义是非常大的。
如何提高性能，接口数据缓存化是非常重要的手段。青龙系统属于后台操作型系统，业务逻辑复杂，如果不能缓存，完全依靠数据库操作，那么，响应会超过数十秒。如何进行缓存，需要设计缓存系统进行支撑，青龙系统在演进过程中，依托公司的缓存服务，并且结合应用内存，包括Redis消息通知体系，构建了具有自己特色的缓存体系，很好的支撑了业务发展，大型互联网服务，一般都微服务化了，这样意味着一个用户操作，都是由多个服务接口支持，如果按照传统的同步接口设计，那么，不仅面临性能问题，而且，QPS也是无法满足的，因此，需要将同步接口调用异步化。在2012年左右，eBay就提出所有系统调用异步化，后面，几乎所有大型互联网公司，都对自身系统进行了异步化改造，并且，取得了很好的效果，在和腾讯CTO Tony交流中，他就提出即使支付这种服务，也是有办法进行异步化设计的。同步接口异步化，也是需要系统工具支持的，青龙系统在发展过程中，也发展了基于Redis的分布式调度系统，做大了缓存和异步化，系统性能会有很大的提升。对应青龙系统这样的大型互联网服务，对应核心服务要求是非常高的，同时，又有数量非常多的非核心服务，如果不能进行主次服务分离化，那么意味着如果要提升核心服务水平，增加服务器，那么，就需要为所有的服务进行扩容，这样是不经济的。因此，系统需要精心设计，做到核心服务和非核心服务分离，给核心服务提供充足的资源，确保核心服务的性能。
数据一致性
数据服务，对于大型互联网应用，已经变为非常核心，称为系统的大脑也不为过。
我们一般需要考虑实时性和一致性，这两个最重要的维度，当然，数据量也是一个维度，一般我们认为是大数据的应用场景。
这样，我们就能分为四个基本的场景：高实时性/高一致性，高实时性/低一致性，低实时性/高一致性，低实时性/低一致性。针对具体的业务，我们可以匹配到具体的数据场景，这样，我们就能找到对应的解决方案。在这个过程中，客观的进行业务分析非常重要，并不是，选择高实时性/高一致性是最优方案，因为这个方案的实现成本是最昂贵的，可能是不经济，也没有必要的。
实时&强一致场景：这个在大数据技术成熟之前，是非常棘手的，但是，现在解决方案已经比较成熟了。典型应用是生产系统的实时监控，例如实时生产量，各个生产环节差异量等，其实是作为生产系统的一部分。利用当前主流的大数据处理架构是可以解决的，例如线上生产库binlog实时读取，Kafaka进行数据传输，Spark进行流式计算，ES进行数据存储等。如果利用传统的ETL抽取方案来解决，频繁对生产数据库进行抽取，并不是可行的方案，因为，这样会极大的影响线上OLTP系统的性能。还可以举一个生产系统实时监控案例，架构方案是应用系统完成写数据库的同时，把内容通过消息发送，后面的大数据处理系统接收消息来进行处理，这个架构方案，对于实时性某种程度上可以保障，但是，也存在效率问题，但是，对于强一致性就非常不合适了，因为消息系统如ActiveMQ等不仅无法保障消息数据不能丢失，而且对应消息顺序也是无法保障，项目实施后，虽然采取了很多补救措施，也无法满足强一致性需求，不得不重起炉灶。
实时&弱一致性场景：典型的应用场景是消息通知，例如电商的全程跟踪消息，如果个别数据出现丢失，对于用户的影响并不大，也是可以接受的，因此，可以采用更加廉价的解决方案，应用完成对应的动作后，将消息发出即可，使用方订阅对应的消息，按照主键，如订单号，存储即可。
离线&强一致场景：这是典型的大数据分析场景，也就是众多的离线报表模式。从技术上，传统的ETL抽取技术也能满足要求，数据仓库对应的技术也能够解决。
离线&弱一致场景：对于抓取互联网数据，日志分析等进行统计系统，用于统计趋势类的应用，可以归为此类，这类应用主要是看能够有足够廉价的方案来解决，是不是可以巧妙的利用空闲的计算资源。这个在很多公司，利用晚上空闲的计算资源，来处理此类的需求。
以上讨论的都是大数据应用，也就是从数据量大的应用场景。但是，对应现实中很多数据处理系统来讲，例如很多B2B业务系统，或者传统行业，其实是数据量并大，那么采用更加廉价的OLTP的方法，例如复制读库等，也是可以完成对应的工作的。
因此，架构设计应当针对具体应用场景的，满足当前业务的发展需求，可以考虑两年的需求，最合适的架构就是最好的，而不存在放之四海都是最好的架构设计。不分析清楚自己的应用场景，盲目照抄大公司的技术架构，显然也是不合适的。当然，如果选择的架构本身，不能满足应用场景的需求，后续，不论进行多少补救，依然无法满足需求，并且，架构会变得异常复杂，替换的成本也将是非常高昂，不得不慎重。
用户体验
京东是非常重视用户体验的公司，老刘就明确指出任何人不能对用户体验提升的意见说No。青龙系统在研发过程中，我们认为MVP原则和动态运营是非常重要的。
MVP原则，也就是敏捷开发中的迭代思路。对应一个大的项目，按照传统的瀑布模型，一般经历设计，研发，测试到最后上线阶段，这对于互联网应用来说，很多情况下是不能接受的，因为业务需求变化太快，如果上线周期太长，也许上线后发现情况已经变化了，或者，上线后发现不能落地推广。因此，对应一个大项目，一般会进行迭代分解，最核心的需求，会优先开发，并完成上线，上线验证后，继续开发优先级低的需求。
动态运营，其实也和MVP原则有很强的联系，也就是功能上线后，要真正运营起来，看具体数据，如果发现和设计不符合，那么，就要进行调整，到符合用户需求。这也是互联网服务的用户体验，要优于传统的软件开发系统，传统软件开发基本上上线后就不在优化了，而对于互联网服务来说，上线只是开始，只有将这个功能运营好，才叫好，并且，这个过程一直是持续的。
对于如何打造一个高可用的互联网系统，上面很多点大家都知道，包括高可用，高性能，数据一致性和用户体验，关键是如何落实和做到极致，就如大家都学习乔布斯，但是，能够真正把产品做到极致的还是凤毛麟角。