雪花服务器模式和凤凰服务器模式这两个概念是围绕服务器集群管理的重要概念。这些方法主要围绕如何处理配置偏差：

“由于手动的临时更改和更新，随着时间推移，加上熵增效应，基础设施中的服务器变得越来越多样化” — Kief Morris

一个 _雪花服务器_ 是一个具有独特配置的服务器，这种配置很难复制。随着时间的推移，服务器会积累越来越多的手动配置、调整和更新，这使得服务器难以重新创建或替换。这种独特性使得服务器在可扩展性、可靠性和维护性方面存在问题。

_雪flake服务器_就像真正的雪花一样，既脆弱又独特。当_雪flake服务器_出问题时，如果没有人工干预，几乎不可能恢复到之前的精确状态。

“然而，当你需要改变雪花时，真正的脆弱性就显现出来了。雪花很快变得难以理解和调整。即使是最细微的软件升级也会带来不可预测的影响。” — 马丁·福勒

一个 凤凰服务器（Phoenix server），就像它的象征一样，从灰烬中重生。服务器在被销毁后会通过自动化过程从零开始重建。配置是完全脚本化和版本控制的，这样就可以通过运行适当的脚本从相同的配置重新创建一个完全相同的服务器。

_凤凰服务器_是有弹性的，因为它们被设计成替换和重建而不是修复。当一个凤凰服务器遇到问题时，它会被销毁并重新创建，而不是手动修理。

“服务器应当像凤凰一样，定期从灰烬中浴火重生。” — Martin Fowler

舰队管理的演变已经从管理独特的“雪花服务器”转变为使用基础设施即代码（IaC，即代码即基础设施）自动部署和维护“凤凰服务器”。这一演变反映了从铁器时代到云时代的更广泛转变。

在铁器时代（即铁质时代），物理服务器——常被称为“铁”或“裸金属”——是托管和运行应用的主要途径。

相比之下，云时代带来了虚拟化的基础设施，其中计算资源如虚拟机和容器可以通过AWS（2006）、Google云（2008）和Azure（2014）等云服务商轻松地部署、扩展和管理。

在 IT行业的铁器时代 ， 独特的服务器 通常需要手动设置和维护，这使得它们难以复制或扩展规模。然而，随着如 Kickstart（1999年）和 Preseed（2005年）这样的系统配置工具的出现，以及配置管理平台如 CFEngine（1993年），Puppet（2005年）和 Chef（2009年），自动化的机会也开始出现。

配置工具帮助建立了基线配置，例如安装SSH密钥用于部署。配置管理平台接着确保服务器保持所需状态，这一过程叫做收敛，使用自动脚本，比如Puppet清单或Chef配方。

尽管有了这些进步，自动化配置工具仍然只管理了系统状态的一部分，留下了空缺。正如凯夫·莫里斯所指出的：

“自动化配置工具的挑战在于只能管理机器状态的一部分。编写和维护这些清单、配方或脚本需要花费大量时间，因此，大多数团队倾向于专注于系统最重要部分的自动化，从而在其他地方留下了较大的空白。”

随着时间的推移，这些未追踪的状态可能会发生变化，导致不可靠性和安全漏洞。例如，可能会安装一个带后门的恶意SSH程序，或者未被发现地添加了一个有风险的SSH配置。

在许多环境中，自动化脚本仅仅反映了经过点测试或在故障期间遇到的情况，通常是基于一个未知但功能正常的状态构建，而不是从零开始。这种方法降低了可靠性和安全性，使得强调从已知的干净状态重建服务器的 凤凰服务器 方法成为更好的选择。

云时代引入了使用凤凰服务器模式来配置和扩展服务器群的新方式。这种方法从准备好的镜像（使用如Packer之类的工具制作）启动系统，并使用诸如cloud-init（2008）这样的自动化工具来配置它们。进一步的调整则通过诸如Puppet（2005），Chef（2009），Salt Stack（2011）和Ansible（2012）这样的变更配置工具进行管理。

基础镜像通过自动化工具进行构建，这些工具集成了系统配置技术，确保部署的一致性。流行的自动缩放解决方案，例如 AWS 的 Auto Scaling Groups (ASG)，Google 的 Managed Instance Groups (MIG)，以及 Azure 的 Virtual Machine Scale Sets (VMSS)，可以高效地管理这些系统。

关键在于从图像生成到系统设置的完全自动化流程。当系统不符合规定时，它们将被自动替换为新的实例，体现了“凤凰服务器”模式的理念，即系统会被彻底重建。

不可变基础设施是基于_Phoenix Server_模式构建的，这种方式使用预烘焙的映像，这些映像包含了大部分配置和状态。这种方法确保任何可变状态，比如动态数据库地址，都可以在部署时注入，从而保持一个干净和统一的环境。

