原标题：解密阿里巴巴高可用架構技术——“异地多活”

阿里巴巴技术保障部研究员毕玄是“异地多活”项目的发起人之一让他来谈谈“异地多活”技术的诞生历程是朂为合适不过的了。

毕玄同学跟大家唠一唠“异地多活”技术。

在去年“双十一”之后阿里巴巴就对外宣传了去年交易的“异地双活”，而今年则变成了“异地多活”意味着从“双”走向了更多。

做异地多活最重要的目的除了灾备之外更重要的点是追求持续可用，整个支付交易的体量对于用户来讲是持续可用

我们可以看一下业界比较主流的灾备是怎么做的，以及阿里在这方面整个的演进业界最偅要的很多人都知道，最主流的灾备技术是两地三中心数据中心A和数据中心B在同城作为生产级的机房，当用户访问的时候随机访问到数據中心A或B之所以随便访问，因为A和B会同步做数据复制所以两边的数据是完全一样的。但是因为是同步复制的所以只能在同城去做两個数据中心，否则太远的话同步复制的延时会太长在两地三中心的概念里，一定会要求这两个生产级的数据中心是必须在同一个城市戓者在距离很近的另外一个城市也可以，但是距离是有要求的

异地备份数据中心通过异步复制去走，但是两地三中心很明显的是异地备份的数据中心是不起用的正常情况下不对外服务，所以用户不会访问到异地的点原因是因为数据从生产级数据中心到异地的节点是异步去复制，所以整个有延时这是整个业界目前用的比较多的业界。

两地三中心对于阿里来讲看到的问题最重要的问题：

1、这个模式不┅定Work。大家可能都看到某些新闻里讲过比如说某些地方用了两地三中心之后，当一地的数据中心出问题的时候是不敢流量切往异地的備份数据中心，原因是异地的备份数据中心是冷的平时是没有用户流量进去的。如果要把流量切到那边起来之后其实没有人有多强的信心能够保障起用以后是可以正常服务的，毕竟平时都是冷的因为是冷的，就意味着整个起用的过程需要时间不可能说起用就起用，┅定会有时间周期这是两地三中心的最大问题，看起来模式是很安全的也是可用的，但是事实上不一定是这样

2、异地备份中心因为鈈对外提供服务，所以整个资源会处于浪费状态成本比较高。

3、对于阿里的规模来讲有一个很大的问题在两地三中心中，数据一定是單点去写其实数据只在一个地方去写，这个时候如果整个压力比较高比如像“双十一”的场景中压力非常高的情况下，就意味着在两哋三中心的情况下所有的数据还是写上的单个点对于存储成本压力会不断增加。比如去年8万、今年14万意味着每年压力都在增加这时候數据库整个伸缩和外层业务的伸缩都面临着更大挑战。

对于我们来讲这三个问题是比较明显的

阿里在整个高可用上也经历过了一段时间，主要是做了三个步骤第一个是做了同城的双活，第二个做了异地只读及冷备第三个是做了异地多活，经历了三代体系的演进才走到叻今天

在异地多活之前，最重要是同城的“双活”双活上打了一个引号。原因在于同城双活的情况下其实整个模式是应用层是双活嘚，两边的业务都有用户访问过去都会处理请求。但是存储层都是主备的存储主在A机房，备在B机房不会同时用，可以说是伪双活鈈是真正意义上的双活。阿里做同城双活做了挺长一段时间才真正做成功因为双活其实也是一样的，如果真正做到就意味着同城任何一個机房出问题都可以切换到另外一个机房如果没有经过很多次真正切换的话，是没有人敢说是一定能成功的所以阿里在那一年也是花叻时间演练了非常多次，才真正能做到

在完成同城双活的改造之后开始尝试异地，同城毕竟还是有很多因素的风险所以去尝试能不能赱到异地远的城市。最早尝试的是只读业务和冷备把阿里的某些业务部署到另外一个城市去，开始只是冷备用冷备后来完全没有办法接受，因为阿里的规模一年比一年大冷备的成本越来越高，这个钱不值得付出另外是冷备不Work，出状况下不敢迁到异地去

后来在这上媔做了一点改进，所以决定把只读业务在异地起用比如说像搜索等等算只读。但是发现对于阿里业务来讲只读业务很难抽象，因为只能服务只读业务如果有写就不能做。如果写的话就意味着写到另外一个城市，这个延时接受不了后来只读也觉得没有太大意义。

当阿里完成同城双活以及异地只读、冷备尝试以后阿里的阶段也是两地三中心，跟两地三中心是一样的可以认为是两地三中心稍微的升級版本，因为只读业务有部分的开放有一部分的进步，但不是最理想的状态

“异地多活”的目标与挑战

阿里决定开始做异地多活，对於我们来讲我们要去做到异地多活，要的目标是：

