4个9是如何炼成的？

随着2014年元旦微博平台抗峰的顺利通过，2013年微博平台核心服务接口的可用性指标被定格在99.991%。

微博服务可用性提升是2013年微博平台技术团队的一个重要目标，为此，平台内部还特别建立的微博平台的SLA指标体系，其中微博平台核心服务接口（主要以feed服务相关接口为主）的可用性指标为：全年平均接口请求性能99.99%，即4个9的可用性指标。

我们的挑战在哪里？

说到feed服务大家都知道，feed服务是微博最核心，最有价值的服务，于是它也是产品经理们花心思最多的地方，各种产品功能策略逐步在feed服务中实现，“Feed置顶”、“关键词屏蔽”、“热门推荐”等等，伴随而来的是服务依赖的增多，虽然微博平台对内部的各个依赖资源及服务模块都有SLA指标的要求，但就算所依赖的各个服务的可用性都是在合理性能下的99.99%，假设feed服务依赖于9个服务模块，理论上feed服务的可用性只能达到99.99% ^9＝99.91%，即只能保证3个9的可用性。更何况，feed服务实际依赖不止9个资源或服务模块，甚至有些依赖的服务模块由于某些限制确实还不能达到4个9的可用性指标。这些情况都对服务的可用性形成很大的威胁，对我们的完成目标造成很大的挑战。

我们做了什么？

进入亚马逊，谷歌，微软等美国IT企业工作，百度搜索（MUMCS）

为了完成4个9可用性的目标，一方面微博平台内部建立标准的SLA指标体系，无论是资源，还是服务，都严格定义SLA指标（主要包括性能标准和可用性），并且实行服务分级策略，对于一般重要的（弱依赖）资源或服务执行标准的SLA标准，而对于非常重要的（强依赖）资源或服务，实行高要求的SLA标准，同时投入足够的资源和人力确保关键依赖服务的SLA指标的优化保障。另一方面，根据feed服务自身的业务特点，以所依赖资源或服务的SLA指标数据为基础，制定合理的容错和保障策略，通过在架构方面的策略改造，保证服务的健壮性，提升服务的可用性。

对于服务的SLA指标，最主要的就是明确性能标准和到达这一标准的服务调用比例（即可用性），以mysql资源为例：单次请求性能99.99%,（当然，这个指标需要根据具体的业务特点、sql的复杂程度等具体情况进行不同的定义，不能一概而论）。 明确了依赖服务的SLA指标，我们就可以从架构上通过一些策略保障整体服务品质，而不必过份依赖特定的资源和服务，具体有如下几个方面：

超时控制：

从connect timeout 到socket timeout细化超时指标和处理策略。Feed服务依赖了10多个资源或服务模块，偶尔会有某个服务出现问题，或者网络的抖动导致请求超时，如果feed服务无差别的进行等待，那将是一个噩梦。所以，feed服务根据业务特点，把这些依赖进行分级，然后再依据强弱依赖关系，对SLA指标进行分级，最后对各个依赖的请求分别设定异常处理阈值。以Feed置顶功能对资源的依赖为例，置顶微博ID存放在缓存memcached中，在feed聚合时需要从memcached取出这个数据，而平台对这个资源的SLA要求为99.99%，正常情况下都能满足整体服务性能，但当遇到特别情况比如网络抖动，很多获取置顶微博ID的请求将超过阈值，如果对请求超时不进行有效控制，就会影响到整个feed的请求。所以，在这种情况下，feed服务从架构上，对置顶功能的资源依赖明确了超时控制，一旦对这个资源请求时间超过80ms（一般情况下，这个阈值要比依赖资源确认的SLA标准稍微放宽一些，确保正常情况下这个超时控制策略不会误伤正常业务功能），则断开请求，避免影响到整个feed请求，而这种策略，就是通过资源的connect timeout和socket timeout来实现的。尽管在这种资源问题的情况下，置顶微博可能会偶发不显示，但feed的最主要功能没有受到影响。可见，这种对依赖隔离非常重要，对于任何依赖不能无止境的信任。

进入亚马逊，谷歌，微软等美国IT企业工作，百度搜索（MUMCS）

阻塞与容错：

对于必要的依赖，要有一定的容忍度（限定在SLA之内），通过请求队列，自动容错降级等方式容忍短期的服务波动，同时还需要一定的自动修复策略，保证依赖服务恢复后，主服务能够快速自动恢复。

Feed服务中最典型的阻塞容错策略是feed的发表模块，当你发表一条微博时，微博内容并不是直接存入mysql中，而是暂存在消息队列中，然后再由专门的消息处理模块对这些消息进行处理，进行更新入库。这样做把feed服务对3个左右的mysql依赖降低到对一个轻量级的消息队列的依赖，可靠性一下子提高了一个档次。当前类似这样通过阻塞及容错策略进行依赖降级或隔离的场景还有不少。

手动开关：

然而，在一些特殊的情况下，有些依赖的资源或服务可能长时间不可用，这样导致服务一直受到影响。尽管我们有前面所说的比如超时控制等一些保护策略，但这些保护策略也在消耗这一定的时间。短时间波动的问题可以非常好解决，但对于相对持续较长的问题，则很难达到效果。这是就需要我们手动切断依赖，等依赖问题恢复后再打开。

有人可能提出，为什么不能在超时控制的策略之上，自动增加这种开关机制能？实际上，对于非常核心的资源服务依赖，一般性的问题都不允许进行降级，如果采用自动降级策略风险将非常大，因为自动降级的边界非常难以判断，这种情况最好的方式就是采用手动降级的方式。（一旦实施了这个，一般都是出现了非常严重的问题，服务品质已经收到影响，只是尽可能的把影响降到较小范围。类似于“断臂保命”）

容量规划：

容量规划是每个系统必须认真面对的问题，单机容量（qps）＝最大处理线程数／单次请求平均响应时间，系统容量（qps）＝单机容量＊机器数＊r（容量系数），特别值得一提的是，分布式系统中的容量系数需要细致评估。另外，对于容量评估也要根据系统的演进经常的进行review，微博平台一般每个季度进行一次容量评估，同时明确定义一下SLA指标的修正，特别是重大活动之前需要提前评估。比如，对于微博服务，在元旦，春节都需要提前规划准备。而对于冗余量的问题，日常30%的冗余，确保一般突发事件引起的流量增长可以正常承受。

降级与限流：

容量评估能够解决可以预见的流量峰值请求，但作为开放的互联网服务，经常会有你不能预见的流量请求来冲击你，甚至有时你预见了将有超出你系统容量的请求，却来不及完成扩容。这时候就需要我们考虑如何避免流量超出容量导致整体服务crash。就像说，吃掉你能吃掉的，对于吃不掉的就快速扔掉； 这就需要一定的降级和限流策略。

对于这个降级与限流，实际处理时一般分为两级：单一实例的容器保护策略，整体集群服务的业务保护策略。

对于单一实例的容器保护策略（以tomcat为例）主要涉及maxThreads，acceptCount，具体处理策略如下图：（阈值处理指标需要根据具体业务场景来定）（如图：容器保护策略）

进入亚马逊，谷歌，微软等美国IT企业工作，百度搜索（MUMCS）