在博文：微服务系列(1)里我们提到过注册中心的概念，简单来说微服务注册中心是一个用于存储和管理微服务实例信息的组件，它提供了服务注册、服务发现、服务健康检查等功能，以确保微服务之间的稳定通信。在微服务架构中，各个服务实例将自己的信息注册到注册中心，同时从中心获取其他服务的实例信息以进行通信。当一个服务实例发生故障或下线时，注册中心会自动将其从服务列表中移除，从而确保其他服务实例获取到的服务列表始终是可用的。
举个栗子：
有两个服务，consumer和provider，各自都采用了多副本部署。一般来说，consumer在调用provider时，会访问provider服务所暴露出来的负载均衡ip，一旦负载均衡ip改变了，开发者就不得不采用一些手段修改客户端服务的请求地址。
但如果我们引入了注册中心这个中间层，provider服务在每一次启动时，都会向注册中心注册自己的信息（名称、地址、端口、标签等matedata），这样，consumer侧就无需在意provider侧的ip变化，只需要每次向注册中心“拿”就可以了。
微服务的注册中心目前主流的有以下四种：
- Zookeeper
- Eureka
- Consul
- Kubernetes
（由于本人工作和consul打交道更多，这里我们主要聊consul）
consul
consul的介绍
Consul是由HashiCorp公司推出的一款开源工具，是一个分布式的、高可用的、高性能的服务注册与发现系统，它提供了服务注册、服务发现、健康检查、KV存储等功能。
consul的工作原理
-
节点类型
Consul主要由以下两种节点组成：
Server节点：Server节点负责存储服务实例的注册信息、健康检查状态等元数据。一个Consul集群通常包含3个或5个Server节点，以实现高可用性。Server节点之间通过Raft协议进行数据同步和选举Leader。
Client节点：Client节点负责转发服务注册、查询等请求到Server节点，并缓存部分数据以提高查询性能。Client节点通常部署在每台微服务所在的主机上，以实现服务实例与Consul的紧密集成。
Agent：在Consul集群的每一个节点，都会运行一个Agent进程，agent分为client和server两种模式。以后细说。 -
服务注册
微服务实例可以通过HTTP API或者配置文件的方式将自己的信息注册到Consul中。注册信息包括服务名称、地址、端口、标签等元数据。Client节点会将服务实例的注册信息转发到Server节点，并存储在内部的数据结构中。 -
服务发现
当一个服务实例需要与另一个服务进行通信时，它可以通过查询Consul获取目标服务的实例信息。 -
健康检查
Consul支持的健康检查类型包括http，tcp，script。
HTTP检查：注册中心定期向服务实例的指定HTTP端点发送请求，根据HTTP响应状态码判断服务实例是否健康；
TCP检查：注册中心定期尝试与服务实例的指定TCP端口建立连接，根据连接是否成功判断服务实例是否健康；
命令行检查：定期执行命名（比如：ls/ifconfig），退出状态码为0表示服务实例健康。 -
数据同步
Consul使用Raft协议确保Server节点之间的数据同步。通过Raft协议，Consul可以在多个Server节点之间复制数据，实现强一致性。此外，Raft协议还用于选举Leader节点，以确保集群中只有一个节点负责处理写请求。 -
Gossip协议
Gossip协议是一种基于UDP的轻量级通信协议，consul使用Gossip协议实现集群节点之间的成员关系管理和事件传播。
)
)