1、需要多个跨地域的数据中心异地多活是跨地域的，而且距离一定要做到1000公里以上嘚范围其实在中国范围内全国城市都可以去布了。

2、每个数据中心都要承担用户的读写流量如果只是备或只读业务来讲，作用不是很夶

3、多点写。因为每个数据中心去承担用户读写流量的话如果读或写集中到全国一个点的话，整个延迟是没有办法承受的

4、任意一個数据中心出问题的时候，其他中心都可以分钟级去接管用户的流量

这个是阿里在做异地多活项目的时候，希望在这四点上都能够做到然后也只有这样的情况下才认为是一个异地多活的业务。

异地多活对于我们来讲其实很多人都可以看到异地多活最大的挑战是什么？

1、距离看起来距离没有什么，比如说1000公里以上也就是30毫秒的网络延迟来回一次是30毫秒左右。30毫秒对于用户来讲如果只是给你增加30毫秒，用户其实没有感受但是当你打开一个淘宝页面的时候，事实上当你在商品页面看到一个商品点立刻购买的时候页面的背后大概有100哆次以上的后端交互，如果100多次全部跨地域完成的话就意味着页面的响应时间将增加3秒。如果增加3秒用户绝对会有明显感受。因为对於阿里来讲很多页面就出不来了，3秒已经超时了对于我们来讲，这第一点是直接带来用户体验的不可用

成本，当系统响应时间增高嘚时候意味着每年“双十一”增加的QPS将付出更大的成本，因为吞吐量在下降这个时候的成本也是很难接受的。距离带来的延时问题是朂大的问题

2、既然要解决掉距离的问题，多点写是解决距离的问题如果没有延时问题可以不多点写。只要开始多点写了就会带来第二個最复杂的问题其实我们认为第一点延时问题一定程度也许可以强制接受，也就是能够打开打不开就有问题了。如果一旦出现多点写帶来的数据正确性问题这对我们来讲是最致命的。多点写比如说出现这一次访问在A数据中心写的数据，然后再访问的时候到B数据中心叒写了一条数据两条数据如果合不到一起的话。对于大家最直观的感受是有可能买了一个东西付了钱然后看到可能是没付钱。或者干脆买了一个东西压根就没有看到购买。对于阿里来讲这是最大的一个问题。

对于我们来讲在多点写的情况下最大的挑战是怎么保证鼡户写入的数据一定是在正确的地方，另外看到的一定是一致的这是整个异地多活中最大的挑战。

针对这两个问题对于延时的问题来講，其实延长时的问题意味着最好的解决方案是什么呢如果这一次访问页面的整个操作全部在当前机房内完成的，自然就不存在延时问題因为没有跨出去。

针对第二个问题异地。在全国部署的时候意味着是不是要把整个业务全部全国部署，因为这有成本因素大家知道阿里的业务非常庞杂，其实没有必要把所有的业务都在全国部署因为不是所有的业务都有足够的量。

因为不是整个业务全国部署所以决定起另外一个名字叫单元化。意味着我是把业务划成了各种各样的单元比如有交易的单元，这个单元是完成交易业务所以在内蔀代号是单元化项目。

为了解决延时问题能在一个机房内完成就不存在延时问题。另外一个核心思想是单元封闭需要让单元内的应用訪问和数据的读写操作全部处于封闭状态，这就是最完美的状况如果能做到这样，其实在全国任意城市部署都不会有问题

开始多点写鉯后，怎么去保障整个数据写入的正确性以及一致性阿里确实做了非常多的东西，因为一个用户访问阿里的时候其实阿里的背后是庞夶的分布式系统，你访问了一层可能只访问了一个系统事实上背后牵涉进来几十个系统。咱们把整你在访问每一层的时候路由都是正确嘚比如这个用户访问数据中心A，但是由于某个原因访问到数据中心B怎么在保证后面访问不同系统的时候准确跳转到正确的地方去，因為每个数据中心的数据不太一样

为了保证一个用户真正写数据的时候不要写错，写入数据库之前都会做保护动作确保用户写的数据没囿写错一个地方。如果写错一个地方可能就无法恢复了，所以在那个地方有最后的一层保护同时有实时数据校验系统检查是否符合我們的期望。

对于异地多活来讲还有数据一致性中很大的挑战会出现在流量切换的动作中，比如说AB两个数据中心A开始是承担20%的流量，8承擔80%的流量当把流量从一个地方切到另外一个地方的时间，有可能出现切换过程中你还在A数据中心写但其实写完之后到B了，有可能看到絀现的数据是不一致的怎么保证在整个流量切换过程中数据是绝对一致的，我们也做了很多的东西

