目录
服务调用出现的问题
服务调用出现的问题
- 服务消费者该如何获取服务提供者的地址信息?
- 如果有多个服务提供者,消费者该如何选择?
- 消费者如何得知服务提供者的健康状态?
问题分析
订单服务远程调用用户服务,采用的方式是发起一起http请求,并且采用硬编码的形式
String url = "http://localhost:8081/user/" + order.getUserId();
User user = restTemplate.getForObject(url, User.class);
在实际开发中会有开发环境,测试环境等等,环境的变更服务的地址可能会变化,如果采用硬编码的形式,在每次环境变更中都要重新更改地址打包,不利于维护。以后在应对更高的并发,用户服务可能会部署成多实例,形成一个集群。
采用硬编码的形式只会调用其中一个服务,那么其他的实例就没有存在的意义了
解决方案(eureka原理)
eureka(两个角色)
- 服务端,也可以叫注册中心,其作用是用于注册以及管理微服务
- 消费者和提供者,统称为客户端
eureka的解决方案
- 客户端将自己的信息提供给eureka(服务名称,端口号等等)
- 消费者向eureka提供自己的需求拉取服务
- 消费者拿到了服务再利用负载均衡向提供者拉取信息
此过程出现的问题
假如有一个集群,消费者向eureka拿到的服务挂了怎么办?
客户端每30s向服务端发送一次自己服务器的健康状态,如果已经挂掉了,eureka就会将已经挂掉的服务踢出去,消费者将无法拉取已经挂掉的服务
eureka的作用
消费者该如何获取服务提供者具体信息?
- 服务提供者启动时向eureka注册自己的信息
- eureka保存这些信息
- 消费者根据服务名称向eureka拉取提供者信息
如果有多个服务提供者,消费者该如何选择?
- 服务消费者利用负载均衡算法,从服务列表中挑选一个
消费者如何感知服务提供者健康状态?
- 服务提供者会每隔30秒向EurekaServer发送心跳请求,报告健康状态
- eureka会更新记录服务列表信息,心跳不正常会被剔除
- 消费者就可以拉取到最新的信息
总结
在Eureka架构中,微服务角色有两类:
- EurekaServer:服务端,注册中心
- 记录服务信息
- 心跳监控
- EurekaClient:客户端
- Provider:服务提供者,例如案例中的 user-service
- 注册自己的信息到EurekaServer
- 每隔30秒向EurekaServer发送心跳
- consumer:服务消费者,例如案例中的 order-service
- 根据服务名称从EurekaServer拉取服务列表
- 基于服务列表做负载均衡,选中一个微服务后发起远程调用
- Provider:服务提供者,例如案例中的 user-service