{"name":"架构设计","id":"软件工程-架构-系统设计-架构设计","content":"# 架构设计\n\n## 架构设计的第一性原理\n\n### 软件架构为何存在：建筑没有的困境\n\n软件架构与建筑架构、城市规划等物理世界的架构有一个**根本性差异**：\n\n| 领域 | 完成后状态 | 变化特征 |\n|------|------------|----------|\n| 建筑架构 | 竣工后基本不变 | 以\"永恒\"为主题 |\n| 城市架构 | 演进缓慢，有实体约束 | 以\"规划\"调控变化 |\n| 软件架构 | 交付即意味着需求变化 | 以\"变化\"为主题 |\n\n建筑架构完成时，所有需求已知、约束固定。软件架构交付时，需求往往才开始涌现。这一现象的根源在于软件系统的本质：**软件是对现实世界问题域的符号化映射，而现实问题域本身在持续演化**。\n\n因此，软件架构存在的原因不是为了描述一个\"正确的结构\"，而是为了在**持续的变化压力**下，维持系统的**可控性**与**可演化性**。\n\n### 架构要解决的核心问题：有限理性下的适应性\n\n架构设计的根本驱动力来自人类面临的一个基本约束：**有限理性**（Bounded Rationality）。——我们无法在设计之初穷尽所有未来变化。\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\n1. **抽象复杂性**：识别系统\"难以改变的部分\"，形成稳定结构。\n2. **约束系统边界**：通过模型、原则、接口与契约保持系统可控。\n3. **降低长期成本**：让系统能在不推翻原有结构的情况下持续演进。\n\n因此，架构是一种 **约束 + 构造 + 演化** 的综合能力，而非对代码结构的静态描述。\n\n## 架构设计要素体系\n\n### 架构规划：战略层\n\n**目标：做正确的系统，而不是把系统做正确。**\n\n架构规划解决的问题：\n\n- 业务目标对系统的质量属性要求（性能、可用性、扩展性...）\n- 技术约束边界（预算、团队能力、时间窗口...）\n- 系统分解策略（模块划分、依赖关系、接口契约...）\n- 架构风险与应对预案\n- 技术债务管理策略\n\n**输出是可落地、可迭代的架构蓝图**，同时明确约束、边界和演进路线。\n\n### 架构分解：结构层\n\n通过\"分而治之\"将需求与复杂性拆解为可实现的模块。设计分解遵循三个原则：\n\n1. **分解粒度**：粒度越细成本越高，粒度越粗耦合越强，需要寻找\"认知分界\"。\n2. **稳定性中心化**：优先将不易改变的部分抽象出来（领域对象、契约、平台层）。\n3. **变化边界对齐**：分解边界应与需求变化频率对齐，频繁变化的部分应与稳定部分解耦。\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| 数据架构 | 数据组织存储 | 业务+应用架构 | ER图、存储策略 | 领域模型、分布策略 |\n| 技术架构 | 技术实现方案 | 应用+数据架构 | 技术选型、部署架构 | 合适优于先进 |\n\n**层间关系**：单向依赖，上层驱动下层；协同演进，保持一致性。\n\n**常见陷阱**：层间倒置（技术驱动业务）、层间越位（上层规定下层细节）、层内过度设计、层间不一致。\n\n### 架构输入：系统之\"约束空间\"\n\n架构的设计空间由以下四类输入共同定义：\n\n| 输入类型    | 内容            | 架构意义         |\n| ------- | ------------- | ------------ |\n| 功能性需求   | 系统做什么         | 确定功能性模型、边界   |\n| 非功能需求   | 性能、可用性、弹性、扩展性 | 驱动架构风格选择     |\n| 限制条件    | 团队、预算、法规、安全   | 决定可行空间       |\n| 现有资产与技术 | 存量系统、技术栈      | 决定系统兼容性与迁移成本 |\n\n架构的可行性由这些因素共同决定，而非单一技术选择。\n\n### 架构输出：系统蓝图体系\n\n结构化后的架构输出通常包含五类蓝图：\n\n1. **架构规划蓝图**：目标、范围、愿景、阶段路线图\n2. **研发设计蓝图**：架构模型、组件关系、契约、边界\n3. **测试蓝图**：验证策略、质量属性验证体系\n4. **部署蓝图**：物理拓扑、管控体系、发布策略\n5. **采购蓝图**：RFP、POC、技术决策依据\n\n## 架构设计原则\n\n### 合适优于先进\n\n过度追求先进技术会增加复杂性与不可控性。\n架构应追求**稳态、可解释性、与组织能力匹配**。\n\n### 简单优于复杂\n\n软件复杂度会自然增长，架构必须主动控制复杂性。\nKISS、YAGNI、最小可行结构（MVS）是核心方法。\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- 接口契约随时间发散，同一功能有多种实现方式\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## 架构设计方法论\n\n### 问题分类：架构设计的起点\n\n架构设计的第一个问题是\"问题是什么\"。**不同复杂度的问题需要不同程度的架构投入**。\n\n#### 四类问题与架构映射\n\n| 问题类型 | 特征 | 可预测性 | 架构投入 | 策略 |\n|----------|------|----------|----------|------|\n| **简单问题** | 有已知最佳实践 | 高 | 最小投入 | 复用模式 |\n| **繁杂问题** | 多种解，需分析比较 | 中 | 标准投入 | 多方案比较 |\n| **复杂问题** | 不确定，需验证假设 | 低 | 演化投入 | MVP验证+迭代 |\n| **混沌问题** | 失稳，因果不明 | 极低 | 敏捷试错 | 先止血后建模式 |\n\n#### 识别信号\n\n| 问题类型 | 典型信号 |\n|----------|----------|\n| 简单问题 | 需求明确有参照、团队有经验、技术栈成熟 |\n| 繁杂问题 | 边界清晰但路径不唯一、多质量属性权衡、多种选型 |\n| 复杂问题 | 无先例、假设未验证、需求在演进、需在实践中发现模式 |\n| 混沌问题 | 系统失稳、高压快节奏、因果关系不明 |\n\n#### 架构方法选择\n\n```\n简单问题 → 复用最佳实践\n繁杂问题 → 分析比较（建模→多方案→评估→决策）\n复杂问题 → 假设验证（MVP→反馈→演进）\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* 至少 3～5 个备选方案\n* 必须跨不同技术、不同结构风格\n* 强调差异性而非同质性\n\n归根结底，备选方案的价值不在于选择，而在于**扩展设计空间**。\n\n#### 认知锁定的后果\n\n认知锁定一旦发生，架构决策将面临：\n\n| 后果 | 具体表现 |\n|------|---------|\n| **路径依赖** | 后续决策围绕初始方案累积，形成结构刚性 |\n| **风险盲区** | 初始方案的缺陷在迭代中被忽视，直到暴露时已难修复 |\n| **团队失焦** | 架构讨论变成\"捍卫已有方案\"，而非\"寻找最优解\" |\n| **创新抑制** | 团队停止探索新方案，架构能力停止演进 |\n\n\n### 质量属性驱动的架构评估\n\n步骤：\n\n1. 列出关键质量属性（性能、可用性、扩展性、安全性…）\n2. 按业务阶段排序\n3. 对每个架构方案逐项评估其满足度\n4. 找到风险点、敏感点、折衷点\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* 数据单元（数据库、缓存、Stream）\n\n运行视图的重点不是图，而是：\n\n* 可观测性\n* 流量模型\n* 弹性与容量规划\n* 故障注入模型\n\n## 需求分析体系\n\n### 需求贯穿系统全生命周期\n\n需求是架构的约束来源，包括：\n\n* 功能性需求\n* 非功能需求（质量属性）\n* 限制条件（法律、安全、组织）\n* 假设与上下文（Context）\n\n### V-模型\n\nV模型的核心原理：**开发阶段与验证阶段存在镜像对称关系**。\n\n```\n定义系统（左侧）←→ 验证系统（右侧）\n```\n\n#### 核心原理\n\n| 原理 | 说明 |\n|------|------|\n| **对称性** | 开发与验证一一对应，左侧定义什么，右侧验证什么 |\n| **顺序性** | 验证方案在设计阶段确定，而非事后补救 |\n| **架构纽带** | 架构向上承接需求，向下指导实现，同时定义验证边界 |\n\n#### 适用边界\n\nV模型揭示的是**确定性**开发场景的规律：需求越明确、结构越稳定，对称性约束越有价值。\n\n在需求频繁变化的场景下，严格的对称性约束反而成为限制——这是V模型的局限，不是原理的局限。\n\n## 架构模型体系\n\n以下模型是架构师的基础建模工具：\n\n| 模型     | 目的          | 适用阶段  |\n| ------ | ----------- | ----- |\n| 用例模型   | 描述用户价值和系统能力 | 分析    |\n| 领域模型   | 识别业务不变性     | 架构    |\n| 鲁棒图    | 用例到对象模型的桥梁  | 分析→设计 |\n| 时序图    | 描述行为流程      | 设计    |\n| ER 图   | 数据建模        | 数据架构  |\n| 整体架构草图 | 快速表达结构      | 架构    |\n\n## 架构治理与演进\n\n真正的架构价值不在于设计，而在于**让系统可持续演进**：\n\n关键治理能力：\n\n1. **统一的模型语言**\n2. **标准化边界定义**\n3. **技术雷达与演进策略**\n4. **质量属性监控与反馈**\n5. **架构决策记录（ADR）**\n6. **组合式能力的可演化性**\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**陷阱二：低复杂度假设与业务增长不匹配**\n\n系统边界随业务扩张突破原有假设，架构债在临界点集中爆发。\n\n### 判断框架：架构投入参考矩阵\n\n| 系统特征 | 预期生命周期短 | 预期生命周期长 |\n|----------|--------------|--------------|\n| 需求稳定 | 低架构投入 | 标准架构流程 |\n| 需求不确定 | 最小可行架构 + 迭代验证 | 敏捷架构 + 持续演进 |\n| 团队小 | 轻量文档 | 架构可视化 |\n| 多团队协作 | 强接口契约 + 治理 | 完整架构流程 + ADR |\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) 数据库中间件是解决数据扩展性问题的重要架构组件，是架构设计中数据层扩展策略的重要实现方式\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","metadata":"tags: ['计算机系统', '软件工程']","hasMoreCommit":true,"totalCommits":13,"commitList":[{"date":"2026-03-27T17:11:33+08:00","author":"MY","message":"docs(architecture): 重构架构设计文档并完善理论体系","hash":"da32c502b86750804f1c545707c86574f8825637"},{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2025-12-09T11:40:31+08:00","author":"MY","message":"docs(architecture): 重构架构设计文档，优化结构与内容表述","hash":"e7c31ffae68504aa94a6e99f3532c8a15d4a100c"},{"date":"2022-05-11T15:01:31+08:00","author":"cjiping","message":"✏️更新 架构","hash":"afb18fe967347f815b204ee9dec1c48fcd250b35"},{"date":"2022-05-05T17:38:27+08:00","author":"cjiping","message":"✏️更新 架构设计","hash":"7c9964f93906147a0d6f1185e359b13d011499ce"},{"date":"2022-05-04T23:12:11+08:00","author":"MY","message":"✏️更新 架构设计","hash":"15b035e289fad871e88c9924cc8aa328ea17c27b"},{"date":"2021-10-21T23:31:38+08:00","author":"My","message":"✏️更新 监控与可用性","hash":"7f0a843cb3614c331efd4e850f8657f0b14880cd"},{"date":"2021-10-17T23:19:31+08:00","author":"My","message":"✏️更新 架构设计","hash":"b71ac55d132dbce81725cc8abc041718148d79dc"},{"date":"2021-10-12T22:11:00+08:00","author":"My","message":"✏️更新 架构设计","hash":"a70aa0f0c26d82819bd74a475dc228a8906f47f9"},{"date":"2021-10-04T16:03:48+08:00","author":"My","message":"✏️更新 架构设计","hash":"f790427c7c64de61ecbdbf09fb98de80080a8831"}],"createTime":"2021-09-29T21:31:19+08:00"}