sanbuphy
238 lines
9.2 KiB
Markdown
238 lines
9.2 KiB
Markdown
# 后端进化史：从 "单体" 到 "无服务" (Interactive Intro)
|
||
|
||
> 💡 **学习指南**：本章节无需编程基础，通过交互式演示带你回顾后端架构的 30 年变迁。我们将从最早的物理服务器讲起，一直到现代的 Serverless 云计算。
|
||
|
||
<BackendEvolutionDemo />
|
||
|
||
## 0. 引言：看不见的"大后方"
|
||
|
||
你点的外卖、刷的视频、发的微信，背后都有一个庞大的系统在支撑。
|
||
这个系统就是**后端 (Backend)**。
|
||
|
||
如果前端是"餐厅的服务员"，那后端就是"后厨"。
|
||
为了服务越来越多的客人（用户），后厨经历了一次次痛苦的扩建和重组。
|
||
|
||
核心变化只有一点：**如何以最低的成本，支撑最大规模的用户？**
|
||
|
||
---
|
||
|
||
## 1. 原始时代：物理服务器 & CGI (1990s)
|
||
|
||
在互联网刚起步时，后端就是一台放在机房里的**物理服务器**。
|
||
你把 `index.html`、`script.pl` 通过 FTP 传上去，用户访问时服务器逐个执行脚本。
|
||
|
||
### 1.1 痛点：慢、贵、难扩展
|
||
|
||
- **慢**：每次改代码都要手动上传。
|
||
- **贵**：扩容只能买更大的机器。
|
||
- **难扩展**：一台机器顶住所有请求，坏了就全站宕机。
|
||
|
||
**关键点**：这一阶段的核心问题是**硬件扩展与部署效率**。
|
||
|
||
<CgiQueueDemo />
|
||
|
||
---
|
||
|
||
## 2. 简单粗暴：单体架构 (Monolith)
|
||
|
||
随着框架的出现（Rails / Django / Spring），大家把所有功能都塞进一个应用里：
|
||
登录、下单、支付、商品管理……都在一个进程里完成。
|
||
|
||
就像一个小餐馆，洗菜、切菜、炒菜都在一个大厨房里完成。
|
||
|
||
- **优点**：开发简单，部署方便（把一个大包扔到服务器上就行）。
|
||
- **缺点**：牵一发而动全身。
|
||
|
||
### 2.1 "雪崩"效应
|
||
|
||
想象一下，如果"切菜"的师傅不小心切到了手（代码出了 Bug），整个后厨都要停下来处理伤口，导致所有客人都吃不上饭。
|
||
|
||
这就是单体架构最大的风险：**隔离性差**。
|
||
|
||
<MonolithReleaseRiskDemo />
|
||
|
||
### 2.2 交互演示：单体 vs 微服务
|
||
|
||
下方的演示展示了两种架构在面对故障时的不同表现。
|
||
|
||
- 点击 **"Simulate Crash"** 按钮，模拟订单模块 (Order Service) 崩溃。
|
||
- **左边 (单体)**：订单模块崩溃导致内存溢出，**整个系统**（包括用户、支付）全部瘫痪。
|
||
- **右边 (微服务)**：订单模块挂了，但用户还能登录，还能查看历史账单。只有"下单"功能暂时不可用。
|
||
|
||
<MonolithVsMicroserviceDemo />
|
||
|
||
**关键点**：微服务架构的核心价值，在于**故障隔离**和**独立扩展**。
|
||
|
||
---
|
||
|
||
## 3. 蚂蚁雄兵：微服务 (Microservices)
|
||
|
||
为了解决单体的问题，我们把大厨房拆成了很多个小厨房（服务）。
|
||
|
||
- 专门负责用户的服务
|
||
- 专门负责订单的服务
|
||
- 专门负责支付的服务
|
||
|
||
### 3.1 容器化革命 (Docker)
|
||
|
||
怎么管理这么多小厨房？
|
||
Docker 就像是**集装箱**。它把每个小服务连同它的锅碗瓢盆（依赖库）一起打包。
|
||
无论运到哪里（哪台服务器），打开集装箱就能直接开工，不用再重新安装环境。
|
||
|
||
### 3.2 编排与治理：K8s / 服务网格
|
||
|
||
当集装箱数量到达成百上千，就需要一个"港口调度系统"：
|
||
|
||
- **Kubernetes (K8s)**：负责把容器安排到合适的机器上（调度、扩缩容、滚动更新）。
|
||
- **Service Mesh**：负责服务之间的交通规则（熔断、限流、重试、可观测）。
|
||
|
||
**关键点**：微服务不是"拆开就好"，真正的难点在于**治理和运维**。
|
||
|
||
<MicroserviceLatencyDemo />
|
||
|
||
---
|
||
|
||
## 4. 云端进化：无服务 (Serverless)
|
||
|
||
微服务虽然好，但维护几十个小厨房还是很累。你需要担心：
|
||
|
||
- 厨房够不够大？（服务器扩容）
|
||
- 停电了怎么办？（高可用）
|
||
- 容器太多怎么管？（运维成本）
|
||
|
||
### 4.1 什么是 Serverless？
|
||
|
||
Serverless 并不是"没有服务器"，而是**"你不需要管理服务器"**。
|
||
|
||
就像你现在不想自己做饭，也不想开饭馆，而是直接叫**外卖**。
|
||
|
||
- 你只需要写代码（下单）。
|
||
- 云厂商（美团）负责准备机器、运行代码、自动扩容。
|
||
- **按次付费**：代码跑了 100 毫秒，就收 100 毫秒的钱。没人访问就不收钱。
|
||
|
||
### 4.2 适用场景
|
||
|
||
Serverless 特别适合：
|
||
|
||
- **潮汐流量**：比如外卖软件，中午流量大，半夜没人。Serverless 会自动在中午为你分配 1000 台机器，半夜缩减到 0 台。
|
||
- **事件驱动**：比如"用户上传图片后，自动压缩图片"。
|
||
- **快速验证**：小团队、MVP、黑客松项目。
|
||
|
||
<ServerlessCostAutoScaleDemo />
|
||
|
||
### 4.3 BaaS 组合拳
|
||
|
||
Serverless 的真正力量来自于 **BaaS (Backend as a Service)**：
|
||
|
||
- 登录 -> Auth0 / Supabase Auth
|
||
- 支付 -> Stripe
|
||
- 数据库 -> Supabase / Firebase / DynamoDB
|
||
- 消息 -> Kafka / SQS
|
||
|
||
**关键点**：Serverless 让后端越来越像"搭积木"。
|
||
|
||
---
|
||
|
||
## 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** | 函数 | 只写核心函数 | 喝茶 (云厂商全包了) |
|
||
|
||
**下一步建议**：
|
||
|
||
- 想打基础：学会 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** | - | 可观测性，利用日志/指标/追踪理解系统运行状态。 |
|