从种树说起：走近微服务和全链路压测
据说，超过70%的IT从业人员，不知道“全链路压测”具体是什么！当别人问起，我们该怎么聊这个词显得不外行？
本文名为《从种树说起：走近微服务与全链路压测》，将真的从种树说起，带你远观和近玩，了解微服务和全链路压测的基础知识，并介绍下得到App每年的全链路压测工作具体做了什么。
一、远观：全链路压测的知识
在准备这个分享题目的时候，突然觉得用种树这个行为来类比微服务的问世、以及全链路压测的目的，是无比的贴切，所以我真的要从种树开始说起了。
种一棵树至少需要4步：第1步首先要挖个坑，然后放入树苗，第3步往坑里填泥土，最后一步是浇水，比著名的把大象赶到冰箱里还多了1步。
我们再来看一下种树的人力与分工。在小学，需要三个人协作完成，通常不会有明确的分工，全凭小朋友的兴趣。到了中学，长大了，有力气了，也会讲究分工了，效率也高了，两个人就可以搞定。
再后来，一个全能的程序猿就搞定所有的功能，挖坑、放树苗、填土和浇水。这是一个非常厉害的猴子。
于是呢，我们来一个不那么恰当类比：当把所有的技能放到一个猴子身上，就有点像早期的一种架构，这种架构下通常把所有的功能服务部署到一台大型的服务器上。
右面这个图，就是一个小型机的图，这样的服务器性能非常好，但是超级贵，使用的DB也很可能是Oracle，通常只有一些超级有钱的主会用。而这种把所有功能服务部署在一台服务器上的时代，就是我们后面要说的单体应用架构时代。
包括现在很多的头部互联网公司在内，很多互联网公司都是从单体架构起步的。早期的时候，单体架构的这种扩展方式可以很好地满足使用需求，但随着时间的推移，这种方式就会产生很多问题，具体表现如下。
1. 应用复杂度增加，更新、维护困难。一个简单的应用会随着时间的推移而逐渐变大。一旦应用变得庞大而又复杂，开发团队将会面临很多问题，很难进行二次开发或维护，不能期望所有的程序猿都成为孙悟空那样的“神猴”。
2. 易造成系统资源浪费
虽然使用负载均衡的方式可以对项目中的服务容量进行水平扩展，这样就会导致其他不需要扩展的服务也进行了相应的扩展，但这些扩展是不需要的，因此这种方式会极大地浪费资源。
3.应用可靠性低
当所有模块都运行在一台机器、一个操作系统、甚至是一个进程中时，如果任何一个模块中出现了一个Bug，可能会导致整个进程崩溃，从而影响到整个应用。
4.影响开发效率
当一个应用越大时，启动时间就会越长。开发和调试的过程中，如果有很大一部分时间都要在等待中度过，那么必然会对开发效率有极大的影响。
一句话概括就是：猴子和机器，都得特别强。
架构演进到了SOA时代
面向服务的架构（SOA）是一个组件模型，SOA将原来的单体架构按照功能细分为不同的子系统（或称为服务），并通过这些服务之间定义良好的接口和协议联系起来。比如各个子系统依赖服务中间件来调用所需服务。
SOA架构通过多个组件服务来完成请求的方式有很多好处，具体如下：
· 把项目拆分成若干个子项目，不同的团队可以负责不同的子项目，从而提高开发效率。
· 把模块拆分，使用接口通信，降低了模块之间的耦合度。
· 为企业的现有资源带来了更好的重用性。
· 能够在最新的和现有的应用之上创建应用。
· 能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。
使用SOA解决了单体架构中的问题，但多数情况下，SOA中相互独立的服务仍然会部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多，SOA的服务会变得越来越复杂。本质上看，单体架构的问题并没有因为使用SOA而变得更好。
客户端开发的同学其实可以快速的理解Soa架构，就好比客户端上App的开发架构，无论怎么划分组件，但终究要编译部署在一个app或者一部手机里面。
微服务时代来了
终于，随着云服务和容器技术的兴起，微服务架构成为了主流。我们看到，从一个猴子，演变成了按照领域的不同来分工的多个角色。
这个变化的带来的好处有这些：
1. 复杂度可控
微服务架构在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰地表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性，并提高了开发效率。
2. 可独立部署
由于微服务具备独立的运行进程，所以每个微服务都可以独立部署。当某个微服务发生变更时，无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低了对生产环境所造成的风险，最终缩短应用交付周期。
3. 技术选型灵活
微服务架构下，技术的选型是多样化的。每个团队都可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术。由于每个微服务相对简单，当需要对技术进行升级时，所面临的风险较低，甚至完全重构一个微服务也是可行并容易的。
4. 易于容错
当架构中的某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，导致整个应用不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
5. 易于扩展
单个服务应用也可以实现横向扩展，这种扩展可以通过将整个应用完整地复制到不同的节点中实现。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
当发现种树效率低，单体服务时代只能通过压榨猴子，或者增加全能的猴子的数量来整体扩容。
6. 专注领域
每个微服务都有自己的业务领域，并且一个微服务一般只完成某个特定的功能，例如商品服务只管理商品、客户服务只管理客户等。这样开发人员可以完全地专注于某一个特定领域功能的开发，而不用过多地考虑领域之外其他因素，有利于团队形成自己的通用语言和领域专家，从而提高开发效率。
写到这里时，我想到了那个关于“微服务给领域驱动设计带来了第二春”的说法。领域驱动设计里面的一些知识可以指导我们进行微服务的划分和业务开发，感兴趣的同学可以移步《 》。
再来个类比，一个全能的猴子就好比是单体架构，而按专业领域明确分工好比是微服务架构。微服务架构根据领域划分，技术架构嵌于各个服务中。
我们不能简单的评判架构的优劣，每个架构都有其适用的范围和时代特征，后者是在容器化技术成熟以后才得以流行起来。
在《演进式架构》中有一段内容，“软件架构并不是在真空环境中构建的，它们始终反映其所处的环境。例如，当SOA还是流行的架构样式时，企业不会使用开源的操作系统，所有基础设施都需要付费获得使用许可，且非常昂贵。十年前，如果开发人员提议使用微服务、在具有单独操作系统和主机的实例上运行服务，那么他会被运营中心嘲笑，因为这种架构在当时贵得离谱。由于软件开发环境的动态平衡，新的环境孕育新的架构。”
读到了这里，你可能已经有了这些疑问？
为什么会花时间介绍架构演进？
相对于全链路，是不是还有单链路压测？
单链路压测解决什么问题？
全链路压测和栽树到底什么关系？
首先来回答一下为什么介绍架构演进，因为全链路压测的问世和微服务架构流行，有着不可分割的关系。在早期的单体服务时代，是没有这个名词的。
相对于全链路，是不是还有单链路压测？单链路压测解决什么问题？
单链路服务压测，通常是在全链路压测前首先要做的，就是把压测的流量，打到具体的一个微服务上，来找到单个微服务系统的能力极限和系统问题。
为了大家更好的理解，我们还拿栽树来说明。比如把订单服务类比栽树，一个专业挖坑的人一小时可挖20个坑，把商品服务必做放树苗，一小时可以放80棵树苗，把用户服务比作填坑，一小时可填40个坑，某功能服务比作浇水，他的能力极限是一小时可浇30棵树。
问：如何通过系统（人员）扩容，实现一小时完整的栽150棵树？
从下图可以看出，我们需要8个栽树的系统（人），2个放树苗的系统，4个填坑的系统和5个浇水的系统。而在单体架构时代来扩容，就需要把昂贵的猴子的数量也成倍增加，但是总体的代价要高于微服务架构。
问：在不扩容，也就是不增加人员储备的情况下，我们这个栽树小组，一小时最少可以完整的栽多少棵树？
有人可能已经发现了，是20课，因为一个小时只能挖20个坑，这是整个链路系统的瓶颈值。
正确的答案是0棵树！
为什么呢？我们来看下面这段文字。
“苏联报纸上曾刊登过一组漫画：
三个工人一起种树，
其中第一个人挖坑，第二个人往坑里放树苗，第三人往坑里填泥土。
有一天第二个工人没来上班，第一个工人照样挖坑，第三个工人照样往没有树苗的坑里填泥土。"
同理，在微服务的架构中，如果关键的核心服务挂掉，很可能就是整件事情就无法正确完成，平台提供的服务也就无法完整的交付给用户。
全链路压测，就是要把可能掉队的局部找出来并优化掉，把对全局的影响降级到最低，保证系统在极端情况下的高可用！
例如，某电商平台购物车相关服务调用链结构图，从左到右依次展示了首页、单品列表、购物车、结算等购物信息流。这个链路上某个环节掉链子，最终都可能会影响整个购买下单流程。
全链路压测的背景
种树的过程了解了微服务，终于轮到主角登场了。首先来介绍下全链路压测的起源，在许多资料和业内公认的起源是“阿里双十一”。
淘宝双11活动从2009年首次举办。
在2013年双11之前，整个阿里的平台没人能确保平台能万无一失，特别是面对11月11号0点刚到时的瞬间访问洪流。为什么没办法真正做到万无一失呢，最重要的一点是没办法让整个平台在双11之前经受到双11当天那样体量和完整交易链路的请求，很多双11之前的准备工作只是对今年双11可能的最高峰值进行服务器资源的配置，即前面提到的一系列限流降级等平台保护措施；容量压测又仅仅是基于单机的服务处理能力，对应的容量规划也是针对单个应用去评估；全面细致的线下压测，即在搭建跟生产环境几乎同样配置的预生产环境中进行各种模拟压测，这样的线下模拟压测确实能够发现一定的性能问题，但这样的测试跟双11当天所产生的业务链路覆盖度以及数据请求的多样性是完全无法比拟的；此外，在机房、网络、中间件、存储等一系列环节同样充斥着各种不确定性。
2012年“双11”零点惊魂促使阿里下决心搞定“全链路压测”，用模拟的流量进行极限压测以获得生产系统的真实负载能力，经过 2013 年、2014 年连续两年的实战摸索，现在已然成为阿里“双11”稳定运行的利器。
全链路压测的常见目标
目标1：利用全链路压测保障系统稳定性，通过生产环境的实际业务压力发现最真实的性能短板，有针对性地进行优化。
例如得到App中的锦囊服务，用户在实现浏览锦囊的时候，会直接或间接调用虚线框中的任何一个服务，其中一个服务不正常，都会影响用户体验。
目标2：利用全链路压测，提前找到网络节点的问题，督促服务商优化。【常用于自建机房的场景】
比如中心机房在北京，由于某个活动要在南方的一些省市投放广告，搞市场活动，那么这个场景的全链路压测还需要验证网络节点的因素。如果某个骨干网节点有问题，中心机房扩容再多都浪费。
全链路压测的使用场景
通常，在遇到如下的场景时，我们可以使用全链路压测来帮助我们。
现在，我想对于之前的这4个问题，我们每个人心里都有了自己的答案。
二、近玩：得到的全链路压测
每一年，罗辑思维都会举办《时间的朋友》的跨年演讲，并在电视和视频网站直播。第一年是在优酷，有200多万人的在线观看，第二年是在深圳卫视合作直播，并在优酷等视频网站同步。直播过程中会有些活动，为App和平台在同一时刻引来了大量的用户请求。这就意味着，如果没有对这个做好应对，那么在直播过程中就有可能出现大面积服务中断。
所以，得到也引入了全链路压测。曾经应阿里云邀请，同事也写了一篇文章《罗辑思维在全链路压测方面的实践和工作笔记》，附上链接，感兴趣的网友可以查阅。
https://developer.aliyun.com/article/691001
全链路压测公认的几个挑战点
参考了一些资料，结合我们自身的实践，总结了如下4个挑战点。
1.涉及的系统多，牵扯的开发人员多，存在跨部门、跨平台的服务调用；
2.模拟的测试数据要接近真实访问流量，评估过高和过低都是资源的浪费；
3.数据隔离，压测不能影响生产环境；
4.压测工具，如何发起海量的请求。
上述问题，我们公司目前的应对策略如下：
1、通过领导重视，几年下来，技术部门对于这个事情的重视程度也基本达成了共识。公司层也面高度重视，每年Q4服务端都要预留（强占）人力资源。
2、是如何评估数据模型的问题。后面会详细说。
3、通常有三个级别，影子数据、影子表和影子库。压测的标识信息，要求所有系统都能识别，并支持影子表写入。据一些老同事描述，第一期的系统改造过程无比艰难。
4、得到利用业内的先进工具，比如阿里云的PTS，而有的大厂资源充足会去自建。关于是否要自建，留给读者思考，感兴趣可以留言交流。
阿里云PTS发起海量的请求，当识别为压测流量时，写请求要求数据必须写到影子表，而读请求根据业务场景自行决定。
得到全链路压测过程
1、梳理与准备（10月）
排期：制定工作计划，圈定需要参与的人员，提前准备，每年Q4的重点工作内容之一。
系统改造：压测场景的全部系统，要支持传递并识别压测标识，把压测数据正确写入“影子表”。
流量模型的确定：基于业务峰值的一个时间段内统计各接口的峰值，最后拼装成压测的流量模型。
2、单链路压测（11月）
单链路压测：先对独立的业务系统进行压测，找到问题进行整改，确定什么样的硬件配置可以抗住目标值120%的流量，从而确保单个业务场景达标。
从下图可以看到，单链路压测的过程还是曲折的，也发现了一些在正常流量下暴露暴露不出来的问题。
3、全链路压测（12月底前）
全链路压测：用预估的流量，对所有压测列表的接口同时进行压测，模拟跨年活动时会涌入的流量。
当全链路压测的时候，有的服务流量会比单链路压测时放大许多倍，甚至发现一些新的问题。比如跨年前12月份的最后一个版本，上线了一个新的“学习清单”的功能，据说跨年演讲的时候有口播，所以压测试给这个服务增加了流量，结果导致相关的好几个服务需要扩容。
每年的全链路压测工作，帮助技术团队在《时间的朋友》跨年演讲活动期间，保障得到App和平台高可用。2020年是个特殊的一年，而今年的跨年演讲活动将在武汉举行，提前送上祝福，也希望本文能让你走近全链路压测，能对你有所启发。
参考资料
•《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》
•《分布式系统架构：技术栈详解与快速进阶》
•《逆流而上：阿里巴巴技术成长之路》
•《高可用架构》
•https://www.jianshu.com/p/27060fd61f72
•https://www.aliyun.com/product/pts
•https://developer.aliyun.com/article/691001