京东618技术解析之高可用多中心交易平台

京东618技术解析之高可用多中心交易平台

分流是应对互联网业务流量峰值时保证系统高可用的常规方法，但涉及交易系统的分流是很难的。京东在备战2015年618时就开始了多中心交易的改造，让用户就近访问交易服务，并在2015年双11之前完成了面向用户的全部读流量和小部分写流量的多中心，而这次618备战，京东又把交易流程涉及的几乎所有系统的写流量实现多中心架构。近日，京东商城交易平台架构师肖飞接受CSDN记者专访，介绍了京东交易平台备战618的技术挑战、高可用架构的设计思路以及京东多中心架构的最新进展和具体实现。

京东多中心交易平台有三个主要的目标：

• 在多个数据中心支持交易流程中读流量和写流量的水平扩容；
• 异地容灾，任何一个中心出了故障之后，其全部的交易请求会被另外的中心无缝接管；
• 用户体验和性能优化，尽量规避异地的跨机房访问延迟。

肖飞介绍，交易平台在今年618备战主要完成了三项任务：

1. 几乎所有的核心的交易流程所涉及的系统，以及写流量的多中心的架构；
2. 对支持多中心交易系统的底层核心数据库复制中间件JingoBUS做了大量的工作，包括性能的优化和针对运维可视化的改进；
3. 统一了交易流程中各个核心系统的流量可视化和故障切换（以前在分散各个系统里面分别实施），即把交易流程中的各种流量以及互相切换进行了一个标准化，以实现快速切换。

嘉宾简介：

京东商城交易平台架构师肖飞

肖飞于2011年8月份加入京东，曾亲身参与到京东的应用性能监控、统一日志、流式计算、内存缓存、四层防攻击等一些基础技术平台的研发和搭建工作，经历了京东的技术系统从简单粗放向复杂精细化的演变过程。目前主要工作为多中心交易项目中的数据复制中间件JingoBUS的研发。平时也会开发一些公共的平台和工具，关注分布式系统的实现、程序设计、性能优化、开发语言等。

CSDN：京东经历过了多次618和双11，备战的思路应该已经比较成熟，但京东的业务也在发展，今年618和之前的大促相比，技术挑战有什么不同？

肖飞：如您所说，京东经历了很多次大促了，现在备战已经形成了一些套路。在大促之前两三个月，会着重进行诸如系统容量预估、架构review和微调、风险点和监控点梳理、压测和优化、各项预案的梳理和演练等工作。系统容量评估方面，各系统通过压测来评估是否能够支撑，无法满足的要重点review，采取系统优化、扩容等方式来满足，或根据系统情况准备限流或降级等预案。

大促期间，也就是紧盯监控，随时应对各项突发事件。大促过后，我们会review大促过程中系统的各项性能指标，和先前的准备工作，查漏补缺，进行系统的下一个短期规划（基本上是下一次的大促为目标）。数据增长量和容量方面，有些系统则会以2年或更长的时间来规划。由于要不断的满足业务的各项需求和技术架构改造，系统到下一个大促前也会经历比较多的变化，因此有必要按照上述列表重新梳理一遍，当然有些成熟的可以很快做完。

今年618的技术挑战仍然是如何在保证大流量下的系统高可用。但是由于流量基础越来越高，不能像以往的方式简单地增加服务器资源来满足系统峰值的需求。本次618，交易系统全面接入到Docker弹性云，以实现更便捷的进行扩容和缩容。另一方面，这给应用系统带来的挑战是，如何压榨容器资源最大限度的满足系统的性能指标。把物理机上混合部署的多实例应用，迁移到CPU隔离的容器上，促使我们做了一些合理的参数调整，配合压测不断优化。

CSDN：能否进一步谈谈京东高可用系统的设计理念，包括哪些层面？具体的技术指标是怎么样的？

肖飞：高可用是个比较广的话题。简单地从字面理解，就是要保证从用户请求到获得响应这个链路上的所有的系统设施可用程度极高。通常是用几个9来描述可靠程度。所以，高可用从链路上，包括了DNS、运营商网络入口、LB、应用层、缓存、数据库等软件设施、连接和承载他们的硬件设施的高可用。每个层次都有自己的高可用方案和专业人员来实施。任何一个层次的故障都会导致可用程度下降。保障高可用最基本的前提是这些设施不能有单点。

可用，从系统的SLA角度，则是在某种并发量的前提下，稳定的耗时为多少的一种要求和承诺。稳定的耗时我们通常用TP99或TP999来描述，后者表示99.9%的请求在多长时间内返回。所以，可靠性、稳定性是我们高可用系统设计的前提。

关于高可用系统有一些耳熟能详的架构设计原则：

• 分流。分流是通过调用链路上的系统设施的冗余，将请求路由到不同的设施上。比如根据终端将APP、PC端的流量分开到不同的后端服务；根据重要性，将核心系统和非核心系统的流量分开；根据用户等级，划分到不同的web服务；根据数据访问特征和时间复杂度，将批量key和单key请求划分到不同的缓存集群；将抽数分析和普通业务分到不同的数据库；将大数据处理的专线带宽和交易业务的专线带宽在路由上做不同QOS设置；等等。流量会有逻辑和物理上的分组。最终，应用监控到的性能数据，应该可以看到不同流量分组下的指标。分流也是系统扩展性的结果。
• 故障切换。在可以分流的基础上，当某个流量分组链路上的系统设施出现故障的时候，切换到另外分组的系统设施上，保证链路的通畅。切换时的手段和影响是系统设计时需要考虑的。SNA无状态架构应用的故障切换很容易，有状态则需要仔细设计切换的步骤。
• 隔离。和分流有点像。但是隔离是物理上的，比如秒杀系统，有独立的服务器资源来部署一整套交易流程服务。
• 限流。上面谈到的SLA，超出系统可承载的吞吐量时，稳定的耗时是没法保证的。在已经做了分流和隔离的基础上，资源仍然无法满足，则有必要做限制。常见措施有LB层的请求频率控制、RPC层的并发控制和CPU使用率的熔断机制、数据库层的连接池控制等等。
• 降级。当出现故障且切换成本较高时，针对非关键依赖进行降级。或者直接返回缓存的非实时数据，或者直接返回异常，以便下游服务采取应对措施，等等。降级必须以不影响用户核心体验为标准。
• 并行和异步。在核心交易流程中，将一些没有先后依赖关系的服务，可以进行异步并行的调用。或者某些非关键的依赖可以请求后不需等待直接返回。

