阿里高可用的两大法宝

SREcon 是由计算机科学领域知名机构 USENIX 主办，聚焦网站可靠性、系统工程、以及复杂分布式系统相关的运维行业技术盛会，今年 SREcon17 大会 Asia/Australia 站于当地时间 5 月 22 日 -24 日在新加坡举行。吸引了来自 Google、Facebook、微软、阿里巴巴、百度和滴滴等全球著名互联网科技公司的顶级技术专家，到会分享网站可靠性工程相关的议题，包含大规模网站可用性提升、资源规划及性能优化等话题。

本文源自阿里巴巴容量规划和全链路压测在 SREcon 大会上的演讲分享，分享者是阿里中间件（Aliware）团队高级技术专家张军（花名游骥）和林佳梁（花名子矜）。

双十一从 2009 诞生到现在，2013 年绝对是一个分水岭。

为什么这么说？因为 2013 有了全链路压测。

每年的 11 月 11 日 00：00：00，阿里巴巴集团最紧张激动的时刻到来了。多收档的热情这一刻开始爆发，反映到数字上是去年双十一今人的记录：24 小时交易额 1012 亿，交易创建峰值 17.2w；而在二进制世界里面，则是极短时间内如海啸般涌入的超大规模流量。

流量洪峰的杀伤力，曾在 2011 年和 2012 年给技术团队留下了午夜惊魂的难忘回忆。然而随着全链路压测的登场，它改变了阿里巴巴对应流量洪峰的态度和方式，也一次次刷新中国互联网世界的纪录。

阿里巴巴有着非常丰富的业务形态，每种业务都由一系列不同的业务系统来提供服务，每个业务系统都分布式地部署在不同的机器上。随着业务的发展，特别是在大促营销等活动场景下（比如双 11），需要为每个业务系统准备多少机器对于阿里巴巴技术团队来说是一大难题。“容量规划”正是为解决这个难题而诞生， 容量规划的目的在于让每一个业务系统能够清晰地知道：什么时候应该加机器、什么时候应该减机器？双 11 等大促场景需要准备多少机器，既能保障系统稳定性、又能节约成本？

在双 11 等大促场景的准备过程当中，容量规划一般分为四个阶段：

1. 业务流量预估阶段： 通过历史数据分析未来某一个时间点业务的访问量会有多大；

2. 系统容量评估阶段： 初步计算每一个系统需要分配多少机器；

3. 容量的精调阶段： 通过全链路压测来模拟大促时刻的用户行为，在验证站点能力的同时对整个站点的容量水位进行精细调整；

4. 流量控制阶段： 对系统配置限流阈值等系统保护措施，防止实际的业务流量超过预估业务流量的情况下，系统无法提供正常服务。

在第一个阶段当中，通过合适的预测算法和丰富的历史数据，通常能够比较准确地预估业务的访问量。即使在第一阶段预估的业务访问量跟实际的存在误差，通过第四阶段的流量控制也能够确保站点始终处于良好的服务状态。做完业务访问量的预估之后，容量规划进入第二阶段，为系统进行容量的初步评估。如何通过精准的容量评估，用最小的成本来支撑好预估的业务量是这个阶段的核心问题。

要计算一个系统需要多少台机器，除了需要知道未来的业务调用量之外，还有一个更重要的变量，就是单台机器的服务能力。获取单台机器的服务能力在阿里巴巴是通过单机压测的方式来获取。在阿里巴巴， 为了精准地获取到单台机器的服务能力，压力测试都是直接在生产环境进行，这有两个非常重要的原因：单机压测既需要保证环境的真实性，又要保证流量的真实性 。否则获取到的单台机器服务能力值将会有比较大的误差，影响到整个容量规划的准确性。

生产环境进行单台机器压力测试的方式主要分为 4 种：

模拟请求的实现比较简单，也有非常多的开源或者商业工具可以来做请求模拟，比如 apache ab、webbench、httpload、jmeter、loadrunner。通场情况下，新系统上线或者访问量不大的系统采用这种方式来进行单机压测。模拟请求的缺点在于，模拟请求和真实业务请求之间存在的差异，会对压力测试的结构造成影响。模拟请求的另一个缺点在于写请求的处理比较麻烦，因为写请求可能会对业务数据造成污染，这个污染要么接受、要么需要做特殊的处理（比如将压测产生的数据进行隔离）。

