后端架构演进：从单机到云原生

💡 学习指南：本章节无需编程基础，通过交互式演示带你回顾后端架构的 30 年变迁。我们将从最原始的物理服务器讲起，一直到现代的 Serverless 云计算。理解架构演进的历史，能帮助你在面对技术选型时做出更明智的决策。

后端架构进化之旅

用一个餐厅的成长历程，理解后端架构的 30 年变迁

1990s

🏠

家庭小作坊

物理服务器

2000s

🏢

大型中央厨房

单体架构

2010s

🏭

专业化分工

微服务架构

2020s+

🍽️

外卖平台

Serverless

🏠

家庭小厨房

🍽️ 餐厅场景

一位厨师在一间小厨房里，亲自去菜市场买菜、洗菜、切菜、炒菜、上菜。客人多了就忙不过来，只能让客人排队等。

💻 后端映射

一台物理服务器，处理所有请求：接收HTTP请求、读取文件、执行CGI脚本、返回响应。CPU和内存有限，请求多了只能排队。

⚡ 核心痛点

单机性能瓶颈：客人太多时，厨师根本忙不过来
垂直扩展成本高：买更贵的机器就像换更大的厨房，治标不治本
单点故障：厨师生病了，整个餐馆必须关门

0. 引言：为什么要了解架构演进？

想象一下，你正在规划一次长途旅行。你可以选择骑自行车、开私家车、坐高铁，或者乘飞机。每种方式都有其适用的场景：自行车适合短距离且想锻炼身体的情况，飞机则适合跨越大陆的长途旅行。

后端架构的选择也是如此。

从互联网诞生到现在，后端架构经历了多次重大变革。每一次变革都不是为了"追新潮"，而是为了解决当时面临的特定问题：

年代	核心问题	架构演进
1990s	如何把网站跑起来	物理服务器
2000s	代码越来越乱怎么维护	单体架构 + MVC
2010s	系统太大怎么扩展和协作	微服务 + 容器化
2020s	如何降低运维成本和复杂性	Serverless + 云原生

了解架构演进的意义在于：

避免重复造轮子：很多"新"概念其实早在几十年前就有雏形，了解历史能让你站在巨人的肩膀上
做出合理的技术选型：没有最好的架构，只有最适合当前阶段的架构
理解技术背后的权衡：每一次架构演进都是在开发效率、系统性能、运维复杂度之间做取舍
预判技术趋势：历史总是押韵的，理解过去的演进规律有助于把握未来方向

🏗️ 架构演进对比

四个时代的核心架构特征对比

🖥️

物理机

1990s

单机

🏢

单体

2000s

集中

🏭

微服务

2010s

分布

☁️

Serverless

2020s+

无服

🏢

单体 (2000s)

🏗️ 架构特征

单一代码库，统一技术栈
共享数据库，事务一致性
统一部署，整体发布
进程内通信，无网络开销

✅ 优点

开发简单，易于上手
测试方便，本地启动即可
部署简单，一个包搞定

❌ 痛点

代码耦合，牵一发而动全身
技术栈单一，难以引入新技术
团队扩张后协作困难

🔧 典型技术

Spring/Django/RailsTomcat/GunicornMySQL/PostgreSQLMaven/Gradle

1. 物理服务器时代 (1990s)

在互联网刚起步时，后端就是一台放在机房里的物理服务器（一台真实的电脑）。

🖥️ 物理服务器时代演示

点击"发送请求"，观察早期 CGI 服务器的处理瓶颈

👤 用户浏览器

🖥️ CGI 服务器

等待请求

💡 早期的痛点在哪里？

进程启动开销：每个请求都要启动新的 CGI 进程，就像每来一个客人都要重新搭一个厨房
资源无法复用：数据库连接每次都要重新建立，CPU 频繁在进程间切换
扩展困难：只能买更强的单机（垂直扩展），无法通过增加机器分担压力

这就是物理服务器 + CGI时代的核心问题：进程级隔离带来了稳定性，但也带来了巨大的性能开销。

1.1 核心特点

单机部署：所有应用运行在一台物理机上
手动运维：需要人工上架、布线、安装系统
垂直扩展：性能不够时只能买更强的机器

1.2 痛点

慢：每次改代码都要手动上传，然后重启服务器
贵：扩容只能买更大的机器（垂直扩展）
难扩展：一台机器顶住所有请求，CPU 满载时就只能排队

1.3 扩展策略

