远程调用的问题以及eureka原理

目录

服务调用出现的问题

问题分析

解决方案（eureka原理）

eureka（两个角色）

eureka的解决方案

此过程出现的问题

eureka的作用

总结

服务调用出现的问题

• 服务消费者该如何获取服务提供者的地址信息？
• 如果有多个服务提供者，消费者该如何选择？
• 消费者如何得知服务提供者的健康状态？

问题分析

订单服务远程调用用户服务，采用的方式是发起一起http请求，并且采用硬编码的形式

String url = "http://localhost:8081/user/" + order.getUserId();
User user = restTemplate.getForObject(url, User.class);

在实际开发中会有开发环境，测试环境等等，环境的变更服务的地址可能会变化，如果采用硬编码的形式，在每次环境变更中都要重新更改地址打包，不利于维护。以后在应对更高的并发，用户服务可能会部署成多实例，形成一个集群。

采用硬编码的形式只会调用其中一个服务，那么其他的实例就没有存在的意义了

解决方案（eureka原理）

eureka（两个角色）

• 服务端，也可以叫注册中心，其作用是用于注册以及管理微服务
• 消费者和提供者，统称为客户端

eureka的解决方案

1. 客户端将自己的信息提供给eureka（服务名称，端口号等等）
2. 消费者向eureka提供自己的需求拉取服务
3. 消费者拿到了服务再利用负载均衡向提供者拉取信息

此过程出现的问题

假如有一个集群，消费者向eureka拿到的服务挂了怎么办？

客户端每30s向服务端发送一次自己服务器的健康状态，如果已经挂掉了，eureka就会将已经挂掉的服务踢出去，消费者将无法拉取已经挂掉的服务

eureka的作用

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

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

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

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

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

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

总结

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

• EurekaServer：服务端，注册中心
  • 记录服务信息
  • 心跳监控
• EurekaClient：客户端
  • Provider：服务提供者，例如案例中的 user-service
    • 注册自己的信息到EurekaServer
    • 每隔30秒向EurekaServer发送心跳
  • consumer：服务消费者，例如案例中的 order-service
    • 根据服务名称从EurekaServer拉取服务列表
    • 基于服务列表做负载均衡，选中一个微服务后发起远程调用