On this page
article
Web 框架的本质
🎯 核心问题
代码写好了,怎么让全世界的人都能访问? 这就像问:你是想开一家路边小摊,还是经营一家跨国连锁餐厅?后端架构的选择,决定了你的"餐厅"能服务多少顾客。
1. 为什么要了解架构演进?
想象一下,你正在规划一次长途旅行。你可以选择骑自行车、开私家车、坐高铁,或者乘飞机。每种方式都有其适用的场景:自行车适合短距离且想锻炼身体的情况,飞机则适合跨越大陆的长途旅行。
后端架构的选择也是如此。
从互联网诞生到现在,后端架构经历了多次重大变革。每一次变革都不是为了"追新潮",而是为了解决当时面临的特定问题:
| 年代 | 核心问题 | 架构演进 |
|---|---|---|
| 1990s | 如何把网站跑起来 | 物理服务器 |
| 2000s | 代码越来越乱怎么维护 | 单体架构 + MVC |
| 2010s | 系统太大怎么扩展和协作 | 微服务 + 容器化 |
| 2020s | 如何降低运维成本和复杂性 | Serverless + 云原生 |
📊 从表格中你能看到什么?
让我们逐行解读这张表:
1990s → 2000s:从"能跑就行"到"需要维护"。网站从静态页面变成动态应用,代码量激增,需要更好的组织方式。
2000s → 2010s:从"单机"到"分布式"。用户量爆炸式增长,单台服务器扛不住了,需要拆分系统,水平扩展。
2010s → 2020s:从"自己运维"到"云服务"。容器和微服务虽然强大,但运维成本太高,Serverless 让开发者只关注业务逻辑。
核心启示:架构演进不是技术选型的游戏,而是解决实际问题的过程。每个阶段都有其适用的场景,没有"最好的架构",只有"最适合的架构"。
了解架构演进的意义在于:
- 避免重复造轮子:很多"新"概念其实早在几十年前就有雏形,了解历史能让你站在巨人的肩膀上
- 做出合理的技术选型:没有最好的架构,只有最适合当前阶段的架构
- 理解技术背后的权衡:每一次架构演进都是在开发效率、系统性能、运维复杂度之间做取舍
- 预判技术趋势:历史总是押韵的,理解过去的演进规律有助于把握未来方向
2. 物理服务器时代 (1990s)
2.1 什么是物理服务器?
在互联网刚起步时,后端就是一台放在机房里的物理服务器(一台真实的电脑)。
💡 通俗解释
物理服务器就像你家里的台式机,但它:
- 7×24小时不关机
- 放在专门的数据中心(有空调、UPS电源、消防系统)
- 有更快的网络带宽(企业级光纤)
- 有固定的公网IP地址(全世界都能访问)
这就好比你家 vs 餐厅:你家只是偶尔做饭,餐厅则是专业厨房,全天候营业,设备更专业。
2.2 核心特点
- 单机部署:所有应用运行在一台物理机上
- 手动运维:需要人工上架、布线、安装系统
- 垂直扩展:性能不够时只能买更强的机器
🔧 垂直扩展 vs 水平扩展
**垂直扩展**(Scale Up):升级单台服务器的配置(更多CPU、更大内存、更快硬盘)。水平扩展(Scale Out):增加更多服务器,让它们一起工作。
比喻:
- 垂直扩展:把小餐厅改成大餐厅,装修更豪华,但只有一个厨师
- 水平扩展:开连锁店,每个店规模不大,但有100家分店
优缺点:
- 垂直扩展简单,但有上限(顶级服务器很贵,且有限制)
- 水平扩展理论上无限,但需要解决数据一致性问题 :::
2.3 痛点
- 慢:每次改代码都要手动上传,然后重启服务器
- 贵:扩容只能买更大的机器(垂直扩展)
- 难扩展:一台机器顶住所有请求,CPU满载时就只能排队
2.4 物理服务器时代的优缺点
| 维度 | 评价 |
|---|---|
| 优点 | 完全掌控硬件,性能可预测;没有虚拟化开销;数据物理隔离,安全性高 |
| 缺点 | 采购周期长(数周);前期投入大(CapEx);资源利用率低;扩容困难 |
| 适用场景 | 金融核心系统、政府涉密系统、对数据主权有严格要求的场景 |
💡 CapEx vs OpEx
CapEx(Capital Expenditure):资本性支出,一次性投入大量资金购买硬件。
OpEx(Operating Expenditure):运营性支出,按使用量付费(如云服务器)。
比喻:
- CapEx:买房,一次性付几百万,之后每月只需交物业费
- OpEx:租房,每月交房租,不用一次性掏大钱
云时代的启示:Serverless 和云服务让更多公司从 CapEx 转向 OpEx,降低创业门槛。
3. 单体架构时代 (2000s)
3.1 什么是单体架构?
随着框架的出现(Rails / Django / Spring),大家把所有功能都塞进一个应用里。
💡 通俗解释
单体架构(Monolith)就像一个超级商场:
- 服装区、食品区、电器区都在同一栋楼里
- 所有员工在一个管理系统里工作
- 如果整栋楼停电,所有区域都停止营业
对比微服务就像商业街:每家店独立运营,一家店关门不影响其他店。
3.2 核心特点
- 单一代码库:所有功能模块在同一个项目中
- 共享数据库:所有模块共用同一个数据库
- 统一部署:整个应用作为一个整体打包部署
3.3 优点
- 开发简单:一个项目搞定所有功能
- 部署方便:把一个大包扔到服务器上就行
- 调试容易:本地启动就能调试所有功能
3.4 痛点:雪崩效应
想象一下,如果"切菜"的师傅不小心切到了手(代码出了Bug),整个后厨都要停下来处理伤口,导致所有客人都吃不上饭。
这就是单体架构最大的风险:隔离性差。
🚨 真实的雪崩案例
某电商公司双十一大促:- 订单服务因为某个商品的价格计算错误,抛出异常
- 异常没有被正确捕获,导致线程池耗尽
- 所有后续请求(包括商品浏览、搜索、用户登录)都被阻塞
- 整个网站彻底瘫痪,持续1小时
如果用微服务:
- 订单服务挂了,但商品浏览、搜索、用户登录仍然可用
- 用户至少可以继续浏览商品,损失降到最低 :::
3.5 单体架构的优缺点与适用场景
| 维度 | 评价 |
|---|---|
| 优点 | 开发简单,无需考虑分布式复杂性;调试方便,本地启动即可调试全功能;部署简单,一个包即可运行;事务管理容易,单机数据库即可保证ACID |
| 缺点 | 代码耦合度高,随着业务增长代码膨胀;技术栈单一,难以局部升级;扩展困难,只能整体扩容;故障隔离差,一个模块故障影响全局;团队协作效率低,多人改同一套代码 |
| 适用场景 | 初创公司MVP验证、小型团队(<10人)、业务相对简单、对交付速度要求高于扩展性的场景 |
| 不适用场景 | 大型团队并行开发、需要频繁发布不同模块、某些模块需要独立扩容的场景 |
🎯 初学者建议
如果你正在学习后端开发,强烈建议从单体架构开始:
- 先学会走路:理解HTTP、数据库、基本的MVC架构
- 再考虑跑步:当项目真的遇到扩展性问题,再考虑微服务
- 避免过度设计:很多公司的"微服务"其实是"分布式单体",更难维护
学习路径:
- 阶段1:用 Spring Boot / Django / Rails 写一个完整的单体应用
- 阶段2:遇到性能瓶颈时,尝试拆分出1-2个服务
- 阶段3:当团队规模>50人,系统真的复杂了,再全面微服务化 :::
3.6 单体架构的技术栈
| 语言/框架 | 特点 | 代表企业 |
|---|---|---|
| Java + Spring | 企业级开发首选,生态完善 | 阿里巴巴、京东 |
| PHP + Laravel/ThinkPHP | 快速开发,适合中小型项目 | 早期 Facebook、微博 |
| Python + Django/Flask | 开发效率高,适合快速原型 | Instagram、Pinterest |
| Ruby on Rails | 约定优于配置,初创公司最爱 | GitHub、Twitter(早期) |
| Node.js + Express | 前后端统一语言,I/O密集型场景 | Netflix、Uber |
4. 容器化与微服务 (2010s)
4.1 为什么需要微服务?
单体架构的痛点在2010年代集中爆发:
- 代码太庞大:一个项目几百万行代码,新人入职要花一个月才能看懂
- 部署太慢:构建一次要30分钟,发布一次要小心翼翼
- 协作太难:100个开发者改同一个项目,代码冲突每天发生
- 扩展太贵:只需要扩展"聊天服务",却要复制整个应用
微服务的核心思想:把大应用拆成多个小服务,每个服务:
- 独立开发、独立部署
- 有自己的数据库
- 通过API通信
💡 Docker是什么?
Docker就像是"集装箱":
- 每个集装箱里有独立的货物(代码 + 依赖库 + 运行环境)
- 无论运到哪里(哪台服务器),打开集装箱就能直接开工
- 不用担心"我这台机器没有Python 3.9"、“那个机器缺少某个库”
比喻:
- 没有 Docker:每次搬家,要把家具、电器、衣服一件件搬上卡车,到了新家再一件件摆好
- 有 Docker:所有东西打包进集装箱,卡车直接运走,到了新家放下就能用
核心价值:“一次构建,到处运行”。
4.2 技术栈时间线
4.3 微服务架构
为了解决单体的问题,我们把大厨房拆成了很多个小厨房(服务):
- 专门负责用户的服务
- 专门负责订单的服务
- 专门负责支付的服务
4.4 Kubernetes 编排
当集装箱数量到达成百上千,就需要一个"港口调度系统":
- Kubernetes (K8s):负责把容器安排到合适的机器上(调度、扩缩容、滚动更新)
- Service Mesh:负责服务之间的交通规则(熔断、限流、重试、可观测)
💡 什么是"编排"?
编排(Orchestration)是指自动管理大量容器的系统。
比喻:
- 没有 K8s:你手动管理100个容器,哪个挂了要手动重启,哪个流量大了要手动加机器
- 有 K8s:你告诉它"我要这个服务一直有10个实例运行",它会自动完成:
- 哪台服务器资源充足,就把容器调度到那里
- 容器挂了,自动重启
- 流量大了,自动扩容到20个实例
- 更新代码时,滚动更新(先停1个旧实例,启动1个新实例,逐个替换)
关键点:微服务不是"拆开就好",真正的难点在于治理和运维。
4.5 微服务与容器化的优缺点
| 维度 | 评价 |
|---|---|
| 优点 | 服务独立部署,技术栈可异构;故障隔离,单个服务崩溃不影响全局;按需扩展,热点服务单独扩容;团队协作友好,不同团队负责不同服务;代码库更小,易于理解和维护 |
| 缺点 | 分布式复杂性高(网络延迟、分布式事务、服务发现);运维成本高,需要专业的DevOps团队;调试困难,问题可能需要跨多个服务追踪;数据一致性难以保证;部署和监控基础设施要求复杂 |
| 适用场景 | 大型团队(>50人)、业务复杂需要分模块独立演进、某些模块需要独立扩容、需要多语言技术栈、对可用性要求高的系统 |
| 不适用场景 | 小型团队、业务简单、流量小且稳定、没有专业运维团队的情况 |
⚠️ 微服务的陷阱
**陷阱1:分布式单体**拆了10个微服务,但它们之间紧密耦合:
- 服务A调用服务B,服务B调用服务C,服务C又调用服务A
- 改一个功能,要同时改5个服务
- 部署时,必须按顺序依次部署,否则系统报错
这比单体更糟糕:你拥有了单体的复杂性,又没有享受到微服务的独立部署好处。
陷阱2:过度拆分
把只有100行代码的功能也拆成一个独立服务:
- 10个服务,每个只有100行代码
- 服务间通信的开销(网络序列化/反序列化)比实际业务逻辑还重
- 运维成本爆炸:要部署、监控、日志收集10个服务
正确做法:从功能内聚的角度拆分,一个微服务应该是一个完整的业务能力(如"订单服务",而不是"订单创建服务"、“订单查询服务”)。
4.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 | 流量治理与安全 |
5. Serverless 与云原生时代 (2020s+)
5.1 为什么需要 Serverless?
微服务虽然好,但维护几十个小厨房还是很累。你需要担心:
- 厨房够不够大?(服务器扩容)
- 停电了怎么办?(高可用)
- 容器太多怎么管?(运维成本)
💡 Serverless 不是真的"没有服务器"
Serverless的意思是"你不需要管理服务器",而不是真的没有服务器。
比喻:
- 物理服务器时代:你买地、盖房、装修、雇厨师、买食材…全部自己来
- 云服务器时代:你租一个已经装修好的餐厅,但自己雇厨师、管理运营
- Serverless时代:你只需要设计菜单,云端有共享厨房,有专业厨师,你下单他们做,按次付费
核心变化:
- 以前:买服务器 → 配环境 → 部署代码 → 监控 → 扩容 → 维护
- 现在:写代码 → 上传 → 按使用量付费
就像外卖:你不需要厨房,只需要设计菜单,有人帮你做。
5.2 什么是 Serverless?
Serverless = FaaS + BaaS
FaaS(Function as a Service,函数即服务):
- 你只写函数(如"用户注册时发送欢迎邮件")
- 云厂商负责运行这个函数,自动扩缩容
- 典型代表:AWS Lambda、阿里云函数计算
BaaS(Backend as a Service,后端即服务):
- 登录 → Auth0 / Supabase Auth
- 支付 → Stripe
- 数据库 → Supabase / Firebase / DynamoDB
- 消息 → Kafka / SQS
🎯 Serverless 适用场景
最佳场景:
- 潮汐流量:外卖软件,中午流量大,半夜没人。Serverless会自动在中午分配1000台机器,半夜缩减到0台
- 事件驱动:“用户上传图片后,自动压缩图片”
- 快速验证:小团队、MVP、黑客松项目
不适合场景:
- 长时间运行的任务:视频转码(可能跑1小时,函数最大执行时间通常只有15分钟)
- 需要低延迟的应用:高频交易(冷启动延迟可能几十毫秒到几秒)
- 需要精细控制底层:操作系统内核调优、GPU直接访问 :::
5.3 Serverless 与云原生的优缺点
| 维度 | 评价 |
|---|---|
| 优点 | 零运维成本,开发者只需关注业务代码;自动扩缩容,完美应对流量峰值;按需付费,无流量时成本接近零;快速上线,几分钟即可部署全球;高可用内置,云服务自动处理故障转移 |
| 缺点 | 冷启动延迟(几百毫秒到数秒);运行时长限制(通常5-15分钟);调试困难,本地难以完全模拟云环境;供应商锁定风险;不适合长时间运行或计算密集型任务;成本在高频持续流量下可能反超传统方案 |
| 适用场景 | 事件驱动处理(图片处理、消息通知);潮汐流量应用(活动页、促销);快速原型验证和MVP;低频API或后台任务;无专职运维团队的小团队 |
| 不适用场景 | 需要持续低延迟的应用;长时间计算任务;对冷启动敏感的场景(高频交易);需要精细控制底层基础设施的场景 |
💰 成本对比:何时Serverless更贵?
**场景1:低频访问**- 传统服务器:每月$20(不管有没有人访问)
- Serverless:100万次请求 × $0.0002/次 = $20(仅在有流量时付费)
- 结论:低频场景,Serverless更省钱
场景2:高频持续访问
- 传统服务器:每月$20
- Serverless:1亿次请求 × $0.0002/次 = $20,000
- 结论:高频持续场景,传统服务器更省钱
场景3:潮汐流量
- 传统服务器:为了应对峰值,需要$100/月的服务器(平时资源利用率只有10%)
- Serverless:峰值时$20,平时几乎$0
- 结论:潮汐流量场景,Serverless节省成本
启示:不要盲目上Serverless,要根据实际流量特征做成本测算。
5.4 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 | 用编程语言定义基础设施 |
6. 各架构阶段对比与选型指南
6.1 架构演进全景对比
| 维度 | 物理服务器 | 单体架构 | 微服务+容器 | Serverless |
|---|---|---|---|---|
| 团队规模 | 1-5人 | 5-50人 | 50-500人 | 1-20人 |
| 部署复杂度 | 极高 | 低 | 极高 | 极低 |
| 运维成本 | 高 | 中 | 很高 | 低 |
| 扩展性 | 差 | 垂直扩展有限 | 水平扩展优秀 | 自动扩展 |
| 技术栈灵活性 | 无 | 单一 | 多样化 | 受限 |
| 冷启动 | 无 | 无 | 容器启动时间 | 有延迟 |
| 适用场景 | 遗留系统、特殊合规要求 | 初创公司、业务简单 | 大型互联网公司、复杂业务 | 快速验证、事件驱动 |
6.2 技术选型决策树
开始选型
│
├─ 团队有专业运维人员?
│ ├─ 是 → 考虑微服务或物理机
│ └─ 否 → 继续判断
│
├─ 需要快速上线验证想法?
│ ├─ 是 → Serverless 或单体
│ └─ 否 → 继续判断
│
├─ 团队规模 > 50人?
│ ├─ 是 → 考虑微服务
│ └─ 否 → 继续判断
│
├─ 流量有明显峰谷特征?
│ ├─ 是 → Serverless
│ └─ 否 → 单体架构(推荐初创)
│
└─ 特殊要求(合规、遗留系统)?
└─ 是 → 物理服务器
🎯 初学者选型建议
如果你是个开发者或小团队:
- 阶段0 (学习):本地跑单体应用,理解HTTP、数据库、基本架构
- 阶段1 (MVP):部署单体应用到云服务器(如阿里云ECS、AWS EC2)
- 阶段2 (增长):当团队>10人、业务变复杂,考虑拆分出1-2个微服务
- 阶段3 (成熟):当团队>50人、流量百万级,全面微服务化
关键原则:不要一开始就上微服务,那是"过早优化"。让架构随业务成长而演进。
6.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
7. 总结与学习路线
7.1 核心要点
后端架构的演进,本质上是在做加法和减法:
| 时代 | 架构 | 开发者要做的事 | 运维要做的事 |
|---|---|---|---|
| 物理时代 | 单机 | 写脚本、手动部署 | 维护机房与硬件 |
| 单体时代 | 一整块 | 写所有业务逻辑 | 维护几台大服务器 |
| 微服务时代 | 拆分 | 关注单一业务 | 维护K8s集群(很累!) |
| Serverless | 函数 | 只写核心函数 | 喝茶(云厂商全包了) |
关键洞察:
- 架构演进不是"新技术取代旧技术",而是适用场景的变化
- 没有银弹,每个架构都有其适用的边界
- 选择架构要考虑:团队规模、业务复杂度、流量特征、运维能力
7.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(领域驱动设计)
- 培养技术判断力和架构思维
- 实践项目:设计一个支持百万级用户的系统架构,包含高可用、弹性伸缩等方案
7.3 持续学习资源推荐
书籍:
- 《设计数据密集型应用》(DDIA)- 分布式系统必读
- 《云原生模式》
- 《微服务设计》
- 《领域驱动设计》
在线资源:
- AWS/Azure/阿里云官方架构文档
- CNCF(云原生计算基金会)项目文档
- 各大公司技术博客(Netflix Tech Blog、阿里技术公众号等)
8. 名词速查表(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 | - | 可观测性,利用日志/指标/追踪理解系统运行状态 |
Last updated 26 Apr 2026, 03:21 +0800 .