📈 扩展策略对比

垂直扩展 vs 水平扩展

📦

垂直扩展

买更强的机器

CPU

内存

🔄

水平扩展

加更多机器

成本硬件贵机器多

上限有瓶颈理论上无限

复杂度简单需要分布式

数据一致性好需要同步

1.4 物理服务器时代的优缺点

维度	评价
优点	完全掌控硬件，性能可预测；没有虚拟化开销；数据物理隔离，安全性高
缺点	采购周期长（数周）；前期投入大（CapEx）；资源利用率低；扩容困难
适用场景	金融核心系统、政府涉密系统、对数据主权有严格要求的场景

2. 单体架构时代 (2000s)

随着框架的出现（Rails / Django / Spring），大家把所有功能都塞进一个应用里。

🏢 单体架构演示

观察单体应用如何处理请求，以及模块间的依赖关系

单体应用进程

👤

用户模块

健康

📦

订单模块

健康

💳

支付模块

健康

🏭

库存模块

健康

🗄️

共享数据库

💡 单体架构的特点

共享进程空间：所有模块在同一个进程中运行，内存共享
数据库耦合：所有模块共享同一个数据库，Schema变更影响全局
级联故障：一个模块崩溃可能导致整个进程挂掉（雪崩效应）

2.1 核心特点

单一代码库：所有功能模块在同一个项目中
共享数据库：所有模块共用同一个数据库
统一部署：整个应用作为一个整体打包部署

2.2 优点

开发简单：一个项目搞定所有功能
部署方便：把一个大包扔到服务器上就行
调试容易：本地启动就能调试所有功能

2.3 痛点：雪崩效应

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

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

2.4 单体架构的优缺点与适用场景

维度	评价
优点	开发简单，无需考虑分布式复杂性；调试方便，本地启动即可调试全功能；部署简单，一个包即可运行；事务管理容易，单机数据库即可保证 ACID
缺点	代码耦合度高，随着业务增长代码膨胀；技术栈单一，难以局部升级；扩展困难，只能整体扩容；故障隔离差，一个模块故障影响全局；团队协作效率低，多人改同一套代码
适用场景	初创公司 MVP 验证、小型团队（<10人）、业务相对简单、对交付速度要求高于扩展性的场景
不适用场景	大型团队并行开发、需要频繁发布不同模块、某些模块需要独立扩容的场景

2.5 部署流程演进

🚀 部署方式演进

从手工部署到自动化流水线的变化

👤

1990s

手工部署

📦

2000s

脚本部署

🔄

2010s

CI/CD 流水线

🚀

2020s+

GitOps

脚本部署

部署方式:自动化脚本

耗时:10-30分钟

风险:脚本维护成本

代表工具:ShellAnsiblePuppet

2.6 单体架构的技术栈

在单体架构时代，开发者通常使用以下技术栈：

语言/框架	特点	代表企业
Java + Spring	企业级开发首选，生态完善	阿里巴巴、京东
PHP + Laravel/ThinkPHP	快速开发，适合中小型项目	早期 Facebook、微博
Python + Django/Flask	开发效率高，适合快速原型	Instagram、Pinterest
Ruby on Rails	约定优于配置，初创公司最爱	GitHub、Twitter（早期）
Node.js + Express	前后端统一语言，I/O 密集型场景	Netflix、Uber

3. 容器化与微服务 (2010s)

3.1 Docker 容器化

🐳 Docker 容器化演示

理解容器如何让应用"一次打包，到处运行"

传统部署

应用 A

依赖库 v1.0

操作系统

物理服务器

Docker 容器

应用 A

依赖 v1.0

应用 B

依赖 v2.0

Docker Engine

宿主机操作系统

物理服务器

📦

环境一致性

开发、测试、生产环境完全一致，告别"在我机器上能跑"

🚀

快速部署

秒级启动，镜像分发，滚动更新无停机

📊

资源隔离

CPU/内存限制，互不干扰，一台机器跑多个应用

🔄

版本管理

镜像版本化，随时回滚，灰度发布

Docker 就像是集装箱，它把每个小服务连同它的锅碗瓢盆（依赖库）一起打包。

无论运到哪里（哪台服务器），打开集装箱就能直接开工，不用再重新安装环境。

3.2 技术栈时间线

📚 技术栈演进时间线

每个时代的主流技术栈

🖥️物理机时代1990s

Web服务器

ApacheNginxIIS

后端语言

