阿里异地多活与同城双活的架构演进

http://www.sohu.com/a/158859741_444159?qq-pf-to=pcqq.discussion

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

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

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

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

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

对于我们来讲这三个问题是比较明显的。阿里在整个高可用上也经历过了一段时间，主要是做了三个步骤。第一个是做了同城的双活，第二个做了异地只读及冷备，第三个是做了异地多活，经历了三代体系的演进才走到了今天。

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

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

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

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

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

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