1.背景随着转转业务的不断发展和用户的不断增长，公司不断加大对硬件和基础设施的投入，以满足业务发展的需要。但是，资源利用率却逐渐下降。因为最初的目标是发展业务，实现功能，随着业务的成熟，逐渐更加注重服务的稳定性、性能、冗余、容灾等解决方案，会增加资源成本。那么如何在保证服务质量和服务性能的同时，降低运营成本，提高资源利用率呢？容量管理是其中不可或缺的一部分。2.容量管理的目标在解释容量管理的目标之前，我们先来看看容量管理的含义。百度百科的定义：容量管理致力于在合适的时间以经济的方式提供数据处理和存储所需的容量。在我看来，容量管理的本质是风险和成本的平衡，即在保证业务服务稳定的前提下，以最低的成本保证最好的服务质量。因此，容量管理有两个目标：成本控制：容量管理确保服务的容量和性能以最具成本效益的方式满足既定的业务需求，并最有效地利用资源。业务支持：容量管理结合当前服务质量（SLA），确保持续的服务水平；容量管理结合容量规划来指导成本规划和业务规划所需的调整。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.业务配置缩减一个业务CPU为4核，内存为8G。如下图所示，单日CPU使用率最高为8%（上限为400%），内存使用率为72%。我们会在保证服务资源冗余度为30%的情况下，将服务的CPU配置降低到2核。B服务容器内存为8G。根据内存公式，该服务的JVM内存为6G。此时将容器内存降低到7G是合理的（由于业务场景不同，需要根据业务需要调整内存的使用，避免GC异常或OOM）。内存公式JVM总内存=堆内存+线程栈内存（XSS）*线程数+启动开销（开销不变）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%。ResponseTimes（响应时间）：中值（median）：50%的响应时间不超过平均服务时间（Average）的2倍。90thpct：90%响应时间不能超过平均服务时间（Average）的5倍。第99%：99%响应时间和90%响应时间相差>=2倍，注意分析界面耗时慢的原因。从这个标准可以看出，在响应时间方面，我们对不同的百分位请求时间有不同的要求。例如服务A的压测QPS为1000，TP50为100ms，TP90为300ms，TP99为800ms。很明显服务耗时很长，服务性能严重下降。此时的压测数据不能代表服务的真实情况。容量。因此，我们根据已有的服务耗时数据，结合服务性能目标，为服务响应时间设定了一个明确的浮动范围。压力测试目标值配置及合规报告示例：压力测试获得的服务能力数据将统一记录在服务信息管理平台上。5、扩容缩容如下图：基于服务容量数据，在公司的促销活动中，我们实现了定时扩缩容的功能；为了保证日常的服务质量，我们会使用服务容量数据来实现服务容量弹性伸缩的功能。随着日常服务压测流程和规范的不断完善，服务的容量数据也日趋完善。这些数据不仅对服务的扩缩容起到指导作用，也为服务的稳定性提供了保障。6.小结容量管理是一个复杂的系统工程，方法和方法多种多样。不仅要明确、明确和实施战略、方法、方法，还要不断细化和完善规范和流程，以达到降本增效的目的。同时，容量管理的重要性不言而喻。它是服务稳定性保障和资源成本控制的基石。随着智能运维技术的逐步成熟，我们必须朝着更低成本、更好质量的目标迈进。作者简介张磊，转转应用运维负责人。主要负责业务系统的可用性、性能、容量、运维自动化平台等SRE系统建设。
