《软件架构实践》读书笔记——（二）_可集成性的通用场景-CSDN博客

本文链接：https://blog.csdn.net/m0_73828856/article/details/145705729

前篇看这里：

《软件架构实践》读书笔记——（一）

第五章：可部署性

1. 可部署性的定义：

可部署性（Deployability）指软件能够在可预测的时间和工作量内被部署到目标环境中，并且如果新部署不符合规范，可以回滚到之前的状态。

2. 持续部署与持续交付：

持续部署（Continuous Deployment）是指自动化的部署过程，没有任何人为干预。

持续交付（Continuous Delivery）是指自动化的部署过程，仅在最后一步可能需要人工干预。

3. 部署流水线：

部署流水线（Deployment Pipeline）是从代码签入版本控制系统到应用程序部署好供用户使用的一系列工具和活动的集合。

4. 环境一致性（Environment Consistency）：

虚拟化技术使得开发、集成和生产环境之间可以实现一致性，有助于减少环境差异导致的问题。

5. DevOps实践：

DevOps是一组实践，旨在减少向系统提交变更和将变更放入生产之间的时间，同时确保高质量。

6. 部署策略（Deployment Strategies）：

讨论了不同的部署策略，包括蓝/绿部署（Blue/Green Deployment）和滚动升级（Rolling Upgrade）。

7. 可部署性战术（Deployability Tactics）：

描述了多种可部署性战术，包括规模递增（Canary Releases）、回滚（Rollback）、部署命令脚本（Deployment Scripts）、管理服务交互（Service Interaction Management）、打包依赖项（Dependency Packing）和功能特性切（Feature Toggling）。

8. 可部署性模式（Deployability Patterns）：

探讨了微服务架构（Microservices Architecture）和其他模式，如蓝/绿部署和滚动升级，这些模式支持高效的部署过程。

9. 部署的影响因素：

分析了影响软件部署的因素，包括部署的颗粒度（Granularity）、可控性（Controllability）、有效性（Effectiveness）和对其他质量属性的影响。

10. 部署的挑战和权衡（Trade-off）：

讨论了在部署过程中可能遇到的挑战，以及在快速部署、成本和系统稳定性之间的权衡。

可部署性通用场景

第六章：能源效率

1.能源效率的重要性：

能源效率（Energy Efficiency）是指在软件系统中以最小的能源消耗提供所需的功能和性能。随着移动设备、物联网（Internet of Things, IoT）和云服务的普及，能源效率成为了架构师必须考虑的关键质量属性。

2.能源效率通用场景：

介绍了能源效率的通用场景（General Energy Efficiency Scenario），包括场景组成、描述、可能的值，以及如何度量响应度。

3.能源效率战术：

4. 监视资源：

强调了度量能耗的重要性，包括通过传感器实时收集数据的计量战术，使用基准数据或制造商规格的静态分类，以及基于工作负荷等动态条件的动态分类。

5. 分配资源：

讨论了在考虑能耗的前提下如何分配资源来完成任务，包括减少设备活动、服务发现（Service Discovery）和资源调度等战术。

6. 减少资源需求：

探讨了通过管理事件到达、限制事件响应、事件优先级、减少计算开销、限定执行时间和提高资源利用效率等战术来直接减少能源消耗。

7. 基于战术的能源效率调查问卷：

提供了一个调查问卷（Tactical Energy Efficiency Survey Questionnaire），帮助分析人员快速理解架构师使用特定战术来管理能源效率的程度。

8. 能源效率模式：

介绍了一些提高能源效率的模式示例，如传感器融合（Sensor Fusion）、杀死异常任务（Killing Errant Tasks）和电源监视器（Power Monitor），这些模式有助于在不同场景下实现能源效率。

第七章：可集成性

1. 可集成性的定义：

可集成性（Integrability）是指软件系统能够与预期的和未预期的组件、系统或环境成功集成的能力，这种能力涉及成本和技术风险的考量。

