架构

概述

软件架构（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 │          │Impl View│          │ Process │   └────┬────┘          └────┬────┘          └────┬────┘        ↑                    ↑                    ↑   开发人员创建            构建系统创建         运行组件描述   类/包 + 关系          模块(JAR/WAR)        进程 + IPC                        + 依赖关系                                               ┌────┴────┐                                               │ 部署视图 │                                               │Physical │                                               └────┬────┘                                                    ↑                                               机器 + 进程                                               网络连接

包含：

各类常见架构图

架构边界设计

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

边界管理的内容：

边界管理的价值：

边界划分的方式

过度设计 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、架构治理、质量保障体系。

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

架构治理

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

不治理的代价

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

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

架构治理的组成

常用治理机制

架构质量属性

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

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

架构的度量体系

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

代码结构度量

运行度量

架构可演进度量

架构技术债务

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

治理策略：

架构安全模型

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

架构的未来

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

云化与 XaaS 化

自动化运维与治理

演进式架构

云原生与服务网格

无服务器架构

安全与合规驱动的架构

智能化架构

架构作为组织能力

关联内容