从建设到治理，从系统到团队，谈高可用架构之道

何为高可用架构，如何实现高可用架构，一百家互联网企业可能摸索出数千种探索道路并给出数万种答案，但符合自身企业技术环境发展的答案可能有且只有一种，如何从海量实践中提炼出值得借鉴学习的高可用架构之道，相信是不少一线技术管理者需要深思熟虑的问题。

2016 年 12 月 2-3 日， ArchSummit 全球架构师峰会将在北京举行。本届大会组委会策划了“高可用架构之道”专题，并邀请了京东商城研发部架构师林世洪老师担任该专题出品人，我们借此机会采访了林世洪老师，他为我们分享了高可用架构建设过程的经验总结，希望可以为大家带来启发，如果对实践高可用架构有疑问，也欢迎报名参加ArchSummit 北京站，与现场的技术专家一同讨论交流。

受访嘉宾介绍：

林世洪，毕业于北京交通大学，2011 年加入京东，先后负责京东订单履约体系和零售平台架构工作，连续两届架构委员会成员，此期间主导和参与了京东研发若干规范的制定，着力推动电商核心系统架构升级，总结形成了大型促销备战方法论，保障了电商主流程系统的稳定性，降低了整体系统建设成本。个人技术方面更多关注根据业务特点和技术要求对系统进行可运营化改造和治理。

InfoQ：能否简单介绍您总结的大型促销备战方法论？在总结这套方法论的过程中您遇到哪些印象深刻的经验或教训？

林世洪：简单总结一下：“积极防御、及早发现、快速处理”。实际上，问题的防御、发现和处理是大家都知道的动作，大家分享得很多了，我原来的分享也分场景列举了不少，在此不多做解释，关键是这每一个动作前面都加一个副词来约束，哪个做到都不容易。

1. 积极

指的是意识方面问题。如果不亲自参与到系统的运营过程中，研发人员很难体会到防御设计的必要性。那些参与过系统运营，特别是参与过事件处理的人，对系统缺陷和稳定性有更深刻的认识，回头再设计系统时考虑就会周全，这是第一层，可以称为意识培养，即培养可运营化设计的意识。

这种意识的强度往往呈现出周期性波动，过了一段时间就会淡薄，直至有外力强化，包括真实事件强化和培训强化，这就出现了第二层，可以称为意识治理。

最后一层借助一种制度，即系统负责人的制度，系统负责人对系统的稳定和发展负责，他会以主人翁的精神来养育系统，使得系统持续稳定发展，这一层可以称作意识管理。

2. 及早

这是一个相对的时间概念，通过监控等手段及时发现问题，甚至在问题出现之前就能预测出来，从而尽早介入处理，可以避免或减少对业务的影响。

这里举一个针对任务处理系统的监控例子：任务出现积压，而且积压在增多，这时监控系统会检查其吞吐能力和处理延迟，如果处理延迟在增大，吞吐能力在降低，则说明系统有问题，否则系统正常；如果任务没有积压，但处理延迟有明显增大趋势，则系统出现问题的几率比较大。

从这个例子看出来，发现问题要综合看多个指标，同时考虑量（积压量）和趋势，才能及时准确地判断是否发生了问题，以及问题发生在哪里。

3. 快速

系统运行时可能遇到各种各样的问题，如果有对应的应急预案，并演练到位、分工明确，各种决策要素可以迅速收集，保证工具齐全，则可从容决策和处理，即达到“快速”的要求。这里需要强调的是，当真出现了紧急情况，最要紧的并不是去寻找问题的根源，而是果断采取措施控制住影响。越早决策，影响就越小。有些技术人员喜欢刨根问底找原因，忽略了对业务的影响程度，可能会使一个小事件升级为大事件，大家要特别注意。

InfoQ：多机房部署模式有很多种，例如传统的两地三中心到现在的分布式多活中心，能否结合京东的多中心交易系统谈谈京东在多机房部署模式的选型思路？以及在建设过程中遇到什么困难最后如何解决的？

林世洪：谈到多机房部署方式，最主要的内在决定因素是系统本身，不同的系统对可用性的要求也是不一样的。我们会对系统进行分级分类治理，例如我们会把电商核心主流程系统，以及主流程系统必需的基础系统和中间件定义为 0 级系统，公司会在 0 级系统倾斜更多的人力和物力资源，设计更加可靠的架构和部署模式。

