SpringCloud服务治理（十三）服务容量规划

容量规划

容量定义：资源所能支撑特定服务的能力
容量规划：资源管理
适用范围：同构集群

性能 &&　容量

性能：决定一辆车能装什么东西
容量：决定需要多少量车

容量规划大致需要经过以下几个步骤
１.评测模型
２.应用依赖
３.趋势预测
４.容量管理

一 评测模型

１.设定服务指标(偏向性能方面)

在用户期望、业务需求、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应用访问
• 防止我的某个接口或者某种资源被过度访问
• 防止我对某个接口或者某种资源的过度访问
• 系统负载太高可以降级掉不重要的应用对我的调用
• 依赖的非关键调用长时间没有响应可以对其进行降级