前言

在谈容量规划之前，首先要知道我们的系统处理能力有限的，不可能是无限的，处理能力的限制取决于资源的限制，生活中很多这种例子，例如喝水的水杯，也是有容量限制的，超出容量限制，则溢出，再例如高速公路双向四车道、六车道、八车道等等，那么可以并行的车辆限制这取决于车道数，这里的车道数指的则是资源，那么在建设高速公路时，肯定会做相应的规划是四车道还是六车道合适，结合当下和对未来的预测从而规划和设计，对于我们的系统也是如此，要清楚的了解系统处理能力，资源使用率、容量规划等情况。

为什么要容量规划

随着业务越来越复杂，系统和服务逐渐增多，不同的系统特性和选用的机器资源也均不相同，容量规划是要能够清楚的知道各个业务系统的特性及机器资源使用情况，业务系统有什么特殊属性及需要什么样机器配置，如何选择和匹配达到最优的效果，这样便于知道什么时候该加机器，加什么样的资源机器，加多少及什么是该减少等等情况，从成本的角度既要保证系统的可用性、稳定性又要能够节约成本，避免资源浪费。如对于上述不清楚的话，就无法做系统的稳定性，对当前的系统不清楚、那么对后续规划肯定也是做不好的。

容量规划的方法

在容量规划之前首先要知道系统容量是可度量的，资源是有限的，所谓的容量是指系统最大负载的状态下的最大处理能力，或在满足业务目标的前提下，系统最大处理承受能力。

规划模型

容量规划模型大致可分为三步，分别是设定目标、指标汇总、容量摸底形成闭环，首先要能够清楚我对系统的期望，或者SLA是怎样的，其次是能够通过指标了解当前系统的运行状态，资源使用率等，最后是容量摸底手段是通过模拟用户并发对系统验证，观测系统是否满足期望。

设定目标

设定目标有两种形式，第一是从活动策划角度，例如：企业举办重大线上活动时，市场或运营的伙伴评估该活动的参与人数，将该人数给到技术伙伴，那么技术伙伴根据活动场景、特性及参与人数来准备资源，使系统能够满足该活动的要求。第二是从成本的角度，例如，在项目初期，流量不大的情况下，或者逐渐上升系统，要能够清楚当前的机器能够支撑多少流量，在什么样的情况下该增加资源，什么样的情况下该减少资源；上述情况都是需要能够清楚我们的资源和系统特性的配比，如：4核8G的服务器，结合系统的特性、在高峰期能够支撑多少流量，包括其他资源、数据库、缓存中间等等，高峰期是每天的某个时刻呢，还是每年的某个月份等等，对于用户层面的目标可以是SLA、对于服务内部的目标可以是SLO等等。

指标汇总

指标汇总有两部分，第一部分是硬件层面，如机器配置、CPU、内存等等，第二部分是软件层面、如错误率、线程数、并发数，最大连接数等。指标汇总可以分别埋点采集、日志、Agent形式，业界比较流行开源软件有Prometheus、Zabbix，通过上述的方式可以观测到硬件、软件层面的使用情况，如：CPU高峰期的使用率是否到达100%、内存的使用率、响应时间、超时/异常错误率等等，通过该方式可以清楚了解到系统整体运行状况及资源使用情况等等。

容量摸底

容量摸底是通过模拟并放大流量来观测系统的运行状态，容量摸底的形式有引流、模拟流量两种形式，第一是引流（流量复制），该方式可以直接将流量镜像到其他的机器，也可以录制流量、将其保存，在压测的时间段内将流量回访并放大倍数，Nginx提供了ngx_http_mirror_module模块，第二种方式采用模拟流量（模拟请求）压测、可以通过单机压测评估的表现状况，依次推算集群模式的表现状况，仅仅这样是不够的，在错综服务网格中，服务存在各种依赖，服务依赖也决定服务的表现情况，因此还要通过全链路压测来观测整体的表现状态，寻找系统瓶颈并优化，持续全链路压测，直到满足期望。

值得注意的是，上述情况可能存在脏数据的情况，为了防止脏数据的产生，多数情况我们只能对读操作压测，为了确保模拟更贴近线上，往往也需要对写的操作压测，这里提供一种解决方案，通过影子库的方式，在对写压测时，通过特殊标识，在请求头中进行上下文传递的方式，到写库操作时，判断是特殊标识，从区分将该数据写到主库还是影子库。影子库建议同一实例，通过数据库名称区分，好处是环境真实，缺点是影子库和主库存在同一实例。

扩展性

扩展性是依据架构师以往的经验，在架构设计时必须要考虑的扩展性，可参考扩展性的DID方法，分别是Design设计、Implement实现、Deploy实现，在设计时按照现有容量的20倍设计，按照现有容量的3倍实现，按照现有容量的1.5倍部署，是因为DID为系统的扩展性提供了经济、有效、及时的方法。扩展性是架构设计必须要考虑，并且要在设计阶段就需要考虑的，可以帮助团队节省资源和成本，一旦到实施阶段发现扩展性不够，那么再改变设计方案，带来的成本是相当大的，存在很大的风险。举个例如：假设某登录服务，该服务存储所有登录状态，从可用性的角度，要求登录服务是无状态，只有是无状态的服务，才能做到水平扩容，集群化，从而提升可用性，在设计登录服务时就需要思考上述问题和设计方案，包括服务的实现及部署方案，一旦到后期需要时，发现无法做到水平扩容，需要重构，那么带来的成本可想而知，因此对架构设计要求可扩展性强并具有弹性，它既可以扩张也可以收缩，要有一定的灵活性，随着业务规模的收缩和扩张，调整系统的容量。

容量管理

容量管理是对当前系统的容量管理，可以实时了解运行的容量，主动感知容量的瓶颈，及为扩容和收缩提供依据，主要是基于采集指标数据进行分析，对各个组件动态检测、实时感知组件容量瓶颈，并对各个组件设计预警阈值，还可以对历史数据对比分析，做未来趋势预测等等。例如：服务器的CPU使用率不能超过80%、数据库的CPU、内存、磁盘、数据增速、连接数阈值监控。容量管理可以实时预测容量瓶颈，预测瓶颈及时预警，主动感知变化，减少故障可能性。

趋势预测

趋势预测是依据容量管理中的历史数据对未来流量的趋势预测，从而预测容量，趋势预测整个过程中首先要明确指标Metrics，指标必须是可度量的，如：内存、磁盘、CPU使用率等，其次对现有资源的摸底，如：磁盘、内存总共大小，并且对该资源访问约束并阈值预警，超过阈值及时预警，防止资源溢出从而导致整个系统雪崩，试想下：如一共有五台机器，整体的资源利用率不超过80%，假设每台机器承受的QPS是200，那么整体QPS是1000，在QPS不变的情况下，假设突然一台机器宕机，那么剩余四台必然承受不了流量，相继继续宕机，出现雪崩现象，最后根据监控趋势图计算高峰期的时间点，及高峰期的资源利用率，对高峰期的防护，从而提升系统稳定性。