微博平台的稳定与容灾测试
马年春节将至，鉴于今年微博将与春晚合作，复杂的业务以及庞大的用户访问量对微博的稳定性提出了重大的考验，维持微博的稳定是一项防御工作，并不如开发新产品一样具有激进性，但是一旦防线崩溃，后果是不堪设想的。 何为稳定、为何不稳定 何为稳定的系统？这里的稳定是指工作状态及结果符合预期，达到期望的目标。在微博，引起不稳定的因素很多，依赖的资源服务异常、硬件故障、流量突增、代码bug以及服务升级等。为了在诸多的不稳定因素和频繁的变更下依旧保持系统稳定，微博平台采取了“容错设计”和“容灾演练”两大措施。 容错设计 分层隔离：将多个服务共同依赖的资源进行隔离，从而确保一个服务出现异常时另一个服务不受影响。对微博核心业务进行物理隔离，保证微博核心业务如feed服务正常运行。分层隔离并不能解决故障，但能够用低的成本解决故障。 超时控制：超时控制，包括对资源的超时控制以及接口的超时控制，其定位：对任何依赖不能无止境的信任！对不靠谱的依赖该放弃放弃！ 队列阻塞：对于并发多的服务，增加请求队列，对于必要的依赖要有一定的容忍度，限定在Agreement之内。同时，对于不能消化的请求将会尽早的抛弃，避免流量过大，导致服务crash。 开关容错：包括各种自动及手动降级开关，如守护进程实时监控hbase或mysql存储响应时间，如果超过阀值，将自动快速失败。手动开关是在必要时切断一切依赖。 容量规划：单机容量(qps) = 大处理线程数/单次请求平均响应时间。每季度一次容量评估，重大活动提前评估，日常30％的冗余。 容灾演练 做好以上，我们的系统稳定了吗？这些仍然不够，做到真正的全面防御，还需要设计出各种突发的异常场景，并对其进行演练，因此诞生了容灾演练平台——TouchStone。
演练目的： 确认碰撞时安全气囊是打开的（确认容错设计生效） 即使出问题事后有补救措施（预案处理） 发现其他隐患 演练过程：
Touchstone容灾演练过程 下图为TouchStone的组成模块：
Touchstone容灾演练系统组成 常见的异常表现及原因： 异常影响程度叠加放大（串行化操作？） 功能相关的接口同时受到影响（依赖性影响？） 大量接口大范围受到影响（四七层等保护策略出现问题？过载？） 某个接口的所有请求都受到影响（资源单点部署？） 对于一个复杂的系统，“异常”是常态：从网络到硬盘的资源故障，每周数十次的代码变更，突发的流量等等。面向错误进行系统设计和实现，并通过容灾演练系统验证设计有效，确认补救措施符合预期，才是的出路。
