架构

概述

软件架构（Software Architecture）是一种用来管理复杂性的工程学科，其目标是在软件系统漫长生命周期中，在有限条件下做最优权衡，构建、演进、运行并维护系统。它不仅满足非功能性需求（可维护性、可扩展性、可靠性、可测试性、可部署性），更承担沟通、决策、治理等组织层面的职能。

架构本质上是一组重要且难以逆转的设计决策，这些决策定义了系统的组织结构、组件及联系、行为协作、限制与约束，并指导系统的持续演化。架构作为团队协作的契约，约束不同模块/服务间的交互方式，使团队在系统演进过程保持一致性与可替换性。

架构的本质

架构的核心目标

在有限条件下做最优权衡，以最小成本完成系统长期构建与维护。

本质上解决两件事：

  1. **让系统能运转（行为价值）** — 满足当前业务需求
  2. **让系统能持续修改（架构价值）** — 适应未来的变化

架构价值的丧失，会导致系统不可维护、业务扩展受阻、组织效率下降。

架构的核心原则

它们都服务于同一个目标——降低变更成本。架构的本质是在漫长生命周期中管理变化，这些原则是管理变化的具体手段

策略与细节分离

软件可以抽象为两类内容：

保持边界，使细节的变化不影响策略，是"整洁架构""六边形架构""DDD"等架构风格的共同目标。

现实与目标的差距

上述描述是目标状态——好的架构应该策略稳定、细节灵活。但实际上：

这恰恰证明了架构设计的必要性——正是因为"细节难以替换"是现实，才更需要通过边界隔离、依赖反转、保持可选项等原则，让业务逻辑不依赖具体技术实现，从而降低系统生命周期中的变更成本。

架构核心要素

软件架构的核心要素构成系统的基础组织结构，是架构定义的最小完整集

组件（Component）

组件是软件系统的基本构建单元，具有以下特征：

特征 说明
语义完整性 语义完整、语法正确、有可重用价值
接口封装 通过接口提供数据转换，不暴露内部实现
外部属性 组件对其他组件承担的责任（提供的服务、所需服务、性能特征、错误处理、资源使用）

组件可嵌套组合：组件由更小的组件和接口构成，形成层次结构。

连接器（Connector）

连接器是组件间通讯、协调或合作的仲裁机制，是架构的核心黏合剂：

类型 示例
过程调用 同步/异步方法调用
消息传递 消息队列、事件总线
远程调用 RPC、gRPC
数据流 Pipe-Filter 模式中的数据管道

连接器将组件解耦，使组件可独立变更。

数据（Data）

数据是组件通过连接器接收或发送的信息元素：

数据与组件/连接器共同构成完整的架构结构。

接口（Interface）

接口是组件与连接器交互的契约，定义输入输出格式、调用协议和行为语义。

契约设计权衡：

契约类型 严格程度 适用场景
RPC（如 gRPC） 严格 内部服务、强类型语言
REST 中等 跨语言、开放API
事件驱动 宽松 异步、松耦合

约束（Constraint）

约束是架构决策的边界条件，包括技术约束、业务约束、组织约束和经济约束。

环境（Environment）

组件与环境的关系是架构定义的必要部分。环境包括外部系统、硬件/基础设施、用户/干系人，决定了架构的上下文和约束边界。

架构能力模型

从软件生命周期视角，架构的能力模型可分为以下六类：

为什么需要架构能力模型

没有模型指导时，架构设计容易顾此失彼——只看开发视图会导致部署困难，只看性能会丧失可维护性，只看当前会忽视未来变化。

能力模型的价值：

开发视图

关注团队结构、模块组织、代码可维护性。降低协作成本。

部署视图

关注系统如何构建、发布、扩容。降低发布成本。

运行视图

关注运行时行为。降低故障成本。

维护视图

关注问题诊断、变更成本、可观测性。降低诊断成本。

架构解耦体系

解耦是降低变更成本的核心手段——把变化锁在局部，不让它扩散到全局

解耦的维度

架构是可以"生长"的： 单体 → 可部署单元 → 微服务 → 服务网格

一个好的架构应该同时支持：

去冗余（重复识别）

分辨：

独立性

插件式架构思想

软件发展史，就是增加"可插拔点"的历史。插件的目标：

单向边界（依赖反转）

依赖方向应指向更稳定的方向——内层不依赖外层，外层依赖内层。

202002031612

架构分类

基础设施架构

中间件与数据架构

业务系统架构

随着技术发展，边界正不断融合与渗透。

架构视图体系

视图是表达架构的方式，不是架构本身。

架构图绘制的 4R 原则

4+1 视图

