Eureka
客户端实现原理
服务端实现原理
注册中心比较
| 比较点 | Eureka | Zookeeper | Consul | Nacos |
|---|---|---|---|---|
| 一致性 | AP（最终一致性） | CP（强一致性） | CP | CP+AP |
| 时效性 | 服务注册心跳时间 注册表检查时间 readwrite 同步到 readonly时间 消费方拉取readonly注册表时间 |
快，强一致性 | 快，强一致性 | CP 快 AP 慢 |
| 适用规模 | 20K~30K实例（节点） | 10K~20K实例（节点） | < 3K实例（节点） | |
| 通信方式 | Http Rest | 自定义协议 | Http Rest | HTTP/DNS |
| 集群模式 | Peer 2 Peer（服务器之间） | leader 读/写 follower 读 |
Agent 监听的方式 | |
| 性能问题 | 简单的更新机制， 设计复杂（扩容麻烦） |
扩容麻烦， 规模较大时GC频繁 |
3K节点以上， 更新列表缓慢 |
|
| 运维熟悉度 | 相对陌生 | 熟悉 | 更陌生 | |
| 一次性协议 | http定时轮询 | ZAB | RAFT |
为什么推荐使用 ZK 作为 Spring Cloud 的基础设施
一致性模型
维护相对熟悉
配置中心饿服务注册中心单一化
尽可能用@EnableDiscoveryClient
他支持多种注册中心。@EnableEurekaClient只支持 eureka
注册中心重复节点问题
问题
3节点 重启，注册服务中心没有来得及删除节点。
然后3节点又注册过来，注册了新的节点，同时老节点还在。
解决办法
- 注册增加service Id计算（不太懂）
-
解决注册服务中心 可以支持高节点
读取
网关读取注册服务和服务实例列表
- 持久化到db或者放到redis缓存中
- 网关定时拉取注册中心的服务信息。
-
注册
客户端服务正常注册到注册中心
若有收获，就点个赞吧
0 人点赞