2. 评估架构的可集成性：

讨论了如何评估架构的可集成性，包括理解组件之间的依赖关系和“距离”。这些依赖关系可能包括：

（1）语法距离（Syntactic Distance）：协作元素必须在共享数据的数量和类型上达成一致。

（2）数据语义距离（Semantic Distance）：协作元素必须在数据语义上达成一致，即使两个元素共享相同的数据类型，它们的值也可能有不同的解释。

（3）行为语义距离（Behavioral Semantic Distance）：协作元素必须在行为上达成一致，特别是在系统的状态和模式方面。

（4）时序距离（Temporal Distance）：协作元素必须就有关时间的假设达成一致，如操作频率不同或时序假设不同。

（5）资源距离（Resource Distance）：协作元素必须就共享资源的前提达成一致，如设备访问或计算资源分配。

3. 可集成性通用场景：

描述了可集成性的通用场景，包括来源（Source）、刺激（Stimulus）、制品（Artifact）、环境（Environment）和响应（Response）等方面，这些场景帮助分析和规划集成任务。

4. 可集成性战术：

详细介绍了提高可集成性的战术，包括限制依赖关系、适配和协调。这些战术旨在减少组件间的依赖，简化集成过程，并提高系统的灵活性。

5. 限制依赖关系的战术：

包括封装（Encapsulation）、使用中介（Use of Intermediaries）、限定通信路径（Constrained Communication Paths）、遵守标准（Standards Compliance）和抽象公共服务（Abstracted Public Services）等战术，以减少组件间的直接依赖。

6. 适配战术：

涉及发现（Discovery）、裁剪接口（Tailored Interfaces）和配置行为（Configurable Behavior）等战术，以解决组件间的依赖问题，并允许组件在不同上下文中重用。

7. 协调战术：

包括编排（Orchestration）和管理资源（Resource Management）等战术，以协调组件间的交互，并管理对共享资源的访问。

8. 基于战术的可集成性调查问卷：

提供了一个调查问卷，帮助分析人员评估架构中使用的可集成性战术，以及这些战术的实现和影响。

9. 可集成性模式：

讨论了一些支持可集成性的架构模式，如包装器（Wrapper）、桥接器（Bridge）、中介（Mediator）、面向服务的架构（Service-Oriented Architecture, SOA）和动态发现（Dynamic Discovery）模式。

第八章：可修改性

1. 可修改性的定义：

可修改性（Modifiability）关注于降低进行系统变更的成本和风险。它涉及系统的功能、平台、环境、品质和能力可能发生的变更。

2. 可修改性的重要性：

研究表明，软件系统的大部分成本发生在初始发布之后，这通常涉及到对系统的变更。因此，可修改性是软件架构中一个关键的质量属性。

3. 可修改性通用场景：

描述了可修改性的通用场景，包括变更的来源、刺激、制品、环境和响应，以及如何度量响应度，例如变更所需的时间和资源。

4. 可修改性战术：

讨论了提高可修改性的战术，包括增加内聚性（Cohesion）、减少耦合性（Coupling）、延迟绑定（Binding）等，这些战术有助于控制变更的复杂性以及进行变更的时间和成本。

5. 增加内聚性的战术：

包括拆分模块（Split Module）和重新分配职责Reallocate Responsibilities），以减少单个模块变更影响多个模块的可能性。

6. 减少耦合性的战术：

涉及封装（Encapsulation）、使用中介（Use of Intermediaries）、抽象公共服务（Abstracted Public Services）和限制依赖关系（Limit Dependency Relationships）等，以降低模块之间的耦合性。

7. 延迟绑定的战术：

包括参数化（Parameterization）、组件替换（Component Replacement）、配置时绑定（Configuration-Time Binding）、资源文件（Resource Files）、发现（Discovery）、解释参数（Interpreted Parameters）、共享库（Shared Libraries）和多态性（Polymorphism）等，以在软件生命周期的后期进行变更。