同样是 0 级系统，其部署模式也有区别。我们把系统分为前端系统和后端系统，前端系统如结算页和下单系统，因对客户体验敏感，系统可用性和响应速度都有很高的要求，所以采用了多交易中心的部署策略，一方面通过多个分中心的方案来满足响应速度的要求，另一方面通过主中心来满足可用性要求。

后端系统相对更注意吞吐能力和数据一致性等方面的要求，可用性要求和响应速度相对低，往往采用较简单的主从备架构或者应用多活架构，没有分中心的设计，这样系统建设成本和维护成本都相对低，即使出现机房故障，也允许花较长时间来切换机房。

多中心交易系统建设过程遇到不少挑战：

• 数据一致性问题，这是比较大的挑战，多中心交易方案从本质上是一个分布式系统，天然地存在数据分区，也就有数据分区问题，在解决这类问题时，采用了场景化数据分类处理的策略。在正常场景下，交易数据只能从分中心产生，同步到主中心；而交易所需要的主数据则从主中心同步到分中心，在分中心故障场景下交易数据才可以在主中心产生。
• 数据同步问题，MySQL 数据库提供的同步机制无法满足及时性问题和异构数据之间的同步问题，我们专门为此开发了一套数据同步中间件系统，它采用总线结构，解决了多数据源间的数据异构同步难题；通过并发处理提升了吞吐能力，节省了同步时间；本身通过 HA 机制实现了高可用。

InfoQ：您谈到越来越多的互联网企业在建设自己的数据中心，为什么会有这样的趋势？如何评估从租赁到自建的转折点？

林世洪：首先，自建数据中心需要充足的资金，投入的内容包括土地、基建、风火水电等基础设施、电信资源、IT 基础设施、整个运营环境等等，并且需要专业的运营管理能力。如此巨大的投入，为什么还要自建呢?

自建数据中心通常是为了解决市场已有数据中心无法满足需求的矛盾，通常表现在数据中心的规模容量、功能设计、服务保障等等，当商业数据中心在某些方面无法满足企业的刚需时，企业会选择自建。

关于由租转建的转折点，可以是投入产出比，也可以是核心生产力长期回报，也可以是某种特殊的契机、情景，这要看企业当前发展阶段的诉求和矛盾是什么。但相信，如果自建数据中心带来的综合收益明显大于租用、解决了企业的切实需求，企业就可能要考虑自建，甚至在出现这种趋势时就会考虑自建，毕竟自建周期比较长，而且需要积累经验。

另外自建数据中心是企业综合实力的体现，对整个技术体系和格局会带来积极的推动作用，形成良性局面后对企业的技术核心竞争力长期发展、成本优化、人才培养都会带来积极的作用，例如：Google、Facebook 等已经从中获得了显著的成效。通过足够的规模效应、技术和管理优化，压缩成本。通过选择更低成本的地区、甚至国家，以获得相对更低的成本。

InfoQ：架构设计要与企业的业务规模和发展趋势相匹配，架构设计往往需要考虑前瞻性，您认为在业务快速扩张阶段如何避免在架构设计上滞后或超前于发展趋势？

林世洪：凡事预则立，不预则废，需要给架构设计者一个设计原则，必须遵守，即 did 原则：design 20 倍体量，implement 3 倍的体量，deploy 1.5 倍的体量。这里的体量结合非功能要求来说，可以是吞吐量、存储容量等。

要贯彻这个原则，需要对业务量的发展有预判，对系统处理能力有评估，对设计方案有评审，对资源申请有审核，对线上资源利用率有监督，这些流程对应的手段很多，这里不多赘述。

除了体量之外，还是一个先进性跟踪的问题，架构设计上如果过于超前，对于技术开发人员要求较高，往往需要专业的团队，这样成本会有相应的增加。如果技术开发人员的水平跟不上的话，就会影响业务的变化。

随着业务的发展、业务的迅速迭代，系统会变得越来越复杂，系统架构越来越重，往往事与愿违。但无论如何，一个企业应该及早地实施服务化，因为它能将一个较大的问题分解为多个较小的问题，非常适合快速成长的企业快速多变的需求特征；同时应该注意通过流程控制系统将流程控制逻辑集中处理，避免流程控制分散带来的数据不一致问题。

