第 1 讲：架构的定义、本质与复杂度来源

核心结论（10 条必记）

1. 架构是系统的顶层设计 -- 关注整体结构、关键决策、质量属性，不关注代码细节
2. 架构设计的本质是管理复杂度 -- 识别复杂度来源，通过合理结构控制复杂度
3. 架构复杂度三大来源 -- 高性能、高可用、可扩展
4. 架构不等于框架不等于设计模式 -- 架构是宏观，框架是中观，设计模式是微观
5. 解决一个复杂度往往引入新的复杂度 -- 架构设计是权衡的艺术
6. 好的架构是最合适的架构 -- 不是最牛的架构
7. 架构是演化出来的 -- 不是一开始就设计完美的
8. 架构设计要先识别复杂度再针对性设计 -- 有什么问题解决什么问题
9. 不要过度设计 -- 3人团队不需要微服务，日活1000不需要分库分表
10. 架构师核心能力 -- 复杂度识别、方案设计、权衡取舍、技术广度、沟通协调

---

一、为什么要先搞清楚"什么是架构"

场景 1：技术评审会上的争论

小李（开发）： "我觉得我们应该用微服务架构。" 老王（架构师）： "为什么？" 小李： "因为现在大厂都用微服务啊，而且微服务更先进。" 老王： "我们现在就 3 个人的后端团队，日活 5000，你要拆多少个微服务？" 小李： "至少 10 个吧，用户服务、订单服务、商品服务……" 老王： "那分布式事务怎么办？服务治理谁来做？监控链路追踪配好了吗？"

问题：把"技术方案"当成了"架构"，没有理解架构的本质。

场景 2：盲目照搬大厂方案

某创业公司看到阿里巴巴的中台架构，决定也搞中台。团队只有 20 人，拆了十几个中台，业务复杂度没那么高，反而增加了大量协调成本，半年后项目严重延期，最后回滚为单体。

问题：没有搞清楚架构设计的本质是"解决复杂度"，而不是"炫技"。

---

二、架构到底是什么

经典定义

来源	定义	强调点
IEEE 1471	有关软件整体结构与组件的抽象描述	整体结构、组件、抽象描述
架构师定义	系统的顶层设计，包括系统的关键决策	顶层设计、关键决策、修改代价高
Martin Fowler	架构是关于重要部分的决策	关注"重要部分"

综合理解

架构是对系统结构的顶层设计，包括：

1. 系统分成哪些模块/组件
2. 模块之间如何交互
3. 关键技术选型
4. 核心约束和原则
5. 重要的质量属性如何保证

架构应该关注的 vs 不应该关注的

应该关注： 模块划分、通信方式、数据存储、高并发方案、高可用保证

不应该关注： 设计模式选择、函数写法、变量命名、多线程细节

---

三、架构的本质：管理复杂度

架构设计的本质，就是管理和控制系统的复杂度。

复杂度的两种来源

来源	说明	示例
业务复杂度	业务规则/流程/场景复杂	电商促销规则、金融风控、物流路由
技术复杂度	高性能/高可用/可扩展/安全/低成本	秒杀10万QPS、支付99.99%可用性

为什么分层架构能控制复杂度

不分层： 所有逻辑混在一起，难以理解、测试、复用、修改

def create_order(req):
    # 校验 + 查询 + 计算 + 扣库存 + 创建订单 + 发消息 全混一起
    pass

分层后： Controller -> Service -> Repository，职责清晰，复杂度被有效控制

# Controller 层只管入口
# Service 层管业务逻辑
# Repository 层管数据访问

为什么微服务能分解复杂度

单体问题： 代码量大、协作困难、部署慢、扩展难、技术栈统一

拆分后： 代码量可控、独立开发部署、针对性扩容、可选技术栈

（但微服务也引入分布式事务、服务治理等新复杂度）

---

四、架构 vs 框架 vs 设计模式

维度	架构	框架	设计模式
层次	宏观	中观	微观
关注点	整体结构和关键决策	可复用的半成品代码	特定场景的代码套路
例子	微服务、分层、SOA	Spring Boot、Django	单例、策略、观察者

三者的关系：

架构（决定用微服务）
  -> 框架（选择 Spring Boot）
    -> 设计模式（支付用策略模式）

常见误区

误区	错误说法	正确说法
框架当架构	"我们用的是 Spring Boot 架构"	"微服务架构，用 Spring Boot 框架开发"
模式当架构	"我们用的是 MVC 架构"	"分层架构，表现层用 MVC 设计模式"
纠结细节	架构评审讨论单例模式	架构评审关注模块划分和技术选型

---

五、架构复杂度的三大来源

来源一：高性能

典型场景： 秒杀系统每秒10万+请求、搜索毫秒级响应

解决方案与引入的新复杂度：

