Files
test-repo/docs/zh-cn/appendix/backend-evolution.md
T

90 lines
3.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 后端进化史:从 "单体" 到 "无服务" (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** | 函数 | 只写核心函数 | 喝茶 (云厂商全包了) |
未来的后端开发,将越来越像"搭积木"——你只需要关注**业务逻辑**,底层的脏活累活,全部交给云。