如何搭建视频网站,资源网站推荐,php网站模板开源,网店代运营店铺文 / 新一
一、前言
一年一更的彩虹桥系列又来了#xff0c;在前面两期我们分享了在稳定性和性能2个层面的一些演进优化思路。近期我们针对彩虹桥 Proxy 负载均衡层面的架构做了一次升级#xff0c;目前新架构已经部署完成#xff0c;生产环境正在逐步升级中#xf…文 / 新一
一、前言
一年一更的彩虹桥系列又来了在前面两期我们分享了在稳定性和性能2个层面的一些演进优化思路。近期我们针对彩虹桥 Proxy 负载均衡层面的架构做了一次升级目前新架构已经部署完成生产环境正在逐步升级中借此机会更新一下彩虹桥架构演进之路系列的第三篇。 阅读本文预计需要2030分钟建议不熟悉彩虹桥的同学在阅读本文前可以先看一下前两篇彩虹桥架构演进的文章
得物数据库中间件平台“彩虹桥”演进之路
彩虹桥架构演进之路-性能篇得物技术 二、背景
彩虹桥目前依赖 SLB 做负载均衡和节点发现随着业务发展流量越来越高SLB 带宽瓶颈逐渐暴露虽然在半年前做过一次双 SLB 改造临时解决了带宽瓶颈但运维成本也随之变高。除了带宽瓶颈外SLB 无法支持同区优先访问导致难以适配双活架构。所以准备去除彩虹桥对 SLB 的强依赖自建彩虹桥元数据中心提供负载均衡和节点发现等能力同时支持同区访问等能力来更好的适配双活架构。下面会详细介绍一下彩虹桥元数据中心以及 SDK 相关能力的相关细节。 三、核心名称解释 四、现有架构回顾
在开始介绍彩虹桥元数据中心之前我们先来回顾一下彩虹桥目前架构以及存在的一些痛点。 现有架构 业务服务集成 SDK 通过域名访问请求经过 SLB 转发到具体的 Proxy 节点。 每个集群挂载双 SLBSDK 通过 DNS 解析轮训路由到2个 SLB2个 SLB 挂载不同的后端节点。 每个集群部署的 Proxy 节点均为一个可用区双活架构为集群维度多可用区部署。 业务侧大多数为多可用区混布单同一个逻辑库只会连接一个彩虹桥集群由于彩虹桥一个集群内的节点均为同一可用区所以业务服务-彩虹桥这条链路必然会出现一半节点跨区访问。 彩虹桥集群按照业务域划分彩虹桥集群所属业务域的 RDS 大多数都会跟彩虹桥集群同区。比如彩虹桥交易集群为i区归属交易集群的逻辑库挂载的 RDS 大多数也都是i区。 主要痛点 SLB 带宽已达瓶颈5Gb/s历史上出现过多次 SLB 带宽达到 100%的情况目前彩虹桥单集群挂载了双 SLB 暂时解决带宽瓶颈但仍存在痛点 1. SLB 扩容流程较复杂配置监听、配置虚拟服务器组、监听绑定虚拟服务组配置调度算法、更新域名解析的等基于目前发布系统能力无法实现全自动化。根据之前混沌工程演练结果SLB 扩容流程需要30分钟左右。 2. SLB 扩容后需要改域名解析DNS 解析生效需要一段时间域名 TTL 1 分钟本地缓存10分钟新 SLB 需要10分钟左右才开始逐渐承载流量无法实现 SLB 快速扩容。 单可用区故障时需要人工操作切流到其他可用区集群SLA 难以保证目前无法自动化判定单可用区故障且集群级别流量调度需要人工预估集群负载难以实现自动化切流。 SLB 目前支持最低权重为1/100粒度较粗无法支撑发布过程中的更小流量灰度需求。 Proxy 单个集群所有节点均为同一个 AZ需要与下游 RDS 保证同 AZ跨集群流量调度灵活性差很难实现多可用区流量均衡目前由于大部分 RDS 为 I 区Proxy 多可用区流量非常不均衡i区 90%/k 区流量 10%。 五、自建元数据中心SDK 增强 元数据中心独立部署 新增 Metadata 数据库多可用区部署需要跟集群中的 Proxy 同区。 新增 MetaCenter 服务多可用区部署。 Proxy 连接所有 Metadata 数据库注册心跳都会写入到所有数据库。 MetaCenter 服务定时查询所有 metadata 数据库基于心跳版本号和多个数据库的并集筛选出健康的节点列表存储到内存中。 MetaCenter 服务提供 API查询 MetaCenter 内存中的可用节点列表数据。 SDK 启动时会去通过7层 SLB 访问 MetaCenter 提供的 API 拉取节点列表并存储到内存运行中每隔 5s 更新一次。 MetaCenter 每次计算时如果有节点下线通过 ARK 实时下发拉取事件给 SDKSDK 会立刻重新拉取一次节点列表。 SDK 通过下发的节点列表做负载均衡优先路由到同可用区的 Proxy 节点其次按照节点权重轮训。 SDK 轮训间隔时间和节点变更事件下发开关均为可配置实时生效。 架构详解
Metadata 数据库 节点表结构设计 beat_version心跳版本号只有上报心跳时会更新。 config_version配置版本号更新权重状态时会更新。 enabled是否启用 Proxy
节点启动时 注册启动时会去所有 metadata 数据库注册当前节点如果 node_info 不存在对应节点记录则新增如果存在则修改权重为初始权重。 启动完成后需要调用 bifrost-admin 提供的调用节点启用 API发布脚本
update node_info set weight 1, config_version #{config_version}where cluster_name ? and address ? 节点运行时 心跳定时更新所有 metadata 数据库节点记录的 beat_version 字段
update node_info set beat_version beat_version 1 where cluster_name ? and address ? 节点下线 调用 bifrost-admin 提供的下线 OPEN API发布脚本 MetaCenter( Heimdall) 启动时
初始化心跳版本号记录所有 metadata 数据库每个节点最新 beat_version 和初始化心跳丢失次数到内存 运行时
定时查询节点信息3s 一次筛选可用节点并写入到内存中提供 OpenAPI 给 SDK 调用每个库均执行以下操作最终会得到每个库的可用节点列表最后把多个 list 求并集得到最终的可用列表写入到内存中。 查出所有列表数据后对比内存中的 beat_version 与数据库中的 beat_version如不相同则更新内存如果相同说明对应节点心跳有丢失如果丢失次数超过阈值则剔除此节点。 节点列表中除了 ip、端口信息外还有权重启用状态属性 这些属性都属于控制流变更如果出现2边数据库不一致场景以 config_version 最大的为准。 1.2.3.20节点与K区网络断开 1.2.3.20节点宕机
如果本次计算时有节点列表变化会下发一个变更事件到 ARKvalue 为时间戳-秒SDK 在收到次配置变更后会立刻到 MetaCenter 拉取一次节点列表以弥补定时轮训的延时。 兜底配置
MetaCenter 提供的 OpenAPI 是通过计算后存入内存的数据为了可以人工干预节点列表需要支持开关一键切换至人工配置的节点列表数据。 SDK( Rainbow) SDK 启动时会去通过7层 SLB 拉取节点列表并存储到内存运行中每隔5s更新一次。 如果拉取失败启动时报错运行中不做任何处理等待下次拉取。 如果拉取的可用节点列表为空启动时报错运行时兜底不做任何处理等待下次拉取。 拉取的可用节点列表与内存中做对比如果有节点被移除需要优雅关闭对应的存量连接如果被移除节点超过1个则不做驱逐。 当可用节点数量/所有节点数量 X%时忽略本次变更不更新内存中的可用节点列表。 拉取的节点数据会按照可用区进行分组分为同可用区跨可用区2个队列 负载均衡时优先从同 AZ 节点队列中进行加权轮训。 当同AZ节点权重总和/所有节点权重总和 Y%时同 AZ 节点优先策略失效退化为所有节点加权轮训。 当同AZ可用节点 Z时同 AZ 节点优先策略失效退化为所有节点加权轮训 。 需要新增查询节点列表的监控埋点以上三种计算结果的埋点 另外 SDK 支持一键动态切换至走老架构方式4层 SLB 管理后台 新增页面【节点管理】用于查询管理节点 新增页面【兜底节点管理】用于管理兜底节点列表。 提供节点上下线 API给发布系统调用。
修改状态会去所有 metadata 数据库执行只有一个库成功就返回成功如所有库都修改失败则返回失败。
update node_info set enabled 0, config_version #{config_version}where ip ? and port ? 容灾能力
表格中的是否有影响和故障恢复时间均指 SDK-Proxy 的访问链路Proxy-DB 链路不在范围内。 可用区i全部宕机举例
参考以下时间线可在30s左右完成恢复。 i区 Metadata 数据库故障无影响。 一些思考
Q为什么不用 sylas得物注册中心产品做注册中心而是要自建元数据中心做服务发现
彩虹桥和 sylas 均为 P0 级别服务对稳定性要求极高在架构设计之初需要充分考虑到互相依赖可能带来的级联故障在与注册中心相关同学沟通后决定自建彩虹桥元数据中心实现自闭环。 Q为什么不是传统的基于 Raft 协议的三节点来实现服务发现而是用多套数据源做 merge
Raft 是工程上使用较为广泛的强一致性、去中心化、高可用的共识算法在分布式系统中适用于高一致性、容错性要求高的场景。但 Raft 协议需要维护领导者选举和日志复制等机制性能开销较大其次 Raft 协议相对复杂在开发、维护、排障等方面会非常困难反之采用多数据源求并集的方式更简单同时也具备单节点故障、整个可用区故障以及跨区网络中断等多种复杂故障下的容灾能力。 Q如何在 SLB 切换到新架构的过程中保障稳定性
可灰度支持单个上游节点粒度的灰度
可回滚支持一键动态切换至 SLB 架构
可观测大量埋点数据可实时进行观测有问题可快速回滚。 六、总结
自建元数据中心后将给彩虹桥带来一系列收益 应用服务通过 SDK 直接连接 Proxy 节点摆脱了对 SLB 的依赖解决了带宽瓶颈和额外网络开销问题并提高了流量灰度控制的精细度。 简化了扩容流程扩容时只需增加 Proxy 节点大大缩短整个扩容时间。 多可用区容灾实现自动故障转移无需人工干预。 SDK 具备了同 AZ 路由能力更好适配双活架构。 往期回顾
1.得物精准测试平台设计与实现
2.解析Go切片为何按值传递时会发生改变得物技术
3.基于IM场景下的Wasm初探提升Web应用性能得物技术
4.实时特征框架的生产实践得物技术
5.商家下载中心设计演进之路得物技术 关注得物技术每周一、三更新技术干货
要是觉得文章对你有帮助的话欢迎评论转发点赞
未经得物技术许可严禁转载否则依法追究法律责任。
