【SpringCloud】Ereka-eureka原理分析

Eureka注册中心

在之前的案例中，我们有一个订单服务和一个用户服务，订单服务需要远程调用我们的用户服务。它采用的方式是发起一次http请求。我们是将UserService服务的ip和端口硬编码在代码当中的。

这样的一种写法，它其实是有一定问题的：在公司里开发的时候，我们会有开发环境、测试环境、生产环境等等，每一次环境的变更，可能服务的地址也会发生变化。而且为了应付更多的并发，User服务可能会部署成多实例，形成一个集群，那这个时候，硬编码该写谁的地址呢。

假如我们的服务提供者user-service部署了多个实例，如图：

大家思考几个问题：

• order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？
• 有多个user-service实例地址，order-service调用时该如何选择？
• order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

Eureka的结构和作用

这些问题都需要利用SpringCloud中的注册中心来解决，其中最广为人知的注册中心就是Eureka，其结构如下，起到的作用就是：记录和管理微服务。

user-service（服务提供者）和order-service（服务消费者）。不管是消费者还是提供者，都是微服务，所以统称为Eureka的客户端。

只要是Eureka的客户端，在启动的时候都会把自己的信息注册给Eureka。Eureka会把你的名字记录下来（user-service名称、ip端口）。

这样order-service直接去找Eureka要user-service，然后Eureka就会返回给你地址信息。

然后再利用负载均衡从三个user-service中挑一个，向挑好的发请求，并且挑好的这个不可能是挂的，因为服务每隔30秒钟都会向Eureka发一次心跳，来确认一下自己的状态。如果有一天它不跳了，就会把它从列表中剃掉。

回答之前的各个问题。

问题1：消费者该如何获取服务提供者具体信息？

获取地址信息的流程如下：

• user-service服务实例启动后，将自己的信息注册到eureka-server（Eureka服务端）。这个叫服务注册。
• eureka-server保存服务名称到服务实例地址列表的映射关系
• order-service根据服务名称，拉取实例地址列表。这个叫服务发现或服务拉取。

问题2：如果有多个服务提供者，消费者该如何选择？

• order-service从实例列表中利用负载均衡算法选中一个实例地址
• 向该实例地址发起远程调用

问题3：消费者如何感知服务提供者健康状态？

• user-service会每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态，称为心跳
• 当超过一定时间没有发送心跳时，eureka-server会认为微服务实例故障，将该实例从服务列表中剔除
• order-service拉取服务时，就能将故障实例排除了

在Eureka架构中，微服务角色有两类

EurekaServer：服务端，注册中心

• 记录服务信息

• 心跳监控

EurekaClient：客户端

• Provider：服务提供者，例如案例中的 user-service

  注册自己的信息到EurekaServer

  每隔30秒向EurekaServer发送心跳

• consumer：服务消费者，例如案例中的 order-service

  根据服务名称从EurekaServer拉取服务列表

  基于服务列表做负载均衡，选中一个微服务后发起远程调用

注意：一个微服务，既可以是服务提供者，又可以是服务消费者，因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端。