【云驻共创】异地多活是什么？如何实现？

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

一、多活架构概述

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

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

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

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

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

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

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

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

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

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

三、异地多活设计

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

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

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

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

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

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

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

  

四、总结

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

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

本文参与华为云社区【内容共创】活动第19期。
https://bbs.huaweicloud.com/blogs/370132

任务31：异地多活是什么？如何实现？