极客时间：《从 0 开始学架构》:业务高可用的保障：异地多活架构
1、引言
高可用计算架构还是高可用存储架构，其目的都是为了解决部分服务器故障的场景下，如何保证系统能够继续提供服务。但也存在一些极端的情况，导致所有或大部分服务器出现故障，如断电、自然灾害等，业务也就会受到不同层次的影响，因此，需要设计异地多活架构。
2、应用场景
异地多活架构的关键点就是异地、多活，其中异地就是指地理位置上不同的地方；多活就是指不同地理位置上的系统都能够提供业务服务，这里的“活”是活动、活跃的意思。判断一个系统是否符合异地多活，需要满足两个标准：
- 正常情况下，用户无论访问哪一个地点的业务系统，都能够得到正确的业务服务。
- 某个地方业务异常的时候，用户访问其他地方正常的业务系统，能够得到正确的业务服务。
PS:异地多活虽然功能很强大，但也不是每个业务不管三七二十一都要上异地多活。
4、架构模式
根据地理位置上的距离来划分，异地多活架构可以分为同城异区、跨城异地、跨国异地。
-
同城异区
同城异区指的是将业务部署在同一个城市不同区的多个机房。 -
跨城异地
跨城异地指的是业务部署在不同城市的多个机房，而且距离最好要远一些。
跨城异地距离较远带来的网络传输延迟问题，给异地多活架构设计带来了复杂性。因为距离的原因，跨城异地肯定会导致数据不一致。
如何解决这个问题呢？重点还是在“数据”上，即根据数据的特性来做不同的架构。如果是强一致性要求的数据，例如银行存款余额、支付宝余额等，这类数据实际上是无法做到跨城异地多活的。而对数据一致性要求不那么高，或者数据不怎么改变，或者即使数据丢失影响也不大的业务，跨城异地多活就能够派上用场了 -
跨国异地
跨国异地指的是业务部署在不同国家的多个机房。跨国异地多活的主要应用场景一般有这几种情况： -
为不同地区用户提供服务
-
只读类业务做多活
假设我们做了前面提到的高可用存储架构中的数据分区备份，又通过自动化运维能够保证 1 分钟就能将全部系统正常启动，那是否意味着没有必要做异地多活了？
备份系统平常没有流量，如果直接上线可能触发平常测试不到的故障。
在实时的系统也会有数据延时，如果涉及到金融这种系统，仍然是不敢直接切换的。
系统运行过程中会有很多中间数据，缓存数据等。系统不经过预热直接把流量倒过来，大流量会直接把系统拖垮