微服务体系架构_系统演化与AI介绍详解
微服务体系架构详解：系统演化、微服务核心思想与 AI 介绍
课程位置：第四阶段「微服务项目 + AI 应用」第 1 课
前置知识：Spring Boot、MyBatis、MySQL、Redis、Git、若依、企业开发流程
下一课：Spring Cloud Alibaba——Nacos + Feign
学习目标：理解单体架构为什么会演化为分布式和微服务，建立后续 Nacos、Feign、Sentinel、Gateway 的整体认知，并理解 AI 在微服务系统中的正确位置。
1. 先理解：微服务到底是什么
很多初学者会把微服务理解为：
一个 Spring Boot 项目
↓
拆成多个 Spring Boot 项目
这个理解只说对了一小部分。
真正的微服务是：
一个大型系统
↓
按照业务能力拆分成多个自治服务
↓
每个服务独立开发
独立运行
独立部署
独立扩缩容
↓
服务之间通过网络通信
例如电商系统原来是：
mall
├─ 用户
├─ 商品
├─ 库存
├─ 订单
└─ 支付
拆成微服务以后可能变成：
user-service
product-service
stock-service
order-service
payment-service
注意：
微服务最关键的不是“项目数量变多”
而是“业务边界和运行边界发生了变化”
2. 为什么拆开之后反而更难
单体中：
userService.getById(id);
只是 JVM 内部方法调用。
微服务中：
order-service
↓ HTTP
user-service
就变成网络调用。
网络调用天然存在：
服务不可用
网络抖动
响应超时
连接失败
重复请求
请求丢失
部分成功
多实例负载均衡
因此：
微服务不是消灭复杂度
而是把“单体内部复杂度”
换成“分布式系统复杂度”
这句话一定要记住。
3. 那为什么企业还要微服务
当系统规模越来越大，单体会出现新的问题：
代码仓库越来越庞大
多个团队修改同一工程
发布越来越慢
一个模块故障影响整个 JVM
不同模块扩容需求不一致
技术升级互相牵制
例如：
搜索模块每天 100 万请求
后台字典管理每天 100 次请求
单体只能：
整个应用一起扩容
微服务可以：
search-service 扩 20 个实例
system-service 只运行 2 个实例
所以微服务的价值更多体现在：
独立演进
独立部署
独立扩容
团队自治
故障隔离
而不是：
“单次请求一定更快”
事实上，远程调用通常比本地方法调用更慢。
4. 微服务不是越高级越好
架构没有绝对高级低级，只有：
是否适合当前业务
下面这些项目通常不需要一开始就拆微服务：
毕业设计
小型后台系统
团队 2~5 人
访问量不高
业务模块不多
没有独立扩容要求
这时：
模块化单体
通常更简单、更稳定。
5. 为什么前面的淘车湾不需要微服务
淘车湾虽然有：
预约
工单
服务项目
套餐
结算
审批
但课程项目中：
团队规模小
访问量小
部署简单
模块之间关系紧密
如果强行拆成：
appointment-service
workorder-service
settlement-service
workflow-service
会立即增加：
远程调用
服务发现
分布式事务
配置中心
部署
日志追踪
联调成本
收益反而不明显。
所以：
小项目不要为了简历“看起来高级”而强行微服务
6. 系统架构是怎么演化的
常见路线可以记成：
单体架构
↓
模块化单体
↓
分布式服务
↓
微服务
↓
云原生
7. 第一阶段：单体架构
一个 Spring Boot：
mall-server
├─ user
├─ product
├─ order
├─ stock
└─ payment
整个应用：
一个 JVM
一个部署单元
启动：
java -jar mall.jar
单体优点
开发简单
部署简单
本地调试简单
方法调用简单
事务简单
性能损耗低
例如：
@Transactional
public void createOrder() {
orderMapper.insert(...);
stockMapper.update(...);
}
如果都在：
同一个数据库
同一个事务
Spring 本地事务很好处理。
8. 单体什么时候出现瓶颈
当项目越来越大：
3 人 → 100 人
5 万行代码 → 100 万行代码
1 个业务 → 几十个业务域
问题开始出现：
一个小功能也要整个项目发布
代码冲突越来越多
测试范围越来越大
启动越来越慢
故障影响范围越来越大
不同模块不能独立扩容
这时才真正出现拆分价值。
9. 模块化单体
在真正拆微服务前，非常推荐先做到：
一个部署单元
但内部业务模块边界清晰
例如：
mall
├─ user
├─ order
├─ stock
└─ payment
每个模块：
职责清楚
不要随意互相访问内部实现
如果一个单体内部已经乱成一团，直接拆微服务往往会变成：
把原来的混乱
搬到网络上
所以：
微服务之前先做好模块边界
10. 什么是分布式系统
简单理解：
一个完整业务
由多个独立进程/机器共同完成
例如：
order-service
↓
stock-service
↓
payment-service
这些服务：
不在同一个 JVM
需要：
网络通信
微服务一定属于分布式系统，但：
分布式系统不一定都是微服务架构
11. 微服务应该怎么拆
最重要原则：
按业务能力拆
正确：
user-service
order-service
payment-service
travel-service
错误：
controller-service
service-service
mapper-service
后者只是按技术分层拆，没有业务自治意义。
12. 为什么不能“一张表一个服务”
例如：
customer-service
vehicle-service
appointment-service
appointment-item-service
如果只是因为：
一张表 = 一个服务
通常会导致服务数量爆炸。
微服务应该代表：
相对完整的业务能力
而不是：
数据库表
13. 高内聚、低耦合
高内聚
相关业务尽量放在一起：
订单创建
订单取消
订单查询
订单状态
放在：
order-service
低耦合
服务之间：
不要依赖太多内部细节
例如订单服务不要：
直接读取用户服务的数据表
14. 服务拥有自己的数据
理想微服务架构强调：
Database per Service
例如：
user-service
→ user_db
order-service
→ order_db
payment-service
→ payment_db
其他服务原则上：
不要随便直接操作别人的数据库
因为如果：
order-service 直接 JOIN user 表
那么 user-service 修改数据库结构后：
order-service 也被直接影响
这会破坏服务自治。
15. 跨服务数据怎么获取
例如订单详情需要用户名。
单体可以：
SELECT ...
FROM orders o
JOIN users u ...
微服务更常见：
Order Service 查订单
↓
调用 User Service
↓
组装结果
但这又引出一个新问题：
远程调用成本
16. 远程 N+1
如果查询 100 个订单，然后：
循环 100 次调用 user-service
就是：
远程 N+1
比数据库 N+1 更危险，因为每次都是：
网络调用
常见优化：
批量接口
缓存
数据冗余
事件同步
17. 微服务通信方式
主要分：
同步通信
异步通信
同步
常见：
HTTP
REST
RPC
调用方：
必须等待结果
例如：
订单创建前立即检查用户是否存在
异步
常见：
RabbitMQ
RocketMQ
Kafka
例如订单创建后：
发送订单已创建消息
↓
积分服务增加积分
↓
通知服务发送通知
调用方：
不需要等待全部后续动作
18. 同步和异步不是二选一
适合同步：
登录
即时价格查询
立即库存校验
必须马上拿到结果的业务
适合异步：
通知
积分
日志
异步报表
非实时数据同步
19. 微服务第一个问题：服务地址怎么找
假设：
user-service
现在在：
192.168.1.10:8081
如果订单服务写死：
http://192.168.1.10:8081
扩容后：
192.168.1.10:8081
192.168.1.11:8081
192.168.1.12:8081
调用方该找谁？
如果服务器重启，地址又变了怎么办？
于是需要：
注册中心
20. 注册中心
核心功能：
服务注册
服务发现
服务注册
user-service 启动：
告诉注册中心：
我的服务名是 user-service
我的实例地址是 xxx
服务发现
order-service：
询问注册中心：
user-service 有哪些可用实例？
注册中心返回：
实例列表
课程下一课会使用：
Nacos
21. 服务名和 IP 的区别
服务名：
user-service
是：
逻辑名称
它可能对应：
10.0.0.1:8081
10.0.0.2:8081
10.0.0.3:8081
Nacos 维护的是类似：
服务名 → 实例列表
22. 第二个问题：多个实例选哪个
如果 user-service 有 3 个实例：
调用方需要选其中一个
这就是：
负载均衡
常见策略概念：
轮询
随机
权重
Spring Cloud 中常见：
Spring Cloud LoadBalancer
23. 水平扩容与垂直扩容
垂直扩容
一台服务器：
4 核 → 16 核
8GB → 64GB
水平扩容
1 个实例 → 10 个实例
微服务非常适合：
按服务独立水平扩容
例如只扩：
search-service
不用整个系统一起扩。
24. 第三个问题：远程调用代码很麻烦
如果每次都手写 HTTP：
URL
参数
请求
响应解析
异常
代码会很多。
于是 Spring Cloud 提供：
OpenFeign
例如：
@FeignClient("user-service")
public interface UserClient {
@GetMapping("/users/{id}")
UserVO getById(
@PathVariable Long id
);
}
业务代码：
UserVO user =
userClient.getById(1L);
看起来像：
本地 Java 接口
但本质仍然是：
网络 HTTP 调用
这点非常重要。
25. Feign 不是本地方法
即使代码：
userClient.getById(1L)
很像：
userService.getById(1L)
也必须考虑：
连接失败
响应超时
服务不可用
返回异常
所以：
远程调用一定不能用“本地方法调用思维”
26. 第四个问题：服务雪崩
假设：
A → B → C
C 突然响应 30 秒。
B：
大量线程等待 C
随后 B 资源耗尽。
A：
又大量等待 B
最后：
C 故障
↓
B 被拖垮
↓
A 被拖垮
↓
越来越多服务不可用
这就是：
服务雪崩
27. 怎么防雪崩
常见思想：
超时
限流
熔断
降级
隔离
课程后面会学：
Sentinel
28. 什么是限流
接口最大安全能力：
1000 QPS
突然：
10000 QPS
如果全部放进来：
系统可能直接崩
限流：
只允许系统能承受的流量进入
29. 什么是熔断
如果某个下游连续失败：
短时间内不再继续请求它
而是：
快速失败
目的：
避免继续浪费资源
可以类比：
保险丝
30. 什么是降级
例如推荐服务挂了：
不能让整个首页也挂掉
可以降级：
AI 推荐失败
↓
返回普通热门推荐
核心思想：
非核心能力出问题
不应该拖垮核心业务
31. 第五个问题：前端访问谁
微服务系统有：
user-service
order-service
travel-service
search-service
ai-service
不推荐 Vue：
直接记所有服务地址
于是需要：
API Gateway
32. Gateway
可以理解为：
微服务系统统一大门
例如：
Vue
↓
Gateway
├─ /user/** → user-service
├─ /order/** → order-service
└─ /travel/** → travel-service
Gateway 常做：
路由
统一鉴权
限流
跨域
日志
路径重写
课程后面学习：
Spring Cloud Gateway
33. Gateway 和 Nginx 的区别
两者都能：
反向代理
但常见架构：
Nginx
↓
Gateway
↓
Microservices
Nginx 更偏：
网络入口
TLS
静态资源
反向代理
负载均衡
Gateway 更偏：
Spring Cloud 服务路由
认证上下文
服务发现
业务过滤器
34. 第六个问题：配置太多
20 个服务可能有：
20 份 application.yml
数据库地址变化时：
每个服务都改
非常麻烦。
于是需要：
配置中心
课程中：
Nacos Config
会负责集中配置。
35. Nacos 可以解决两个核心问题
课程里先记：
Nacos
=
注册中心
+
配置中心
下一课会详细讲：
Namespace
Group
DataId
服务注册
服务发现
配置管理
36. 第七个问题：分布式事务
单体：
@Transactional
可能操作：
order 表
stock 表
如果同数据库：
本地事务
很好解决。
微服务拆开后：
order-service → order_db
stock-service → stock_db
出现：
订单成功
库存失败
怎么办？
这就是：
分布式事务问题
37. 为什么 @Transactional 不够
普通 Spring 事务：
只能直接控制当前事务资源
它不能神奇地：
自动回滚另一台服务器上的数据库事务
因此微服务以后会遇到：
Seata
TCC
Saga
事务消息
本地消息表
最终一致性
当前先理解：
为什么问题会出现
不要急着背实现。
38. CAP
三个字母：
C = Consistency
一致性
A = Availability
可用性
P = Partition Tolerance
分区容错性
最重要的理解不是“死背三选二”，而是：
当网络分区真正发生时
系统必须面对一致性与可用性的权衡
分布式系统无法假设：
网络永远不会断
所以 P 是现实中必须考虑的问题。
39. CP 和 AP
CP 倾向
优先保证：
一致性
分区时：
部分请求可能拒绝
AP 倾向
优先保证：
可用性
允许：
暂时不一致
40. BASE
常见展开：
Basically Available
Soft State
Eventually Consistent
核心理解：
允许短时间不完全一致
最终达到一致
例如：
订单成功
↓
积分 2 秒后到账
通常可以接受。
这就是：
最终一致性
41. 不是什么业务都适合最终一致
例如：
支付扣款
库存扣减
账户余额
一致性要求通常更高。
所以要问：
这个业务晚几秒一致，能不能接受？
能：
可以考虑异步最终一致
不能：
需要更强一致性策略
42. 第八个问题：链路怎么排错
单体：
一个日志文件
微服务一次请求可能：
Gateway
↓
Order
↓
User
↓
Stock
↓
Payment
出错后要知道：
到底是哪一步出问题
于是需要：
分布式链路追踪
43. TraceId
一次请求生成：
traceId = abc123
沿调用链传递。
所有服务日志：
都带 abc123
这样搜索：
abc123
就能看到整个请求。
44. 可观测性
现代系统常说：
Logs
Metrics
Traces
中文：
日志
指标
链路
合起来就是：
Observability
可观测性
45. 第九个问题：微服务安全
单体：
认证后就在一个应用里
微服务：
身份要穿过多个服务
常见思路：
客户端
↓
Gateway 认证
↓
内部服务收到可信身份上下文
↓
业务服务继续做权限校验
绝不能：
因为前端传 userId
就认为身份可信
46. 无状态服务
微服务通常推荐：
Stateless
例如不要把登录 Session：
只保存在某一台 user-service 内存
因为负载均衡后：
第一次请求 → 实例 A
第二次请求 → 实例 B
B 不知道 A 的内存状态。
常见解决：
JWT
Redis
数据库
把共享状态放到：
实例之外
47. 为什么不能把远程地址写 localhost
在本地：
localhost:8081
看起来正常。
但 Docker / 服务器环境中：
localhost
通常表示：
当前这个容器/机器自己
它不一定是另一个服务。
所以微服务应该更多使用：
服务名
+
服务发现
48. 服务健康检查
服务注册并不代表：
永远健康
服务可能：
挂掉
卡死
网络断开
注册中心或平台需要知道：
这个实例还能不能接请求
所以会涉及：
心跳
健康检查
后面 Nacos 会具体学习。
49. 微服务组件总地图
先记住：
Nacos
→ 找服务 + 管配置
Feign
→ 调服务
Sentinel
→ 保护服务
Gateway
→ 统一入口
这四句话非常重要。
50. Spring Boot 和 Spring Cloud 区别
可以记：
Spring Boot
=
快速写出一个服务
Spring Cloud
=
让很多服务协同工作
Spring Cloud 关注：
服务发现
配置
服务调用
负载均衡
熔断
路由
分布式系统通用模式
51. Spring Cloud Alibaba
Spring Cloud Alibaba 是：
Spring Cloud 生态中的 Alibaba 分布式解决方案集成
课程中主要接触：
Nacos
Sentinel
并配合 Spring Cloud 的：
OpenFeign
Gateway
LoadBalancer
构建微服务系统。
52. 版本兼容特别重要
微服务依赖不是：
随便找个最新版就能混用
要匹配：
JDK
Spring Boot
Spring Cloud
Spring Cloud Alibaba
当前官方 Spring Cloud Alibaba 仓库给出的主要分支关系包括：
2025.1.x
→ Spring Cloud 2025.1.x
→ Spring Boot 4.0.x
→ JDK 17+
2025.0.x
→ Spring Cloud 2025.0.x
→ Spring Boot 3.5.x
→ JDK 17+
2023.x
→ Spring Cloud 2023
→ Spring Boot 3.2.x
→ JDK 17+
2022.x
→ Spring Cloud 2022
→ Spring Boot 3.0.x
→ JDK 17+
因此你的正确操作顺序是：
先看 Spring Boot 版本
↓
查对应 Spring Cloud
↓
查对应 Spring Cloud Alibaba
↓
再引依赖
不要：
Boot 3.2
+
网上随手复制最新 SCA 依赖
53. BOM 是什么
BOM：
Bill of Materials
可以理解：
一套统一依赖版本清单
微服务组件很多，因此通常使用：
<dependencyManagement>
统一版本。
不要：
每个 Spring Cloud 依赖自己随便填版本
54. 服务治理
微服务真正难的是：
治理
所谓服务治理，就是处理：
服务在哪里
谁调用谁
调用失败怎么办
流量太大怎么办
配置怎么统一
日志怎么追踪
因此：
注册中心
负载均衡
熔断
限流
配置中心
Gateway
链路追踪
都属于服务治理的重要内容。
55. 重试为什么危险
很多人觉得：
失败了再试一次就行
但如果下游已经过载：
所有请求都自动重试 3 次
原来 10000 请求：
可能变 30000 次调用
这会形成：
重试风暴
56. 重试需要考虑三件事
次数限制
退避
幂等
57. 幂等
幂等简单理解：
同一个请求执行多次
最终业务效果仍然只有一次
例如支付：
同一个 paymentNo
请求两次
不能：
扣两次钱
常见手段：
业务唯一号
数据库 UNIQUE
状态机
幂等 Token
去重记录
58. 为什么网络环境更需要幂等
可能发生：
服务端已经处理成功
↓
响应在网络中丢失
↓
调用方认为失败
↓
自动重试
如果没有幂等：
业务执行两次
59. 超时
任何远程调用都应该有：
合理超时时间
不能无限等待。
因为下游卡住时：
调用线程
连接
资源
会一直被占用。
60. Design for Failure
微服务设计要接受一个事实：
故障是常态
应该假设：
网络会失败
服务会重启
下游会超时
消息会重复
所以每次远程调用都要问：
超时多久？
失败怎么办？
能重试吗？
是否幂等？
能降级吗？
61. 微服务数据库的代价
原来一个单体：
一个连接池 20 个连接
如果拆 20 个服务：
每个服务 20 个连接
理论可能变：
400 个数据库连接
所以微服务会增加：
JVM
连接池
日志
配置
容器
监控
运维
基础设施成本。
62. 微服务和 Docker
服务很多以后：
运行环境难统一
Docker 能把：
应用 + 运行环境
打成容器。
因此 Docker 和微服务经常一起出现。
但：
Docker ≠ 微服务
单体也可以 Docker 部署。
63. Kubernetes
以后可能接触：
Kubernetes
它主要解决：
容器编排
部署
扩缩容
自愈
服务管理
当前阶段先建立概念即可。
64. 云原生
Cloud Native 不是：
把服务器搬到云上
它更强调：
容器化
自动化
弹性
可观测性
微服务
微服务经常是云原生体系的一部分，但：
两者不完全等价
65. 一个完整微服务请求
例如旅行平台：
Vue
↓
Gateway
↓
travel-service
↓ Feign
user-service
服务注册：
travel-service
user-service
↓
Nacos
流量保护：
Sentinel
66. 推荐先记住这张图
Client
│
▼
Gateway
│
┌──────────┼──────────┐
▼ ▼ ▼
user-service travel-service order-service
│ │ │
└─────► Nacos ◄───────┘
注册 / 发现
配置管理
服务之间：
Feign
保护：
Sentinel
67. 服务拆得太细会怎样
如果一个页面需要：
A → B → C → D → E → F
同步链越长：
延迟越高
失败点越多
排查越难
因此不要：
为了“微”而无限拆
68. 避免循环依赖
危险：
A → B
B → C
C → A
会造成：
职责混乱
调用链复杂
故障传播
遇到这种结构要重新考虑：
业务边界
数据归属
是否用事件解耦
69. API 契约
服务之间通信以后，接口就是：
契约
包括：
URL
Method
参数
返回
错误码
字段语义
接口一旦很多服务依赖：
不能随便破坏
70. 为什么跨服务不要直接返回 Entity
数据库 Entity：
属于服务内部实现
如果直接作为 Feign 返回值：
数据库结构
就扩散到了其他服务
推荐：
RemoteDTO
UserDTO
OrderVO
只暴露真正需要的数据。
71. AI 介绍：AI 在系统里是什么位置
现在进入本课第二部分：
AI 介绍
AI 很广，包括：
机器学习
深度学习
自然语言处理
计算机视觉
大语言模型
当前 Java AI 应用路线最常遇到的是：
LLM
大语言模型
72. Java 项目怎么接 AI
最简单架构：
Vue
↓
Java Backend
↓ HTTP / SDK
AI Model
↓
Java Backend
↓
Vue
例如：
用户输入：
“大连三天两晚，预算2000，喜欢海边”
↓
Java 调用大模型
↓
模型生成推荐
↓
后端处理
↓
返回前端
73. AI 可以独立成 ai-service 吗
可以：
ai-service
负责：
模型调用
Prompt
结果格式化
RAG
AI 限流
模型切换
但：
不是所有项目都必须拆 ai-service
小项目直接在业务服务调用 AI SDK：
也完全可以
74. 什么情况下适合独立 AI 服务
例如：
多个业务模块都调用 AI
模型调用量很大
需要单独扩容
需要统一 Prompt 管理
需要统一成本控制
模型供应商经常切换
这时：
独立 ai-service
更有价值。
75. AI 服务为什么特别需要超时
AI 模型通常比普通数据库查询：
慢很多
可能：
1 秒
5 秒
20 秒
甚至更久
如果无限等待：
很容易占满服务资源
所以：
AI 调用必须设置合理超时
76. AI 为什么需要降级
例如首页有：
AI 个性推荐
模型服务挂了：
不应该让首页直接 500
可以：
AI 推荐失败
↓
返回普通热门目的地
这就是：
Fallback
77. AI 为什么不能直接决定支付和权限
大模型输出具有：
非确定性
所以不要：
让 AI 自由决定金额
让 AI 自由决定用户权限
让 AI 直接删数据库
核心业务必须仍由：
确定性 Java 代码
数据库状态
权限规则
控制。
78. AI 输入输出都不可信
用户输入：
不可信
模型输出：
也不可信
例如模型返回：
{
"discount": 999999
}
后端不能：
直接执行
必须：
DTO 反序列化
字段校验
业务规则校验
79. AI 最适合做什么
例如：
自然语言理解
内容生成
问答
总结
推荐说明
信息抽取
智能检索
知识库
客服
80. RAG 先认识
RAG：
Retrieval-Augmented Generation
中文：
检索增强生成
简单流程：
用户问题
↓
先检索自己的知识库
↓
找到相关资料
↓
把资料交给大模型
↓
模型基于资料回答
后续 AI 阶段会深入。
81. Agent 先认识
Agent 可以简单理解：
大模型
+
工具
+
多步骤执行
例如旅行助手：
理解需求
↓
查景点
↓
查酒店
↓
查天气
↓
生成行程
当前先知道名字即可。
82. AI 和微服务为什么很适合结合
AI 调用有特点：
慢
贵
不稳定
第三方依赖
并发限制
因此非常适合结合：
限流
熔断
缓存
异步
降级
这些正是微服务治理关注的问题。
83. AI 长任务为什么适合异步
例如：
生成完整 7 天旅行计划
如果模型需要 30 秒：
HTTP 一直等待
体验不好。
可以设计：
提交任务
↓
MQ
↓
AI Worker
↓
生成结果
↓
保存数据库
↓
用户查询结果
84. AI 和核心业务的边界
推荐：
AI
负责：
理解、生成、推荐、辅助
普通 Java 业务代码
负责：
权限、资金、库存、状态、事务
85. Spring Cloud Alibaba 与 Spring AI Alibaba 不一样
不要混淆：
Spring Cloud Alibaba
→ 微服务治理
Spring AI Alibaba
→ AI 应用开发
名字很像，但职责不同。
86. 第四阶段课程地图
第 1 课
微服务体系架构
↓
理解为什么
第 2 课
Nacos + Feign
↓
服务在哪里、怎么调用
第 3 课
Sentinel
↓
流量大、服务故障怎么办
第 4 课
Gateway
↓
外部请求从哪里进入
后面
若依 Cloud
↓
完整脚手架
智途 AI 旅行项目
↓
真实微服务实战
87. 最核心的四句话
Nacos
找到服务
Feign
调用服务
Sentinel
保护服务
Gateway
进入服务
先把这四句话背下来。
88. 服务注册完整链路
user-service 启动
↓
注册到 Nacos
↓
Nacos 保存实例列表
↓
order-service 要调用 user-service
↓
服务发现获取实例
↓
LoadBalancer 选择一个
↓
Feign 发 HTTP
89. 服务故障完整链路
user-service 变慢
↓
Feign 请求超时
↓
大量失败
↓
Sentinel 统计异常
↓
熔断 / 降级
↓
快速返回
↓
避免 order-service 被拖垮
90. Gateway 请求链
Vue
↓
Gateway
↓
鉴权
↓
路由
↓
order-service
↓
Feign
↓
user-service
91. 微服务开发为什么本地更麻烦
单体：
启动一个 Spring Boot
微服务：
Gateway
User Service
Order Service
Travel Service
Nacos
Redis
MySQL
可能都要启动。
因此：
本地资源占用更高
调试更复杂
92. IDEA 微服务学习建议
后面建议建立父工程：
spring-cloud-demo
├─ user-service
├─ order-service
└─ common
父 Maven：
<packaging>pom</packaging>
统一：
依赖版本
模块管理
93. 每个服务都要有名字
例如：
spring:
application:
name: user-service
为什么重要？
因为后面：
Nacos
Feign
Gateway
都会围绕：
service name
工作。
94. 多服务端口不能都一样
例如：
gateway 8080
user-service 8081
order-service 8082
如果都用：
8080
本机启动就会：
端口冲突
95. 最好的学习顺序
下一课不要一开始就把：
Nacos
Feign
LoadBalancer
Gateway
Sentinel
全部塞进去。
推荐：
两个普通 Spring Boot 服务
↓
先写死 URL 调用
↓
亲自遇到地址问题
↓
再加 Nacos
↓
再加 Feign
这样你会真正知道：
组件到底解决了什么问题
96. 常见误区
误区 1
微服务一定比单体性能高
错误。
网络调用：
通常更慢
误区 2
服务越多越专业
错误。
误区 3
用了微服务就自动高并发
错误。
高并发仍需要：
Redis
限流
异步
数据库优化
误区 4
@FeignClient 像本地方法，所以一定成功
错误。
误区 5
@Transactional 可以回滚所有微服务
错误。
误区 6
Gateway 里应该写所有业务逻辑
错误。
Gateway 应主要负责：
入口横切能力
97. 常见错误排查思维
服务 A 调不到服务 B：
1. B 启动了吗
2. B 注册了吗
3. 服务名一致吗
4. Nacos 能看到吗
5. 网络通吗
6. Feign 配置对吗
7. URL Mapping 对吗
98. 面试题：什么是微服务
答：
微服务是一种围绕业务能力拆分应用的架构方式。
每个服务具有相对独立的业务职责，
可以独立开发、部署和扩缩容，
服务之间通过网络进行通信。
它提升了服务自治和团队协作能力，
同时也引入服务发现、远程调用、
分布式事务和可观测性等复杂问题。
99. 面试题：微服务和单体哪个好
答：
没有绝对好坏。
单体开发、部署、调试和事务更简单，
更适合小团队和中小型系统。
微服务适合业务和团队规模较大，
并且存在独立部署、独立扩容需求的系统。
架构应该匹配业务规模，而不是为了技术先进强行拆分。
100. 面试题：为什么需要注册中心
答：
微服务实例会随着扩容、缩容和重启动态变化。
如果调用方写死 IP 和端口，
配置难以维护。
注册中心让服务启动后注册实例，
调用方通过服务名动态发现可用实例。
101. 面试题：为什么需要 Feign
答：
Feign 把服务间 HTTP 调用封装成声明式 Java 接口，
减少手工构造 URL、请求和响应解析代码。
但 Feign 本质仍是远程网络调用，
仍然需要考虑超时、失败、重试和降级。
102. 面试题：什么是服务雪崩
答：
下游服务变慢或故障后，
上游大量请求持续等待，
线程和连接等资源逐渐耗尽。
故障沿调用链继续向上传播，
最终使更多服务不可用，
这就是服务雪崩。
103. 面试题：熔断与降级区别
答：
熔断是在下游持续异常时暂时停止继续调用，
防止资源继续消耗和故障扩散。
降级是某项能力不可用时返回简化结果，
优先保证核心业务可用。
两者经常配合使用。
104. 面试题：为什么需要 Gateway
答：
微服务很多以后，
不适合客户端维护所有服务地址。
Gateway 提供统一入口，
负责路由，并可以集中处理鉴权、限流、跨域和日志等横切逻辑。
105. 面试题：为什么需要分布式事务
答：
微服务拆分后，一个业务操作可能跨多个服务和数据库。
某个服务成功、另一个服务失败时，
普通本地 @Transactional 无法统一回滚远程服务的数据，
因此产生分布式事务和数据一致性问题。
106. 面试题：CAP 是什么
答：
CAP 描述分布式系统中的一致性、
可用性和分区容错性。
当网络分区发生时，
系统需要在一致性和可用性之间做权衡。
实际分布式系统必须面对网络故障，
不能假设网络永远可靠。
107. 面试题：BASE 是什么
答：
BASE 是一种允许系统短时间处于非强一致状态，
但最终达到一致的分布式设计思想。
例如订单完成后积分晚几秒到账，
如果业务可以接受，就适合采用最终一致性方案。
108. 面试题：为什么远程调用要设置超时
答：
如果下游服务卡住而调用方无限等待，
线程、连接等资源会持续被占用。
大量请求积累后，
调用方本身也会被拖垮。
因此远程调用必须设置合理超时。
109. 面试题：为什么重试必须考虑幂等
答：
服务端可能已经处理成功，
但响应因为网络异常没有返回。
调用方重试时，
同一个业务可能再次执行。
所以写操作必须通过业务唯一号、状态机、
唯一约束等方式保证重复请求不会产生重复副作用。
110. 面试题：为什么服务不要直接访问其他服务数据库
答：
直接访问其他服务数据库会形成强数据耦合。
对方修改表结构时，
当前服务也会受到直接影响。
微服务强调数据归属，
跨服务数据应该优先通过接口或事件交互。
111. 面试题：Spring Boot 和 Spring Cloud 区别
答：
Spring Boot 主要帮助快速构建一个独立 Spring 应用。
Spring Cloud 主要解决多个分布式应用之间的通用治理问题，
例如服务发现、配置、服务调用、负载均衡、熔断和路由。
112. 面试题：为什么微服务不是越多越好
答：
每增加一个服务边界，
都会增加网络调用、部署、配置、日志、
监控和分布式事务成本。
拆分应该围绕真实业务边界和独立演进需求，
而不是追求服务数量。
113. 面试题：AI 为什么不能直接决定核心业务
答：
大模型输出具有非确定性。
权限、支付、库存和不可逆数据库操作
必须由确定性后端规则进行最终验证和执行。
AI 更适合作为理解、生成、推荐和辅助能力。
114. 本章知识树
微服务体系
│
├─ 系统演化
│ ├─ 单体
│ ├─ 模块化单体
│ ├─ 分布式
│ ├─ 微服务
│ └─ 云原生
│
├─ 服务设计
│ ├─ 业务边界
│ ├─ 高内聚
│ ├─ 低耦合
│ ├─ 数据归属
│ └─ 独立部署
│
├─ 服务通信
│ ├─ HTTP
│ ├─ Feign
│ └─ MQ
│
├─ 服务治理
│ ├─ Nacos
│ ├─ 服务发现
│ ├─ LoadBalancer
│ ├─ Sentinel
│ └─ Gateway
│
├─ 稳定性
│ ├─ Timeout
│ ├─ Retry
│ ├─ Idempotency
│ ├─ Circuit Breaker
│ ├─ Fallback
│ └─ Rate Limit
│
├─ 一致性
│ ├─ 本地事务
│ ├─ 分布式事务
│ ├─ CAP
│ ├─ BASE
│ └─ 最终一致性
│
├─ 可观测性
│ ├─ Logs
│ ├─ Metrics
│ ├─ Traces
│ └─ TraceId
│
└─ AI
├─ LLM
├─ AI Service
├─ RAG
├─ Agent
├─ Timeout
└─ Fallback
115. 本章最重要的 20 条原则
1. 微服务不是简单把一个项目拆成很多项目
2. 微服务本质属于分布式系统
3. 微服务不是越多越好
4. 服务应该按业务能力拆
5. 一个表一个服务通常是错误思路
6. 模块化单体是非常重要的过渡形态
7. 服务之间的网络调用一定可能失败
8. 服务应该尽量拥有自己的数据
9. 跨服务不要直接依赖对方数据库
10. 同步调用链不要过长
11. 远程调用必须设置超时
12. 重试必须考虑幂等
13. Nacos 解决服务发现和配置管理
14. Feign 简化服务间调用
15. Sentinel 保护服务
16. Gateway 提供统一入口
17. @Transactional 不能自动解决跨服务事务
18. CAP 和 BASE 是分布式一致性的基础
19. AI 是增强能力，不应绕过确定性业务规则
20. 架构永远应该匹配实际业务与团队规模
116. 练习：组件匹配
请先自己回答：
服务 IP 经常变化
→ ?
想像 Java 接口一样调用远程服务
→ ?
下游挂掉拖垮上游
→ ?
前端不知道应该访问哪个服务
→ ?
20 个服务的配置不好管理
→ ?
订单成功库存失败
→ ?
请求链太长不知道哪里慢
→ ?
答案：
Nacos
Feign
Sentinel
Gateway
Nacos Config
分布式事务 / 最终一致性
分布式链路追踪
117. 练习：判断是否应该拆微服务
场景：
3 人团队
内部后台
20 张业务表
每天 500 用户
更推荐：
模块化单体
而不是：
拆 20 个服务
118. 练习：雪崩分析
调用链：
Gateway
↓
Order
↓
Stock
↓
第三方 API
第三方 API：
响应 30 秒
思考：
如果没有超时、熔断和隔离
Order 与 Stock 会怎样？
119. 练习：AI 降级
如果：
AI 旅行推荐服务不可用
不要：
整个首页 500
设计：
AI 失败
↓
回退数据库热门景点
120. Cursor 提示词：判断是否真的需要微服务
请先分析，不修改代码。
当前项目是 Spring Boot 单体应用。
请根据：
1. 团队规模
2. 业务模块数量
3. 日访问量/QPS
4. 模块独立发布需求
5. 模块独立扩容需求
6. 数据一致性复杂度
7. 运维能力
判断是否真的应该拆微服务。
不要因为“技术更高级”就建议拆分。
如果不需要，请给模块化单体建议。
如果需要，请给最少必要服务边界。
121. Cursor 提示词：设计服务边界
请根据当前业务设计微服务边界。
要求：
1. 按业务能力拆，不按 Controller 或数据库表拆
2. 每个服务职责清晰
3. 标出每个服务拥有的数据
4. 标出同步调用
5. 标出适合 MQ 异步的地方
6. 标出潜在分布式事务
7. 检查循环依赖
8. 避免服务拆得过细
122. Cursor 提示词：远程调用风险审查
请分析当前微服务调用链。
找出：
1. 最长同步调用链
2. 没设置超时的调用
3. 不安全的自动重试
4. 非幂等写操作
5. 可异步化调用
6. 雪崩风险
7. 远程 N+1
8. 循环调用
先输出风险，不直接修改。
123. Cursor 提示词：AI 服务设计
我要在旅行系统中加入 AI 助手。
请设计最小方案。
要求：
1. 判断是否真的需要独立 ai-service
2. AI 负责自然语言理解、生成和推荐
3. 订单、支付、权限继续使用确定性 Java 业务规则
4. AI 调用必须有超时
5. 设计模型不可用时的 Fallback
6. 重复请求可考虑 Redis 缓存
7. 长耗时任务分析是否适合 MQ
8. AI 输出转换 DTO 并校验
9. 不允许模型直接操作数据库
124. 下一课实战准备
下一篇：
《Spring Cloud Alibaba：Nacos + Feign 详解》
我们会按照最适合初学者的顺序：
1. 创建父 Maven 工程
2. 创建 user-service
3. 创建 order-service
4. 先写死 URL 调用
5. 亲自看到写死地址的问题
6. 安装和启动 Nacos
7. 服务注册
8. 服务发现
9. DiscoveryClient
10. LoadBalancer
11. OpenFeign
12. @FeignClient
13. PathVariable / RequestParam / RequestBody
14. 远程 DTO
15. 多实例负载均衡
16. Nacos Namespace / Group / DataId
17. 配置中心
你会真正看到：
order-service
从：
http://localhost:8081/users/1
变成：
通过服务名 user-service
动态找到实例并调用
这才是真正开始进入 Spring Cloud Alibaba 微服务代码实战。
125. 版本学习提醒
微服务的版本兼容比普通 Spring Boot 项目更严格。
以后每次搭建项目都按：
JDK
↓
Spring Boot
↓
Spring Cloud Release Train
↓
Spring Cloud Alibaba
↓
Nacos / Sentinel 等组件
这个顺序确认。
不要照搬多年以前博客中的：
Spring Boot 2
Spring Cloud Hoxton
老版 Ribbon
老版 Hystrix
然后混入：
Spring Boot 3
下一课会继续以：
JDK17 + Spring Boot 3
为主线来写练习。