为了使得压测的请求跟真实的业务请求更加接近，在压测请求的来源方式上，我们尝试从真实的业务流量进行录制和回放，采用请求复制的方式来进行压力测试。请求复制的方式比请求模拟请求方式的准确性更高，因为业务的请求更加真实了。从不足上来看，请求复制同样也面临着处理写请求脏数据的问题，此外复制的请求必须要将响应拦截下来，所以被压测的这台机器需要单独提供，且不能提供正常的服务。请求复制的压力测试方式，主要用于系统调用量比较小的场景。

对于系统调用量比较大的场景，我们有更好的处理办法。其中的一种做法我们称为请求的引流转发，阿里巴巴的系统基本上都是分布式的，通过将多台机器的请求转发到一台机器上，让一台机器承受更大的流量，从而达到压力测试的目的。请求的引流转发方式不仅压测结果非常精准、不会产生脏数据、而且操作起来也非常方便快捷，在阿里巴巴也是用的非常广泛的一种单机压测方式。当然，这种压测方式也有一个前提条件就是系统的调用量需要足够大，如果系统的调用量非常小，即使把所有的流量都引到一台机器，还是无法压测到瓶颈。

与请求引流转发的方式类似，最后一种压测方式同样是让分布式环境下的某一台机器分配更多的请求。不同的地方在于采用的方式是通过去调整负载均衡设备的权重。调整负载均衡方式活的的压测结果非常准确、并且不会产生脏数据。前提条件也需要分布式系统的调用量足够大。

在阿里巴巴，单机压测有一个专门的压测平台。压测平台在前面介绍的 4 种压测方式基础上，构件了一套自动化的压测系统。在这个系统上，可以配置定时任务定期对系统进行压测，也可以在任意想压测的时间点手动触发一次压测。在进行压测的同时，实时探测压测机器的系统负载，一旦系统负载达到预设的阈值即立刻停止压测，同时输出一份压测报告。

因为是在生产环境进行压测，我们必须非常小心，保障压测过程不影响到正常的业务。在单机压测平台上，每个月将进行 5000 次以上的压测，系统发布或者大的变更都将通过单机压测来验证性能是否有变化，通过单机压测获取的单机服务能力值也是容量规划一个非常重要的参考依据。

有了预估的业务访问量，也知道了系统单台机器的服务能力，粗略的要计算需要多少台机器就非常简单了。

最小机器数 ＝ 预估的业务访问量 ／ 单机能力。

通常情况下，我们会预留少量的 buffer 来防止评估的误差和意外情况。

进行到这一步，我们已经完成了系统容量的粗略评估，然而做到这一步是不是就够了呢？过去的教训曾经狠狠地给我们上了一课。

我们对每一个系统都做好了粗略的容量计算，以为一切都会比较顺利了，可是真实场景并非如此，当双 11 的零点到来的时候，许多系统的运行情况比我们想象的要更坏。原因在于真实的业务场景下，每个系统的压力都比较大，而系统之间是有相互依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况，会引入一个不确定的误差。这就好比，我们要生产一个仪表，每一个零件都经过了严密的测试，最终把零件组装成一个仪表，仪表的工作状态会是什么样的并不清楚。

事实上我们也有一些血的教训。在 2012 年的双 11 零点，我们一个系统的数据库的网卡被打满了，从而导致部分用户无法正常购物，尽管当时我们做了非常充分的准备，但还有一些事情是我们没考虑到的。

需要怎么样才能解决这个问题？在 2013 年的双 11 备战过程当中，在很长一段时间内这都是我们面临的一个难题。在中国，学生通常都会有期末考试，为了在期末考试中取得比较好的成绩，老师通常会让学生们在考试前先做几套模拟题。双 11 对我们的系统来说就是一年一度的期末考试，所以我们冒出了这么一个想法：“如果能让双 11 提前发生，让系统提前经历双 11 的模拟考验，这个问题就解决了”。通过对双 11 零点的用户行为进行一次高仿真的模拟，验证整个站点的容量、性能和瓶颈点，同时验证之前进行的容量评估是否合理，不合理的地方再进行适当的微调。