架构设计内容分享(七)：100Wqps异地多活，得物是怎么架构的？

最新推荐文章于 2024-10-15 05:00:00 发布

之乎者也·

最新推荐文章于 2024-10-15 05:00:00 发布

阅读量1.9k

点赞数 21

分类专栏：架构设计内容分享文章标签：架构网络

本文链接：https://blog.csdn.net/qq_45038038/article/details/135083087

版权

架构设计内容分享专栏收录该内容

224 篇文章 80 订阅

订阅专栏

1. 什么是异地多活

异地多活的概念很多，像什么同城双活、两地三中心、三地五中心等等概念。

要想理解异地多活，需要从架构设计的3高原则说起。

架构设计的3高原则

现如今，开发一个软件系统，对其要求越来越高，如果你了解一些「架构设计」的要求，就知道一个好的软件架构应该遵循以下 3 个原则：

高性能
高并发
高可用

高性能意味着系统拥有更大流量的处理能力，更低的响应延迟。

例如 1 秒可处理 10W 并发请求，接口响应时间 5 ms 等等。

高并发表示系统在迭代新功能时，能以最小的代价去扩展，系统遇到流量压力时，可以在不改动代码的前提下，去扩容系统。

高可用通常用 2 个指标来衡量：

平均故障间隔 MTBF（Mean Time Between Failure）：表示两次故障的间隔时间，也就是系统「正常运行」的平均时间，这个时间越长，说明系统稳定性越高
故障恢复时间 MTTR（Mean Time To Repair）：表示系统发生故障后「恢复的时间」，这个值越小，故障对用户的影响越小

可用性与这两者的关系：

可用性（Availability）= MTBF / (MTBF + MTTR) * 100%

这个公式得出的结果是一个「比例」，通常我们会用「N 个 9」来描述一个系统的可用性。

从这张图你可以看到，要想达到 4 个 9 以上的可用性，一年的不可以时间为 52分钟，平均每天故障时间必须控制在 10 秒以内。

系统发生故障其实是不可避免的，尤其是规模越大的系统，发生问题的概率也越大。

这些故障一般体现在 3 个方面：

硬件故障：CPU、内存、磁盘、网卡、交换机、路由器
软件问题：代码 Bug、版本迭代
不可抗力：地震、水灾、火灾、战争

这些风险随时都有可能发生。所以，在面对故障时，我们的系统能否以「最快」的速度恢复，就成为了可用性的关键。

常见的多活方案

4 个 9 高可用的核心方案就是异地多活

异地多活指分布在异地的多个站点同时对外提供服务的业务场景。

异地多活是高可用架构设计的一种，与传统的灾备设计的最主要区别在于“多活”，即所有站点都是同时在对外提供服务的。

常见的多活方案有同城双活、两地三中心、三地五中心等多种技术方案，

常见方案1：同城双活

同城双活是在同城或相近区域内建立两个机房。同城双机房距离比较近，通信线路质量较好，比较容易实现数据的同步复制，保证高度的数据完整性和数据零丢失。

同城两个机房各承担一部分流量，一般入口流量完全随机，内部RPC调用尽量通过就近路由闭环在同机房，相当于两个机房镜像部署了两个独立集群，数据仍然是单点写到主机房数据库，然后实时同步到另外一个机房。

下图展示了同城双活简单部署架构，当然一般真实部署和考虑问题要远远比下图复杂。

服务调用基本在同机房内完成闭环，数据仍然是单点写到主机房数据储存，然后实时同步复制到同城备份机房。

当机房A出现问题时候运维人员只需要通过GSLB或者其他方案手动更改路由方式将流量路由到B机房。

同城双活可有效用于防范火灾、建筑物破坏、供电故障、计算机系统及人为破坏引起的机房灾难。

常见方案2：两地三中心

所谓两地三中心是指同城双中心 + 异地灾备中心。

异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，数据和服务平时都是冷的，

