微服务架构核心组件、职责与交互全解析
一、 微服务全景架构图（分层）
微服务不再是散乱的工程，而是一个分工明确的矩阵。通过分层，我们可以更清晰地看到请求是如何流转的。
text
==================== 流量接入层 (Entrance) ====================
[ 外部客户端：App / H5 / Web / PC ]
│ (Restful API / HTTPS)
┌────────▼────────┐
│ API 网关 (Gateway) │──► 职责：鉴权、路由、限流、日志
└────────┬────────┘
│
==================== 业务服务层 (Services) ====================
┌──────────────┼──────────────┐
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ 用户服务 │ │ 订单服务 │ │ 库存服务 │──► 职责：核心业务逻辑
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└──────────────┼──────────────┘
│ (Feign/RPC 调用)
│
==================== 服务治理层 (Control) =====================
┌────────────────────┼────────────────────┐
│ ┌──────────────┐ ┌─┴────────────┐ ┌─────┴──────┐
│ │ 注册发现中心 │ │ 统一配置中心 │ │ 熔断/限流器 │──► 职责：管理与保护
│ │ (Nacos/Eureka)│ │ (Nacos/Apollo)│ │ (Sentinel) │
│ └──────────────┘ └──────────────┘ └────────────┘
└────────────────────┬────────────────────┘
│
==================== 基础设施/观测层 (Infrastructure) =========
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 消息队列 │ │ 分布式缓存 │ │ 链路追踪 │──► 职责：异步、性能
│ (Kafka/MQ) │ │ (Redis) │ │ (Skywalking) │ 与系统监控
└──────────────┘ └──────────────┘ └──────────────┘二、 核心组件职能
1. API 网关 (API Gateway) ------ "保安与向导"
- 核心作用：整个微服务系统的唯一入口。
- 具体职责 ：
- 路由转发 ：把
/order的请求发给订单服务，把/user的请求发给用户服务。 - 安全鉴权：统一判断用户是否登录、是否有权限访问，通过后才放行到后端。
- 流量监控：在入口处记录日志，或者拦截恶意攻击。
- 路由转发 ：把
2. 服务注册与发现 (Service Registry) ------ "动态通讯录"
- 核心作用：记录每一个微服务实例的实时 IP 和端口。
- 具体职责 ：
- 注册：服务启动时主动上报自己的位置。
- 发现：服务 A 想调服务 B 时，不用写死 IP，而是问注册中心："B 现在在哪几台服务器上？"
- 关联关系 ：它是微服务协同的基石。
3. 配置中心 (Config Center) ------ "中央广播站"
- 核心作用：集中管理所有服务的配置文件。
- 具体职责 ：
- 配置解耦：代码里不写死数据库密码、业务开关等。
- 动态生效 ：修改配置后，所有服务实时接收更新，不需要重新打包重启。
4. 远程调用 (Feign / RPC) ------ "部门内线电话"
- 核心作用：让服务与服务之间能互相说话。
- 具体职责 ：
- 声明式调用：在代码里像调用本地方法一样去调用远程的其他服务。
- 负载均衡：如果对方有 3 台机器，它会自动选择一台压力小的去访问。
5. 熔断与限流 (Sentinel) ------ "电力保险丝"
- 核心作用：保护系统不因某个点坏掉而全盘崩溃。
- 具体职责 ：
- 限流：每秒只允许 500 人访问，超出的排队或拒绝，防止压垮服务器。
- 熔断：如果发现"支付服务"挂了，立刻切断订单服务对它的调用，并返回一个友好的错误提示（降级），防止订单服务也被拖死。
6. 消息队列 (Message Queue) ------ "收发室快递柜"
- 核心作用：解耦服务、异步处理。
- 具体职责 ：
- 削峰填谷：瞬时流量太猛时，先存入 MQ，后端服务按照自己的节奏慢慢消费。
- 异步化：下单成功后，直接发个消息给 MQ。积分服务、短信服务自己去取消息处理，订单服务不用等它们执行完。
三、 组件间的生命周期与协作逻辑
我们可以通过**"一个请求的一生"**来串联这些组件：
- 启动阶段 ：
- 所有微服务从 配置中心 拿到自己的配置（如数据库地址）。
- 微服务启动成功，把自己的 IP 登记到 注册中心。
- 请求进入 ：
- 用户请求到达 API 网关，网关先做身份校验。
- 校验通过后，网关去 注册中心 查一下哪个订单服务在线。
- 服务交互 ：
- 订单服务处理逻辑，需要查用户信息，通过 Feign 调用户服务。
- 此时 Sentinel 紧盯链路，如果用户服务太慢，Sentinel 启动限流或熔断。
- 数据沉淀与反馈 ：
- 订单处理完，往 MQ 丢一条消息通知其他服务。
- Skywalking 全程记录该请求走过的所有路径和时间。
四、 常见组件对比表
| 维度 | 主流推荐 (Spring Cloud Alibaba 体系) | 备选/经典组件 |
|---|---|---|
| 注册中心 | Nacos (最推荐，国内最火) | Eureka, Consul, Zookeeper |
| 配置中心 | Nacos Config | Apollo (功能最强), Spring Cloud Config |
| 网关 | Spring Cloud Gateway | Zuul (已过时), Kong, Nginx |
| 熔断限流 | Sentinel (功能丰富，有管理后台) | Hystrix (已停更) |
| 远程调用 | OpenFeign / Dubbo | RestTemplate |
| 链路追踪 | Skywalking (无侵入，最强) | Zipkin, Jaeger |
五、 心法
- 不要试图一次性学完所有组件：先搞定 Nacos + OpenFeign + Gateway，这就已经能搭出一个能跑的微服务了。
- 理解比代码更重要：代码只是调用 API，理解"为什么要用网关？""为什么需要注册中心？"才是微服务的核心。
- 关注数据一致性 ：微服务最难的地方在于数据散落在不同数据库，以后你可以进阶学习 Seata（分布式事务）。