注册中心
三个角色
- 服务提供者：注册服务，并定时向注册中心发送心跳；
- 服务消费者：消费服务，从服务中心获取服务列表，并发起请求访问服务提供者；
- 服务注册中心：保存和刷新注册信息。
注册中心的主要功能
服务注册、服务发现、心跳检查、服务列表查询、健康检查等。
CAP理论
- 一致性(Consistency)：所有节点在同一时间具有相同的数据；
- 可用性(Availability) ：保证每个请求不管成功或者失败都有响应；
- 分隔容忍(Partition tolerance) ：系统中任意信息的丢失或失败不会影响系统的继续运作。
P均满足，而A和C只能满足其一。
常见的注册中心
Zookeeper、Eureka、Nacos和Consul
Zookeeper
常常作为Dubbo微服务框架中的注册中心。
服务注册就是在Zookeeper中创建一个znode节点，节点包含了服务的ip、port、协议和序列化方式等。
Zookeeper为主从模式，主节点故障时，需要重新选举，耗时较长，选举过程中Zookeeper集群不可用，所以zk仅满足CAP理论的CP，不满足高可用。
Zookeeper是唯一采用“推拉结合”的方式同步服务端变化的注册中心。
Eureka
SpringCloud微服务框架默认的注册中心。
Eureka是集群模式，所有节点平等均可单独对外提供服务，满足高可用，属于
AP模型，是存在一定时间差的数据不一致性。
已停止维护。
Nacos
作为Eureka的替代品，无缝支持多个主流的分布式微服务框架，且支持动态配置服务。支持CP和AP两种模型，可以通过命令切换。
Consul
和Zookeeper一样也是CP模型，支持多数据中心。
go语言开发。
如何选型
首选AP模型，个人比较推荐Nacos，另外还有Kubnetes，也是未来的一个方向，但是运维成本比较高。
