容量规划与保护.

Presentation on theme: "容量规划与保护."— Presentation transcript:

1 容量规划与保护

2 大纲 容量规划 需要哪些数据 单机容量 依赖容量 容量保护 Web server 层面 代码层面
大致的内容是分为两块 一块是 如何构建应用容量，还有一块是容量溢出的一些防御措施

3 容量历程 淘宝某应用某机房机器变化走势图 1.淘宝机器的变化历程

4 容量历程 机器预算 应用能不能支撑？ 经验 不知道 经验<cpu load 流量> 结果
如果遇到突发事件（全国哀悼日）流量突然上涨。应用支撑不住了就需要紧急加机器，加多少也不清楚，反正能加多少是多少，所有人都高度紧张。 能支撑多少，什么情况下系统会挂，全是经验

5 容量历程 问题一：不知道应用到底能支撑多少量 问题二：只能根据现在的访问量、load等评估系统情况
问题三：应用的机器基本上不会被下掉，导致非常大的浪费。 问题四：没有统一的，可量化的容量模型

6 容量历程 遇到这些场景下，我们心就有一个疑问，我们缺了什么？我们需要一个什么系统来解决这个问题？

7 容量规范 容量水位 水位=(流量QPS/性能QPS)*100% 流量QPS 性能QPS 单机流量QPS 集群流量QPS 单机性能QPS
首先我们需要一个单位来表示应用的容量 所有的应用系统都有可承载的上限 ，这个上限一般情况下是和机器的核数相关，如：4核的话，性能的上限就是在load为4上下，当然这个不是绝对的，PE 可以根据自己的实际情况来具体定义，我们把这个上限称为性能tps。 应用实时在接受外部流量的请求，我们把这个请求称为 流量tps 水位就是当前的(流量tps/性能tps)*100%

8 容量规范 通过容量水位来确定机器的增减 安全水位(标准水位) 危险水位 加机器水位 减机器水位
首先我们要解决一个问题是，怎么样应用的机器怎么样才算够了多少台才算安全了？ 那是不是需要一个规范， 一个可做为依据来指导 线上机器的分配部署让我们主动知道什么时候下机器什么时候上机器。

9 容量规范 水位线 红色必须1周之内加机器。 黄色如果是短期波动不用管；如果是自然稳定的增长，也需要加机器，但不紧急。
绿色是最正常的状态。把生产集群水位长期稳定在绿色是PE的职责。 蓝色必须退机器。 虽然水位上升到100%依然是安全服务的，但流量在上涨就overflow了。所以必须留有buffer。 红色的部分要求紧急加机器。 水位大部分时间应该在绿色，小部分时间在黄色。

10 容量实施 需要获取到应用的真实性能数据 需要获取应用的流量数据 容量计算公式 依赖容量计算公式

11 容量规范 实施 性能数据 流量数据 容量计算 依赖容量计算

12 性能数据 某应用线上压测结果 某应用线下压测结果 257 537 Load cpu 30%左右

13 优点 缺点 性能获取方式 正式环境来实施性能压测 线上压测原则 真实流量 真实环境 真实性能数据 危险 不是为了压测应用极限负载
在前面提到一个性能qps ，可能很多人都想到性能环境压测出来的数据， 我们采用的是在线上正式环境来实施性能压测 为什么 线上压测优点是什么 线上压测的缺点是什么 但是有一点必要要明确的是，线上压测不是以压测应用性能为目的的压测！ 线上压测原则 不是为了压测应用极限负载 而是获取应用稳定的最高负载

14 线上压测 应用访问类型 分流模式 通过将多台的机器流量汇聚到一台机器上
非登录读应用 登录读应用 写应用 分流模式 通过将多台的机器流量汇聚到一台机器上 负载均衡 App configserver 日志回放模式 通过读取web server 日志，并将日志中的get 请求重新请求道某个机器上 带cookie的 不带cookie 线上的原理 其实采用一种很简单的方式进行，可能有人也使用过。流量分流 负载均衡 lvs Web server apache nginx App configserver

15 淘宝架构

16 线上压测架构

17 例子一--分流模式

18 例子二--分流模式

19 例子三--日志回放模式

20 容量规划 压测操作可控性 随时可以手动或自动进行 随时可以停止 过程可视 完善的保护机制 数据监控采集 完善的监控阀值设置 异常的保护机制

21 容量规范 实施 流量数据 性能数据 容量计算 依赖容量计算

22 容量规划 流量QPS 注意: 通过统计web server日志，获取应用的单机流量QPS和集群QPS。 为什么不直接用最大值？
这个主要是考虑到流量的波动性，平均值使容量水位更加稳定 流量qps 这块就是通过日志离线分析了，目前上这块就比较流行的是hadoop storm 我们使用的是高峰期的平均qps，这个主要是考虑到访问的波动性，如果只是单纯的使用最高值，这个数据往往比较偏高

23 容量规范 实施 容量计算 性能数据 流量数据 依赖容量计算

