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