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