[toc]
程序系统架构演变
目前程序系统架构大体经历了下面几个过程。
架构演变的底层逻辑
先明确一个核心观点：架构的本质是 “权衡”—— 在 “业务需求”“技术成本”“性能体验” 三者间找平衡点：
- 业务需求：用户量、功能复杂度、迭代速度（比如创业项目要 “快”，成熟产品要 “稳”）；
- 技术成本：开发效率、运维难度、团队能力（比如小团队养不起微服务运维团队）；
- 性能体验：响应速度、可用性、扩展性（比如电商双 11 要抗住 10 倍流量）。
所有架构的演变，都是这三者矛盾升级后的解决方案。
单体架构（2000-2010）: “小而美” 的起步阶段
业务背景
2000 年前后，互联网刚起步，产品多是 “工具型” 或 “信息展示型”。比如企业官网（展示产品）、个人博客（写文章）、小型 CRM（管理客户）。
核心需求就是快速上线、能用就行。用户量通常在 1000 以内，功能不超过 10 个模块，每天访问量几千次左右。
这时，没人会考虑 “分布式”“高可用”。因为业务根本用不上，反而会增加开发成本。
架构设计
单体架构的核心概念是 “集中式”。即所有代码、依赖、数据(可选)都在一个应用里，部署在一台服务器上。
因此互联网早期，软件系统的架构就是将所有的功能代码都放在一个应用程序中，并且部署在一个服务器即可。这样可以减少开发，部署和维护的成本。
如图所示一个单体架构的电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，这些模块通常在一个项目中，然后部署到一台服务器中。
架构优缺点
优点
- 开发成本低：一个人能搞定全栈（前端 + 后端 + 数据库），不用考虑 “服务间调用”“数据同步”；
- 维护简单：报错了直接在代码里打断点，从接口层追到数据层，一步定位问题；
- 部署简单：只需要维护一台服务器，部署时全量替换包，重启服务器就行。
缺点
- 性能瓶颈：由于单体架构中应用和数据库部署在同一个服务器中。因此两者在流量高峰期间会抢服务器 CPU；
- 可扩展性差：由于所有功能都在一个应用中，因此当业务需求增加时，无法针对不同模块进行优化和扩展。
- 部署风险：想改个程序，必须重新打包，重新部署到服务器中，在重启期间，程序无法使用。
- 代码臃肿：如果程序代码不断增加，代码从 1 万行涨到 5 万行，找一个逻辑都要翻半天。
架构优化技巧
- 加缓存：用 Redis 存热门数据（比如门票库存），减少数据库查询；
- 数据库读写分离：主库写（下单），从库读（查订单），分担压力；
- 代码分层：代码严格按 “Controller→Service→DAO” 分层，避免逻辑混乱。
只有当优化后仍满足不了业务（比如用户量超 10 万），才需要考虑下一阶段。
架构突破点
当出现以下场景时，单体架构就到了 “天花板”：
- 服务器 CPU / 内存长期占用超 80%，优化后仍无法下降；
- 单次部署时间超过 10 分钟，影响业务迭代（比如一天要发 3 次版）；
- 团队超过 5 人，多人改同一套代码，冲突不断。
这时，“垂直拆分架构” 就该登场了。
垂直拆分架构（2010-2013）：业务拆分
业务背景
2010 年后，互联网产品开始向 “多功能” 发展：比如电商从 “只卖商品” 增加了 “订单支付 用户评价 物流跟踪等功能”；
这时，单体架构的 “一锅粥” 问题凸显。即随着单体应用的访问量不断增大，由于单体应用中的各个功能模块紧密耦合，因此无法针对不同的模块进行优化和扩展。
例如电商系统的 “商品浏览”（读多写少）和 “订单支付”（写多读少）混在一起，商品页的高访问量会拖慢支付流程。
架构设计
垂直拆分架构的核心逻辑是 “按业务进行拆分，隔离”。即把原来的大单体拆成多个独立的 “小单体”，每个小单体负责一块业务，拥有自己的代码、服务器和数据库。
将一个大单体按照业务拆分为多个单体之后，每个单体就可以根据需求进行各自优化和扩展了。
例如一个大型电商系统的单体应用，拆分为电商系统，后台系统，CMS系统等。我们可以根据需求来优化扩展对应的应用。如图所示。
优缺点
优点：解决了单体的 “大而全” 问题
- 风险隔离：例如某电商的商品服务因缓存失效崩了，但订单和支付服务正常，用户还能下单（只是看不到商品详情）；
- 方便优化和扩展：商品服务访问量大，则单独对商品服务添加 2 台服务器；如果支付服务要稳定，则单独对支付服务使用高可用配置（双机热备）；
- 团队协作：不同的业务功能可以分给不同的团队开发。每个团队专注一块业务，代码冲突少了。
缺点
- 系统复杂度增加：由于是将一个单体应用拆分为多个互不相干的应用。因此系统的复杂度就会增加。
- 数据同步问题： 由于是将一个单体应用拆分为多个互不相干的应用。因此不同应用之间的数据同步问题就会变得比较复杂。
- 重复开发：各个应用之间相互独立，通常无法互相调用，并且应用之间会有重复的代码。例如每个应用可能都需要写一套登录校验的代码。
垂直拆分架构的 “判断标准”
不是所有业务都要拆，满足以下条件再拆：
- 业务模块边界清晰（比如 “商品业务模块” 和 “用户业务模块” 完全独立，没有强耦合）；
- 某个模块的访问量 / 数据量是其他模块的 3 倍以上（比如商品模块每天 100 万访问，其他模块 10 万）；
- 团队人数超过 10 人，需要按业务域分工。
架构突破点
当垂直拆分后的服务越来越多（比如电商加了 “评价服务”“物流服务”），新的问题出现了。
- 每个服务都要对接支付接口（微信 / 支付宝），但对接逻辑复杂，每个服务都写一遍太浪费；
- 服务间调用越来越多（比如下单要调用商品服务查库存、调用用户服务查地址、调用支付服务发起支付），接口地址管理混乱（改一个接口，所有调用方都要改）。
这时，需要一个 “统一的公共服务” 和 “服务调用管理中心”—— 分布式架构（SOA）应运而生。
分布式架构（SOA）（2013-2016）：“公共服务 + 服务总线”
业务背景
2013 年后，互联网产品开始向 “平台化” 发展：比如美团从 “外卖” 扩展到 “酒店”“打车”“买菜”；阿里从 “淘宝” 扩展到 “天猫”“支付宝”“阿里云”。
这些产品的核心特点是 “多业务线复用公共能力”。比如 “支付”“用户认证”“消息推送” 是所有业务线都需要的功能。如果每个业务线都自己做，不仅成本高，还容易出问题（比如支付接口不统一，导致对账混乱）。
因此分布式架构就需要将多个业务中重复的功能进行抽取，做出一个独立的应用，并且让其他需要的应用去调用它。
此时还需增加一个中心，这个中心就是用来连接各个服务应用。各个服务应用之间，只需要和中心进行通信，这个时候，各个应用之间的交互就会变得更加的清晰，业务架构/逻辑等，也会变得很清楚。
架构设计
分布式架构（SOA）的核心是 “标准化公共服务 + 中心化服务总线”。即把所有业务都需要的能力抽成 “公共服务”，用 “服务总线（ESB）” 统一管理服务间的调用，从而解决 “重复开发” 和 “调用混乱” 的问题。
如图所示，无ESB的分布式架构 
如图所示，有ESB的分布式架构 
此处的服务总线（ESB），是用来管理服务应用之间的调用关系的。它会记录下每个服务应用的地址，当一个服务应用需要调用另一个服务应用时，就会去服务总线中查询目标服务的地址，然后进行调用。
优缺点
- 优点1：抽取的公共业务代码来作为服务层，提高了代码的复用性。
- 优点2: 使用中心解决了服务应用之间调用关系
- 缺点1：应用与应用之间的耦合性更高了。并且一旦其中一个公共业务出问题，那么会影响到其他的应用。
- 缺点2：服务与服务之间关系复杂，并且运维和测试部署都会变得困难。
优化方向
- 高可用：给 中心/ESB 或公共服务做集群（多台服务器部署），一台挂了，其他台继续工作；
- 性能优化：给 中心/ESB 加缓存（比如缓存服务地址），减少 中心/ESB 的负载压力；
- 服务解耦：用 “事件驱动” 替代 “同步调用”（比如订单创建后，发一条事件到消息队列，支付服务监听消息队列，不用 中心/ESB 同步调用）。
架构突破点
2016 年后，互联网进入 “高并发时代”—— 比如双 11 的订单峰值超 10 万 / 秒，SOA 的 ESB 根本扛不住：
- 中心/ESB 的集群规模要扩到 10 台以上，运维成本太高；
- 服务间的同步调用（比如下单要等 3 个服务调用完成）导致响应时间超 2 秒，用户体验差；
- 公共服务和业务服务耦合太紧，公共服务改个小功能，所有业务服务都要停服升级。
这时，需要一种 “更灵活、更抗并发” 的架构 —— 微服务架构来了。
微服务架构（2016-2020）：“细粒度拆分 + 去中心化治理”
业务背景
2016 年后，互联网产品进入 “生态化” 阶段：比如阿里的 “电商生态” 包含淘宝、天猫、1688、菜鸟物流；字节的 “内容生态” 包含抖音、今日头条、西瓜视频。
这些产品的核心特点是 “高并发、快迭代、多团队独立开发”。比如抖音的 “短视频推荐” 要扛住亿级用户访问，同时每天要发 3 次版（迭代新功能），分布式架构的 “重总线 + 粗粒度服务” 根本满足不了。
架构设计：“拆到最小 + 去掉总线”
微服务架构的核心是 “细粒度拆分 + 去中心化治理”。就是把服务拆到 “一个功能一个服务”。去掉中心化的 ESB，让服务之间直接调用，同时用 “服务治理工具” 解决调用中的问题。
即原有的大的系统会拆分为多个可以独立开发、设计、运行的小型服务。各个小型服务之间，相互通信，来组成一个业务系统。这就是微服务架构。
微服务架构下需要解决的问题
微服务架构，简单的说就是将单体应用进一步拆分，拆分成更小的服务，每个服务都是一个可以独立运行的项目。
一旦采用微服务系统架构，就势必会遇到这样几个问题：
- 这么多服务，如何管理它们？
- 这么多服务，它们之间是如何互相通信？
- 这么多服务，如何访问它们？
- 这么多服务，一旦某个服务出现了问题，该如何处理？
上面的这些问题都是微服务架构下会遇到的。因此为了解决上面的问题就出现了许多概念。如下所示
- 服务注册发现
- 服务调用
- 服务网关
- 服务容错
- 服务链路追踪
微服务架构的优缺点
优点：灵活、抗并发、易迭代
- 故障隔离：若某一个微服务发送故障，不会影响到其他正常微服务，影响范围小；
- 技术栈灵活：推荐服务用 Go（性能高），用户服务用 Java（生态成熟），视频上传服务用 Python（转码库多）；
- 按需扩容：在某些流量高的时间段，可以对负载压力大的微服务进行扩容。
缺点：“分布式复杂性”
- 分布式事务不一致：由于微服务架构下，服务之间是通过网络进行通信的，因此会存在分布式事务不一致的问题。
- 服务调用链路太长：由于微服务架构下，服务之间是通过网络进行通信的，因此会存在服务调用链路太长的问题。这就会导致服务调用的延迟增加。
- 运维复杂度爆炸：随着微服务的增加，服务之间的调用关系也会变得复杂。这就会导致服务治理的难度增加。
微服务架构的适用场景
不是所有公司都适合微服务，满足以下条件再上：
- 用户量超 1000 万，峰值 QPS 超 1 万；
- 团队人数超 30 人，按业务域分成多个小团队；
- 有专门的运维 / DevOps 团队，能维护服务治理工具。
架构突破点
微服务解决了高并发问题，但对 “轻量需求” 来说，成本太高：比如抖音的 “用户点赞通知” 功能，每天调用量 10 万次，却要维护一个 “通知微服务”（包含注册中心、网关、监控），性价比太低。
这时，需要一种 “不用管运维，只写业务代码” 的架构 ——Serverless 架构。
Serverless 架构（2020 - 至今）：“无服务器，只写函数”
业务背景：从 “重服务” 到 “轻量功能”
2020 年后，互联网产品进入 “精细化运营” 阶段：比如电商的 “优惠券核销 物流短信通知等功能”；社交 APP 的 “点赞提醒 评论回复通知 等功能”。
这些功能的核心特点是 “轻量、潮汐流量”。 比如 “优惠券核销” 平时每天 1 万次调用，双 11 当天 100 万次调用；“点赞提醒” 凌晨调用量几乎为 0，晚上 8 点峰值 10 万次。
用微服务做这些功能，会有两个问题：
- 运维成本高：一个 “短信通知” 微服务，要维护服务器、扩容配置，太浪费；
- 成本高：服务器 24 小时开机，即使调用量为 0，也要花钱。
架构设计
Serverless（无服务器架构）的核心是 “开发者只写函数，云厂商管所有基础设施”。
即把业务逻辑写成 “函数”（比如 “发送短信” 函数），函数触发时才运行，云厂商负责服务器、扩容、运维，按调用次数收费。
架构组成
| 架构层 | 核心组件 | 作用 |
|---|---|---|
| 函数层（FaaS） | 短信函数、优惠券核销函数、点赞提醒函数 | 每个函数只做一件事（比如 “短信函数”：接收手机号和内容，调用阿里云短信 API 发送） |
| 托管服务层（BaaS） | 云数据库 RDS、OSS、消息服务 MNS | 用云厂商的托管服务替代自建服务（比如用 RDS 存优惠券数据，不用自建 MySQL） |
| 触发器层 | API 网关、定时触发器、MNS 触发器 | 触发函数运行（比如用户点击 “核销优惠券”，API 网关触发 “优惠券核销函数”） |
函数运行流程（以短信通知案例）
- 用户下单成功，订单服务发一条 “发送短信” 消息到 MNS；
- MNS 触发器监听消息，触发 “短信函数” 运行；
- “短信函数” 从 RDS 查用户手机号，调用阿里云短信 API 发送订单通知；
- 函数运行完成后，自动释放资源（不占用服务器）；
- 云厂商按 “函数运行时间（100ms）+ 调用次数（1 次）” 收费。
核心特点
- 无状态：函数运行时不保存数据（比如 “短信函数” 不存手机号，每次运行都从 RDS 查），下次触发重新初始化；
- 自动扩缩容：调用量从 1 万涨到 100 万，云厂商自动加 100 个函数实例；调用量降到 0，实例也降到 0，不花钱；
- 按调用计费：阿里云函数计算，每月 100 万次调用以内免费，超了按 0.01 元 / 万次收费，成本极低。
优缺点
优点：极致轻量化，降本增效
- 开发快：“发送短信” 函数只需要 10 行代码（调用云厂商的短信 API），不用写服务治理逻辑，10 分钟就能上线；
- 运维为 0：不用管服务器、扩容、监控，云厂商全搞定（比如函数运行报错，云厂商会发告警到钉钉）；
- 成本低：某电商的 “优惠券核销” 函数，每月调用量 50 万次，成本不到 1 元，比微服务（每月服务器费 500 元）省 99%。
缺点：不适合所有场景（别滥用！）
- 状态管理难：函数无状态，需要频繁调用 BaaS 服务（比如 RDS），如果业务逻辑依赖复杂状态（比如长会话），会很麻烦；
- 厂商锁定：阿里云函数计算的 API 和 AWS Lambda 不一样，把函数从阿里云迁到 AWS，要改代码；
Serverless架构的 “最佳实践”
- 适合场景：轻量功能（短信、日志处理）、潮汐流量（秒杀通知）、边缘场景（IoT 设备数据处理）；
- 不适合场景：低延迟（直播、游戏）、高状态（长会话应用）、高计算（大数据分析）；
- 混合架构：核心服务用微服务（比如电商的订单服务），边缘功能用 Serverless（比如短信通知），兼顾性能和成本
架构没有 “银弹”，选择合适的架构
回顾上文，你会发现一个规律：架构的演变，不是 “从差到好”，而是 “从适合小业务到适合大业务”—— 没有哪种架构是 “绝对先进” 的。
- 2025 年的今天，很多内部管理系统（比如公司的 OA）还是用单体架构（因为用户量小，没必要拆）；
- 某些大公司的核心业务用微服务架构，边缘业务（短信通知）用 Serverless架构；
- 一个创业项目，从单体架构起步，用户量超 10 万拆垂直架构，超 1000 万拆微服务，边缘功能用 Serverless，这才是 “合理的演进路径”。
最后，给你一个 “架构选择决策表”，帮你快速判断该用哪种架构。
| 业务规模 | 团队人数 | 核心需求 | 推荐架构 |
|---|---|---|---|
| 用户量 < 1 万，功能 < 10 个 | 1-5 人 | 快速上线，成本低 | 单体架构 |
| 用户量 1 万 - 10 万，功能 10-20 个 | 5-10 人 | 风险隔离，性能可控 | 垂直拆分架构 |
| 用户量 10 万 - 100 万，多业务线 | 10-30 人 | 公共能力复用，调用标准化 | 分布式架构（SOA） |
| 用户量 100 万 - 1 亿，高并发 | 30 + 人 | 灵活迭代，抗并发 | 微服务架构 |
| 轻量功能，潮汐流量 | 任意 | 降本增效，运维为 0 | Serverless 架构 |
记住：最好的架构，是能支撑当前业务，又能为未来 1-2 年的增长预留空间的架构。千万不要为了 “追热点” 而盲目拆分，也不要为了 “省成本” 而固守旧架构。