转转微服务容量管理实践-转转服务对象

1、背景

随着转转业务的不断发展和用户不断增长，公司持续增加对硬件和基础设施的投入，用于满足业务发展的需要，然而资源的使用率却逐步下降。因为最初的目标是发展业务，实现功能，随着业务的发展成熟，逐步更加关注服务的稳定性，性能、冗余、灾备等方案，这样更会增加资源成本。那么如何在保障服务质量和确保服务性能的前提下，同时降低运营成本提高资源利用率呢？容量管理就是其中必不可少的一环。

2、容量管理的目标

在解释容量管理目标之前，先来看一下容量管理的含义。

百度百科的定义：容量管理致力于在恰当的时间以一种经济节约的方式为数据处理和存储提供所需的容量。

在我看来，容量管理的本质是风险和成本之间的平衡，即在保障业务服务稳定的前提下，以最低的成本保证最优的服务质量。所以容量管理的目标有两点：

成本控制：容量管理保证服务的容量和性能以最节约成本的方式满足既定业务需求，并对资源进行最有效的使用。
业务支撑：容量管理结合当前服务质量（SLA），保证服务提供连续的服务水平;容量管理结合容量规划，指导业务规划所需的费用成本规划和调整。

3、发展阶段

转转的服务容量管理主要经历了3个阶段。

第一阶段：无容量管理，服务全部混合部署到物理机和KVM虚拟机上，单台设备运行几十个服务，物理资源共享，造成服务间的互相影响。
第二阶段：分析服务的可用性和性能数据配合运维的服务管理经验来降低服务混部比例，下线KVM虚拟机，调整服务配置，提升资源利用率，从而减少服务器数量，达到降低服务资源成本的目标。
第三阶段：随着服务稳定性和性能指标数据的不断完善，服务进入云时代，加之压测标准和资源利用率标准的制定，进步一完善了容量管理的基础，成本和服务质量得到了有效的平衡。

第二阶段完成后，IT相关资源成本节约了约50%，第三阶段相较于第二阶段，IT相关资源成本进一步降低约50%。对于公司的降本增效的目标起到了关键性作用。那么下面我们讲讲具体怎么做到这样的成果的。

4 容量管理

4.1 容量水位

容量水位是当前实际消耗的资源（包括裸金属物理机、云资源和其他依赖的SaaS服务）占用当前总体可用资源的比例。例如，B服务有4个云实例，但实际上只使用了2个云实例，另两个实例并未加入分组提供线上服务，所以该服务的资源使用率只有50%，故当前的容量水位是50%。只有获取当前的容量水位，才可以依此进行各种判断和规划。后续进行容量分析时也是基于容量水位的元数据进行多维度数据整合分析并进一步优化。服务容量水位所需要收集的元数据如下表：

云主机：

CPU
内存
磁盘
网卡

应用服务：

JVM内存
应用线程
GC频率
QPS
响应时间

如下图所示，可以看出，对于转转的用户习惯，访问量分布基本是在白天，晚上20:00-23:00用户访问量会逐步增加达到高峰。我们更要关注的是这个时间点上业务服务的容量是否能支撑系统的稳定运行，后续的容量规划也需要按这个峰值的对应的容量水位来估算。

4.2 资源容量优化

了解了容量水位后再对比我们线上服务的资源使用情况发现很多的资源浪费是容量水位偏低造成的。每月服务相关资源的费用也是一个不小的数字，此时容量优化的意义和价值就会凸显出来，这也是我们第二阶段和第三阶段做的事。

1、服务配置缩减 A服务CPU为4核，内存为8G。如下图所示，单日最高CPU使用率为8%（上限400%），内存使用率72%，在保证服务资源冗余30%的情况下，我们会把服务的CPU配置缩减为2核。

B服务容器内存为8G，根据内存公式，服务的JVM内存为6G，此时容器内存缩减到7G比较合理（由于业务场景不同，对于内存的使用需结合业务需要调整，避免引起GC异常或OOM）。

内存公式

JVM总内存 = heap 内存 + 线程stack内存 (XSS) * 线程数 + 启动开销（constant overhead）

2、混合部署/策略

在线业务和离线业务混合部署，晚间业务低峰期开启离线业务计算任务，有效地利用CPU，实现峰谷轮动。
把低等级负载较低的服务或对服务可用性要求不高的服务与高等级或容量水位高的业务服务进行混合部署，充分地利用硬件或云主机资源。

例如：A服务是管理后台服务，资源利用率约为10%；B服务为搜索服务，资源利用率约为40%，我们把两个服务混合部署，充分利用主机资源。

4.3 集群容量

单纯的依靠容量水位去评估服务容量只是利用服务管理经验的服务监控数据控制资源成本。更精确更合理的方案是利用压测结合容量水位确定服务集群的准确容量。获取集群容量的方式通常有两种，一种是通过日志回放，模拟线上流量对单实例压测或者通过TCP-Copy的方式，把线上机器的流量拷贝对单实例进行压测,转转初期就是使用这种方式压测。另一种是对整个集群进行压测，通过获取集群的最大容量，再除以集群内实例数量来获取服务单实例容量。从经验和数据来看，采用集群压测的方式更适合一些，因为这种方式完全使用线上真实业务场景进行压测，获取的数值更准确。所以我们现在的单实例容量都是通过集群压测的方式获得。

4.4 压测指标

压测指标通常关注两类指标，一是系统类指标，二是服务类指标。

类指标。：

CPU使用率
内存使用率
磁盘I/O使用率
网卡带宽

服务指标：

接口响应耗时
耗时分位
错误率
慢速比

4.5 压测标准

通常情况下，资源使用率并不简单地等于CPU利用率、CPU负载，也包括内存、I/O、服务相关配置不合理造成的瓶颈等等。所有这些资源的瓶颈最终都会表现为响应时间和错误率的增加，所以不论服务有多少资源，我们需要找到一个触及系统资源瓶颈的临界点（如下图所示），在这个点之前，应用的性能表现和访问量是呈线性关系的，一旦访问量超过这个临界点，应用的性能就会明显下降。基于此，我们压测的标准如下：

Error%（错误率）：

A级服务压测请求错误比例<= 1%。
B级服务压测请求错误比例<= 3%。
C级、D级、E级服务压测请求错误比例<= 5%。

Response Times（响应时间）：

Median（中位数）：50%响应耗时不超过服务平均耗时（Average）2倍。
90th pct：90%响应耗时不能超过服务平均耗时（Average）5倍。
99th pct：99%响应耗时与90%响应耗时差值>=2倍，注意分析耗时长的接口慢的原因。

这个标准中可以看出，响应耗时方面，我们对于不同的百分位请求耗时有着不同的要求。比如A服务的压测QPS为1000，TP50为100ms，TP90为300ms，TP99为800ms，很明显服务的长耗时比较多，服务的性能下降严重，此时的压测数据并不能代表服务的真实容量。所以我们基于现有的服务耗时数据结合服务性能目标，对服务的响应耗时规定了明确的浮动范围。

压测目标值配置和达标报告示例: