Eureka服务注册与发现

首先来看一下服务治理的简单架构图

image

服务注册中心#

• 失效剔除 当我们人为主动进行服务下线，注册中心会受到注册实例的服务下线的请求，进而维护的有效服务列表的时效性。但我们还不可避免地会遇到其他不可预期的事情，比如网络故障、内存溢出等等情况，会导致我们的服务实例与注册中心失去联系，但却没有发送服务下线请求，故需要一个机制来应付这种场景——注册中心在启动时候会创建一个定时任务，默认每隔一段时间（默认60秒）将当前服务清单中超时（默认为90秒）没有续约的服务实例剔除出去
  • 设置失效剔除时间,单位ms eureka.server.eviction-interval-timer-in-ms=60000
• 自我保护 服务的有效信息靠服务注册中心通过心跳机制来维护，那要是服务注册中心自己出问题了呢？服务注册中心认为，少数服务失效是服务实例的故障，而大多数的服务失效则认为是自己的故障。Eureka通过一个自我保护机制来实现：服务注册到Eureka Server之后，会维护一个心跳连接，那么Eureka Server在运行期间会统计心跳失败的比例在15分钟内是否低于85%，如果出现低于的情况，Eureka Server会将当前的实例注册信息保护起来，不会让它们立刻过期。
  • 关闭自我保护机制 eureka.server.enable-self-preservation=false

  注意： 保护机制在生产环境中，通常是为了防止因网络原因而导致原本没有问题的服务被清除。而如果真的是大面积服务失效，那么久需要服务容错机制了，往后会提到的熔断器。因此一旦开启了保护机制，则服务注册中心维护的服务实例就不是那么准确了。 关于自我保护机制更深入了解，可参考Spring Eureka自我保护机制

服务提供者#

• 服务注册 “服务提供者”在启动的时候会通过REST请求的方式将自己注册到服务注册中心上，并将自身的一些信息一块带上。服务中心对之进行接收保存并更新服务清单，并对其他注册的服务实例进行广播 源码解读可参考EUREKA服务注册源码品读
• 服务同步 如架构图所示，这里的两个微服务提供者分别注册到两个不同的服务注册中心上，也就是说，它们的信息分别被两个服务注册中心所维护。此时由于服务注册中心之间因互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的注册中心，从而实现注册中心之间的服务同步。通过服务同步，两个服务提供者的服务信息就可以通过这两台服务注册中心中的任意一台获取
• 服务续约 在注册完服务之后，服务提供者通过心跳机制来告知服务注册中心“我还活着”，以防止服务中心的“失效剔除”定时任务将服务进行剔除，我们称该操作为服务续约
  • 定义服务续约间隔，默认30 eureka.instance.lease-renewal-interval-in-seconds=30
  • 定义服务失效时间，默认90 eureka.instance.lease-expiration-duration-in-seconds=90

服务消费者#

• 获取服务 当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务清单来返回给客户端，同时该缓存清单会每隔30秒更新一次。
  • 想服务注册中心注册 eureka.client.register-with-eureka=true
  • 修改缓存服务清单时间间隔,默认30s eureka.client.registry-fetch-interval-seconds=30
• 服务调用 服务消费者通过上面提到的获取服务清单后，就可以拿到的想要调用的服务提供者的详细信息，然后根据自身需求进行服务调用
• 服务下线 在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭期间，我们自然不希望客户端会继续调用关闭了的实例。所以客户端程序中，当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线了”。服务端在接收到请求之后，将该服务状态设置为（DOWN），并把该下线事件传播出去。