feat: update docs and components, fix DLQ demo bug

2026-01-18 12:21:49 +08:00
parent 26ed39e1eb
commit e41063a1cd
159 changed files with 54236 additions and 2525 deletions
@@ -16,24 +16,48 @@

 ---

-## 1. 简单粗暴：单体架构 (Monolith)
+## 1. 原始时代：物理服务器 & CGI (1990s)
+
+在互联网刚起步时，后端就是一台放在机房里的**物理服务器**。
+你把 `index.html`、`script.pl` 通过 FTP 传上去，用户访问时服务器逐个执行脚本。
+
+### 1.1 痛点：慢、贵、难扩展
+
+- **慢**：每次改代码都要手动上传。
+- **贵**：扩容只能买更大的机器。
+- **难扩展**：一台机器顶住所有请求，坏了就全站宕机。
+
+**关键点**：这一阶段的核心问题是**硬件扩展与部署效率**。
+
+<CgiQueueDemo />
+
+---
+
+## 2. 简单粗暴：单体架构 (Monolith)
+
+随着框架的出现（Rails / Django / Spring），大家把所有功能都塞进一个应用里：
+登录、下单、支付、商品管理……都在一个进程里完成。

-在 2010 年以前，绝大多数应用都是**单体**的。
 就像一个小餐馆，洗菜、切菜、炒菜都在一个大厨房里完成。

-*   **优点**：开发简单，部署方便（把一个大包扔到服务器上就行）。
-*   **缺点**：牵一发而动全身。
+- **优点**：开发简单，部署方便（把一个大包扔到服务器上就行）。
+- **缺点**：牵一发而动全身。
+
+### 2.1 "雪崩"效应

-### 1.1 "雪崩"效应
 想象一下，如果"切菜"的师傅不小心切到了手（代码出了 Bug），整个后厨都要停下来处理伤口，导致所有客人都吃不上饭。

 这就是单体架构最大的风险：**隔离性差**。

-### 1.2 交互演示：单体 vs 微服务
+<MonolithReleaseRiskDemo />
+
+### 2.2 交互演示：单体 vs 微服务
+
 下方的演示展示了两种架构在面对故障时的不同表现。
-*   点击 **"Simulate Crash"** 按钮，模拟订单模块 (Order Service) 崩溃。
-*   **左边 (单体)**：订单模块崩溃导致内存溢出，**整个系统**（包括用户、支付）全部瘫痪。
-*   **右边 (微服务)**：订单模块挂了，但用户还能登录，还能查看历史账单。只有"下单"功能暂时不可用。
+
+- 点击 **"Simulate Crash"** 按钮，模拟订单模块 (Order Service) 崩溃。
+- **左边 (单体)**：订单模块崩溃导致内存溢出，**整个系统**（包括用户、支付）全部瘫痪。
+- **右边 (微服务)**：订单模块挂了，但用户还能登录，还能查看历史账单。只有"下单"功能暂时不可用。

 <MonolithVsMicroserviceDemo />

@@ -41,49 +65,173 @@

 ---

-## 2. 蚂蚁雄兵：微服务 (Microservices)
+## 3. 蚂蚁雄兵：微服务 (Microservices)

 为了解决单体的问题，我们把大厨房拆成了很多个小厨房（服务）。
-*   专门负责用户的服务
-*   专门负责订单的服务
-*   专门负责支付的服务

-### 2.1 容器化革命 (Docker)
+- 专门负责用户的服务
+- 专门负责订单的服务
+- 专门负责支付的服务
+
+### 3.1 容器化革命 (Docker)
+
 怎么管理这么多小厨房？
 Docker 就像是**集装箱**。它把每个小服务连同它的锅碗瓢盆（依赖库）一起打包。
 无论运到哪里（哪台服务器），打开集装箱就能直接开工，不用再重新安装环境。

+### 3.2 编排与治理：K8s / 服务网格
+
+当集装箱数量到达成百上千，就需要一个"港口调度系统"：
+
+- **Kubernetes (K8s)**：负责把容器安排到合适的机器上（调度、扩缩容、滚动更新）。
+- **Service Mesh**：负责服务之间的交通规则（熔断、限流、重试、可观测）。
+
+**关键点**：微服务不是"拆开就好"，真正的难点在于**治理和运维**。
+
+<MicroserviceLatencyDemo />
+
 ---

-## 3. 云端进化：无服务 (Serverless)
+## 4. 云端进化：无服务 (Serverless)

 微服务虽然好，但维护几十个小厨房还是很累。你需要担心：
-*   厨房够不够大？（服务器扩容）
-*   停电了怎么办？（高可用）

-### 3.1 什么是 Serverless？
+- 厨房够不够大？（服务器扩容）
+- 停电了怎么办？（高可用）
+- 容器太多怎么管？（运维成本）
+
+### 4.1 什么是 Serverless？
+
 Serverless 并不是"没有服务器"，而是**"你不需要管理服务器"**。

 就像你现在不想自己做饭，也不想开饭馆，而是直接叫**外卖**。
-*   你只需要写代码（下单）。
-*   云厂商（美团）负责准备机器、运行代码、自动扩容。
-*   **按次付费**：代码跑了 100 毫秒，就收 100 毫秒的钱。没人访问就不收钱。