PerlPHPASP

数据库

MySQLPostgreSQLOracle

部署方式

FTPSSH手动

🏢单体架构2000s

后端框架

SpringDjangoRailsLaravel

前端技术

jQueryBootstrapJSP

数据库

MySQLRedisMongoDB

构建工具

MavenGradleAnt

🏭微服务2010s

容器化

DockerKubernetesHelm

服务框架

Spring CloudgRPCDubbo

数据存储

RedisMongoDBKafkaES

可观测

PrometheusGrafanaJaeger

☁️Serverless2020s+

函数计算

LambdaVercelCloudflare

BaaS

SupabaseFirebaseAuth0

前端框架

Next.jsNuxtSvelteKit

数据库

PlanetScaleNeonTurso

3.3 微服务架构

🏭 微服务架构演示

观察多个独立服务如何协作，以及服务间通信方式

👤用户服务健康

端口:8081

数据库:MySQL

依赖:无

📦订单服务健康

端口:8082

数据库:PostgreSQL

依赖:用户服务

💳支付服务健康

端口:8083

数据库:MongoDB

依赖:用户服务, 订单服务

🏭库存服务健康

端口:8084

数据库:Redis

依赖:订单服务

服务间通信链路

用户服务

验证用户身份

订单服务

创建订单记录

库存服务

检查库存数量

支付服务

处理支付请求

订单服务

更新订单状态

为了解决单体的问题，我们把大厨房拆成了很多个小厨房（服务）：

专门负责用户的服务
专门负责订单的服务
专门负责支付的服务

3.4 Kubernetes 编排

☸️ Kubernetes 编排演示

观察 K8s 如何自动调度容器、实现负载均衡和故障恢复

控制平面 (Control Plane)

🌐

API Server

集群的统一入口

🗄️

etcd

分布式键值存储

📋

Scheduler

Pod 调度器

🎮

Controller

控制器管理器

工作节点 (Worker Nodes)

🖥️Node-1运行中

CPU:

45%

内存:

60%

运行 Pod: 5 个

🖥️Node-2运行中

CPU:

30%

内存:

40%

运行 Pod: 3 个

🖥️Node-3准备中

CPU:

内存:

运行 Pod: 0 个

💡 Kubernetes 核心概念

Pod：最小的部署单元，一个 Pod 可以包含一个或多个容器
Deployment：管理 Pod 的副本数量和滚动更新
Service：提供稳定的网络访问入口，实现负载均衡
Scheduler：根据资源需求和策略，自动将 Pod 调度到合适的节点

当集装箱数量到达成百上千，就需要一个"港口调度系统"：

Kubernetes (K8s)：负责把容器安排到合适的机器上（调度、扩缩容、滚动更新）
Service Mesh：负责服务之间的交通规则（熔断、限流、重试、可观测）

关键点：微服务不是"拆开就好"，真正的难点在于治理和运维。

3.5 微服务与容器化的优缺点

维度	评价
优点	服务独立部署，技术栈可异构；故障隔离，单个服务崩溃不影响全局；按需扩展，热点服务单独扩容；团队协作友好，不同团队负责不同服务；代码库更小，易于理解和维护
缺点	分布式复杂性高（网络延迟、分布式事务、服务发现）；运维成本高，需要专业的 DevOps 团队；调试困难，问题可能需要跨多个服务追踪；数据一致性难以保证；部署和监控基础设施要求复杂
适用场景	大型团队（>50人）、业务复杂需要分模块独立演进、某些模块需要独立扩容、需要多语言技术栈、对可用性要求高的系统
不适用场景	小型团队、业务简单、流量小且稳定、没有专业运维团队的情况

3.6 微服务技术栈

类别	技术/工具	作用
容器化	Docker, containerd	应用打包与隔离
编排调度	Kubernetes, Docker Swarm	容器管理与自动扩缩容
服务发现	Consul, etcd, ZooKeeper	服务注册与发现
API 网关	Kong, Zuul, Envoy	统一入口、路由、限流
配置中心	Apollo, Nacos, Spring Cloud Config	集中配置管理
监控告警	Prometheus, Grafana, ELK	指标监控与日志分析
链路追踪	Jaeger, Zipkin, SkyWalking	分布式请求追踪
服务网格	Istio, Linkerd	流量治理与安全

4. Serverless 与云原生时代 (2020s+)

微服务虽然好，但维护几十个小厨房还是很累。你需要担心：

