0°

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

内容预览:
  • 而在业务层面的容错,简而言之,避免“人的失误”~
  • AMS是一个活动运营平台,一个月会上线400多个活动,涉及数以千计的活动...~
  • 完善的监控系统能够及时发现问题,防止影响面的进一步扩大和失控,但是...~

亿级Web 系统的容错性实践【上】 (请戳我)亿级Web 系统的容错性实践【中】 (请戳我)中总结了web系统容错的几种机制:简单重试主备服务自动切换动态剔除或者恢复异常机器超时时间设置,这几种机制各有其局限性,本文继续介绍web系统容错的其它机制



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


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

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

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




服务解耦、物理隔离


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

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

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

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

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

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

这样做带来了很多好处:

1:原来主存储的压力分流

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

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

轻重分离、物理分离

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

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

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

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

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

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

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



业务层面的容错


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

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

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

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

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

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

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

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

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

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

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

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

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


小结


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

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

推荐阅读:

精心整理 | 2017下半年文章目录

从机器学习谈起(2)

存储数据包的一生(下)

理解、使用Docker(下)

各种字符串Hash函数比较


专注服务器后台技术栈知识总结分享

欢迎关注交流共同进步

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

码农有道 coding


码农有道,为您提供通俗易懂的技术文章,让技术变的更简单!

原文始发于微信公众号(码农有道):【系统架构】亿级Web 系统的容错性实践【下】

以上就是:【系统架构】亿级Web 系统的容错性实践【下】 的全部内容。

本站部分内容来源于互联网和用户投稿,如有侵权请联系我们删除,谢谢。
Email:[email protected]


0 条回复 A 作者 M 管理员
    所有的伟大,都源于一个勇敢的开始!
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论