中国互联网技术已走进世界第一梯队，技术不但不应该成为影响业务发展的瓶颈，反过来应该是推动业务发展的源泉。一个公司在发展的早期，可以不必过分注重技术的先进性，只要业务能发展起来，技术债还起来不是难事，会从债务变成债主。京东和阿里都是这样的例子，先是技术跟着业务走，逐渐驱动业务发展。

InfoQ：在各业务线上的敏捷开发模式是否会给架构治理带来困扰，在平衡开发效率和开发约束之间您有什么经验可以分享？

林世洪：我们的研发分为多条业务线，每条业务线中有多个系统，每个系统相关的研发、测试、产品、业务人员实施敏捷开发，目的是保持沟通的高效率和减少不必要的干扰，保持对业务变化的快速响应。

如果有架构升级相应的工作，通常不会大规模地实施，我们会选择典型系统作为小白鼠，采取小步快跑的方式进行，不会对所有系统进行统一的架构升级工作，这样太重了，不够安全，也不利于品质的保障。

另外我们的技术架构体系是多层次的，也为我们架构升级与业务系统的开发迭代工作的隔离提供了有利条件，所有架构改进的实施必须安全、快速，尽量不打断正常的产品研发的节奏。架构升级的工作会适应业务系统的每个迭代，每次迭代制定明确的目标。

以升级消息队列服务为例：

• 第一个迭代的任务是选择合适的业务系统进行调研，制定相应的切换升级策略；
• 第二个迭代是开发，架构师进入到该项目中与业务系统同步，这个迭代与新产品发布同时完成；
• 第三个迭代是消息队列系统本身的改进，包括性能、容量、并发上的一些改进，经过几个迭代后，其他业务系统都可以放心大规模使用新的消息队列。

InfoQ：能否总结在高可用架构建设中有哪些“天灾人祸”可以有效杜绝，以及是如何做到的？进一步地目前还有哪些“天灾人祸”还不能有效预防？

林世洪：先说下还有哪些“天灾人祸”不能防吧：

1. 用户端软硬件故障：例如电脑不显示了，这个我们没办法预防，但可以采取措施减少销售机会的丧失，如提供手机 APP、H5、视频购物等。如果用户上不了网了，我们可以提供离线浏览功能等等；
2. 出现极端的不可抗力：如不同城市的所有机房同时断电断网，这种情况是真的不可抗了。

一般场景都可以有效预防，但有些场景必须特别注意，处理不好就会引起可用性问题，而且问题发生几率相对高，举两个例子：

1. 基础服务系统全部同时重启：如果一个基础服务的客户端非常多，调用量非常大，这样做可能是灾难性的，如果自我保护措施做的不好，可能产生类似 DDoS 攻击的效果；
2. 降级措施自动实施：自动降级一定要小心，经常因检测手段不可靠造成错误操作的情况。

下面再谈可以杜绝的问题：

1. 单个服务器故障：对于无状态服务器，使用集群即可应对，对于有状态服务器，可以启用备用服务器；
2. 某个服务集群故障：切备用集群，也可以准备降级预案，预案可以是多级多策略的；
3. 某个机房故障：可以将切到另外一个机房，如果是多活的应用则不用切换，但有可能需要做流量控制；
4. 出现意料之外的峰值，或因资源等问题造成处理能力下降：措施可以是过载自我保护、启动异步降级预案、紧急扩容；
5. 运营商网络故障：网络架构分层，入口在一层，可以将入口切到其它运营商，以下各层不需要切换；

从以上来看，系统的扩展能力和自我防护能力是架构上的标配。另外，虽然这些问题都可以应对，但应对措施是由人来做的（即使有自动化的措施），所以必须加强演练，以提高决策速度和准确度，要有自动检查机制防止错误的命令被执行。

InfoQ：关于大规模服务过载后的恢复流程，能否举例您是如何尽量减少服务受影响的时间？目前是否遇到不能自动化处理的问题？能否谈谈你们对大规模故障恢复时长的指标要求以及如何做到？

林世洪：首先，设计合理的架构都会有过载保护机制，来避免大规模服务过载的发生。举个例子：

• A 系统调用 B 系统，曾出现检测出 A 端服务响应时间长，可用率降低的同时，B 端检测到服务响应时间和可用率都很正常的情况。这个例子里 B 端做了过载保护，限制了并发调用量，所以 B 保持了自身的健康。

