同城双活:交易链路的稳定性与可靠性探索 | 得物技术
目录
作者:Alan 英杰 Matt 羊羽
一、背景
1. 异地双活
2. 同城双活
二、设计思路
三、双活整体架构
四、具体改造方案
1. 交易应用侧双活改造
2. 交易依赖方应用双活改造
3. 中间件&基础组件
3.1 识别机器资源可用区
3.2 中间件RTO
3.3 主要组件双活改造方案
3.3.1 DLB - 自研流量网关
3.3.2 彩虹桥 - 自研分布式关系数据库代理
3.3.3 DMQ
3.3.3.1 蓝绿属性
3.3.3.2 生产者
3.3.3.3 消费者
3.3.4 Kafka
3.3.5 ES
3.3.6 注册中心
3.4 流量分配策略
3.4.1 RPC流量
3.4.2 MQ流量比例
五、上线环节
1. 前期准备阶段
2. 开发&验证阶段
3. 线上准备&上线阶段
六、项目成果
1. 流量表现
2. 成本情况
七、带来的新问题及后续
知易行难,双活过程中遇到了非常多的问题,但是回过头看很难完美的表述出来,之所以这么久才行文也是这个原因,总是希望可以尽可能的复现当时的思考、问题细节及解决方案,但是写出来才发现能给出的都是多次打磨、摸索之后的我们认为偏合理的方案;不过换个角度看,给大家展示出来一个正确答案,是否有更积极的参考价值呢?
以及,涉及到容器、发布平台、底层网络运维、监控等组件的内容,限于视野及技术能力并未包含在内,仅聚焦在业务团队及中间件组件的设计及改造上。
一
背景
回到我们的现状,得物目前的交易应用及中间件基础组件都是基于某云部署,且前期为了降低跨机房调用产生的网络损耗,较多应用都绑定了存储组件(db/redis/hbase)及核心依赖下游的所在可用区,对此,为了避免在极端情况下,得物的交易主链路出现长时间不可用的情况,团队决定提前预防,启动同城双活项目。
异地双活
存储相关有两份,双机房内各自读写,双向同步 数据的循环赋值需要重点考虑如何处理 数据间的同步延迟问题会比较明显,不过各自机房内基本上可自闭环调用 对于用户、商家资产的处理比较复杂,比如用户券、卖家库存等,一般需要考虑在某个机房维护(gzone),避免数据同步问题带来的超卖、超用 切流时需要做目标机房的局部数据禁写,避免脏数据产生
同城双活
只有一份数据源,不需要考虑数据同步的延迟问题及切流时的禁写逻辑,不过若数据所在机房出问题,另一个机房无法正常承接流量(只能承接部分兜底流量,如cdn、缓存等有兜底数据的场景) 不需要考虑具备中心节点性质的数据问题,如用户券、库存等 跨机房访问较多,尤其是数据层面的读写,可能会造成RT的大幅上涨
不管是同城还是异地、双活还是多活(双活只是多活里最简单的场景,双活到三活难度飙升范围应该不亚于<羊了个羊>里第一关和第二关的难度),都是为了以下目标:
提高可靠性:通过在不同的物理位置部署服务,减少单点故障的风险。即使一个机房发生故障,其他机房也可以接管服务,确保业务连续性。
负载均衡:可以灵活分配用户请求流量,避免单个机房过载,尤其随着业务规模的扩大单个云厂商的机房已经无力提供更多资源的情况下。
灾难恢复:通过流量的调度切换来快速恢复某个机房的故障问题,减少业务中断时间。
云成本:在技术成熟度较高的前提下,做同云、跨云 甚至云+自建IDC机房之间的多活,一方面可以降低对某个云厂商的依赖从而获取一定的议价权;另一方面多活本身在提高资源利用率方面可以有更多可能性。
提高服务质量:这点尤其表现在异地多活场景,通过在多个中心之间分配流量,可以减少网络延迟,提供更快的响应时间和更高的服务质量。
二
设计思路
三
双活整体架构
接入层:DNS 域名解析+ SLB主备 + DLB+DAG多机房部署,保障接入层高可用。其中在DAG中实现了根据用户ID、流量比例等控制蓝绿流量的策略。 应用层: 应用通过改造,划分为逻辑蓝绿集群,通过蓝绿同调的粘性屏蔽跨区调用。 中间件层:多个中间件组件有各自不同的跨AZ部署策略、数据同步、主动切换策略,下面会详述。 数据层:数据层保持一份数据,通过自动/手动主从切换,跨区部署等技术手段,保障机房级别故障下服务可用,包含DB、Redis、Hbase等。
四
具体改造方案
交易应用侧双活改造
A、C服务参与双活,需要跨可用区部署。B服务不参与双活,不需要跨可用区部署。
A、B、C服务都需要识别流量染色、服从流量调度。
相关服务Owner各自将服务中集成的统一基础框架升级到指定版本,接入无侵入、零配置、开箱即用的蓝绿发布能力组件全家桶。保证基于蓝绿发布的运行时流量调度能力被完整集成。上述简图中A、B、C服务需要进行该步骤。 相关服务Owner各自在发布平台界面白屏化迁移发布模式。发布模式迁移到蓝绿发布时,发布平台自动将服务Pod进行跨可用区部署,并在Pod中注入支撑流量调度的进程级元信息。蓝绿发布能力组件在上游调用方LoadBalance时介入进行流量染色、流量调度。上述简图中A、C服务需要进行该步骤。
交易依赖方应用双活改造
中间件&基础组件
识别机器资源可用区
中间件RTO
主要组件双活改造方案
01
DLB - 自研流量网关
02
彩虹桥 - 自研分布式关系数据库代理
03
DMQ
通过Broker分片级别打散到不同的可用区形成一套完整的集群。
蓝绿属性
生产者
蓝集群的消息会被投递的broker的前一半队列中 绿集群的消息会被投递到broker的后一半队列中
消费者
04
Kafka
由于ZK的ZAB协议要求保证 Math.floor(n/2)+1 奇数个节点存活才能选出主节点,所以 ZK 需要进行3个可用区部署,上面的nameserver类似。分散在3个可用区中,A:B:C 节点数 = 2N:2N:1,确保始终是奇数个集群节点。
Broker 在两个可用区对等部署,分区的主从跨区部署。当单个可用区故障时,分区leader切换。
05
ES
数据节点:需要保持各个可用区之间节点对等,以保证数据的平衡;使用分区感应把主副分片隔开,保持在不同可用区内。
master节点:部署在至少三个可用区,以保证任何一个可用区挂了,都不影响master的选举。
06
注册中心
PS:自研分布式注册中心,基于raft协议实现系统可用性、数据一致性。承担得物全站RPC服务发布/订阅职责。
代理节点多分区部署,保障多可用区双活 Sylas集群Raft节点3个分区部署,保障多可用区双活
流量分配策略
01
RPC流量
每个应用会在请求上下文中附上当前的蓝绿标识; 如果某个应用没有纳入双活范畴,这里的蓝绿标识会丢失,此时有两种策略:
02
MQ流量比例
五
上线环节
前期准备阶段
基于当前的蓝绿发布做双活,每次的蓝绿发布过程就是一次双活切流演练,避免长久不使用,需要用的时候手忙脚乱或者年久失修 服务层做双活部署,数据层不做大的改造,DB和Redis通过自身的主从切换实现高可用,从节点分布在不同的可用区 交易域内所有服务+核心链路相关外域服务做双活改造
交易域所有服务&以及核心业务场景强依赖的外部服务、强依赖的具体业务场景、可否降级&有无兜底 MQ使用情况:DMQ还是Kafka还是其他、是否需要保证消息的顺序性 所有服务当前机器所在可用区、是否绑定固定可用区 交易域所有数据库、Redis对应的主节点和从节点分别所在可用区情况 依赖zookeeper的job情况
上下游非交易域沟通确认(必须纳入改造范围的服务、可以不用双活改造的服务必须要有兜底) 双活涉及到的服务jar升级、未接入蓝绿发布的接入蓝绿发布 跨区调用情况下RT上涨明显的接口针对性优化
运维侧提供自建Redis的就近读方案,但是对于数据一致性方面有所牺牲,各方根据实际业务场景和接口RT情况综合评估是否需要接入
开发&验证阶段
环境本身的搭建:服务蓝绿集群拆分、绑定可用区、容器蓝绿集群机器比例配置 双活蓝绿染色环境代码版本校验、代码准入规则、分支自动合并规则、测试流程流转等 将双活蓝绿染色环境定为测试二轮round2环境,在日常迭代中常态化回归验证双活流程
正常业务流程回归 测试环境蓝绿切流回归 测试环境MQ生产&消费切流回归 核心业务接口RT情况记录对比、优化意见
验证通道优先级:发布通道优先级 > 全局通道
此刻预发环境等于已经实际上完成了双活改造
交易平台绝大部分服务之前都是绑定可用区A区,每个服务单独部署一台机器到B区,观察接口RT情况
线上准备&上线阶段
日志平台、监控平台、trace链路、容器升级支持蓝绿标
生产环境DMQ切换为蓝绿2.0支持按照双活蓝绿标消费
数据库&Redis主节点切换,保证主从节点只在A区或者B区
大部分在在a、b这两个区,也有例外。核心是主节点一定要在这两个区
线上服务拆分蓝绿集群(手动),项目正式上线,回归验证&RT问题关注
绿集群(A区)扩容至100%机器,蓝集群(B区)维持50%机器,灰度观察5天
线上RT上涨接口技术专项优化
发布平台双活保障迭代升级
支持新增服务一键加入双活蓝绿集群
双活蓝绿集群支持按区批量扩容能力(单机房故障情况下,快速拉起存活区的服务)
六
项目成果
流量表现
两个可用区的集群流量达到了50:50。不过rocketmq 由于存在少量上下游应用并未进行多活改造,还有较小流量未严格分布
核心指标 qps/rt/错误率
核心基础组件访问情况 由于所有数据存储(db、redis、hbase)均在A区,故B区的 rt 有一定上涨,整体看上浮大概 7-8ms( 存在一次请求 查询多次数据的场景),还在持续推动优化
成本情况
七
带来的新问题及后续
两个大域双活切流是否需要联动(联动:影响范围被放大,且搜推侧扩容不易;不联动:各域双活流量非常割裂) 两个大域之间的是否识别相同的蓝绿标(各大域内部自闭环保证同区访问or大域之间也需要保证)
往期回顾
文 / Alan 英杰 Matt 羊羽
关注得物技术,每周一、三、五更新技术干货
要是觉得文章对你有帮助的话,欢迎评论转发点赞~
未经得物技术许可严禁转载,否则依法追究法律责任。
“
扫码添加小助手微信
如有任何疑问,或想要了解更多技术资讯,请添加小助手微信: