容量规划与授权限流降级.pdf

容量规划与授权限流降级 游骥 微博 庄主游骥 problems 线上机器能承受多大的调用量？系统需要加机器 or 减机器？如何控制调用和资源访问？Part3 授权限流降级 Part1 线上压测 Part2 容量规划 Part1 线上压测 线上压测方式 1.模拟请求 2.复制请求 3.请求引流转发 4.修改负载均衡权重 模拟调用者 调用 压测目标机器 模拟请求 线上正常服务机器 压测目标机器 复制真实请求 线上正常服务机器 复制真实请求 调用 调用 复制请求 Part1 线上压测 Part1 线上压测 调用者 线上机器A 线上压测机器B 线上机器C 转发 转发 调用 调用 调用 请求引流转发 Part1 线上压测 请求 线上机器A 线上机器B 线上压测机器C 负载均衡控制器 more 请求 请求 修改负载均衡权重 Part1 线上压测 压测相关工具 压测方式 优点 缺点 模拟请求 简单应用、对于没什么流量的系统非常好用 模拟请求缺乏真实性，写的请求需特别考虑（脏数据）复制请求 请求真实，能够放大流量 写请求和响应需特别考虑。需一台不提供服务的机器充当压测目标机 请求引流转发 完全真实的场景，压测数据准确 依赖系统自身的流量、服务类应用不太好转发 修改负载均衡权重 完全真实的场景，压测数据准确 依赖系统自身的流量，需要负载均衡控制器开放接口 Part1 线上压测 压测相关工具 1.模拟请求:http_load,webbench,ab,jmeter,Siege等 2.复制请求:tcpcopy,btrace,nginx post_action，自定义agent等 3.请求引流转发：apache mod_jk mod_proxy,nginx proxy等 4.修改负载均衡权重:F5,LVS,SOA service registration等负载均衡控制器 Part1 线上压测 线上机器 压测模型 数据采集 阀值监控 异常情况 压测报表 模拟请求 压测用户 人工 定时自动 复制请求 引流转发 负载均衡 压测控制 cpu load rt 系统数据 性能数据 业务数据 其他 淘宝压测平台架构 Part2 容量规划 容量名词解释 单机能力=单台机器压测阀值qps 单机负荷=前一天单台机器最大qps 集群能力=单机能力*机器数（机器环境一致）集群负荷=前一天集群最大qps 水位标准 单机房（70%），双机房（40%)，三机房（60%）Part2 容量规划 单个系统容量计算 单机水位=单机负荷/单机能力*100%集群水位=集群负荷/集群能力*100%理论机器数=（实际机器数*集群负荷*集群水位）/（集群能力*水位标准）机器增减=理论机器数 实际机器数 Part2 容量规划 链路容量计算 各系统压测阀值qps 容量模型 各个系统需机器数预估 输 入 输 出 页面url qps预估 依赖链路关系数据 依赖链路关系数据通过eagleeye获取（类似谷歌的dapper，twitter的zipkin）Part3 授权限流降级 授权限流降级场景？我提供的某个接口或者资源我只想被A应用访问 我提供的某个接口或者资源我不想被B应用访问 防止我的某个接口或者某种资源被过度访问 防止我对某个接口或者某种资源的过度访问 系统负载太高可以降级掉不重要的应用对我的调用 依赖的非关键调用长时间没有响应可以对其进行降级 Part3 授权限流降级 调用方A 白名单 调用方B 调用方C A、B通过 C拦截 黑名单 授权 Part3 授权限流降级 限流 调用方A 调用方B 调用方C D依赖的接口 D依赖的资源 服务端限流 客户端限流 系统D Part3 授权限流降级 降级 A调用 降级 非重要B调用 C调用 非关键依赖E（响应很慢）依赖F 负载很高 降级 B 系统D Part3 授权限流降级 授权限流降级部署结构图 负载很高 授权限流降级客户端 系统D 系统A 控制台 配置管理中心 用户 结果 操作 配置 配置 THANK YOU