阿里巴巴中间件技术部的高级技术专家周洋(中亭)从能力大促、精细大促和效率大促三个方面探寻双 11 高可用架构演进之路，并对未来双 11 的挑战进行了展望。
阿里双 11 的技术挑战
双 11 技术挑战的本质是使用有限的成本去实现***化的用户体验和集群整体吞吐能力，用最合理的代价解决零点峰值，支撑好业务的狂欢。
阿里做双11已经有八年之久了，八年来双11的交易额增长 200 倍，交易峰值增长 400 多倍，系统复杂度和大促支撑难度以指数级攀升。
并且经过多年的发展，双 11 技术实现链条中的变量不断增加，如峰值的增量和系统架构的变化、交易峰值的组成、拆单比、每个业务入口的访问量等，这些变量也给系统带来了不确定性。
回顾这八年的双 11 零点之战，它推动了阿里的技术进步、推动了架构优化，加速了技术演进和沉淀。
阿里的技术演进是一个螺旋向上的过程，整体高可用演进可以分为三个阶段：能力大促、精细大促、效率大促，下面来一一分析。
阿里双 11 高可用架构演进
能力大促——3.0 分布式架构
能力大促***个要求是解决扩展性的问题。上图是淘宝 3.0 分布式架构，其意义在于让淘宝从一个集中化应用转变为分布化应用。
在该架构中对业务进行了分层，同时在系统中***使用中间件、分布式调用、分布式消息、分布式数据库;架构底层沉淀了分布式存储和缓存。
目前而言，大部分互联网应用都是基于这一架构的，并且发展到现在，该架构并无太大的变化。
随着双 11 业务量的增加，该架构面临着很多挑战：
- 系统的可用性和故障恢复能力，以前集中化架构，出现问题回滚即可;现在由于涉及到众多分布式系统，快速排查和定位问题变得十分困难。
- 分布式改造之后，单个系统存放在特定机房里，随着业务发展，机器数目的增加，机房应用层水平伸缩瓶颈、数据库链接等都成了挑战。
- IDC 资源限制，单个城市已经不足以支撑业务的增长规模。
- 容灾问题，单地域 IDC 单点、网络、台风、电力等导致高风险。
- 国际化部署需求，可扩展性再次成为瓶颈。
针对上述挑战，我们采用了异地多活方案，具体从四个方面出发：首先建设异地单元机房，其次由于业务中买家维度数据远多于卖家维度数据，且卖家维度数据变化并非十分频繁，因此可以将流量按用户维度进行切分。
此外，由于走向异地***的挑战是网络，为了减少异地调用的延时，必须实现业务在本单元的封闭性，减少远程调用，***，由于容灾的需求，数据层实时同步，保持最终一致。
异地多活架构
上图是异地多活架构，可以看出，从 CDN 到阿里内部的接入层都满足单元化规则，根据当前用户的 ID，判断流量的出口;在下游的层层中间件上以及数据写入存储时会对用户请求进行判断，如出现异常，则报错，防止错误的数据写入。
卖家的数据部署在中心，单元的数据会同步到中心，中心卖家的数据也会同步到各个单元，但在各个单元内只能对卖家的数据进行读操作。
那么异地多活的到底有什么意义呢?首先异地多活消除了 IDC 资源单点和容量瓶颈，其次解决了异地容灾问题，业务可以秒级快速切换。
此外，异地多活简化了容量规划，提升了伸缩性和可维护性。***，通过异地多活解决了可扩展性问题，为后续架构演进打下坚实基础。
能力大促——容量规划
对于上文提到的 3.0 架构，单机器的极限能力乘以机器数，在下游依赖都充足的情况下，近似等于整个系统的能力。因此，当前做容量规划，首先需要评估应用线上单机极限能力;再根据公式和经验推演容量规划。
目前，在阿里内部进行容量规划时，面临以下挑战：
- 容量规划的目的是从用户登录到完成购买的整个链条中，整体资源如何合理分配?
- 500+ 的核心系统、整个技术链条长、业务入口多、逻辑复杂。
- 链路瓶颈点较多，每年大促峰值都会出现一些问题，无法提前发现。
- 堆积木的容量规划方法，前面失之毫厘后面谬以千里。
- 在能力评估时应该考虑的是一个处理链路而不仅仅是单一的应用。
- 缺乏验证核心页面和交易创建链条实际承载能力的手段。
压测方案
为了应对上述挑战，我们需要从全链条的角度出发进行压测和容量规划。全链路压测是在线上集群模拟真实业务流量的读写压测，完成从网络、IDC、集群、应用、缓存、DB 以及业务系统上下游依赖链条的容量、性能压力测试。
整体压测通过自定义压测工具，大流量来自机房外部，进而构造线上测试数据，且业务模型接近真实;全链路压测隔离了测试数据和正常数据，两者之间互不影响，并且全链路压测时是对用户体验无感知、无影响的。
全链路压测通过复用中间件的能力，具有超大规模的集群压测能力，每秒千万 QPS。同时将压测引擎部署到全球各地的 CDN 上，实现了分布式部署压测引擎，按照约定的时间发送压测数据。
其次，压测数据是基于线上真实数据进行了脱敏和偏移，数据模型与双 11 极其接近。此外，实现了线程级隔离，无脏数据，压力测试直接作用于线上集群，暴露问题更加精准。
通过全链路压测，打破了不可预知技术风险的限制，加速技术进化;为新技术的尝试和突破做好保底和验收的工作;做到了主动发现问题而不是被动等待、应急处理;通过新的线上演练，为稳定性的确定性打下坚实基础。
能力大促——限流降级
限流降级是能力大促的必要要求。在双 11 开始前，尽管我们准备了大量的机器和能力，然而在双 11 零点到来时，真实业务量还是有可能大于我们的预期。
此时，为了确保我们的机器不超负荷运作，我们采用了限流措施，超过机器极限的业务全部拒绝，避免系统因业务流量的突然过大而崩溃。
目前，阿里能够做到从线程数、请求值、负载多个角度进行限流，从而保障系统的稳定。
分布式应用是默认下游应用是不可靠的，对于一些弱依赖的请求，应该进行提前自动降级。至于哪些应用需要降级?需要降级什么?下游的依赖又是什么?这些问题都是通过依赖治理来解决的。
精细大促——依赖治理
在阿里内部，依赖治理是通过中间件分布式链路跟踪技术，完成系统架构梳理;同时对海量调用链进行统计，得到链路各个依赖系统的稳定性指标;此外，结合业务用例识别强弱依赖，弱依赖可自动降级提供有损服务。
精细大促——开关预案
精细化双 11 控制的首要机制是开关预案。开关是让系统切换不同功能表现的标准技术，可以无需变更代码只推送配置控制系统行为，让系统的后门标准化。
开关中心配置变更可以实时下发到集群，且操作行为对业务而言是原子性的。开关预案整合了一批业务开关、限流等操作，将多系统的后台操作组装批量执行;实现了预案推送是有顺序性的，保证业务切换的一致性和完整性。
精细大促——故障演练
统计学的数据显示：当服务规模大于一定数量时，硬件故障无法避免。因此，系统要面向失败做设计，测试系统健壮性的***方法，就是不要用正常方式使服务停机。对应线上系统，要实现容灾，首先需要实现背后工具体系的容灾。
由于线上故障是一种常态，系统负责人要具备快速发现和处理故障的能力，需要实战机会来成长。另外，跨团队的流程也是需要加以重视，由于业务分布式的特性，出现故障时需要业务系统的上下游共同协作，这就对流程提出来严格的要求。
故障演练的实现方案
前期，我们将阿里电商常见的故障进行画像和分析，得到初步结论，按照 IaaS、PaaS、SaaS 层进行初步划分，但这个模型无法完全通用，并非包含所有的故障。
因此，后期我们对这一模型又进一步抽象，将故障分为进程内的故障，如代码死循环等;进程外的故障，如磁盘读写速度变慢、网络波动等;分布式调用依赖的底层设施故障，如数据库、缓存或者其他设施出现故障。
目前，阿里故障演练实现了业务零改造，可插拔式接入;多维度业务识别和故障注入，定量控制演练影响;沉淀通用故障模型，平台化输出演练能力。
从去年双 11 开始，阿里开始使用线上统一演练环境，通过逻辑隔离，动态扩展逻辑环境，按需租赁，简化测试步骤，使得演练结果更加真实。
同时多套环境互不影响，严格保证环境的稳定和安全;支持用户、业务、数据、流量特征的分流和隔离，提高了效率，赋能业务创新。
效率大促——流量调度
在线上集群中，如果个别机器发生故障，为了保证业务的整体稳定性，需要对故障点进行流量调度。
流量调度通过实时探测与监控分布式环境中每一台机器的状况，如果机器发生故障，则使用分布式服务具有的自我隔离和自我修复能力，使用流量调度和负载均衡机制，通过关注局部用户请求和用户体验，提升整体可用性。
阿里双 11 未来挑战
尽管我们已经采用了很多措施来保障双 11 的稳定性，但未来，依旧面临着不少挑战：
实现更加精细化、数据化、智能化的双 11。
从容量确定性到资源确定性，从每个实例部署在哪里***、精确到每个内核如何分配***。
更加精准的分析、预测流量模型和业务模型，实现预测、引导相结合，逼近真实、增加确定性。
实现技术变量的采集、分析、预测，数据分析驱动，自主决策处理，关键技术指标的预估错误系统做到自适应，弹性处理。
在体验、成本和***吞吐能力方面找到新的平衡点。
