# Zookeeper注册发现
# Zookeeper是服务发现最佳选择么
# CAP理论
- C
- A
- P
# 注册中心需求分析及关键设计考量
数据一致性需求：最终一致性
分区容忍及可用性：注册中心不能因为自身原因破坏服务之间本身连通性
- 举例：孤岛机房内网络正常，可能无法使用本机房的服务
服务规模、容量、服务连通性
写无法扩展
- 频繁发布时，服务注册的写请求
- 毫秒级服务健康状态的写清求
实时地址列表和健康状态，不太需要执久化存储和事务日志
- ZAV写会在ZK所有节点上保持一个事务日志，定期有Snapshot到磁盘保证一致性和执久性，及可恢复
选举期间集群不可用，leader宕机30～120s
健康状态依赖业务方自己定义，而不是TCP长连接活性探测
- K8s：liveness和readness健康检查
- Eureka：服务状态，健康检查
弱依赖，仅在服务发布、上下线机器，服务扩缩容等才依赖注册中心
- Eureka精心设计的Client，注册中心不可用时的容灾处理，客户端缓存，注册中心缓存
- K8s：生命周期管理
- zk原生客户端无此能力，并且运维好使用好并不容易
- Client/Session状态机复杂：长连接/Session管理，Ephemeral ZNode，Event&Notification，Ping机制...
- 异常处理
- ConnectionLossException与Disconnected事件
- SessionExpiredException 和 SessionExpired 事件
- 使用做集群管理80%分掉坑
应用对 ZooKeeper 申请使用的时候要进行严格的场景、容量、SLA 需求的评估
# Eureka
- Peer to Peer对等通信，去中心化，无master/slave之分，最终一致性，一段时间没有收到服务实例心跳（30s）则注销实例（90s）
ps:
综合对比ZooKeeper、Eureka、Consul 、Nacos等微服务注册中心，用途及优缺点分析 (opens new window)