小白初识 SpringCloud：微服务基础与 SpringCloud 核心作用

🎯 本文适合人群 ：Java 后端初学者、微服务新手

⏱️ 阅读时长 ：25 分钟

📌 你将收获：理解微服务架构、掌握 SpringCloud 核心概念和应用场景

📖 目录

一、什么是微服务
[二、单体架构 vs 微服务架构](#二、单体架构 vs 微服务架构)
三、微服务的优缺点
[四、SpringCloud 是什么](#四、SpringCloud 是什么)
[五、SpringCloud 核心作用](#五、SpringCloud 核心作用)
[六、SpringCloud 与 SpringBoot 的关系](#六、SpringCloud 与 SpringBoot 的关系)
[七、SpringCloud 技术栈](#七、SpringCloud 技术栈)
八、微服务实战场景
九、常见面试题

一、什么是微服务

1.1 传统理解

微服务 （Microservices）是一种架构风格，它将一个大型应用拆分成多个小而独立 的服务，每个服务运行在自己的进程中，服务之间通过轻量级通信机制（通常是 HTTP RESTful API）进行交互。

1.2 通俗解释

把微服务比作餐厅分工：

复制代码

传统餐厅（单体架构）：
┌─────────────────────────────────────┐
│  一个大厨负责所有工作：              │
│  ├─ 采购食材                        │
│  ├─ 切菜、洗菜                      │
│  ├─ 炒菜、煮菜                      │
│  ├─ 装盘、上菜                      │
│  └─ 收银、打扫                      │
└─────────────────────────────────────┘
问题：大厨累垮了，效率低！

微服务餐厅（微服务架构）：
┌──────────┐  ┌──────────┐  ┌──────────┐
│ 采购员   │  │ 厨师     │  │ 服务员   │
│ 负责买菜 │  │ 负责烹饪 │  │ 负责上菜 │
└──────────┘  └──────────┘  └──────────┘
     │             │             │
     └─────────────┴─────────────┘
              各司其职，协作完成

核心思想：

每个服务做好一件事（单一职责）
服务之间独立部署 、独立运行
服务之间通过接口通信

1.3 微服务特征

特征	说明	举例
独立性	每个服务独立开发、部署	订单服务崩溃不影响用户服务
自治性	服务有自己的数据库	用户服务有 user_db，订单服务有 order_db
轻量通信	HTTP/gRPC 等协议通信	用户服务通过 HTTP 调用订单服务
技术多样性	不同服务可用不同技术栈	用户服务用 Java，推荐服务用 Python
按需扩展	单独扩展某个服务	双 11 只扩展订单服务，不动其他服务

二、单体架构 vs 微服务架构

2.1 单体架构（Monolithic Architecture）

定义：所有功能模块打包在一个应用中，共用一个数据库。

架构图：

复制代码

┌─────────────────────────────────────────┐
│         单体应用（一个 WAR/JAR）         │
├─────────────────────────────────────────┤
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │ 用户模块 │  │ 订单模块 │  │ 商品模块 │ │
│  └─────────┘  └─────────┘  └─────────┘ │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
│  │ 支付模块 │  │ 库存模块 │  │ 物流模块 │ │
│  └─────────┘  └─────────┘  └─────────┘ │
└─────────────────────────────────────────┘
                  ↓
         ┌──────────────┐
         │  单一数据库   │
         └──────────────┘

优点：

✅ 开发简单：一个项目搞定
✅ 部署简单：打包成一个 WAR/JAR
✅ 测试简单：启动一个应用即可
✅ 适合小团队

缺点：

❌ 代码耦合：改一个模块可能影响其他模块
❌ 部署风险：一处 Bug 导致整个应用崩溃
❌ 扩展困难：只能整体扩展，无法单独扩展某个模块
❌ 技术栈固定：所有模块必须用同一技术栈

2.2 微服务架构（Microservices Architecture）

定义：将应用拆分成多个独立的服务，每个服务独立部署、独立数据库。

架构图：

复制代码

┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ 用户服务     │  │ 订单服务     │  │ 商品服务     │
│ (8081)       │  │ (8082)       │  │ (8083)       │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │ user_db          │ order_db        │ product_db
       
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ 支付服务     │  │ 库存服务     │  │ 物流服务     │
│ (8084)       │  │ (8085)       │  │ (8086)       │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │ pay_db           │ stock_db        │ logistics_db

所有服务通过 HTTP/gRPC 通信

优点：

✅ 独立部署：修改订单服务不影响用户服务
✅ 技术自由：不同服务可用不同技术栈
✅ 按需扩展：只扩展高负载的服务
✅ 团队自治：不同团队负责不同服务
✅ 故障隔离：一个服务挂了不影响其他服务

缺点：

❌ 复杂度高：需要管理多个服务
❌ 分布式问题：网络延迟、数据一致性
❌ 运维成本：需要部署多个应用
❌ 调试困难：问题可能跨多个服务

2.3 对比总结

维度	单体架构	微服务架构
开发复杂度	低	高
部署方式	整体部署	独立部署
扩展性	整体扩展	按需扩展
技术栈	统一技术栈	技术多样性
团队规模	适合小团队	适合大团队
适用场景	小型项目、快速验证	大型项目、高并发

何时选择微服务？

团队规模 > 10 人
业务复杂度高
需要频繁迭代
高并发场景
需要技术多样性

三、微服务的优缺点

3.1 优点详解

1. 独立开发和部署

复制代码

传统单体：
  修改订单模块 → 重新打包整个应用 → 部署整个应用
  （影响所有用户，风险大）

微服务：
  修改订单服务 → 只部署订单服务 → 其他服务不受影响
  （灰度发布，风险小）

2. 技术栈自由

复制代码

用户服务：Java + SpringBoot + MySQL
订单服务：Go + Gin + PostgreSQL
推荐服务：Python + Flask + MongoDB

3. 按需扩展

复制代码

双 11 大促：
  订单服务：10 个实例（高负载）
  用户服务：2 个实例（低负载）
  
节省成本，提高效率！

4. 故障隔离

复制代码

场景：支付服务崩溃
  ✅ 用户服务：正常运行（用户可以浏览商品）
  ✅ 订单服务：正常运行（可以下单，支付功能降级）
  ❌ 支付服务：不可用（但不影响其他功能）

3.2 缺点详解

1. 分布式复杂度

复制代码

单体架构：
  用户下单 → 直接调用本地方法 → 扣减库存
  （简单、快速、事务保证）

微服务：
  用户下单 → HTTP 调用库存服务 → 扣减库存
  （网络延迟、需要分布式事务）

2. 服务间通信成本

复制代码

单体：方法调用（微秒级）
微服务：HTTP 调用（毫秒级）
  - 网络延迟
  - 序列化/反序列化
  - 超时重试

3. 数据一致性问题

复制代码

场景：下单扣库存
  订单服务：创建订单 ✅
  库存服务：扣减库存 ❌（网络超时）
  
结果：订单创建了，但库存没扣！
  
解决方案：分布式事务（Seata）

4. 运维成本增加

复制代码

单体：1 个应用 + 1 个数据库
微服务：10 个服务 + 10 个数据库
  - 需要自动化部署（CI/CD）
  - 需要服务监控（Prometheus）
  - 需要日志收集（ELK）

四、SpringCloud 是什么

4.1 官方定义

SpringCloud 是一套微服务解决方案，基于 SpringBoot，提供了微服务开发所需的各种组件。

4.2 通俗理解

如果把微服务比作建房子：

复制代码

SpringBoot = 砖头（构建单个服务）
SpringCloud = 施工方案（如何组织多个服务）

SpringBoot：
  ├─ 快速创建单个服务
  ├─ 内置 Tomcat
  └─ 自动配置

SpringCloud：
  ├─ 服务如何发现彼此？（Nacos）
  ├─ 服务如何互相调用？（OpenFeign）
  ├─ 服务挂了怎么办？（Sentinel）
  ├─ 如何统一入口？（Gateway）
  └─ 配置如何管理？（Nacos Config）

4.3 SpringCloud 特点

特点	说明
基于 SpringBoot	继承 SpringBoot 的优点，快速开发
组件化	每个功能都是独立组件，按需选择
生态丰富	Alibaba、Netflix 等多种实现
简化开发	注解式开发，降低微服务复杂度

4.4 SpringCloud 版本

SpringCloud 采用伦敦地铁站命名：

版本	发布时间	SpringBoot 版本	状态
Hoxton	2019	2.2.x, 2.3.x	维护中
2020	2020	2.4.x, 2.5.x	维护中
2021	2021	2.6.x, 2.7.x	推荐 ✅
2022	2022	3.0.x	最新

版本选择建议：

生产环境：SpringCloud 2021 + SpringBoot 2.7.x
学习环境：SpringCloud 2021 + SpringBoot 2.7.x

五、SpringCloud 核心作用

5.1 核心功能全景图

复制代码

┌────────────────────────────────────────────────────────────┐
│                    SpringCloud 核心功能                     │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  ┌──────────────┐      ┌──────────────┐                  │
│  │ 服务注册与发现 │      │  配置管理    │                  │
│  │   Nacos      │      │  Nacos Config│                  │
│  └──────────────┘      └──────────────┘                  │
│                                                            │
│  ┌──────────────┐      ┌──────────────┐                  │
│  │ 服务调用     │      │  负载均衡    │                  │
│  │  OpenFeign   │      │  LoadBalancer│                  │
│  └──────────────┘      └──────────────┘                  │
│                                                            │
│  ┌──────────────┐      ┌──────────────┐                  │
│  │ 服务网关     │      │  熔断降级    │                  │
│  │  Gateway     │      │  Sentinel    │                  │
│  └──────────────┘      └──────────────┘                  │
│                                                            │
│  ┌──────────────┐      ┌──────────────┐                  │
│  │ 链路追踪     │      │  分布式事务  │                  │
│  │  Sleuth      │      │  Seata       │                  │
│  └──────────────┘      └──────────────┘                  │
└────────────────────────────────────────────────────────────┘

5.2 核心作用详解

1. 服务注册与发现（Nacos）

问题：微服务有很多个，如何知道彼此的地址？

解决方案：服务注册中心

复制代码

┌─────────────────────────────────────────┐
│          Nacos 注册中心                  │
├─────────────────────────────────────────┤
│  用户服务：192.168.1.101:8081          │
│  订单服务：192.168.1.102:8082          │
│  商品服务：192.168.1.103:8083          │
└─────────────────────────────────────────┘
         ↑                  ↓
      注册服务          查询服务
         │                  │
    ┌────┴────┐      ┌─────┴─────┐
    │ 用户服务 │      │ 订单服务  │
    └─────────┘      └───────────┘

好处：

服务地址动态管理
服务自动健康检查
支持服务下线和上线

2. 服务调用（OpenFeign）

问题：服务之间如何调用？

传统方式：

java 复制代码

// 使用 RestTemplate（麻烦）
String url = "http://order-service/order/create";
RestTemplate restTemplate = new RestTemplate();
Order order = restTemplate.postForObject(url, request, Order.class);

OpenFeign 方式：

java 复制代码

// 像调用本地方法一样调用远程服务（简单）
@FeignClient("order-service")
public interface OrderClient {
    @PostMapping("/order/create")
    Order createOrder(@RequestBody OrderRequest request);
}

// 使用
@Autowired
private OrderClient orderClient;

Order order = orderClient.createOrder(request);  // 自动发 HTTP 请求

好处：

简化远程调用代码
自动负载均衡
支持熔断降级

3. 服务网关（Gateway）

问题：客户端需要调用多个服务，地址太多难管理

解决方案：统一网关入口

复制代码

客户端（手机、网页）
       ↓
┌─────────────────────┐
│   Gateway 网关      │  统一入口：http://gateway:9000
├─────────────────────┤
│  路由规则：         │
│  /user/** → 用户服务 │
│  /order/** → 订单服务│
│  /product/** → 商品服务│
└─────────────────────┘
       ↓         ↓         ↓
   用户服务   订单服务   商品服务

好处：

统一入口，简化客户端
统一鉴权、限流
动态路由

4. 熔断降级（Sentinel）

问题：某个服务挂了，调用它的服务也会等待超时

解决方案：熔断器

复制代码

正常情况：
  订单服务 → 调用库存服务 → 成功 ✅

库存服务挂了：
  订单服务 → 调用库存服务 → 超时 ❌
  （等待 5 秒，用户体验差）

使用熔断器：
  订单服务 → 检测到库存服务挂了 → 快速失败 ✅
  （直接返回降级响应，不等待）
  
降级响应示例：
  "库存服务暂时不可用，请稍后再试"

好处：

防止雪崩效应
快速失败，提升体验
服务自动恢复检测

5. 配置管理（Nacos Config）

问题：微服务配置分散，难以管理

传统方式：

复制代码

用户服务：application.yml
订单服务：application.yml
商品服务：application.yml

修改配置 → 重启所有服务 ❌

Nacos Config 方式：

复制代码

┌─────────────────────────┐
│   Nacos 配置中心        │
├─────────────────────────┤
│  公共配置：             │
│    - 数据库地址         │
│    - Redis 地址         │
│  用户服务配置           │
│  订单服务配置           │
└─────────────────────────┘
       ↓  ↓  ↓
   动态刷新配置（不重启）✅

好处：

集中管理配置
动态刷新，不重启
支持多环境（dev、test、prod）

六、SpringCloud 与 SpringBoot 的关系

6.1 层级关系

复制代码

┌────────────────────────────────────────┐
│         SpringCloud（微服务方案）       │
│  ├─ 服务注册与发现（Nacos）            │
│  ├─ 服务调用（OpenFeign）              │
│  ├─ 服务网关（Gateway）                │
│  └─ 熔断降级（Sentinel）               │
└────────────────────────────────────────┘
                  ↓ 基于
┌────────────────────────────────────────┐
│         SpringBoot（快速开发框架）      │
│  ├─ 自动配置                           │
│  ├─ 嵌入式 Tomcat                      │
│  ├─ 起步依赖                           │
│  └─ Actuator 监控                      │
└────────────────────────────────────────┘
                  ↓ 基于
┌────────────────────────────────────────┐
│         Spring Framework（核心框架）    │
│  ├─ IoC 容器                           │
│  ├─ AOP                                │
│  ├─ 事务管理                           │
│  └─ MVC                                │
└────────────────────────────────────────┘

6.2 形象比喻

复制代码

Spring Framework = 地基（基础框架）
SpringBoot = 毛坯房（单个服务）
SpringCloud = 小区物业（管理多个服务）

6.3 依赖关系

xml 复制代码

<!-- SpringBoot 项目 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<!-- SpringCloud 项目（包含 SpringBoot） -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

七、SpringCloud 技术栈

7.1 Netflix 体系（第一代，逐渐退出）

组件	作用	状态
Eureka	服务注册与发现	停止维护 ❌
Ribbon	负载均衡	停止维护 ❌
Hystrix	熔断降级	停止维护 ❌
Zuul	服务网关	停止维护 ❌

7.2 Alibaba 体系（第二代，推荐使用）

组件	作用	状态
Nacos	服务注册与发现 + 配置管理	维护中 ✅
Sentinel	熔断降级 + 限流	维护中 ✅
Seata	分布式事务	维护中 ✅
RocketMQ	消息队列	维护中 ✅

7.3 Spring 官方体系

组件	作用	状态
Gateway	服务网关	维护中 ✅
OpenFeign	服务调用	维护中 ✅
LoadBalancer	负载均衡	维护中 ✅
Sleuth	链路追踪	维护中 ✅

7.4 推荐技术栈（2024）

复制代码

服务注册与发现：Nacos ✅
配置管理：Nacos Config ✅
服务调用：OpenFeign ✅
负载均衡：Spring Cloud LoadBalancer ✅
服务网关：Gateway ✅
熔断降级：Sentinel ✅
分布式事务：Seata ✅
链路追踪：Sleuth + Zipkin ✅

八、微服务实战场景

8.1 电商系统架构

复制代码

                    ┌──────────────┐
                    │   Gateway    │  网关（统一入口）
                    │   :9000      │
                    └──────┬───────┘
                           │
        ┌──────────────────┼──────────────────┐
        ↓                  ↓                  ↓
  ┌──────────┐       ┌──────────┐       ┌──────────┐
  │ 用户服务 │       │ 商品服务 │       │ 订单服务 │
  │  :8081   │       │  :8082   │       │  :8083   │
  └──────────┘       └──────────┘       └──────────┘
                           ↓                  ↓
                     ┌──────────┐       ┌──────────┐
                     │ 库存服务 │       │ 支付服务 │
                     │  :8084   │       │  :8085   │
                     └──────────┘       └──────────┘

服务拆分原则：

按业务功能拆分
每个服务职责单一
服务粒度适中（不要拆得太细）

8.2 下单流程

复制代码

1. 用户下单
   客户端 → Gateway → 订单服务

2. 订单服务调用其他服务（使用 OpenFeign）
   订单服务 → 用户服务（验证用户）
   订单服务 → 商品服务（获取商品信息）
   订单服务 → 库存服务（扣减库存）
   订单服务 → 支付服务（创建支付订单）

3. 如果库存服务挂了（使用 Sentinel）
   订单服务 → 库存服务 ❌（超时）
   → 熔断器打开
   → 返回降级响应："库存不足，请稍后重试"

九、常见面试题

面试题 1：什么是微服务？

参考答案：

微服务是一种架构风格，将大型应用拆分成多个小而独立的服务，每个服务：

运行在独立进程中
负责单一业务功能
拥有独立数据库
通过轻量级通信机制（HTTP/gRPC）交互
可以独立部署和扩展

优点：独立部署、技术自由、按需扩展、故障隔离
缺点：分布式复杂度高、运维成本增加、数据一致性问题

面试题 2：单体架构和微服务架构的区别？

参考答案：

维度	单体架构	微服务架构
部署方式	整体打包部署	独立部署
技术栈	统一技术栈	技术多样性
扩展性	整体扩展	按需扩展
团队协作	所有人维护一个项目	不同团队负责不同服务
故障影响	一处 Bug 影响整个应用	故障隔离
适用场景	小型项目	大型、高并发项目

面试题 3：SpringCloud 和 SpringBoot 的关系？

参考答案：

SpringBoot：

快速开发单个服务的框架
提供自动配置、嵌入式 Tomcat 等功能
简化 Spring 开发

SpringCloud：

基于 SpringBoot 的微服务解决方案
提供服务注册、服务调用、服务网关等组件
解决微服务架构的各种问题

关系：

SpringCloud 基于 SpringBoot
SpringBoot 构建单个服务，SpringCloud 管理多个服务
SpringBoot 是地基，SpringCloud 是上层建筑

面试题 4：SpringCloud 核心组件有哪些？

参考答案：

推荐技术栈（Alibaba + Spring 官方）：

组件	作用	说明
Nacos	服务注册与发现 + 配置管理	替代 Eureka + Config
OpenFeign	服务调用	简化 HTTP 调用
Gateway	服务网关	统一入口、路由、限流
Sentinel	熔断降级 + 限流	替代 Hystrix
LoadBalancer	负载均衡	替代 Ribbon
Seata	分布式事务	保证数据一致性
Sleuth	链路追踪	追踪请求调用链路

面试题 5：微服务的优缺点是什么？

参考答案：

优点：

独立部署：修改一个服务不影响其他服务
技术多样性：不同服务可用不同技术栈
按需扩展：只扩展高负载的服务
故障隔离：一个服务挂了不影响其他服务
团队自治：不同团队负责不同服务

缺点：

分布式复杂度：网络延迟、数据一致性问题
运维成本：需要管理多个服务和数据库
服务间通信：HTTP 调用比本地方法调用慢
调试困难：问题可能跨多个服务
学习成本：需要掌握更多技术

面试题 6：什么时候应该使用微服务？

参考答案：

适合使用微服务的场景：

团队规模较大（> 10 人）
业务复杂度高，模块众多
需要频繁迭代和发布
高并发场景，需要按需扩展
需要技术多样性

不适合使用微服务的场景：

小团队（< 5 人）
业务简单
项目初期，需求不明确
并发量不高

原则：

不要为了微服务而微服务
先单体，再微服务
根据业务需求和团队规模决定

面试题 7：服务注册与发现的原理是什么？

参考答案：

原理：

服务注册：
- 服务启动时，向注册中心注册自己的信息（IP、端口、服务名）
- 定时发送心跳，证明服务存活
服务发现：
- 服务调用其他服务前，向注册中心查询目标服务的地址列表
- 从地址列表中选择一个（负载均衡）
- 发起 HTTP 调用
健康检查：
- 注册中心定时检查服务健康状态
- 如果服务长时间无心跳，自动下线

流程图：

复制代码

1. 服务注册
   用户服务启动 → Nacos（注册：user-service, 192.168.1.101:8081）

2. 服务发现
   订单服务 → 查询 Nacos："user-service 有哪些实例？"
   Nacos → 返回：[192.168.1.101:8081, 192.168.1.102:8081]
   订单服务 → 选择一个实例 → 发起调用

面试题 8：什么是熔断？什么是降级？

参考答案：

熔断（Circuit Breaker）：

定义：当某个服务故障率达到阈值，自动切断调用，防止级联失败
状态：关闭 → 开启 → 半开 → 关闭
好处：快速失败，防止雪崩

降级（Fallback）：

定义：服务不可用时，返回备用响应，保证核心功能可用
场景：服务超时、异常、熔断
示例：库存服务挂了，返回"库存不足，请稍后重试"

区别：

熔断是自动切断，降级是提供备用方案
熔断是手段，降级是结果

示例：

java 复制代码

@FeignClient(name = "stock-service", fallback = StockFallback.class)
public interface StockClient {
    @GetMapping("/stock/deduct")
    Boolean deduct(@RequestParam Long productId);
}

// 降级类
@Component
public class StockFallback implements StockClient {
    @Override
    public Boolean deduct(Long productId) {
        // 降级响应：返回 false
        return false;
    }
}

面试题 9：服务网关的作用是什么？

参考答案：

作用：

统一入口：
- 客户端只需要知道网关地址
- 网关负责路由到具体服务
鉴权认证：
- 在网关层统一进行 Token 校验
- 避免每个服务都写鉴权代码
限流：
- 在网关层限流，保护后端服务
- 防止恶意请求
日志监控：
- 统一记录请求日志
- 方便问题排查
协议转换：
- HTTP → gRPC
- REST → WebSocket

示例：

yaml 复制代码

spring:
  cloud:
    gateway:
      routes:
        - id: user-service
          uri: lb://user-service  # lb = LoadBalancer
          predicates:
            - Path=/user/**  # 路径匹配

面试题 10：微服务如何保证数据一致性？

参考答案：

问题场景：

复制代码

下单流程：
1. 订单服务：创建订单 ✅
2. 库存服务：扣减库存 ❌（网络超时）

结果：订单创建了，但库存没扣（数据不一致）

解决方案：

两阶段提交（2PC）：
- 准备阶段 + 提交阶段
- 缺点：性能差、有单点故障
三阶段提交（3PC）：
- 改进 2PC，引入超时机制
- 缺点：仍然复杂
Saga 模式：
- 每个服务都有补偿操作
- 失败时执行补偿（回滚）
TCC 模式：
- Try（预留资源） + Confirm（确认） + Cancel（取消）
- Seata 支持
本地消息表：
- 记录本地消息，定时发送
- 保证最终一致性
MQ 事务消息：
- RocketMQ 支持事务消息
- 半消息机制

推荐方案：

优先考虑最终一致性（异步、MQ）
强一致性场景使用 Seata（TCC/AT 模式）

总结

本文介绍了微服务和 SpringCloud 的基础知识：

✅ 微服务架构 ：将大应用拆分成多个小服务，独立部署、独立数据库

✅ SpringCloud ：微服务解决方案，提供服务注册、调用、网关等组件

✅ 核心组件 ：Nacos、OpenFeign、Gateway、Sentinel、LoadBalancer

✅ 适用场景：大团队、高并发、需要频繁迭代的项目

下一篇预告：《SpringCloud 核心组件全解析：小白必学五大基础组件一览》

📚 推荐学习路线：

✅ 微服务基础（本文）
SpringCloud 核心组件
Nacos 实战
OpenFeign 实战
Gateway + Sentinel 实战

💡 学习建议：

先理解概念，再动手实践
每学一个组件，写一个 Demo
结合实际项目场景思考