微服务框架 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架构中，微服务角色有两类：

相关阅读:
单体、分布式、微服务架构发展
Java：既然有了synchronized，为什么还要提供Lock？
源码解析springbatch的job是如何运行的？
LeetCode 300. 最长递增子序列
使用py-redis分布式锁解决超卖问题——微服务总结（一）
基于改进滑模、经典滑模、最优滑模控制的永磁同步电机调速系统MATLAB仿真
首选电商淘宝商品详情API接口（数据获取）
EasyExcel单字段自定义转换@ExcelProperty::converter无效
Windows自带虚拟机的使用方法
[学习记录] 设计模式 1. 单例模式实现

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