{"name":"系统设计","id":"软件工程-架构-系统设计-系统设计","content":"# 系统设计\n\n> **在约束条件下做架构决策，支撑系统持续演进的思维模型**。\n\n## 系统设计的本质\n\n### 什么是系统设计\n\n系统设计关注的是：\n\n* 系统要解决什么问题（目标）\n* 系统受到哪些不可违背的限制（约束）\n* 在约束下，如何做结构性选择（决策）\n* 这些选择最终塑造了系统的能力边界\n\n> **系统设计 = 约束下的架构决策过程**\n\n### 系统设计关注的不是\"功能\"，而是\"能力\"\n\n功能回答的是：\n\n* 系统\"能不能做某件事\"\n\n系统设计回答的是：\n\n* 系统\"在什么条件下、以什么代价、能做到什么程度\"\n\n因此，系统设计的核心关注点是：\n\n* 性能\n* 扩展性\n* 伸缩性\n* 可用性\n* 安全性\n* 可演进性\n\n这些被统称为：**系统的质量属性**。\n\n## 系统设计的六层认知模型\n\n```\n业务目标\n   ↓\n约束条件\n   ↓\n架构决策\n   ↓\n实现机制\n   ↓\n系统能力\n   ↓\n验证/演进\n```\n\n### 业务目标（Why）\n\n系统首先服务于业务目标，而不是技术理想。\n\n常见目标包括：\n\n* 用户规模增长\n* 成本可控\n* 响应时间要求\n* 合规与安全要求\n\n> 没有业务目标的系统设计，只是在堆复杂度。\n\n### 约束条件（Constraint）\n\n约束决定了设计空间的边界。\n\n常见约束包括：\n\n* 流量规模（用户量、QPS、数据量）\n* 延迟要求\n* 成本预算\n* 团队规模与技术能力\n* 法规与安全要求\n\n> **约束不是负担，而是设计的前提条件。**\n\n### 架构决策（Decision）\n\n系统设计的核心不是\"选什么技术\"，而是做出结构性决策，结构性决策定义了\"系统是什么形态\"：\n\n* 单体 vs 分布式\n* 同步 vs 异步\n* 强一致 vs 最终一致\n* 本地状态 vs 无状态\n* 预扩容 vs 弹性扩容\n\n每一个决策，本质上都是在约束条件下做取舍——用某些能力的损失换取其他能力的获得。\n\n### 系统能力（Outcome）\n\n设计决策最终沉淀为系统的能力边界：\n\n* 最大吞吐能力\n* 并发承载能力\n* 故障恢复能力\n* 安全防护能力\n* 架构演进空间\n\n### 实现机制（Implementation）\n\n设计决策需要落地为具体实现方案。\n\n关键实现要素：\n\n* **技术选型**：语言、框架、中间件、数据库等\n* **数据模型**：领域模型、存储结构、数据流设计\n* **接口设计**：API协议、通信方式、模块边界\n* **部署架构**：拓扑结构、容灾策略、伸缩机制\n\n> 实现层是\"决策\"转化为\"能力\"的桥梁，也是最容易引入复杂度的地方。\n\n### 验证/演进（Verification & Evolution）\n\n系统能力需要通过度量验证，并随业务演进。\n\n验证机制：\n\n* **SLA/SLO**：定义可度量的能力指标\n* **错误预算**：量化能力边界内的容错空间\n* **监控告警**：持续观测能力衰减\n\n演进机制：\n\n* **架构评审**：定期审视能力与业务匹配度\n* **技术债务**：识别能力演进障碍\n* **迭代计划**：规划能力演进路径\n\n> 缺乏验证的架构决策是无法迭代优化的赌博。\n\n## 系统设计方法论\n\n> **架构决策的结构化思考框架，而非具体技术方案**\n\n### 核心本质\n\n系统设计方法论回答一个根本问题：**如何在动手之前，先想清楚？**\n\n它的价值在于：避免凭感觉决策、避免遗漏关键要素、避免在错误的方向上走太远。\n\n### 三条元原则\n\n**合适原则** — 优秀架构是约束条件下的最优解，而非技术选型的最优解。大公司方案在小团队往往是灾难。\n\n> **何时不适用**：当合规要求、技术债临界点或组织惯性强制指定了某种方案时，\"合适\"需要重新定义。此刻的\"不合适\"可能源于历史包袱而非理性选择，此时的优先级是**识别约束的本质可塑性**，而非盲目顺从。\n\n**简单原则** — 复杂不会让系统更可靠，只会让它更难维护。简单方案和复杂方案都能满足时，选简单的。\n\n> **何时不适用**：高性能计算、硬实时系统、金融级一致性的场景中，适度复杂性是满足指标的代价。此刻的\"简单\"可能是性能或正确性的敌人，**简单原则让位于能力交付**。\n\n**演化原则** — 没有一步到位的架构。架构的生命力在于持续迭代，而非一步登天。\n\n> **何时不适用**：当系统核心抽象已经固化、上下游依赖已锁定、改造风险远大于收益时，激进重构是陷阱而非机会。此刻的\"演化\"应改为**局部优化与渐进改良**，而非推倒重来。\n\n### 四步法框架\n\n```\n识别复杂度 → 设计备选方案 → 评估选择 → 详细设计\n```\n\n**核心价值：避免在错误的复杂度上投入，以及在错误的方向上走太远。**\n\n| 步骤 | 目的 |\n|-----|------|\n| 识别复杂度 | 做对的事，而非做多的事 |\n| 设计备选方案 | 不把鸡蛋放一个篮子 |\n| 评估选择 | 用约束而非感觉决策 |\n| 详细设计 | 确保方案能落地 |\n\n#### 第一步：识别复杂度\n\n做什么：找出真正的能力缺口，而非功能需求。\n\n系统设计的起点不是\"要做什么功能\"，而是\"当前系统缺什么能力\"。\n\n| 类型 | 本质 |\n|------|------|\n| 高性能 | 单机瓶颈 vs 水平扩展能力 |\n| 高可用 | 故障容忍度与恢复速度 |\n| 可扩展 | 需求变化的响应成本 |\n\n关键：不是每个系统都需要高大全。识别出当前阶段下的1-2个主要矛盾即可。\n\n常见错误：用想象的需求替代实际需求，为\"未来可能\"提前买单。\n\n#### 第二步：设计备选方案\n\n做什么：设计3-5个有显著差异的方案。\n\n方案之间必须有架构级差异（如主备 vs 集群 vs 分片），而非细节差异（如检测周期1分钟 vs 5分钟）。\n\n关键约束：\n\n- 不要只设计一个方案\n- 不要设计太多\n- 不要只选熟悉的技术\n\n#### 第三步：评估和选择\n\n做什么：建立评估矩阵，从多维度权衡。\n\n核心维度：性能、可用性、硬件成本、项目投入、复杂度、可扩展性。\n\n选择原则：最简单优先、最合适优先、最熟悉优先。\n\n#### 第四步：详细设计\n\n做什么：将选定的方案落实到关键技术细节。\n\n确定：部署架构、配置参数、接口协议、数据模型。\n\n### 方法论检查清单\n\n| 阶段 | 自检问题 |\n|------|----------|\n| 开始前 | 真正的复杂度是什么？还是在解决假问题？ |\n| 备选方案 | 有没有明显差异的多个方案？ |\n| 评估选择 | 决策依据是什么？还是凭感觉选？ |\n| 详细设计 | 细节是否足以落地？ |\n\n### HLD/LLD 分层设计\n\n> **HLD 回答\"系统由什么构成\"，LLD 回答\"每个部分怎么实现\"。**\n\n#### 本质：分层的必要性\n\n系统设计天然分为两个层次：\n\n* **HLD（高层设计）**：从整体看系统，回答组件构成与关系\n* **LLD（低层设计）**：从局部看实现，回答每个组件内部怎么写\n\n分层是为了让不同角色、不同阶段关注不同层次的问题，避免认知过载。\n\n#### HLD：宏观架构\n\nHLD 是系统的\"航拍图\"——展示整体结构、主要组件及其交互关系，但不触及实现细节。\n\n| 要素 | 说明 |\n|------|------|\n| 系统架构 | 主要组件、组件间关系、部署结构 |\n| 服务划分 | 模块边界、职责定义、服务间接口 |\n| 数据流 | 模块间数据流动方向 |\n| 技术栈 | 框架、数据库、中间件选型 |\n| 约束权衡 | 性能、安全、成本的权衡决策 |\n\n**产出物**：架构图、服务/模块职责定义、API 接口概览、数据存储策略、关键设计决策。\n\n#### LLD：微观实现\n\nLLD 是 HLD 每个组件的\"施工图纸\"——细化到类、方法、算法、数据结构。\n\n| 要素 | 说明 |\n|------|------|\n| 类/模块设计 | 类图、方法签名、模块接口 |\n| 算法逻辑 | 关键算法的伪代码或流程 |\n| 数据结构 | 具体的数据 schema、索引 |\n| 错误处理 | 异常场景、边界条件 |\n\n**产出物**：类图与时序图、详细接口定义（请求/响应格式）、数据库表结构、单元测试计划。\n\n#### 关系对照\n\n| 维度 | HLD | LLD |\n|------|-----|-----|\n| 视角 | 整体 | 局部 |\n| 粒度 | 组件级 | 类/方法级 |\n| 关注 | 结构与关系 | 逻辑与实现 |\n| 指导 | 协调与评审 | 开发与测试 |\n| 产出 | 架构图 | 类图/时序图 |\n\n#### 常见问题\n\n| 问题 | 本质 |\n|------|------|\n| HLD 太粗 | 缺乏关键设计决策，只画方块图 |\n| HLD 太细 | 把 LLD 当 HLD 写，层次不清 |\n| LLD 缺失 | 开发人员自由度过大，偏离设计意图 |\n| 两者脱节 | HLD 描述的架构在 LLD 中未体现 |\n\n#### 判断要点\n\n* **HLD 不是越详细越好** — 细节是 LLD 的职责\n* **LLD 必须反映 HLD** — 每个 HLD 决策都应落实到 LLD\n* **分层是为了协作** — 不同角色在不同层次工作\n\n## 系统设计的权衡\n\n> **系统设计不只是计算 QPS 和画架构图，更重要的是在多重约束下做取舍。**\n\n### 权衡的第一性原理\n\n权衡之所以存在，两个根本原因：\n\n**资源有限** — 预算、人力、时间都是有限的，在有限资源下追求 A 能力，必然挤压 B 能力的空间。\n\n**能力互斥** — 有些能力本身就不能共存，选择强一致性就必然放弃可用性，选择高安全就必然增加复杂度。\n\n> **任何提升都有代价，代价必须在设计阶段被显式接受，而非在故障后被动承受。**\n\n### 核心权衡维度\n\n| 此处追求 | 代价是 | 典型场景 |\n|----------|--------|----------|\n| 性能 | 简单性、运维成本 | 过度优化 |\n| 强一致性 | 可用性、响应时间 | CP 系统 |\n| 水平扩展 | 分布式复杂度 | 分片、多副本 |\n| 安全性 | 开发效率、用户体验 | 强鉴权 |\n| 交付速度 | 架构质量 | 技术债 |\n\n### 权衡判断框架\n\n1. **明确选择空间** — 有哪些选项？每个选项的能力边界在哪里？\n2. **评估每个选项的代价** — 获得什么能力？放弃什么能力？\n3. **确认代价承受者** — 代价由开发团队、运维团队还是用户承担？\n4. **判断选择可逆性** — 错了能改吗？改动的成本有多大？\n5. **设计验证计划** — 决策基于什么假设？如何验证假设是否成立？\n\n## 反模式与常见误区\n\n> **知道什么不该做，与知道什么该做同样重要。**\n\n| 反模式 | 本质 | 危险信号 |\n|--------|------|----------|\n| 银弹思维 | 相信某方案能解决所有问题 | 用同一技术套所有场景 |\n| 过度设计 | 为\"未来可能\"提前付出代价 | 在解决不存在的问题 |\n| 最小化陷阱 | 用短期便利替代长期收益 | 技术债只增不减 |\n| 权威依赖 | 因\"大厂这样做\"而忽视上下文 | 问\"XX怎么做\"而非\"我的约束是什么\" |\n| 沉默的代价 | 代价存在但从未被显式讨论 | 没人能解释\"为什么这样做\" |\n\n**系统设计能力的本质**：不是知道多少种方案，而是**知道在什么约束下放弃什么**。\n\n## 系统设计的演进视角\n\n### 不同阶段的设计重点\n\n| 阶段  | 核心关注     |\n| --- | -------- |\n| 小规模 | 简单性、开发效率 |\n| 中规模 | 扩展性、可用性  |\n| 大规模 | 伸缩性、治理能力 |\n\n### 演进原则\n\n* 避免过度设计\n* 优先保留演进空间\n* 用约束驱动复杂度，而非预期\n\n## 结语\n\n系统设计不是一次性工作，而是伴随系统生命周期持续发生的决策过程。\n\n> **优秀的系统设计，不在于一开始就\"设计得多复杂\"，而在于：**\n>\n> **系统是否能够在不断变化的约束下，持续演进而不失控。**\n\n## 关联内容（自动生成）\n\n- [/软件工程/架构/系统设计/可用性.md](/软件工程/架构/系统设计/可用性.md) 系统核心质量属性之一，与约束条件和架构决策密切相关\n- [/软件工程/架构/系统设计/扩展性.md](/软件工程/架构/系统设计/扩展性.md) 系统核心质量属性，决定需求变化的响应成本\n- [/软件工程/架构/系统设计/伸缩性.md](/软件工程/架构/系统设计/伸缩性.md) 系统对短期负载变化的响应能力，是弹性设计的具体体现\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) 实现大规模系统的主流架构范式，涉及一致性与可用性的权衡\n- [/软件工程/架构/系统设计/高并发.md](/软件工程/架构/系统设计/高并发.md) 系统设计的重要实践场景，考验性能、扩展性、可用性的综合能力\n- [/软件工程/架构/系统设计/缓存.md](/软件工程/架构/系统设计/缓存.md) 提升系统性能和扩展性的关键技术手段\n- [/软件工程/架构/系统设计/流量控制.md](/软件工程/架构/系统设计/流量控制.md) 保障系统稳定性和可用性的核心机制，与约束条件直接相关\n- [/软件工程/架构/系统设计/可观测性.md](/软件工程/架构/系统设计/可观测性.md) 系统可维护、可演进的基础，支撑验证与演进阶段\n- [/软件工程/架构/架构.md](/软件工程/架构/架构.md) 系统设计的高级抽象，系统设计是架构设计的具体实现过程\n- [/软件工程/架构/架构思维.md](/软件工程/架构/架构思维.md) 系统设计的思维基础，指导在约束下做出架构决策\n- [/软件工程/架构/演进式架构.md](/软件工程/架构/演进式架构.md) 强调架构的持续演进能力，与系统设计的演化原则一致\n- [/软件工程/架构/架构治理.md](/软件工程/架构/架构治理.md) 确保架构决策有效执行，是系统设计落地的保障\n- [/软件工程/架构/系统设计/混沌工程.md](/软件工程/架构/系统设计/混沌工程.md) 主动验证系统韧性，是可用性设计的前置实践\n- [/软件工程/架构/架构重构.md](/软件工程/架构/架构重构.md) 系统持续演进的的重要手段，体现在变化中保持可控\n- [/软件工程/架构/技术选型.md](/软件工程/架构/技术选型.md) 实现机制的重要组成部分，决定技术栈与团队能力匹配","metadata":"tags: ['计算机系统', '软件工程', '安全']","hasMoreCommit":true,"totalCommits":17,"commitList":[{"date":"2026-04-13T15:33:49+08:00","author":"MY","message":"docs(architecture): 更新系统设计文档结构和内容","hash":"8e3c2d80aa2faba9a257e10b1d6efe0a3bb19aff"},{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2025-12-15T18:13:46+08:00","author":"MY","message":"docs(system-design): 重构系统设计文档，完善架构认知总纲与核心能力体系","hash":"9c8e9693a727c80aceb69501fda63c70a76fd3d5"},{"date":"2022-07-27T17:44:15+08:00","author":"cjiping","message":"➕新增 性能工程","hash":"ba2e39fccab7fbbbdbae982af1433f5fcde26ead"},{"date":"2022-06-01T16:30:01+08:00","author":"cjiping","message":"📦整理 网络安全","hash":"269283053fdd22fc22929e391e7b5476aad253a8"},{"date":"2021-12-20T16:04:24+08:00","author":"cjiping","message":"✏️更新 系统设计","hash":"eeca4458fbbeacb9b5c8d19a083d99b50a37aec7"},{"date":"2021-09-26T20:42:03+08:00","author":"My","message":"📦整理 系统设计 扩展性","hash":"5ae99401031a0ef46d4a8b20548534b94fa90626"},{"date":"2021-09-25T23:42:20+08:00","author":"My","message":"✏️更新 扩展性","hash":"129acb0bce0d7ffee5d87e160323a5e8dc93d75e"},{"date":"2020-09-28T19:11:11+08:00","author":"MY","message":"📦重构 可用性","hash":"8f48da37af67853f59063bdc9ce43e36bd7749a6"},{"date":"2020-09-27T20:35:01+08:00","author":"MY","message":"📦重构 高并发","hash":"31b657a7daf0652fff2d46a5483df43a52b76409"}],"createTime":"2020-03-16T21:05:42+08:00"}