当双中心所在城市或者地区出现异常而都无法对外提供服务的时候，异地灾备中心可以用备份数据进行业务的恢复。

两地三中心方案特点

优势

服务同城双活，数据同城灾备，同城不丢失数据情况下跨机房级别容灾。

架构方案较为简单，核心是解决底层数据双活，由于双机房距离近，通信质量好，底层储存例如mysql可以采用同步复制，有效保证双机房数据一致性。

灾备中心能防范同城双中心同时出现故障时候利用备份数据进行业务的恢复。

劣势

数据库写数据存在跨机房调用，在复杂业务以及链路下频繁跨机房调用增加响应时间，影响系统性能和用户体验。

服务规模足够大(例如单体应用超过万台机器)，所有机器链接一个主数据库实例会引起连接不足问题。

出问题不敢轻易将流量切往异地数据备份中心，异地的备份数据中心是冷的，平时没有流量进入，因此出问题需要较长时间对异地灾备机房进行验证。

同城双活和两地三中心建设方案建设复杂度都不高，两地三中心相比同城双活有效解决了异地数据灾备问题，但是依然不能解决同城双活存在的多处缺点，想要解决这两种架构存在的弊端就要引入更复杂的解决方案去解决这些问题。

常见方案2：三地五中心

三地五中心和两地三中心的架构差不太多，这里不做展开，

异地多活3大挑战

1、数据同步延迟挑战

（1）应用要走向异地，首先要面对的便是物理距离带来的延时。

如果某个应用请求需要在异地多个单元对同一行记录进行修改，为满足异地单元间数据库数据的一致性和完整性，需要付出高昂的时间成本。

（2）解决异地高延时即要做到单元内数据读写封闭，不能出现不同单元对同一行数据进行修改，所以我们需要找到一个维度去划分单元。

（3）某个单元内访问其他单元数据需要能正确路由到对应的单元，例如A用户给B用户转账，A用户和B用户数据不在一个单元内，对B用户的操作能路由到相应的单元。

（4）面临的数据同步挑战，对于单元封闭的数据需全部同步到对应单元，对于读写分离类型的，我们要把中心的数据同步到单元。

2、单元化解耦挑战

所谓单元(下面我们用RZone代替)，是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。

单元化架构就是把单元作为系统部署的基本单位，在全站所有机房中部署数个单元，每个机房里的单元数目不定，任意一个单元都部署了系统所需的所有的应用。

单元化架构下，服务仍然是分层的，不同的是每一层中的任意一个节点都属于且仅属于某一个单元，上层调用下层时，仅会选择本单元内的节点。

选择什么维度来进行流量切分，要从业务本身入手去分析。

例如电商业务和金融的业务，最重要的流程即下单、支付、交易流程，通过对用户id进行数据切分拆分是最好的选择，买家的相关操作都会在买家所在的本单元内完成。

对于商家相关操作则无法进行单元化，需要按照下面介绍的非单元化模式去部署。

当然用户操作业务并非完全能避免跨单元甚至是跨机房调用，例如两个买家A和B转账业务，A和B所属数据单元不一致的时候，对B进行操作就需要跨单元去完成，后面我们会介绍跨单元调用服务路由问题。

3、流量的路由挑战

流量调度，系统部署过去后流量怎么跟着怎么过去。
流量自闭环。由于距离的原因，跨地域的物理延时是没法避免的，流量过去之后怎么保证所有的操作都在本地完成，如果做不到那怎么将这种延时影响降到最低。
容灾切流。当某个机房出现故障时，如何快速把流量无损地切至其他机房。这里并不是说简单把流量切过去就完事，由于数据在多区域同步，流量切过去之后能否保证数据的一致性？

2. 得物APP的异地多活改造

2.1得物APP异地多活基础改造

改造之前的单机房架构

了解改造点之前我们先来看下目前单机房的现状是什么样子，才能更好的帮助大家去理解为什么要做这些改造。

