微服务高可用容灾架构设计

导语

相对于过去单体或 SOA 架构，建设微服务架构所依赖的组件发生了改变，因此分析与设计高可用容灾架构方案的思路也随之改变，本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。

作者简介

刘冠军

腾讯云中间件中心架构组负责人、专家工程师

15年 IT 从业经验，第一份工作服务于 IBM 中国实验室，曾任职 IBM 大型机中间件研发总监。现任腾讯云专家工程师，中间件中心架构组负责人，负责中间件产品中心架构师团队及 PaaS 平台产品售前工作。共获得16项专利授权，在事务处理、web 服务、微服务、消息队列和银行架构等方面有着丰富经验，支持过国内外多家大中型客户。

概述

相对于 SOA 架构，微服务架构使用去中心化的方式组织业务应用，服务之间的通信不需要经过总线，服务路由的逻辑下发到各个微服务中自行完成。另一方面，微服务架构也离不开中心化的组件实现服务治理、应用部署、监控等功能，微服务场景下主备、多活等高可用容灾方案的设计需要通盘考虑。

在分析复杂的容灾架构前，我们首先应当明确问题的定义，拆解问题，分解子问题，从不同维度分开讨论才能获得一个清晰的结论。当我们讨论主备、双活等高可用模式时，不同的高可用模式对于应用、数据库、注册中心等组件的含义不是一样的，但各组件又相互关联。在笔者看来，一个完整的微服务架构组件包含三个维度：

1、微服务管控层：由于分布式架构带来了复杂性，需要引入相关的分布式支撑组件。

• 应用生命周期管理组件：负责应用发布、回滚、弹性伸缩、故障转移，微服务架构对部署运维能力有更高的要求，要求业务能够实现交付设施自动化。该部分组件对业务运行时影响比较小。
• 服务治理组件：负责服务注册发现、服务配置、服务路由等分布式治理能力，其中最为人熟知的组件是服务注册中心，注册中心负责对服务进行健康检查，及时摘除异常实例，因此在容灾模式下对网络要求比较高，如果网络不稳定容易导致健康检查不准确，频繁进行大规模服务实例变更通知，影响系统稳定性。
• 监控组件：负责采集可观测性三大件 Trace, Log, Metrics，底层往往使用 ES 或者时序数据库，由于这部分组件请求数据量比较大，在规划部署时，网络流量的成本应当被纳入考量。

2、应用层：应用尽量无状态化，降低部署的难度。

3、数据层：目前大多数应用使用关系型数据库，当前关系型数据库的技术水平还不能很好的支持多实例多写，所以对于数据库只能讨论主备模式，关键点在于主备切换的自动化以及数据复制的延迟，分别降低故障恢复的 RTO 与 RPO。

同城主备

同城主备（Active-Standby）往往是双 AZ 部署，AZ 间距离需要满足监管要求。双 AZ 同时只有一个主 AZ 对外提供服务，另一个备 AZ 用做备份，往往只需要部署少量资源。

部署方案：

• 微服务管控层：TSF 一主一备，服务注册发现，应用发布、监控等都在 AZ 内闭环。
• 应用层：应用一主一备，备中心包含主中心逻辑上的全量应用，应用副本数可缩减。
• 数据库层：一主多从，强同步复制，使用 TDSQL 的 RPO 和 RTO 可达到0，并且应用能够无感知切换。

应用层异常分析

对应用层几种异常场景进行分析： 1、单个微服务实例故障：微服务需要做多实例部署，单 AZ 内可容错。

2、某个微服务的所有实例故障，可能原因有两种：

• 应用本身代码有问题：回滚应用或进行修复；
• 某个微服务的所有物理实例故障：利用 LaaS 层节点反亲和，尽量机架间分散部署实例。

3. 整个 AZ 所有实例故障：这种情况整体启用备 AZ，切换用户流量。

微服务管控层异常分析

TSF 微服务管控层可以分为两个层次： 1、发布时组件：主要影响应用的发布功能，组件故障影响应用的发布、回滚，不影响应用运行。TSF 组件本身均为无状态，可多实例部署，不影响应用运行。底层依赖 MySQL 数据库主从部署，可单独跨 AZ 部署，避免单点故障。