┌─────────────────────────────────────────────────────────┐
│                      场景 (Scenarios)                   │
│                    ┌─────────────────┐                  │
│                    │   验证与驱动     │                  │
│                    │   视图设计       │                  │
│                    └────────┬────────┘                  │
│         把视图串联在一起 ─────── ───────                  │
└─────────────────────────────────────────────────────────┘
        ↑                    ↑                    ↑
   ┌────┴────┐          ┌────┴────┐          ┌────┴────┐
   │ 逻辑视图 │          │ 开发视图 │          │ 进程视图 │
   │ Logical │          │ Dev View│          │ Process │
   └────┬────┘          └────┬────┘          └────┬────┘
        ↑                    ↑                    ↑
   最终用户/业务人员       开发人员/配置管理员    系统集成人员
   领域模型、职责         代码组织、分层依赖      线程、并发、同步
   接口契约                                     进程 + IPC
                                               ┌────┴────┐
                                               │ 物理视图 │
                                               │Physical │
                                               └────┬────┘
                                                    ↑
                                               系统工程师/运维
                                               机器、容器部署
                                               网络拓扑

各视图说明：

视图 别名 关注点 主要受众
逻辑视图 Logical View 功能需求、领域模型、接口契约 最终用户、业务人员
开发视图 Development View 代码组织、分层结构、模块依赖、构建配置 开发人员、配置管理员
进程视图 Process View 运行时行为、并发同步、通信机制 系统集成人员
物理视图 Physical View 硬件映射、分布式部署、网络拓扑 系统工程师、运维
场景视图 Scenarios View 用例、业务流程、视图串联验证 测试人员、分析师

各类常见架构图

架构边界设计

架构设计的核心是边界管理——把变化锁在边界内，让边界外不受影响。

边界管理的内容：

边界管理的价值：

边界划分的方式

过度设计 vs 不足设计

边界必须谨慎，过度设计常比不足更糟糕。

过度设计是用复杂性换取想象中的灵活性；不足设计是用今天的简单换明天的改动成本。

架构演进的规律是：演化式成长优于预判式设计。猜错边界的代价 >> 慢慢改的代价。代码可以删掉，概念和抽象删不掉。

架构演进

从后端视角来看，系统演进路径通常是：

  1. Mainframe
  2. 原始分布式
  3. 单体 Monolithic
  4. SOA
  5. 微服务 Microservices
  6. 服务网格 Service Mesh
  7. 无服务 Serverless

"微服务的价值不是细粒度，而是解耦与自治能力。"

架构认知流派

架构并非单一视角，而是多种思想共同构成的认知框架。不同流派从不同角度解释"什么是架构"，它们并非互斥，而是互补关系。理解这些流派有助于在复杂系统中选择更合适的架构方式。

层次 回答的问题 包括
架构定义流派 "架构是什么"的本体论 结构派、决策派
架构设计方法论 "如何做架构设计"的方法论 模式派、领域驱动派、进化派、系统论派、工程派

类比：定义流派像"哲学基本问题"，设计方法论像"解决问题的方法"。

结构派

关注系统由哪些模块组成，以及模块如何连接。

核心思想： 架构 = 组件 + 连接方式。

适用：系统建模、部署规划、宏观结构设计。

常见产物：分层架构、微服务架构图、C4 Model。

决策派

将架构视为一系列长期关键决策，这些决策决定了系统生命周期成本。

核心思想： 架构 = 重要且难以逆转的决策（Architecturally Significant Decisions）。

适用：架构评审、架构治理、技术选型、演进规划。

常见产物：ADR（Architecture Decision Record）、RAID Matrix。

模式派

通过复用经过验证的模式解决架构问题。

核心思想： 架构 = 上层设计模式（Architectural Patterns）。

典型模式：分层架构、事件驱动架构、CQRS、微内核、SOA。

适用：寻找通用解决方案、形成团队共识。

领域驱动派

以业务领域为中心组织系统结构，使软件与业务演进保持一致。

核心思想： 架构 = 领域边界 + 领域模型 + 上下文协作方式。

关键概念：限界上下文、上下文映射、核心域、策略建模。

适用：复杂业务系统、持续迭代系统、组织规模较大的团队。

进化派

关注架构的可变化性和演进能力，强调持续反馈与可替换性。

核心思想： 架构 = 支持持续变更的技术体系 + 演进机制。

原则：可测量、可演进、保持架构可选项（Fitness Function）。

适用：快速变化的业务环境、云原生体系、微服务系统。

系统论派

将软件视为复杂系统，通过系统动力学理解行为与结构。

核心思想： 架构 = 影响系统行为的结构性约束。

关注：反馈回路、瓶颈、边界、系统行为模式（如雪崩、拥塞）。

适用：大型分布式系统、复杂组织架构调整。

工程派

强调架构作为工程实践的综合体，包含流程、规范、工具链、治理。

核心思想： 架构 = 人、流程、工具的整体协作体系。

涉及：DevOps、CI/CD、架构治理、质量保障体系。

适用：中大型组织、要求高可靠性的行业。

架构反模式与误区

架构反模式是那些看似合理但会导致架构失败的常见错误。与架构模式相对，反模式揭示"如何不做"而非"如何做"。理解反模式是避免失败的前提。

决策类反模式