如上图所示，客户端的请求进来会先到SLB(负载均衡)，然后到我们内部的网关，通过网关再分发到具体的业务服务。

业务服务会依赖Redis, Mysql, MQ, Nacos等中间件。

改造之后的目标

既然做异地多活，那么必然是在不同地区有不同的机房，比如中心机房，单元机房。

所以我们要实现的效果如下图所示：

得物APP机房改造

得物多活改造一期目前有两个机房，分别是机房A和机房B。

A机房我们定义为中心机房，也就是多活上线之前正在使用的机房。

另一个B机房，在描述的时候可能会说成单元机房，那指的就是B机房。

得物APP单元化改造

得物多活进行了业务的单元改造，他们的业务比较单一，就是电商业务，所以：一个机房就是一个单元，或者说，一个单元就是一个机房，在这个单元内能够完成业务的闭环。

比如说用户进入APP，浏览商品，选择商品确认订单，下单，支付，查看订单信息，这整个流程都在一个单元中能够完成，并且数据也是存储在这个单元里面。

这块对他们的难度不大。

得物APP流量调度

用户的请求，从客户端发出，这个用户的请求该到哪个机房，这是得物APP要改造的第一个点。

没做多活之前，域名会解析到一个机房内，做了多活后，域名会随机解析到不同的机房中。

如果按照这种随机的方式是肯定有问题的，对于服务的调用是无所谓的，因为没有状态。

但是服务内部依赖的存储是有状态的呀。

得物APP是电商业务，用户在中心机房下了一个单，然后跳转到订单详情，这个时候请求到了单元机房，底层数据同步有延迟，一访问报个错：订单不存在。用户当场就懵了，钱都付了，订单没了。

所以针对同一个用户，尽可能在一个机房内完成业务闭环。

为了解决流量调度的问题，得物APP基于OpenResty二次开发出了DLB流量网关，DLB会对接多活控制中心，

DLB流量网关能够知道当前访问的用户是属于哪个机房，如果用户不属于当前机房，DLB会直接将请求路由到该用户所属机房内的DLB。

如果每次都随机到固定的机房，再通过DLB去校正，必然会存在跨机房请求，耗时加长。

所以在这块得物APP也是结合客户端做了一些优化，在DLB校正请求后，得物APP会将用户对应的机房IP直接通过Header响应给客户端。

这样下次请求的时候，客户端就可以直接通过这个IP访问。

如果用户当前访问的机房挂了，客户端需要降级成之前的域名访问方式，通过DNS解析到存活的机房。

2.2 RPC框架的异地多活改造

当用户的请求达到了单元机房内，理论上后续所有的操作都是在单元机房完成。

这就要求RPC请求落在就近的机房，那么，怎么知道单元机房的服务信息

所以得物APP的注册中心（Nacos）要做双向同步，这样才能拿到所有机房的服务信息。

不同的机房的Nacos，服务的注册信息采用双向复制，进行同步。

前面也提到了，用户的请求尽量在一个机房内完成闭环，当然，只是尽量，没有说全部。

这是因为有的业务场景不适合划分单元，比如库存扣减。

所以在得物APP的划分里面，有一个机房是中心机房，那些不做多活的业务只会部署在中心机房里面，那么库存扣减的时候就需要跨机房调用。

对于单元服务会存在多个机房的服务信息，如果不进行控制，则会出现调用其他机房的情况，所以RPC框架要进行改造。

2.2.1 定义RPC路由类型

默认路由

请求到中心机房，会优先调用中心机房内的服务，如果中心机房无此服务，则调用单元机房的服务，如果单元机房没有此服务则直接报错。

单元路由

请求到单元机房，那么说明此用户的流量规则是在单元机房，接下来所有的RPC调用都只会调用单元机房内的服务，没有服务则报错。

中心路由

