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

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

这两天在新加坡参加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来分钟就能洋洋洒洒写下几大千字。他的课程可以重新翻看一遍,不同的工作阶段肯定会有不同的感受,定能得到更多启发。

本文分享自微信公众号 - 聊聊SRE(forrest_thinking)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-06-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励