重新认识容量评估，用压测抠住生产命门

以下内容是摘自我知识星球前几天的一个讨论，经过整理发出来分享一下，标题也是群里的同事写的，认识很深刻。

这两天在新加坡参加SRECon也是在分享这个话题，后面会分享更细节的一些东西。目前限免，我的极客时间专栏订阅者优先，加入时带姓名、公司和职位，否则可能会通不过奥。

今天在聊聊SRE星球里面发起了一个关于容量演练的话题。幸运的被赵老师点出，各路大神给出的建议非常精辟实在。

讨论的原文地址:https://t.zsxq.com/QNNJaea以下整理各位老师的观点。

@赵成：

第一，需要知道容量的瓶颈点在哪儿，比如在数据库（慢SQL，明显消耗CPU资源的SQL等），缓存，文件系统，或者某个集群上面等等。需要深入分析问题，再解决这些点上的问题。一般一个问题重复出现在某个点上，把这个点上的问题解决了就能缓解很多，也能认清很多。

不要因为遇到了问题，才考虑到容量评估的这个手段。所以，赵老师建议，可以先回到问题本身，优先把问题解决掉才是最重要，这样也最立竿见影。

第二，容量评估。冰冻三尺非一日之寒。看似是压测一下就可以解决的，其实他是一套体系化的解决方案。

比如，电商做一次压测，大致的步骤会涉及模型评估，核心链路梳理，模型数据制作，单应用单机压测，单链路压测，资源扩容，全链路压测。然后再优化，这中间还要考虑压测时如果对生产环境造成影响。如何快速恢复，这也需要有限流、降级、熔断等手段。 所以，整个过程下来是非常复杂的。如果之前在这些体系上还没有做到位，现在想直接做压测，是不太可行的。里面还涉及工具、数据、模型评估等等，这些东西的是需要大量的经验、时间和实践积累起来的。

这样来看，回到第一条可能，会更切合实际得多。

第三，可以把容量评估作为长期建设目标去规划。

赵老师提到了容量规划的几种方式。如下：

一般情况下，还是先需要先从压测类型来说。首先肯定是单机单应用压测，然后是单链路，然后是全链路。因为只有知道单个应用集群的容量，你才知道这个集群需要扩多少资源，然后再压测单链路，你才知道这个链路上的瓶颈点在哪儿，最后才是全链路压测。

1、单机单应用压测。这个最好使用线上流量压测，不要做复制或模拟。因为线上流量足够大的话，完全可以摸到单机的水位在哪儿。同时还不会有脏数据。

这里又有两种模式。第一种，如果是web服务，前端有Nginx的话，直接将一部分机器的请求重定向到某台主机上，这样就会有2、3、4、5...倍的流量过来，很快就可以拿到这台单机单应用的水位是多少。第二种，如果是LB的模式，直接调整LB上的权重，让每台主机的流量配比大一点，不到水位就继续加大权重。这里的水位是你的系统指标和业务值班，包括：CPU，内存，响应时间，响应正确率等等。

2、单链路压测。这时你就需要模拟流量了，同时这里还有一个暗含条件，就是你必须要找出有哪些是核心单链路。

不同的行业有不同的标准。比如电商，核心链路就是跟交易相关的应用及之间的调用关系，这个要花时间一点点梳理出来。如果是分布式微服务的系统，你就需要有对应的全链路跟踪系统，帮你去分析线上实际的调用情况，不然靠人是玩不转的。比如pinpoint，SkyWalking等等。

同时，跟压测单链路交易无关的应用，就可以做降级或限流处理，即使失败也没关系。比如什么商品推荐，商品评论，订单列表等等。这个跟生成订单，用户付钱没有直接关系，就可以不用管它。但是系统上要做到，这些应用即使挂了，也不能阻塞交易流程，这个是业务实现上就要考虑到的。

同样，对于金融行业，也一定会有这样的链路，策略也是一样的。

3、全链路压测。这一步要造测试数据了，这里的前提还是你要知道你用户的访问模型是怎么样，不然没法造。比如，你要先制造一批测试数据，有：用户ID，测试店铺，测试商品，以及测试用的优惠券，同时一个用户会买多少商品，用哪些优惠券，逛哪些商铺，这些数据和关系要提前生成好。土一点的办法可以用excel或文本工具生成。高级一点的，就用sql语句自动生成。再高级一点，做成Console，通过业务逻辑生成。

再往下，就要组装这些数据。生成真正的HTTP请求或者是RPC的请求，并施压到生产系统。这里有工具可以帮你做这个事情，比如开源的Gatling。

第四，关于读流量和写流量，读流量也就是QPS这个无所谓，不会造成脏数据。但是对于写流量，也就是TPS，要注意区分，不然就是生产环境的脏数据了。

业界通常的做法，就是在打标和做影子表。打标就是给压测请求上带个标识，是压测标。同时数据库中间件要能识别这个标识，将这个标识识别出来，把这样的请求路由到影子表里，而不是写到生产表里面，这样就避免了脏数据。

需要注意的是：影子表里面记录的数据，要跟生产表差不多，不然就体现不出真实的写入性能了。

第五，关于限流和降级。因为压测的时候，一定会比平时压力大，并且还是在生产环境的系统上。所以不可避免的会导致一些大大小小的故障或异常出现。这时要能够及时发现，如果出现某个核心应用或链路，或者核心指标出现异常。一定要能够做到降级和限流保护，同时终止压测。

最后，这套体现不是一朝一夕能建成，要很长的时间，并且还需要业务改造的配合，不可求成，必须慢慢来。通过组织赋能，做到以上赵老师说的这些细节。

回到问题本身，赵老师着重强调第一条，先把当前的瓶颈点找到，然后解决掉这个点上的问题再说。@右军：

容量评估：背后是找短板，提前预防，配置合适的机器数。 1: 先从各系统的性能短板走一波优化； 2: 全局认识主链路系统依赖，有条件的做线上压测，或者从模拟线上流量压测也行。主要是和真实环境模型的匹配度。 3: 回到目标，从业务出发，比如现在是5w/s的交易创建，结合业务发展需要做到10w，就可以找差距。 4: 结合异步、缓存、合并处理等可能可能的具体措施。@黄岛主：

约束理论，先有度量，然后通过度量找到约束点，然后改进。

度量一般要从业务链反向溯源，覆盖端到端，如： 用户层：用户感知指标（如页面响应时长、页面错误率） 业务层：业务流量流速（卡单数量，过单时延等） 应用层：接口响应时延，消息对列长度，消息转发时长 网络层：xxxx 主机层：xxxx

@何剑明-快手：

1.容量这个事情，需要自上而下，从老板层面推动。因为容量压测的大量工作，非常耗时，如果不做为rd 的kpi的一部分，他们是很抵触的。不事先建立共同目标，最后的结果可能是两头不讨好。

2.联合稳定性组来做，能有事半功倍的效果。因为容量极限，容量不足，容量突增这些异常场景本身就是稳定性组要关注的，两者联合，各自工作量减半，目标一致，这事做成的概率更大。

终上，我最大的感受是震撼，赵老师10来分钟就能洋洋洒洒写下几大千字。他的课程可以重新翻看一遍，不同的工作阶段肯定会有不同的感受，定能得到更多启发。