-### 3.2 适用场景
+- 你只需要写代码（下单）。
+- 云厂商（美团）负责准备机器、运行代码、自动扩容。
+- **按次付费**：代码跑了 100 毫秒，就收 100 毫秒的钱。没人访问就不收钱。
+
+### 4.2 适用场景
+
 Serverless 特别适合：
-*   **潮汐流量**：比如外卖软件，中午流量大，半夜没人。Serverless 会自动在中午为你分配 1000 台机器，半夜缩减到 0 台。
-*   **事件驱动**：比如"用户上传图片后，自动压缩图片"。
+
+- **潮汐流量**：比如外卖软件，中午流量大，半夜没人。Serverless 会自动在中午为你分配 1000 台机器，半夜缩减到 0 台。
+- **事件驱动**：比如"用户上传图片后，自动压缩图片"。
+- **快速验证**：小团队、MVP、黑客松项目。
+
+<ServerlessCostAutoScaleDemo />
+
+### 4.3 BaaS 组合拳
+
+Serverless 的真正力量来自于 **BaaS (Backend as a Service)**：
+
+- 登录 -> Auth0 / Supabase Auth
+- 支付 -> Stripe
+- 数据库 -> Supabase / Firebase / DynamoDB
+- 消息 -> Kafka / SQS
+
+**关键点**：Serverless 让后端越来越像"搭积木"。

 ---

-## 4. 总结
+## 5. 必备基础设施：后端"内功"
+
+无论架构怎么变，一些基础能力始终存在。
+
+### 5.1 负载均衡 (Load Balancer)
+
+像"大堂经理"一样，把客人平均分配给不同窗口，避免某个窗口排队爆炸。
+
+### 5.2 缓存 (Cache)
+
+像"备菜"一样，把常用的热菜放在餐台边上（Redis / CDN），省得每次都从厨房重做。
+
+<CacheHitRatioDemo />
+
+### 5.3 消息队列 (MQ)
+
+像"取号机"一样，把高峰期的订单排队处理，避免系统被瞬间击穿（Kafka / RabbitMQ）。
+
+### 5.4 数据库分工
+
+- **关系型 (MySQL / Postgres)**：订单、支付、用户信息。
+- **NoSQL (Redis / MongoDB)**：缓存、日志、推荐特征。
+
+**关键点**：这些"内功"决定了系统的**性能、稳定性、成本**。
+
+---
+
+## 6. 现代开发方式：DevOps / CI/CD / 可观测
+
+后端架构的进化，不只是技术栈变化，还包括开发流程变化。
+
+### 6.1 DevOps：开发与运维合体
+
+开发不再只是写代码，还要关心部署、监控、告警。
+
+### 6.2 CI/CD：自动化流水线
+
+- 代码提交 -> 自动测试
+- 测试通过 -> 自动部署
+- 出问题 -> 自动回滚
+
+### 6.3 可观测性 (Observability)
+
+现代后端需要三件套：
+
+- **日志 (Logs)**：发生了什么？
+- **指标 (Metrics)**：系统状态如何？
+- **链路追踪 (Tracing)**：一次请求在系统内走过了哪些服务？
+
+---
+
+## 7. 进阶趋势：边缘计算与平台工程
+
+### 7.1 Edge / 边缘计算
+
+把计算放在离用户更近的地方（边缘节点），实现更低延迟。
+
+### 7.2 平台工程 (Platform Engineering)
+
+大厂会搭建内部平台：
+
+- 给业务团队提供一键部署、一键监控。
+- 把复杂性"下沉"到平台，让业务更专注。
+
+---
+
+## 8. 总结与学习路线

 后端架构的演进，本质上是在做**加法**和**减法**：

-| 时代 | 架构 | 开发者要做的事 | 运维要做的事 |
-| :--- | :--- | :--- | :--- |
-| **单体时代** | 一整块 | 写所有业务逻辑 | 维护一台大服务器 |
-| **微服务时代** | 拆分 | 关注单一业务 | 维护 K8s 集群 (很累!) |
-| **Serverless** | 函数 | 只写核心函数 | 喝茶 (云厂商全包了) |
+| 时代           | 架构   | 开发者要做的事   | 运维要做的事          |
+| :------------- | :----- | :--------------- | :-------------------- |
+| **物理时代**   | 单机   | 写脚本、手动部署 | 维护机房与硬件        |
+| **单体时代**   | 一整块 | 写所有业务逻辑   | 维护几台大服务器      |
+| **微服务时代** | 拆分   | 关注单一业务     | 维护 K8s 集群 (很累!) |
+| **Serverless** | 函数   | 只写核心函数     | 喝茶 (云厂商全包了)   |
+
+**下一步建议**：
+
+- 想打基础：学会 HTTP、数据库、缓存、消息队列。
+- 想上手实践：用 Docker 跑一个小项目，再部署到云端。
+- 想更专业：了解 K8s、监控体系、CI/CD 流水线。

 未来的后端开发，将越来越像"搭积木"——你只需要关注**业务逻辑**，底层的脏活累活，全部交给云。
+
+---
+
+## 9. 名词速查表 (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** | -                                 | 可观测性，利用日志/指标/追踪理解系统运行状态。       |