没有按应用架构，就无法实现不可变基础设施

F5

早在2013年，我们就接触到了不可变服务器这一概念。顾名思义，不可变服务器是静态的。其配置固定，无法更改（或者至少不应更改）。如需更改，则使用采用新配置的新服务器替换正在运行的服务器。这种方式尤其适用于云环境和高度自动化的本地环境，因为它可以简化配置，并提高部署自动化系统的可靠性。

这一概念即使应用于网络和应用服务，在云和容器化环境中也能发挥良好作用，但并不太适合传统的共享基础设施架构。

这是因为，共享基础设施本身就意味着有多个服务同时运行。根据F5 iHealth 的数据，这里的“多个”平均可达123个独立配置（虚拟服务器）。如果只是要更改其中一个虚拟服务器，尝试停止并重新部署其余122个虚拟服务器既不切实际，也不建议这样做。

但这并不意味着这一理念不切实际或不可取。要在采用自动化和基础设施即代码（IaC）系统的同时采用不可变基础设施，关键是转向按应用划分的架构。

为何采用不可变基础设施？

为什么要对企业网络架构进行如此重大的调整？请允许我引用一下自己之前的话，因为时至今日，我仍想不到更恰当的表述方式：

因为熵。

软件熵定律由Ivar Jacobson等人在《面向对象软件工程：用例驱动方法》中提出：

原则上，热力学第二定律指出，封闭系统的无序程度无法降低，只能保持不变或增加。衡量这种无序程度的指标是熵。这一定律似乎也适用于软件系统；随着系统不断修改，其无序程度（即熵）总会增加。这称为软件熵。

这一定律也适用于必须进行固件或系统级更新、部署热修复和补丁的系统，也适用于需要紧急调整配置的系统。理想情况下，这类配置变更只能通过严格遵循的变更管理流程来实施。不可变（一次性）基础设施试图解决的问题是：对系统所做的变更越多，系统似乎就会变得越臃肿、越不稳定。无序。混乱。熵。

这不仅涉及为应用提供服务而更改配置，或针对最近发现的某个漏洞紧急部署虚拟补丁。这些都是更改应用服务配置的充分理由，但并非全部。热修复、补丁和版本依赖关系也可能需要您更改共享基础设施上运行的123项配置之一。

通过转向按应用划分的架构，可以避免其中1个、2个甚至10个实例干扰共享基础设施上运行的其他100个实例。实质上，为每个应用提供独立的数据路径，可为采用不可变基础设施方法奠定基础，从而更好地支持向基于基础设施即代码的自动化部署实践转型。

这意味着采用完全基于软件的应用服务管道，并以类似于在容器内部署微服务的方式，按照“微应用服务”架构部署应用服务。

Julian Dunn在Chef的博客中对此作了精辟阐述：不可变基础设施：实用还是不实用？

不可变基础设施通常是指这样一种技术栈：只构建一次（可以是虚拟机镜像、容器镜像或其他形式），运行一个或多个实例，此后不再更改。其部署模式是终止实例或容器，然后从第一步重新开始：构建新镜像并弃用旧实例。

因此，如果将这一理念应用于与特定应用耦合最紧密（具有亲和性）的应用服务，就会形成一种双层网络架构：核心层提供通用共享服务（例如网络DDoS防护，以及通过传统的基于端口的防火墙进行访问控制），并连接到每个应用各自的“堆栈”。该堆栈被视为不可变基础设施，并采用基础设施即代码理念进行部署和管理。

但如果没有按应用划分的基础设施，就无法真正实现不可变基础设施，因为需要先将相关应用服务与其共享平台解耦。如果可以使用同一平台，只是采用软件形态，这一过程会更加轻松，因为所需的大量知识和工具集已经具备，可以全力推进按应用划分的不可变模型。

即使您并未考虑采用真正的不可变基础设施，也可以在最合适的时机（例如发布新的基础设施版本、热修复或补丁时）利用这种模式，从而减轻您和该基础设施所支持应用的DevOps负责人的工作负担。

关于作者

F5

F5 的更多博客文章