对阿里巴巴而言，每年最重要的一天莫过于双11。这是因为在双11的零点，系统会遭遇史无前例的巨大洪峰流量冲击，保证双11当天系统的稳定性对高可用团队来说是巨大的挑战。在这个挑战中会有很多不确定因素，大致分为两方面：
- 技术架构带来的不确定性，阿里在08年开始对系统进行拆分，由原有的单一系统拆分成了分布式架构，包括CDN、网关、负载均衡、分布式页面系统等，整体的技术生态十分丰富。分布式环境任意环节出了问题都可能会对系统造成影响；
- 业务发展带来的不确定性，系统的可用性随着业务增长，面临更严峻的挑战和不确定性。
这些不确定性背后的因素多种多样，既涉及系统容量、业务性能，又涉及基础设施瓶颈、中间件瓶颈和系统之间的依赖影响，并且众多因素缺乏有效的验证手段。事实上，阿里从10年开始就在尝试去解决双11零点的稳定性问题。
最初采用的方式是在线上单机的生产环境的压力测试和容量规划，
主要采用了四种方式：第一在开始阶段模拟调用者，其中在生产环境中只能模拟只读请求，对写请求需要特定的处理；第二种方式是采用流量录制和回放的方式做压力测试，通过将录制的流量快速率回放对单台机器进行压测，获取单台机器的服务能力；后两种是从流量分配的角度出发，分别是请求流量转发和改变负载均衡的权重，两者核心思想都是将流量集中到某台机器上。
通过上述机制和手段，能够准确探测到单台机器的服务能力。基于单台服务能力和预估即将到来的业务流量进行容量规划，确定所需服务器的数目，这种做法伴随着阿里度过了10、11、12三年的双11零点稳定性的考验。
但10和11年双11零点由于流量过大暴露了不少问题，让我们意识到单个系统ready不代表全局ready，究其根本原因在于系统之间相互关联和依赖调用之间相互影响。在做单个系统的容量规划时，所有的依赖环节能力是无限的，进而使得我们获取的单机能力值是偏乐观的；同时，采用单系统规划时，无法保证所有系统均一步到位，大多数精力都集中核心少数核心系统；此外，部门问题只有在真正大流量下才会暴露，比如网络带宽等等。
时间： 2024-10-11 17:43:25