我对类型有一个大致的了解，但是在某些情况下（当自动化变得复杂时）在它们之间进行选择时，参考矩阵会有所帮助。例如应用程序。）
为了避免担心它过于广泛，我认为将其拆分为多个问题会分散信息，并且有关安全性比较的问题也需要比较每种类型。
#1 楼
Phoenix Server一词是由Martin Fowler的一个人创造的，而这三个术语在Martin的bliki的短文中都有描述。雪花服务器
凤凰服务器
不可变服务器
文章中介绍了每种服务器的优缺点。主要区别在于服务器的管理方式。
服务器的存在是为了满足某些应用程序的容器作用。由于应用程序经常更改，因此经常需要更改容器的某些属性，例如程序包，配置等。有时还需要由于外部原因而更改容器本身的属性，例如需要修补程序的安全漏洞。
有几种更改现有服务器的方法：
首先手动创建服务器，然后每次更改服务器的内容（变异）需要更改。
通常以自动化方式（而非手动方式）为基于“配方”的服务器“烘焙”图像。然后从该映像创建服务器。并对每个更改重复此过程。
前者称为Snowflake，而后者是一种允许使用Phoenix和Immutable服务器类型的实践。不可变表示在创建现有服务器后不会对其进行任何更改，而Phoenix则表示服务器已完全销毁，并且在更改过程中将使用新服务器替换它。
#2 楼
当我更想列出每种类型的优点和缺点时，这是我的观点（并非详尽无遗，这是我认为重要的操作观点）：雪花服务器
它们是什么：具有特定配置的系统，数据中心中没有其他服务器具有完全相同的参数。通常，它们是手动管理的。
优点：
满足正在运行的需求。
长期更新通常是短裤。
适用于托管产品很好地记录了调整的特殊情况。
缺点：
有时更新会保留未使用的文件，因此清理可能很复杂。
当必须对多台机器进行更改时，需要花费一些时间。
没有什么可以防止未记录的更改。
如果发生损坏，则必须重建基本操作系统并进行还原，某些操作系统的调整无法还原，应重新应用，很容易越过一条线而忘记重要的调整。
通常由于手动配置而无法提供。
Phoenix服务器
/>是什么：由某些代码自动配置。
优点：
由代码定义，可版本控制。
轻松复制到某个时间点。
寿命长，更新也短。
对受控文件的更改已记录在案，不能忘记。
缺点：
有时更新会留下未使用的文件，因此清理可能很复杂。
并非所有内容都在代码管理下，如果不包括在自动化中，人为的调整可能会丢失。
不可变服务器
它们是什么：
从主映像自动进行一次自动置备，通常没有访问权限。
/>优点：
由代码定义，可版本控制。
轻松复制到某个时间点。
由于通常删除了远程访问，因此减少了攻击面。
固定的配置，没有任何变化可以破坏某些内容
从主映像轻松扩展“按需”。 >
缺点：
它们是不可变的，您必须确保可以快速发布更新，以防0day缺陷影响您。
并非所有的应用程序都适合该模型（例如，数据库不可能总是完全替换相同的数据，需要进行迁移）。
为崩溃和日志管理的取证分析带来了一些新挑战。
这些模式都不是唯一的，您拥有根据您的实际需求选择最佳的。雪花给灾难后的恢复带来了很多问题，因此通常在Phoenix和Immutable之间进行选择。
#3 楼
这三种都是不同的模式，不是在任何特定情况下选择使用哪种模式的情况，而是知道何时识别可以帮助或伤害您的模式的情况。Snowflake Server
Snowflake Server非常类似于一种反模式，代表了服务器以不受控制的方式发展到无法轻松复制的情况。
我这种服务器在生产中已经有大量的磨合，它们很容易发现，因为通常会有大量失败的更改和注释，例如“ [更改]在Development / Test / UAT / Staging中起作用” 。
Phoenix Servier
Phoenix Server更像是主体，而不是Martin Fowler所说的模式：
服务器应该像凤凰，定期从灰烬中升起。 IT服务C连续性计划或恢复计划：
每个服务的单独计划应为事件的每个阶段提供详细的过程和分步指南，以便恢复团队能够恢复服务，从而满足商定的流程和组件RTO。
不可变服务器
不可变服务器或不可变基础结构是我们对待所有部署的过程基础设施，配置和代码完全不变，即不变。当我们部署任何新内容时，我们会启动新的基础架构并将代码部署到此基础架构。有趣的是，这基本上满足了Evergreening传统上可以满足的需求。
注意事项内部讨论列表上的“ Phoenix Server”一词。