2、运行时组件：分为两个层次：

• 监控、日志组件：全部故障影响监控数据采集，但不影响应用运行。组件自身无状态，可多实例部署，底层 ES/Redis 为非关系型数据库，可使用主备/分片模式部署，可单独跨 AZ 部署，避免单点故障。
• 服务注册中心：故障影响新服务注册、配置下发，TSF 在应用本地设计了缓存机制，在注册中心不可用时，应用仍可发起服务间调用。组件使用 Consul 集群部署，一主多从模式。

关于 TSF 管控端的高可用深入分析可参考后续系列专题文章。

数据库层异常分析

由于数据库是单点，单 AZ 内有可能出现单点宕机，故障时可切换至同 AZ 备节点或同城备节点，类似于 TDSQL 的一主多从模式，TDSQL 也可实现 IP 自动故障切换，应用无感知。

同城双活

用户所有的业务系统同时在两个数据中心运行，同时为用户提供服务，当某个 AZ 的应用系统出现问题时，有另一个 AZ 的应用来持续的提供服务.

部署方案：

• 微服务管控层：TSF 双活部署，有全局统一的注册中心，对网络延时有要求。
• 数据库层：一主多从，由于主节点只在一个 AZ，所以应用访问数据库可能会跨 AZ，因此要求AZ间网络延时低，降低数据倾斜带来的性能消耗。
• 应用层：无状态服务同时对外提供服务，双活的前提是微服务管控层双活以及数据库跨 AZ 时延低。

数据库层高可用部署模式仍为一主多从，后面不再对数据库层进行异常分析。

应用异常分析

对应用层几种异常场景进行分析： 1、整个AZ宕机：利用 GSLB 或者跨 AZ 的 LB 等技术切换至另一个 IP，同时这层能力可以实现负载均衡。

2、微服务间调用容灾：TSF 支持 AZ 内就近路由，AZ 内实例不可用时跨 AZ 调用。

添加测试环境路由插件依赖

目前 TSF 基于跨 AZ 的 VIP(客户提供或者 TCS/TCE 提供)实现注册中心等组件自动切换至另一个 AZ，在单 AZ 故障时应用无感知自动切换另一个 AZ 的管控端。

两地三中心

两地三中心建立在同城双活+异地灾备的基础上，兼具高可用性和灾难备份的能力，其中异地灾备中心 是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。

整体架构是同城双活+主备的组合方案。

部署方案：

• 微服务管控层：同城双活部署，异地灾备，各自的数据不需要做同步，只负责各自的服务管控。
• 数据库层：一主多从，TDSQL 同城强同步，异地异步复制。
• 应用层：无状态服务同时对外提供服务，主中心故障后，切换入口路由至异地备中心。

异地多活

异地多活的前提是架构能够实现两地三中心，并且在数据库层面做了水平分片，业务应用与数据库分片成组绑定。异地多活能够将故障范围缩小在单个分片内，并且减少数据库复杂度。一般对于数据量非常大的国家级银行/保险会采用这种架构。

方案又分为两种：异地互备与单元化，以下分开介绍。

异地互备

数据库层面水平拆成两个实例分片，例如可以按地域拆成北方、南方。

部署方案：

• 微服务管控层：服务同城双活，异地不互通。
• 应用层：不同数据分片的应用异地多活，相同数据分片的应用同城双活，异地灾备。
• 数据库层：数据分片一主多从，不同分片异地互备。

容灾切换策略：如南方城市整体故障，入口出做 DNS 切换南方用户访问 IP 至北方。

单元化

一般如果数据量过大，单纯使用数据库 Sharding 模式无法解决问题，可以考虑使用单元化架构。首先明确单元的定义，单元是一组计算资源和一组数据资源在逻辑上的绑定，设计的关键点包括：

1. 分片划分：考虑体量与业务，选择分区策略，尽量避免跨单元调用。
2. 部署单元设计：考虑容灾设计，单元与数据库分片绑定，同城单元双活，异地部署灾备单元。
3. 路由：TSF 提供能力在网关入口或服务入口计算单元化规则，对请求进行染色，后续请求按条件同单元路由，跨单元时通过网关调用。

