注册中心
三个角色
- 服务提供者:注册服务,并定时向注册中心发送心跳;
- 服务消费者:消费服务,从服务中心获取服务列表,并发起请求访问服务提供者;
- 服务注册中心:保存和刷新注册信息。
注册中心的主要功能
服务注册、服务发现、心跳检查、服务列表查询、健康检查等。
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,也是未来的一个方向,但是运维成本比较高。