架构

定义

软件架构有时也称软件体系结构，指的是软件系统的基本组织方式。按国际标准化组织与国际电工委员会联合发布的系统与软件工程标准中的表述，它由系统的组成部分、这些部分彼此的关系及与环境的关系，以及指导其设计与演进的原理共同构成^[1]。同一标准体系还把架构描述与架构视图区分开来，架构描述是表达架构的工作产物，而架构视图则从某个特定视角呈现系统^[2]。

有研究者从要素角度归纳，认为架构由三部分构成：职责明确的模块或组件、组件之间明确的关联关系，以及约束和指导原则^[3]。另有观点把架构视为对系统中实体及实体之间关系的抽象描述，是在需求与代码之间建立对应关系的中间层^[4]。在早期的经典模型中，架构被概括为构件、连接件与约束三者的组合，构件可以是程序模块，连接件可以是过程调用或远程调用，约束则规定构件连接的形式与条件^[5]。

需要区分几个相邻概念。模块是逻辑拆分的结果，组件是物理拆分的结果，划分模块主要为了职责分离，划分组件主要为了单元复用；框架是组件实现的规范，架构则是结构本身^[6]。架构的关注点在于系统由哪些部分组成、这些部分如何协作实现业务请求，以及用什么规范保证其有序运行^[7]。

原理

架构设计的核心工作是把系统按某种原则切分，再把切分后的部分通过明确的接口连接起来。切分的依据通常是与业务能力和技术职责相对应的边界，切分的目的是让不同角色能够并行工作。在分层架构中，系统被划分为若干层，每层只承担特定角色，层与层之间通过软件接口通信。以移动操作系统为例，其软件栈常被分为应用程序层、应用程序框架层、运行时与系统库、内核层四层，上层通过框架层提供的编程接口调用下层能力^[8]。这种做法的用意是实现关注点分离，使层内部的变化尽量不外溢到其他层。

从依赖方向看，分层架构的关键在于管理依赖，只允许相邻层或由外层向内层调用。整洁架构进一步把依赖方向固定为由外向内：最内层是实体与领域模型，中层是用例与应用服务，外层是接口适配器，最外层是框架与驱动，业务逻辑不依赖具体框架与数据库^[9]。

架构常借助多个视角来描述。克鲁chten 在 1995 年提出的 4+1 视图模型包含逻辑视图、进程视图、开发视图、物理视图，并以场景（用例）把四者串起来^[2]。逻辑视图描述软件实现层面的组件与类及其关系，进程视图关注并发、分布与容错，开发视图关注开发环境中的代码组织，物理视图把可执行软件映射到硬件节点上，用于处理可用性、可靠性与吞吐量等非功能要求^[2]。

架构模式则是可复用的解法。分层架构把表现层、业务层与数据访问层横向分开；客户端-服务器架构由客户端发起请求、服务器处理并返回结果，两者通常运行在不同硬件上并经网络通信；事件驱动架构由事件生成者与事件接收者组成，接收方在事件发生后作出响应，适合不可预测、异步的环境^[1]。微服务架构则把一个应用拆成一组小型服务，每个服务运行在独立进程中，通过轻量级机制（通常是 HTTP 资源接口）通信，并可以独立部署^[10]。

发展历程

软件架构作为一个独立议题，与软件规模的扩大同步出现。1968 年，迪杰斯特拉在多道程序设计系统中提出软件工程概念，并展示了一种支持可测性的分层软件结构，把软件质量与结构安排联系起来^[1]。此后约 20 年，肖提出了不同的架构风格，指出主要子系统的基本性质及其相互作用方式需要新的抽象来涵盖，并以黑板模型说明专家协作求解问题的组织方式^[1]。

20 世纪 70 至 80 年代，编程范式与结构组织方式相继成型：1979 年出现 MVC 模式，把模型、视图与控制器分开；80 年代面向对象编程推广，两层结构把用户界面与业务逻辑、数据存储分离^[3]。1995 年，克鲁chten 提出 4+1 视图模型，为从多个角度描述架构提供了通用做法^[2]。

