转: 从微信的故障谈谈服务可用性

编者按：本文来自36氪特约作者叶新江（@猪立叶-Anson ）。叶新江曾任MSN中国总架构师，现任“个信互动”高级技术副总裁。个信互动公司推出专注于应用推送技术的服务“个推”，为包括新浪微博、百度、网龙等在内的公司提供推送服务。这里是我们之前对个推的报道。

昨天微信发生部分服务故障，媒体微博上面就此事表现相当热闹，这也从另一方面印证了微信的江湖地位以及移动互联网改变生活的真实写照。

从用户角度来说，一直好好的一个东西突然坏了，很大情况下可能不会首先想到是这东西本身坏了，而是先从别的地方找原因，这也是人的一种惯性思维。 而一旦发现是用的这东西本身坏了，愤怒和无奈的程度会更加加倍。但是有一点大家想过没有，任何一个东西的可用性都是需要有一定代价才能保证的。 越能用得长的东西，要么就是质量一流，要么就是需要不断检修和维护，这都需要不断付出努力才能做到。

服务可用性落实到具体的可以衡量的指标上来说，通常用几个9 来表示。通常大家所说的3个9 (99.9%), 是说一个业务系统造成大部分用户无法使用的时间一年中不超过 8小时46分钟，而全球互联网中的老大Google 对于服务可用性达到了5个9(99.999%), 也就是一年内故障时间不超过 5分钟 15 秒，这个故障时间对用户基本无感知。对于用户数量和交易数量可预测或者凭经验就可以了解的，而又关系到国计民生的行业，譬如银行、电信企业来说，一般都要求达到5个9。 然而对于互联网而言，5 个9 的服务可用性需要付出的代价和挑战是相当巨大的。

首先，在基础设施方面，针对服务质量，IDC 也分成很多等级；A 级一般承诺服务可用性达到或者接近4 个9， 这就要求至少以下几个方面: 必须多路电源接入（如果只有一路电源，万一没电了就瞎了），必须有支持至少 5 小时的蓄电设备、必须有独立的发电设备、所有设备和线路冗余备份（是所有设备），整个系统无单点故障。 以上这些还是比较粗的几条。

有了这样的基础设施保证，如果应用系统本身支持不到相应的几个9， 那么整个业务系统就服从木桶原则，哪个服务可用性低就是哪个。 而动不动就上亿用户一起访问的互联网应用来说，要做到 4 个或者5个9， 至少需要在几个方面来考虑：架构上的合理性和灵活性、整个系统成本的控制、运维的方便和高效。

先说说成本，对于类似传统的金融系统等而言，一般采用的是大块头的机器，因为其服务规模相对可控，譬如同时进行存钱、取钱转账的用户也就说那么万级别。 但是对于互联网系统而言，如果也采用大块头的机器，那么整个系统的花费将是天文数字。所以除了特别关键的数据会采用大块头机器来处理，一般都买的是普通的商业计算机（小几万一个）， 随着用户规模的增加不断买新的机器进行扩充，这本身也符合发展规律。 但是一般的商用机器故障率还是相当高的。你如果买过家用电脑，估计也经常碰到机器开不起来的问题吧。 那么怎么样在一堆机器里面的几个机器坏了的情况下，系统还能正常工作呢，这就要求在应用设计的时候能采用集群技术，自动进行故障转移和容错。 这就要求在架构上要能考虑到这些因素。

然后我们再来看，你如果所有的机器放在一个地方，即使能够在一个机房放得下， 在地大物博的中国，从北京来访问在杭州的服务器，如果是跨运营商的网络之间来访问，估计比坐飞机快不了多少。 这样的速度显然不符合好的体验这条金律。 而且把所有机器放在一个地方，万一这个地方出了什么问题，岂不是全完蛋了！ 所以不能把鸡蛋放在一个篮子里面，就需要根据用户的分布情况在不同的城市、同一城市的不同区域来建设业务系统。但是在逻辑上， 不同城市的系统应该又是同一个系统的，否则我在杭州加了一个在北京的朋友，如果过两天看不到了，谁还用啊。

这里又有一些问题需要解决，譬如就在某一天某个城市的开挖下水道，把光纤给挖断了， 导致访问到这个城市的系统无法使用了，那怎么办呢？ 把这些用户分流到别的城市的系统上去不就行了？ 是的，理论上是可以的。 但是就相当于如果一个城市被台风影响，需要把全部居民转移到另外一个城市或者几个城市里一样，转移到哪个城市、接收的城市是否能容纳这些新增加的居民，这些居民的银行存款等数据是否也能保证到了新城市后还能保持可用？在实在万不得已的情况下，有一部分居民可能无法转移。大规模互联网系统在故障时的处理思路也大致如此。 首先需要规划哪个城市给哪些用户服务，容量是多少，如果要接收别的城市的居民，那么还需要留多少容量，接收哪个城市来的用户，事先要把这些用户的信息能同步过来保存着等等。 即便如此在规划无法做到十分完善的情况下，部分用户可以继续服务，部分用户只能降级服务甚至拒绝服务，这也是为了保障整个系统能尽可能提供有限服务。

还有一个就是运维的高效性， 在故障出现后或者出现之前就能及时启动合理的应急措施，进行用户的分流，甚至对部分用户进行限流等。

如果在有些地方考虑不周，譬如我之前所在一家知名 IM 企业，由于地震导致海底光缆故障，很大部分的用户无法通过原路径访问系统，系统本身无法在中国提供应用层面的路由选择；只能依赖运营商来调整路由，这就在时间上大大超出可用性承诺的时间，无论最终是谁的原因， 最终导致用户大量流失。 也碰到过由于没有对部分用户降级服务或者延迟服务，而导致全部用户不断进行服务恢复尝试，形成浪涌和雪崩，导致整个服务最终拒绝服务(Deny of Service).

这些对于目前我们自己拥有上千万并发的个推系统而言，也都是一直在完善的方面。

对于腾讯而言，这十几年来对于几亿 QQ 用户的服务，积累了大量的有价值的经验. 微信出现这样的情况，应该说还是不多见的， 可能也说明在腾讯内部的资源分配还存在一定不均衡。 不过相信他们可以很快进行调整和完善，当然在这背后也意味着他们巨大的努力和付出。

原创文章，作者：guest