为了迎接中秋节及国庆节的到来，需要对线上服务器进行扩容，发现了一些问题，就顺手整理下如何做容量规划
容量规划
容量定义：资源所能支撑特定服务的能力
容量规划：资源管理
适用范围：同构集群
性能 && 容量
性能：决定一辆车能装什么东西
容量：决定需要多少量车
容量规划大致需要经过以下几个步骤
１.评测模型
２.应用依赖
３.趋势预测
４.容量管理
一 评测模型
１.设定服务指标(偏向性能方面)
在用户期望、业务需求、SLA三者之间平衡
具体的指标：计算速度、网页打开速度、响应时间、命中率、、SLA
２.设定容量指标(偏向物理层面)
扩容调整的方式：水平调整、垂直调整
垂直扩展的收益比较低，现在基本已经不考虑采用这种方式，主要还是水平调整。
水平调整基于AKF扩展立方又分为：
- 1.横向复制：通过克隆进行扩展
- 2.拆分不同的东西：用名词或是动词标示数据和服务，从而进行划分
- 3.拆分相近的东西：通常拆分的是数据集，把数据划分到专用独立的数据片或是泳道
业务指标：UV,交易量，调用量，搜索量
水平容量指标：TPS,QPS,SESSION
垂直容量指标：CPU,内存，IO，网络，连接数
３.压测和监控
引流(复制请求)：
1.测试效果受到集群实际流量限制
2.压测时间需要选择流量较大时候
3.不产生脏数据，适用范围灵活
模拟流量(模拟请求)
1.测试效果不受集群实际流量控制
2.压测时间灵活
3.可能产生脏数据，对get请求较为合适
４.容量计算
集群容量= 容量指标峰值/容量指标最大安全值
实际案例：
服务指标 ： 交易关键URL响应时间 <=300ms
水平容量指标：TPS
系统健康约定如下
CPU : <=80%
IOPS : <=200
网络带宽 : 800Mbps
内存使用 : <=4G
例如线上集群单台服务指标RT值超过300ms，TPS=100
一个集群4台机器的话，那么集群的TPS就是 4*100 = 400
集群的最大TPS峰值是160。
集群容量 = (160/400)*100% = 40%
二 应用依赖
随着网站架构的变化，现在很难有单一部署的应用，大部分网站架构都是基于SOA的水平扩展。
那么在其中一个应用流量大涨的情况下，需要评估周边相关应用是否可以承载你扩容后的请求。
依赖分为两类
静态依赖：
- 代码层 — 应用程序要
- 配置层 — 运营配置项目
动态依赖：
- 应用层 — 应用日志分析
- 架构层 — 服务治理框架
- 系统层 — 网络分析
三 趋势预测
根据以往的数据，在不同服务器阶段，能够承载的服务指标，大致预估未来增长的预期。
主要根据D-I-D原则
设计(Design) — 按照现有容量的20倍进行设计。
实现(Implement) — 按照现有容量的3倍进行实现。
部署(Deploy) — 按照现有容量的1.5倍进行部署
四 容量管理
主要体现在系统的监控上，系统架构比较重要的部分就是系统的监控。
上限水位 标准 下限水位
单机房 ： 80% 70% 50%
双机房 : 55% 40% 30%
三机房 ： 75% 60% 50%
这里还涉及到一个数据的分配，假设三机房。A机房将自己50%的数据备份到B机房，另外50%数据备份到C机房。保证在一个机房失败的情况下，可路由到其他机房！
一个好的容量管理平台
表现层：UI,API
应用层：报表管理、容量管理、趋势预测、压测管理
服务层：计算分析中心
组件层：数据采集中心、配置中心
数据层：集群依赖分析系统、监控系统
需要考虑的流量问题
- 我提供的某个接口或者资源我只想被A应用访问
- 我提供的某个接口或者资源我不想被B应用访问
- 防止我的某个接口或者某种资源被过度访问
- 防止我对某个接口或者某种资源的过度访问
- 系统负载太高可以降级掉不重要的应用对我的调用
- 依赖的非关键调用长时间没有响应可以对其进行降级
以上的所有问题都归结于：授权、限流、降低
服务的授权 ：黑白名单
服务的限流 ：SOA服务框架或是服务提供方
服务降级 ：服务的调用端，或是在服务提供的客户端，返回一个空对象模式
以上三者可以都放在一个统一的客户端进行处理！
—————————————————————————————————————————————
案例：
一 新项目上线服务器的申请：
服务指标：
max time = 200ms
qps = 20000
计算：
单机能力 = 300qps
单机房部署的标准水位是 = 70%
300 * 70% * 服务器数量 = 20000
服务器数量 = 95.23809523809524
按照DID原则 ： 服务器数量 = 142.85714285714286 即需要部署143台服务器！
二 若是已经上线项目的服务器调整,目前线上实际的QPS是200,单机房部署
单机能力 = 300qps
单机负荷 = 200qps ，线上目前的最大请求压力
集群能力 = 143 * 300 = 42900
集群负荷 = 200 * 143 = 28600
28600 * (28600 / 42900) * 143 = ( 42900 * 70% * 理论服务器数量)
理论服务器数量 = 90 台。
那么可以减去 143 -90 = 53台服务器。
计算的公式是： 集群负荷 * (集群实际水位) * 实际服务器数目 = ( 集群能力 * 标准水位 * 理论服务器数量)
—————————————————————————————————————————————
tips：
容量规划的一些名词：
qps的计算 : ( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
例如： 每天300w PV 的在单台机器上，这台机器需要多少QPS = ( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
单机能力 = 单台服务器压测的阀值 qps(通过线下压测)
单机负荷 = 上线后单台机器最大qps(或是通过线下压测)
集群能力 = 单机能力 * 机器数(机器环境一致)
集群负荷 = 上线后集群最大QPS(单机负荷 * 服务器数量)
水位标准
单机房 : 70%
双机房 : 40%
三机房 : 60%
单个机房容量计算
单机水位 = (单机负荷/单机能力) * 100%
集群水位 = (集群负荷/集群能力) * 100%
理论机器数 = (实际机器数 * 集群负荷 * 集群水位) /(集群能力 * 水位标准)
机器增减 = 理论机器数 – 实际机器数 or 实际机器数 – 理论机器数
以上谈的都是简单的基于QPS的服务指标，实际线上规划时候还需要考虑：响应时间等其他因素！
参考资料：
1.http://wenku.it168.com/d_001180778.shtml
2.http://wenku.it168.com/d_000626871.shtml
3.http://product.china-pub.com/199567
绝了