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