标准化工作随后跟进。ANSI/IEEE 610.12-1990 从构件、构件之间及构件与环境之间的关系出发界定体系结构，并纳入指导其设计与演化的原理^[5]。此后 ISO/IEC 42010 系列标准对架构描述、利益相关方关注点、视点与视图等概念作出规定，成为架构描述的通用框架^[11]。

互联网业务规模扩大后，架构重心从单机内的分层转向分布式组织。以单体形式部署的应用在代码量增长后出现模块边界模糊、部署频率低、扩展只能整体进行等问题，微服务架构随之兴起，其起源可追溯到 2000 年前后，并随云计算与虚拟化技术发展而普及。六边形架构（又称端口与适配器架构）等强调边界与可替换性的方案也在此期间提出。

应用

在移动操作系统与嵌入式设备中，架构决定了软件栈的分层方式和模块归属。以分层方式组织的系统把应用、框架、运行时与内核分层放置，新增功能通常以模块形式挂接到框架层，从而避免改动底层^[8]。

在企业应用与工业软件中，架构模式按场景选择。工业软件系统常见客户端-服务器架构、事件驱动架构、多层架构与数据中心架构，其中事件驱动方式被用于在结构松散的软硬件组件之间传递事件，以提高响应能力^[1]。互联网业务则多按业务能力把系统拆成用户、订单、支付、调度等服务，并在网关层统一鉴权与路由，用消息队列在服务间异步传递事件^[12]。

架构描述还被用于沟通与治理。以城市作类比的可视化方法把组件按代码规模或圈复杂度映射为不同大小的建筑，使架构结构与代码度量可以同时呈现，便于团队讨论与评审^[1]。在架构设计过程中，通常需要识别系统目标和约束、建立多条候选架构、评估性能等质量属性，再据此作出架构决策并进入实施^[1]。

局限

架构无法一劳永逸地保证系统质量，也难以覆盖全部非功能属性。有研究指出，常见视点集合大多只针对特定结构，并不直接容纳安全、性能等质量属性，质量属性往往需要跨视图考虑，按视点逐个描述容易把质量问题的讨论推迟^[11]。4+1 视图模型本身也缺少描述业务流程和容纳非功能需求的能力，被后续研究视为不足^[13]。

架构在长期演进中容易腐化。若变更时未考虑其对结构的影响，原有架构会被任意修改直至失去关键属性，形成架构侵蚀与架构债务；其表现包括性能下降、缺陷增多、引入新需求所需时间变长^[14]。有观点认为，任何混合在一起的架构都会不断腐化，重构之后仍可能再次腐化，架构设计能够做到的是及时发现并修正，而不是彻底避免^[15]。

架构文档常常滞后于实现。项目初期编写的架构描述在开发生命周期中往往得不到维护，源代码反而成为唯一保持最新的材料，架构因此要靠逆向工程去“发现”而不是靠文档去读取^[14]。强调快速交付的敏捷方法在某些情况下会加快这一过程，对长期结构问题的关注减少，文档与设计也随之减少^[14]。

此外，激进的小步演进方式也有其边界。演进式架构若缺少架构治理，容易出现模块边界混乱、隐式依赖、接口不一致，并出现局部合理而全局较差的情况；对于需求稳定、合规约束强的系统，小步改动反而可能带来风险^[16]。不存在适用于所有产品和规模的架构，为普通规模设计的架构在用户量增长 10 倍或 100 倍后往往不再有效^[17]。

参见

• 设计模式 —— 面向对象设计层面的可复用解法，抽象层次低于架构模式

• 分层架构 —— 按职责横向切分系统并按层管理依赖的一种基础架构风格

• 微服务架构 —— 把应用拆成一组可独立部署的小型服务的架构风格

• 架构视图 —— 从特定视角呈现系统结构的描述单元，4+1 视图模型是其代表

• 软件工程 —— 研究软件开发、维护与管理的学科，架构是其设计阶段的核心议题

• 技术债务 —— 用财务债务比喻架构与代码中积累的维护负担