畅捷通多租户多数据中心的架构演进

如果无法正常显示，请先停止浏览器的去广告插件。

1. 畅捷通多租户多数据中心的架构演进郑芸畅捷通总架构师

2. 郑芸畅捷通总架构师用友集团技术规划管理委员会成员畅捷通技术委员会负责人阿里云MVP 具有多年分布式系统架构经验，擅⻓网络安全、分布式微服务架构与中间件、互联网产品设计、数据治理、应用多活容灾、云原生高并发高可用整体技术解决方案等。

3. 大纲 • • • 畅捷通多数据中心多活改造的背景 ✓ 客户与产品特点 ✓ 稳定性影响因素畅捷通多数据中心多活架构的演进历程 ✓ 基于多租户的微服务架构 ✓ 兼顾灰度方案的多租户多数据中心的应用多活高可用保障方案 ✓ 多中心灰度轮转验证 ✓ 可用区故障切换方案

4. 公司介绍 – 中国领先的小微企业财税及业务云服务提供商畅捷通是用友旗下成员企业，提供以数智财税、数智商业为核心，以生态服务为延展的小微企业云服务。公司专注中国一亿多小微企业，帮助海量小微企业实现人员在线、业务在线、客户在线、管理在线，改变传统的经营业态，更快适应当前数智化转型需求。客户在线业务在线人员在线通过“在线”走向数智化转型数智财税服务数智商业服务增值服务畅捷通SaaS+咨询+服务数智化解决方案管理在线

5. 我们的客户与产品特点我们的客户小微企业产品特点云服务累计付费企业数（万） 39.7 40 服务全移动；超600万家仅移动设备可完成全部业务 83% 30 客户特点 38% 20 业务上云 21.7 15.7 规模小数量多分布广全在线全场景移动化业务实时在线；充分利用云服务厂商提供的云原生 10 技术 0 2019 2020 2021 多租户模式 ToB应用，租户间数据隔离；新制造、新商贸、新零售、新服务、新财税所有租户统一入口；共享云上的计算、存储资源

6. 高可用是“打造精品”的前提基础 2010~2022年知名云服务厂商宕机不完全统计业务持续创新 2周迭代频度 3000+ 构建次数/迭代 1000+ 特性/年挑战持续为客户提供稳定、创新的服务挑战⻘云 QingCloud 4 阿里云 5 腾讯云 8 亚⻢逊 22 谷歌微软 12 8 注：数据来源于壹零智库

7. 影响业务连续性的可能因素业务变更产品矩阵多多端复杂实时在线变更操作失误配置错误、环境搬运、应用发布等云设施故障中间件故障消息队列、Redis、磁盘网络故障 DDOS等网络攻击、网络配置主机级故障机房级故障服务集成第三方服务、ISV等硬件故障网卡故障，供电故障、制冷设备故障可用区级故障访问激增热点、业务大促、批量操作等突发灾害地震、洪灾等自然灾害地域级故障随业务规模增⻓技术故障带来的损失也相应增⻓代价服务故障损失技术投入业务规模

8. 技术架构的演进 – 持续进化、发展、成⻓云服务：数智财税和数智商业云原生架构软件服务单体架构微服务架构单租户架构 2013-2017 2012之前软件包 • B/S架构，部署在客户侧 • 所有业务放在中心服务器里单租户虚机 • 基于Cloud Foundry自主研发的运行平台 • 每个租户单独虚机部署 2017-2019年多租户 • 基于Dubbo的微服务架构 • 多租户模式 • 公有云部署 • 支撑好生意、好会计、易代账等产品线 2020年以后多数据中心多活 • 基于云原生技术体系构建 • 中间件、数据存储等使用云厂商提供的云服务 • 支持多中心部署

9. 高可用多活架构改造的目标 2-5-10 成本可控业务连续目标：一级一类核心功能数据不丢，服务不停（SLA，RPO=0，RTO<20m）高业务连续 • 故障爆炸半径小 • 核心一级一类应用连续性能保证高成本可控低 • 避免人为变更的影响 • 避免多AZ的网络延迟增加业务的耗时 • 避免同租户跨可用区访问 • 避免资源闲置 • 用户规模带来的成本可分摊到多个中心

