软件架构
2025年1月9日
Head First Software Architecture
软件架构
Head First Software Architecture
本书主要讲解软件架构的设计原则和实践。书中介绍了多种架构风格，例如分层架构、模块化单体架构、微内核架构和微服务架构，并分析了每种架构的优缺点和适用场景。 重点阐述了架构决策的重要性，以及如何通过架构决策记录（ADR）来规范和记录这些决策。 此外，书中还强调了权衡取舍在软件架构中的重要性，并提供了大量练习和案例来帮助读者理解和掌握这些概念。
好的，我将根据提供的资料，按照章节总结知识点，并用中文回复，力求做到信、雅、达。
第一章：软件架构概述
- 软件架构学习的挑战: 大脑会倾向于认为软件架构不重要，而将注意力放在其他事情上。但可以通过技巧让大脑意识到软件架构的重要性。
- 软件架构的核心: 架构特性（Architectural Characteristics） 是任何系统的基本构建模块。没有它们，就无法进行架构决策，选择架构风格，甚至无法创建逻辑架构。
- 软件架构的本质: 软件架构没有最佳实践，需要仔细分析每种情况并做出决策。
- 类比: 可以通过房屋或花园的类比来理解软件架构。
第二章：架构特性
- 架构特性的定义: 架构特性是架构的基石，决定了系统需要支持什么。它们也被称为非功能性需求、系统质量属性或 “-ilities”。
- 架构特性的重要性: 它们有助于做出架构决策和分析重要的权衡。
- 常见的架构特性: 例如可伸缩性（scalability）、可靠性（reliability）和可测试性（testability）等。
- 显式与隐式特性: 显式特性在需求中明确指出，而隐式特性则影响架构决策，但未明确列出，如安全性。
- 复合特性: 多个特性组合成新的特性，如敏捷性（agility），它包括可测试性、可部署性和模块化等。
- 优先级: 需要根据上下文确定架构特性的优先级，并且优化一个特性可能会牺牲另一个特性。
- 没有标准列表: 架构特性的列表并非固定不变，会随着软件开发生态的变化而变化。
- 架构特性与逻辑组件: 架构特性和逻辑组件共同决定了架构风格。
第三章：权衡与决策
- 软件架构的第一定律：一切皆权衡。每个决策都包含权衡，没有无代价的决策。
- 战略与战术决策: 战略决策更具架构性，需要更多思考和规划，通常是长期的。
- 架构与设计的区别：架构决策具有显著的权衡，更具战略性，而设计决策则更偏向实现细节。
- 权衡分析：包括找出特定方法的好处和坏处，以获得完整的信息。
- ADR (Architecture Decision Record): 用于记录架构决策，包括标题、状态、上下文、决策和后果。
- ADR 的状态: 包括 RFC（征求意见）、Proposed（提议中）、Accepted（已接受）和 Superseded（已取代）。
- ADR 的内容: 包括上下文（决策的环境和约束）、决策（具体要做出的选择）和后果（决策带来的影响）。
- 异步与同步通信的权衡: 异步通信可以提高响应速度和可用性，而同步通信则更易于管理事务和错误。
第四章：逻辑组件
- 逻辑组件的定义: 逻辑组件是系统的构建模块，执行特定的功能。
- 逻辑组件的表示: 通常通过目录或命名空间来表示。
- 逻辑组件的特性: 每个逻辑组件都应该在系统中具有明确的角色和责任。
- 识别逻辑组件的方法：
- 工作流方法: 根据工作流程的步骤来识别组件。
- 参与者/动作方法: 根据系统中参与者的动作来识别组件。
- 避免实体陷阱: 命名组件时避免使用 “manager” 或 “supervisor” 等词语。
- 组件耦合:
- 传入耦合 (Afferent Coupling, CA): 依赖于当前组件的其他组件的数量。
- 传出耦合 (Efferent Coupling, CE): 当前组件依赖的其他组件的数量。
- 总耦合 (Total Coupling, CT): 传入耦合和传出耦合的总和。
- 耦合的重要性: 松耦合可以降低组件之间的依赖性，但也会带来权衡。
- 逻辑组件的组织: 逻辑组件通常与源代码目录结构对应。
第五章：架构风格
- 架构风格的分类: 可以根据代码的划分方式（技术关注点或领域关注点）以及部署方式（单体或分布式）进行分类。
- 单体架构: 将所有逻辑组件部署为一个单元。
- 分布式架构: 将逻辑组件分散到多个单元中。
- 架构风格的选择: 需要考虑多种因素，包括问题的复杂性和时间紧迫性。
第六章：分层架构
- 分层架构的特点: 按照技术关注点将系统划分为不同的层，例如表示层、业务规则层和持久层。
- 层与组件的关系: 领域组件通常会跨越多个物理层。
- 分层架构的优缺点: 简单易懂，但可能难以适应领域变化。
- 适用场景: 适合简单且不需要频繁更改的系统。
第七章：模块化单体架构
- 模块化单体架构的特点: 在单体架构的基础上，按照业务领域对系统进行划分，形成多个模块。
- 模块化的优势: 提高可维护性、可测试性和可部署性，降低变更风险。
- 模块间的通信: 通过模块的 API 进行间接通信。
- 模块化与分层: 模块化单体架构可以包含分层架构，并且每个模块可以有自己的层。
- 数据模式: 每个模块都有自己的数据模式.
第八章：微内核架构
- 微内核架构的特点: 将系统分为一个核心部分（core）和多个插件（plugin）。
- 核心的功能: 核心提供最基本的功能，插件负责扩展和定制功能。
- 插件的类型: 可以是单体或分布式的。
- 微内核的“微内核性”: 取决于核心在没有插件的情况下有多大的功能以及核心的易变性。
- 适用场景: 适用于需要高度定制和扩展的系统，例如 IDE 和电子回收系统。
第九章：架构实践
- 综合运用: 本章通过 TripEZ 旅行应用程序，综合运用了之前章节的知识，包括架构特性、逻辑组件和架构风格，来构建一个完整的架构。
- 架构决策过程: 包括确定架构特性、构建逻辑架构、做出架构决策和选择架构风格。
- 没有正确答案: 软件架构没有绝对的正确答案，重点在于分析权衡并为决策提供合理依据。
- 多种可能的解决方案: 对于同一个问题，可以有多种可行的架构解决方案。
第十章：微服务架构
- 微服务架构的特点: 将应用程序分解为一组小的、独立部署的服务。
- 服务粒度: 微服务不宜过大或过小，需要找到合适的粒度。
- 数据所有权: 每个微服务拥有自己的数据。
- 共享功能: 可以使用共享服务或共享库来实现。
- 工作流管理: 可以通过编排（Orchestration）或协作（Choreography）来管理。
- 编排: 由一个中心服务来协调其他微服务的调用。
- 协作: 微服务之间通过事件进行通信，无需中央协调者。
第十一章：事件驱动架构
- 事件驱动架构的特点: 通过事件进行异步通信，将处理分解为独立的服务。
- 事件的定义: 已发生的事情，通常用过去式表示。
- 消息与事件: 消息是命令，而事件是通知。
- 异步通信: 服务发送事件后无需等待响应，提高了系统的响应速度和可用性。
- 同步通信: 发送服务必须等待接收服务响应。
- 数据耦合: 在事件驱动架构中，数据可能会形成耦合点。
- 数据拓扑: 数据库可以是单体也可以是服务专有的。
- 事件驱动架构的优缺点: 具有高弹性、高可用性，但也更复杂。
附录：其他
- 架构师的职责: 清晰、简洁地沟通，并与开发团队合作。
- 清晰的架构图: 使用一致的形状、颜色和线条，并包含图例。
- 学习路径: 从了解基础知识到扩展广度和深度.