# 27-业务高可用的保障：异地多活架构

# 应用场景

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

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

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

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

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

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

# 架构模式

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

# 同城异区

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

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

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

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

# 跨城异地

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

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

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

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

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

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

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

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

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

# 跨国异地

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

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

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

• 只读类业务的多活

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