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

导语

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

作者介绍

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

概述

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

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

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

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

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

同城主备

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

部署方案：

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

应用层异常分析

对应用层几种异常场景进行分析：

1. 单个微服务实例故障：微服务需要做多实例部署，单 AZ 内可容错。

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

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

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

微服务管控层异常分析

TSF 微服务管控层可以分为两个层次：

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

监控、日志组件：全部故障影响监控数据采集，但不影响应用运行。组件自身无状态，可多实例部署，底层 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 过去在各行业客户都有过落地，也积累了比较丰富的经验。总的来说，架构设计是在做取舍，没有完美的方案，一方面应遵循简单原则，架构设计越简单，越容易落地，运维复杂度越低，成本也越低，另一方面根据实际需求，如监管要求、部署现状、业务数据量等，结合客观条件限制选择合适的方案。