请求到单元机房，那么直接调用中心机房的服务，中心机房没有服务则报错。请求到中心机房，那么就本机房调用。

2.2.2 业务RPC改造

业务方需要对自己的接口（Java interface）进行标记是什么类型，是单元路由，还是中心路由，通过@HARoute加在接口上面。

标记完成后，在Dubbo接口进行注册的时候，会把路由类型放入到这个接口的元数据里面。

在Nacos后台可以查看Dubbo接口的路由类型，这些数据，也是RPC路由异地多活改造的核心参数。

后面通过RPC调用接口内部所有的方法都会按照标记类型进行路由。

比如，单元路由的RPC，RPC在路由的时候会根据这个值判断用户所在的机房。

路由逻辑如下：

RPC 接口复制一份，命名为UnitApi，带上路由参数。在新接口的实现里面调用老接口，新旧接口共存。

2.2.4 遇到的问题

1 其他场景切单元接口

除了RPC直接调用的接口，还有一大部分是通过Dubbo泛化过来的，这块在上线后也需要将流量切到UnitApi，等老接口没有请求量之后才能下线。

2 接口分类整改

接口进行分类，之前没有多活的约束，一个Java interface中的方法可能各种各样，所以需要进行rpc

接口的分类整改

3 业务层面调整

业务层面调整，比如之前查询订单只需要一个订单号，但是现在需要路由参数，所以接入这个接口的上游都需要调整。

2.3 数据库的异地多活

请求顺利的到达了服务层，接下来要跟数据库打交道了。

数据库得物APP定义了不同的类型，定义如下：

1 单元化

此库为单元库，会同时在两个机房部署，每个机房都有完整的数据，数据采用双向同步。

2 中心化

此库为中心库，只会在中心机房部署。

3 中心单元化

此库为中心单元库，会同时在两个机房部署，中心可以读写，其他机房只能读。

中心写数据后单向复制到另一个机房。

2.3.1 DB-Proxy代理中间件

异地多活之前，得物内部的各大服务，都是客户端形式的Sharding中间件，客户端模式访问分库分表，

要命的是，每个业务方的版本还不一致。

在多活切流的过程中需要对数据库禁写来保证业务数据的准确性，如果没有统一的中间件，这将是一件很麻烦的事情。

所以得物APP调整为 proxy模式，去掉 client模式的分库分表访问。

得物APP 通过对ShardingSphere进行深度定制，二次开发数据库代理proxy中间件，彩虹桥。

有了proxy组件之后，各业务方替换之前的Sharding Client方式。

2.3.2 分布式ID

单元化的库，数据层面会做双向同步复制操作。如果直接用表的自增ID则会出现下面的冲突问题：

得物APP采用了一种一劳永逸的方式，接入全局唯一的分布式ID来避免主键的冲突。

所以，分布式ID绝对是分库分表的核心技术要点，如果做到高并发、高性能、防止倾斜，绝对是一大核心的技术难题

2.3.3 使用OTTER进行数据同步

OTTER是阿里巴巴公司为了解决杭州/美国机房数据间同步研发的一个开源软件。

OTTER基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库，是一个分布式数据库同步系统。

工作原理图：

原理描述：

基于Canal开源产品，获取数据库增量日志数据。

典型管理系统架构，manager(web管理)+node(工作节点)

a. manager运行时推送同步配置到node节点
b. node节点将同步状态反馈到manager上

基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作

2.3.4 业务改造

在Dao层对表进行操作的时候，会通过ThreadLocal设置当前方法的ShardingKey，然后通过Mybatis拦截器机制，将ShardingKey通过Hint的方式放入SQL中，带给彩虹桥。

彩虹桥会判断当前的ShardingKey是否属于当前机房，如果不是直接禁写报错。

