知识花园

最近更新

架构 MOC

26分钟阅读

架构

在开发大型软件或进行团队协作时，我们不可能也不需要去发明一种全新的范式。计算机科学领域在过去五十年里已经沉淀了大量经过无数团队生产验证的工程智慧——REST 设计原则、领域驱动设计、SRE 方法论、Team Topologies、持续交付。把这些成熟范式实践好，本身就是一种极高效的工作方式。

架构分三条线，各占约三分之一：

  • 技术线：面向系统的技术架构范式。API 设计、微服务、云原生、基础设施即代码、安全架构——以社区主流标准为准，减少主观判断，追求一致性与可重复性。
  • 业务线：面向业务复杂度的架构范式。DDD、事件驱动、SRE、可观测性——精简干练，经得起时间考验。
  • 协作线：面向团队效能的工程实践。版本控制工作流、CI/CD、代码审查文化、团队拓扑——工程效能的提升不只是工具，更是实践与文化。

每条线的比例：60% 核心范式（主流、成熟、普适）+ 40% 前沿探索（AI 等新范式，持续迭代）。

一、目录

本系列共 24 篇文章，沿三条线展开：技术线（系统架构范式）、业务线（业务复杂度方法论）、协作线（团队工程实践）。每条线各含 60% 核心范式 + 40% 前沿探索。

50-architecture/
├── 00-architecture-MOC.md                                     ← 本文件
│
├── 10-tech/                                                   # 技术线（面向系统）
│   ├── 01-API 设计：REST、GraphQL 与 gRPC 的原则与选型.md      ← 资源建模 / HTTP 语义 / 三者选型框架
│   ├── 02-微服务设计：服务边界、契约与治理.md                 ← 服务边界 / 契约测试 / 分布式陷阱
│   ├── 03-云原生架构：容器化、Kubernetes 与 Serverless.md    ← 十二要素 / K8s 抽象 / 决策框架
│   ├── 04-IaC：Terraform 与配置管理.md                       ← 状态管理 / GitOps 结合 / 漂移检测
│   ├── 05-安全架构：零信任、身份认证与 Secret 管理.md        ← BeyondCorp / OAuth / Vault
│   ├── 06-Platform Engineering：内部开发者平台与黄金路径.md  ← IDP / Backstage / 平台产品思维
│   └── 07-AI 工程化：LLM 在生产环境的集成模式.md              ← Prompt 管理 / 流式输出 / Evals
│
├── 20-business/                                               # 业务线（面向业务复杂度）
│   ├── 08-软件架构范式：从分层到事件驱动.md                  ← 六边形 / 事件驱动 / 架构风格选型
│   ├── 09-DDD：业务复杂度的工程解法.md                       ← 通用语言 / 限界上下文 / 聚合根
│   ├── 10-系统设计方法论：C4 模型与 ADR.md                   ← C4 四层 / ADR 写法 / 架构 Review
│   ├── 11-SRE 与可靠性工程：SLO、错误预算与事故管理.md       ← SLI·SLO / Toil / Postmortem
│   ├── 12-可观测性架构：Metrics、Logs、Traces 与 OTel.md     ← 三支柱分工 / 告警信噪比 / DORA
│   ├── 13-数据流与事件架构：消息队列、CQRS 与事件溯源.md     ← Kafka 选型 / CQRS / Saga Pattern
│   ├── 14-AI 架构模式：RAG、Agent 与生产化设计.md            ← RAG 标准架构 / Agent 工具调用 / 评估
│   └── 15-FinOps：云成本的可见性与优化.md                    ← 成本归因 / Reserved vs Spot / 异常告警
│
└── 30-collaboration/                                          # 协作线（面向团队效能）
    ├── 16-版本控制工作流：Trunk-Based Development 与 GitFlow.md  ← 两种模型对比 / 工作流选型
    ├── 17-提交规范与变更管理：Conventional Commits.md        ← 语义化版本 / 自动 Changelog
    ├── 18-CI·CD 与发布工程：流水线设计与 GitOps.md           ← 蓝绿·金丝雀 / ArgoCD / DORA
    ├── 19-代码审查：PR 文化与高质量 Code Review.md           ← 审查目的 / PR 大小原则 / 自动化分工
    ├── 20-工程文档体系：README、ADR、Runbook 与 RFC.md       ← 文档即代码 / 不同文档受众
    ├── 21-敏捷工程实践：Scrum、Kanban 与 XP.md               ← 敏捷价值观 / XP 工程实践 / 技术债
    ├── 22-团队拓扑：组织结构与软件架构的协同设计.md          ← 四种团队类型 / Conway 逆用
    ├── 23-技术债管理：识别、量化与系统性偿还.md              ← 热点分析 / 重构安全网 / 决策机制
    ├── 24-工程文化：心理安全、无责归因与持续改进.md          ← 心理安全 / Blameless Culture
    └── 25-AI 辅助工程：工具链整合与最佳实践.md               ← Copilot·Cursor / 工作流整合

