架构

1. 概述（Overview）

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

架构本质上是一组长期可复用的设计决策，这些决策定义了：

架构不是图，而是决策；图只是表达架构的手段。

2. 架构的本质（Essence）

2.1 架构的核心目标

用最小的人力成本完成系统长期构建与维护。

本质上解决两件事：

  1. **让系统能运转（行为价值）**
  2. **让系统能持续修改（架构价值）**

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

2.2 架构的核心原则

2.3 策略与细节分离

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

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

3. 架构能力模型（Model）

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

3.1 开发视图（Development）

关注团队结构、模块组织、代码可维护性。

3.2 部署视图（Deployment）

关注系统如何构建、发布、扩容。

3.3 运行视图（Runtime）

关注运行时行为：

3.4 维护视图（Maintenance）

关注问题诊断、变更成本、可观测性：

3.5 架构可选项体系

保持可替换性：

3.6 边界与依赖管理

拆分边界、控制依赖方向、服务化演进。

4. 架构解耦体系（Decoupling）

4.1 解耦的维度

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

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

4.2 去冗余（重复识别）

分辨：

4.3 独立性

5. 架构分类（Architecture Types）

5.1 基础设施架构

5.2 中间件与数据架构

5.3 业务系统架构

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

6. 架构视图体系（Architecture Views）

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

6.1 架构图绘制的 4R 原则

6.2 4+1 视图

4+1视图

包含：

6.3 各类常见架构图（保留原图）

7. 架构边界设计（Boundaries）

架构设计的核心是边界管理：

7.1 边界划分的方式

7.2 插件式架构思想

软件发展史，就是增加“可插拔点”的历史。

插件的目标：

7.3 单向边界（依赖反转）

202002031612

7.4 过度设计 vs 不足设计

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

8. 关键业务逻辑（Core Logic）

核心业务逻辑与核心业务数据应组合成“业务实体”。

8.1 用例模型

8.2 请求/响应模型

对用例的 I/O 数据保持独立，避免污染业务实体。

9. 架构风格与框架

9.1 COLA（阿里）

融合了 DDD、六边形架构、整洁架构思想。

9.2 整洁架构

202002031554

原则：

9.3 谦卑对象模式

将难测试部分隔离，让测试不依赖易变部分。

9.4 Main 组件

系统启动与协作中心，是最外层的“细节”。

9.5 测试的架构地位

测试是最外层的依赖，设计架构时必须考虑可测试性。

10. 架构演进（Evolution）

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

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

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

11. 架构认知流派

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

11.1 结构派（Structure-Oriented）

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

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

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

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

11.2 决策派（Decision-Oriented）

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

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

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

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

11.3 模式派（Pattern-Oriented）

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

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

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

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

11.4 领域驱动派（Domain-Driven）

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

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

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

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

11.5 进化派（Evolutionary Architecture）

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

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

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

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

11.6 系统论派（Systems Thinking）

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

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

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

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

11.7 工程派（Engineering-Oriented）

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

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

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

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

12. 架构的意义（Value）

RAID 矩阵

202191322132

RiskAssumptionIssueDependency
决策1
决策2
决策3

13. 实现细节（Details）

13.1 数据库

关注数据结构与一致性机制

13.2 Web

Web 本质是 IO 设备

13.3 框架

引入框架≠提升架构，需要评估风险与生命周期

14. 面向具体技术的架构模式

单体架构：Spring Boot

20201027154734

微服务（Spring Cloud）

20201027154755

微服务 + K8S

20201027154819

服务网格 Istio

20201027154819

Serverless

上传代码 → 自动运行 → 无需关心基础设施

14.5 架构治理（Architecture Governance）

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

架构治理的组成

常用治理机制

14.6 架构质量属性（Quality Attributes）

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

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

14.7 架构的度量体系（Metrics）

为了减少架构的“玄学成分”，需要可量化的度量：

代码结构度量

运行度量

架构可演进度量

14.8 架构技术债务（Tech Debt）

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

治理策略：

14.9 架构安全模型（Security）

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

15. 架构的未来

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

15.1 云化与 XaaS 化

15.2 自动化运维与治理

15.3 演进式架构（Evolutionary Architecture）

15.4 云原生与服务网格

15.5 无服务器架构（Serverless）

15.6 安全与合规驱动的架构

15.7 智能化架构

15.8 架构作为组织能力

关联内容（自动生成）