异地多活架构是什么?如何设计及实现?

随着数字信息化的推进,对系统及平台的依赖性越来越高,尤其是重要的业务系统,稳定的持续化的服务能力尤为重要,也就是我们常说的高可用,一般有主备、主从、多主、同城灾备、同城多活、异地灾备、异地多活等架构设计,异地多活就是高可用一个高级实践。

一、多活架构概述

软件系统高可用一直是架构设计必须要考虑的功能,只是在软件生命周期的不同节点,采用的架构不同,比如:

  • 项目初期,我们可能只是数据库的主备模式,在主数据库发生错误时,我们及时的把备数据库还原,就可以继续使用,但主备方式一般不及时,会有一部分数据丢失,对数据完整性要求严格的项目一般不采用这种方式。

  • 项目发展中期,可以采用主从、高可用模式,这个模式一般是近实时同步,在发生事故时,我们可以及时的切换,可以无缝的切换不间断的提供服务,同时业务服务这个时期也应该考虑高可用。

  • 项目稳定期,项目、平台成熟稳定后,高可用性应该是首要任务,可以考虑多同城多IDC,同城多IDC基本上已经足够支持大多数意外情况,在同城网络延迟也不会波动太大,但毕竟在同一个城市,比如洪灾的发生,所以等项目平台稳定后,为了提高高可用性,异地多活是绕不过的一个方案。但这个方案实现起来难度非常大,考虑的因素也非常多,所以一般采用逐步迭代的方式,最终实现全平台的异地多活。

异地多活架构是什么?如何设计及实现?_第1张图片

二、软件架构3个重要指标

软件架构设计中,针对架构设计的好坏,是否经得住业务的快速发展而带来的冲击,主要考虑三方面

  • 高性能,高性能主要表现为TPS、QPS,单位时间内处理的越多性能越好,主要是跟业务逻辑代码实现、通讯协议、数据库及基础资源有关

  • 易扩展,表现在版本迭代、功能扩展、中间件替换及系统对接的难易程度,主要跟架构规划阶段对业务的理解、扩展性预留出足够灵活的接口,尽量降低模块间、系统间的耦合度,采用通用的对接协议、数据结构为扩展做好足够的预备方案

  • 高可用,高可用是存在感最低的一个指标,因为在正常情况下,往往被忽视,高可用是持续服务的能力,尽量不因外界因素,影响平台的正常使用,这对重要的业务系统显得非常重要。

高可用常见的落地方式有主备、主从、同城多活、异地多活等方式,但难度逐步增加,同时提供的高可用性也逐渐提高。

异地多活架构是什么?如何设计及实现?_第2张图片

三、异地多活设计

在我们的架构设计中,多活,主要涉及到应用、服务、存储层,异地多活也基本是这3个层面的多活。

  • 应用端多活目前实现起来并不复杂,部署的时候只要保持多中心同时部署即可,只要保持多地应用端文件一致性即可,一般没有多大问题。

  • 服务层多活就有些麻烦,需要根据存储层提供的能力进行相应的调整。

    • 存储层主从方式,这种方式服务层就需要处理CUD进行路由到主节点操作,同时主节点进行实时的同步到从节点,如果R操作,直接进行本地存储层操作,一般这种方式会考虑使用中间件进行中转,同时加上数据校对,也就是我们常说的最终一致性,如果业务上对数据一致性要求比较严格,可以采用2PC、3PC方式进行。

    • 存储层是主主方式,比如MySql就有主主模式,哪服务层可以直接进行本地就行操作,有存储实现两地数据的同步。

    • 通过中间件方式,如果存储没有自己的多数据中心同步机制,需要通过开发中间件来实现,比如常见的Redis多中心同步工具XRedis、MongoDB跨机房副本集同步工具MongoShake。服务层一般只需要进行少量的适配就可以。

  • 存储层在异地多活实现中,是重点考虑的一个点,因为应用层、服务层基本都是无状态的实现起来比较容易,但存储是有状态的,在异地多活中,常常需要特殊处理,如果自身没有多中心同步机制功能,那就需要开发来实现,同时考虑异地、跨中心带来的网络延迟影响性能。

    异地多活架构是什么?如何设计及实现?_第3张图片

四、总结

异地多活是架构设计中比较难实现的一点,但也是非常重要的一环,在架构设计中前期最好能考虑到这一点,提前在技术选型、方案设计中往异地多活这边考虑,这样在需要时,可以轻松一些实现。但尽管这样,异地多活也是不容易实现,属于架构设计中比较高级的阶段,而且并没有多少通用的方案,大部分都是根据具体的业务需求进行设计。

如果有异地多活方面的问题,欢迎留言或者私信沟通。

你可能感兴趣的:(资深架构师技术分享,云原生,低代码开发,架构,数据库,中间件)