概念线索

线索一：范式优于原创，站在巨人肩上

Google 的 SRE 方法论、Eric Evans 的 DDD、Team Topologies——这些不是学术理论，是无数工程团队用血泪总结出来的经验结晶。遇到问题先问”有没有已验证的范式”，往往比从零发明效率高一个数量级。这个系列的核心任务，是把这些范式理解清楚、内化、并知道在什么场景下用哪个。

贯穿文章：业务线/软件架构范式 → 业务线/DDD → 技术线/微服务设计 → 协作线/团队拓扑

线索二：Conway 定律——组织结构决定系统架构

Mel Conway 在 1967 年观察到：系统的架构倾向于镜像设计该系统的组织的沟通结构。 这不是警告，是工具——微服务的服务边界应该和团队边界对齐；DDD 的限界上下文应该和组织结构对话；Team Topologies 正是反向利用这个定律，通过设计团队结构来驱动架构演进。理解 Conway 定律，才能理解为什么微服务不只是技术决策，更是组织决策。

贯穿文章：技术线/微服务设计 → 业务线/DDD → 协作线/团队拓扑

线索三：架构决策要记录，让”为什么”穿越时间

为什么选 gRPC 而不是 REST？为什么放弃微服务回归单体？为什么用 Kafka 而不是 RabbitMQ？这些决策在做的时候清晰，半年后新人加入或你自己也忘了当时的约束条件。ADR（Architecture Decision Record）是让决策上下文可以穿越时间的工具。 好的架构不是最聪明的设计，是最有文档的设计。

贯穿文章：业务线/系统设计方法论 ADR → 协作线/工程文档体系 → 技术线/API 设计

线索四：可观测性是三条线的交汇点

技术线需要可观测性保证系统运行状态（Metrics/Logs/Traces）；业务线用可观测性验证架构决策效果（SLO 达成率、错误预算）；协作线用可观测性衡量工程效能（DORA 四项指标：部署频率/变更失败率/恢复时间/交付周期）。你无法管理你无法观测的东西——这对系统成立，对团队也成立。

贯穿文章：业务线/可观测性架构 → 业务线/SRE 与可靠性工程 → 协作线/CI/CD 与发布工程

线索五：标准化是规模化协作的基础

一个人做项目，工作流随意；十人团队，不统一就是熵增。Conventional Commits 不是格式洁癖，是让 Changelog 自动生成、语义化版本自动递增的基础；Trunk-Based Development 不是 Git 偏好，是让持续集成真正”持续”的前提；Team Topologies 的平台团队不是官僚机构，是减少其他团队认知负担的基础设施。标准化把”每次都要想”变成”不用想”，释放认知带宽做真正有价值的事。

贯穿文章：协作线/版本控制工作流 → 协作线/提交规范与变更管理 → 协作线/CI/CD 与发布工程

技术线

面向系统的技术架构范式，以社区主流标准为准。

核心范式（60%）

  • 技术线/API 设计：REST、GraphQL 与 gRPC 的原则与选型 REST 的核心约束（无状态、统一接口、资源建模），URI 设计与 HTTP 语义，状态码与错误处理，版本管理策略，GraphQL 的适用场景（前端驱动、灵活查询）与缺陷（N+1、缓存困难），gRPC 的适用场景（微服务内部 RPC、强类型契约），三者选型的决策框架

  • 技术线/微服务设计：服务边界、契约与治理 微服务 vs 单体的选型本质（组织规模、团队自治度、部署独立性），服务边界的划定原则（与 DDD 限界上下文的对应），API 契约设计（契约测试：Consumer-Driven Contracts），服务发现与注册，Circuit Breaker 与 Bulkhead 模式，服务网格（Istio/Envoy）的职责，分布式系统的常见陷阱（分布式单体、过度拆分）

  • 技术线/云原生架构：容器化、Kubernetes 与 Serverless 云原生的十二要素（The Twelve-Factor App），容器化的架构含义（不可变基础设施），Kubernetes 的核心抽象（Pod/Deployment/Service/Ingress），Serverless 的设计哲学与冷启动代价，多云策略的利弊，云原生架构的决策框架

  • 技术线/基础设施即代码（IaC）：Terraform 与配置管理 IaC 的核心价值（可重复、可审计、可版本化的基础设施），Terraform 的状态管理与模块化，声明式 vs 命令式（Ansible vs Terraform），GitOps 与 IaC 的结合，Drift Detection（配置漂移检测），IaC 的测试策略

  • 技术线/安全架构：零信任、身份认证与 Secret 管理 零信任的工程实现（BeyondCorp 模型），OAuth 2.0 / OIDC 协议与适用场景，JWT 的正确使用与常见错误，Secret 的生命周期管理（Vault / AWS Secrets Manager），最小权限原则的系统化实施，RBAC vs ABAC，供应链安全（SBOM、依赖扫描）

前沿探索（40%）

  • 技术线/Platform Engineering：内部开发者平台与黄金路径 Platform Engineering 是 DevOps 的下一个阶段，核心目标是降低开发者认知负担，Internal Developer Platform（IDP）的能力模型（Self-service、Golden Path、可观测性集成），Backstage 作为开发者门户，Platform Team 的产品思维，与 DevOps 文化的关系

  • 技术线/AI 工程化：LLM 在生产环境的集成模式 LLM API 的集成架构（Prompt Management、上下文窗口管理），流式输出的工程实现，多模型路由与 Fallback 策略，成本估算与限流设计，LLM 的可观测性（Prompt 日志、延迟、Token 消耗），Prompt Injection 防护，评估（Evals）的工程化

业务线

面向业务复杂度的架构范式，精简干练，经得起时间考验。

核心范式（60%）

  • 业务线/软件架构范式：从分层到事件驱动 分层架构（三层/六边形/洋葱/整洁架构）的演进脉络，微服务的前提条件（不是银弹），事件驱动架构（EDA）的优势与复杂度，Strangler Fig Pattern（渐进式现代化遗留系统），单体何时优于微服务，架构风格选择的决策框架

  • 业务线/领域驱动设计（DDD）：业务复杂度的工程解法 通用语言（Ubiquitous Language）的价值，限界上下文（Bounded Context）的划定，聚合根（Aggregate Root）的设计原则，领域事件作为系统边界的通信方式，战略设计（上下文映射）vs 战术设计（实体/值对象/仓储），DDD 与微服务边界的对应关系，DDD 的适用场景与过度使用的问题

  • 业务线/系统设计方法论：C4 模型与架构决策记录（ADR） C4 模型的四个层次（Context/Container/Component/Code）与各层的受众，什么时候画什么图，Architecture Decision Record 的格式与写作原则，记录”为什么”而不是”是什么”，Architecture Review 流程，技术 RFC 的写作

  • 业务线/SRE 与可靠性工程：SLO、错误预算与事故管理 SRE 的核心思想（用软件工程方法解决运维问题），SLI/SLO/SLA 的定义与设计方法，错误预算的使用逻辑（可靠性与功能迭代速度的动态平衡），Toil 的识别与系统性自动化，事故管理生命周期，无责 Postmortem 文化，MTTR vs MTBF

  • 业务线/可观测性架构：Metrics、Logs、Traces 与 OpenTelemetry 可观测性三大支柱的分工与关系，OpenTelemetry 作为统一标准的意义，Prometheus + Grafana（指标体系），结构化日志（JSON Logging + ELK/Loki），分布式链路追踪（Jaeger/Zipkin），告警设计（信噪比是核心问题），DORA 指标作为工程效能的可观测性

  • 业务线/数据流与事件架构：消息队列、CQRS 与事件溯源 消息队列的三个核心价值（解耦/异步/削峰），Kafka vs RabbitMQ vs Redis Streams 的选型，CQRS（命令查询责任分离）的设计动机与实现模式，Event Sourcing 的原理与真实代价，Outbox Pattern（解决分布式事务的双写问题），Saga Pattern（分布式长事务的编排与协调）

