系统设计

在约束条件下做架构决策，支撑系统持续演进的思维模型。

系统设计的本质

什么是系统设计

系统设计关注的是：

系统设计 = 约束下的架构决策过程

系统设计关注的不是"功能"，而是"能力"

功能回答的是：

系统设计回答的是：

因此，系统设计的核心关注点是：

这些被统称为：系统的质量属性。

系统设计的六层认知模型

业务目标   ↓约束条件   ↓架构决策   ↓实现机制   ↓系统能力   ↓验证/演进

业务目标（Why）

系统首先服务于业务目标，而不是技术理想。

常见目标包括：

没有业务目标的系统设计，只是在堆复杂度。

约束条件（Constraint）

约束决定了设计空间的边界。

常见约束包括：

约束不是负担，而是设计的前提条件。

架构决策（Decision）

系统设计的核心不是"选什么技术"，而是做出结构性决策，结构性决策定义了"系统是什么形态"：

每一个决策，本质上都是在约束条件下做取舍——用某些能力的损失换取其他能力的获得。

系统能力（Outcome）

设计决策最终沉淀为系统的能力边界：

实现机制（Implementation）

设计决策需要落地为具体实现方案。

关键实现要素：

实现层是"决策"转化为"能力"的桥梁，也是最容易引入复杂度的地方。

验证/演进（Verification & Evolution）

系统能力需要通过度量验证，并随业务演进。

验证机制：

演进机制：

缺乏验证的架构决策是无法迭代优化的赌博。

系统设计方法论

架构决策的结构化思考框架，而非具体技术方案

核心本质

系统设计方法论回答一个根本问题：如何在动手之前，先想清楚？

它的价值在于：避免凭感觉决策、避免遗漏关键要素、避免在错误的方向上走太远。

三条元原则

合适原则 — 优秀架构是约束条件下的最优解，而非技术选型的最优解。大公司方案在小团队往往是灾难。

何时不适用：当合规要求、技术债临界点或组织惯性强制指定了某种方案时，"合适"需要重新定义。此刻的"不合适"可能源于历史包袱而非理性选择，此时的优先级是识别约束的本质可塑性，而非盲目顺从。

简单原则 — 复杂不会让系统更可靠，只会让它更难维护。简单方案和复杂方案都能满足时，选简单的。

何时不适用：高性能计算、硬实时系统、金融级一致性的场景中，适度复杂性是满足指标的代价。此刻的"简单"可能是性能或正确性的敌人，简单原则让位于能力交付。

演化原则 — 没有一步到位的架构。架构的生命力在于持续迭代，而非一步登天。

何时不适用：当系统核心抽象已经固化、上下游依赖已锁定、改造风险远大于收益时，激进重构是陷阱而非机会。此刻的"演化"应改为局部优化与渐进改良，而非推倒重来。

四步法框架

识别复杂度 → 设计备选方案 → 评估选择 → 详细设计

核心价值：避免在错误的复杂度上投入，以及在错误的方向上走太远。

步骤目的
识别复杂度做对的事，而非做多的事
设计备选方案不把鸡蛋放一个篮子
评估选择用约束而非感觉决策
详细设计确保方案能落地

第一步：识别复杂度

做什么：找出真正的能力缺口，而非功能需求。

系统设计的起点不是"要做什么功能"，而是"当前系统缺什么能力"。

类型本质
高性能单机瓶颈 vs 水平扩展能力
高可用故障容忍度与恢复速度
可扩展需求变化的响应成本

关键：不是每个系统都需要高大全。识别出当前阶段下的1-2个主要矛盾即可。

常见错误：用想象的需求替代实际需求，为"未来可能"提前买单。

第二步：设计备选方案

做什么：设计3-5个有显著差异的方案。

方案之间必须有架构级差异（如主备 vs 集群 vs 分片），而非细节差异（如检测周期1分钟 vs 5分钟）。

关键约束：

第三步：评估和选择

做什么：建立评估矩阵，从多维度权衡。

核心维度：性能、可用性、硬件成本、项目投入、复杂度、可扩展性。

选择原则：最简单优先、最合适优先、最熟悉优先。

第四步：详细设计

做什么：将选定的方案落实到关键技术细节。

