介绍
在传统的可变服务器基础架构中，服务器会不断更新和修改。 使用这种基础设施的工程师和管理员可以通过 SSH 连接到他们的服务器，手动升级或降级软件包，逐个服务器调整配置文件，并将新代码直接部署到现有服务器上。 换句话说，这些服务器是可变的； 它们可以在创建后更改。 由可变服务器组成的基础设施本身可以称为可变的、传统的或（贬低的）手工的。
不可变基础架构 是另一种基础架构范例，其中服务器在部署后永远不会被修改。 如果需要以任何方式更新、修复或修改某些内容，则会提供由具有适当更改的通用映像构建的新服务器来替换旧服务器。 经验证后，投入使用，旧的退役。
不可变基础架构的好处包括您的基础架构具有更高的一致性和可靠性，以及更简单、更可预测的部署过程。 它减轻或完全防止了可变基础设施中常见的问题，例如配置漂移和雪花服务器。 但是，有效地使用它通常包括全面的部署自动化、云计算环境中的快速服务器配置以及用于处理有状态或临时数据（如日志）的解决方案。
本文的其余部分将：
- 解释可变和不可变基础设施之间的概念和实际差异
- 描述使用不可变基础架构的优势并将其复杂化
- 对不可变基础架构的实现细节和必要组件进行高级概述
可变和不可变基础设施之间的差异
可变基础设施和不可变基础设施之间最根本的区别在于它们的核心策略：前者的组件设计为在部署后进行更改； 后者的组件旨在保持不变并最终被替换。 本教程侧重于将这些组件作为服务器，但还有其他方法可以实现不可变的基础架构，例如使用容器，它们应用相同的高级概念。
更深入地讲，基于服务器的可变和不可变基础架构之间存在实际和概念上的差异。
从概念上讲，这两种基础设施在处理服务器的方法上存在很大差异（例如 创建、维护、更新、销毁）。 这通常用“宠物与牛”的类比来说明。
实际上，可变基础架构是一种更古老的基础架构范式，它早于使不可变基础架构成为可能和实用的核心技术，如虚拟化和云计算。 了解这段历史有助于将两者之间的概念差异以及在现代基础设施中使用其中一种的含义联系起来。
接下来的两节将更详细地讨论这些差异。
实际差异：拥抱云
在虚拟化和云计算成为可能并广泛使用之前，服务器基础架构以物理服务器为中心。 创建这些物理服务器既昂贵又耗时； 初始设置可能需要几天或几周的时间，因为订购新硬件、配置机器、然后将其安装到 colo 或类似位置需要多长时间。
可变基础设施起源于此。 因为更换服务器的成本如此之高，所以尽可能长时间地继续使用您运行的服务器并尽可能减少停机时间是最实际的。 这意味着定期部署和更新有很多适当的更改，但出现问题时也有临时修复、调整和补丁。 频繁手动更改的后果是服务器可能变得难以复制，从而使每个服务器都成为整个基础架构中独特且脆弱的组件。
虚拟化和按需/云计算的出现代表了服务器架构的一个转折点。 虚拟服务器的成本更低，即使是大规模的，它们可以在几分钟内创建和销毁，而不是几天或几周。 这使新的部署工作流程和服务器管理技术首次成为可能，例如使用 配置管理 或 云 API 以编程方式和自动快速配置新服务器。 创建新虚拟服务器的速度和低成本是不变性原则实用的原因。
传统的可变基础设施最初是在物理服务器的使用决定了其管理的可能性时开发的，并且随着时间的推移随着技术的改进而继续发展。 在部署后修改服务器的范例在现代基础设施中仍然很常见。 相比之下，不可变的基础架构从一开始就被设计为依赖基于虚拟化的技术来快速配置架构组件，例如云计算的虚拟服务器。
概念差异：宠物与牛，雪花与凤凰
云计算推进的基本概念变化是服务器可以被认为是一次性的。 考虑丢弃和更换物理服务器是非常不切实际的，但对于虚拟服务器，这样做不仅可行，而且容易且高效。
传统可变基础设施中的服务器是不可替代的独特系统，必须始终保持运行。 这样一来，它们就像宠物一样：独一无二，独一无二，并由人工照料。 失去一个可能是毁灭性的。 另一方面，不可变基础架构中的服务器是一次性的，易于复制或使用自动化工具扩展。 这样一来，它们就像牛：牛群中没有一个人是独一无二的或不可或缺的。
引用 Randy Bias，谁先应用了宠物 vs. 牛类比云计算：
在旧的做事方式中，我们将服务器视为宠物，例如邮件服务器 Bob。 如果鲍勃倒下了，一切都在甲板上。 首席执行官无法收到他的电子邮件，这是世界末日。 在新的方式中，服务器被编号，就像牛群中的牛一样。 例如，www001 到 www100。 当一台服务器出现故障时，它会被取出、射击并在线更换。
另一种类似的方式来说明服务器处理方式之间差异的含义是雪花服务器和凤凰服务器的概念。
雪花服务器类似于宠物。 它们是手动管理的服务器，经常更新和调整，形成一个独特的环境。 凤凰服务器类似于牛。 它们是始终从头开始构建的服务器，并且很容易通过自动化程序重新创建（或“从灰烬中升起”）。
不可变基础设施几乎完全由牛或凤凰服务器组成，而可变基础设施允许一些（或许多）宠物或雪花服务器。 下一节讨论两者的含义。
不可变基础设施的优势
要了解不可变基础架构的优势，有必要将可变基础架构的劣势背景化。
可变基础设施中的服务器可能会遭受配置漂移的影响，即在未记录的情况下，即兴更改会导致服务器的配置彼此之间以及与经过审查、批准和最初部署的配置之间的差异越来越大。 这些越来越像雪花一样的服务器难以复制和替换，使得扩展和从问题中恢复等事情变得困难。 由于难以创建与生产环境相匹配的暂存环境，即使复制问题以进行调试也变得具有挑战性。
在多次手动修改之后，服务器的不同配置的重要性或必要性变得不清楚，因此更新或更改任何配置都可能产生意想不到的副作用。 即使在最好的情况下，也不能保证对现有系统进行更改，这意味着依赖于这样做的部署可能会失败或将服务器置于未知状态。
考虑到这一点，使用不可变基础架构的主要好处是部署简单、可靠性和一致性，所有这些最终都会最大限度地减少或消除许多常见的痛点和故障点。
已知良好的服务器状态和较少的部署失败
不可变基础架构中的所有部署都是通过基于经过验证和版本控制的映像配置新服务器来执行的。 因此，这些部署不依赖于服务器的先前状态，因此不会失败——或者只是部分完成——因为它。
配置新服务器时，可以在投入使用之前对其进行测试，从而将实际部署过程减少为一次更新，以使新服务器可用，例如更新负载平衡器。 换句话说，部署变为 atomic：要么成功完成，要么没有任何变化。
这使得部署更加可靠，并确保基础设施中每台服务器的状态始终是已知的。 此外，此过程可以轻松实现 蓝绿部署 或 滚动发布 ，这意味着无需停机。
没有配置漂移或雪花服务器
不可变基础架构中的所有配置更改都是通过将更新的映像检查到带有文档的版本控制中并使用自动化、统一的部署过程来部署具有该映像的替换服务器来实现的。 Shell 对服务器的访问有时会受到完全限制。
通过消除雪花服务器和配置漂移的风险，这可以防止复杂或难以重现的设置。 这还可以防止有人需要修改难以理解的生产服务器的情况，这种情况存在很高的错误风险并导致停机或意外行为。
一致的暂存环境和轻松的水平扩展
因为所有服务器都使用相同的创建过程，所以不存在部署边缘情况。 这通过使复制生产环境变得微不足道来防止混乱或不一致的暂存环境，并且还通过无缝地允许您向基础架构添加更多相同的服务器来简化 水平扩展 。
简单的回滚和恢复过程
使用版本控制来保留图像历史记录也有助于处理生产问题。 用于部署新映像的相同过程也可用于回滚到旧版本，从而在处理停机时增加额外的弹性并减少恢复时间。
不可变基础设施实施细节
不可变基础设施在其实现细节中具有一些要求和细微差别，特别是与传统的可变基础设施相比。
通过简单地遵守不变性的关键原则，在技术上可以实现独立于任何自动化、工具或软件设计原则的不可变基础设施。 但是，强烈建议使用以下组件（大致按优先级顺序）以实现大规模实用性：
- 云计算环境中的服务器，或其他虚拟化环境（，如容器，尽管这会改变下面的一些其他要求）。 这里的关键是拥有从自定义图像快速配置的隔离实例，以及通过 API 或类似工具进行创建和销毁的自动化管理。
- 整个部署管道的完全自动化，理想情况下包括创建后的图像验证。 设置这种自动化显着增加了实施这种基础设施的前期成本，但这是一种一次性成本，可以迅速摊销。
- 面向服务的架构，将您的基础架构分成模块化的、逻辑上离散的单元，这些单元通过网络进行通信。 这使您可以充分利用云计算的产品，这些产品 与面向服务的 类似（例如 IaaS、PaaS）。
- 一个 无状态、易失的应用层 ，其中包括您的不可变服务器。 这里的任何东西都可以随时（易失性）快速销毁和重建，而不会丢失任何数据（无状态）。
- 一个持久数据层，包括：
- 集中式日志记录，包含有关服务器部署的其他详细信息，例如通过版本或 Git 提交 SHA 进行的图像识别。 由于服务器在此基础架构中是一次性的（并且经常被丢弃），因此即使在 shell 访问受到限制或服务器被破坏后，在外部存储日志和指标也可以进行调试。
- 用于数据库和任何其他有状态或临时数据的外部数据存储，例如DBaaS/云数据库和对象或块存储（云提供或自行管理） ）。 当服务器不稳定时，您不能依赖本地存储，因此您需要将该数据存储在其他地方。
- 工程和运营团队致力于协作并致力于该方法。 尽管最终产品很简单，但在一个不可变的基础设施中有很多活动部件，没有人会知道所有这些。 此外，在此基础架构中工作的某些方面可能是新的或超出人们的舒适区，例如调试或在没有 shell 访问权限的情况下执行一次性任务。
有许多不同的方法来实现这些组件中的每一个。 选择一个在很大程度上取决于个人偏好和熟悉程度，以及您想要自己构建多少基础架构而不是依赖付费服务。
CI/CD 工具 是部署流水线自动化的好起点； Compose 是 DBaaS 解决方案的一个选项； rsyslog 和 ELK 是集中记录的流行选择； Netflix 的 Chaos Monkey，它会随机杀死您生产环境中的服务器，是您最终设置的真正考验。
结论
本文介绍了什么是不可变基础架构、它与旧式可变基础架构之间的概念和实践差异、使用它的优势以及实现细节。
知道是否或何时应该考虑迁移到不可变的基础架构可能很困难，而且没有一个明确定义的分界点或拐点。 开始的一种方法是实施本文中推荐的一些设计实践，例如配置管理，即使您仍在一个很大程度上可变的环境中工作。 这将使将来更容易过渡到不变性。
如果您的基础架构包含上述大多数组件，并且您发现自己遇到了扩展问题或对部署过程的笨拙感到沮丧，那么这可能是开始评估不变性如何改进您的基础架构的好时机。
您可以从几家公司（包括 Codeship、Chef、Koddi 和 Fugue）那里了解更多关于他们的不可变实现的文章基础设施。
