注册中心(一)

注册中心(一)

业务痛点

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

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

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

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

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

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

注册中心(一)_第1张图片

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

注册中心(一)_第2张图片

注册中心模型

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

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

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

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

  • 服务上下线动态感知:

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

注册中心(一)_第3张图片

注册中心和服务间的通信

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

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

你可能感兴趣的:(spring,cloud,java,分布式,运维)