10. 高可用多活架构改造的总体策略指导原则业务驱动阶段适用周期演练动态调整根据影响业务连续性的因素类型不同制定不同的架构改造策略业务变更灰度环境事前充分验证云设施故障多数据中心防患未然总体思路关键步骤拆根据业务属性设置多中心的拆分依据（应用、数据库）寻通过多端不同策略的路由寻址实现流量转发切针对不同故障进行流量切换保活

11. 原有的单中心部署架构统一入口官网 www.chanjet.com 跳转⻚业务服务（好业财） 2 微服务集群数据库 1 网关微服务集群微服务集群中间件通用服务微信公众服务业务服务（好会计）网关正式 2 IM消息微服务集群数据库容器集群微服务集群微服务集群正式中间件容器集群基础设施（网络/计算/存储）基础设施（网络/计算/存储） 3 身份认证云审批云存储 … 监控系统

12. 业务服务 – 基于多租户的微服务架构设计 Node Node K8S容器资源池 Node 微服务设计财务 GQL 报表小畅电商 … • 按业务划为微服务，高内聚低耦合购销 Platform 数据转换微商城 … • 弊端：服务间调用关系变复杂，变更影响点难评估库存 … 营销 … … 微服务框架数据库中间件多租户设计 OrgID + AppID 租户ID 租户ID 租户ID 租户ID • 支持共享数据表，通过表的租户id，实现隔离 • 也支持按租户水平分库； • 弊端：脚本的变更影响所有租户 … Tenant Tenant Tenant Tenant Master

13. 业务变更 – 全链路灰度方案前端监控系统 4 小程序 Mobile Browser 独立ISV 支付回调标签系统开放平台网关接入层 2 3 灰度网关对比分析监控面板第三方对接指标上报 1 灰度环境数据层登录缓存正式环境 BFF层 BFF层微服务1 微服务n 微服务1 微服务n 元数据Redis ZK配置中心元数据Redis ZK配置中心持久缓存租户DB 中间件消息队列定时任务灰度策略名单操作日志请求日志行为数据

14. 畅捷通四位一体的全链路灰度发布方案灰度方案支持CDN 前端应用流量网关微服务架构应用服务多租户数据库前端应用流量网关应用服务数据库前端静态资源 OSS按Object区分灰度/正式静态资源，由请求路径确定访问 CDN的资源。流量网关使用Nginx+Lua脚本，按URI内容解析，在流量入口进行灰度租户分流，实现REST接口灰度。消息队列调度任务根据Topic区分灰度消息和正式消息；根据环境变量进行生产和消费。通过环境变量过滤租户名单进行任务的执行。数据存储线上和灰度共用一套数据存储；DDL向下兼容；元数据、系统预置数据通过分布式缓存进行环境的隔离。

15. 拆 – 中心划分的业务属性挑选业务属性对数据进行分片，通过自上而下的流量路由，让高内聚的数据在固定中心完成读写身份认证 • 为所有产品提供身份认证的全局业务，读多写少； • 数据强一致全量存储；业务服务 • 不同租户数据逻辑隔离且支持水平分库； • 不同应用使用不同的云服务集群； • 不同租户可上下游协同业务；通用服务 • 以租户购买的应用为划分依据； • 为所有产品提供垂直业务的公共服务； • 被核心业务弱依赖；可降级使用 *墨菲定律：如果事情有变坏的可能，不管这种可能性有多小，它总会发生

16. 带灰度方案的多租户多中心部署图静态资源 CDN 接入层（按可用区划分目录）多可用区网关 CLB 独立ISV 支付回调第三方对接开放平台网关可用区2 可用区1 accounting/ydzee hyc/hsy 接入层灰度网关灰度 Node 灰度网关接入层 Node 正式灰度 Node SaaS SaaS SaaS SaaS PaaS PaaS PaaS PaaS Redis 登录Redis ZK Master DB Redis Tenant DB ZK Redis 登录Redis 持久Redis Redis ZK Master DB 正式 Node Tenant DB ZK 持久Redis 同城距离，专线延迟 1ms 左右 RocketMQ 云存储 MNS 微信公众服务云审 IM 双可用区多数据中心 -<应用，企业> 可独立发布的服务可用区1 可用区2

