【系统架构】亿级Web 系统的容错性实践【下】

服务降级，自动屏蔽非核心分支异常

对于一次礼包领取请求，在我们的后端CGI会经过10多个环节和服务的逻辑判断，包括礼包配置读取、礼包限量检查、登陆态校验、安全保护等等。而这些服务中，就有不可以跳过的核心环节，例如读取礼包配置的服务，也有非核心环节，例如数据上报。对于非核心环节，我们的做法，就是设置一个比较低的超时时间。

例如我们其中一个统计上报服务，平均耗时是3ms，那么我们就将超时时间设置为20ms，一旦超时则旁路掉，继续按照正常逻辑走业务流程。

服务解耦、物理隔离

虽然，大家都知道一个服务的设计，要尽可能小和分离部署，如此，服务之间的耦合会比较小，一旦某个模块出问题，受到影响的模块就比较少，容错能力就会更强。可是，从设计之初，就将每一个服务有序的切割地很小，这个需要设计者具备超前的意识，能够提前意识到业务和系统的发展形态，而实际上，业务的发展往往是比较难以预知的，因为业务的形态会随着产品的策略的改变而变化。在业务早期流量比较小的时候，通常也没有足够的人力和资源，将服务细细的切分。AMS从日请求百万级的Web系统，逐渐成长为亿级，在这个过程中，流量规模增长了100倍，我们经历了不少服务耦合带来的阵痛。

服务分离、大服务变成多个小服务

我们常常说，鸡蛋不能都放在一个篮子里。AMS以前是一个比较小的系统（日请求百万级，在腾讯公司内完全是一个不起眼的小Web系统），因此，很多服务和存储在早起都是部署在一起的，查询和发货服务都放在一起，不管哪一个出问题，都相互影响。后来，我们逐渐的将这些核心的服务和存储，慢慢地分离出来，细细切分和重新部署。在数据存储方面，我们将原来3-5个存储的服务，慢慢地切为20多个独立部署的存储。

例如，2016年下半年，我们就将其中一个核心的存储数据，从1个分离为3个。

这样做带来了很多好处：

1：原来主存储的压力被分流；

2：稳定性更高，不再是其中一个出问题，影响整个大的模块；

3：存储之间是彼此物理隔离的，即使服务器硬件故障，也不会相互影响。

轻重分离、物理分离

另外一方面，我们对于一些核心的业务，进行“轻重分离”。例如，我们支持2016年“手Q春节红包”活动项目的服务集群。就将负责信息查询和红包礼包发货的集群分别独立部署，信息查询的服务相对没有那么重要，业务流程比较轻量级，而红包礼包发货则属于非常核心的业务，业务流程比较重。

轻重分离的这个部署方式，可以给我们带来一些好处：

1：查询集群即使出问题，也不会影响发货集群，保证用户核心功能正常；

2：两边的机器和部署的服务基本一致，在紧急的情况下，两边的集群可以相互支援和切换，起到容灾的效果；

3：每个集群里的机器，都是跨机房部署，例如，服务器都是分布在ABC三个机房，假设B机房整个网络故障了，反向代理服务会将无法接受服务的B机房机器剔除，然后，剩下AC机房的服务器仍然可以正常为外界提供服务。

业务层面的容错

如果系统架构设计层面的“容错”我们都搭建完善了，那么再继续下一层容错，就需要根据实际的业务来进行，因为，不同的业务拥有不同的业务逻辑特性，也能够导致业务层面的各种问题。而在业务层面的容错，简而言之，避免“人的失误”。不管一个人做事性格多么谨慎细心，也总有“手抖”的时候，在不经意间产生“失误”。AMS是一个活动运营平台，一个月会上线400多个活动，涉及数以千计的活动配置信息（包括礼包、规则、活动参与逻辑等等）。在我们的业务场景下，因为种种原因而导致“人的失误”并不少。

例如，某个运营同学看错礼包发放的日限量，将原本只允许1天放量100个礼包的资源，错误地配置为每天放量200个。这种错误是测试同学比较难测试出来的，等到活动真正上线，礼包发放到101个的时候，就报错了，因为资源池当天已经没有资源了。虽然，我们的业务告警系统能够快速捕获到这个异常（每10分钟为一个周期，从十多个维度，监控和计算各个活动的成功率、流量波动等等数据），但是，对于腾讯的用户量级来说，即使只影响十多分钟，也可以影响成千上万的用户，对于大规模流量的推广活动，甚至可以影响数十万用户了。这样的话，就很容易就造成严重的“现网事故”。

完善的监控系统能够及时发现问题，防止影响面的进一步扩大和失控，但是，它并不能杜绝现网问题的发生。而真正的根治之法，当然是从起源的地方杜绝这种场景的出现，回到上面“日限量配置错误”的例子场景中，用户在内部管理端发布活动配置时，就直接提示运营同学，这个配置规则是不对的。

在业界，因为配置参数错误而导致的现网重大事故的例子，可以说是多不胜数，“配置参数问题”几乎可以说是一个业界难题，对于解决或者缓解这种错误的发生，并没有放之四海而皆准的方法，更多的是需要根据具体业务和系统场景，亦步亦趋地逐步建设配套的检查机制程序或者脚本。

因此，我们建设了一套强大并且智能的配置检查系统，里面集合了数十种业务的搭配检查规则，并且检查规则的数目一直都在增加。这里规则包括检查礼包日限量之类比较简单的规则，也有检查各种关联配置参数、相对比较复杂的业务逻辑规则。

另外一方面，流程的执行不能通过“口头约定”，也应该固化为平台程序的一部分，例如，活动上线之前，我们要求负责活动的同事需要验证一下“礼包领取逻辑”，也就是真实的去领取一次礼包。然而，这只是一个“口头约定”，实际上并不具备强制执行力，如果这位同事因为活动的礼包过多，而漏过其中一个礼包的验证流程，这种事情也的确偶尔会发生，这个也算是“人的失误”的另外一种场景。

为了解决问题，这个流程在我们AMS的内部管理端中，是通过程序去保证的，确保这位同事的QQ号码的确领取过全部的礼包。做法其实挺简单的，就是让负责活动的同事设置一个验证活动的QQ号码，然后，程序在发货活动时，程序会自动检查每一个子活动项目中，是否有这个QQ号码的活动参与记录。如果都有参与记录，则说明这位同事完整地领取了全部礼包。同时，其他模块的验证和测试，我们也都采用程序和平台来保证，而不是通过“口头约定”。

通过程序和系统对业务逻辑和流程的保证，尽可能防止“人的失误”。

这种业务配置检查程序，除了可以减少问题的发生，实际上也减轻了测试和验证活动的工作，可以起到节省人力的效果。不过，业务配置检查规则的建设并不简单，逻辑往往比较复杂，因为要防止误杀

小结

无论是人还是机器，都是会产生“失误”，只是对于单一个体，发生的概率通常并不大。但是，如果一个系统拥有数百台服务器，或者有一项工作有几百人共同参与，这种“失误“的概率就被大大提升，失误很可能就变为一种常态了。机器的故障，尽可能让系统本身去兼容和恢复，人的失误，尽可能通过程序和系统流程来避免，都尽可能做到”不依赖于人“。

容错的核心价值，除了增强系统的健壮性外，我觉得是解放技术人员，尽可能让我们不用凌晨起来处理告警，或享受一个相对平凡闲暇的周末。对于我们来说，要完全做到这点，还有很长的路要走，与君共勉。