转自 http://itzoo.info/?p=591

一 如何利用应用自己的数据来保证系统的稳定-淘宝小赌

总体感觉淘宝经过最近这几年双十一和双十二的洗礼，在流量的容量规划和控制方面做了很多工作：

水位的概念

水位这个概念我觉得描述的非常恰当，就是大坝水位的概念一样。从上面这场PPT图片可以看出，单机房下70%作为了正常水位线，长期低于60%说明机器资源浪费、高于80%说明需要加机器了。双机房的正常水位线设定在40%是处于互备的目的考虑，一旦某个机房挂了，可以迅速将流量迁移到互备机房，这样双倍的流量需要保持在80%以下。

性能QPS的测量

性能QPS是指集群性能QPS（单机性能QPS x 集群结点数目），性能QPS是指load在num(cpu core)，cpu使用率70%情况下系统所能承受的QPS，num(cpu core)指的是CPU的核数，对于4核机器一般在4到4.5左右。采用这一数值实际上是对load这一指标的深入理解之后做出的。关于load通俗的解释是系统可以同时处理的任务个数或者处理队列的长度，理解Linux 的处理器负载均值 这篇翻译文章解释的很好，值得一看。

对于性能QPS的评估，淘宝有线上压测的方式，一般架构最前端都有lvs之类的负载均衡器做流量分发，通过把流量缓慢迁移到某一个应用服务器，可以观察到QPS以及系统负载的变化。 这种方式有一定的风险，一般站点如果没有能力控制的话，我建议还是采用tcpcopy等工具将流量复制到测试环境做评估，也可以采用PPT中提到的日志回访模式，根据访问日志将实际请求在测试环境中重演一遍得到测试结果。

流量QPS的评估

流量QPS主要是根据实际业务目标进行估算，比如双十一大促，业务目标是达成200亿，可以估算到会有多少订单，进而可以根据服务之间的依赖关系估算到每个服务的容量（这叫做容量依赖）。

容量依赖估算有两种方式:

• 一种是可以通过在服务路径中注入统一的UUID的方式测算到每个子系统的实际容量。
• 一种是根据访问日志的refer信息估算不同服务间的容量依赖关系。

流量防护

淘宝在流量防护做的工作有限流和服务降级。限流工作由内部代号叫做TMD(Taobao Missile Defense)的系统来完成。据说TMD可以抵挡DDoS攻击，可以封禁IP和cookie，可以限流（比如detail页面限流1600QPS），也可以提供验证码服务。TMD的工作原理是nginx实时发送日志给TMD Server，TMD server做策略分析，然后控制台做汇总和控制.我个人对这个系统比较感兴趣，淘叔度关于Tengine的一个PPT中提到了TMD,貌似还没有开源. 

二 新浪微博平台防御体系-姚四芳

架构图

从图上可以看出核心是scribe+storm+dashboard构成。

scribe是facebook开源的日志收集框架。

Scribe is a server for aggregating log data that’s streamed in real time from clients. It is designed to be scalable and reliable.

storm是twitter开源的分布式实时计算引擎。

Storm is a distributed realtime computation system. Similar to how Hadoop provides a set of general primitives for doing batch processing, Storm provides a set of general primitives for doing realtime computation. Storm is simple, can be used with any programming language, is used by many companies, and is a lot of fun to use!

个人认为两者的组合的确是日志实时分析利器，新浪微博基于这两个项目搭建健康状况实时分析平台真的是多快好省。

特色

• 方法级别的监控粒度和服务降级

  通过注解的方式实现（java代码），一旦发现某个方法响应时间过长，可以对该方法降级，马上返回，这也是快速失败思想的体现。后来在讨论环节姚提到了ASM，所以实现方式应该是利用了ASM对所有通过注解标记的方法进行了字节码动态增强，对方法做了代理。Spring的AOP实现底层也实现了ASM，这个技术挺有用，值得深入研究一下。

• URI接口降级

  新浪微博自己实现的访问proxy控制URI是否降级，一旦流量超过警戒线，可以对某些不处在关键路径上的URI服务降级，返回503状态。

• 图形化的Dashboard

  PPT中的一张图给我印象深刻，可惜忘了拍了。从他们平台监控Dashboard上可以看到微博feed区消息渲染这一过程中每个步骤的状态图，从图上可以清晰地看到哪个步骤是性能瓶颈，哪个步骤可能会出问题。这种方式不仅可以做监控，还可以快速定位性能瓶颈，从而做有针对性的代码优化。

三 如何利用SEDA提高系统的性能和稳定性-小米瞿晋萍

瞿从排队论切入，指出所有服务端软件都是排队服务思想，回顾了常见的并发模型：

首先介绍了基于thrift THsHaServer介绍了传统的HsHA模型（HALF-SYNC/HALF-ASYNC，半同步半异步模式），这种模型使用一个单独的线程处理网络IO，然后把请求丢给worker线程池，每个worker线程负责处理实际的任务，它的缺点是并发处理能力受worker线程池大小影响。

接着介绍了thrift 0.8版本对HsHa模式的改进——TThreadedSelectorServer，这种模型出一个线程池来专门进行网络IO的处理，所以它比THsHAServer更适合处理网络IO密集的情况。此外还介绍了twitter的Finagle框架，它也是对HsHA模型的改进。

最后介绍了SEDA(staged event driven architecture),这其实是一种思想，把一个复杂的事件驱动的任务拆解成由多个队列连接的状态集合。Host+MQ 就是这种思想的体现，每个Host处理任务的其中一个阶段，不同阶段的中间结果用消息队列来连接和协调。队列的拥塞程度可以反映出该阶段的处理能力和状态。

关于thrift各种服务器server模式，老外做了详解,这里有篇翻译文章写的不错。HsHa的详细介绍牛文在这里。SEDA思想也是老外提出的，服务器端的多线程并发处理模型这个领域，老外确实比国人高明不少，基本上所有模式都是人家想的，慨叹一下，这里面水深坑多，值得深入研究。

http://club.alibabatech.org/salon_detail.htm?salonId=29