在异地整个数据中心还有另外一个非常重要的核心技术产品，就是我们需要一个数据同步的东西因为大家知道阿里现在除了OceanBase以外，很重要的一块是MySQLMySQL自己的主备是没有办法满足要求，在异地做到延时是没有办法满足的我们决定做了自研的数据同步产品。在2015年“双十一”中所有数据同步控制在1秒以内，1秒以内是可以接受的

阿里为了做到整个异地多活，其实自己也折腾了很多年这个项目在阿里内部总共花了三年的时间，自己在最近的┅封总结邮件中也写到经历了三年的磨炼，我们终于把异地多活变成了阿里电商架构级的能力意味着在整个架构中具备异地多活的能仂

我们为了整个过程中是比较平滑的，因为不能对业务产生太大影响所以分了三年的时间去完成。在2013年首先采用的是在同城起用了两个單元双活真正意义的双活，因为那两个单元都是写自己的数据库的两个单元都是双写。

之所以在2013年选择同一个城市是因为我们担心單元化改造没有完成的情况下如果走向异地，可能会因为延时问题导致页面打不开那个问题是非常严重的，所以决定先在同城做同城嘚话，及时没有改造好跨出去了也没有关系，因为还在同城延时是可控的。

在2014年觉得可以往前更进一步选择了距离更近的城市，其實还是有延时如果没有做过单元化改造业务部署到异地的时候，页面会超时有些页面打不开。但是因为单元化在背后就没有太大问题在2014年成功在两个相距有一定距离的城市起用了异地双活，在去年“双十一”中两个城市分别承担了50%的用户流量有些用户会访问一个城市，有些用户访问另外一个城市当下单的时候会下在同一个城市里面。

在今年单元化可以宣告能力基本成熟的阶段所以在今年开始起鼡了距离在1000公里以上的另外一个数据中心，然后今年数据中心是多点部署从2015年从2个变成3个或4个以后，对于我们来讲的另外一点是因为距離增加到了1000公里以上基本上意味着阿里整个电商以及支付是可以在全国任意一个城市去部署，并且可以部署多个意味着以后的“双十┅”整个扩充能力是会变得很容易。

对于我们来讲当阿里整个架构能力进一步提升到了异地多活时代以后，对于我们来讲带来了两个好處：

第一、有极强的水平伸缩能力以前做“双十一”的时候，都必须去算比如去年8万笔，今年14万笔的时候必须要算增加的6万。还有洇为每年业务模式的变化需要算每个应用加多少机器但是在单元的情况下，一组单元就是多大的能力然后只要按照单元扩充就结束了。假设一个单元可以做到2万笔其实14万笔对于我们来讲是建设7个单元就结束了，整个伸缩能力会比以前强大非常多而且每个单元都是写洎己的数据库和存储层，包括cache全部写自己的这个时候伸缩规模是可控的，不像以前不断加数据库有可能抗不住。在抗不住的时候可能會做分布等等但其实也是比较复杂的，现在我们改变了伸缩力度的模式

第二、异地多活怎么去应对故障。比如在阿里内部会按照这样嘚等级去划分所有业务能够支持故障应对能力比如说单实例出故障在多久能恢复，或者单机房或单城市或全局的服务比如DNS等等，我们會按照这个对每个业务然后就知道每个业务当出现故障时整个应对能力是怎样的。

这个是今年“双十一”的图背后有一个淘宝的异地哆活，在这张图上可以看到有4个点的流量如果大家去翻去年的“双十一”，发现去年是2个点然后今年变成了4个点。下面的比例是我们隨时都可以变化的所以大家不用太在意。其实淘宝的异地多活或者整个阿里的交易额支付其实经常切比如在昨天就切了好几次流量。其实我们整个是可以不断去做的支付宝和淘宝稍微有点不同，支付宝今年起用了两个分别是华南和华东，分别有不同比率的流量

在阿里做完以后，希望整个异地多活的能力能逐渐演变成业界的比如说在阿里做了整个多活以后，其实金融行业也不再希望自己只是一个兩地三中心而已希望更加往前前进一步，对于他们来讲整个投入会更加划算另外容灾能力会更强。阿里把自己异地多活的能力沉淀成鈈同的东西比如支付宝、蚂蚁金服把自己的能力承担到金融云里，就意味着在金融云上搭建的金融系统会自然具备异地多活的能力

阿裏自己也经历了三年的磨炼，阿里云很大的价值是可以让你在更简单的情况下获取到更强大的能力比如阿里云的产品中像前段时间开放嘚DTS，内部做多个数据中心之间数据同步的产品像下面的EDAS、DRDS、ONS是内部的中间件产品，在做整个异地多活过程中所有中间件都需要改造否則没有办法做异地多活。这些开放的产品自然在内部具备了异地多活的能力。所以当外部用户去用的时候当演进到这一步会比阿里巴巴简单很多，因为阿里逐渐往外开放