这里跟大家简单的说明下为什么切流过程中要禁写，这个其实跟JVM的垃圾回收有点相似。如果不对操作禁写，那么就会不断的产生数据，而得物APP切流，一定要保证当前机房的数据全部同步过去了之后才开始生效流量规则，否则用户切到另一个机房，数据没同步完，就会产生业务问题。除了彩虹桥会禁写，RPC框架内部也会根据流量规则进行阻断。

2.3.5 遇到的问题

1 单元接口中不能访问中心数据库

如果接口标记成了单元接口，那么只能操作单元库。

在以前没有做多活改造的时候，基本上没有什么中心和单元的概念，所有的表也都是放在一起的。

多活改造后，得物APP会根据业务场景对数据库进行划分。

划分后，中心库只会被中心机房的程序使用，在单元机房是不允许连接中心库。

所以单元接口里面如果涉及到对中心库的操作，必定会报错。

这块需要调整成走中心的RPC接口。

2 中心接口不能访问单元数据库

跟上面同样的问题，如果接口是中心的，也不能在接口里面操作单元库。中心接口的请求都会强制走到中心机房，如果里面有涉及到另一个机房的操作，也必须走RPC接口进行正确的路由，

因为你中心机房不能操作另一个机房的数据库。

3 批量查询调整

比如批量根据订单号进行查询，但是这些订单号不是同一个买家。

如果随便用一个订单的买家作为路由参数，那么其他一些订单其实是属于另一个单元的，这样就有可能存在查询到旧数据的问题。

这样批量查询的场景，只能针对同一个买家可用，如果是不同的买家需要分批调用。

2.4 Redis 的异地多活

Redis在业务中用的比较多，在多活的改造中也有很多地方需要调整。

对于Redis首先得物APP明确几个定义：

不做双向同步

Redis不会和数据库一样做双向同步，也就是中心机房一个Redis集群，单元机房一个Redis集群。

每个机房的集群中只存在一部分用户的缓存数据，不是全量的。

Redis类型

Redis分为中心和单元，中心只会在中心机房部署，单元会在中心和单元两个机房部署。

2.4.1 业务改造

1 Redis多数据源支持

多活改造前，每个应用都有一个单独的Redis集群，

多活改造后，由于应用没有进行单元化和中心的拆分，所以一个应用中会存在需要连接两个Redis的情况。

一个中心Redis，一个单元Redis。

基础架构组提供的专用Redis Client包，需要支持多数据源的创建，

基础包中并且定义通用的配置格式，业务方只需要在自己的配置里面指定集群和连接模式即可完成接入。

spring.redis.sources.carts.mode=unit 
spring.redis.sources.carts.cluster-name=cartsCuster

具体的Redis实例信息会在配置中心统一维护，不需要业务方关心，

在做机房扩容的时候，业务方是不需要调整的

2 数据一致性

缓存和缓存之间，不进行同步，没有数据一致性问题

缓存和DB之间，使用binlog 进行同步

这里得物APP的方案是采用订阅数据库的binlog来进行缓存的失效操作，可以订阅本机房的binlog，也可以订阅其他机房的binlog来实现所有机房的缓存失效。

使用 binlog 进行同步的实操，非常重要

2.4.2 遇到的问题

1 序列化协议兼容

在接入新的Redis Client包后，测试环境出现了老数据的兼容问题。

有个别应用自己定制了序列化方式，导致Redis按新的方式装配后没有用到自定义的协议，这块也是进行了改造，支持多数据源的协议自定义。

2 分布式锁的使用

目前项目中的分布式锁是基于Redis实现，当Redis有多个数据源之后，分布式锁也需要进行适配。

在使用的地方要区分场景，默认都是用的中心Redis来加锁。

但是单元接口里面的操作都是买家场景，所以这部分需要调整为单元Redis锁对象进行加锁，这样能够提高性能。其他的一些场景有涉及到全局资源的锁定，那就用中心Redis锁对象进行加锁。

2.5 RocketMQ异地多活

