微服务面试的第一类问题通常很基础：Spring Cloud 有哪些核心组件？服务注册和发现是什么意思？Eureka 和 Nacos 有什么区别？这类题不难，但很容易因为概念混在一起而答乱。
一句话先收住主线：Spring Cloud 不是一个单独框架，而是一套微服务治理组件集合；注册中心解决"服务在哪里"的问题，负载均衡和远程调用解决"怎么调用"的问题，熔断降级和网关解决"调用链如何保护和入口如何治理"的问题。
客户端请求
Gateway
统一入口
业务微服务
Feign
远程调用
Ribbon
负载均衡
注册中心
Eureka / Nacos
返回服务实例列表
选择一个实例
调用服务提供者
Hystrix / Sentinel
熔断降级保护
Spring Cloud 五大组件怎么答
传统 Spring Cloud 常说五大组件：
| 组件 | 作用 | 一句话记忆 |
|---|---|---|
| Eureka | 注册中心 | 服务注册、服务发现、服务心跳 |
| Ribbon | 负载均衡 | 从多个实例里选一个调用 |
| Feign | 远程调用 | 像调用本地接口一样调用远程服务 |
| Hystrix | 服务熔断 | 下游异常时快速失败或走降级 |
| Zuul / Gateway | 网关 | 统一入口、路由、鉴权、限流 |
如果项目使用 Spring Cloud Alibaba，可以把回答自然替换成：
| 能力 | 常见组件 |
|---|---|
| 注册中心 / 配置中心 | Nacos |
| 负载均衡 | Ribbon 或 Spring Cloud LoadBalancer |
| 服务调用 | OpenFeign |
| 服务保护 | Sentinel |
| 服务网关 | Spring Cloud Gateway |
面试里不要把组件背成清单就停。更好的回答是补一句：这些组件围绕服务调用链协作，注册中心提供实例信息，Feign 发起调用，Ribbon 做负载均衡，Gateway 管入口，Hystrix 或 Sentinel 做故障保护。
服务注册和发现是什么意思
在单体项目里，模块之间通常是进程内方法调用。到了微服务，服务被拆成多个进程，甚至部署在不同机器上。调用方必须知道被调用服务有哪些实例、IP 和端口是什么、哪些实例还健康。
注册中心就负责这件事：
是
否
服务提供者启动
向注册中心注册
服务名、IP、端口
定时发送心跳
服务消费者
从注册中心拉取
服务实例列表
本地缓存服务列表
负载均衡选择实例
发起远程调用
心跳是否超时
注册中心剔除实例
实例保持可用
可以拆成三个动作：
- 服务注册：服务提供者启动后，把服务名、IP、端口等信息注册到注册中心。
- 服务发现：服务消费者从注册中心拉取服务列表，再通过负载均衡选择一个实例调用。
- 服务监控：服务提供者定时发送心跳，注册中心根据心跳判断实例是否健康。
注册中心不是流量入口
这里有一个新手很容易混的点：注册中心不负责转发业务请求。
Nginx 或 Gateway 是流量入口，请求会真实经过它们；注册中心更像一个"服务通讯录"，保存服务名、IP、端口、健康状态。消费者调用服务时，先从注册中心拿到通讯录，再自己选择实例发起请求。
服务消费者
注册中心
查询服务实例
返回 IP 和端口列表
消费者本地负载均衡
直接调用服务提供者
外部请求
Gateway / Nginx
转发真实业务流量
所以面试里如果问注册中心的作用，不要说"转发请求"。更准确的说法是：保存服务实例信息，提供服务发现和健康检测能力。
Eureka 的工作流程
Eureka 的典型流程是：
user-service启动后，把localhost:8081、localhost:8082等实例信息注册到 Eureka。order-service作为消费者，从 Eureka 拉取user-service的实例列表。order-service本地缓存服务列表。- 发起调用时，Ribbon 根据负载均衡规则选择一个实例。
- 服务提供者每 30 秒向 Eureka 发送一次心跳。
- Eureka 如果 90 秒没有收到某个实例的心跳，就会把它剔除。
Eureka 的设计更偏 AP：优先保证服务可用，即使短时间内服务列表不是绝对最新，也尽量让系统继续对外提供服务。
Nacos 的工作流程
Nacos 也支持服务注册、服务发现和健康检测，但它比 Eureka 多了几个能力：
- 支持临时实例和非临时实例。
- 临时实例通过心跳检测，心跳异常会被剔除。
- 非临时实例由 Nacos 主动探测，异常时不会直接剔除。
- 支持服务列表变更推送，消费者可以更快感知实例变化。
- 同时支持配置中心。
临时实例和非临时实例可以这样理解：
| 实例类型 | 健康检测方式 | 异常后怎么处理 | 适合场景 |
|---|---|---|---|
| 临时实例 | 服务主动心跳 | 心跳异常会被剔除 | 普通微服务实例，随时可能扩缩容 |
| 非临时实例 | Nacos 主动探测 | 异常时标记不健康，但不会直接剔除 | 固定服务、重要基础设施、需要人工确认的实例 |
大多数业务微服务用临时实例就够了。非临时实例更像"这个实例即使暂时不可用，也不要从注册表里直接消失"，适合更稳定、更受控的服务。
Nacos 和 Eureka 怎么对比
| 对比点 | Eureka | Nacos |
|---|---|---|
| 核心能力 | 注册中心 | 注册中心 + 配置中心 |
| 服务发现 | 消费者拉取服务列表 | 拉取 + 服务端推送变更 |
| 健康检测 | 服务提供者心跳 | 临时实例心跳，非临时实例主动探测 |
| 异常实例处理 | 心跳超时剔除 | 临时实例剔除，非临时实例保留 |
| CAP 倾向 | AP | 默认 AP，非临时实例场景可偏 CP |
项目回答时可以这样落地：
我们项目里使用 Nacos 作为注册中心和配置中心。服务启动后会把服务名、IP、端口注册到 Nacos，消费者通过服务名拉取实例列表，并结合负载均衡发起调用。Nacos 相比 Eureka，除了服务注册发现，还支持配置中心；服务列表变化时也支持推送，更新更及时。
面试回答模板
可以这样答：
Spring Cloud 常见核心组件包括 Eureka 注册中心、Ribbon 负载均衡、Feign 远程调用、Hystrix 熔断降级、Gateway 或 Zuul 网关。服务注册是服务提供者启动后把服务名、IP、端口注册到注册中心；服务发现是消费者从注册中心拉取服务列表，再通过负载均衡选择一个实例发起调用。Eureka 通过心跳做健康检测，服务 90 秒没有心跳会被剔除。Nacos 也支持注册发现，并且支持配置中心、服务变更推送、临时实例和非临时实例，功能更丰富。
小结
这篇文章只需要抓住一条线：
服务提供者注册 -> 消费者发现 -> 负载均衡选择实例 -> 远程调用 -> 心跳维持健康状态。
Spring Cloud 的组件很多，但面试里先把服务调用链讲清楚，就不容易散。