聊聊异地多活成熟的架构模式
你好，我是华仔。
2018年专栏推出的时候，关于异地多活架构这部分，我们讲解了物理部署上的三种模式，分别是同城异区、跨城异地和跨国异地，也详细介绍了根据业务特点设计异地多活架构的4个步骤和4大技巧。6年时间过去了，业界相关技术在不断发展，异地多活架构设计也逐渐成熟。
基于此，这一节我们就一起来看一下目前业界成熟的异地多活架构模式，包括业务定制型、业务通用型和存储通用型三种。
异地多活架构总体思路
在详细介绍三种异地多活架构模式之前，我们先来整体看看异地多活架构设计的思路。异地多活架构虽然复杂，不同的架构模式用到的技术和方案也不尽相同，但总体来说，异地多活架构设计的思路是相通的，基本都可以总结为下图：
不管我们采取什么样的技术和手段来实现异地多活架构，总体上都可以把异地多活架构设计分为三部分：网络架构、计算架构和存储架构。我们简单介绍下：
- 网络架构：系统如何调度流量，包括网络流量调度和业务流量调度。其中，网络流量调度采用传统的DNS/GSLB等设备来实现将请求流量分配到多个异地机房，业务流量调度需要基于业务规则（例如用户归属机房）来将请求路由到指定的机房。
- 计算架构：系统如何冗余计算资源，是静态分配（比较浪费钱），还是动态生成（实现比较复杂，可能有风险）。
- 存储架构：关键业务数据如何同步，如何保证一致性，如何处理故障时数据不一致对业务的影响。
了解了总体思路，我再来看具体的架构模式长什么样。
业务定制型异地多活架构模式
业务定制型异地多活架构模式就是专栏中讲的异地多活架构模式，虽然6年过去了，技术也在不断发展，但这个模式并没有过时。不管你的系统是否上云或是否实现了云原生，这个模式现在依然可行。
业务定制型异地多活的核心思想是“定制”，需要根据业务的特点和数据的特点来设计专属的异地多活架构方案，其原理示意图如下：
业务定制型异地多活架构有两个关键设计点。一是按照业务的优先级进行排序，优先保证核心业务异地多活。例如，用户中心的业务分为“注册”“登录”“用户信息管理”等业务，当我们要实现用户中心的异地多活时，应该优先实现“登录”业务，“注册”和“用户信息管理”可以不实现。
二是基于核心业务的流程和数据，设计定制化的异地多活架构。例如上图中A业务的数据用“数据库 + 消息队列”的方式实现关键数据快速同步，以及B业务的数据用“CDC（Change Data Capture）+ 算法”的方式实现数据双写。
业务定制型异地多活架构模式的主要优点有3个：
- 对基础设施无强要求（例如机房部署、存储系统、时延等），支持部署在远距离的两个城市，可以应对区域级别故障和灾难。
- 复杂度相对来说低一些，因为可以针对具体业务进行特殊处理。
- 落地成本比较低。硬件成本以异地双活为例，两个机房各自冗余50%资源即可。而且，也无需投入人力开发大量的配套系统，故障时在网络层面整体切换流量到正常机房即可。
但是，这种业务定制型异地多活架构模式也有缺点。首先是不通用，每个业务都需要单独来做异地多活，业务需要改造。例如我之前公司的游戏接入、游戏商店、浏览器业务等，都要自己分别实现异地多活架构。其次是难扩展，核心业务如果有重大变化，异地多活方案要重新设计。例如微博本来是图文为主，如果要改成短视频为核心，则异地多活方案要重新设计。
业务定制型异地多活架构模式比较适合业务规模不大，业务不是很复杂，业务数量也不多的企业和团队，例如我之前做的阿里游戏异地多活架构就属于这种模式。
业务通用型异地多活架构模式
业务通用型异地多活架构模式旨在提供通用的异地多活架构，避免对业务进行大量定制化的改造，其核心思想是通过配套服务来实现异地多活，无需按照业务优先级排序来筛选业务。只要业务支持BASE（最终一致性）就可以实现异地多活部署，如果业务必须强一致性就采用中心化部署。其基本原理如下：
不同的业务都基于统一的配套服务来实现异地多活的能力，常见的配套服务包括流量调度、配置中心、建站中心和数据同步。我们一一来看。
流量调度指的是在网络环境中，通过特定的算法、策略以及相关技术工具，对不同来源的业务流量进行合理分配与引导，使其流向不同的目标节点，比如服务器、数据中心等。目的在于优化资源利用、提升系统性能、保障服务质量以及应对诸如高并发、故障等各类情况，确保业务的顺畅运行。
简单的异地多活流量调度主要是网络流量调度，复杂的流量调度除了网络流量调度外，还可以调度微服务应用到数据库、存储系统的流量。
配置中心是集中管理应用程序配置信息的平台。在分布式系统等复杂架构里，众多服务模块往往有着各式各样的配置参数，像数据库连接配置、缓存配置等。配置中心能将这些分散的配置统一存储、管理，并支持动态更新，使得各服务模块可以便捷地获取最新配置，有助于提高系统的可维护性、灵活性以及配置管理的效率。
当需要进行异地多活切换或者接管的时候，配置中心起着关键作用。如果没有配置中心统一管理相关信息，快速接管和恢复就无从谈起。
建站平台通过容器化的相关技术，在多活故障切换的时候，临时申请相关硬件和软件资源，快速创建并运行相关的微服务应用来处理业务请求。有了建站平台，正常运行时就不需要冗余太多相关资源，能够大大降低整体运行成本，故障时又可以快速搭建业务处理系统接管流量，实现异地多活架构。
建站平台的关键基础系统是配置中心，只有基于完善的配置中心才能实现快速建站的目标。
最后是数据同步。数据同步服务通过提供统一的底层数据同步工具或者系统，实现不同存储介质、系统或者数据中心间的数据同步，确保异地多活架构下多个数据中心的数据一致性。我们可以采用多种手段实现数据同步，例如数据库复制、消息队列、CDC（Change Data Capture）等方式，实时或者定时地将数据变动进行传递，让不同位置的数据副本能及时更新。
需要注意的是，远距离（两地时延超过30ms）的数据同步不管采用什么技术手段，本质上都是最终一致性。
基于此，业务通用型异地多活架构模式有2大优点：
- 对硬件基础设施无强要求，例如机房部署、存储系统、时延等，一般部署在远距离的两个城市，可以支持区域级别故障处理。
- 业务基本不用改造，只需判断业务是否支持BASE，支持就可以异地多活，不支持就单点部署。
然而，该模式也并非十全十美，缺点主要有3个：
- 配套服务复杂，包括流量调度、容灾切换、建站平台、配置管理、数据同步等。
- 存在全局单点业务，例如库存、卖家等相关业务。
- 配套服务的开发成本比较高，需要专门的团队研发和维护。
总之，业务通用型异地多活架构模式比较适合业务数量多、业务强一致性要求不高的大公司，因为只有支持多个业务实现异地多活架构，配套服务才能发挥最大的价值。目前业界比较知名的异地多活架构方案中，淘宝和支付宝的单元化架构（也叫LDC架构，Logic Data Center）就属于这类。
存储通用型异地多活架构模式
存储通用型异地多活架构模式是一种新型异地多活架构模式，它随着最近几年分布式一致性数据库的发展而兴起，其核心思想是采用本身已经支持分布式一致性的存储系统，架构上天然支持异地多活。其基本原理如下：
整个架构设计的关键是采用了底层支持分布式一致性的存储系统，这些存储系统底层通过分布式一致性算法（Raft、Paxos等）来保障数据在多个节点间的强一致性。即使面对网络分区、节点故障等复杂情况，只要不是极端情况下多个机房同时故障，就可以确保系统整体处于可用且数据一致的状态。业务层可以放心地对数据进行读写操作，无需担忧数据不一致引发的业务错误。
这种架构模式的主要优点有2个，很好理解。
- 架构天然就支持异地多活，业务除了切换存储系统外，其它基本不用改造。
- 支持数据强一致性，适合金融交易等要求高的复杂业务场景。
接下来，我们详细说下该模式的主要缺点。首先，需要分布式一致性的存储系统支持。目前这样的存储系统可选不多，有ZooKeeper、etcd、OceanBase和TiDB。其中，ZooKeeper和etcd不支持大规模的数据存储，而OceanBase和TiDB是数据库存储系统，目前应用比较多。
其次，对机房部署有强要求。如果要实现异地多活，只能采用近邻部署，因为分布式一致性算法如果要保证性能的话，底层的时延越低越好，目前的经验数据是不要超过10ms。国内目前支持这种部署的城市主要有4组：北京+天津、广州+深圳、成都+重庆、上海+杭州。
最后是成本比较高，为了支持分布式一致性存储，需要采用“两地三中心”甚至“三地五中心”的部署模式。
总的来说，存储通用型异地多活架构模式比较适合对数据一致性、灾难恢复有强要求的业务，例如金融电信等，像网商银行的异地多活架构底层就采用了OceanBase存储系统。
小结
这一节，我们重点讲解了异地多活架构的三种模式。业务定制型异地多活架构需要基于核心业务的特点进行定制化设计，适合业务规模不大，业务不复杂的企业。业务通用型异地多活架构模式需要打造强大的配套服务来实现异地多活架构，比较适合业务数量多、业务强一致性要求不高的大公司。存储通用型异地多活架构模式通过采用分布式一致性的存储系统来实现异地多活架构，比较适合对数据一致性、灾难恢复有强要求的金融电信等业务。
思考题
以上就是今天的全部内容，最后留一道思考题给你吧：如果让你来设计一个用户量1亿的短视频平台的异地多活架构，哪种模式比较好？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
- 千锤百炼领悟之极限 👍（0） 💬（1）
思考题，因为短视频不需要强一致性，首先排除存储通用型。用户数量是1亿，业务有优先级，存在核心业务，觉得使用业务定制型。
2025-01-31