注册中心（一）

注册中心（一）

业务痛点

项目的架构从以前的单体结构发展到现在的微服务。不仅服务的数量变的多了，而且服务都是多节点的部署。

假如在serviceA去调用serviceB，当serviceA会在配置中配置一个serviceB的ip和port进行通信。

当serviceB有10个节点的时候，我们就需要配置10个ip地址，这样做没有任何问题。

• 服务配置困难：当serviceB其中的某一个节点挂掉的时候，serviceA去调用的时候，总会发现其中一些有异常。而挂掉的节点无法serviceA无法感知到，会导致serviceA服务的一些调用也出现异常。这种也可以基于域名去做，但是服务的上线与下线每次都需要对域名进行配置。

• 服务上下线动态感知：当serviceB因为业务的增长，从10个节点扩展到12个节点，那么需要在serviceA中修改之前配置的10个ip地址。那么当serviceB被10个其他服务甚至更多的服务去调用的时候，那么这10个节点都需要进行更新。

如下图中，红色的serviceB是一个挂掉的服务，而虚线的是一个扩容的服务。

这两个问题如何解决，那么就有人去做一个注册中心的组件。

注册中心模型

注册中心的出现解决了我们的痛点。那么注册中心都会包含哪些功能呢

• 服务地址统一管理：管理所有服务的所有地址信息，设计一个key，value形式的集合存储起来。

  serviceA在启动的时候，就会去注册中心去获取serviceB的通讯地址，而不用写到配置文件中了；

  serviceA这个时候只需要维护注册中心的ip和port就可以，根据目标服务的名称去调用目标服务。

• 服务上下线动态感知：

  通过心跳机制或者探针机制去感知服务的状态，从而维护在注册中心的节点。java中一般是通过socket（TCP）来感知。

注册中心和服务间的通信

服务和注册中心之间一定存在通信，因为要获取到调用服务的地址。

pull

拉取的方式，serviceA自己维护一个定时器，每隔N秒就会去请求一次最新的serviceB的服务节点列表，然后存储在自己的缓存中。

• 缺点
  • 有延迟，在上次请求和这次请求之间会存在服务列表不一致的情况出现，最坏的场景是N秒。
  • serviceA去请求注册中心会增加serviceA节点的开销，注册中心也有一定的压力。
• 优点
  • 注册中心无需推送，注册中心的压力会比较小。

push

注册中心会维护一个通信通道，在serviceB节点地址列表发生变更的时候，主动去通知serviceA。

• 缺点
  • 服务端需要维护通信通道，在服务节点特别多的时候，注册中心需要不断的检测通信通道是否正常（心跳包）。
• 优点
  • 实时，维护一个通信通道，在注册中心地址发生变更的时候，第一时间通知到serviceA。

市面上流行的注册中心

1. nacos
2. redis
3. etcd
4. consule
5. zookeeper
6. eureka

注册中心对比

Nacos

数据存储：存储在内存中（ConcurrentHashMap）

通信协议：默认gRPC，支持http

心跳：自带心跳机制

数据变更推送方式：push（udp）、pull

CAP模型：支持AP和CP，默认AP

Eureka

数据存储：存储在内存中NodeDataBase（树形），持久化在文件中， 每次启动都会加载到内存中

通信协议：http

心跳：自带心跳机制

数据变更推送方式：pull（30s）

CAP模型：AP

zookeeper

数据存储：存储在内存中（ConcurrentHashMap）

通信协议：jute协议

心跳：自带心跳机制

数据变更推送方式：watch（push）

CAP模型：CP