90 lines
3.8 KiB
Markdown
90 lines
3.8 KiB
Markdown
|
# 后端进化史：从 "单体" 到 "无服务" (Interactive Intro)
|
|||
|
|
|
|||
|
|
> 💡 **学习指南**：本章节无需编程基础，通过交互式演示带你回顾后端架构的 30 年变迁。我们将从最早的物理服务器讲起，一直到现代的 Serverless 云计算。
|
|||
|
|
|
|||
|
|
<BackendEvolutionDemo />
|
|||
|
|
|
|||
|
|
## 0. 引言：看不见的"大后方"
|
|||
|
|
|
|||
|
|
你点的外卖、刷的视频、发的微信，背后都有一个庞大的系统在支撑。
|
|||
|
|
这个系统就是**后端 (Backend)**。
|
|||
|
|
|
|||
|
|
如果前端是"餐厅的服务员"，那后端就是"后厨"。
|
|||
|
|
为了服务越来越多的客人（用户），后厨经历了一次次痛苦的扩建和重组。
|
|||
|
|
|
|||
|
|
核心变化只有一点：**如何以最低的成本，支撑最大规模的用户？**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. 简单粗暴：单体架构 (Monolith)
|
|||
|
|
|
|||
|
|
在 2010 年以前，绝大多数应用都是**单体**的。
|
|||
|
|
就像一个小餐馆，洗菜、切菜、炒菜都在一个大厨房里完成。
|
|||
|
|
|
|||
|
|
* **优点**：开发简单，部署方便（把一个大包扔到服务器上就行）。
|
|||
|
|
* **缺点**：牵一发而动全身。
|
|||
|
|
|
|||
|
|
### 1.1 "雪崩"效应
|
|||
|
|
想象一下，如果"切菜"的师傅不小心切到了手（代码出了 Bug），整个后厨都要停下来处理伤口，导致所有客人都吃不上饭。
|
|||
|
|
|
|||
|
|
这就是单体架构最大的风险：**隔离性差**。
|
|||
|
|
|
|||
|
|
### 1.2 交互演示：单体 vs 微服务
|
|||
|
|
下方的演示展示了两种架构在面对故障时的不同表现。
|
|||
|
|
* 点击 **"Simulate Crash"** 按钮，模拟订单模块 (Order Service) 崩溃。
|
|||
|
|
* **左边 (单体)**：订单模块崩溃导致内存溢出，**整个系统**（包括用户、支付）全部瘫痪。
|
|||
|
|
* **右边 (微服务)**：订单模块挂了，但用户还能登录，还能查看历史账单。只有"下单"功能暂时不可用。
|
|||
|
|
|
|||
|
|
<MonolithVsMicroserviceDemo />
|
|||
|
|
|
|||
|
|
**关键点**：微服务架构的核心价值，在于**故障隔离**和**独立扩展**。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. 蚂蚁雄兵：微服务 (Microservices)
|
|||
|
|
|
|||
|
|
为了解决单体的问题，我们把大厨房拆成了很多个小厨房（服务）。
|
|||
|
|
* 专门负责用户的服务
|
|||
|
|
* 专门负责订单的服务
|
|||
|
|
* 专门负责支付的服务
|
|||
|
|
|
|||
|
|
### 2.1 容器化革命 (Docker)
|
|||
|
|
怎么管理这么多小厨房？
|
|||
|
|
Docker 就像是**集装箱**。它把每个小服务连同它的锅碗瓢盆（依赖库）一起打包。
|
|||
|
|
无论运到哪里（哪台服务器），打开集装箱就能直接开工，不用再重新安装环境。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. 云端进化：无服务 (Serverless)
|
|||
|
|
|
|||
|
|
微服务虽然好，但维护几十个小厨房还是很累。你需要担心：
|
|||
|
|
* 厨房够不够大？（服务器扩容）
|
|||
|
|
* 停电了怎么办？（高可用）
|
|||
|
|
|
|||
|
|
### 3.1 什么是 Serverless？
|
|||
|
|
Serverless 并不是"没有服务器"，而是**"你不需要管理服务器"**。
|
|||
|
|
|
|||
|
|
就像你现在不想自己做饭，也不想开饭馆，而是直接叫**外卖**。
|
|||
|
|
* 你只需要写代码（下单）。
|
|||
|
|
* 云厂商（美团）负责准备机器、运行代码、自动扩容。
|
|||
|
|
* **按次付费**：代码跑了 100 毫秒，就收 100 毫秒的钱。没人访问就不收钱。
|
|||
|
|
|
|||
|
|
### 3.2 适用场景
|
|||
|
|
Serverless 特别适合：
|
|||
|
|
* **潮汐流量**：比如外卖软件，中午流量大，半夜没人。Serverless 会自动在中午为你分配 1000 台机器，半夜缩减到 0 台。
|
|||
|
|
* **事件驱动**：比如"用户上传图片后，自动压缩图片"。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. 总结
|
|||
|
|
|
|||
|
|
后端架构的演进，本质上是在做**加法**和**减法**：
|
|||
|
|
|
|||
|
|
| 时代 | 架构 | 开发者要做的事 | 运维要做的事 |
|
|||
|
|
| :--- | :--- | :--- | :--- |
|
|||
|
|
| **单体时代** | 一整块 | 写所有业务逻辑 | 维护一台大服务器 |
|
|||
|
|
| **微服务时代** | 拆分 | 关注单一业务 | 维护 K8s 集群 (很累!) |
|
|||
|
|
| **Serverless** | 函数 | 只写核心函数 | 喝茶 (云厂商全包了) |
|
|||
|
|
|
|||
|
|
未来的后端开发，将越来越像"搭积木"——你只需要关注**业务逻辑**，底层的脏活累活，全部交给云。
|