集成：在服务提供端或者调用端，如何集成注册中心？应用内 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协议 |
