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

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

在这里插入图片描述

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

在这里插入图片描述

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

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

在这里插入图片描述

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

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

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

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

在这里插入图片描述

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

在这里插入图片描述

一个服务端，一个客户端

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

在这里插入图片描述

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

在这里插入图片描述

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

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

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

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

在这里插入图片描述

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

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

在这里插入图片描述

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

回顾一下“三个问题”

消费者该如何获取服务提供者具体信息？
- 服务提供者启动时向eureka注册自己的信息
- eureka保存这些信息
- 消费者根据服务名称向eureka拉取提供者信息
如果有多个服务提供者，消费者该如何选择？
- 服务消费者利用负载均衡算法，从服务列表中挑选一个
消费者如何感知服务提供者健康状态？
- 服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
- eureka会更新记录服务列表信息，心跳不正常会被剔除
- 消费者就可以拉取到最新的信息

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

相关阅读:
[gstreamer] overview of gstreamer
统信UOS升级Python3及安装spyder5
论文解读：SlowFast Networks for Video Recognition
【前沿】数据目录是什么？您为何需要它？
基于 Rainbond 部署 DolphinScheduler 高可用集群
并发编程中的金光咒-锁（基础版）
B端产品经理和C端产品经理，做哪个更好？
Java开发学习---Bean基础配置及其作用范围
蓝桥杯2024年第十五届省赛真题-小球反弹
Ribbon负载均衡服务调用

原文地址：https://blog.csdn.net/weixin_44226181/article/details/128073234