彩虹桥架构演进之路

一、前言

一年一更的彩虹桥系列又来了，在前面两期咱们分享了在稳固性和性能2个层面的一些演进&优化思绪。近期咱们针对彩虹桥 Proxy 负载平衡层面的架构做了一次性更新，目前新架构曾经部署成功，消费环境正在逐渐更新中，借此时机更新一下彩虹桥架构演进之路系列的第三篇。

二、背景

彩虹桥目前依赖 SLB 做负载平衡和节点发现，随着业务开展流量越来越高，SLB 带宽瓶颈逐渐暴露，只管在半年前做过一次性双 SLB 变革暂时处置了带宽瓶颈，但运维老本也随之变高。除了带宽瓶颈外，SLB 无法允许同区优先访问，造成难以适配双活架构。所以预备去除彩虹桥对 SLB 的强依赖，自建彩虹桥元数据中心，提供负载平衡和节点发现等才干，同时允许同区访问等才干来更好的适配双活架构。上方会详细引见一下彩虹桥元数据中心以及 SDK 关系才干的关系细节。

三、外围称号解释

四、现有架构回忆

在开局引见彩虹桥元数据中心之前，咱们先来回忆一下彩虹桥目前架构，以及存在的一些痛点。

现有架构

重要痛点

五、自建元数据中心&SDK 增强

图片元数据中心独立部署

架构详解

Metadata 数据库

节点启动时

 node_info weight   config_version   cluster_name  ?  address  ?

节点运转时

 node_info  beat_version  beat_version   cluster_name  ?  address  ?

节点下线

MetaCenter( Heimdall)

初始化心跳版本号：记载一切 metadata 数据库每个节点最新 beat_version 和初始化心跳失落次数到内存

定时查问节点信息（3s 一次性），挑选可用节点并写入到内存中，提供 OpenAPI 给 SDK 调用，每个库均口头以下操作，最终会获取每个库的可用节点列表，最后把多个 list 求并集，获取最终的可用列表，写入到内存中。

查出一切列表数据后，对比内存中的 beat_version 与数据库中的 beat_version，如不相反则更新内存，假设相反说明对应节点心跳有失落，假设失落次数超越阈值，则剔除此节点。

节点列表中除了 ip、端口信息外，还有权重，启用形态属性， 这些属性都属于控制流变卦，假设产生2边数据库不分歧场景，以 config_version 最大的为准。

假设本次计算时有节点列表变动，会下发一个变卦事情到 ARK（value 为期间戳-秒），SDK 在收到次性能变卦后会立刻到 MetaCenter 拉取一次性节点列表，以补偿定时轮训的延时。

MetaCenter 提供的 OpenAPI 是经过计算后存入内存的数据，为了可以人工干预节点列表，须要允许开关一键切换至人工性能的节点列表数据。

SDK( Rainbow)

另外 SDK 允许一键灵活切换至走老架构模式（4层 SLB）

治理后盾

修正形态会去一切 metadata 数据库口头，只要一个库成功就前往成功，如一切库都修正失败，则前往失败。

 node_info enabled   config_version   ip  ?  port  ?

容灾才干

表格中的能否有影响和缺点复原期间均指 SDK-Proxy 的访问链路，Proxy-DB 链路不在范畴内。

参考以下期间线，可在30s左右成功复原。

一些思索

Q：为什么不用 sylas（得物注册中心产品）做注册中心，而是要自建元数据中心做服务发现？

彩虹桥和 sylas 均为 P0 级别服务，对稳固性要求极高，在架构设计之初须要充沛思索到相互依赖或许带来的级联缺点，在与注册中心关系同窗沟通后，选择自建彩虹桥元数据中心，成功自闭环。

Q：为什么不是传统的基于 Raft 协定的三节点来成功服务发现，而是用多套数据源做 merge？

Raft 是工程上经常使用较为宽泛的强分歧性、去中心化、高可用的共识算法，在散布式系统中，适用于高分歧性、容错性要求高的场景。但 Raft 协定须要保养指导者选举和日志复制等机制，性能开支较大，其次 Raft 协定相对复杂，在开发、保养、排障等方面会十分艰巨，反之驳回少数据源求并集的模式更繁难，同时也具有单节点缺点、整个可用区缺点以及跨区网络终止等多种复杂缺点下的容灾才干。

Q：如何在 SLB 切换到新架构的环节中保证稳固性？

可灰度：允许单个抢先节点粒度的灰度

可回滚：允许一键灵活切换至 SLB 架构

可观测：少量埋点数据可实时启动观测，有疑问可极速回滚。

六、总结

自建元数据中心后，将给彩虹桥带来一系列收益：