NOTE
2.6 如何设计注册中心
1. 什么是注册中心 - 记录了 服务名<- IP地址+Port 的映射关系，本质上和DNS没区别 - 2. 为什么需要注册中心 没有注册中心那么A调用B只能写死IP地址，不灵活 3. 如何实现注册中心 3.1. 服务端 3.1.1. 服务注册表 2. 中心化、强一致存储中间件。比如Zookeepe
这是历史学习笔记，可能存在过时或不完整的理解。
1. 什么是注册中心
- 记录了服务名<->IP地址+Port的映射关系，本质上和DNS没区别
2. 为什么需要注册中心
没有注册中心那么A调用B只能写死IP地址，不灵活
3. 如何实现注册中心
3.1. 服务端
3.1.1. 服务注册表
- 中心化、强一致存储中间件。比如Zookeeper(Zab算法)，etcd(Raft算法)
- 去中心化、弱一致实现。比如Eureka、Consul、Nacos
3.1.2. 基础设施
- 以基础设施（DNS）来实现服务发现。比如SkyDNS、CoreDNS
3.2. 客户端
3.2.1. 服务提供者
3.2.1.1. 服务注册
- 服务提供者启动完成后，调用注册中心API接口，写入服务名+IP地址+Port+状态
3.2.1.2. 服务注销
- 服务提供者定时上报心跳给注册中心，如果一段时间没有收到心跳把它从列表剔除
- 服务提供者关闭时主动调用注册中心的API下线
3.2.1.3. 服务负载均衡
3.2.2. 服务消费者
3.2.2.1. 服务发现
- poll：服务消费者定时请求注册中心
- push：注册中心推送给服务消费者。即长连接维持心跳
- long polling：服务消费者请求注册中心，注册中心hold住一段时间，有数据则返回
3.2.2.2. 服务路由
- 服务消费者通过服务提供者的名称，从注册中心拿到一堆节点列表。如果需要对这些节点进行过滤和选择，这个就是服务路由 路由规则有以下几种：
3.2.2.2.1. IP
- 指定IP访问，方便有时候测试和定位问题
3.2.2.2.2. 就近寻址
- 就近寻址：优先同一Zone内调用降低网络延迟。需要服务提供者注册的时候把机房的标识写入到注册中心，这样服务消费者调用是就可以根据自己的机房信息来决定路由
3.2.2.2.3. 服务分组
- 有可能需要部署多组服务分别不同消费方使用
3.2.2.2.4. 服务版本
- 版本化，支持灰度
3.2.2.2.5. 其他可选
- 故障注入、熔断、流量镜像等
4. 注册中心组件
4.1. Eureka
Eureka.md（原链接已失效）
4.2. Consul
consul.md（关联笔记尚未公开）
4.3. ETCD
etcd.md（关联笔记尚未公开）
4.4. Zookeeper
4.5. Kubernetes的DNS
5. 选型
5.1. Zookeeper vs Eureka
| Zookeeper | Eureka | |
|---|---|---|
| 集群模式 | leader、follower（只有leader写） | p2p（每个节点都可以写） |
| 一致性保障 | CP | AP |
| 时效性 | 默认几秒 | 默认1分钟 |