确定：部署架构、配置参数、接口协议、数据模型。

方法论检查清单

阶段自检问题
开始前真正的复杂度是什么？还是在解决假问题？
备选方案有没有明显差异的多个方案？
评估选择决策依据是什么？还是凭感觉选？
详细设计细节是否足以落地？

HLD/LLD 分层设计

HLD 回答"系统由什么构成"，LLD 回答"每个部分怎么实现"。

本质：分层的必要性

系统设计天然分为两个层次：

分层是为了让不同角色、不同阶段关注不同层次的问题，避免认知过载。

HLD：宏观架构

HLD 是系统的"航拍图"——展示整体结构、主要组件及其交互关系，但不触及实现细节。

要素说明
系统架构主要组件、组件间关系、部署结构
服务划分模块边界、职责定义、服务间接口
数据流模块间数据流动方向
技术栈框架、数据库、中间件选型
约束权衡性能、安全、成本的权衡决策

产出物：架构图、服务/模块职责定义、API 接口概览、数据存储策略、关键设计决策。

LLD：微观实现

LLD 是 HLD 每个组件的"施工图纸"——细化到类、方法、算法、数据结构。

要素说明
类/模块设计类图、方法签名、模块接口
算法逻辑关键算法的伪代码或流程
数据结构具体的数据 schema、索引
错误处理异常场景、边界条件

产出物：类图与时序图、详细接口定义（请求/响应格式）、数据库表结构、单元测试计划。

关系对照

维度HLDLLD
视角整体局部
粒度组件级类/方法级
关注结构与关系逻辑与实现
指导协调与评审开发与测试
产出架构图类图/时序图

常见问题

问题本质
HLD 太粗缺乏关键设计决策，只画方块图
HLD 太细把 LLD 当 HLD 写，层次不清
LLD 缺失开发人员自由度过大，偏离设计意图
两者脱节HLD 描述的架构在 LLD 中未体现

判断要点

系统设计的权衡

系统设计不只是计算 QPS 和画架构图，更重要的是在多重约束下做取舍。

权衡的第一性原理

权衡之所以存在，两个根本原因：

资源有限 — 预算、人力、时间都是有限的，在有限资源下追求 A 能力，必然挤压 B 能力的空间。

能力互斥 — 有些能力本身就不能共存，选择强一致性就必然放弃可用性，选择高安全就必然增加复杂度。

任何提升都有代价，代价必须在设计阶段被显式接受，而非在故障后被动承受。

核心权衡维度

此处追求代价是典型场景
性能简单性、运维成本过度优化
强一致性可用性、响应时间CP 系统
水平扩展分布式复杂度分片、多副本
安全性开发效率、用户体验强鉴权
交付速度架构质量技术债

权衡判断框架

  1. **明确选择空间** — 有哪些选项？每个选项的能力边界在哪里？
  2. **评估每个选项的代价** — 获得什么能力？放弃什么能力？
  3. **确认代价承受者** — 代价由开发团队、运维团队还是用户承担？
  4. **判断选择可逆性** — 错了能改吗？改动的成本有多大？
  5. **设计验证计划** — 决策基于什么假设？如何验证假设是否成立？

反模式与常见误区

知道什么不该做，与知道什么该做同样重要。

反模式本质危险信号
银弹思维相信某方案能解决所有问题用同一技术套所有场景
过度设计为"未来可能"提前付出代价在解决不存在的问题
最小化陷阱用短期便利替代长期收益技术债只增不减
权威依赖因"大厂这样做"而忽视上下文问"XX怎么做"而非"我的约束是什么"
沉默的代价代价存在但从未被显式讨论没人能解释"为什么这样做"

系统设计能力的本质：不是知道多少种方案，而是知道在什么约束下放弃什么。

系统设计的演进视角

不同阶段的设计重点

阶段核心关注
小规模简单性、开发效率
中规模扩展性、可用性
大规模伸缩性、治理能力

演进原则

结语

系统设计不是一次性工作，而是伴随系统生命周期持续发生的决策过程。

优秀的系统设计，不在于一开始就"设计得多复杂"，而在于：

系统是否能够在不断变化的约束下，持续演进而不失控。

关联内容（自动生成）