集成:在服务提供端或者调用端,如何集成注册中心?应用内 OR 应用外
测活:服务注册之后,如何对服务进行测活以保证服务的可用性
负载均衡:当存在多个服务提供者时,如何均衡各个提供者的负载?
运行时依赖:引入注册中心之后,对应用的运行时环境有何影响?
可用性:如何保证注册中心本身的可用性,特别是消除单点故障?
状态获取:(1)主动探测(2)心跳上报
一些可能问题:
- 保护机制:如果短时间内摘除的节点数量超过集群的40%,则停止摘除节点
- 通知风暴问题(准备更多的注册中心节点;精简通知内容)
目前比较流行的解决方案包括:
对比维度 | euraka | consul | ZK |
---|---|---|---|
实现思路 | 去中心化,通过复制来同步数据,但不保证一致性。只要有一个节点可用,系统整体就可用。 | 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案 | 使用ZK节点临时节点来维护服务器列表,ZK支持watch节点变更通知机制 |
测活 | 客户端心跳 | TCP/HTTP/gRPC/Cmd | 自研-客户端心跳 |
负载均衡 | Ribbon | Fabio | 自研-负载均衡 |
雪崩保护 | 有,灾难态进入自我保护模式 | 无 | 自研 |
自动注销实例 | 支持 | 支持 | 进程不可用,临时节点自动销毁 |
访问协议 | HTTP | HTTP/DNS | 自研 |
监听支持 | 支持 | 支持 | WATCH NODE变更 |
多数据中心 | 支持 | 支持 | 不支持 |
跨注册中心同步 | 支持 | 支持 | 不支持 |
框架集成 | SpingCloud继承 | Spring、k8s集成 | 无 |
优点 | 去中心化,高可用 | 功能相对完善 | 简单容易实现,适用于初创期 |
不足 | 一致性差 | 可用性无保证 | 服务可用性无保障 ZK跨机房集群支持不佳 |
CAP | AP | CP | CP |
一致性协议 | 仅复制,非强一致 | raft | zab,一种类paxos协议 |