【架构设计】27-业务高可用的保障:异地多活架构

应用场景

异地多活的关键点在于异地、多活,其中异地就是指地理位置上不同的地方,多活就是指不同地理位置上的系统都能够提供业务服务。判断一个系统是否异地多活,需要满足以下二个条件:

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

虽然异地多活很强大,能够保证灾难发生时业务都不受到影响。但是其代价非常的大。

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

因此,异地多活虽然很强大,但并不是什么业务都需要设计异地多活的。如果无法承受异地多活带来的复杂性和成本的话,是可以不做异地多活的,只要做异地备份就可以,比如新闻网站之类的。但是如果业务中断对用户影响非常大的话,就要做异地多活了,比如支付之类的。

当然,如果业务的体量非常大的话,能够做异地多活就尽量要做异地多活。因为这可以给用户带来更好的体验,同时对于体量非常大的系统,其延伸收入也非常大,可以减少异常场景带来的收入减少。

架构模式

根据地理位置上距离来划分,异地多活架构可以分为同城异区跨城异地跨国异地

同城异区

同城异区是指将系统部署在同一个城市的不同区的多个机房。例如在深圳部署二个机房,一个在南山区,一个在福田区,然后将二个机房用专用的高速网络连接起来。

对于一些极端的场景,如地震等,同城异区似乎没什么用。因为这些极端场景,可能使整个城市的网络都不可用。但为什么还要设计这种架构,其主要在于“同城”。

同城的二个机房,其距离不会太远,通过搭建专用的高速网络,同城的二个机房可以实现和同一个机房内几乎一样的网络传输速度。这就意味着,对于这二个地理位置不同的机房,在逻辑上我们可以看成是同一个机房,这可以降低设计的复杂性及成本。

采用同城异区架构,如果遇到特大的灾难是无能为力的。但是这种极端场景是很少发生的。除了这类灾难,机房火灾、机房停电、机房空调故障等情况发生的概念更高,而且破坏力一样大。针对这些场景,同城异区架构可以很好的解决。

跨城异地

跨城异地是将业务部署在不同城市的多个机房,而且距离最好远一点。比如北京和广州。而不是广州和深圳。

同城异区架构不能解决如新奥尔良水灾的问题,距离太近,又无法解决如加州停电这类问题,跨城异地就是为了解决这类问题,因此只有距离足够远才能解决这二类问题。

跨城异地虽然能够解决这类极端灾难问题,但是其复杂度大大提升。距离增加的主要问题有二个:网络传输速度会下降、中间传输中各种不可控的因素非常的多。如光纤挖断等,针对这种故障我们无法预知也无能为力。

以上二个问题同城异区也会遇到,但由于同城异区的距离短,中间经过的设备和线路也少,问题发生的概率比较低。而且同城异区距离短,即使搭建多条线路,成本也不会增加很多。而跨城异地,搭建多个通道的成本会高不少。

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

解决这个问题的关键在于“数据”,即根据数据的特性做不同的架构。如果是强一致性要求的数据的话,如银行卡余额等,如果用户余额做了跨城异地架构,部署在广州和北京机房,如果光缆被挖断后,会出现几下场景的问题:

  • 用户A余额有10000元钱,在广州和北京机房都是这个数据。
  • 用户A向用户B转了5000元,这个操作是在广州机房操作的完成的,完成后用户A在广州机房的余额是5000元。
  • 由于广州机房到北京机房的光缆被挖断,广州机房无法把余额同步到北京机房,此时北京机房用户A的余额是10000元。
  • 用户A又到北京机房进行转账,发现余额仍然是10000元,迅速转帐给用户C10000元,此时北京机房的用户A的余额是0元。但是无法同步到广州机房,广州机房的用户余额仍然是5000元。
  • 此时,用户A又到广州机房进行转账,发现余额还有5000元,赶紧转账给用户D5000元,此时广州机房的用户余额为0。

这个场景下,会发现用户A用10000的余额,转账了20000元。所以这种强一致性的数据,实际上是无法做跨城异地架构的。只能采取同城异区架构。

而对数据一致性要求不那么高,或者数据不怎么改变,或者即便数据丢失也影响不大的业务,跨城异地就可以使用了。例如:用户登录、新闻类网站、微博类网站。

跨国异地

跨国异地是指把业务部署在不同国家的多个机房。相比跨城异地架构,跨国异地的距离更远了,其数据同步延迟就更久了,正常情况下可能就有几秒钟。这种程度的延迟已经不满足“正常情况下,用户无论访问哪一个地点的业务系统,都能够得到正确的业务服务”。虽然跨城异地也有延迟,但是几毫秒的延迟对于用户来说是无感知的,但是延迟达到几秒就比较明显了。

跨国异地的“多活”和跨城异地的“多活”,其含义已经不太一样了。跨国异地多活的使用场景有以下几种:

  • 为不同地区用户提供服务
    例如:亚马逊中国是为中国用户提供服务。亚马逊美国是为美国用户提供服务。亚马逊中国的用户是无法登录亚马逊美国的。

  • 只读类业务的多活

    例如:谷歌的搜索服务,无论是访问英国谷歌还是美国谷歌,搜索的内容基本上是一致的,并且用户也不需要访问到实时的搜索结果,有几秒的延迟也不要紧。


   转载规则


《【架构设计】27-业务高可用的保障:异地多活架构》 孤独如梦 采用 知识共享署名 4.0 国际许可协议 进行许可。
 上一篇
【架构设计】46-架构重构内功心法第三式:运筹帷幄 【架构设计】46-架构重构内功心法第三式:运筹帷幄
46-架构重构内功心法第三式:运筹帷幄前言通常情况下,需要重构的系统,基本上都是因为各种历史原因和历史问题没有及时处理,遗留下来逐渐积累,然后到了一个临界点,各种问题开始互相作用,集中爆发。到了真正要开始重构的时候,架构师识别出系统关键的复
2019-05-29
下一篇 
【架构设计】44-架构重构内功心法第一式:有的放矢 【架构设计】44-架构重构内功心法第一式:有的放矢
44-架构重构内功心法第一式:有的放矢一般情况下,系统的架构是不断演化的,少部分架构演化可能需要推倒重来进行重定,但大部分的架构演化都是通过架构重构来实现的。相比全新的系统架构设计,架构重构要求更高: 业务已经上线,无法停下来 关联方众
2019-05-29
  目录