交易系统一般会根据这些架构原则来设计系统，配合压测来做性能的优化，运行时配合各个层面上的自动化/半自动化工具、监控平台、部署系统等，来应对大流量、高并发的挑战。

CSDN：多中心的系统范围相比半年前的双11备战扩大了很多，能否介绍其中的主要技术突破？

肖飞：主要有以下几个方面：

1. 在一个数据中心时，用户的数据已经按照用户维度进行了分区。多中心之后，一些基础数据如商品、价格等在每个中心仍然会是全量，存储用户路由的用户基础数据也会是全量。用户产生的增速大的比如虚拟资产、订单才需要在跨数据中心这个层面上做数据分片。考虑到故障冗余，在现阶段两个主要的数据中心，这些数据也仍然保持全量，但是在稳定的用户路由下，两个中心都可写入，不同用户的写入主节点不一样。我们仍然是采取的传统的数据分片、每个分片主从复制的方式来做。这样的数据一致性容易控制。应用层需要根据稳定的用户路由，保证同一个用户数据不能同时写入多个数据中心。

2. 目前的两个中心或即将上线的三中心，MySQL数据库部署架构类似多Master，但是我们没有采取MySQL自身的多Master机制。而是采用了数据复制中间件来做相互之间的同步。在数据复制中间件上我们考察和借鉴过开源社区的实现，例如Databus、Canal/Otter、OpenReplicator等，但最终还是自主实现了这个中间件（解析部分使用了Canal的DBSync），并根据我们在一期中的运维实践，给中间件加了很多非常实用的功能，比如细粒度监控、自动化等等，并为应用提供API暴露相关的延迟等状态信息。

3. 多中心交易更多的是沟通协调层面的问题。由于在交易核心流程中，从入口到最后下单，系统非常多。所以我们也是在逐步地扩大这个核心流程中的系统改造范围。用户路由从入口到最后的结算服务，如果都能协调一致，减少或消除一些中间层的额外纠正，数据中心内流量闭环才能真正的实现。

CSDN：在多中心交易架构之下，可扩展性和高可用更有保障，但可能有异地跨机房的访问延迟，京东如何解决？

肖飞：对于异地多中心部署，路由一致协调、机房内流量闭环是主要的工作。路由一致，读你所写的一致性很容易得到，用户也感觉不到数据延迟带来的短暂不一致。另一方面，数据复制中间件会在传输等环节做更进一步的优化，缩短数据不一致的故障时间窗口。

CSDN：在演练过程中，将流量切换到另一个机房，涉及有状态服务的时候，京东是怎么做的？

肖飞：服务化对外隐藏状态。我观察到几乎所有的交易系统对外提供的服务接口都是无状态的。上面讲到分流，本质上是一种带权重的负载均衡，调用方按照流量分组标识来调用某一组服务接口，但是也是可以根据需要（比如故障或演练）切换调用另外一组服务接口实例。因此一个中间层系统的维护者，在做流量切换的时候，只需要保证对下游调用者的流量分组有可用实例，对依赖的上游服务做到可以随时切换分组标识即可。服务框架层来处理一些负载均衡和故障切换细节。

那么每个服务化的系统只需要处理自己所直接依赖的状态就可以，这些可能是数据库、缓存、ES、分布式存储等等。有些通过一些中间件比如各种无状态的Proxy来解决，有些直接使用了分布式存储提供的对外接口，这两种方式也可以理解为直接利用了封装状态对外提供无状态服务，他们本质上和大多数自己维护状态的系统要解决的问题差不多。

基础层的大多数系统还是直接面向存储的。其中有一些系统所需要维护的状态很简单，比如接单系统，依赖一堆散列库，只需要维护一个地址列表即可，Round-Robin的方式写入订单，某个库故障是跳过即可，订单落入到哪个库都无所谓。

更多一些是需要维护固定路由的，比如分片地址、主从拓扑结构等信息。这类信息一般会通过配置系统来管理。在演练过程中，读流量的切换比较简单，无非切换应用系统的预设配置模板，将存储从一个从集群切换到另外一个从集群。写流量的切换涉及到主从拓扑信息变更，就需要非常小心。需要存储层主从复制进度、应用写切换窗口期处理、配置系统等协调起来。当然不同系统的细节也不一样。

2016京东618技术系列：

• 扛过618全部流量，京东15万Docker集群如何炼成
• 618前夕看京东IT基础设施建设与无人机物流规划
• 解构京东智慧物流：智能化设备+大数据技术

京东618/双11技术演进：

• 京东11.11技术探秘(2014)
• 11·11单日1400万单的背后：京东技术首次全解密(2014)
• 翁志：京东峰值系统设计（2014.11.11）
• 解密京东618技术：重构多中心交易平台 11000个Docker支撑（2015）
• 京东11.11技术备战解析：10万级Docker、多交易中心与京东大脑（2015）
• 刘海锋：从2014到2016，大规模内存数据库演进之路（2015）