部署方案：

• 微服务管控层：由于网关可能出现单元化要求有一个全局的服务注册中心。
• 应用层：每个地域包含全量单元分片，不同数据分片的应用异地多活，相同数据分片的应用同城双活，异地灾备。
• 数据库层：数据分片一主多从，不同分片异地互备。

单元异常分析：

• 整个地域故障转移：整体流量切换至另一个地域。
• 地域单个单元故障转移：除去应用代码本身问题，单元在物理上同城多中心分散部署，基本不可能出现一个城市某一个单元全部宕机。

基于单元化的异地多活

异地多活的概念澄清：

• 问题起源：单元化架构中另外一个核心考虑点是方便实现异地多活。在传统的同城双活、异地灾备架构中有一个广为诟病的问题，就是异地灾备的资源绝大部分时间没有实际服务于业务，购置部署之后，长期闲置，像一个久未上阵的战士，浪费了国家的军饷。为了更好的提升资源的利用率，很多客户尤其是金融类客户进一步追求异地多活的架构，让异地的资源也能分担一部分流量，正常的处理业务。
• 这里要注意正确理解异地多活的概念。异地多活，并不是指全业务（包括全量应用和全量数据）可以活在 Region A 又可以同时活在 Region B（两地相距数百公里以上，符合灾备监管要求）；而是指部分业务在 Region A 处理，部分在 Region B 处理，没有哪个 Region 是完全闲置的存在。因为前者的做法不论是技术上还是经济成本上都代价太高。

单元化支持异地多活：单元化架构下，由于数据做了分片分单元处理，把不同的单元放在不同的 Region 上处理。天然的实现了上面所提的异地多活充分利用机器资源的目标。各 Region 在分单元处理业务的同时，也作为灾备中心为异地的其他单元提供应用和数据的异地灾备能力。 目前 TSF 产品已经实现单元化能力，同时为了实现单元化异地多活的诉求，TSF 在最新版中实现了跨地域多集群互相发现互相访问的能力，如下图所示。

• 实现原理不是基于一个跨地域的全局注册中心，因为目前 TSF 的注册中心还是 Consul，Consul 集群是 CP 模式，CP 模式对于信息同步的延时性要求很高，Consul 集群只能同城多节点高可用部署，不能异地部署。所以目前 TSF 的异地访问，采用了单元网关寻址模式，由单元网关 Gateway 寻找异地服务所在的另一个单元网关 Gateway，再基于 Consul Access（无状态的前置层）到该集群的 Consul 注册中心拉取服务节点，实现跨地域服务访问。通过网关转发的模式，优点是单元封闭性好，访问链路清晰，出了问题容易追溯；缺点自然是增加了服务跳转次数，响应时间会有所增加。
• 未来TSF 的注册中心还会融合进北极星注册中心，这是一种基于数据库主从方式存储信息的 AP 模式注册中心，能够更好的作为一个跨地域的全局注册中心。

总结

以上基于微服务架构，从各个分层对高可用方案分别展开剖析，各个分层对高可用架构的设计是相辅相成的，每个高可用方案下任何一层能力的缺失可能都无法达成期望的目标。上述各所介绍的各种高可用架构，TSF 过去在各行业客户都有过落地，也积累了比较丰富的经验。总的来说，架构设计是在做取舍，没有完美的方案，一方面应遵循简单原则，架构设计越简单，越容易落地，运维复杂度越低，成本也越低，另一方面根据实际需求，如监管要求、部署现状、业务数据量等，结合客观条件限制选择合适的方案。

往期

推荐

《Apache pulsar 技术系列-- 消息重推的几种方式》

《Apache Pulsar 技术系列 - GEO replication 中订阅状态的同步原理》

《CKafka 跨洋数据同步性能优化》

《微服务优雅上下线的实践方法》

《基于 DTS 同步 MySQL 全增量数据至 CKafka，构建实时数仓的最佳实践》

《业务高速增长，如祺出行如何用腾讯云消息队列 RocketMQ 应对挑战》

了解更多微服务、消息队列的相关信息！

解锁超多鹅厂周边！