从0开始学架构_29_28_业务高可用的保障异地多活架构

你好，我是华仔。

今天我和你分享的主题是异地夺国方案，无论是高可用、计算框架，还是高可用存储框架，其本质的设计目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。

但在一些极端场景下，有可能所有服务器都出现故障。

例如典型的有机房、断电、机房、火灾、地震、水灾。

这些极端情况会导致某个系统所有服务器都故障或者业务整体瘫痪。

而且即使有其他地区的备份，把备份业务系统全部恢复到能够正常提供业务花费的时间也比较长，可能是半小时，也可能是十二小时。

因为备份系统平时不对外提供服务，可能会存在很多隐藏的问题，没有发现。

如果业务期望达到，即使在此类灾难性故障的情况下，业务也不受影响，或者在几分钟内就能够很快恢复，可么就需要设计异地多活方案。

今天呢我来聊聊异地多活方案，接下来还会再讲异地多活的设计技巧和流程。

顾名思义，异地多活方案的关键点就是异地多活，其中异地就是指地理位置上不同的地方，类似于不要把鸡蛋都放在同一篮子里。

多活，就是指不同地理位置上的系统都能够提供业务服务。

这里的活是指活动活跃的意思，判断一个系统是否符合异地多国需要满足两个标准。

第一，正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务。

第二，某个地方业务异常的时候，用户访问其他地方正常的业务系统，能够得到正确的业务服务与活。

对应的字是贝贝是备份，正常情况下对外是不提供服务的。

如果需要提供服务，则需要大量的人工干预和操作，花费大量的时间才能让贝变成活。

单纯从异地多活的描述来看，异地多活很强大，能够保证在灾难的情况下业务都不受影响。

那是不是意味着不管什么业务，我们都要去实现异地多活架构呢？其实不然，因为实现异地多活架构不是没有代价的，相反其代价很高。

具体表现为，系统复杂度会发生质的变化，需要设计复杂的异地多活方案，成本会上升，毕竟要多在一个或多个机房搭建独立的一套业务系统。

因此，异地多活虽然功能很强大，但也不是每个业务，不管三星二十一都要上异地多活。

例如常见的新闻网站、企业内部的IT系统、游戏、博客、站点等。

如果无法承受异地多活，带来的复杂度和成本，是可以不做异地多活的，只需要做异地备份即可。

因为这类业务系统即使中断，对用户的影响并不会很大。

例如，a新闻网站中不了用户换个新闻网站即可。

而共享单车、滴滴出行、支付宝、微信这类业务就需要做异地多活了。

这类业务系统中断后对用户的影响很大，例如支付宝用不了就没法买东西了。

滴滴用不了，用户就打不到车了。

当然，如果业务规模很大，能够做异地多活的情况下，还是尽量首先这样能够在异常的场景下给用户提供更好的体验。

其次，业务规模很大，肯定会伴随衍生的收入，例如广告收入异地多活，能够减少异常场景带来的收入损失。

同样，以新闻网站为例，虽然从业务的角度来看，新闻类网站对用户影响不大，反正用户也可以从其他地方看到基本相同的新闻，甚至用户几个小时不看新闻也没什么问题。

但是从网站本身来看，几个小时不可访问，肯定会影响用户对网站的口碑。

其次，几个小时不可访问网站上的广告收入损失也会很大。

接下来我们来看看异地多国的方案，根据地理位置上的距离来划分，异地多活方案可以分为同城异区、跨城异地、跨国异地。

接下来，我来详细解释一下每一种方案的细节与优缺点。

一、桐城疫区。

桐城疫区指的是将业务部署在同一个城市、不同区的多个机房。

例如，在北京部署两个机房，一个机房在海淀区，一个机房在通州区，然后将两个机房用专用的高速网络连接在一起。

如果我们考虑一些极端场景，同城疫区似乎没什么作用，那为何我们还要设计同城疫区这种方案呢？答案就在于，同城同城的两个机房，距离上一般大约就是几十千米。

通过搭建高速的网络同城e区的两个机房，能够实现和同一个机房内几乎一样的网络传输速度。

这就意味着，虽然是两个不同地理位置上的机房，但逻辑上我们可以将它们看作同一个机房。

这样的设计大大降低了复杂度，减少了异地多国的设计和实现复杂度及成本。

那如果采用了同城疫区架构，一旦发生新奥尔良水灾，这种灾难怎么办呢？很遗憾，答案是无能为力。

但我们需要考虑的是，这种极端灾难发生概率是比较低的，可能几年或者十几年才发生一次。

其次，除了这类灾难机房、火灾、机房、停电、机房、空调故障，这类问题发生的概率更高，而且破坏力一样很大。

而这些故障场景，同城疫区方案都可以很好的解决。

因此，结合复杂度、成本、故障发生概率来综合考虑，同城疫区是应对机房级别故障的最优方案。

二、跨城异地跨城异地指的是业务部署在不同城市的多个机房，而且距离最好要远一些。

例如将业务部署在北京和广州两个机房，而不是将业务部署在广州和深圳的两个机房。

为何跨城异地要强调距离要远呢？前面我在介绍桐城疫区的方案时提到，桐城疫区不能解决新奥尔良水灾这种问题，而两个城市离得太近，又无法应对。

如每家大停店这种问题，跨城异地其实就是为了解决这两类问题的。

因此，需要在距离上比较远，才能有效应对这类极端灾难事件。