厨房够不够大？（服务器扩容）
停电了怎么办？（高可用）
容器太多怎么管？（运维成本）

⚡ Serverless 架构演示

观察 Serverless 如何按需执行函数、自动扩缩容

🔐

用户登录

冷状态

📦

订单处理

冷状态

🖼️

图片处理

冷状态

💾

数据备份

冷状态

自动扩缩容状态

并发请求:0

运行实例:0

冷启动:0

流量模拟器

💡 Serverless 核心特性

按需执行：函数只在被调用时运行，不调用不产生费用
自动扩缩容：从 0 到数千实例自动扩展，无需人工干预
冷启动：长时间未调用后首次调用会有延迟，需要预热策略
事件驱动：响应 HTTP 请求、消息队列、定时任务等多种事件源

4.1 什么是 Serverless？

Serverless 并不是"没有服务器"，而是"你不需要管理服务器"。

就像你现在不想自己做饭，也不想开饭馆，而是直接叫外卖。

你只需要写代码（下单）
云厂商（美团）负责准备机器、运行代码、自动扩容
按次付费：代码跑了 100 毫秒，就收 100 毫秒的钱。没人访问就不收钱

4.2 适用场景

Serverless 特别适合：

潮汐流量：比如外卖软件，中午流量大，半夜没人。Serverless 会自动在中午为你分配 1000 台机器，半夜缩减到 0 台
事件驱动：比如"用户上传图片后，自动压缩图片"
快速验证：小团队、MVP、黑客松项目

4.3 BaaS 组合拳

Serverless 的真正力量来自于 BaaS (Backend as a Service)：

登录 -> Auth0 / Supabase Auth
支付 -> Stripe
数据库 -> Supabase / Firebase / DynamoDB
消息 -> Kafka / SQS

关键点：Serverless 让后端越来越像"搭积木"。

4.4 Serverless 与云原生的优缺点

维度	评价
优点	零运维成本，开发者只需关注业务代码；自动扩缩容，完美应对流量峰值；按需付费，无流量时成本接近零；快速上线，几分钟即可部署全球；高可用内置，云服务自动处理故障转移
缺点	冷启动延迟（几百毫秒到数秒）；运行时长限制（通常5-15分钟）；调试困难，本地难以完全模拟云环境；供应商锁定风险；不适合长时间运行或计算密集型任务；成本在高频持续流量下可能反超传统方案
适用场景	事件驱动处理（图片处理、消息通知）；潮汐流量应用（活动页、促销）；快速原型验证和MVP；低频API或后台任务；无专职运维团队的小团队
不适用场景	需要持续低延迟的应用；长时间计算任务；对冷启动敏感的场景（高频交易）；需要精细控制底层基础设施的场景

4.5 Serverless 技术栈与平台

类别	技术/平台	特点
FaaS 平台	AWS Lambda	最早的 FaaS 服务，生态最成熟
	Azure Functions	微软云集成度高，.NET 友好
	Google Cloud Functions	与 GCP 服务深度集成
	阿里云函数计算	国内生态完善，冷启动优化好
	腾讯云云函数	与微信生态整合
	Vercel/Netlify Functions	前端开发者友好，边缘部署
BaaS 服务	Firebase	Google 的移动端后端方案
	Supabase	PostgreSQL 的 Firebase 开源替代
	AWS Amplify	AWS 的移动和 Web 应用开发平台
部署工具	Serverless Framework	多云部署，社区活跃
	Terraform	基础设施即代码
	Pulumi	用编程语言定义基础设施

5. 各架构阶段对比与选型指南

5.1 架构演进全景对比

维度	物理服务器	单体架构	微服务+容器	Serverless
团队规模	1-5人	5-50人	50-500人	1-20人
部署复杂度	极高	低	极高	极低
运维成本	高	中	很高	低
扩展性	差	垂直扩展有限	水平扩展优秀	自动扩展
技术栈灵活性	无	单一	多样化	受限
冷启动	无	无	容器启动时间	有延迟
适用场景	遗留系统、特殊合规要求	初创公司、业务简单	大型互联网公司、复杂业务	快速验证、事件驱动

5.2 技术选型决策树

