简述异地多活架构

异地多活架构所解决的问题、判断标准、代价和架构模式(同城异区/跨城异地/跨国异地)

转载自 极客时间《从0开始学架构》李运华

第28期 | 业务高可用的保障:异地多活架构

所解决的问题

无论是高可用计算架构,还是高可用存储架构,其本质的设计目的都是为了解决部分服务器故障的场景下,如何保证系统能够继续提供服务。但在一些极端场景下,有可能所有服务器都出现故障。例如,典型的有机房断电、机房火灾、地震、水灾……这些极端情况会导致某个系统所有服务器都故障,或者业务整体瘫痪,如果业务期望达到即使在此类灾难性故障的情况下,业务也不受影响,或者在几分钟内就能够很快恢复,那么就需要设计异地多活架构。

判断标准

判断一个系统是否符合异地多活,需要满足两个标准:

  • 正常情况下,用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务。
  • 某个地方业务异常的时候,用户访问其他地方正常的业务系统,能够得到正确的业务服务。

与“活”对应的是字是“备”,备是备份,正常情况下对外是不提供服务的,如果需要提供服务,则需要大量的人工干预和操作,花费大量的时间才能让“备”变成“活”。

代价

异地多活代价很高,具体表现为:

  • 系统复杂度会发生质的变化,需要设计复杂的异地多活架构。
  • 成本会上升,毕竟要多在一个或者多个机房搭建独立的一套业务系统。

因此,异地多活虽然功能很强大,但也不是每个业务不管三七二十一都要上异地多活。如果无法承受异地多活带来的复杂度和成本,是可以不做异地多活的,只需要做异地备份即可。

架构模式

根据地理位置上的距离来划分,异地多活架构可以分为同城异区、跨城异地、跨国异地。接下来我详细解释一下每一种架构的细节与优缺点。

同城异区

同城异区指的是将业务部署在同一个城市不同区的多个机房。例如,在北京部署两个机房,一个机房在海淀区,一个在通州区,然后将两个机房用专用的高速网络连接在一起。

同城的两个机房,距离上一般大约就是几十千米,通过搭建高速的网络,同城异区的两个机房能够实现和同一个机房内几乎一样的网络传输速度。这就意味着虽然是两个不同地理位置上的机房,但逻辑上我们可以将它们看作同一个机房,这样的设计大大降低了复杂度,减少了异地多活的设计和实现复杂度及成本。

那如果采用了同城异区架构,一旦发生新奥尔良水灾这种灾难怎么办呢?很遗憾,答案是无能为力。但我们需要考虑的是,这种极端灾难发生概率是比较低的,可能几年或者十几年才发生一次。其次,除了这类灾难,机房火灾、机房停电、机房空调故障这类问题发生的概率更高,而且破坏力一样很大。而这些故障场景,同城异区架构都可以很好地解决。因此,结合复杂度、成本、故障发生概率来综合考虑,同城异区是应对机房级别故障的最优架构。

优点:逻辑上可以将同城异区的多个机房看作同一个机房,减少设计和实现复杂度及成本

缺点:无法面对影响整个城市的极端灾难

跨城异地

跨城异地指的是业务部署在不同城市的多个机房,而且距离最好要远一些。例如,将业务部署在北京和广州两个机房,而不是将业务部署在广州和深圳的两个机房。 距离上比较远,才能有效应对新奥尔良水灾、美加大停电这类极端灾难事件。

跨城异地虽然能够有效应对极端灾难事件,但“距离较远”这点并不只是一个距离数字上的变化,而是量变引起了质变,导致了跨城异地的架构复杂度大大上升。距离增加带来的最主要问题是两个机房的网络传输速度会降低,光速真空传播大约是每秒30万千米,在光纤中传输的速度大约是每秒20万千米,再加上传输中的各种网络设备的处理,实际还远远达不到理论上的速度。

除了距离上的限制,中间传输各种不可控的因素也非常多。例如,挖掘机把光纤挖断、中美海底电缆被拖船扯断、骨干网故障等,这些线路很多是第三方维护,针对故障我们根本无能为力也无法预知。例如,广州机房到北京机房,正常情况下RTT(round-trip time,往返时延)大约是50毫秒左右,遇到网络波动之类的情况,RTT可能飙升到500毫秒甚至1秒,更不用说经常发生的线路丢包问题,那延迟可能就是几秒几十秒了。