17. 多中心流量路由策略 Web端 IDC1 DNS Cloud2.chanjet.com Cloud1.chanjet.com CLB CLB 灰度网关 PROD 好业财 GRAY 好业财 IDC2 灰度网关：实现应用、灰度集群的路由转发。灰度网关 PROD 好会计 GRAY 好会计 PROD 好业财公共区 GRAY 好业财多可用区网关：对外屏蔽多中心，降低调用复杂度。开放平台网关开放平台网关：ISV调用OpenAPI的入口多可用区网关 POS端 ISV端

18. 寻 – 前端与数据源二级寻址 www.chanjet.com 前端寻址官网中心->域名管理应用->中心管理 {用户，租户，应用} {域名} 跳转⻚身份认证 {中心一域名} {租户，应用} 中心一环境1 多中心管理系统业务对中心无感中心易扩充增加新中心只需要更改配置即可多域名支持域名更换不影响正常使用中心二分层配置数据源寻址开通应用 {中心二域名} 中心一应用 {租户，中心} 中心透明应用服务应用服务中心二 namespace 水平分库按租户水平分库配置统一配置分层存储，各中心一致动态寻址动态数据源服务，流量纠偏 namespace 环境2 {租户a，dcluster} master1 环境Default {租户a，dcluster} tenant tenant master2 tenant tenant

19. 数据高可用 – 复用RDS跨区特性策略：数据库跨区互备份 IDC1 多租户数据高可用由云服务保障，简单、可靠主可用区 IDC2 存储热备1 RDS1 备可用区集群 Proxy Address 读写读读 DB计算节点主节点存储热备2 多租户借助云原生数据库的跨可用区热备能力 RDS2 只读节点只读节点计算节点备用资源池 DB分布式存储存储热备集群三副本三副本

20. 多租户多数据中心架构一套代码、一套多租户策略 www.chanjet.com 多数据中心数据中心-IDC1 灰度集群微服务多租户数据中心-IDC2 正式集群微服务 RDS 微服务 RDS 租户群1 租户群2 存储热备微服务灰度集群微服务多租户正式集群微服务 RDS 租户群1 存储热备数据中心-IDC3 微服务 RDS 微服务租户群2 灰度集群微服务多租户正式集群微服务 RDS 租户群1 微服务 RDS 租户群2 存储热备统一技术平台-流水线（DevOps）一套代码，一套流水线，统一监控日志进行集中收集，数据隔离多次发布统一监控，统一告警存储跨中心热备统一发布按中心隔离微服务

21. 中心灰度轮转 – 多中心DevOps流水线发布策略 ② ① 分中心逐步更新五步法 1. Hotfix验证 2. 中心1灰度验证，持续多天 3. 中心1正式发布 4. 更新中心2灰度（间隔1天） 5. 中心2上线完毕实现价值 1. 将变更带来的影响半径控制在单个中心以内 2. 通过在构建流水线时指定中心，实现中心灰度的轮转验证 3. 部署进度可视，事件驱动，钉钉群可视化展示，减少人工沟通成本 ③

22. 切 – 接入层故障切换监控告警日志采集用户访问 WAF 监控程序对请求进行分流 ③ CLB1 CLB2 可用区1 可用区2 接入层接入层修改路由策略切换步骤通过监控服务，检查接入层健康程度，出现故障后 ① 扩容 ② 修改ZK中多中心开关配置为multi，关闭流量纠偏功能，完成数据库的跨可用区访问 ServiceA 应用层应用层 ServiceB Redis 中间件 RocketMQ ServiceA 专线 ServiceB ② Redis 中间件 RocketMQ 数据层数据层 Redis PgSQL Redis PgSQL ① ③ 修改路由配置，切换受损流量至另一个可用区回切方法修改路由配置，切回流量；修改ZK值