开始选型
    │
    ├─ 团队有专业运维人员？
    │   ├─ 是 → 考虑微服务或物理机
    │   └─ 否 → 继续判断
    │
    ├─ 需要快速上线验证想法？
    │   ├─ 是 → Serverless 或单体
    │   └─ 否 → 继续判断
    │
    ├─ 团队规模 > 50人？
    │   ├─ 是 → 考虑微服务
    │   └─ 否 → 继续判断
    │
    ├─ 流量有明显峰谷特征？
    │   ├─ 是 → Serverless
    │   └─ 否 → 单体架构（推荐初创）
    │
    └─ 特殊要求（合规、遗留系统）？
        └─ 是 → 物理服务器

5.3 不同场景下的推荐架构

场景一：独立开发者/兼职项目

推荐架构：Serverless (Vercel/Netlify) 或单体应用
理由：几乎零运维成本，按需付费，快速上线
示例技术栈：Next.js + Vercel + Supabase

场景二：初创公司 MVP 验证

推荐架构：单体架构 + 云服务器
理由：开发速度快，团队可以专注于业务逻辑而非基础设施
示例技术栈：Spring Boot / Django / Rails + RDS + ECS

场景三：成长型公司（10-50人团队）

推荐架构：模块化单体或轻量级微服务
理由：开始面临代码耦合问题，但还不需要完整的微服务复杂度
示例技术栈：Spring Cloud / Go Micro + Kubernetes

场景四：大型互联网公司

推荐架构：微服务 + 服务网格 + 中台架构
理由：团队规模大，业务复杂，需要独立的发布节奏和技术栈
示例技术栈：自研 RPC 框架 + Istio + 自建 PaaS 平台

场景五：事件驱动/潮汐流量应用

推荐架构：Serverless + 事件总线
理由：流量波动大，需要极致的成本优化和自动扩缩容
示例技术栈：AWS Lambda + API Gateway + EventBridge

6. 总结与学习路线

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

时代	架构	开发者要做的事	运维要做的事
物理时代	单机	写脚本、手动部署	维护机房与硬件
单体时代	一整块	写所有业务逻辑	维护几台大服务器
微服务时代	拆分	关注单一业务	维护 K8s 集群 (很累!)
Serverless	函数	只写核心函数	喝茶 (云厂商全包了)

下一步建议：

想打基础：学会 HTTP、数据库、缓存、消息队列
想上手实践：用 Docker 跑一个小项目，再部署到云端
想更专业：了解 K8s、监控体系、CI/CD 流水线

未来的后端开发，将越来越像"搭积木"——你只需要关注业务逻辑，底层的脏活累活，全部交给云。

6.2 学习路线建议

根据你的职业阶段，推荐以下学习路径：

阶段一：打好基础（0-1年）

目标：理解后端核心概念，能独立开发单体应用

掌握一门后端语言（Java/Python/Go 任选其一）
学习 HTTP 协议和 RESTful API 设计
掌握关系型数据库（MySQL/PostgreSQL）
了解缓存基础（Redis）
学习 Git 和基础 Linux 命令
实践项目：用单体架构完成一个 CRUD 应用（如博客系统、待办事项）

阶段二：扩展能力（1-3年）

目标：理解分布式系统，能参与微服务开发

深入学习微服务架构和拆分策略
掌握 Docker 和 Kubernetes 基础
学习消息队列（Kafka/RabbitMQ）
了解分布式事务和一致性
掌握监控和日志（Prometheus/ELK）
实践项目：将单体应用拆分为 3-5 个微服务，使用 Docker 部署

阶段三：专业深化（3-5年）

目标：能设计大型系统，具备技术选型能力

深入理解云原生架构（Service Mesh、Serverless）
掌握容量规划和性能调优
了解多活架构和灾备设计
学习 DDD（领域驱动设计）
培养技术判断力和架构思维
实践项目：设计一个支持百万级用户的系统架构，包含高可用、弹性伸缩等方案

持续学习资源推荐

书籍

《设计数据密集型应用》（DDIA）- 分布式系统必读
《云原生模式》
《微服务设计》
《领域驱动设计》

在线资源

AWS/Azure/阿里云官方架构文档
CNCF（云原生计算基金会）项目文档
各大公司技术博客（Netflix Tech Blog、阿里技术公众号等）

6.3 架构选型的核心原则

记住以下原则，帮助你在实际工作中做出正确的选择：

没有银弹：不存在最好的架构，只有最适合当前场景的架构
演进优于完美：先让系统跑起来，再逐步优化，不要过度设计
团队能力优先：选择团队熟悉和能驾驭的技术，而不是最新最酷的技术
成本意识：计算总体拥有成本（TCO），包括开发、运维、培训等
可回退性：设计时考虑回退方案，微服务可以合并回单体，但很难拆分

