四、系统设计
4.1 系统架构图
4.2 原理解析
XXL-REGISTRY内部通过广播机制,集群节点实时同步服务注册信息,确保一致。客户端借助 long pollong 实时感知服务注册信息,简洁、高效;
4.3 跨机房(异地多活)
得益于服务注册中心集群关系对等特性,集群各节点提供幂等的服务注册服务;因此,异地跨机房部署时,只需要请求本机房服务注册中心即可,实现异地多活;
举个例子:比如机房A、B 内分别部署服务注册中心集群节点。即机房A部署 a1、a2 两个服务注册中心服务节点,机房B部署 b1、b2 两个服务注册中心服务节点;
那么各机房内应用只需要请求本机房内部署的服务注册中心节点即可,不需要跨机房调用。即机房A内业务应用请求 a1、a2 获取配置、机房B内业务应用 b1、b2 获取配置。
这种跨机房部署方式实现了配置服务的 “异地多活”,拥有以下几点好处:
- 1、注册服务响应更快:注册请求本机房内搞定;
- 2、注册服务更稳定:注册请求不需要跨机房,不需要考虑复杂的网络情况,更加稳定;
- 2、容灾性:即使一个机房内服务注册中心全部宕机,仅会影响到本机房内应用加载服务,其他机房不会受到影响。
4.4 一致性
类似 Raft 方案,更轻量级、稳定;
- Raft:Leader统一处理变更操作请求,一致性协议的作用具化为保证节点间操作日志副本(log replication)一致,以term作为逻辑时钟(logical clock)保证时序,节点运行相同状态机(state machine)得到一致结果。
- xxl-registry:
- Leader(统一处理分发变更请求):DB消息表(仅变更时产生消息,消息量较小,而且消息轮训存在间隔,因此消息表压力不会太大;);
- state machine(顺序操作日志副本并保证结果一直):顺序消费消息,保证本地数据一致,并通过周期全量同步进一步保证一致性;