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