23. 切 – 可用区故障切换监控告警日志采集用户访问监控程序应用网关切换步骤对请求进行分流通过监控服务，检查数据库层健康程度，出现故障后， ③ 流量切换可用区1 可用区2 接入层接入层 ① 数据库跨区做主备切换 ② 扩容 ServiceA 应用层 ServiceB Redis 中间件 RocketMQ ③ CLB流量切换 ServiceA 应用层 ServiceB ② 扩容 Redis 中间件反向操作即可 RocketMQ ① 数据层数据层 Redis PgSQL 回切方法 Redis PgSQL 备库主备可用区切换

24. 故障方案总结用户访问场景应用网关 1 接入层 2 可用区2 接入层 3 应用层接入层断网正常容灾操作 • 修改路由到可用区2 • 数据库跨区访问 • 修改路由到可用区1 2 正常断网 3 应用层宕机正常 • 回滚、限流、灰度切换等，不切换可用区，本中心解决 4 数据库异常正常 • 数据库跨区主备切换 • 数据库跨区访问应用层中间件中间件 4 数据层可用区2 对请求进行分流 1 可用区1 可用区1 数据层 • K8S，Redis等扩容 1+3+4 可用区故障正常 • 数据库跨区主备切换 • 修改路由到可用区2

25. 系统高可用总结 – 不确定性中找确定影响因素业务变更：功能复杂业务变更：应用迭代解决思路服务拆分服务治理通过微服务限流、降级、熔断技术，在故障发生时快速隔离故障，保证核心应用不受影响，不间断访问。全链路灰度发布为了有效预防产品上线可能带来的⻛险，我们通过全链路灰度方案，来实现新特性的小范围体验，来避免由于系统变更可能带来的⻛险。多数据中心应用多活云设施故障数据分片、业务分级数据按业务属性进行分片，每个中心只有部分数据，支持水平扩展；产品通过数据分片进行多活部署，实现应用的多活容灾，来规避网络、服务器等重大故障对系统的影响。

26. 解决的核心问题数据源动态路由可用区差异上线中心灰度轮转单可用区接入故障，可利用多中心数据源动态路由的机制，实现2-5-10的故障修复借助统一流水线分中心逐步更新五步法，通过迭代流水线动态指定上线中心，支持了灰度中心按季度进行轮转，避免灰度样本锁区。实现可用区分阶段上线，当前一个可用区充分验证后，才推包到其他可用区。多可用区对ISV及第三方服务友好借助开放平台网关+多可用区网关技术，最终实现了多可用区对ISV及第三方服务透明。多可用区可互切换客户价值提升多可用区最多1天的差异，一旦出现故障，可快速切换请求到正常可用区。极端情况存在1天差异，通过新库老代码的方案支持，仍可以切换

27. 业务价值爆炸半径短逃逸速度快单可用区故障只影响当前可用区通过扩容、升配，路由切用户；减少受影响用户范围换，可用区故障可在20分钟内完成逃逸；实现业务恢复与故产品整体稳定性提升业务同区闭环业务请求同区闭环，避免⻓链路频繁跨区，影响性能障恢复解耦数据强一致充分利用云原生红利，数据库的高可用由云服务保障，避免数据双向同步导致的不一致

28. 降低对研发的影响维护难环境构建部署调用复杂环境不一错误定位资开发效率源标准化一份配置，分层存储协作太难了~ 工具化自动化一份基准代码，多份部署 12 Factor 环境等价开发、线上、多中心环境基本相同日志作为事件流系统诊断、业务跟踪

29. 工具化、自动化协助研发提效监控可视化中心自动化测试平台标签系统灰度圈选

30. 其他解决方案异地多活跨云多活 • 战争、洪灾等地域级的故障无法规避 • 避免服务商锁定 • 不同地域距离远，网络延迟大，云厂商 • 不同云厂商之间需要实现数据同步没有现成的跨地域方案

31.

32.