系统架构

系统架构不是一张组件图，也不是框架和中间件的购物清单。它关注的是：一个系统为什么被建成现在的样子，哪些结构和设计决定最重要，这些决定如何回应业务目标、运行环境和长期变化。图可以表达架构，但图本身不等于架构；代码承载了许多架构决定，也不会自动说明这些决定的理由。

ISO/IEC/IEEE 42010 把“架构”和“架构描述”区分开来。前者属于被讨论的系统或其他实体，后者是用来表达架构的工作成果。这个区分能避免一种常见误解：文档不完整不代表系统没有架构，文档画得漂亮也不代表设计合理。架构描述是否有用，取决于它能否回应相关人员真正关心的问题。

从关注点开始

同一系统在不同人眼里并不相同。产品负责人关心交付范围和成本，开发人员关心模块边界和修改影响，运维人员关心容量、监控和故障恢复，安全人员关心身份、数据和攻击面。架构工作首先要识别这些利益相关方和关注点，再选择适合的视图。部署视图不能替代数据模型，调用链也不能解释组织权限。

这也是架构文档需要多种视图的原因。逻辑结构说明职责如何分配，运行结构说明进程和通信怎样协作，部署结构说明软件落在哪里，数据视图说明信息如何存储和流动。视图之间应当能够互相核对。例如，一个组件声称无状态，部署和数据视图中却存在本地持久化，就说明描述或实现至少有一处不一致。

功能回答系统要做什么，质量属性回答系统要做到什么程度、在什么条件下做到。性能、可用性、安全性、可修改性和可测试性往往直接影响架构。单独写“系统应当高可用”没有多少设计价值；更有效的表达会说明什么故障发生在什么环境中，系统应该怎样响应，允许中断多久，数据最多可以丢失多少。

卡内基梅隆大学软件工程研究所长期使用质量属性场景帮助团队把模糊要求变成可以分析的约束。不同属性之间经常需要权衡：同步复制提高数据安全，却可能增加写入延迟；细粒度服务便于独立变化，也带来更多网络交互和运维成本。架构设计的价值不在于消除权衡，而在于让权衡基于明确目标并留下可追溯的理由。

系统边界、团队结构、业务规模和技术条件都会变化。早期合适的单体应用不一定落后，拆成微服务也不会自然获得弹性和自治。应该根据变化频率、发布独立性、数据一致性、故障隔离和团队能力判断边界，而不是先选择流行形式再寻找理由。

架构决定记录（ADR）适合保存那些会影响后续工作的选择：当时面对什么问题，考虑过哪些方案，为什么接受当前取舍，什么变化会触发重新评估。这样的记录比只保留最终结构更有价值，因为后来的人能够理解限制来自哪里，也能判断限制是否还存在。

Geo Platform 的架构知识体系会从架构描述和质量属性进入模块化、领域边界、分布式系统、数据与集成、云原生、可靠性、安全和治理。每个专题都把方法放到具体条件中讨论，不把模式当成普遍答案。遇到缓存、消息队列、分库或服务拆分等选择时，页面会同时说明它解决的问题和新增的复杂性。

ISO/IEC/IEEE 42010:2022，架构描述、关注点、视图和框架的标准入口。付费条款不在本站复刻。
Software Architecture, Carnegie Mellon Software Engineering Institute，用于软件架构实践及其与系统质量的关系。
Reasoning About Software Quality Attributes，用于质量属性场景和架构权衡。