7. 名词速查表 (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	-	可观测性，利用日志/指标/追踪理解系统运行状态

后端架构演进：从单机到云原生 ​

后端架构进化之旅

家庭小厨房

🍽️ 餐厅场景

💻 后端映射

⚡ 核心痛点

0. 引言：为什么要了解架构演进？ ​

🏗️ 架构演进对比

单体 (2000s)

🏗️ 架构特征

✅ 优点

❌ 痛点

🔧 典型技术

1. 物理服务器时代 (1990s) ​

🖥️ 物理服务器时代演示

💡 早期的痛点在哪里？

1.1 核心特点 ​

1.2 痛点 ​

1.3 扩展策略 ​

📈 扩展策略对比

1.4 物理服务器时代的优缺点 ​

2. 单体架构时代 (2000s) ​

🏢 单体架构演示

💡 单体架构的特点

2.1 核心特点 ​

2.2 优点 ​

2.3 痛点：雪崩效应 ​

2.4 单体架构的优缺点与适用场景 ​

2.5 部署流程演进 ​

🚀 部署方式演进

脚本部署

2.6 单体架构的技术栈 ​

3. 容器化与微服务 (2010s) ​

3.1 Docker 容器化 ​

🐳 Docker 容器化演示

传统部署

Docker 容器

3.2 技术栈时间线 ​

📚 技术栈演进时间线

3.3 微服务架构 ​

🏭 微服务架构演示

服务间通信链路

3.4 Kubernetes 编排 ​

☸️ Kubernetes 编排演示

💡 Kubernetes 核心概念

3.5 微服务与容器化的优缺点 ​

3.6 微服务技术栈 ​

4. Serverless 与云原生时代 (2020s+) ​

⚡ Serverless 架构演示

💡 Serverless 核心特性

4.1 什么是 Serverless？ ​

4.2 适用场景 ​

4.3 BaaS 组合拳 ​

4.4 Serverless 与云原生的优缺点 ​

4.5 Serverless 技术栈与平台 ​

5. 各架构阶段对比与选型指南 ​

5.1 架构演进全景对比 ​

5.2 技术选型决策树 ​

5.3 不同场景下的推荐架构 ​

场景一：独立开发者/兼职项目 ​

场景二：初创公司 MVP 验证 ​

场景三：成长型公司（10-50人团队） ​

场景四：大型互联网公司 ​

场景五：事件驱动/潮汐流量应用 ​

6. 总结与学习路线 ​

6.2 学习路线建议 ​

阶段一：打好基础（0-1年） ​

阶段二：扩展能力（1-3年） ​

阶段三：专业深化（3-5年） ​

持续学习资源推荐 ​

6.3 架构选型的核心原则 ​

7. 名词速查表 (Glossary) ​

后端架构演进：从单机到云原生

0. 引言：为什么要了解架构演进？

1. 物理服务器时代 (1990s)

1.1 核心特点

1.2 痛点

1.3 扩展策略

1.4 物理服务器时代的优缺点

2. 单体架构时代 (2000s)

2.1 核心特点

2.2 优点

2.3 痛点：雪崩效应

2.4 单体架构的优缺点与适用场景

2.5 部署流程演进

2.6 单体架构的技术栈

3. 容器化与微服务 (2010s)

3.1 Docker 容器化

3.2 技术栈时间线

3.3 微服务架构

3.4 Kubernetes 编排

3.5 微服务与容器化的优缺点

3.6 微服务技术栈

4. Serverless 与云原生时代 (2020s+)

4.1 什么是 Serverless？

4.2 适用场景

4.3 BaaS 组合拳

4.4 Serverless 与云原生的优缺点

4.5 Serverless 技术栈与平台

5. 各架构阶段对比与选型指南

5.1 架构演进全景对比

5.2 技术选型决策树

5.3 不同场景下的推荐架构

场景一：独立开发者/兼职项目

场景二：初创公司 MVP 验证

场景三：成长型公司（10-50人团队）

场景四：大型互联网公司

场景五：事件驱动/潮汐流量应用

6. 总结与学习路线

6.2 学习路线建议

阶段一：打好基础（0-1年）

阶段二：扩展能力（1-3年）

阶段三：专业深化（3-5年）

持续学习资源推荐

6.3 架构选型的核心原则

7. 名词速查表 (Glossary)