微服务框架 SpringCloud微服务架构 3 Eureka 3.2 Eureka 原理分析

微服务框架

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】

SpringCloud微服务架构

3 Eureka

3.2 Eureka 原理分析

3.2.1 服务调用出现的问题

在我们之前的Demo 案例中，出现了下图所示的调用情况

而且是采用硬编码的形式，把IP和端口告诉order 服务

这样也很容易地就带来一些问题，这样写死了，环境改变了怎么办？耦合度巨高

而且随着服务的高并发，user 服务可能会部署成多个实例，

这样时候，硬编码咋办？【所以这里一定不能用硬编码】

【归结一个问题：服务消费者到底应该如何获取服务提供者的地址信息？】

而且有一天，咱们真的拿到了它们每台的地址，有多个服务提供者的情况，消费者又该如何选择？

而且，消费者又如何得知服务提供者的健康状态？ 【…一堆的问题】

【这个时候就可以请出 Eureka了】

3.2.2 Eureka 的作用

一个服务端，一个客户端

在每一个 user-service 和 order-service 启动的那一刻，会把自己的信息注册给Eureka

现在当有消费者想要消费服务时，就直接找Eureka

这样第一个问题 【服务消费者到底应该如何获取服务提供者的地址信息】 就解决了

接着通过负载均衡，从三个中挑一个出来

再接下去，就可以发请求了

【怎么保证服务是健康的？】

心跳续约，每30 s 一次，来让注册中心确认自己的状态

如果说有天 user-service 8083 没跳了，注册中心就会把它从信息中删除

order-service 再次拉取服务信息时，就不会拉到8083 了

【即消费者可以监控到服务提供者的状态】

回顾一下“三个问题”

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

   • 服务提供者启动时向eureka注册自己的信息
   • eureka保存这些信息
   • 消费者根据服务名称向eureka拉取提供者信息

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

   • 服务消费者利用负载均衡算法，从服务列表中挑选一个

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

   • 服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
   • eureka会更新记录服务列表信息，心跳不正常会被剔除
   • 消费者就可以拉取到最新的信息

3.2.3 总结

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

• EurekaServer：服务端，注册中心

  • 记录服务信息
  • 心跳监控

• EurekaClient：客户端

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

    • 注册自己的信息到EurekaServer
    • 每隔30秒向EurekaServer发送心跳

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

    • 根据服务名称从EurekaServer拉取服务列表
    • 基于服务列表做负载均衡，选中一个微服务后发起远程调用