【博客349】微服务容量如何规划？

内容： 记录规划微服务容量的一些想法

背景：

在单体应用时，只需要针对这个单体应用的访问量和实际接口性能来决定要不要给单体应用扩容，
而拆分为众多的微服务之后，需要考虑每个服务的容量规划，它的复杂度主要来自下面几个方面：

1、服务数量众多，纯靠人肉运维难以管理

2、服务的接口表现差异巨大，有的接口属于访问量比较大，但接口响应时间比较短的轻接口；
   有的接口属于访问量比较小，但接口响应时间比较长的重接口。
   
3、服务部署的集群规模大小不同，需要扩容的机器数量差异很大。

4、服务之间还存在依赖关系，在服务扩容的时候，还需要考虑依赖服务的容量是否足够。

容量规划的关键点：

1、如何评估集群的最大容量和线上实际运行的负荷，也就是如何做好容量评估；

2、如何确定弹性扩缩容的时机以及机器数，也就是如何做好调度决策。

关键点的解决思路：

* 容量评估：
一般集群的容量评估都是通过线上实际压测来确定的，那么该如何进行线上压测呢？

1. 选择合适的压测指标
一般在选取压测指标时，主要有两类：一类是系统类指标，比如机器的 CPU 使用率、内存占用量、
磁盘 I/O 使用率以及网卡带宽等；一类是服务类指标，比如接口响应的平均耗时、错误率。

但这些指标在实际压测时，都会存在一些问题。系统类指标比如 CPU 使用率并不能直接反映出服务
压测时的健康状况，有时候 CPU 使用率不高的时候，接口耗时也可能有问题；而有时候 CPU 使用
率较高时，接口耗时表现依然很正常。而服务类的指标比如接口响应的平均耗时也不能精确的反映服务
的实际健康状态，一个最典型的场景就是在压测时，已经出现一定比例的慢请求，而在平均耗时上并不
能看出有多大变化，这时候实际服务已经处于不健康的状态了，应该停止压测了。

在压测时，除了观察以上这些指标以外，还可以观察接口的慢速比，也就是接口响应时间高于某个阈值
的比例。

2. 压测获取单机的最大容量
集群的最大容量就是单机的最大容量 × 集群内的机器数量，所以要获得集群的最大容量，就须获得
单机的最大容量。通常有两种方式来获取单机的最大容量，一种是单机压测，一种是集群压测。

单机压测一般有两种方式，一种是通过日志回放等手段，模拟线上流量来对单机进行压测；
一种是通过 TCP-Copy 的方式，把线上机器的流量拷贝过来对单机进行压测。

集群压测是对整个集群进行压测，以获取单机的最大容量。一般做法是通过不断把线上集群的节点
摘除，以减少机器数的方式，来增加线上节点单机的流量，从而达到压测的目的。

采用集群压测的方式要更合理一些，因为它是完全使用线上真实流量进行压测，获取的单机最大容量
数值更精确。如果采用单机压测，通常为了避免产生“脏数据”，往往需要去掉一些上行的修改请求，
所以不能完全模拟线上真实情况。不过使用集群压测的方式也有一个缺点，就是压测的时候会对线上
用户的实际请求产生影响，如果压测出问题了，会直接影响线上服务，所以一般会选择在业务低峰期
进行压测，最大限度减少对线上服务造成的影响。还有一点是，通常会在工作日进行压测，以便出现
问题时，也能人为快速介入。

假设我们采用集群压测，不断地缩减线上节点的数量，并观察服务的慢速比指标，当慢速比达到1%时，
就停止压测，这个时候就可以计算单机的最大容量了，一般做法是用压测停止时刻的单机平均QPS作
为单机的最大容量。但是，采用QPS就真的合理吗？实际上并非如此，这是因为QPS并不能准确衡量
单机的消耗


所以，一个更合理的计算单机容量的方式是采用区间加权来计算，也就是把请求按照响应时间分成多
个区间，每个区间分别赋予不同的权重，响应时间越长权重越高，比如 0～10ms 区间的权重是 1，
10～50ms 区间的权重是 2，50～100ms 区间的权重是 4，100～200ms 区间的权重是 8，
200～500ms 区间的权重是 16，500ms 以上的权重是 32

3. 实时获取集群的运行负荷
通过压测能够获取到单机的最大容量，再乘以集群内的机器数量就是集群的最大容量了，下一步获取
集群实际运行的负荷，就可以判断集群是否需要扩容了。跟刚才计算单机容量的方式类似，集群的运
行负荷也需要通过采用区间加权的方式来计算，但是因为集群的规模可能很大，超过上千台机器，
显然通过计算每台单机运行的负荷再加在一起的方式效率不高。我在线上实际使用的方法是统计每
台单机在不同耗时区间内的请求数，推送到集中处理的地方进行聚合，将同一个集群内的单机位于
不同耗时区间内的请求进行汇总，就得到整个集群的请求在不同耗时区间内的分布了，再利用区间
加权的方式就可以计算整个集群的运行负荷。

* 调度决策
在容量评估阶段，可以获取集群的最大容量和集群的实际运行负荷，有了这两个数据后该如何做
调度策略呢？

1. 扩容
在决定扩多少机器时，一般有两种方式，一种是按数量，一种是按比例。因为不同的集群内机器数量
差别可能很大，所以一般采取按比例的方式，举个例子比如每一次扩容都增加 30% 的机器数量，再
看扩容后的水位线是否处于致命线以上了。

2. 缩容
在扩容完成后，集群的水位线保持在安全线以上一段时间后，就需要缩容，以节省机器成本。可以根
据实际业务特点来决定多久后可以缩容。而在缩容时也不是一次把所有扩容的机器都缩掉，而是采用
逐步缩容的方式，每隔 5 分钟判断一次集群的水位线是否还在致命线以上，然后按照 10%、30%、
50%、100% 的比例进行缩容，这样可以避免缩容太快导致集群水位线又降到致命线以下又得再扩容
机器。

在实际根据水位线决定是否扩缩容时还需要防止网络抖动等原因造成的水位线瞬间抖动，这个时候
集群的运行负荷会突然变大，导致水位线异常，此时如果加以处理的话就会触发扩容，而实际上并
不需要扩容。为了防止瞬间抖动，可以每分钟采集一次系统的水位线，一共采集多个点，只有多个点
超过一点比例的点满足扩容条件，才真正触发扩容。