我们常常说，鸡蛋不能都放在一个篮子里。AMS以前是一个比较小的系统（日请求百万级，在腾讯公司内完全是一个不起眼的小Web系统），因此，很多服务和存储在早起都是部署在一起的，查询和发货服务都放在一起，不管哪一个出问题，都相互影响。后来，我们逐渐的将这些核心的服务和存储，慢慢地分离出来，细细切分和重新部署。在数据存储方面，我们将原来3-5个存储的服务，慢慢地切为20多个独立部署的存储。
例如，2015年下半年，我们就将其中一个核心的存储数据，从1个分离为3个。
亿级Web系统的容错性建设实践 - 徐汉彬Hansion - 技术行者
这样做带来了很多好处：
（1） 原来主存储的压力被分流。
（2） 稳定性更高，不再是其中一个出问题，影响整个大的模块。
（3） 存储之间是彼此物理隔离的，即使服务器硬件故障，也不会相互影响。
2. 轻重分离，物理隔离另外一方面，我们对于一些核心的业务，进行“轻重分离”。例如，我们支持2016年“手Q春节红包”活动项目的服务集群。就将负责信息查询和红包礼包发货的集群分别独立部署，信息查询的服务相对没有那么重要，业务流程比较轻量级，而红包礼包发货则属于非常核心的业务，业务流程比较重。
亿级Web系统的容错性建设实践 - 徐汉彬Hansion - 技术行者
轻重分离的这个部署方式，可以给我们带来一些好处：
（1） 查询集群即使出问题，也不会影响发货集群，保证用户核心功能正常。
（2） 两边的机器和部署的服务基本一致，在紧急的情况下，两边的集群可以相互支援和切换，起到容灾的效果。
（3） 每个集群里的机器，都是跨机房部署，例如，服务器都是分布在ABC三个机房，假设B机房整个网络故障了，反向代理服务会将无法接受服务的B机房机器剔除，然后，剩下AC机房的服务器仍然可以正常为外界提供服务。
亿级Web系统的容错性建设实践 - 徐汉彬Hansion - 技术行者
六、 业务层面的容错如果系统架构设计层面的“容错”我们都搭建完善了，那么再继续下一层容错，就需要根据实际的业务来进行，因为，不同的业务拥有不同的业务逻辑特性，也能够导致业务层面的各种问题。而在业务层面的容错，简而言之，避免“人的失误”。不管一个人做事性格多么谨慎细心，也总有“手抖”的时候，在不经意间产生“失误”。AMS是一个活动运营平台，一个月会上线400多个活动，涉及数以千计的活动配置信息（包括礼包、规则、活动参与逻辑等等）。在我们的业务场景下，因为种种原因而导致“人的失误”并不少。
例如，某个运营同学看错礼包发放的日限量，将原本只允许1天放量100个礼包的资源，错误地配置为每天放量200个。这种错误是测试同学比较难测试出来的，等到活动真正上线，礼包发放到101个的时候，就报错了，因为资源池当天已经没有资源了。虽然，我们的业务告警系统能够快速捕获到这个异常（每10分钟为一个周期，从十多个维度，监控和计算各个活动的成功率、流量波动等等数据），但是，对于腾讯的用户量级来说，即使只影响十多分钟，也可以影响成千上万的用户，对于大规模流量的推广活动，甚至可以影响数十万用户了。这样的话，就很容易就造成严重的“现网事故”。
亿级Web系统的容错性建设实践 - 徐汉彬Hansion - 技术行者