全链路压测|新人第一问：为什么你做不好容量评估？

去年8月，国内某大型快递公司S为了应对双十一的快递系统高峰，想学习阿里用全链路压测的方法对系统进行提前检查、优化系统性能。

于是经朋友介绍，知道隆冬强所在的公司做过类似的行业解决方案，深入了解隆冬强所在公司的产品后，决定进行全链路压测方面的合作。

隆冬强是一位业内知名的大数据专家，对大数据存储、离线和实时计算如数家珍，每天研究的是比Flink更牛B的实时计算系统，但大数据专家也有自己不太熟悉的领域。

原本负责压测项目的小黑，那段时间正忙的脱不开身，于是这个任务就落在了这位大数据专家隆冬强的头上，但此时他对全链路压测也是一知半解，于是打算找小黑聊聊，之后再去S公司调研。

全链路压测就好比是性能领域的核武器，隆冬强早就耳闻其威名，这个概念在2013年双十一由阿里巴巴首次提出，并最后成功实施，效果得到广泛的一致好评。

跃跃欲试的隆冬强在去客户现场之前就找到了小黑同学，于是便有了如下对话。

隆冬强：

我之前做大数据领域的，对于性能压测领域不熟悉，双十一活动扩容这个事情找各个应用的负责人评估一下容量就可以了吧，为什么还需要我们来做这个事情？

小黑：

在传统的单体架构时代，一般也是靠经验来评估的，因为传统架构时代流量不大，架构简单，在测试环境完全搭一套隔离环境来模拟生产就可以。只要保证硬件、软件配置基本相同，那么测试结果也会相对准确。

但是在分布式时代，情况往往不同，容量评估变得很难，解答这个问题之前，让我用曾经在阿里的经历讲一下容量规划这个事情，主要经历了以下四个重要阶段：

01、经验+拍脑袋阶段

最开始Denali（淘宝早期系统名称）的时代，线上容量大致估算一台机器一天100万PV（访问量）来计算活动预估PV是多少的。

举例说明：某公司运营需要策划一场活动，目标访问量为2000万，此时只需要通过简单的公式比如：2000万 / 100万 = 20 ，那么工程师就能可以快速的估算需要20台机器了。

简单利用公式就能算出需要多少台机器，上述的100万PV为一个经验值，在单体架构下这种计算方式还是非常有效的。

02、商业压测工具（线下测试）阶段

2008年后淘宝进入了大规模的分布式改造阶段，系统越来越庞大且复杂，大家认识到经验主义已经不可行了。于是开始引入商业的压测工具，想达到评估线上容量的目标：即通过性能环境的测试数据，来准确评估线上的容量情况。

在分布式环境下，这个目标一直得不到解决，原因是线上环境和测试环境硬件、软件配置、数据规模完全不一样，而且也没有规律可循，因此无法达到这个目标。

03、线上只读压测阶段

随着互联网的发展，商业压测工具已经解决不了目前发展变革所带来的问题，阿里当时提出了一个大胆的解决方案：利用线上环境压测。收集线上访问日志汇总分析，在短时间回放访问请求，通过响应时间和线上机器负载，准确的评估线上的容量情况。

这种线上只读的解决方案目前只能解决只读流量压测，涉及到写入的（如下单、注册、发布商品等）流量还是不能发挥其作用。针对这种情况，当时还提出另一种线上引流压测方式，通过动态调整负载均衡的策略，把线上流量引流到特定几台机器来验证线上单机的准确容量。这个阶段已经可以让部分压测自动化，不再需要开发团队自己搭环境压测了，性能测试团队也能及时地响应任何一个上线版本的性能验证对比问题。

04、全链路压测阶段

第三阶段的线上只读压测能力虽说已经有了很大的提升，但是仍不能彻底的解决双十一容量精准评估问题。2013年阿里云提出了通过影子表、影子库等技术来实现全链路压测的概念，对集团的所有的中间件、核心应用针对性的做了改造，使其具备支撑全链路压测的能力。

影子表能力可以让压测产生的写入数据全部都隔离到其他区域，不影响正式数据，应用升级中间件后就自动具备了这个能力。为了解决商业压测工具不能提供超大瞬间流量的问题，阿里自研了压测流量产品，通过分布在全国各地的CDN机器，同时发起超大并发流量，对集团内部应用进行全链路压测。

通过模拟双十一相同的生产集群、流量模型、流量规模的方案，来提前验证系统是否具备支撑双十一的高压能力，从而保障了阿里双十一的稳定运行。

S公司的系统架构已经不是单体架构，在面对双十一的高峰流量时，并不能通过购买传统的商业压测来解决容量评估问题，想要很好的解决这个问题其实是一件非常困难的事。

阿里汇集了全球顶尖的技术人才，在这条路上探索了五年时间，才能在线上环境具备这样准确估算容量的能力。阿里能做成这样的事情，有许多因素不得不说：顶尖的技术人才、统一的技术框架、底层框架的定制能力。目前国内能同时满足这三者的公司屈指可数，所以这并不是一件简单的事情。

听完小黑所说，隆冬强感叹原来现在系统容量的准确评估难度这么大，看起来不比大数据简单啊。

更多内容请关注公众号【数列科技公司】，领取更多关于全链路解决方案的内部核心资料！