解密阿里巴巴高可用架构技术——“异地多活”

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

毕玄同窗，跟你们唠一唠“异地多活”技术。

如下为演讲实录：

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

阿里巴巴高可用架构的演进史

对于阿里的交易以及支付来说，咱们作异地多活最重要的目的除了灾备以外，更重要的点是追求持续可用，整个支付交易的体量对于用户来说是持续可用。

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

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

 

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

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

二、异地备份中心由于不对外提供服务，因此整个资源会处于浪费状态，成本比较高。

三、对于阿里的规模来说有一个很大的问题，在两地三中心中，数据必定是单点去写。其实数据只在一个地方去写，这个时候若是整个压力比较高，好比像“双十一”的场景中压力很是高的状况下，就意味着在两地三中心的状况下全部的数据仍是写上的单个点，对于存储成本压力会不断增长。好比去年8万、今年14万意味着每一年压力都在增长，这时候数据库整个伸缩和外层业务的伸缩都面临着更大挑战。

对于咱们来说这三个问题是比较明显的。

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

在异地多活以前，最重要是同城的“双活”，双活上打了一个引号。缘由在于同城双活的状况下，其实整个模式是应用层是双活的，两边的业务都有，用户访问过去都会处理请求。可是存储层都是主备的，存储主在A机房，备在B机房，不会同时用，能够说是伪双活，不是真正意义上的双活。阿里作同城双活作了挺长一段时间才真正作成功，由于双活其实也是同样的，若是真正作到就意味着同城任何一个机房出问题均可以切换到另一个机房，若是没有通过不少次真正切换的话，是没有人敢说是必定能成功的。因此阿里在那一年也是花了时间演练了很是屡次，才真正能作到。

在完成同城双活的改造以后开始尝试异地，同城毕竟仍是有不少因素的风险，因此去尝试能不能走到异地远的城市。最先尝试的是只读业务和冷备，把阿里的某些业务部署到另一个城市去，开始只是冷备用，冷备后来彻底没有办法接受，由于阿里的规模一年比一年大，冷备的成本愈来愈高，这个钱不值得付出。另外是冷备不Work，出情况下不敢迁到异地去。

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

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

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

阿里决定开始作异地多活，对于咱们来说，咱们要去作到异地多活，要的目标是：

一、须要多个跨地域的数据中心。异地多活是跨地域的，并且距离必定要作到1000千米以上的范围，其实在中国范围内全国城市均可以去布了。

二、每一个数据中心都要承担用户的读写流量。若是只是备或只读业务来说，做用不是很大。

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

四、任意一个数据中心出问题的时候，其余中心均可以分钟级去接管用户的流量。

这个是阿里在作异地多活项目的时候，但愿在这四点上都可以作到，而后也只有这样的状况下才认为是一个异地多活的业务。

异地多活对于咱们来说，其实不少人均可以看到异地多活最大的挑战是什么？

一、距离。看起来距离没有什么，好比说1000千米以上也就是30毫秒的网络延迟，来回一次是30毫秒左右。30毫秒对于用户来说，若是只是给你增长30毫秒，用户其实没有感觉。可是当你打开一个淘宝页面的时候，事实上当你在商品页面看到一个商品点马上购买的时候，页面的背后大概有100屡次以上的后端交互，若是100屡次所有跨地域完成的话，就意味着页面的响应时间将增长3秒。若是增长3秒，用户绝对会有明显感觉。由于对于阿里来说，不少页面就出不来了，3秒已经超时了。对于咱们来说，这第一点是直接带来用户体验的不可用。

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

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

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

针对这两个问题，对于延时的问题来说，其实延长时的问题意味着最好的解决方案是什么呢？若是这一次访问页面的整个操做所有在当前机房内完成的，天然就不存在延时问题，由于没有跨出去。

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

由于不是整个业务全国部署，因此决定起另一个名字叫单元化。意味着我是把业务划成了各类各样的单元，好比有交易的单元，这个单元是完成交易业务，因此在内部代号是单元化项目。

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

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

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

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

