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

极客时间：《从 0 开始学架构》:业务高可用的保障：异地多活架构

1、引言

高可用计算架构还是高可用存储架构，其目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但也存在一些极端的情况，导致所有或大部分服务器出现故障，如断电、自然灾害等，业务也就会受到不同层次的影响，因此，需要设计异地多活架构。

2、应用场景

异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动、活跃的意思。判断一个系统是否符合异地多活，需要满足两个标准：

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

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

4、架构模式

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

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

• 跨城异地
  跨城异地指的是业务部署在不同城市的多个机房，而且距离最好要远一些。
  跨城异地距离较远带来的网络传输延迟问题，给异地多活架构设计带来了复杂性。因为距离的原因，跨城异地肯定会导致数据不一致。
  如何解决这个问题呢？重点还是在“数据”上，即根据数据的特性来做不同的架构。如果是强一致性要求的数据，例如银行存款余额、支付宝余额等，这类数据实际上是无法做到跨城异地多活的。而对数据一致性要求不那么高，或者数据不怎么改变，或者即使数据丢失影响也不大的业务，跨城异地多活就能够派上用场了

• 跨国异地
  跨国异地指的是业务部署在不同国家的多个机房。跨国异地多活的主要应用场景一般有这几种情况：

• 为不同地区用户提供服务

• 只读类业务做多活

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

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