京东虚拟商品系统的高可用架构设计

电商的双 11 技术，往往代表了互联网企业的最高水平，也代表了顶尖技术人一年来所有的努力。

今天双 11 零点战争开启，截至凌晨 2 点，京东累计下单金额突破 950 亿元，在高流量高并发的情况下，电商系统如何做好技术攻关？各互联网企业又是如何做好容量评估、性能优化、稳定性等方面的？

2017 年 12 月 8-11 日，由 InfoQ 举办的 [ ArchSummit 全球架构师峰会] 将于北京举行，此次大会策划了双 11 架构专场，并邀请了顶级技术专家担任出品人设置了“新一代 DevOps”、“人工智能与业务应用”、“业务系统架构的蜕变与进化”等 17 个热门话题。

在“业务系统架构的蜕变与进化”话题下，我们邀请了京东商城研发部架构师 **周光前来分享《京东虚拟商品系统的高可用架构设计》 **，并借此机会采访了周光老师，他为我们解读了京东虚拟商品系统的双 11 运作，希望可以给大家带来启发。

如果读者想了解更多京东的高可用架构设计，欢迎报名参加 ArchSummit 北京站并与周光老师进一步交流。

受访嘉宾介绍

周光，京东商城研发部架构师

14 年软件开发相关工作经验，8 年以上软件架构设计经验。擅长 SOA，微服务架构，工作流系统。对互联网高并发、高性能、高可用性分布式系统有丰富的架构设计和开发经验。

曾就职于亚马逊中国，负责全球开店系统的设计和开发。目前是京东商城资深架构师，负责架构设计和开发了京东分布式工作流系统，电商云系统以及虚拟商品的多个系统。

识别下方二维码，提前了解《京东虚拟商品系统的高可用架构设计》

京东虚拟商品系统

虚拟商品系统和实物体系从架构体系上来说比较类似，都是服务化的、分布式的，都要满足高可用、高并发和高扩展性的架构设计目标。

从整个交易流程上来说，虚拟商品不涉及到仓储物流配送，但虚拟业务有很多自己的特点也就决定了在架构上需要一些特别的设计。比如交易过程需要与第三方供应商进行多次交互，这个对系统的高可用性提出更多的挑战。

以机票系统为例，查询机票需要调用多个供应商的接口，在接口不稳定或外部网络延迟过长的时候，如何通过缓存、降级保证系统的可用性和用户体验。

随着公司不断扩展虚拟业务种类，并把核心的业务做深做强，对系统的架构设计也提出了更高的要求。虚拟商品系统架构大概可以分为三个阶段：

1. 初始百花齐放
2. 中期业务系统平台化 + 基础的京米平台
3. 目前的组件化、业务赋能阶段。

虚拟业务刚成立的时候为了快速上线新的业务，业务系统各自开发。随着业务种类和业务量的迅猛增加，为了更好的支持新的业务，提高系统的稳定性，我们做了两方面的升级：把业务系统平台化，相同的业务在一个平台里完成，同时把通用的功能比如商品、下单、虚拟风控、退款等抽取出来构成一个基础的京米平台，这样虚拟业务只需要关心本领域高度相关的业务逻辑，新的业务可以基于京米平台快速搭建。

今年以来，除了在平台化上继续深化，我们进行系统组件化设计，通过组件的组合和配置完成新系统新功能的构建，同时可以更迅速的将我们的业务能力开放出去。

大促

大促时期，虚拟商品系统每日有海量的订单。我们会关注像数据库、外部接口、网络等多个地方。

以数据库为例，应用无状态可以快速伸缩，但数据库目前还比较难做到。在架构设计时，对访问量高的调用尽量减少对数据库的依赖，同时排查长事务、检查索引、备份并清理过期数据等等，同时对数据库进行监控，并和数据库运维工程师紧密合作，如果出现数据库瓶颈（比如发现慢 SQL），快速定位问题，并进行相应的处理。

