《02畅捷通多租户多数据中心的架构演进--郑芸.pdf》由会员分享,可在线阅读,更多相关《02畅捷通多租户多数据中心的架构演进--郑芸.pdf(32页珍藏版)》请在三个皮匠报告上搜索。
1、畅捷通多租户多数据中的架构演进郑 芸畅捷通总架构师畅捷通总架构师友集团技术规划管理委员会成员 畅捷通技术委员会负责 阿云MVP郑 芸具有多年分布式系统架构经验,擅络安全、分布式微服务架构与中间件、互联产品设计、数据治理、应多活容灾、云原并发可整体技术解决案等。畅捷通多数据中多活改造的背景 客户与产品特点 稳定性影响因素 畅捷通多数据中多活架构的演进历程 基于多租户的微服务架构 兼顾灰度案的多租户多数据中的应多活 可保障案 多中灰度轮转验证 可区故障切换案纲公司介绍 中国领先的微企业财税及业务云服务提供商畅捷通是友旗下成员企业,提供以数智财税、数智商业为核,以态服务为延展的微企业云服务。公司专注
2、中国亿多微企业,帮助海量微企业实现员在线、业务在线、客户在线、管理在线,改变传统的经营业态,更快适应当前数智化转型需求。客户在线业务在线员在线管理在线通过“在线”向数智化转型数智财税服务数智商业服务增值服务畅捷通SaaS+咨询+服务 数智化解决案我们的客户与产品特点微企业我们的客户超600万家客户特点数量多分布全在线规模产品特点业务上云 业务实时在线;充分利云服务商提供的云原技术多租户模式 ToB应,租户间数据隔离;所有租户统;共享云上的计算、存储资源全场景移动化 服务全移动;仅移动设备可完成全部业务云服务累计付费企业数(万)092020202139.721.715.73
3、8%83%新制造、新商贸、新零售、新服务、新财税可是“打造精品”的前提基础2周迭代频度特性/年1000+3000+构建次数/迭代20102022年知名云服务 商宕机不完全统计云 QingCloud阿云腾讯云亚逊歌微软45822128注:数据来源于壹零智库持续为客户提供 稳定、创新的服务挑战挑战业务持续创新变更操作失误 配置错误、环境搬运、应发布等硬件故障 卡故障,供电故障、制冷设备故障络故障 DDOS等络攻击、络配置中间件故障 消息队列、Redis、磁盘突发灾害 地震、洪灾等然灾害业务变更云设施故障影响业务连续性的可能因素 服务集成 第三服务、ISV等可区级故障访问激增 热点、业务促、批量操作
4、等多端复杂实时在线产品矩阵多机房级故障主机级故障地域级故障服务故障损失技术投代 价业务规模随业务规模增技术故障带来的损失也相应增技术架构的演进 持续进化、发展、成云服务:数智财税和数智商业软件服务 基于Cloud Foundry主研发的运平台 每个租户单独虚机部署单租户 虚机单租户架构2013-2017 微服务架构 2017-2019年云原架构2020年以后多租户 基于Dubbo的微服务架构 多租户模式 公有云部署 撑好意、好会计、易代账等产品线多数据中多活基于云原技术体系构建 中间件、数据存储等使云商提供的云服务 持多中部署B/S架构,部署在客户侧 所有业务放在中服务器软件包单体架构2012
5、之前 可多活架构改造的标 避免资源闲置 户规模带来的成本可分摊到多个中 避免多AZ的络延迟增加业务的耗时 避免同租户跨可区访问 避免为变更的影响 故障爆炸半径 核级类应连续标:级类核功能数据不丢,服务不停(SLA,RPO=0,RTO20m)业务连续性能保证成本可控低成本可控 业务连续2-5-10可多活架构改造的总体策略指导原则业务驱动阶段适周期演练动态调整总体思路业务变更灰度环境云设施故障多数据中根据影响业务连续性的因素类型不同制定不同的架构改造策略事前充分 验证防患未然关键步骤拆寻切根据业务属性设置多中的拆分依据(应、数据库)通过多端不同策略的路由寻址实现流量转发针对不同故障进流量切换保活原
6、有的单中部署架构官微服务集群业务服务(好业财)跳转关关业务服务(好会计)正式数据库中间件容器集群基础设施(络/计算/存储)数据库中间件容器集群基础设施(络/计算/存储)身份认证监 控 系 统统12微服务集群微服务集群微服务集群微服务集群微服务集群正式通服务微信公众服务IM消息云存储3云审批2多租户设计持共享数据表,通过表的租户id,实现隔离 也持按租户平分库;弊端:脚本的变更影响所有租户微服务设计按业务划为微服务,内聚低耦合弊端:服务间调关系变复杂,变更影响点难评估K8S容器资源池NodeNodeNode报表数据转换营销畅电商微商城微服务框架数据库中间件MasterTenant OrgID+A
7、ppID租户ID租户ID租户ID租户ID财务购销库存GQLPlatformTenantTenantTenant业务服务 基于多租户的微服务架构设计租户DB登录缓存持久缓存BFF层接层开放平台关第三对接付回调独ISV灰度环境程序Mobile Browser消息队列BFF层正式环境前端微服务n微服务1元数据RedisZK配置中定时任务数据层中间件微服务n微服务1元数据RedisZK配置中灰度策略名单操作 志请求 志为 数据标签 系统灰度关监控 板对 分析指标上报监控 系统业务变更 全链路灰度案1234畅捷通四位体的全链路灰度发布案持CDN 前端应流量关微服务架构 应服务多租户 数据库前端应流量关应
8、服务数据库前端静态资源 OSS按Object区分灰度/正式静态资源,由请求路径确定访问CDN的资源。消息队列 根据Topic区分灰度消息和正式消息;根据环境变量进产和消费。调度任务 通过环境变量过滤租户名单进任务的执。流量关 使Nginx+Lua脚本,按URI内容解析,在流量进灰度租户分流,实现REST接灰度。数据存储 线上和灰度共套数据存储;DDL向下兼容;元数据、系统预置数据通过分布式缓存进环境的隔离。灰度案拆 中划分的业务属性 为所有产品提供身份认证的全局业务,读多写少;数据强致全量存储;不同租户数据逻辑隔离且持平分库;不同应使不同的云服务集群;不同租户可上下游协同业务;以租户购买的应为
9、划分依据;身份认证业务服务挑选业务属性对数据进分,通过上下的流量路由,让内聚的数据在固定中完成读写*墨菲定律:如果事情有变坏的可能,不管这种可能性有多,它总会发通服务 为所有产品提供垂直业务的公共服务;被核业务弱依赖;可降级使带灰度案的多租户多中部署图双可区多数据中-RocketMQ可独发布的服务可区2NodeSaaSPaaS可区1云存储微信公众服务云审RedisZK正式Tenant DBMaster DB登录Redis持久Redis正式MNS灰度NodeSaaSPaaSRedisZK静态资源 CDN(按可区划分录)接层开放平台关CLB多可区关第三对接付回调独ISV接层灰度关NodeSaaSP
10、aaSRedisZKTenant DBMaster DB登录Redis持久Redis灰度NodeSaaSPaaSRedisZK接层灰度关accounting/ydzeehyc/hsy同城距离,专线延迟 1ms 左右IM可区2可区1多中流量路由策略好业财IDC1IDC2多可区关好会计好业财好会计PRODGRAYCLB灰度关PRODGRAY好业财好业财PRODGRAY开放平台关Web端ISV端多可区关:对外屏蔽多中,降低调复杂度。灰度关:实现应、灰度集群的路由转发。开放平台关:ISV调OpenAPI的DNS公共区CLB灰度关CCPOS端寻 前端与数据源级寻址中透明业务对中感中易扩充增加新中只需要更
11、改配置即可多域名持域名更换不影响正常使官跳转身份认证户,租户,应中中中域名中域名应-中 管理中-域名 管理 开通应 租户,中域名多中管理系统前端寻址数据源寻址平分库按租户平分库配置统配置分层存储,各中致动态寻址动态数据源服务,流量纠偏tenanttenant租户a,dclustermaster1分层配置应环境1namespacenamespace中中tenanttenant租户a,dclustermaster2环境2环境Default租户,应应服务应服务数据可 复RDS跨区特性计算节点备资源池存储热备集群三副本备可区DB计算节点主节点只读节点只读节点DB分布式存储集群 Proxy Addres
12、s主可区三副本读写读读借助云原数据库的跨可区热备能多租户存储热备2RDS1多租户存储热备1RDS2IDC1IDC2策略:数据库跨区互备份数据可由云服务保障,简单、可靠多租户多数据中架构套代码、套多租户策略数据中-IDC1多数据中数据中-IDC2数据中-IDC3统监控志进集中收集,统监控,统告警统发布套代码,套流线,多次发布数据隔离按中隔离 存储跨中热备微服务微服务灰度集群多租户租户群1租户群2RDS微服务微服务正式集群RDS存储热备微服务微服务灰度集群多租户租户群1租户群2RDS微服务微服务正式集群RDS存储热备微服务微服务灰度集群多租户租户群1租户群2RDS微服务微服务正式集群RDS存储热备
13、统技术平台-流线(DevOps)中灰度轮转 多中DevOps流线 发布策略1.将变更带来的影响半径控制在单个中以内 2.通过在构建流线时指定中,实现中灰度的轮转验证 3.部署进度可视,事件驱动,钉钉群可视化展示,减少沟通成本 实现价值分中逐步更新五步法1.Hotfix验证 2.中1灰度验证,持续多天 3.中1正式发布 4.更新中2灰度(间隔1天)5.中2上线完毕切换步骤通过监控服务,检查接层健康程度,出现故障后扩容修改ZK中多中开关配置为multi,关闭流量纠偏功能,完成数据库的跨可区访问修改路由配置,切换受损流量另个可区回切法修改路由配置,切回流量;修改ZK值监控程序修改路由策略接层可区1数
14、据层RedisPgSQL接层可区2数据层CLB2对请求进分流户访问ServiceAServiceBRedisRocketMQ应层ServiceAServiceBRedisRocketMQ应层监控告警志采集RedisPgSQL中间件中间件切 接层故障切换WAF专线CLB1切换步骤通过监控服务,检查数据库层健康程度,出现故障后,数据库跨区做主备切换扩容CLB流量切换回切法反向操作即可监控程序主备可区切换接层可区1数据层RedisPgSQL接层可区2数据层应关对请求进分流户访问ServiceAServiceBRedisRocketMQ应层ServiceAServiceBRedisRocketMQ应层
15、监控告警志采集RedisPgSQL中间件中间件切 可区故障切换备库流量切换扩容接层可区1数据层应关对请求进分流户访问应层中间件接层可区2数据层应层中间件321故障案总结4场景可区1可区2容灾操作1接层断正常 修改路由到可区2 数据库跨区访问2正常断 修改路由到可区1 数据库跨区访问3应层宕机正常 回滚、限流、灰度切换等,不切换可区,本中解决4数据库异常正常 数据库跨区主备切换1+3+4可区故障正常 K8S,Redis等扩容 数据库跨区主备切换 修改路由到可区2影响因素解决思路服务拆分全链路灰度发布多数据中应多活服务治理业务变更:功能复杂业务变更:应迭代系统可总结 不确定性中找确定云设施故障 通
16、过微服务限流、降级、熔断技术,在故障发时快速隔离故障,保证核应不受影响,不间断访问。为了有效预防产品上线可能带来的险,我们通过全链路灰度案,来实现新特性的范围体验,来避免由于系统变更可能带来的险。数据按业务属性进分,每个中只有部分数据,持平扩展;产品通过数据分进多活部署,实现应的多活容灾,来规避络、服务器等重故障对系统的影响。数据分、业务分级解决的核问题数据源动态路由 单可区接故障,可利多中数据源动态路由的机制,实现2-5-10的故障修复可区差异上线 借助统流线分中逐步更新五步法,实现可区分阶段上线,当前个可区充分验证后,才推包到其他可区。中灰度轮转 通过迭代流线动态指定上线中,持了灰度中按季
17、度进轮转,避免灰度样本锁区。多可区可互切换 多可区最多1天的差异,旦出现故障,可快速切换请求到正常可区。极端情况存在1天差异,通过新库代码的案持,仍可以切换多可区对ISV及第三服务友好 借助开放平台关+多可区关技术,最终实现了多可区对ISV及第三服务透明。客户价值提升业务价值 充分利云原红利,数据库的可由云服务保障,避免数据双向同步导致的不致 通过扩容、升配,路由切换,可区故障可在20分钟内完成逃逸;实现业务恢复与故障恢复解耦业务请求同区闭环,避免链路频繁跨区,影响性能单可区故障只影响当前可区户;减少受影响户范围爆炸半径短逃逸速度快数据强致业务同区闭环产品整体 稳定性提升 12Factor降低对研发的影响开发效率协作构建部署环境不资源维护难环境错误定位调复杂太难了份配置,分层存储环境等价开发、线上、多中环境基本相同志作为事件流系统诊断、业务跟踪份基准代码,多份部署具化动化标准化具化、动化协助研发提效动化测试平台监控可视化中标签系统灰度圈选其他解决案异地多活跨云多活战争、洪灾等地域级的故障法规避 不同地域距离远,络延迟,云商没有现成的跨地域案避免服务商锁定 不同云商之间需要实现数据同步