1.什么是容量规划
2.为什么要做容量规划
3.容量规划的对象
4.容量的规划方法

什么是容量规划

容量是指一个系统可处理容纳的最大能力

为什么做容量规划

做运维工作的读者都应该了解 SLA（Service-Level Agreement），即服务等级协议，这是关于网络服务供应商和客户间的一份协议，其中定义了服务类型、服务质量和客户付款等术语。

SLA 等级分为 1 个 9->90%,全年宕机时长 36 天 12 小时，3 个 9→99%,全年宕机时常 8 小时 45 分。一般情况下，公司服务器的总体资源利用率长期处在较低水平，CPU 利用率都在 20% 左右，总的来看，我们有大量的计算资源和存储资源闲置，造成巨大浪费，这也直接导致我们的服务成本偏高。

容量规划的对象

无论您公司是什么业务，只要业务是用计算机来承载，必然可以用计算机的物理资源消耗量作为业务量的度量，这体现在处理器、硬盘、内存、网卡、网络链接数等方面。业务量与计算机资源消耗量整体上是呈正比的。

(1) 计算密集型（2）IO 密集型包括网卡流量 (3) 数据密集型，吃内存

总结，容量管理系统给我们带来的收益如下。

（1）科学地评估系统所用的资源是否合理。

（2）科学地预测未来资源的增长，并进行合理的预算采购。

（3）运维人员以科学的方法对资源进行有效管理，这包括优化集群中结点机器数量，预知服务可承载的最大压力，预知系统何时性能燃尽等。

容量的规划方法

1、模拟请求

模拟请求，即是模拟客户端的调用方式向压测服务器发起请求，简单易操作。

　 测试数据：可以通过分析线上日志分析，根线上业务配比建立压测模型，对于 HTTP 请求业务还有一种简单的方式，通过提取线上日志数据 URL 直接用于压测请求数据。

　 实施步骤

　　(1) 将线上一台节点 offline，测试客户端直连被测服务器

　　(2) 客户端梯度增加并发 (50),不断增加并发直至超过设定的服务指标

　　优缺点

　　测试效果不受服务实际流量的限制，压测时间灵活，适用于 GET 请求不会产生脏数据。业务指标可以通过测试客户端直接获取。

　　风险评估

　　风险低，首先机器 offline 不会影响到线上的正常请求；其次缓慢增加并发，不会造成服务崩溃的情况。

2、线上引流

线上引流，即将线上其它节点的请求复制到被测服务器上，推荐使用 Tcpcopy 工具。

　 测试数据：线上请求直接复制引流，无需准备数据

　 实施步骤

　　(1) 将线上一台节点 Off-line，按照 Tcpcopy 部署的方法部署 client 和 server，为了便于指标的统计，通常将 Tcpcopy 部署在 nginx 所在服务器，被压测服务器前需要增加一层 nginx 服务器。

　　(2) 将集群的其它节点流量复制到 off-line 节点上，可以通过 tcpcopy –r 参数逐步增加复制系数，不断增加-r 参数直至超过设定的服务指标

　　(3) 如果 100% 全部线上流量都不能压测到 off-line 节点的瓶颈，再逐步放大引流系数

　　优缺点

　　请求真实，能够放大流量，测试效果不受服务实际流量的限制，压测时间灵活，但环境部署稍微麻烦，对于 PUT 请求需要做一些业务处理，避免产生脏数据。

　　风险评估

　　风险低，首先机器 offline 不会影响到线上的正常请求，缓慢增加流量复制，不会造成服务崩溃的情况。

3、修改负载权重

对于一个集群，前面往往会有负载均衡服务器，以 Nginx 为例，通过修改 Upstream 模块的负载均衡 weight 可以不断增加集群某一节点的请求数，增加其访问压力。

　测试数据：无需准备

　　 实施步骤

　　(1) 缓慢增加 nginx 的负载均衡系数，使被测节点压力不断增加

　　(2) 直至超过设定的服务指标停止增加压力 　

　　优缺点

　　完全真实的场景，压测数据准确，但是依赖自身的流量，压测时间不灵活，需在高峰期，对用户体验有一定影响，随着一台机器的负载增加响应时间会受到一定影响，会直接反馈给在线用户。

　　风险评估

　　风险低，虽然在高峰期进行，但是只需要修改 nginx 配置再 reload，对服务基本无影响，且每次都逐步增加 weight，不会造成服务器崩溃的情况。

　　 由于请求量恒定，通过缩减服务器数量的方式并不能评估出底层基础组件的容量，如 DB,MQ 等基础组件，从而会导致容量评估不准确;

对于访问流量有一定要求，流量太小的话达不到瓶颈;

（备注：在以前工作中容量规划主要用到了线上引流和修改负载权重两种方式。如果写数据没有很好的措施规避之前，不妨用一下修改负载权重的方式进行容量规划。文章内容转自 CSDN 博客）