雲原生技術的不斷髮展，2018年，CNCF擴展了雲原生技術的定義，以下是雲原生技術的新定義：
“雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。這些技術能夠構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術使工程師們能夠輕鬆地對系統作出頻繁和可預測的重大變更。“
其中，像容器，微服務等概念早已深入人心，而很多開發人員都對此次提及的“不可變基礎設施”這個概念有不少疑惑，下文將對這個概念進行解析。
其實不可變基礎設施這個概念由來已久，並在不同的場合被很多技術專家已不同的形式提出並討論過, 例如如：
- “Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components”， Chad Fowler， 2013
- “Phoenix Server”， Martin Fowler, 2012
不可變基礎設施裏的“不可變”非常類似於程序設計中的“不可變”概念。程序設計中不可變變量（Immutable Variable）就是在完成賦值後就不能發生更改，只能創建新的來整體替換舊的。由於具有這樣的特性這種變量可以在併發環境下安全的使用。對於基礎設施的不可變性，最基本的就是指運行服務的服務器在完成部署後，就不在進行更改。
在過去依賴傳統的高可靠性基礎設施的時代，服務的可靠性依賴於高可靠性的服務器。然而，這些基礎設施具有很高的擁有成本，並且初始化，配置的成本也非常高（對於大中型機，甚至重啓都是一種奢侈的）。所以，在當時不可變基礎設施的設想是難以實現的，開發人員總是需要在服務器上對運行環境做一下持續的更改，如：系統升級，配置修改，補丁等。在許多手動修改之後，服務器的不同配置的重要性或必要性變得不清楚，因此更新或更改任何配置可能會產生意想不到的副作用（這就導致了 Martin Fowler所說的snowflake server “Phoenix Server”,2012）。
可變基礎設施通常會導致以下問題：
- 在災難發生的時候，難以重新構建服務。持續過多的手工操作，缺乏記錄，會導致很難由標準初始化後的服務器來重新構建起等效的服務。
- 在服務運行過程中，持續的修改服務器，就猶如程序中的可變變量的值發生變化而引入的狀態不一致的併發風險。這些對於服務器的修改，同樣會引入中間狀態，從而導致不可預知的問題。
隨着，虛擬化技術以及建立在這之上的雲計算基礎設施的引入，極大的降低了獲取標準化基礎設施的成本。同時，容器技術的引入也讓我們可以方便的打包構建應用及其運行時的依賴環境，這樣我們就可以方便的構建不可變的，可版本化管理的服務（這裏包括了標準化實例，運行環境及應用服務）。
在構建雲原生時，要實現不變基礎設施我們實踐以下幾點：
- 使用雲端虛擬化基礎設施作爲構建基礎
- 通過容器技術來打包及整體構建服務運行環境
- 實現容器鏡像的自動化構建及版本化管理
- 通過持續部署系統，進行自動化部署
更多內容請關注本人公衆號
