全链路压测|新人第一问：为什么你做不好容量评估？
隆冬强提问 | 小黑回答
小黑，我之前做大数据领域的，对于性能压测领域不熟悉，双十一活动扩容这个事情找各个应用的负责人评估一下容量就可以了吧，为什么还需要我们来做这个事情？
在传统的单体架构时代，一般也是靠经验来评估的，因为传统架构时代流量不大，架构简单，在测试环境完全搭一套隔离环境来模拟生产就可以。只要保证硬件、软件配置基本相同，那么测试结果也会相对准确。
但是在分布式时代，情况往往不同，容量评估变得很难，解答这个问题之前，让我用曾经在阿里的经历讲一下容量规划这个事情，主要经历了以下四个重要阶段：
经验+拍脑袋阶段
2008年后淘宝进入了大规模的分布式改造阶段，系统越来越庞大且复杂，大家认识到经验主义已经不可行了。于是开始引入商业的压测工具，想达到评估线上容量的目标：即通过性能环境的测试数据，来准确评估线上的容量情况。
在分布式环境下，这个目标一直得不到解决，原因是线上环境和测试环境硬件、软件配置、数据规模完全不一样，而且也没有规律可循，因此无法达到这个目标。
随着互联网的发展，商业压测工具已经解决不了目前发展变革所带来的问题，阿里当时提出了一个大胆的解决方案：利用线上环境压测。收集线上访问日志汇总分析，在短时间回放访问请求，通过响应时间和线上机器负载，准确的评估线上的容量情况。
这种线上只读的解决方案目前只能解决只读流量压测，涉及到写入的（如下单、注册、发布商品等）流量还是不能发挥其作用。针对这种情况，当时还提出另一种线上引流压测方式，通过动态调整负载均衡的策略，把线上流量引流到特定几台机器来验证线上单机的准确容量。
这个阶段已经可以让部分压测自动化，不再需要开发团队自己搭环境压测了，性能测试团队也能及时地响应任何一个上线版本的性能验证对比问题。
第三阶段的线上只读压测能力虽说已经有了很大的提升，但是仍不能彻底的解决双十一容量精准评估问题。
2013年阿里云提出了通过影子表、影子库等技术来实现全链路压测的概念，对集团的所有的中间件、核心应用针对性的做了改造，使其具备支撑全链路压测的能力。
影子表能力可以让压测产生的写入数据全部都隔离到其他区域，不影响正式数据，应用升级中间件后就自动具备了这个能力。
为了解决商业压测工具不能提供超大瞬间流量的问题，阿里自研了压测流量产品，通过分布在全国各地的CDN机器，同时发起超大并发流量，对集团内部应用进行全链路压测。
通过模拟双十一相同的生产集群、流量模型、流量规模的方案，来提前验证系统是否具备支撑双十一的高压能力，从而保障了阿里双十一的稳定运行。
S公司的系统架构已经不是单体架构，在面对双十一的高峰流量时，并不能通过购买传统的商业压测来解决容量评估问题，想要很好的解决这个问题其实是一件非常困难的事。
阿里汇集了全球顶尖的技术人才，在这条路上探索了五年时间，才能在线上环境具备这样准确估算容量的能力。
阿里能做成这样的事情，有许多因素不得不说：顶尖的技术人才、统一的技术框架、底层框架的定制能力。目前国内能同时满足这三者的公司屈指可数，所以这并不是一件简单的事情。
说完阿里的方案，那我们公司是怎么做容量规划的呢？
嗯，我们公司有将近三年多的全链路压测行业经验，而且超过半数的同事是从阿里过来的，对于合作公司我们除了采用与阿里一致的全链路压测解决方案，还花了大量的时间精力去突破行业瓶颈难题。针对那些没有顶尖的技术人、统一的技术框架、底层框架定制能力的公司，我们提供的不仅是与阿里相当实力的精准评估容量的能力，还会提供我们沉淀多年的行业宝贵经验，让普通的测试、开发同学也可在生产环境中进行安全的全链路压测，以减少上线后的卡顿故障问题。为保证企业的正常运转提供了举足轻重的作用。
今年初国内某Top10高校与我们公司合作，从0到1标准化产品完成接入，14天内进行了三轮核心系统的全链路线上压测，并配合其他供应商完成所有的优化工作，正因为有我们公司的参与，才能在疫情来临之时，保障了50000学生与教职工在线上课的0故障稳定系统。这么大规模的全面在线教学系统在传统的教育行业也实属罕见。
我们公司在教育行业的全链路压测完美成果说明，我们不仅仅在物流、零售、航空、电商等领域属于业界一流水准，在教育行业也是首屈一指的。
———————— E N D ————————