Eureka 入门详解：一篇搞懂微服务中的服务注册与发现
前言
学习微服务的时候，我们经常会遇到一个词：
注册中心。
例如：
Eureka
Nacos
ZooKeeper
Consul
很多刚接触微服务的开发者会产生疑问：
为什么需要注册中心？
服务不是直接通过 HTTP 调用就可以了吗？
Eureka 到底保存了什么？
服务挂掉以后 Eureka 怎么知道？
Eureka 是不是帮我们转发 HTTP 请求？
Eureka 和 ZooKeeper 又有什么区别？
这篇文章就从这些问题开始，把 Eureka 的核心原理完整串起来。
先记住一句最重要的话：
Eureka 是一个服务注册与发现组件，它帮助微服务解决“服务在哪里，以及哪些服务当前可用”的问题。
Netflix 官方将 Eureka 定义为一个 RESTful 服务，主要用于服务发现、负载均衡和故障转移场景；Spring Cloud Netflix 当前仍然提供 Eureka Client 和 Eureka Server 集成。(GitHub )
一、为什么微服务需要 Eureka？
先不要急着学习 Eureka。
我们先看它到底解决了什么问题。
假设现在有一个非常简单的系统：
Order Service
|
↓
User Service
订单服务需要获取用户信息。
如果 User Service 只有一台服务器：
192.168.1.10:8080
我们完全可以在 Order Service 中写：
http://192.168.1.10:8080/users/10001
甚至配置成：
user-service:
url: http://192.168.1.10:8080
看起来没什么问题。
但是业务慢慢增长以后，User Service 一台服务器扛不住了。
于是增加到三台：
User Service
192.168.1.10:8080
192.168.1.11:8080
192.168.1.12:8080
这时候问题来了。
Order Service 到底调用谁？
┌→ 192.168.1.10:8080
Order Service ───┼→ 192.168.1.11:8080
└→ 192.168.1.12:8080
你当然可以把三个地址全部写进配置文件。
但是新的问题马上又来了。
今天：
192.168.1.10
192.168.1.11
192.168.1.12
明天扩容：
192.168.1.13
后天：
192.168.1.11
服务器挂了。
再过几天：
192.168.1.10
重新部署以后 IP 又变了。
如果每发生一次变化，都人工修改所有消费者配置：
Order Service
Payment Service
Product Service
Marketing Service
整个系统会非常难维护。
所以微服务真正需要解决的问题是：
服务实例的地址是动态变化的，消费者不能依赖写死的 IP。
于是注册中心出现了。
二、Eureka 可以理解成“微服务通讯录”
假设我们增加一个 Eureka Server：
Eureka Server
|
┌──────────┼──────────┐
↓ ↓ ↓
User-1 User-2 User-3
User Service 启动的时候，不再要求 Order Service 提前知道自己的地址。
而是主动告诉 Eureka：
我是：
user-service
我的地址：
192.168.1.10:8080
第二台告诉 Eureka：
user-service
192.168.1.11:8080
第三台：
user-service
192.168.1.12:8080
于是 Eureka 内部维护：
USER-SERVICE
├── 192.168.1.10:8080
├── 192.168.1.11:8080
└── 192.168.1.12:8080
Order Service 再需要调用用户服务时，就不用知道具体 IP 了。
只需要知道：
user-service
然后从 Eureka 获取：
192.168.1.10:8080
192.168.1.11:8080
192.168.1.12:8080
这就是：
服务发现。
三、Eureka 最核心的两个角色
Eureka 里面首先要理解两个角色：
Eureka Server
Eureka Client
1. Eureka Server
Eureka Server 就是：
注册中心服务器。
它主要负责维护：
有哪些服务？
每个服务有哪些实例？
每个实例在哪里？
哪些实例还活着？
例如：
Eureka Registry
USER-SERVICE
├── 10.0.0.1:8080
└── 10.0.0.2:8080
ORDER-SERVICE
├── 10.0.1.1:8081
└── 10.0.1.2:8081
PAYMENT-SERVICE
└── 10.0.2.1:8082
Spring Cloud 官方文档也明确说明，Eureka Server 可以保存注册服务信息，并可通过多个 Server 实例互相同步注册状态来实现更高可用。(Home )
四、Eureka Client 是什么？
微服务应用通常是：
Eureka Client。
例如：
user-service
order-service
payment-service
都可以是 Eureka Client。
一个 Eureka Client 通常可以同时拥有两种身份：
Provider
Consumer
例如：
Order Service
它给别人提供：
创建订单
查询订单
取消订单
所以它是：
Provider
但是 Order Service 又需要调用：
User Service
Product Service
Inventory Service
这时候它又是：
Consumer
因此一个微服务：
既可以向注册中心注册自己，也可以从注册中心发现其他服务。
五、什么叫服务注册？
Service Registration：
服务注册。
假设：
user-service
启动以后地址是：
10.0.0.1:8080
它会向 Eureka Server 发送自己的实例信息。
概念上类似：
serviceName = user-service
ip = 10.0.0.1
port = 8080
除此之外，实际注册信息还可以包含：
Hostname
Port
Health Check URL
Status Page URL
Home Page URL
Metadata
Spring Cloud 官方文档说明，Eureka Client 注册时会提交主机、端口、健康状态 URL、主页等服务元数据。(Home )
于是 Eureka Registry 中出现：
USER-SERVICE
└── 10.0.0.1:8080
第二台启动：
USER-SERVICE
├── 10.0.0.1:8080
└── 10.0.0.2:8080
第三台启动：
USER-SERVICE
├── 10.0.0.1:8080
├── 10.0.0.2:8080
└── 10.0.0.3:8080
这就是：
服务启动
↓
告诉 Eureka 自己是谁
↓
Eureka 保存实例
也就是：
服务注册。
六、什么叫服务发现？
现在 Order Service 要调用：
user-service
以前需要：
http://10.0.0.1:8080
现在只需要通过服务名称：
USER-SERVICE
去获取实例列表。
Eureka 返回：
10.0.0.1:8080
10.0.0.2:8080
10.0.0.3:8080
消费者获得这些实例以后，就可以选择其中一个进行调用。
这个过程：
Consumer
↓
查询注册中心
↓
获得 Provider 列表
就是：
Service Discovery，服务发现。
七、Eureka 会不会帮我们转发业务请求？
这是 Eureka 初学者非常容易理解错的地方。
很多人脑子里的架构是：
Order Service
↓
Eureka
↓
User Service
认为 HTTP 请求经过 Eureka。
这是错误的。
Eureka 主要帮助消费者：
找到服务地址。
真正业务调用通常仍然是消费者直接调用 Provider。
正确流程：
① 服务发现
Order ─────────────→ Eureka
↑ |
└──── Provider List ──┘
② 业务调用
Order ─────────────→ User Service
也就是说：
Eureka
不是：
API Gateway
也不是：
Reverse Proxy
它不是帮你转发每一次业务请求。
它主要是一个：
Service Registry
服务注册表。
八、为什么不能每次调用都去问 Eureka？
假设一个接口 QPS 为：
10000
如果每一次请求都这样：
Order Service
↓
Eureka：User Service 在哪里？
↓
返回 IP
↓
再调用 User Service
那意味着 Eureka 一秒可能被查询：
10000 次
如果几十个微服务全部这样干，注册中心本身马上成为系统瓶颈。
所以 Eureka Client 会维护：
本地服务注册信息缓存。
Spring Cloud 官方文档明确说明，Eureka 客户端在内存中缓存注册信息，因此不需要在每次服务调用时访问注册中心。(Home )
结构变成：
Eureka
|
| 拉取注册表
↓
Order Service
|
Local Registry
|
┌───────────┼───────────┐
↓ ↓ ↓
User1 User2 User3
Order Service 本地可能已经知道：
USER-SERVICE
10.0.0.1:8080
10.0.0.2:8080
10.0.0.3:8080
真正发生请求时：
Order
↓
读取本地服务实例列表
↓
选择一个 Provider
↓
直接调用
这也是为什么：
Eureka Server 短时间不可用，不一定意味着所有已有服务调用立刻全部失败。
因为客户端可能仍然保存着之前的服务实例信息。
九、那么到底调用哪一台 User Service？
假设 Eureka 告诉 Order：
USER-SERVICE
A = 10.0.0.1:8080
B = 10.0.0.2:8080
C = 10.0.0.3:8080
Order Service 不可能永远只调用 A。
否则：
A：CPU 100%
B：摸鱼
C：摸鱼
所以需要：
Load Balancing，负载均衡。
例如：
第 1 个请求 → A
第 2 个请求 → B
第 3 个请求 → C
第 4 个请求 → A
这种就叫：
Round Robin
轮询
还有：
Random
随机
Weight
权重
Least Connections
最少连接
Consistent Hash
一致性哈希
等等。
需要明确：
Eureka 主要解决服务注册与发现；客户端负载均衡则由对应客户端/负载均衡组件处理。
现代 Spring Cloud 可以通过 Spring Cloud LoadBalancer 使用 Eureka 提供的逻辑服务名称和实例信息。(Home )
十、Eureka 怎么知道服务还活着？
现在最关键的问题来了。
假设 Eureka 保存：
USER-SERVICE
10.0.0.1
10.0.0.2
10.0.0.3
突然：
10.0.0.2
服务器宕机。
Eureka 怎么知道？
答案就是：
Heartbeat
也就是：
心跳。
十一、什么叫 Eureka 心跳？
User Service 注册完成以后，不是：
注册一次
↓
永远不管
而是定期告诉 Eureka：
我还活着。
比如：
User Service
|
| Heartbeat
↓
Eureka
过一段时间：
User Service
|
| Heartbeat
↓
Eureka
继续：
我还活着。
这个过程叫：
Renew
也就是：
服务续约。
Spring Cloud 当前官方文档说明，Eureka 实例通过周期性心跳维持注册，默认续约周期为 30 秒，并且生产环境通常建议保留这个默认周期。(Home )
因此可以这样理解：
Register
↓
注册一次
Renew
↓
不断证明自己还活着
十二、如果服务直接宕机怎么办？
如果 User Service 正常关闭，可以主动告诉 Eureka：
我要下线了。
但是现实中经常不是正常关闭。
而是：
服务器断电
进程被 kill
JVM 崩溃
机器宕机
网络故障
这时候 User Service 根本没有机会主动说：
我要下线。
但是有一个现象非常明显：
它不再发送心跳。
于是 Eureka 发现：
这个实例已经很长时间没有续约了。
最终就可以把它从注册信息中剔除。
这个过程叫：
Eviction
也就是：
服务剔除。
于是：
原来：
USER-SERVICE
├── A
├── B
└── C
B 挂了以后：
USER-SERVICE
├── A
└── C
消费者再更新本地实例列表，就不会继续把 B 当作正常实例使用。
十三、Eureka 的完整生命周期
到这里，我们可以把整个 Eureka 流程总结成：
Register
↓
注册
Renew
↓
续约 / 心跳
Fetch Registry
↓
获取注册表
Cancel / Evict
↓
主动下线 / 被剔除
整个过程：
服务启动
↓
向 Eureka 注册
↓
Eureka 保存实例
↓
服务持续发送心跳
↓
Consumer 拉取服务列表
↓
缓存到本地
↓
负载均衡选择实例
↓
直接调用 Provider
如果服务挂了：
Provider 宕机
↓
无法继续发送心跳
↓
Eureka 判断实例失效
↓
剔除实例
↓
Consumer 注册表逐渐更新
↓
不再选择该实例
这就是 Eureka 最核心的原理。
十四、什么是 Eureka 自我保护机制？
这是 Eureka 中一个非常经典的概念：
Self Preservation
也就是：
自我保护。
假设公司有：
100 个微服务实例
突然某一分钟：
80 个实例都没有心跳
有两种可能。
第一种：
80 台服务器同时炸了
第二种：
Eureka 和服务之间的网络出了问题
第二种实际上完全有可能。
比如：
机房网络故障
交换机异常
网络分区
大面积丢包
如果 Eureka 采取非常激进的策略：
没收到心跳
↓
马上全部删除
就有可能出现：
服务实际上还活着
↓
只是 Eureka 联系不到
↓
Eureka 全部删掉
↓
消费者认为服务全部不存在
于是原本只是：
局部网络问题
可能扩大成：
整个微服务体系服务发现异常
因此 Eureka 的设计思想更倾向：
当异常规模很大时，需要考虑是不是网络本身出了问题，而不是立刻认为所有实例都死亡。
这就是 Eureka 自我保护思想的核心。
十五、Eureka 为什么更强调可用性？
这和分布式系统中的 CAP 有关系。
CAP：
C = Consistency
一致性
A = Availability
可用性
P = Partition Tolerance
分区容错性
网络分区无法完全避免。
所以系统经常需要在：
更强一致性
和：
更强可用性
之间进行权衡。
Eureka 的设计明显更加重视：
Availability
也就是说：
即使注册信息暂时没有达到绝对实时一致，也希望系统还能继续提供服务。
因此 Eureka 会使用：
客户端缓存
心跳
注册表缓存
Server Peer
自我保护思想
等机制提高整体可用性。
十六、Eureka Server 本身挂了怎么办？
如果全公司只有一台 Eureka：
Eureka Server
那么它本身就可能成为单点。
所以生产环境一般应该考虑：
Eureka Server Cluster
例如：
Eureka-1
↙ ↘
↕ ↕
Eureka-2 ←→ Eureka-3
多个 Eureka Server 可以成为 Peer，互相同步注册信息。Spring Cloud 官方文档仍然支持 Peer-aware Eureka Server 部署，并说明多个 Peer 可以同步服务注册信息。(Home )
于是：
Eureka-1 挂了
客户端还可以访问：
Eureka-2
Eureka-3
提高注册中心本身的可用性。
十七、使用 Spring Cloud 搭建 Eureka Server
在 Spring Cloud 中，Eureka Server 的核心依赖是：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
当前 Spring Cloud Netflix 官方文档仍然提供该 Starter，并通过 @EnableEurekaServer 创建 Eureka Server。(Home )
启动类：
@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaServerApplication.class, args);
}
}
配置示意：
server:
port: 8761
eureka:
client:
register-with-eureka: false
fetch-registry: false
service-url:
defaultZone: http://localhost:8761/eureka/
这里：
register-with-eureka: false
表示：
当前这个单机 Eureka Server 不需要把自己注册给自己。
而：
fetch-registry: false
表示：
当前单机 Server 不需要像普通 Client 一样获取注册表。
Spring Cloud 官方单机配置示例也使用了这两个配置。(Home )
启动以后：
http://localhost:8761
通常可以进入 Eureka 管理页面。
十八、创建 Eureka Client
例如：
user-service
加入依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
配置：
spring:
application:
name: user-service
server:
port: 8080
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
这里最重要的是：
spring:
application:
name: user-service
它基本上就相当于：
这个服务叫什么名字。
Spring Cloud 官方文档说明，默认的 Eureka service ID 就来自 spring.application.name；当前 Spring Cloud 只要 Eureka Client Starter 在 classpath 中并配置了 Eureka Server 地址，应用即可自动注册，不需要为了注册额外添加老教程里常见的 Eureka Client 启用注解。(Home )
十九、多个实例是什么效果？
启动：
user-service
port = 8081
再启动：
user-service
port = 8082
再启动：
user-service
port = 8083
Eureka 中最终可以理解成：
USER-SERVICE
├── localhost:8081
├── localhost:8082
└── localhost:8083
注意：
服务名称相同，不代表只有一个实例。
这是微服务非常重要的概念：
Service
↓
Instances
例如：
user-service
是逻辑服务。
而：
10.0.0.1:8080
10.0.0.2:8080
10.0.0.3:8080
才是三个真实服务实例。
二十、Eureka 和 Feign 是什么关系？
这个也非常容易混。
Eureka 负责：
找到 User Service 在哪里。
Feign 负责：
把 HTTP 调用写得像 Java 接口调用。
例如：
@FeignClient(name = "user-service")
public interface UserClient {
@GetMapping("/users/{id}")
UserVO getUser(@PathVariable Long id);
}
Order Service：
@Autowired
private UserClient userClient;
然后：
UserVO user = userClient.getUser(10001L);
表面上只是：
userClient.getUser()
背后可以理解成：
Feign
↓
发现逻辑服务 user-service
↓
获取可用实例
↓
LoadBalancer
↓
选择实例
↓
HTTP 请求
所以：
Eureka
解决：
服务在哪里。
而：
Feign
解决：
怎么方便地调用 HTTP 服务。
二十一、Eureka 和 LoadBalancer 的关系
假设 Eureka 返回：
USER-SERVICE
A
B
C
到底选择谁：
A？
B？
C？
需要：
LoadBalancer
所以完整关系可以理解成：
Feign
↓
我要调用 user-service
↓
Service Discovery
↓
得到 A / B / C
↓
LoadBalancer
↓
选择 B
↓
HTTP
↓
User Service B
现代 Spring Cloud 官方文档将 Eureka 与 Spring Cloud LoadBalancer 集成，而不是简单按照很多老教程中的 Ribbon 体系来理解。(Home )
二十二、Eureka 和 API Gateway 有什么区别？
Eureka：
服务注册
服务发现
Gateway：
外部请求入口
路由
认证
鉴权
限流
过滤
完整架构可能是：
Client
|
↓
API Gateway
|
┌────────┼────────┐
↓ ↓ ↓
User Order Payment
↑
|
Eureka
Gateway 本身也可以通过：
Eureka
发现后面的微服务。
所以：
Eureka
不是网关。
二十三、Eureka 和 ZooKeeper 有什么区别？
你前面如果已经学过 ZooKeeper，这里非常适合进行对比。
ZooKeeper：
本质：
分布式协调系统
它拥有：
ZNode
Session
Watcher
Ephemeral Node
Sequential Node
可以做：
服务注册发现
分布式锁
Leader Election
分布式协调
而 Eureka 更专注于：
服务注册
服务发现
两者服务存活判断方式也不一样
ZooKeeper 经典思路：
Provider
↓
Ephemeral Node
↓
Session 存在
节点存在
↓
Session Expired
节点删除
Eureka：
Provider
↓
Register
↓
Heartbeat
↓
Renew
↓
长时间没有续约
↓
Evict
所以可以粗略记成：
ZooKeeper
Session
+
临时节点
+
Watcher
而：
Eureka
Register
+
Heartbeat
+
Registry Cache
+
Eviction
二十四、Eureka 和 ZooKeeper 对比表
| 对比项 | Eureka | ZooKeeper |
|---|---|---|
| 定位 | 服务注册发现 | 分布式协调系统 |
| 注册中心 | 核心用途之一 | 可以实现 |
| 服务存活 | 心跳续约 | Session + 临时节点 |
| 服务列表 | Client 拉取并缓存 | ZNode + Watch |
| 分布式锁 | 不是主要用途 | 可以实现 |
| Leader Election | 不是主要用途 | 可以实现 |
| 微服务生态 | Spring Cloud Netflix | Dubbo 等体系中很经典 |
| 核心思想 | 服务可用性 | 分布式协调与一致性 |
二十五、Eureka 和 Nacos 又是什么关系？
它们都可以作为：
注册中心
所以：
Eureka
Nacos
ZooKeeper
Consul
在某些架构图中会出现在同一层：
Registry
┌──────────┼──────────┐
↓ ↓ ↓
Eureka Nacos ZooKeeper
但是 Nacos 除了：
服务注册发现
还非常常见地承担：
配置中心
因此在国内 Java 微服务项目中经常看到：
Spring Cloud Alibaba
+
Nacos
而 Eureka 是：
Spring Cloud Netflix
+
Eureka
的经典组合。
二十六、Eureka 中几个必须掌握的关键词
学习 Eureka 不需要第一天把所有配置全部背下来。
先把下面几个词吃透。
Register
注册
服务告诉 Eureka：
我是谁，我在哪里。
Renew
续约 / 心跳
服务告诉 Eureka：
我还活着。
Fetch Registry
拉取注册表
Consumer 获取：
当前有哪些服务实例。
Cancel
主动下线
服务正常关闭：
我要离开了。
Evict
剔除
服务长时间没有正常续约：
注册中心将失效实例从服务列表中清理。
Self Preservation
自我保护
异常情况下避免过度删除大量可能仍然存活的服务实例。
Local Cache
客户端缓存
消费者不会每一次业务请求都访问 Eureka。
二十七、从启动到调用完整模拟一次
假设现在启动：
Eureka Server
然后启动：
user-service-1
10.0.0.1:8080
第一步：
User1
↓
Register
↓
Eureka
然后：
USER-SERVICE
10.0.0.1:8080
再启动：
user-service-2
10.0.0.2:8080
变成：
USER-SERVICE
10.0.0.1:8080
10.0.0.2:8080
然后启动：
order-service
Order 也注册：
ORDER-SERVICE
10.0.1.1:8081
同时 Order 获取 Eureka 注册表：
USER-SERVICE:
A
B
并缓存到本地。
现在用户创建订单。
Order 需要查询 User：
Order
↓
我要调用 user-service
↓
发现 A / B
↓
LoadBalancer
↓
选择 B
↓
直接 HTTP 请求
↓
User B
整个业务 HTTP 请求：
不经过 Eureka。
现在 User B 宕机。
User B
↓
无法发送 Heartbeat
Eureka 最终认为：
B 不可用了。
把 B 剔除。
注册表变成：
USER-SERVICE
A
客户端的服务列表随后也逐渐更新。
之后：
Order
↓
User A
不会继续把 B 当作正常实例选择。
这就是 Eureka 服务注册与发现的完整生命周期。
二十八、为什么微服务需要注册中心？
现在回到最开始的问题。
如果没有 Eureka：
Order Service
↓
写死 IP
↓
User Service
带来的问题：
扩容要改配置
缩容要改配置
服务器挂了不知道
IP 改了要重新配置
大量服务之间地址维护困难
有 Eureka：
Provider
↓
动态注册
↓
Eureka
↓
动态发现
↓
Consumer
所以服务实例可以：
上线
下线
扩容
缩容
迁移
重启
而消费者不需要把某一个固定 IP 当作永久依赖。
这才是：
注册中心真正解决的问题。
二十九、现在还值得学习 Eureka 吗？
值得。
但需要把：
“学习 Eureka”
和：
“新项目必须选择 Eureka”
分开。
截至 2026 年 9 月，Spring Cloud Netflix 官方文档仍然把 Eureka 作为 Service Discovery 能力提供，当前文档列有稳定版本 5.0.2，因此 Eureka 并不是一个“完全不能使用”的历史概念。(Home )
不过学习 Eureka 更大的价值其实是理解：
服务注册
服务发现
心跳
服务剔除
客户端缓存
负载均衡
注册中心高可用
因为以后即使换成：
Nacos
Consul
ZooKeeper
Kubernetes Service Discovery
核心问题仍然是：
在动态分布式环境中，消费者如何找到可用的 Provider？
所以学 Eureka，本质是在学习：
服务发现模型。
三十、Eureka 知识体系最终应该怎么记？
不要死记几十个配置项。
脑子里建立下面这张图：
Eureka Server
Service Registry
/ \
/ \
Register / Renew Fetch Registry
/ \
↓ ↓
┌──────────────┐ ┌──────────────┐
│ User Service │ │Order Service │
│ Provider │ │ Consumer │
└──────┬───────┘ └───────┬──────┘
│ │
│ │
└──────── HTTP ───────────┘
直接业务调用
Provider：
启动
↓
Register
↓
定期 Renew
Consumer：
Fetch Registry
↓
本地缓存
↓
LoadBalancer
↓
选择 Provider
↓
直接调用
Provider 挂掉：
心跳消失
↓
实例失效
↓
Evict
↓
Consumer 服务列表更新
这就是整个 Eureka。
三十一、一句话总结
如果面试官问：
Eureka 是什么？
可以回答：
Eureka 是 Netflix 开源的服务注册与发现组件。在微服务环境中，Provider 启动后将服务名称、IP、端口和相关元数据注册到 Eureka Server，并通过周期性心跳维持服务实例状态；Consumer 从 Eureka 获取并在本地缓存服务实例列表，通过负载均衡选择可用 Provider，再直接发起业务调用。当实例长时间无法续约时，注册中心会将其从服务列表中剔除。
如果要用一句大白话：
Eureka 就是微服务里的动态通讯录，它负责记录“谁提供什么服务、服务在哪里、谁目前还活着”。
再压缩成六个关键词：
Eureka
=
注册
+
心跳
+
发现
+
缓存
+
负载均衡配合
+
服务剔除
而整个微服务调用链最终可以记成：
微服务拆分
↓
IP 动态变化
↓
需要注册中心
↓
Eureka
↓
Provider 注册
↓
Consumer 发现
↓
本地缓存实例
↓
负载均衡
↓
直接调用 Provider
理解到这里，Eureka 就算真正入门了。
接下来再学习：
Feign
LoadBalancer
Gateway
Hystrix / Circuit Breaker
Config
Nacos
就会发现它们并不是一堆毫无关系的组件，而是在共同解决：
一个大型单体系统被拆成大量微服务以后，这些服务应该怎样寻找彼此、调用彼此、保护彼此和管理彼此。