跨城异地虽然能够有效应对极端灾难事件，但距离较远，这点并不只是一个距离数字上的变化，而是量变引起了质变，导致了跨城异地的方案复杂度大大上升。

距离增加带来的最主要问题是两个机房的网络传输速度会降低。

这不是以人的意志为转移的，而是物理定律决定的。

即光速真空传播大约是每秒三十万千米。

在光纤中，传输的速度大约是每秒二十万千米，再加上传输中的各种网络设备的处理，实际还远远达不到理论上的速度。

除了距离上的限制，中间传输各种不可控的因素也非常多。

例如，挖掘机把光纤挖断、中美海底电缆被拖船扯断、骨干网故障等。

这些线路很多是第三方维护，针对故障，我们根本无能为力，也无法预知。

例如，广州机房到北京机房，正常情况下，二TT大约是五十毫秒左右，遇到网络波动之类的情况，二TT可能飙升到五百毫秒甚至一秒，更不用说经常发生的线路丢包问题，那延迟可能就是几秒几十秒了。

以上描述的问题，虽然桐城疫区理论上也会遇到，但由于桐城疫区距离较短，中间经过的线路和设备较少，问题发生的概率会低很多。

而且，桐城疫区距离短，即使是搭建多条互联通道，成本也不会太高。

而跨城疫区距离太远，搭建或者使用多通道的成本会高不少。

跨城异地距离较远带来的网络传输延迟问题，给异地多国架构设计带来了复杂性。

如果要做到真正意义上的多活业务系统，需要考虑部署在不同地点的两个机房。

在数据短时间不一致的情况下，还能够正常提供业务。

这就引入了一个看似矛盾的地方，数据不一致业务肯定不会正常。

但跨城异地肯定会导致数据不一致，如何解决这个问题呢？重点还是在数据上及根据数据的特性来做不同的方案。

如果是强一致性要求的数据，例如银行存款余额、支付宝余额等，这类数据实际上是无法做到跨城异地多活的。

我们来看一个假设的例子。

假如我们作为一个互联网金融的业务用户，余额支持跨城异地多活，我们的系统分别部署在广州和北京。

那么如果挖掘机挖断光缆后会出现如下场景，用户a余额有一万元，北京和广州机房都是这个数据用户a向用户b转了五千元钱。

这个操作是在广州机房完成的。

完成后，用户a在广州机房的余额是五千元，最于广州和北京机房网络被挖掘机挖断，广州机房无法将余额变通通知北京机房。

此时北京机房用户a的余额还是一万元，用户a到北京机房又发起转账。

此时他看到自己的余额还有一万元，于是向用户c转账一万元。

转账完成后，用户a的余额变为零。

用户a到广州机房一看，哎，余额怎么还有五千元，于是赶紧又发起转账，转账五千元给用户d此时广州机房用户a的余额也变为零了，最终本来余额一万元的用户a却转了两万元出去给其他用户。

对于以上这种假设场景，虽然普通用户很难这样自如的操作，但如果真的这么做，被黑客发现后，后果不堪设想。

正因为如此，支付宝等金融相关的系统对余额，这类数据一般不会做跨城异地的多国方案，而只能采用同城异区这种方案。

而对数据一致性要求不那么高，或者数据不怎么改变，或者即使数据丢失影响也不大的业务，跨成异地多国就能够派上用场了。

例如，用户登录新闻类网站、微博类网站，这些业务采用跨城异地多国，能够很好的应对极端灾难的场景。

三、跨国异地、跨国异地指的是业务部署在不同国家的多个机房。

相比跨城异地，跨国异地的距离就更远了，因此数据同步的延时会更长，正常情况下，可能就有几秒钟了。

这种程度的延迟已经无法满足异地多活标准的第一条。

正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务。

例如，假设有一个微博类网博，分别在中国的上海和美国的纽约都建了机房用户a在上海机房发表了一篇微博。

此时，如果他的一个关注者逼用户访问到美国的机房，很可能无法看到用户a刚刚发表的微博。

虽然跨城异地也会有此类同步延时问题，但正常情况下，几十毫秒的延时对用户来说基本无感知的，而延时达到几秒钟就感觉比较明显了。

因此，跨国异地的多活和跨城异地的微博，实际的含义并不完全一致。

跨国异地多国的主要应用场景一般有这几种情况，第一，为不同地区用户提供服务，例如亚马逊，中国是为中国用户服务的，而亚马逊美国是为美国用户服务的。

亚马逊中国的用户如果访问美国，亚马逊是无法用亚马逊中国的账号登录美国。

亚马逊的第二只读类业务做多活。

例如谷歌的搜索业务。

由于用户搜索资料时，这些资料都已经存在于谷歌的搜索引擎上面。

无论是访问英国、谷歌还是访问美国，谷歌搜索结果基本相同，并且对用户来说，也不需要搜索到最新的实时资料。

跨国异地的几秒钟网络延迟对搜索结果是没有什么影响的。

今天我为你讲了异地多国方案的应用场景和常见方案，希望对你有所帮助。

这就是今天的全部内容，留一道思考题给你吧。

假设我们做了前面提到的高可用存储架构中的数据分区备份，又通过自动化运维能够保证一分钟就能将全部系统正常启动。

那是否意味着没有必要做异地多活了呢？欢迎你把答案写到留言区，和我一起讨论。

相信经过深度思考的回答，也会让你对知识的理解更加深刻。