解决方案	解决什么	引入什么
缓存	数据库瓶颈	缓存一致性问题
分库分表	单库瓶颈	跨库查询、分布式事务
消息队列	削峰填谷	消息丢失、重复消费
负载均衡	单机瓶颈	会话管理、数据一致性

案例：秒杀系统架构演进

v1.0 直接操作数据库 -> 数据库被打爆
v2.0 加缓存 -> 缓存和数据库一致性难保证
v3.0 库存预热 + 消息队列削峰 -> 复杂度可控，换来高性能

来源二：高可用

可用性指标：

• 99.9%（3个9）：年故障 8.76 小时
• 99.99%（4个9）：年故障 52.56 分钟
• 99.999%（5个9）：年故障 5.26 分钟

解决方案与引入的新复杂度：

解决方案	解决什么	引入什么
主备/主从	单点故障	切换逻辑、数据同步
集群	单点故障	一致性保证、脑裂问题
异地多活	机房级故障	数据同步、流量调度、高成本
降级/熔断/限流	接口级故障	规则配置、用户体验

案例：MySQL 高可用演进

v1.0 单机 -> 宕机后服务不可用
v2.0 主备 -> 手动切换慢，可能丢数据
v3.0 主从 + 自动切换 -> 需要监控、选主、防脑裂
v4.0 异地多活 -> 数据同步、流量调度、成本高

来源三：可扩展

两种扩展需求： 功能快速迭代（业务扩展）、容量平滑增长（容量扩展）

案例：电商系统演进

v1.0 单体应用 -> 代码多、协作困难、部署慢
v2.0 分层架构 -> 职责清晰，但还在一个工程
v3.0 服务化（SOA） -> 独立开发部署，但依赖复杂
v4.0 微服务 -> 拆得更细，有服务治理，但管理复杂

小结

解决一个复杂度问题，往往会引入新的复杂度。架构设计的本质，就是在不同复杂度之间做权衡和取舍。

---

六、什么时候该做架构设计

判断表

场景	团队	用户	建议架构
MVP / 创业初期	1-3人	<1万	单体 + 基本分层
快速发展期	5-10人	1万-10万	分层 + 缓存 + 主从
规模化阶段	10-50人	10万-100万	服务化 + 读写分离 + MQ
平台化阶段	50-200人	100万-1000万	微服务 + 分库分表 + 异地多活

三条原则

1. 先识别复杂度 -- 核心复杂度是什么？现在要解决还是未来？
2. 针对性设计 -- 有什么问题解决什么问题，不要过度设计
3. 架构演进 -- 架构是演进的，遇到问题再优化

---

七、架构师的核心能力

能力	说明
复杂度识别	快速准确识别系统核心复杂度
方案设计	针对特定复杂度设计3-5个可行方案
权衡取舍	基于实际约束在多方案间做最合适选择
技术广度	掌握主流技术栈的适用场景和坑
沟通协调	把架构方案讲清楚，推动落地

架构师 vs 程序员

维度	程序员	架构师
关注点	如何实现功能	如何控制复杂度
思维方式	自底向上	自顶向下
决策重点	算法、设计模式	结构、选型、质量
时间视角	当前功能	长期演进

---

八、面试高频题

1. 什么是架构？架构和框架有什么区别？

架构是宏观的顶层设计关注整体结构和关键决策 -> 框架是中观的半成品代码提供基础结构和通用功能 -> 两者层次不同，架构决定用什么框架

2. 架构设计的本质是什么？

软件系统最大的挑战是复杂度 -> 架构设计的本质是管理和控制复杂度 -> 识别复杂度来源并通过合理结构控制它

3. 架构复杂度的来源有哪些？

三大来源：高性能（并发量大响应要快）、高可用（不能宕机故障恢复快）、可扩展（功能快速迭代容量增长） -> 解决一个复杂度往往引入新的复杂度 -> 架构设计是权衡的艺术

4. 什么时候该做架构设计？

先识别系统核心复杂度是什么 -> 有什么问题解决什么问题不要过度设计 -> 架构是演进的遇到问题再优化 -> 3人团队不需要微服务，日活1000不需要分库分表

5. 你做过的最复杂的架构设计是什么？

用 STAR 法 -> Situation（背景规模）-> Task（核心复杂度）-> Action（设计3个方案、评估选择）-> Result（上线效果、经验教训）

---

练习题（待完成）

• [ ] 练习 1：选择一个你熟悉的系统，分析它的核心复杂度是什么？现在的架构如何应对？
• [ ] 练习 2：设计一个在线教育直播系统（万人同时在线、延迟<3秒、不能掉线），分析复杂度并设计至少3个备选方案
• [ ] 练习 3：分析电商系统演进路径（单体 -> 分层 -> 服务化 -> 微服务），每一步解决了什么复杂度、引入了什么新复杂度