基础设施即代码，第2版

第 15 章 核心实践 核心练习：简单小品

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

一个成功的系统往往会随着时间的推移而发展壮大。越来越多的人使用它，越来越多的人为它工作，越来越多的东西被添加到它里面。随着系统的发展，变更的风险和复杂程度也会增加。这往往会导致管理变更的流程更加复杂和耗时。进行更改的开销会增加修复和改进系统的难度，导致技术债务增加，从而削弱系统的质量。

这就是第 1 章所述的 "变化速度推动质量提高，质量提高促进变化速度加快 "这一循环的反面教材。

应用 "基础设施即代码 "的三个核心实践--将一切都定义为代码、持续测试和交付，以及构建小片段（"基础设施即代码的三个核心实践"）--可以实现积极版本的循环。

本章重点介绍第三种做法，即用较小的组件组成系统，以便在系统增长的同时保持较快的变化速度，并提高质量。大多数基础架构编码工具和语言都具有支持模块、库和其他类型组件的功能。但是，基础架构的设计思想和实践还没有达到软件设计的成熟度。

因此，本章借鉴了从数十年软件设计中汲取的模块化设计原则，并从代码驱动的基础架构的角度来考虑这些原则。然后，本章将探讨基础架构系统中不同类型的组件，并着眼于如何利用它们实现更好的模块化。在此基础上，我们可以看看在基础架构组件之间划定界限的不同考虑因素。

模块化设计

模块化的目标是使系统的更改更容易、更安全。模块化可以通过多种方式实现这一目标。一种是消除重复实现，减少为实现特定更改而需要修改的代码数量。另一种方法是通过提供可针对不同用途以不同方式组装的组件来简化实现过程。

让更改更容易、更安全的第三种方法是，在设计系统时，可以对较小的组件进行更改，而无需更改系统的其他部分。较小的部件比较大的部件更容易、更安全、更快速地进行更改。

大多数模块化设计规则都有其局限性。粗心大意地遵循这些规则，实际上会使系统更加脆弱，更难改变。四项关键指标 "中的四项关键指标是考虑系统模块化效果的一个有用视角。

精心设计的组件的特点

设计组件是一门决定将系统中哪些元素组合在一起、哪些元素分开的艺术。要做好这一点，就必须了解各元素之间的关系和依赖性。组件的两个重要设计特征是耦合和内聚。良好设计的目标是创建低耦合和高内聚。

耦合度描述了一个组件的变化需要另一个组件变化的频率。对于系统的两个部分来说，零耦合并不是一个现实的目标。零耦合可能意味着它们根本不是同一个系统的一部分。相反，我们的目标是低耦合或松散耦合。

堆栈和服务器映像是耦合的，因为当你升级服务器上的软件时，可能需要增加分配给堆栈中服务器实例的内存。但每次更新服务器镜像时，都不需要更改堆栈中的代码。低耦合使更改一个组件变得更容易，而破坏系统其他部分的风险很小。

内聚力描述了组件内各元素之间的关系。与耦合一样，内聚的概念与变化模式有关。内聚度较低的堆栈中定义的资源的变化往往与堆栈中的其他资源无关。

一个基础架构堆栈如果为由其他两个堆栈提供的服务器定义了不同的网络结构，那么这个堆栈的内聚力就很低。内聚度高的组件更容易更改，因为它们更小、更简单、更干净，爆炸半径（Blast Radius）也更小，而不像那些包含了各种松散关联的组件。

简约设计的四条法则

XP 和 TDD 的创始人 Kent Beck 经常引用四条规则来简化组件的设计。根据他的规则，简单的代码应该

• 通过测试（完成它应该做的事情）

• 揭示其意图（清晰易懂）

• 无重复

• 包含最少的元素

组件设计规则

软件架构和设计包括许多原则和指导方针，用于设计具有低耦合性和高内聚性的组件。 ...