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

导语

绝对于过来单体或 SOA 架构，建设微服务架构所依赖的组件产生了扭转，因而剖析与设计高可用容灾架构计划的思路也随之扭转，本文对微服务架构落地过程中的几种常见容灾高可用计划开展剖析。

作者介绍

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

概述

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

在剖析简单的容灾架构前，咱们首先该当明确问题的定义，拆解问题，合成子问题，从不同维度离开探讨能力取得一个清晰的论断。当咱们探讨主备、双活等高可用模式时，不同的高可用模式对于利用、数据库、注册核心等组件的含意不是一样的，但各组件又互相关联。在笔者看来，一个残缺的微服务架构组件蕴含三个维度：

• 微服务管控层：因为分布式架构带来了复杂性，须要引入相干的分布式撑持组件

1. 利用生命周期治理组件 ：负责利用公布、回滚、弹性伸缩、故障转移，微服务架构对部署运维能力有更高的要求，要求业务可能实现交付设施自动化。该局部组件对业务运行时影响比拟小。
2. 服务治理组件 ：负责服务注册发现、服务配置、服务路由等分布式治理能力，其中最为人熟知的组件是服务注册核心，注册核心负责对服务进行健康检查，及时摘除异样实例，因而在容灾模式下对网络要求比拟高，如果网络不稳固容易导致健康检查不精确，频繁进行大规模服务实例变更告诉，影响零碎稳定性。
3. 监控组件 ：负责采集可观测性三大件 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 过来在各行业客户都有过落地，也积攒了比拟丰盛的教训。总的来说，架构设计是在做取舍，没有完满的计划，一方面应遵循简略准则，架构设计越简略，越容易落地，运维复杂度越低，老本也越低，另一方面依据理论需要，如监管要求、部署现状、业务数据量等，联合客观条件限度抉择适合的计划。