所以MQ跟数据库一样，也要做同步，将消息同步到另一个机房的MQ中，至于另一个机房的消费者要不要消费，这就要让业务场景去决定。

2.5.1 定义消费类型

1 中心订阅

中心订阅指的是消息无论是在中心机房发出的还是单元机房发出的，都只会在中心机房进行消费。

如果是单元机房发出的，会将单元的消息复制一份到中心进行消费。

2 普通订阅

普通订阅就是默认的行为，指的是就近消费。在中心机房发送的消息就由中心机房的消费者进行消费，在单元机房发送的消息就由单元机房的消费进行消费。

3 单元订阅

单元订阅指的是消息会根据ShardingKey进行消息的过滤，无论你在哪个机房发送消息，消息都会复制到另一个机房，此时两个机房都有该消息。通过ShardingKey判断当前消息应该被哪个机房消费，符合的才会进行消费，不符合的框架层面会自动ACK。

4 全单元订阅

全单元订阅指的是消息无论在哪个机房发出，都会在所有的机房进行消费。

2.5.2 业务改造

1 消息发送方调整

消息发送方，需要结合业务场景进行区分。如果是买家场景的业务消息，在发消息的时候需要将"多活路由Key"放入消息中，具体怎么消费由消费方决定。

如果消费方是单元消费的话那么必须依赖发送方的"多活路由Key"，否则无法知道当前消息应该在哪个机房消费。

2 消息消费方指定消费模式

前面提到了中心订阅，单元订阅，普通订阅，全单元订阅多种模式，到底要怎么选就是要结合业务场景来定的，定好后在配置MQ信息的时候指定即可。

比如中心订阅就适合你整个服务都是中心的，其他机房都没部署，这个时候肯定适合中心订阅。

比如你要对缓存进行清除，就比较适合全单元订阅，一旦数据有变更，所有机房的缓存都清除掉。

2.5.3 遇到的问题

1 消息幂等消费

就算不做多活，消息消费场景，肯定是要做幂等处理的，因为消息本身就有重试机制。

单独拎出来说是在切流的过程中，属于切流这部分用户的消息会被复制到另一个机房重新进行消费，

解释下为什么切流过程中会有消息消费失败以及需要复制到另一个机房去处理，如下图所示：

用户在当前机房进行业务操作后，会产生消息。由于是单元订阅，所以会在当前机房进行消费。

消费过程中，发生了切流操作，消费逻辑里面对数据库进行读写，但是单元表的操作都携带了ShardingKey，彩虹桥会判断ShardingKey是否符合当前的规则，发现不符合直接禁写报错。

这批切流用户的消息就全部消费失败。

等到流量切到另一个机房后，如果不进行消息的重新投递，那么这部分消息就丢失了，这就是为什么要复制到另一个机房进行消息的重新投递。

2 切流场景的消息顺序问题

上面讲到了在切流过程中，会将消息复制到另一个机房进行重新消费，然后是基于时间点去回放的，如果你的业务消息本身就是普通的Topic，

在消息回放的时候如果同一个场景的消息有多条，这个顺序并不一定是按照之前的顺序来消费，所以这里涉及到一个消费顺序的问题。

如果你之前的业务场景本身就是用的顺序消息，那么是没问题的，如果之前不是顺序消息，这里就有可能有问题，我举个例子说明下：

解决方案有下面几种：

Topic换成顺序消息，以用户进行分区，这样就能保证每个用户的消息严格按照发送顺序进行消费
对消息做幂等，已消费过就不再消费。但是这里跟普通的消息不同，会有N条消息，如果对msgId进行存储，这样就可以判断是否消费过，但是这样存储压力太大，当然也可以只存储最近N条来减小存储压力。
消息幂等的优化方式，让消息发送方每发送一次，都带一个version，version必须是递增。消费方消费消息后把当前version存储起来，消费之前判断消息的version是否大于存储的version，满足条件才进行消费，这样既避免了存储的压力也能满足业务的需求。