云原生定义解析—不可变基础设施 （immutable infrastructure)

云原生技术的不断发展，2018年，CNCF扩展了云原生技术的定义，以下是云原生技术的新定义：

“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师们能够轻松地对系统作出频繁和可预测的重大变更。“

其中，像容器，微服务等概念早已深入人心，而很多开发人员都对此次提及的“不可变基础设施”这个概念有不少疑惑，下文将对这个概念进行解析。

其实不可变基础设施这个概念由来已久，并在不同的场合被很多技术专家已不同的形式提出并讨论过, 例如如：

1. “Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components”， Chad Fowler， 2013
2. “Phoenix Server”， Martin Fowler, 2012

 

不可变基础设施里的“不可变”非常类似于程序设计中的“不可变”概念。程序设计中不可变变量（Immutable Variable）就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不在进行更改。

 

在过去依赖传统的高可靠性基础设施的时代，服务的可靠性依赖于高可靠性的服务器。然而，这些基础设施具有很高的拥有成本，并且初始化，配置的成本也非常高（对于大中型机，甚至重启都是一种奢侈的）。所以，在当时不可变基础设施的设想是难以实现的，开发人员总是需要在服务器上对运行环境做一下持续的更改，如：系统升级，配置修改，补丁等。在许多手动修改之后，服务器的不同配置的重要性或必要性变得不清楚，因此更新或更改任何配置可能会产生意想不到的副作用（这就导致了 Martin Fowler所说的snowflake server “Phoenix Server”,2012）。

 

可变基础设施通常会导致以下问题：

1. 在灾难发生的时候，难以重新构建服务。持续过多的手工操作，缺乏记录，会导致很难由标准初始化后的服务器来重新构建起等效的服务。
2. 在服务运行过程中，持续的修改服务器，就犹如程序中的可变变量的值发生变化而引入的状态不一致的并发风险。这些对于服务器的修改，同样会引入中间状态，从而导致不可预知的问题。

 

随着，虚拟化技术以及建立在这之上的云计算基础设施的引入，极大的降低了获取标准化基础设施的成本。同时，容器技术的引入也让我们可以方便的打包构建应用及其运行时的依赖环境，这样我们就可以方便的构建不可变的，可版本化管理的服务（这里包括了标准化实例，运行环境及应用服务）。

 

在构建云原生时，要实现不变基础设施我们实践以下几点：

1. 使用云端虚拟化基础设施作为构建基础
2. 通过容器技术来打包及整体构建服务运行环境
3. 实现容器镜像的自动化构建及版本化管理
4. 通过持续部署系统，进行自动化部署

 

更多内容请关注本人公众号