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

1、 阿里异地多活与同城双活的架构演进CIO之家 微信号 imciow功能介绍 CIO（首席信息官)必备的公众号 CIO知识平台 CIO交流平台 企业IT人员知识平台(信息化资讯 活动 招聘信息 文档分享 IT应用实践 IT选型 IT实施 分享) CIO之家 践行,见未来.对于阿里的交易以及支付来讲，我们做异地多活最重要的目的除了灾备之外，更重要的点是追求持续可用，整个支付交易的体量对于用户来讲是持续可用。我们可以看一下业界比较主流的灾备是怎么做的，以及阿里在这方面整个的演进。业界最重要的很多人都知道，最主流的灾备技术是两地三中心，数据中心A和数据中心B在同城作为生产级的机房，当用户访问的时候随机

2、访问到数据中心A或B。之所以随便访问，因为A和B会同步做数据复制，所以两边的数据是完全一样的。但是因为是同步复制的，所以只能在同城去做两个数据中心，否则太远的话同步复制的延时会太长。在两地三中心的概念里，一定会要求这两个生产级的数据中心是必须在同一个城市，或者在距离很近的另外一个城市也可以，但是距离是有要求的。异地备份数据中心通过异步复制去走，但是两地三中心很明显的是异地备份的数据中心是不起用的，正常情况下不对外服务，所以用户不会访问到异地的点。原因是因为数据从生产级数据中心到异地的节点是异步去复制，所以整个有延时。这是整个业界目前用的比较多的业界。两地三中心对于阿里来讲看到的问题，最重要的问

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

4、题，在两地三中心中，数据一定是单点去写。其实数据只在一个地方去写，这个时候如果整个压力比较高，比如像“双十一”的场景中压力非常高的情况下，就意味着在两地三中心的情况下所有的数据还是写上的单个点，对于存储成本压力会不断增加。比如去年8万、今年14万意味着每年压力都在增加，这时候数据库整个伸缩和外层业务的伸缩都面临着更大挑战。对于我们来讲这三个问题是比较明显的。阿里在整个高可用上也经历过了一段时间，主要是做了三个步骤。第一个是做了同城的双活，第二个做了异地只读及冷备，第三个是做了异地多活，经历了三代体系的演进才走到了今天。异地多活对于我们来讲，其实很多人都可以看到异地多活最大的挑战是什么？1、距离

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

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

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