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