大多数互联网公司都会根据业务对自身系统做一些拆分，大变小，1变n，系统的复杂度也n倍上升。当面对几十甚至几百个应用的时候，再熟悉系统的架构师也显得无能为力。稳定性平台从2011年就开始了依赖治理方面的探索，目前实现了应用级别和接口级别的依赖自动化治理。在2013的双11稳定性准备中，为共享交易链路的依赖验证和天猫破坏性测试都提供了支持，大幅度减小了依赖治理的成本和时间。另一方面，线上容量规划的一面是稳定性，另一面是成本。在稳定性和成本上找到一个最佳的交汇点是线上容量规划的目的所在。通过容量规划来进行各个系统的机器资源分配，在保证系统正常运行的前提下，避免对机器资源的过度浪费。
依赖治理的一些基础概念
依赖模型分为关系、流量、强弱，实际的使用场景有：
关系数据可以通过人工梳理、代码扫描、线上端口扫描的方式获取。流量数据可以通过分析调用日志的方式获取。强弱数据则必须通过故障模拟才能拿到。故障模拟分为调用屏蔽和调用延迟两种情况，分别代表服务不可用和服务响应慢的情况。依赖的级别分为应用级依赖和接口方法级依赖，两个级别的故障模拟手段完全不同，下面分开来描述。
应用级别强弱依赖检测
应用级别故障模拟比较做法有几种，即：修改代码，写开关，远程调试，填错服务的配置项。这几种方式对配置人要求相对较高，并且对应用代码有一定的侵入性，所以没有被我们采用。Linux有一些原生的命令（如iptables、tc）默认就有流量流控功能，我们就是通过控制linux命令来达到模拟故障的效果。命令举例：
iptables -A INPUT -s xxx.xxx.xxx.111 -j DROP
上面的命令表示：当前主机屏蔽掉来自xxx.xxx.xxx.11的网络包。
tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: prio tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 6000ms tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip dst xxx.xxx.xxx.111/32 flowid 1:1
命令表示：在网卡eth0上面设置规则，对xxx.xxx.xxx.111的网络包进行延迟，延迟的时间是6000ms。
接口级别强弱依赖检测
理想情况下，我们希望确定任意一次远程方法调用的强弱，确定到接口方法级别的强弱数据。要想达到这个目的，就只能在通信框架和一些基础设施上面做文章。基于这个思路，我们设计了接口级别强弱依赖检测的方案。方案如下：
过滤规则配置组件(服务器端)
过滤规则配置组件提供一个web界面给用户，接受用户配置的屏蔽指令和测试机器IP信息，并把配置信息更新到配置中心组件中去。
配置的规则举例：
client|throw|xxx.ItemReadService:1.0.0.daily@queryItemById~lQA|java.lang.Exception client|wait|xxx.ItemReadService:1.0.0.daily@queryItemById~lQA|4000
上面的规则分别表示在客户端发起对远程接口xxx.ItemReadService:1.0.0.daily的queryItemById~lQA调用时，在客户端模拟一次异常或延迟4000毫秒后调用。
配置中心组件
配置中心组件的主要作用是接受客户端（过滤规则配置组件）发来的配置信息，持久化配置信息到存储介质中，并实时把配置信息实时推送到配置中心的所有客户端（即每一个故障模拟组件）。此部分功能通过中间件开源产品Diamond实现。
分布式服务调用组件
发生RPC调用时，会传递一些调用信息，如：RPC发起者的IP、当前的方法名称、下一级调用的方法名称。
故障模拟组件
故障模拟组件是一个插件，可以被服务调用组件（HSF）加载。插件可以接受配置中心推送的配置信息，在服务调用组件发生调用前都比对一下据配置信息的内容，当RPC发起者的IP、调用方法都合条件的时候，发生故障模拟行为，从而达到故障模拟的效果。
线上容量规划最重要的一个步骤为线上压力测试，通过线上压力测试来得知系统的服务能力，同时暴露一些在高压力场景下才能出现的隐藏系统问题。我们搭建了自己的线上自动压测平台来完成这一工作，线上自动压测归纳起来主要包含4种模式：模拟请求、复制请求、请求引流转发以及修改负载均衡权重。
模拟请求
完全的假请求，可以通过代码或者采用工具进行模拟，常用到的工具有http_load、webbench、apache ab、jmeter、siege等。模拟请求有一个很明显的问题，即如何处理“写请求”？一方面由于“写请求”的场景不大好模拟（一般需要登录），另一方面“写请求”将要面临如何处理一致性场景和脏数据等。模拟请求方式的压测结果准确性我们认为是最低的。
复制请求
可以看成是半真实的假请求。说它半真实，因为它是由复制真实请求而产生。说它是假请求，因为即使复制的真实请求，它的响应是需要被特殊处理的，不能再返回给调用方（自从它被复制的那一刻，它就已经走上了不真实的轨道）。复制请求同样可以通过代码实现（比如我们有通过btrace去复制对服务的调用）， 此外也有一些比较好用的工具：比如tcpcopy等。如果想在nginx上做请求复制，可以通过nginx的nginx post_action来实现。“复制请求”模式被压测的那台机器是不能提供服务的，这将是一个额外的成本，此外复制请求模式的压测结果准确性也会由于它的半真实而打上折扣。
请求引流转发
完全真实的压测模型，常用于集群式部署的web环境当中。我们对于apache和nginx的系统基本上都采取这种方式来做线上压力测试。用到的方式主要通过：apache 的mod_jk和 mod_proxy模块；nginx的proxy以及upstream等。这种方式压测的结果准确性高，唯一的不足是这种方式依赖系统流量，如果系统流量很低，就算是将所有的流量引到一台机器上面，仍不足以达到压测目的。请求引流转发模式的压测结果准确性高。
修改负载均衡权重
同样为完全真实的压测模型，可以用于集群部署的web环境中，也可用于集群部署的服务类系统。在web环境中我们通过修改F5或者LVS的机器负载均衡权重来使得流量更多的倾斜到其中的某一台后者某几台机器上；对于服务类系统，我们通过修改服务注册中心的机器负载均衡权重来使得服务的调用更多分配到某一台或者某几台机器上。修改负载均衡权重式的压测结果准确性高。
系统的服务能力我们定义为“系统能力”。在系统机器配置都差不多的情况下，系统能力等于线上压力测试获取的单台服务能力乘以机器数。在得知了系统能力之后，接下来我们需要知道自己的系统跑在怎么样的一个容量水位下，从而指导我们做一些决策，是该加机器了？还是该下掉一些多余的机器？通常系统的调用都有相关日志记录，通过分析系统的日志等方式获取系统一天当中最大的调用频率（以分钟为单位），我们定义为系统负荷；当前一分钟的调用频率我们定义为当前负荷。计算系统负荷可以先把相关日志传到hdfs，通过离线hadoop任务分析；计算当前负荷我们采用storm的流式计算框架来进行实时的统计。
水位公式
系统水位 = 系统负荷 / 系统能力；当前水位 = 当前负荷 / 系统能力。
水位标准
单机房（70%）；双机放（40%)；三机房（60%）。
单机房一般都是不太重要的系统，我们可以压榨下性能；
双机房需要保障在一个机房完全挂掉的情况下另一个机房能够撑得住挂掉机房的流量；
三机房同样需要考虑挂掉一个机房的场景后剩下两个机房能够撑得住挂掉机房的流量。
机器公式
理论机器数 = （实际机器数 * 系统负荷 * 系统水位）/ （系统能力 * 水位标准）
机器增减 = 理论机器数 – 实际机器数
强弱依赖检测面临的最大挑战就是如何使用户使用方便，接入成本最小，主要需要解决下面两件事情：
稳定性平台通过依赖治理、容量规划、降级管理、实时监控等手段，对阿里各系统稳定性的治理给予了支持。未来我们将继续深挖稳定性这个领域，汇总各种数据，真正做到稳定性的智能化、自动化。
系列文章：
《 中间件技术及双十一实践之中间件总体介绍》 http://jm-blog.aliapp.com/?p=3359
《 中间件技术及双十一实践之软负载篇》 http://jm-blog.aliapp.com/?p=3450
《 中间件技术及双十一实践·服务框架篇》 http://jm-blog.aliapp.com/?p=3462
《 中间件技术及双十一实践·EagleEye篇》 http://jm-blog.aliapp.com/?p=3465
《中间件技术及双十一实践·消息中间件篇》http://jm-blog.aliapp.com/?p=3483
《中间件技术及双十一实践·数据篇》http://jm-blog.aliapp.com/?p=3490
《中间件技术及双十一实践·应用服务器篇》http://jm-blog.aliapp.com/?p=3495
如果觉得内容还行，请分享给更多的人…