前沿探索（40%）

  • 业务线/AI 架构模式：RAG、Agent 与生产化设计 RAG（Retrieval-Augmented Generation）的标准架构，Embedding + 向量数据库 + LLM 的协作模式，Agent 系统的工具调用模式（ReAct/Function Calling），Multi-Agent 的协调机制，生产环境中的可靠性挑战（幻觉率、延迟 P99、成本控制），LLM 应用的评估框架

  • 业务线/FinOps：云成本的可见性与优化 FinOps 三个成熟阶段（告知/优化/运营），成本归因的标签策略（按团队/服务/环境），Reserved Instance vs Spot vs On-Demand 的使用逻辑，Right-sizing 分析方法，成本异常告警设计，FinOps 团队的职责定位

协作线

面向团队效能的工程实践，工程效能的提升是实践与文化的结合。

核心范式（60%）

  • 协作线/版本控制工作流：Trunk-Based Development 与 GitFlow 两种工作流的核心差异（Trunk-Based：持续集成优先；GitFlow：发布管理优先），Trunk-Based Development 的配套实践（Feature Flag、小提交、全覆盖的 CI），GitHub Flow 作为中间路线，分支寿命的工程含义（长生命周期分支 = 集成风险），如何根据团队和产品节奏选择工作流

  • 协作线/提交规范与变更管理：Conventional Commits 与语义化版本 Conventional Commits 作为社区标准（feat/fix/docs/chore/BREAKING CHANGE），结构化提交的下游价值（自动 Changelog、语义化版本递增、PR 分类），Semantic Versioning（MAJOR.MINOR.PATCH）的含义，Monorepo 下的版本管理策略，提交粒度的工程原则（原子提交 vs 功能提交）

  • 协作线/CI/CD 与发布工程：流水线设计与 GitOps 持续集成的核心价值（快速失败、小批量变更），流水线设计原则（快速反馈、安全左移），发布策略对比（蓝绿部署/金丝雀/Feature Flag），GitOps 的核心思想（Git 作为单一可信来源），Argo CD / Flux 的工作原理，部署频率与变更风险的工程权衡，Dora 指标作为流水线健康度量

  • 协作线/代码审查：PR 文化与高质量 Code Review Code Review 的核心目的（知识共享 > 发现缺陷），高质量 Review 的实践（作者责任、Reviewer 视角、异步沟通礼仪），PR 大小的工程原则（小 PR 是最有效的 Code Review 优化），自动化检查 vs 人工审查的职责划分，Code Review 文化的建设，Pair Programming 作为同步 Review

  • 协作线/工程文档体系：README、ADR、Runbook 与 RFC 不同文档类型的受众与目的：README（用户/开发者快速上手）、ADR（决策记录）、Runbook（操作手册）、RFC（变更提案），文档即代码（Docs as Code）的工程实践，技术写作的核心原则（清晰 > 聪明），文档腐烂的根因与对策，好文档的可维护性设计

  • 协作线/敏捷工程实践：Scrum、Kanban 与 XP 敏捷宣言的工程解读（不是流程，是价值观），Scrum 的核心仪式与真正目的，Kanban 的可视化与 WIP 限制，极限编程（XP）的工程实践（TDD/结对编程/持续集成/重构），估点的局限性，速度 vs 吞吐量，技术实践是敏捷的基础（没有 CI/CD 的 Scrum 只是开会）

  • 协作线/团队拓扑：组织结构与软件架构的协同设计 Team Topologies 的四种团队类型（Stream-aligned/Platform/Enabling/Complicated-subsystem），三种交互模式（Collaboration/X-as-a-Service/Facilitating），Conway 定律的反向利用（通过设计团队结构来驱动架构演进），认知负载作为团队设计的核心约束，平台团队的产品思维，从组织结构读懂系统架构

  • 协作线/技术债管理：识别、量化与系统性偿还 技术债的分类（有意识 vs 无意识；谨慎 vs 粗心），Ward Cunningham 的原意，技术债的量化方法（代码热点分析、复杂度指标），纳入迭代的策略（20% 时间原则），重构的安全网（测试覆盖率），Boy Scout Rule，技术债委员会的决策机制

  • 协作线/工程文化：心理安全、无责归因与持续改进 心理安全（Psychological Safety）作为高绩效团队的基础（Google Project Aristotle），无责 Postmortem 的价值与实施，成长型思维 vs 固定型思维在工程团队的表现，技术分享文化的建立，Blameless Culture 与工程问责的边界，如何在团队中推广工程实践（影响力而非权力）

