架构

概述

软件架构（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 化

自动化运维与治理

演进式架构

云原生与服务网格

无服务器架构

安全与合规驱动的架构

智能化架构

架构作为组织能力

关联内容