如何提高你的网站的粘性,螺蛳粉营销策划方案,国际交流合作网站建设方案,游戏租号网站开发导语
相对于过去单体或 SOA 架构#xff0c;建设微服务架构所依赖的组件发生了改变#xff0c;因此分析与设计高可用容灾架构方案的思路也随之改变#xff0c;本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。
作者介绍
刘冠军 腾讯云中间件中心架构组负责…导语
相对于过去单体或 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的注册中心还是ConsulConsul集群是CP模式CP模式对于信息同步的延时性要求很高Consul集群只能同城多节点高可用部署不能异地部署。 所以目前TSF的异地访问采用了单元网关寻址模式由单元网关gateway寻找异地服务所在的另一个单元网关gateway再基于Consul Access无状态的前置层到该集群的Consul注册中心拉取服务节点实现跨地域服务访问。通过网关转发的模式优点是单元封闭性好访问链路清晰出了问题容易追溯缺点自然是增加了服务跳转次数响应时间会有所增加。未来TSF的注册中心还会融合进北极星注册中心这是一种基于数据库主从方式存储信息的AP模式注册中心能够更好的作为一个跨地域的全局注册中心。 总结
以上基于微服务架构从各个分层对高可用方案分别展开剖析各个分层对高可用架构的设计是相辅相成的每个高可用方案下任何一层能力的缺失可能都无法达成期望的目标。上述所介绍的各种高可用架构TSF 过去在各行业客户都有过落地也积累了比较丰富的经验。总的来说架构设计是在做取舍没有完美的方案一方面应遵循简单原则架构设计越简单越容易落地运维复杂度越低成本也越低另一方面根据实际需求如监管要求、部署现状、业务数据量等结合客观条件限制选择合适的方案。