反模式 特征 危害
HiPPO 主导 个人（收入最高者）决定所有架构决策 决策反映个人偏见，团队不支持执行困难
功能驱动 架构由功能需求而非质量属性需求驱动 系统性能、扩展性、弹性不足
外包决策 将架构决策外包给供应商或顾问 丧失控制，不理解自身 QAR

核心问题： 架构决策必须由团队基于数据和论证做出，必须由 QAR（质量属性需求）驱动，必须理解每个决策的上下文和权衡。

复用类反模式

反模式 特征 危害
为复用牺牲质量 强行复用不匹配当前 QAR 的架构 被遗留技术限制，维护成本超过重新开发
复制成功架构 不理解上下文就复制大公司/文章的成功架构 忽略权衡差异，走上失败道路
框架控制架构 让框架的隐式决策接管应用 丧失底层理解，升级/替换困难

核心问题： 复用必须基于 QAR 匹配。复制架构必须理解其上下文和权衡。框架是工具，不是架构本身。

时间维度反模式

反模式 特征 危害
超前大架构 试图一次设计完美架构，预判所有变化 资源巨大，周期漫长，无法适应实际反馈
牺牲质量换速度 专注 MVP 忽视 MVA，"以后重构" 技术债务指数积累，重构成本远超预期
过度延迟交付 为完善架构不断推迟发布 缺乏实际反馈，延误业务价值

核心问题： 架构是持续过程，不是一次性事件。MVP 与 MVA 需要平衡。没有完美架构，只有基于当前信息的合理选择。

范围维度反模式

反模式 特征 危害
过度泛化 设计通用架构适配所有场景 臃肿无用，满足不了任何场景的真实 QAR
过度设计 用复杂性换想象中的灵活性 增加维护负担，延长开发周期
忽视边界 不考虑未来变化，"先用再说" 技术债务快速积累，变化成本指数增长

核心问题： 过度设计常比不足设计更糟糕。猜错边界的代价远大于慢慢改的代价。代码可以删掉，概念和抽象删不掉。

架构图绘制反模式

错误类型 问题
语义不清 形状/线条/颜色含义不明，无图例说明
层级混杂 运行时元素与静态元素混在同一图
信息过载 一张图试图表达所有内容
图文分离 依赖口头说明，图本身不自治

核心问题： 架构图必须自解释、一致、准确，与代码保持语义同步。自动生成与手动创建结合优于纯手动维护。

认知类反模式

反模式 问题
重结构轻决策 只关注组件和连接，忽视决策过程
架构即委员会 架构脱离开发，由委员会设计
文档至上 认为文档详细=架构好

核心原则： 架构是一系列重要且难以逆转的决策。文档和图不是架构，它们只是决策的载体。决策的质量和可见性才是核心。

架构原则应用误区

原则 常见误用 正确理解
KISS 简单优于一切 简单是手段；过度简单可能导致复杂性转移
DRY 绝对不能重复 有意重复 vs 无意重复；错误的抽象比重复更贵
演化 不做初始设计 初始设计必要；演化是持续改进，不是拒绝设计
合适 用成熟技术就好 匹配团队能力和 QAR；新技术需验证成本

避免反模式的核心原则

  1. **QAR 驱动** — 质量属性需求决定架构，非功能需求或业务压力
  2. **决策可见** — 隐式决策变显式，记录原因、权衡、替代方案
  3. **平衡权衡** — 无完美架构，只有特定上下文的最优选择
  4. **渐进演化** — 架构是持续活动，基于实际反馈迭代改进
  5. **团队共识** — 多元视角挑战假设，避免 HiPPO 和委员会两极
  6. **上下文匹配** — 复制必须理解上下文和权衡
  7. **验证优先** — 实际运行反馈优于理论评审
  8. **保持简单** — 在满足 QAR 前提下尽量简单

"好的判断来自经验，而经验大多来自糟糕的判断。" — 反模式的价值在于让人们不必亲自犯所有错误就能获得判断力。

架构治理

架构不仅是技术问题，更是治理问题。治理的目标是让架构在组织规模扩张过程保持一致性与可控性。

不治理的代价

架构决策会随时间失效，系统会腐化。没有治理的系统：

治理的本质是对抗组织熵增——把架构从"一次设计"变成"持续工程"，保护架构价值、延长系统寿命。

架构治理的组成

常用治理机制

架构质量属性

架构的优劣取决于其质量属性（NFR，而非功能需求）：

架构设计需基于关键质量属性进行技术选型与边界规划。

架构的度量体系

架构领域充斥大量主观判断，缺乏客观标准。为了减少架构的"玄学成分"，需要可量化的度量，把架构质量从感觉变为可衡量的数字：

代码结构度量

运行度量

架构可演进度量

架构技术债务

技术债务不可避免，但需要治理：

治理策略：

架构安全模型

架构必须内建安全，不可后补：

架构的未来

未来的软件架构将呈现以下趋势：

云化与 XaaS 化

自动化运维与治理

演进式架构

云原生与服务网格

无服务器架构

安全与合规驱动的架构

智能化架构

架构作为组织能力

关联内容