以上描述的问题,虽然同城异区理论上也会遇到,但由于同城异区距离较短,中间经过的线路和设备较少,问题发生的概率会低很多。而且同城异区距离短,即使是搭建多条互联通道,成本也不会太高,而跨城异区距离太远,搭建或者使用多通道的成本会高不少。

跨城异地距离较远带来的网络传输延迟问题,给异地多活架构设计带来了复杂性,如果要做到真正意义上的多活,业务系统需要考虑部署在不同地点的两个机房,在数据短时间不一致的情况下,还能够正常提供业务。这就引入了一个看似矛盾的地方:数据不一致业务肯定不会正常,但跨城异地肯定会导致数据不一致。

如何解决这个问题呢?重点还是在“数据”上,即根据数据的特性来做不同的架构。如果是强一致性要求的数据,例如银行存款余额、支付宝余额等,这类数据实际上是无法做到跨城异地多活的。我们来看一个假设的例子,假如我们做一个互联网金融的业务,用户余额支持跨城异地多活,我们的系统分别部署在广州和北京,那么如果挖掘机挖断光缆后,会出现如下场景:

用户A余额有10000元钱,北京和广州机房都是这个数据。 用户A向用户B转了5000元钱,这个操作是在广州机房完成的,完成后用户A在广州机房的余额是5000元。 由于广州和北京机房网络被挖掘机挖断,广州机房无法将余额变动通知北京机房,此时北京机房用户A的余额还是10000元。 用户A到北京机房又发起转账,此时他看到自己的余额还有10000元,于是向用户C转账10000元,转账完成后用户A的余额变为0。 用户A到广州机房一看,余额怎么还有5000元?于是赶紧又发起转账,转账5000元给用户D;此时广州机房用户A的余额也变为0了。

最终,本来余额10000元的用户A,却转了20000元出去给其他用户。 对于以上这种假设场景,虽然普通用户很难这样自如地操作,但如果真的这么做,被黑客发现后,后果不堪设想。正因为如此,支付宝等金融相关的系统,对余额这类数据,一般不会做跨城异地的多活架构,而只能采用同城异区这种架构

而对数据一致性要求不那么高,或者数据不怎么改变,或者即使数据丢失影响也不大的业务,跨城异地多活就能够派上用场了。例如,用户登录(数据不一致时用户重新登录即可)、新闻类网站(一天内的新闻数据变化较少)、微博类网站(丢失用户发布的微博或者评论影响不大),这些业务采用跨城异地多活,能够很好地应对极端灾难的场景。

优点:可以很好地应对极端灾难

缺点:架构设计复杂,数据无法满足强一致性要求

跨国异地

跨国异地指的是业务部署在不同国家的多个机房。相比跨城异地,跨国异地的距离就更远了,因此数据同步的延时会更长,正常情况下可能就有几秒钟了。这种程度的延迟已经无法满足异地多活标准的第一条:“正常情况下,用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务”。例如,假设有一个微博类网站,分别在中国的上海和美国的纽约都建了机房,用户A在上海机房发表了一篇微博,此时如果他的一个关注者B用户访问到美国的机房,很可能无法看到用户A刚刚发表的微博。虽然跨城异地也会有此类同步延时问题, 但正常情况下几十毫秒的延时对用户来说基本无感知的;而延时达到几秒钟就感觉比较明显了。

因此,跨国异地的“多活”,和跨城异地的“多活”,实际的含义并不完全一致。跨国异地多活的主要应用场景一般有这几种情况:

  1. 为不同地区用户提供服务

    例如,亚马逊中国是为中国用户服务的,而亚马逊美国是为美国用户服务的,亚马逊中国的用户如果访问美国亚马逊,是无法用亚马逊中国的账号登录美国亚马逊的。

  2. 只读类业务做多活

    例如,谷歌的搜索业务,由于用户搜索资料时,这些资料都已经存在于谷歌的搜索引擎上面,无论是访问英国谷歌,还是访问美国谷歌,搜索结果基本相同,并且对用户来说,也不
    需要搜索到最新的实时资料,跨国异地的几秒钟网络延迟,对搜索结果是没有什么影响的。

思考题

假设我们做了高可用存储架构中的数据分区备份,又通过自动化运维能够保证1分钟就能将全部系统正常启动,那是否意味着没有必要做异地多活了?

备份系统平常没有流量,如果直接上线可能触发平常测试不到的故障。再实时的系统也会有数据延时,如果涉及到金融这种系统,仍然是不敢直接切换的。系统运行过程中会有很多中间数据,缓存数据等。系统不经过预热直接把流量倒过来,大流量会直接把系统拖垮。

谢谢小天使请我吃糖果
0%