再举一个发生了服务过载的例子：

• A 系统是一个自动工作流系统，它会依次调用 BCD 等若干个服务，有一次出现较大的峰值，BCD 负载飚高，服务响应时间不断增加。A 收到了报警，显示各环节出现积压，且吞吐量出现下降，表明 BCD 已出现问题。这时 A 启用降级流程，将 BCD 的调用频率降低，BCD 紧急扩容后，A 恢复调用频率，整个流程恢复正常。这是一个客户端流程量控制的例子。

简单总结下减少影响时间的几个举措：

1. 一定要遵循一个原则，发现问题后，并不是急于找到发生问题的根本原因，而是要考虑如何将业务影响控制到最小的范围内，果断决策，迅速处理。为了提高决策的效率和准确度，应该做好数据收集工作，这个工作可以由人工和系统来做，要逐步提高系数据收集的自动化，另外还要与各方保持畅通的联络；
2. 需要事先准备好预案，并且做好演练；
3. 做好预防措施。常见预防措施是做流量控制，有服务端控制、客户端控制、服务平台控制三种，其中服务端自身流量控制是必须的。服务端和客户端应该约定好 SLA，包括流量上限、超过上限后的措施、出现问题后的应急措施等。

一个比较好的实践是通过服务调用的并发数来控制，这样评估资源需求、控制流量都容易量化，这种方法特别适用于后端系统，比传统的按流量来控制容易得多。

另外一个比较显著的措施是将高峰值的系统独立部署，例如电商秒杀系统，虽然大部分逻辑与正常下单是一致的，但独立出来可以做专门设计（如防作弊），同时可以起到隔离作用，即使秒杀系统出现问题，也不会影响正常下单。

提到自动化措施，对于数据收集、系统降级等，尽量提高自动化程度，但要避免误判。举例说明：系统存活的判别工作经常由独立部署的监控服务来完成，有时候被监控对象与监控服务器之间网络出现问题，但被监控对象正常，这时会发生误判，可以通过增加监控服务器、监控服务器与被监控对象临近部署、借助客户端监控等手段来避免。

某些事关全局的操作，例如 IDC 的切换，因为切换后处理成本较大，建议用半自动化方式，即人工决策和干预后批量自动处理。

故障处理一定要明确时间上的要求，而且还要有流程上的要求，而且级别超高，要求越严格。要求事件发生多长时间介入处理、多长时间控制影响、汇报关系、汇报频率等，出现损失会有惩罚措施，惩罚力度有章可循。这些要求会促使团队不断改进系统、改善运营，团队也在这个过程中得到成长。

总结一下保障措施：

1. 监控与报警；
2. 自动化数据收集；
3. 制定应急预案并演练；
4. 自动化和半自动化的运营工具；
5. 事件分级与处理流程，惩罚制度；
6. 系统负责人制度；

InfoQ：系统高可用是互联网企业系统架构的基础要求之一，您认为一个架构师应该构建怎样的知识体系可以更全面地看待架构发展从而减少架构的短板和瓶颈？

林世洪：第一，你的知识体系里必须有业务，要了解业务架构的梳理和设计方法。可以从自己所负责的系统所支撑的业务起，了解业务整体，了解系统支撑的业务在整体中的位置，进而可以识别核心业务、识别核心业务流程、识别业务领域边界，分析各业务对技术的要求；

第二，系统运行环境对可用性有直接关系，运行环境的高可靠是应用高可用的基础保障，所以你的知识体系里要包括应用的运行环境，包括网络知识、系统知识、简单的硬件知识；

第三，需要有系统运营知识和经验，深刻体会高可用的价值所在，设计上会更有针对性；

第四，注意学习和总结，掌握一些架构设计和治理原则，如：系统、服务、数据的分级分类分层的设计和治理、系统的拆分和依赖设计原则、分布式系统设计，可以研究典型的广泛应用于互联网应用的开源系统的高可用设计，如分布式缓存、分布式文件系统、分布式调度系统等，多了解走在技术前沿的互联网企业的技术架构。

InfoQ：感谢林世洪老师接受我们的采访，期待 ArchSummit 全球架构师峰会上您策划的高可用架构之道专题。

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。