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端。