架构
1. 概述（Overview）
软件架构（Software Architecture）是一种用来管理复杂性的工程学科，其目标是在软件系统漫长生命周期中，以最低成本构建、演进、运行并维护系统。它不仅满足非功能性需求（可维护性、可扩展性、可靠性、可测试性、可部署性），更承担沟通、决策、治理等组织层面的职能。
架构本质上是一组长期可复用的设计决策，这些决策定义了：
- 系统的结构（Structure）
- 元素与关系（Elements & Relations）
- 行为协作（Behavior）
- 限制与约束（Constraints）
- 演进路径（Evolution Path）
架构不是图，而是决策；图只是表达架构的手段。
2. 架构的本质（Essence）
2.1 架构的核心目标
用最小的人力成本完成系统长期构建与维护。
本质上解决两件事：
- 让系统能运转（行为价值）
- 让系统能持续修改（架构价值）
架构价值的丧失，会导致系统不可维护、业务扩展受阻、组织效率下降。
2.2 架构的核心原则
- 推迟决策（Decide Late）：越晚决定细节，越能基于更多信息做更优选择。
- 隔离变化（Isolate Change）：将变化源隔离在局部，使局部变更不破坏整体。
- 保持可选项（Keep Options Open）：架构的策略是尽量长时间地保留尽可能多的可选项。
- 稳定依赖方向（Stable Dependencies）：低层实现依赖高层策略，而不是反过来。
2.3 策略与细节分离
软件可以抽象为两类内容：
- 策略（业务逻辑）：真正赚钱、省钱的核心逻辑，变化较少
- 细节（技术实现）：数据库、Web 框架、消息队列等，频繁变化
保持边界，使细节的变化不影响策略，是“整洁架构”“六边形架构”“DDD”等架构风格的共同目标。
3. 架构能力模型（Model）
从软件生命周期视角，架构的能力模型可分为以下六类：
3.1 开发视图（Development）
关注团队结构、模块组织、代码可维护性。
- 架构反映团队结构（康威定律）
- 模块化、领域划分、可测试性
3.2 部署视图（Deployment）
关注系统如何构建、发布、扩容。
- 一键部署
- 多环境体系
- 发布与回滚策略
3.3 运行视图（Runtime）
关注运行时行为：
- 高可用
- 性能
- 调度
- 弹性能力
3.4 维护视图（Maintenance）
关注问题诊断、变更成本、可观测性：
- 风险：改动引发的新问题
- 探秘成本：找问题的代价
3.5 架构可选项体系
保持可替换性：
- 可替换数据库
- 可切换 MQ
- 可裁剪组件
3.6 边界与依赖管理
拆分边界、控制依赖方向、服务化演进。
4. 架构解耦体系（Decoupling）
4.1 解耦的维度
- 源码解耦：类/模块依赖管理
- 部署解耦：可独立部署单元
- 服务解耦：服务边界定义、协议、治理
架构是可以“生长”的： 单体 → 可部署单元 → 微服务 → 服务网格
一个好的架构应该同时支持：
- 从单体生长为服务化
- 服务化退化为单体（如中台返祖）
4.2 去冗余（重复识别）
分辨：
- 表面重复
- 本质重复（真正需要抽取）
4.3 独立性
- 开发独立性（多人并行）
- 部署独立性（独立发布）
5. 架构分类（Architecture Types）
5.1 基础设施架构
- 云平台、操作系统、网络、存储
5.2 中间件与数据架构
- MQ、RPC、流计算、大数据平台
5.3 业务系统架构
- 通用软件系统
- 离线分析系统（Data Warehouse）
- 在线业务系统
随着技术发展，边界正不断融合与渗透。
6. 架构视图体系（Architecture Views）
视图是表达架构的方式，不是架构本身。
6.1 架构图绘制的 4R 原则
- Rank：确定图的抽象级别（L0～L4）
- Role：识别系统角色
- Relation：绘制角色间关系
- Rule：基于关键场景绘制协作方式
6.2 4+1 视图
包含：
- 逻辑视图：领域、职责、接口
- 实现视图：代码结构、构建依赖
- 进程视图：运行时交互
- 部署视图：机器、容器部署关系
- 场景视图：用户视角的用例与时序
6.3 各类常见架构图（保留原图）
- 业务架构图
- 前端架构图
- 系统架构图
- 应用架构图
- 部署架构图
- 系统序列图
- 架构立方体 六维度：逻辑 / 物理 / 应用 / 技术 / 功能 / 部署
7. 架构边界设计（Boundaries）
架构设计的核心是边界管理：
- 隔离策略与细节
- 控制跨层依赖
- 通过边界推迟技术决策
7.1 边界划分的方式
- 按领域划分
- 按用例划分
- 按部署/线程/进程/服务划分
7.2 插件式架构思想
软件发展史，就是增加“可插拔点”的历史。
插件的目标：
- 可去掉
- 可替换（多个实现）
7.3 单向边界（依赖反转）
7.4 过度设计 vs 不足设计
边界必须谨慎，过度设计常比不足更糟糕。
8. 关键业务逻辑（Core Logic）
核心业务逻辑与核心业务数据应组合成“业务实体”。
8.1 用例模型
- 输入
- 处理步骤
- 输出
8.2 请求/响应模型
对用例的 I/O 数据保持独立，避免污染业务实体。
9. 架构风格与框架
9.1 COLA（阿里）
融合了 DDD、六边形架构、整洁架构思想。
9.2 整洁架构
原则：
- 内层不依赖外层
- 业务不依赖技术
- UI/DB 都是细节
9.3 谦卑对象模式
将难测试部分隔离，让测试不依赖易变部分。
9.4 Main 组件
系统启动与协作中心，是最外层的“细节”。
9.5 测试的架构地位
测试是最外层的依赖，设计架构时必须考虑可测试性。
10. 架构演进（Evolution）
从后端视角来看，系统演进路径通常是：
- Mainframe
- 原始分布式
- 单体 Monolithic
- SOA
- 微服务 Microservices
- 服务网格 Service Mesh
- 无服务 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）
- 作为沟通语言（跨团队/干系人）
- 支撑原型设计与架构演进
- 承载早期决策（SWOT / RASCI）
- 限定系统约束条件
RAID 矩阵
| Risk | Assumption | Issue | Dependency | |
|---|---|---|---|---|
| 决策1 | ||||
| 决策2 | ||||
| 决策3 |
13. 实现细节（Details）
13.1 数据库
关注数据结构与一致性机制
13.2 Web
Web 本质是 IO 设备
13.3 框架
引入框架≠提升架构，需要评估风险与生命周期
14. 面向具体技术的架构模式
单体架构：Spring Boot
微服务（Spring Cloud）
微服务 + K8S
服务网格 Istio
Serverless
上传代码 → 自动运行 → 无需关心基础设施
14.5 架构治理（Architecture Governance）
架构不仅是技术问题，更是治理问题。治理的目标是让架构在组织规模扩张过程保持一致性与可控性。
架构治理的组成
- 决策治理（ADR 流程）：记录重要架构决策、权衡、风险、备选方案。
- 演进治理：控制技术债务、规划迁移路线、设定演进节奏。
- 一致性治理：制定编码规范、API 规范、数据规范、服务边界规范。
- 风险治理：识别架构风险（R）、假设（A）、问题（I）、依赖（D）。
常用治理机制
- 架构委员会（ASG）
- 架构评审（ADR Review）
- 架构基线与版本管理
- 架构 Scorecard（可维护性、稳定性、复杂度）
14.6 架构质量属性（Quality Attributes）
架构的优劣取决于其质量属性（NFR，而非功能需求）：
- 可维护性（Maintainability）：复杂度、边界定义、可测试性。
- 可扩展性（Scalability）：弹性、横向扩容、无状态化。
- 可用性（Availability）：故障域、隔离、熔断、降级。
- 性能（Performance）：延迟、吞吐、资源利用。
- 可演进性（Evolvability）：替换成本、架构可选项。
- 可观测性（Observability）：指标、日志、追踪链路。
架构设计需基于关键质量属性进行技术选型与边界规划。
14.7 架构的度量体系（Metrics）
为了减少架构的“玄学成分”，需要可量化的度量：
代码结构度量
- 依赖深度（Dependency Depth）
- 环依赖数量（Cycles）
- 模块内聚度（Cohesion）
- 模块耦合度（Coupling）
运行度量
- MTTR（平均修复时间）
- MTBF（平均无故障时间）
- 错误预算（Error Budget）
架构可演进度量
- 新功能上线时间（Lead Time）
- 回滚成本
- 替换 MQ/DB 的成本（可选项评分）
14.8 架构技术债务（Tech Debt）
技术债务不可避免，但需要治理：
- 结构性技术债务：边界错位、耦合混乱、数据模型腐化。
- 技术选型债务：使用过时框架、依赖复杂工具。
- 过程性债务：缺少规范、缺少自动化、缺少测试。
治理策略：
- 建立债务台账（Debt Register）
- 设定年度偿还率（例如 15%）
- 每次迭代保留“架构演进配额”
14.9 架构安全模型（Security）
架构必须内建安全，不可后补：
- Least Privilege（最小权限）
- Zero Trust（零信任）
- 配置安全（Secrets 管理）
- 数据安全（加密、脱敏）
- API 安全（认证、鉴权、率限制）
- 审计与追踪
15. 架构的未来
未来的软件架构将呈现以下趋势：
15.1 云化与 XaaS 化
- 基础设施、平台、软件服务逐渐云端化（IaaS/PaaS/SaaS）。
- 架构设计更关注服务边界、弹性、自动扩缩容和多租户支持。
15.2 自动化运维与治理
- 架构与运维（DevOps/PlatformOps）深度融合。
- 自动化部署、监控、扩展和治理成为标准。
- 架构治理工具和度量体系将普及，提高架构可控性。
15.3 演进式架构（Evolutionary Architecture）
- 架构设计强调可演进、可测量和可替换。
- Fitness Function 评价架构决策和系统行为。
- 支持快速业务变更与持续交付。
15.4 云原生与服务网格
- 微服务进一步解耦、容器化、服务治理由平台提供。
- 服务网格（Istio、Linkerd）提升可观测性、流量控制、策略执行能力。
15.5 无服务器架构（Serverless）
- 上传函数即运行，彻底屏蔽基础设施管理。
- 高度事件驱动、按需扩展。
- 架构关注事件流、函数组合、服务质量保障。
15.6 安全与合规驱动的架构
- 安全内建（Security by Design），数据隐私与合规性成为架构首要考量。
- 零信任、最小权限、多层防护体系。
15.7 智能化架构
- 利用 AI/ML 辅助架构决策、容量预测、性能优化。
- 自动化推荐架构改进、优化服务组合。
15.8 架构作为组织能力
- 架构不仅解决技术问题，还支持组织敏捷、业务连续性和知识传承。
- 架构演进能力成为组织核心竞争力。