239 lines
7.2 KiB
Markdown
239 lines
7.2 KiB
Markdown
|
# 第31天：微服务架构——把大象拆成蚂蚁
|
|||
|
|
|
|||
|
|
## 今天你将学到什么
|
|||
|
|
|
|||
|
|
今天学习微服务架构的核心思想和 AWS 上的实现方式。理解为什么大公司都在从"一个大应用"转向"多个小服务"，以及这样做的好处和挑战。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 单体架构 vs 微服务架构
|
|||
|
|
|
|||
|
|
### 单体架构（Monolith）
|
|||
|
|
|
|||
|
|
所有功能都在一个应用里：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
一个大应用：
|
|||
|
|
├── 用户管理
|
|||
|
|
├── 商品管理
|
|||
|
|
├── 订单处理
|
|||
|
|
├── 支付处理
|
|||
|
|
├── 库存管理
|
|||
|
|
├── 通知服务
|
|||
|
|
└── 数据分析
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**类比**：一家什么都卖的大超市。所有商品在一栋楼里，一个收银系统，一个仓库。
|
|||
|
|
|
|||
|
|
**优点**：
|
|||
|
|
- 开发简单（一个代码库，一个部署）
|
|||
|
|
- 本地调试方便
|
|||
|
|
- 数据一致性容易保证
|
|||
|
|
|
|||
|
|
**缺点**：
|
|||
|
|
- 代码越来越大，新人要几周才能理解
|
|||
|
|
- 改一个小功能要重新部署整个应用
|
|||
|
|
- 一个模块的 bug 可能拖垮整个系统
|
|||
|
|
- 不同模块不能独立扩展（订单模块需要 10 台服务器，但用户模块只需要 2 台）
|
|||
|
|
- 技术栈被锁定（整个应用必须用同一种语言）
|
|||
|
|
|
|||
|
|
### 微服务架构（Microservices）
|
|||
|
|
|
|||
|
|
每个功能是一个独立的小服务：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
用户服务（Python）──┐
|
|||
|
|
商品服务（Java）────┤
|
|||
|
|
订单服务（Go）──────┼── 通过 API 互相通信
|
|||
|
|
支付服务（Node.js）─┤
|
|||
|
|
库存服务（Java）────┤
|
|||
|
|
通知服务（Python）──┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**类比**：一条商业街上的多家专卖店。鞋店只卖鞋，面包店只卖面包。每家店独立经营，互不影响。鞋店装修不影响面包店营业。
|
|||
|
|
|
|||
|
|
**优点**：
|
|||
|
|
- 每个服务小而专注，容易理解和维护
|
|||
|
|
- 独立部署（改了订单服务只需要重新部署订单服务）
|
|||
|
|
- 独立扩展（订单服务压力大就多加几个实例）
|
|||
|
|
- 技术自由（每个服务可以用最适合的语言和框架）
|
|||
|
|
- 故障隔离（支付服务挂了，用户还能浏览商品）
|
|||
|
|
|
|||
|
|
**缺点**：
|
|||
|
|
- 系统复杂度增加（服务间通信、数据一致性）
|
|||
|
|
- 运维难度增加（几十个服务要监控）
|
|||
|
|
- 调试困难（一个请求可能经过 5 个服务）
|
|||
|
|
- 网络延迟（服务间调用比函数调用慢）
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 什么时候该用微服务
|
|||
|
|
|
|||
|
|
### 不要一开始就用微服务
|
|||
|
|
|
|||
|
|
**马丁·福勒（微服务概念的推广者）说过**："几乎所有成功的微服务架构，都是从一个变得太大的单体应用演化而来的。"
|
|||
|
|
|
|||
|
|
### 判断标准
|
|||
|
|
|
|||
|
|
| 情况 | 建议 |
|
|||
|
|
|------|------|
|
|||
|
|
| 团队 < 5 人 | 单体架构 |
|
|||
|
|
| 应用刚起步 | 单体架构 |
|
|||
|
|
| 团队 > 20 人 | 考虑微服务 |
|
|||
|
|
| 不同模块需要不同扩展策略 | 考虑微服务 |
|
|||
|
|
| 部署频率需要很高 | 考虑微服务 |
|
|||
|
|
| 单体已经大到难以维护 | 考虑微服务 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 微服务在 AWS 上的实现
|
|||
|
|
|
|||
|
|
### 服务运行方式
|
|||
|
|
|
|||
|
|
| 方式 | 适合 | AWS 服务 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| 容器 | 长时间运行的服务 | ECS / EKS + Fargate |
|
|||
|
|
| 无服务器 | 事件驱动、轻量服务 | Lambda + API Gateway |
|
|||
|
|
| 虚拟机 | 遗留应用、特殊需求 | EC2 + Auto Scaling |
|
|||
|
|
|
|||
|
|
### 服务间通信
|
|||
|
|
|
|||
|
|
| 方式 | 适合 | AWS 服务 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| 同步调用（HTTP/gRPC） | 需要立即得到结果 | ALB / API Gateway / App Mesh |
|
|||
|
|
| 异步消息 | 不需要立即结果 | SQS / SNS / EventBridge |
|
|||
|
|
| 事件流 | 实时数据流处理 | Kinesis / MSK（Kafka） |
|
|||
|
|
|
|||
|
|
### 服务发现
|
|||
|
|
|
|||
|
|
微服务之间怎么找到对方？
|
|||
|
|
|
|||
|
|
**传统方式**：把每个服务的地址写在配置文件里。服务地址变了就要改配置。
|
|||
|
|
|
|||
|
|
**服务发现**：服务启动时自动注册自己的地址，其他服务通过名字查找。
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
订单服务想调用用户服务：
|
|||
|
|
→ 问服务发现："用户服务在哪？"
|
|||
|
|
→ 服务发现回答："10.0.1.25:8080 和 10.0.1.26:8080"
|
|||
|
|
→ 订单服务选一个调用
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
AWS 提供 **Cloud Map** 服务做服务发现。ECS 服务可以自动注册到 Cloud Map。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 微服务的数据管理
|
|||
|
|
|
|||
|
|
### 每个服务拥有自己的数据库
|
|||
|
|
|
|||
|
|
这是微服务的核心原则之一：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
❌ 错误：所有服务共享一个数据库
|
|||
|
|
用户服务 ─┐
|
|||
|
|
订单服务 ─┼── 同一个 MySQL 数据库
|
|||
|
|
商品服务 ─┘
|
|||
|
|
（一个服务改了表结构，其他服务可能崩溃）
|
|||
|
|
|
|||
|
|
✓ 正确：每个服务有自己的数据库
|
|||
|
|
用户服务 → 用户数据库（RDS）
|
|||
|
|
订单服务 → 订单数据库（DynamoDB）
|
|||
|
|
商品服务 → 商品数据库（RDS）
|
|||
|
|
（互不影响，可以选择最适合的数据库类型）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 数据一致性挑战
|
|||
|
|
|
|||
|
|
当一个操作涉及多个服务时，如何保证数据一致？
|
|||
|
|
|
|||
|
|
**举例**：用户下单需要同时扣库存和创建订单。
|
|||
|
|
|
|||
|
|
**解决方案：Saga 模式**
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
1. 订单服务：创建订单（状态=待确认）
|
|||
|
|
2. 库存服务：扣减库存
|
|||
|
|
- 成功 → 订单服务：确认订单
|
|||
|
|
- 失败 → 订单服务：取消订单（补偿操作）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
每一步都有对应的"补偿操作"。如果某一步失败，执行前面所有步骤的补偿操作来回滚。
|
|||
|
|
|
|||
|
|
Step Functions 非常适合实现 Saga 模式。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 微服务的可观测性
|
|||
|
|
|
|||
|
|
当一个请求经过 5 个服务时，出了问题怎么排查？
|
|||
|
|
|
|||
|
|
### 分布式追踪（AWS X-Ray）
|
|||
|
|
|
|||
|
|
X-Ray 可以追踪一个请求在多个服务间的完整路径：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
用户请求 → API Gateway (5ms) → 订单服务 (20ms) → 库存服务 (15ms)
|
|||
|
|
→ 支付服务 (200ms) ← 瓶颈在这里！
|
|||
|
|
→ 通知服务 (10ms)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
一眼就能看出哪个服务慢了、哪里出了错。
|
|||
|
|
|
|||
|
|
### 集中日志（CloudWatch Logs）
|
|||
|
|
|
|||
|
|
所有服务的日志发送到 CloudWatch Logs，统一查看和搜索。
|
|||
|
|
|
|||
|
|
### 统一监控（CloudWatch）
|
|||
|
|
|
|||
|
|
所有服务的指标（CPU、内存、请求量、错误率）在一个仪表板上展示。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 微服务架构示例：电商平台
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
客户端
|
|||
|
|
↓
|
|||
|
|
API Gateway（统一入口）
|
|||
|
|
├── /users → 用户服务（ECS Fargate）→ Aurora
|
|||
|
|
├── /products → 商品服务（ECS Fargate）→ DynamoDB
|
|||
|
|
├── /orders → 订单服务（ECS Fargate）→ Aurora
|
|||
|
|
├── /payments → 支付服务（Lambda）→ 外部支付网关
|
|||
|
|
└── /notifications → 通知服务（Lambda）→ SES/SNS
|
|||
|
|
|
|||
|
|
服务间通信：
|
|||
|
|
订单服务 → SNS "订单创建" 事件
|
|||
|
|
→ SQS → 库存服务（扣库存）
|
|||
|
|
→ SQS → 通知服务（发通知）
|
|||
|
|
→ SQS → 分析服务（记录数据）
|
|||
|
|
|
|||
|
|
服务发现：Cloud Map
|
|||
|
|
分布式追踪：X-Ray
|
|||
|
|
日志：CloudWatch Logs
|
|||
|
|
监控：CloudWatch Dashboard
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 今天的小测验
|
|||
|
|
|
|||
|
|
1. 单体架构和微服务架构各自的优缺点是什么？
|
|||
|
|
2. 什么时候应该从单体转向微服务？
|
|||
|
|
3. 微服务之间的同步通信和异步通信各自适合什么场景？
|
|||
|
|
4. 为什么每个微服务应该有自己的数据库？这带来了什么挑战？
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 延伸阅读
|
|||
|
|
|
|||
|
|
- [AWS 微服务架构指南](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
|
|||
|
|
- [AWS X-Ray 开发者指南](https://docs.aws.amazon.com/xray/latest/devguide/)
|
|||
|
|
- [AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 明天预告
|
|||
|
|
|
|||
|
|
明天是第四阶段的收尾：应用架构综合实战。我们会设计一个完整的微服务应用架构，把容器、CI/CD、API Gateway、Step Functions 等知识串联起来。
|