前沿探索（40%）

  • 协作线/AI 辅助工程：工具链整合与最佳实践 GitHub Copilot / Cursor / Claude Code 等工具的工作流整合，AI 辅助代码审查的定位与局限，AI 生成代码的测试责任，提示工程在工程任务中的应用（测试生成/文档生成/重构），对初级工程师成长路径的影响，团队采用 AI 工具的节奏与风险，AI 工具的评估框架

阅读路径

路径一：启动一个新项目/团队

协作线/版本控制工作流（选定工作流）
  → 协作线/提交规范与变更管理
  → 协作线/CI/CD 与发布工程（建立流水线）
  → 技术线/API 设计（定义接口契约）
  → 协作线/工程文档体系（README + ADR）

路径二：系统架构设计

业务线/软件架构范式（选择架构风格）
  → 业务线/DDD（划定服务边界）
  → 技术线/微服务设计（服务治理）
  → 业务线/系统设计方法论（记录决策 ADR）
  → 技术线/安全架构（安全内嵌）

路径三：提升工程效能

业务线/SRE 与可靠性工程
  → 业务线/可观测性架构（DORA 指标）
  → 协作线/CI/CD 与发布工程
  → 协作线/代码审查（PR 文化）
  → 技术线/Platform Engineering（前沿）

路径四：团队与组织设计

协作线/团队拓扑（Conway 定律的应用）
  → 业务线/DDD（边界与团队的对应）
  → 技术线/微服务设计（服务边界）
  → 协作线/工程文化
  → 协作线/敏捷工程实践

路径五：AI 时代的架构与工程

业务线/AI 架构模式（RAG/Agent）
  → 技术线/AI 工程化（LLM 集成）
  → 协作线/AI 辅助工程（工具链）
  → 业务线/FinOps（AI 调用成本）

与其他系列的关联

  • 编程语言与软件构造 MOC — 架构是代码的组织方式；设计模式、API 设计、测试策略是编程能力向系统层的延伸
  • 计算理论与算法 MOC — 复杂度分析（时间/空间、P/NP）是架构选型和缓存策略的判断工具
  • Linux 系统 MOC — 技术线/云原生架构和 IaC 的底层操作系统基础
  • 计算机网络 MOC — 技术线/安全架构（TLS/零信任）与技术线/微服务（服务网格）的网络基础
  • 存储系统 MOC — 业务线/数据流架构（事件存储、消息队列持久化）的底层支撑
  • 数据系统 MOC — 业务线/数据流架构（CQRS/Event Sourcing）的数据库层实现，业务线/AI 架构（向量数据库）
  • 云原生与平台工程 MOC — 架构设计（微服务/事件驱动）最终通过 K8s 和 GitOps 交付；分布式系统理论在云原生上落地
  • 可观测性与运维工程 MOC — SLO 是架构质量属性（可靠性）的运行时度量；架构决策影响可观测性代价
  • 安全工程 MOC — 协作线/安全架构（零信任、威胁建模）是架构设计不可缺少的安全维度

暂存内容

以下目录为原有笔记，内容可作为参考养料，新架构不强制复用：

  • 10-it-governance/ — 企业命名规范与域名分配（过于场景化，作为参考）
  • 50-api-and-integration/ — API 设计笔记（部分内容纳入技术线/API 设计）
  • 70-engineering-writing/ — README 与注释规范（部分内容纳入协作线/工程文档体系）
  • 80-engineering-governance/ — Git 策略与 Commit 规范（部分内容纳入协作线相关文章）

关系图谱

反向链接