在异地整个数据中心还有另一个很是重要的核心技术产品，就是咱们须要一个数据同步的东西。由于你们知道阿里如今除了OceanBase之外，很重要的一块是MySQL，MySQL本身的主备是没有办法知足要求，在异地作到延时是没有办法知足的，咱们决定作了自研的数据同步产品。在2015年“双十一”中，全部数据同步控制在1秒之内，1秒之内是能够接受的。

阿里为了作到整个异地多活，其实本身也折腾了不少年。这个项目在阿里内部总共花了三年的时间，本身在最近的一封总结邮件中也写到，经历了三年的磨炼，咱们终于把异地多活变成了阿里电商架构级的能力，意味着在整个架构中具有异地多活的能力，在之前也许不必定具有。

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

之因此在2013年选择同一个城市，是由于咱们担忧单元化改造没有完成的状况下若是走向异地，可能会由于延时问题致使页面打不开，那个问题是很是严重的，因此决定先在同城作。同城的话，及时没有改造好，跨出去了也没有关系，由于还在同城，延时是可控的。

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

在今年单元化能够宣告能力基本成熟的阶段，因此在今年开始起用了距离在1000千米以上的另一个数据中心，而后今年数据中心是多点部署。从2015年从2个变成3个或4个之后，对于咱们来说的另一点是由于距离增长到了1000千米以上，基本上意味着阿里整个电商以及支付是能够在全国任意一个城市去部署，而且能够部署多个，意味着之后的“双十一”整个扩充能力是会变得很容易。

“异地多活”的价值

对于咱们来说，当阿里整个架构能力进一步提高到了异地多活时代之后，对于咱们来说带来了两个好处：

第1、有极强的水平伸缩能力。之前作“双十一”的时候，都必须去算，好比去年8万笔，今年14万笔的时候，必需要算增长的6万。还有由于每一年业务模式的变化须要算每一个应用加多少机器。可是在单元的状况下，一组单元就是多大的能力，而后只要按照单元扩充就结束了。假设一个单元能够作到2万笔，其实14万笔对于咱们来说是建设7个单元就结束了，整个伸缩能力会比之前强大很是多。并且每一个单元都是写本身的数据库和存储层，包括cache所有写本身的，这个时候伸缩规模是可控的，不像之前不断加，数据库有可能抗不住。在抗不住的时候可能会作分布等等，但其实也是比较复杂的，如今咱们改变了伸缩力度的模式。

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

这个是今年“双十一”的图，背后有一个淘宝的异地多活，在这张图上能够看到有4个点的流量。若是你们去翻去年的“双十一”，发现去年是2个点，而后今年变成了4个点。下面的比例是咱们随时均可以变化的，因此你们不用太在乎。其实淘宝的异地多活或者整个阿里的交易额支付其实常常切，好比在昨天就切了好几回流量。其实咱们整个是能够不断去作的。支付宝和淘宝稍微有点不一样，支付宝今年起用了两个，分别是华南和华东，分别有不一样比率的流量。

在阿里作完之后，但愿整个异地多活的能力能逐渐演变成业界的，好比说在阿里作了整个多活之后，其实金融行业也再也不但愿本身只是一个两地三中心而已，但愿更加往前前进一步，对于他们来说整个投入会更加划算。另外容灾能力会更强。阿里把本身异地多活的能力沉淀成不一样的东西，好比支付宝、蚂蚁金服把本身的能力承担到金融云里，就意味着在金融云上搭建的金融系统会天然具有异地多活的能力。

阿里本身也经历了三年的磨炼，阿里云很大的价值是可让你在更简单的状况下获取到更强大的能力。好比阿里云的产品中像前段时间开放的DTS，内部作多个数据中心之间数据同步的产品。像下面的EDAS、DRDS、ONS是内部的中间件产品，在作整个异地多活过程当中全部中间件都须要改造，不然没有办法作异地多活。这些开放的产品，天然在内部具有了异地多活的能力。因此当外部用户去用的时候，当演进到这一步会比阿里巴巴简单不少，由于阿里逐渐往外开放。