从淘宝到云端的高可用架构演进

在缓存上,我认为一切东西都可以被缓存的,通常我们认为缓存跟实际数据库里存在的东西可能是不一样的,有几毫秒的延迟或者怎么样,所以我们设计一个系统的时候,对一致性要求非常高的时候,会倾向于不用缓存,用数据库扛这个流量.但以MySQL为例,InnoDB里有一个很重要的缓存Buffer Pool,对于一个数据库,在冷库的情况下用一堆SQL去查它,和慢慢预热完再查它的时候效果是不一样的,这个是我们当初在做异地多活时面临的一个问题,例如我已经有一个机房,希望建立一个新单元去承担这个机房的流量,当我建完这个单元,把所有的应用都部署好了后,把流量切50%过来会怎么样,假设这两个单元的机器数一样,这个单元会挂,因为这个数据库是冷的,缓存是空的,不能承担之前那个单元数据库所能承担的QPS.

现在业界有很多叫API网关或者CDN,他们在边缘节点也做了一层短暂的Cache,可能只Cache 50或者100毫秒,但是当你系统受到攻击的时候可以拯救你后端的应用系统,攻击引发的命中率通常比较高,有这50毫秒的缓存,可能后端只有几百个QPS过来,那个流量你是可以承受的.

在高可用里两个非常经典的做法是限流和降级,在阿里双11,有一位老兵说过一句话,他说当双11到来的时候,任何一个系统都可能出问题,你要做的是对你的上游限流,对你的下游限流.怎么理解,当上流的流量超过你的能力的时候就要限流,当下游比如DBA告诉你数据库压力很大了,那就对下游限流,只要保证住这个限流,你基本不会挂,每个系统都做到这个的时候,整个系统都是可用的.当流量超出你掌控的时候,这个做法可以让你成为这个暴风下的幸存者.

对限流降级的思考,第一限流降级考验的是什么问题,我认为本质上考验的是故障自恢复能力,在平时工作中会遇到机房断网或者停电,每半个月都会做断网演练,不告诉你发生什么,就把这个网切断,看你的应用O不OK,一般是在晚上两三点,接到很多的机房报警,这个时候看你的架构设计的是否足够可用,如果足够可用就没问题,不会造成什么影响,继续睡觉,如果设计不好,就得爬起来立即处理.

而开关降级最大的作用,比如我们发现一些线上的问题,第一反映是赶紧回滚,但是当你的系统很大的时候,特别像Java这种,一个系统启动要启动几分钟,你的回滚完成,20分钟都过去了,这个过程对用户来说都是有损的,而开关可以在一瞬间把所有的逻辑切到老的.这个是避免回滚时间导致的问题.开关有的时候能救命,如果没有这个开关的话,避免问题放大就只能回滚,所以开关是一个很大的价值所在.

另外一点非常重要的是,在设计一个技术方案的时候,就会把容灾的设计融入到方案里.比如在设计技术方案的时候,在最后一章单独有一个容灾设计,这个节点里任何服务挂掉的时候,你要保持什么样的方式保持这个服务是可用的.

在容灾设计时有几点必须考虑,比如我引了一个新jar包或者调了一个新的RPC的服务、引入了分布式的存储,以前没用过也不知道它稳不稳定,第一想法是它肯定会挂,它挂了我们怎么做,我们当时在做前台系统的异步化的时候,因为Redis支持map的数据结构,所以我们就是用Redis的hmget从这个map里拿出部分的key减少网卡的流量,但即使这个挂掉了,我们还会走老的Cache,只不过网卡流量会大一些,但是对用户的服务是无损的,所以这里要考虑如果它挂了怎么做降级,有什么样的恢复流程.

另外是发布计划,在新系统上线时就会关注这些问题,比如这次有没有做数据迁移,比如以前我是8个库不够用了我拆到16个库或者32个库,中间一定是有数据迁移的,涉及到数据迁移一定要有一套对账系统保证这个数据是新数据和老数据是对得平的,不然一定有问题,因为我们是做交易相关的,订单、金额绝对不能出问题.

另外是你的发布顺序是不是有依赖,如果出了问题的时候,谁要先回滚,这里是取决于技术设计.另外是否要通过客服公告的方式告诉外部用户说有5分钟的不可用,如果真的有用户打电话有疑问客服同学可以向用户解释.

在高可用这个领域做久了会有一种直觉,这个直觉很重要,来源于你的经验转换成这种直觉,但是对于一个成熟的团队来说,需要把这种直觉转化为产品或工具.有很多牛人他们的技能都只能叫手艺,你需要把这种手艺转换成产品和工具.

2015年我去做云产品,这里给大家分享下我们是怎么样帮客户包括我们的系统在云上是做高可用的.

首先看两个经典故障案例,第一个是Gitlab生产数据库删了,它恢复了很久,Snapshot等全都没有生效,做了五六层的备份也都没有什么用.这个事情说明第一我们的故障要定期演练,比如中间件在做的线上故障演练,你说你的系统可用性好,我把这个主库断了,虚拟机挂掉几台试试,做这些演练就可以知道你这个容灾体系是不是可靠的,如果没有这个演练的话,当真正的故障发生时你才会发现这个东西是不OK的.

另外一个很典型的问题,Gitlab对备份的原理是不够了解的,比如当时用的PostgreSQL的一个版本,当时是有问题的,没有验证,开发人员对这个又不是特别了解的情况下就会出现这个问题,这就是为什么要去了解你的依赖以及你依赖的依赖.去年我们做压测,有个应用一边压测一边在优化做发布,发现第一批发的起不来了,就只是改了一两行代码加日志,他就去看什么原因,最后发现依赖的某个jar包依赖一个配置,而这个配置在压测中被降级了,一个jar包就把应用启动卡住了.如果在双十一当天或者在平时业务高峰期的时候发现这个问题是来不及修复的.所以这个时候,我们就要求,依赖的二方jar包必须看一下里面是怎么实现的,依赖哪些东西.

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!