24 容量计算 实现原理：通过当前的应用机器数与性能QPS的乘积获取到应用整个集群的可以承受的最大流量。在与当前集群流量QPS的比较就能计算出需要的机器数量 计算公式： 系统水位 =流量qps/性能qps 理论机器数 = 集群流量qps/性能qps 安全机器数=理论机器数 /安全水位

25 双机房部署->>安全水位为40%
容量计算 例子: 性能QPS 机器数量 20台 集群稳定负载能力 = 100*20=2000 双机房部署->>安全水位为40% 活动场景一 日常场景二 预计双十一流量 = 20000 水位= 1000% 理论机器数= 200台 安全机器数量=200/安全水位=200/40%=500台 实际流量= 2000 水位= 100% 理论机器数= 20台 安全机器数量=20/安全水位=20/40%=50台 为了双十一安全 机器数需要加到500台才行 应用已经在危险的边缘需要马上加30台

26 容量规划

27 容量规范 实施 依赖容量计算 性能数据 流量数据 容量计算

28 依赖容量 大家都知道 淘宝是比较喜欢做活动的，那么也都是有业务目标，淘宝的业务目标都是和钱相关，比如：100亿 之类的。
再根据以前的平均下单金额，就可以估算出大致的下单量，最后就可以知道下单接口的调用量

29 依赖容量 但是实际上 我们的系统是相互关联的，当然 这个是我简单的画了一个，实际上它是一个网状的结构。业务目标最终后转换到一个比较抽象、单一。 如何将这个目标最终转换到各个核心的应用中去？ 这就需要知道应用之间的调用关系

30 依赖容量

31 依赖容量 关系 直接依赖、间接依赖 依赖之间的调用量 依赖之间的强弱 如果要将关系进行划分的话，分为： 我依赖谁、谁依赖我 依赖之间的调用量
如何获取这些数据，这里是有两套系统来支撑，

32 依赖容量 调用轨迹 Eagleeye 记录应用程序完成一次调用需要走过的所有依赖应用的信息

33 依赖容量 数据统计

34 依赖容量 从这里是不是 就可以发现 系统之间的调用比例值，有了系统的调用比例，那就可以很容易的做系统容量的推算，
不管是从上往下推算，还是从下往上推算。 看到这里大家可能会有一个疑问，看上去 这个只是决绝了应用自身的演算，如果是另外一个前端系统，那么怎么来搞他们之间的数据关系呢？

35 依赖容量 refer * 转化率 这个是一个很普通的web server 的日志，大家应该都注意到 日志中的refer。那是不是 就可以通过refer 将所有的应用 就可以联系起来 。当然refer 实际效果 会和转化率相关，这个转化率 就需要根据实际做一些调整

36

37 createOrderForTaobao
detail 107 台实体机 tf_buy 303 cart 699 tf_tm 218 hesper 110 hesper 167 shopsystem 435 tradeplatform 740 itemcenter 692 shopcenter 91 designcenter 135 最终执行路径下的容量情况

38

39 限流降级 限流： 降级： 超过自身容量范围之外的流量暂时拒绝访问 在自身容量不足的情况下
将某些非关键路径上的请求调用暂时关闭，并将这些容量留给更加重要的系统 将自身执行路径上某些不影响业务的调用暂时关闭增加自身容量 前面说的都是容量规划 它为我们做的是未雨绸缪事情，但是流量往往是突变的，如何保障在容量规划之外的稳定。或者流量远远超过容量范围之内，那就需要靠限流降级

40 限流降级 作用范围 Web Server Servlet 容器
介绍限流 首先要简单说明下 淘宝所有应用的结构 是 在最前面是 lvs 负载均衡,由它将流量分配到各个机器的web server 上，然后又web server反向代理 到 直接机器上的servlet 容器上。 在限流上 也就分为了两层，一层在web server 上 对应的系统是TMD，一层是在Servlet 容器里面也就是 应用的自身防御 那就是Switch Stable。 这两套功能上来看 非常的相似，但是在做用上是相互补充的，为什么这么说呢？

41 限流降级 职责分工 TMD Stable Switch 优点： 优点： 缺点： 缺点： 互补 针对集群流量防御，面向集群的流量暴涨。
可以根据集群统计分析数据，并作出对应的决策。 缺点： 需要有一个数据分析过程，无法做到瞬间响应。只能作用于Http 请求 Stable Switch 针对机器单体的流量防御 优点： 在流量瞬间暴涨情况下，立即作出限流反应。同时也可以服务于服务应用 缺点： 只是作用于自身，盲目的排除一切多余流量 Tmd 防止攻击 Stable switch 互补

42 淘宝瞬间流量

43 TMD的原理 TMD 需要有一个感知的过程，TMD server 就想是一个雷达，它需要一点时间来监测到是否有危险到来。但是问题往往就出现在那个时间点的1s钟。 它无法在瞬间就能做出响应。

44 Stable Switch的原理 那就需要一个应用自身 能够自动反应的利器，进行近身肉搏。

45 稳定 关系 控制 容量

46 Thank You