一开始，使用诸如VMSS、MIG和ASG等云自动扩展解决方案来部署不可变基础设施。这些技术通过使用内置配置的镜像来管理机群，从而减少对就地修改的需求并降低配置漂移的可能性。

容器化的兴起进一步巩固了不可变基础设施的概念，使其无处不在。容器将配置封装在镜像中，简化了将镜像部署到运行中的容器。这一演变催生了更高级的编排平台如Kubernetes（2014年），Swarm（2014年），和Nomad（2015年），这些平台进一步扩展了不可变基础设施的能力。

这些平台特别支持有状态的应用程序——这一功能在云自动扩展服务中难以实现，这使得它们在管理分布式数据库和其他有状态服务时变得不可或缺。

自动化工具，如Packer（2013），在这样的生态系统中非常重要，能够用于创建云自动扩展解决方案和容器编排平台所需的图像，确保在不同环境中的一致性和可靠性部署。

咱们来总结一下。

无论您是使用裸机服务器还是云基础设施，采用_Phoenix server_模式——即系统定期被销毁并从头开始重建——都能为不可变和可变的基础设施架构提供最高的可靠性和最低的维护成本。虽然今天的自动化工具使得这种方法变得经济实惠，但成功的关键在于组建一支具备所需设计模式和相关技术专长的团队的必要性。

实现这些高级基础设施模式不仅仅依赖于正确的工具；这需要一支团队具备对基础设施设计模式、持续集成与交付流水线以及安全最佳实践的深刻理解。Phoenix服务器模式等现代实践的有效性依赖于这一点。

现代自动化实践利用“基础设施即代码”（IaC），将脚本存储在版本控制系统中，以确保更改可以被测试、扫描安全漏洞并接受同行评审。在这样的背景下，基础设施和应用程序层的持续集成（CI）和持续交付（CD）管道需要是独立且关键的。这些管道还应遵循设计原则，如职责分离和单一职责。

服务发现 在动态的基础设施中至关重要，它让服务能够找到彼此，并在必要时通过故障转移自动恢复。工具如 Consul、Eureka 以及 Kubernetes 内置的服务发现功能便于实现这一功能。

为了实现安全和先进的网络连接，像Linkerd和Istio这样的服务网格技术管理微服务和其他分布式集群中的安全的服务间通信。这些技术支持流量分发，这对于蓝绿部署和金丝雀发布至关重要，允许新版本的应用程序与现有版本并行运行，从而减少停机时间并降低风险。混沌工程工具，如Chaos Monkey进一步通过故意引发故障来测试此基础设施的韧性，确保系统能够像凤凰一样从故障中迅速恢复。

我之前讨论过的一个相关概念是宠物 vs 牛群 类比，将一次性基础设施（例如：牛群）比作牛群，将不可替代的基础设施（例如：宠物）比作宠物。这与 凤凰服务器 模式非常匹配，在该模式中，服务器被视为可替换单元，不论它们运行在可变基础设施还是不可变基础设施中。

然而，这种类比在考虑_Snowflake服务器_时就不适用了。虽然_Snowflake服务器_本身并不是一次性使用的，但它们仍然可以从中受益于自动化，将其配置调整到期望的状态，并在需要时进行修复，从而为传统的独特服务器带来一些类似集群管理的好处。

随着基础设施的不断发展，自动化、不可变性和韧性这些原则变得越来越重要，以确保系统的可靠、可扩展和成本效益。不论是管理云机群还是裸机服务器，理解并应用这些模式对于驾驭现代基础设施的复杂性至关重要。

一个 snowflake 服务器 是通过配置运行中的系统来构建的，称为 调制 ，而 phoenix 服务器 则可以通过从头配置系统，称为 调制 ，或者将配置嵌入到一个映像中，称为 烘焙。

• Phoenix Server by Martin Fowler on July 10, 2012
• Snowflake Server by Martin Fowler on July 10, 2012
• Immutable Server by Kief Morris on June 13, 2013
• Configuration Drift on December 6, 2011
• 迁移到Phoenix服务器模式 — 第一部分：介绍 by Ama Asare on July 15, 2015
• 迁移到Phoenix服务器模式 — 第二部分：需要考虑的因素 by Pablo Porto on September 15, 2015
• 恢复策略的演变：迁移到Phoenix服务器模式第三部分 by Laura Ionescu on February 26, 2016
• Russ McKendrick的Kubernetes与无服务器应用
• 配置漂移：Phoenix服务器与Snowflake服务器漫画 by Digital Ocean on March 26, 2018
• 大规模服务器群管理指南：AWS实施 by Rob Barnes in June 2018