0%

服务注册中心

服务注册中心

在之前服务规模较小时,可以使用硬编码的方式来将服务地址写在代码中,通过编码的方式来实现服务的路由和负载均衡的问题,也可以使用硬件负载均衡设备(如F5)或者软件负载均衡(如nginx和lvs)等方式来进行处理。但微服务中服务很多,如果使用硬编码提供者的地址的话,管理起来不方便,而且可能会出现单点问题

服务注册与查询

为了避免单点故障,出现了注册中心,用来动态注册和获取服务信息,来统一进行管理服务名称和对应的服务器列表信息

服务提供者、服务消费者、注册中心关系

  • 微服务启动时,将自己的网络地址等信息注册到注册中心中,注册中心会存储这些信息
  • 服务消费者可以从注册中心中查询到服务提供者的网络地址,并使用该地址调用服务提供者的接口
  • 各个微服务与注册中心使用一定机制(如心跳)通信,如果注册中心长时间无法与微服务实例通信成功,则注销该实例
  • 微服务网络地址发生变更时,会重新注册到注册中心

服务提供者在启动的时候,将其提供的服务名称,服务器地址注册到服务配置中心,服务消费者通过服务配置中心来获得需要调用的服务的机器列表,通过相应的负载均衡算法,选取其中一台服务器进行调用,当服务器宕机或者下线的时候,相应的机器需要能够动态的从服务配置中心里面移除,并通知相应的服务消费者,否则服务消费者就有可能调用到已经失效的服务而发生错误。

在这个过程中,服务消费者只有在第一次调用服务的时候需要查询服务配置中心,然后将查询到的信息缓存到本地,后面的调用直接使用本地缓存的服务地址列表信息,而不需要重新发起请求到服务配置中心去获取相应的服务地址列表,直到服务的地址列表有变更(机器上线或者下线),这种无中心化的结构,解决了之前负载均衡设备所导致的单点故障的问题,并且大大减轻了服务配置中心的压力。

功能

  • 服务注册表,记录各个微服务的信息,对这些信息进行查询和管理
  • 服务注册与发现,服务注册是指微服务启动时,将自己的信息注册到注册中心;服务发现是指查询可用微服务列表及其网络地址
  • 服务检查,使用一定机制检测已注册的服务,如果长时间无法访问,则将该实例移除

实现

常见的用来作为注册中心的有Eureka、Consul、zookeeper等

欢迎关注我的其它发布渠道