从架构设计上有很多降级的方案，可以自动降级，比如我们的充值系统，如果某个供应商的接口不可用或者不稳定，可以根据配置自动切换到其他供应商。

我们对故障处理的时间要求是在分钟级别，然后会迅速升级。大部分情况下都能比较快的解决，对用户的影响降到最小。为了保证能快速发现和解决故障，我们会提前架构进行梳理，我们的手段有：

1. 技术改造系统薄弱的、有风险的地方；
2. 加强系统全方位监控（分钟级和秒级）；
3. 模拟真实用户压测发现问题；
4. 准备各种场景应急方案并进行多次演练等等。

谈谈故障及应急手段

基本上可以自动处理的故障，都是根据业务的需求，系统可能出现的问题，或者是总结以前的经验教训，然后在架构设计中考虑进去并进行演练过。

比如在正常的业务系统设计中，用户支付后，支付系统会发送 MQ 消息，业务系统接收到支付成功确认消息会触发后续的处理。但支付系统可能因为高压力，或者网络的问题，MQ 消息延迟会比较长时间。

虚拟某些系统对此很敏感（如果不能快速获得支付确认并进行后续步骤，系统要取消订单），我们在设计的时候下单后如果一定时间没有支付确认，会按一定的时间间隔进行反查，同时与收到的 MQ 消息进行幂等处理。

关于大促，我们一直认为平时多流汗，战时才能少流血。我们把这些准备在日常的开发工作中就进行完成，比如直接与用户相关的系统，我们都进行压力测试后才上线，这样可以对系统的承载能力做到心中有底。

当然，大促中我们最关注的是系统的稳定性和出现故障能快速解决，11.11 前会进行多次的全链路压测，主要目的是确保重点业务流程中系统没有薄弱环节，上下游系统间人员的沟通通畅。

今年有全场景故障演练的工具，开发人员就可以非常方便的进行比如 CPU 类的系统故障、接口异常的服务故障等几十种场景的演练。

应急手段方面，我们会提前与业务部门沟通了解促销的情况，然后根据历史的数据，对大促的流量进行预测。最近几年的预测结果和实际的情况基本上差不多，比较准确。这样也确保我们的备战更加有的放矢，特别是像硬件资源的分配上也更加具有针对性，应对起来更加有信心。

促销当日我们会有专门的值班室，各个业务系统核心开发人员都会进驻 24 小时值守，结合各种监控系统，如果出现故障，大家可以快速进行沟通交流，迅速定位问题，同时根据提前准备好的经过反复演练的应急预案来解决问题。

未来会怎么做？我们系统的架构设计会基于现有的情况，根据业务的战略目标，同时权衡成本和收益，确保架构在不用太大的修改也可以满足业务未来几年快速增长的需要。就虚拟系统来说，未来会更多的侧重于组件化，并在合适的场景引入 AI 人工智能，帮助更好的提升用户体验，同时进行业务赋能。

如何看待重构？

软件的架构应该根据业务的具体场景进行，在遵循通用的一些设计准则基础上，进行权衡。

比如对于初始的新业务项目，为了快速上线抢占市场，开始就进行细粒度划分，采用严格的微服务架构往往不是最好的方式，而在项目中使用模块化可能会更好。因为这时对业务领域的理解并不太深刻，服务的划分不合理，很可能会使服务之间紧耦合，变得复杂，数据一致性保证困难，降低开发效率，增加维护成本。

所以对于这类型项目，当系统上线后，随着业务的增长和对业务领域更深入的了解，根据不同的业务和业务需求，进行合适的重构，不要为了重构而重构。 每次重构都需要有具体的可衡量的目标 / 需求解决痛点和问题，比如增加一个业务规则需要修改的地方太多，又比如系统需要支持每秒多少次的访问而目前架构满足不了。

InfoQ：感谢周光老师接受我们的采访，期待周光老师在 ArchSummit 全球架构师峰会分享的《京东虚拟商品系统的高可用架构设计》。