軟體交付的終態是提供穩定可預期的系統，要做到這一點，我們需要確保：一、軟體製品的一致性；二、執行環境的一致性。

第3講我們分享瞭如何保證軟體製品的一致性，這一講我們來談談如何保證環境的一致性。

執行環境一致性的目標是環境可預期、穩定、低成本。其中低成本比較關鍵，因為環境資源的成本一般比較高。

我們可以將執行環境分為3部分：製品、執行引擎和編排規則。

要保證製品的一致性，第一是保證程式碼及其依賴的一致性；第二是保證構建環境的一致性；最後是保證構建指令碼的一致性。保證環境的一致性，也包含了三點：

1。

應用的一致性

，比如一致的容器映象；

2。

容器執行所需的上下文的一致性

，比如一致的資料配置等；

3。

編排規則的一致性

，需要保證編排執行相同的規則，比如相同容器部署規則、相同節點分佈規則、相同備份規則等。

保證這3點，部署完成之後才會形成一致的可執行環境。但是現實當中，環境還是會有很多其它的問題，比如：

配置檔案中有好多監控之類的配置，對於使用者來說，不知道配置的具體作用，需要修改時不知如何設定。

測試的時候依賴的環境經常發生問題，耗費大量等待和排查時間。比如說依賴的API經常出問題，排查修復可能需要等待依賴方很久，導致測試工作無法繼續進行。

新環境的搭建很耗時。搭建一個新的環境是很痛苦的事情，比如國際化團隊，經常要搭建新的站點，而每搭一個新的環境就要耗費一整天的時間是很痛苦的。

應用在本地無法執行。比如因為缺某個資源導致應用無法正常執行。

配置環境需要小心翼翼，可能出現配置遺漏。每次配環境的時候需要很小心，特別是當環境配置由多人配合時，會出現配置衝突，導致程式無法執行，需要全鏈路排查解決。

這裡我們簡單列了五個常見的問題，它們的根源都是環境缺乏清晰的定義：

不清楚環境的具體內容、對環境搭建過程的認知模糊

。

環境的清晰定義，包括環境包含什麼製品、這些製品如何部署等。那麼環境管理的終態是什麼呢？

當製品相同、執行上下文相同，並且資源資料是一樣的情況下，基於相同的編排規則，環境就應該是一致的。同時，環境可以由軟體來定義和宣告。這是我們認為的環境管理的終態，簡單來說，即軟體定義的不可變環境。軟體定義的不可變環境，可以納入版本管理，保證環境首先是定義明確的，其次是有明確版本的。

環境管理的3個階段

階段一：說明書

環境管理的第一個階段是說明文件，這點相信很多人都經歷過。當我們在做一個專案或產品時，會寫整個產品的部署說明書、說明文件、升級文件等各種文件。但文件很難保證實用，也不一定是最新的、準確的。每次我們去現場交付時，都會遇到一些文件裡沒有描述的問題。這時候還得打電話確認，是否有遺漏什麼。用文件或說明書去管理環境，存在很大的弊端，所以我們想到了用命令的方式去管理。

階段二：命令

第二階段，我們透過命令的方式，寫了各種shell、Python指令碼，把相關命令組合在一起。之前我們在做一個產品的私有化交付的時候，一開始的做法就是用指令碼去管理環境，因為開啟一個新環境實在太痛苦了，需要花很多時間改引數、找包、配IP等，效率太低。所以我們寫了指令碼來管理，用指令碼代替了文件。

但是用指令碼管理環境也存在很多問題。我們要應對各種各樣的環境，同一個任務在不同的場景裡，命令組合可能是不一樣的，所以指令碼會越來越多，維護指令碼的成本也越來越高。

階段三：宣告

為了解決命令指令碼的維護和穩定性問題，我們進入了第三個階段，宣告式——透過配置的方式表達環境，把環境定義出來。宣告式的描述提供了環境的確定性表達。

以 k8s 為例，我們以一個例子來看，如何做環境宣告

上圖是K8S的簡單架構，左上角是K8S的master，左下角是node，master有好幾個元件：scheduler、ControllerManager、APIserver，以及Etcd。Etcd是一個分散式儲存，配置資訊都在Etcd裡面。Node是物理機或者虛擬機器，在每一個Node上面會有多個pod，上面會執行很多的容器。

我們知道K8S的最小單元是pod，裡面有容器，還有各種網路儲存等，透過pod宣告去描述。宣告被apply後，具體的事情在controller裡面處理。

透過 Sidecar 分離關注點

我們寫一個應用，這個應用裡面大量的程式碼其實與業務無關，而是包含很多服務治理的程式碼，例如日誌、監控、限流、熔斷等。這些程式碼佔了很大的比重，而且這些程式碼的維護者和應用開發者不一定是同一批人。服務治理相關的程式碼，在很多企業會有專門的團隊負責維護和升級，類似阿里的中介軟體團隊。傳統的情況下，我們需要升級並重新部署應用才能升級服務治理能力。但是在雲原生時代，應用開發者希望僅關注應用業務程式碼，服務治理相關的程式碼放在其他的容器裡面，業務容器和服務治理容器通常會編排在同一個pod裡面，但是服務治理容器的管理、開發、釋出都跟應用開發者沒有關係，這些就是sidecar容器。sidecar容器實現了關注點的分離，應用的開發者和中介軟體的開發者以及運維相關的開發者，都可以有自己的關注點。

我們以兩個角色為例，一是業務的開發者，關注的是應用的容器，所以釋出的時候，他的關注點都在應用容器這一塊。二是企業的SRE，他的關注點往往在sidecar的各種服務治理容器上，比如logagent的日誌級別和取樣率是否合理等。

透過sidecar，業務開發者和SRE的關注點就分離了。這樣分離還有一個好處，就是中介軟體下沉，都以sidecar的方式管理。一旦遇到相應的中介軟體需要升級，業務程式碼不需要做任何的改變和釋出，只需要做sidecar的釋出就好了。

我們前面提到，一致的環境需要有3個組成部分：相同的製品、相同的執行上下文以及相同的編排規則。相同的執行上下文，本質就是裡面的配置要一致。最早我們是用文件告訴我們怎麼把環境管理起來，之後用指令碼，最後用環境宣告。

然而，用宣告式的方式定義環境也並不完美。舉個具體的例子，在應用執行的時候需要有一些相應的配置，中介軟體、基礎資源、CPU、儲存等都需要配置，這樣會面臨一個很大的問題——環境相關的配置太多了。

環境相關的配置太多，該怎麼管理好呢？

透過 IaC 來定義環境

為了解決這個問題，業內採用了IaC的概念（InfrastructureasCode）。早期在雲機房上架的時候會用到IaC，比如有一個新的機器過來，要裝成centos7的系統，裡面要配特定的DNS服務等等。這是就會定義一個宣告檔案，傳送給saltstack這樣的工具。現在整個環境都是透過基礎設施來描述出來的，所以整個環境包括中介軟體的資源都是基礎設施了，在範圍上比原先要廣的多。

從配置的角度，我們有應用配置、運維配置、基礎設施運維配置，甚至軟體生產過程的配置。我們把應用程式碼和IaC程式碼，放在兩個庫裡面（也有放到一個庫裡面的，各有利弊，在此我們不展開也不評價）。

比如上圖中，在IaCRepo裡我們放了動態配置（即執行時的配置）、BaaS配置（基礎設施，如資料庫、中介軟體儲存、訊息佇列等）、監控配置（如監控粒度、取樣頻率）、釋出配置等。所有的配置都宣告在程式碼庫裡面，基於該宣告編排的所有環境就都是一致的了。

任何事情都是有利有弊，用IaC的方式管理環境又會帶來什麼新的挑戰呢？

首先是“靈活的代價”

。因為所有的配置都是鬆散的文字，缺少統一的聚合根，導致修改者需要自己理解這些配置背後對應的依賴關係。比如某個配置項設定為on會開啟限流，但是必須配合特定的configMap一起使用；比如開啟了一個Ingress外掛，但如果另一個Rollout外掛沒有開啟，會無法正常工作；再比如HPA和CronHPA無法同時使用，會產生衝突。由於編寫的靈活性，會導致無窮的組合形式，其組合產生的後果往往在執行時才會發現。

其次是知識的成本

。IaC將一個環境所有的配置都以文字的介面給到了開發者，但是很多配置項是需要專業背景的，比如運維相關的策略、比如監控的配置方式等等，價值IaC本身的學習成本，往往讓很多開發者望而生畏。

為了解決這個問題，阿里聯合微軟一起釋出了OAM模型，以應用為統一維度，將IaC包含的各類資源和角色進行了分類和聚合。

首先，OAM引入了應用（Application）的概念，將應用的各類IaC配置都聚合在一起，解決其依賴問題。

其次，OAM將IaC的使用者分離為：應用開發者、應用運維、基礎設施運維三大角色，彼此的關注點進行了分離。

OAM抽象和簡化了IaC的定義和維護方式，降低開發者的學習和使用成本。

總結一下，我們認為，環境管理的終態是軟體定義的不可變環境，而當下，它的最佳實踐我們認為是基於OAM模型的、以應用為核心的IaC宣告。

雲效雲原生應用管理平臺AppStack正是基於OAM的應用交付平臺，企業在雲效AppStack，可以透過應用編排、佔位符、變數等宣告式定義，實現一套編排多環境差異化部署，同時基於版本和基線實現環境一鍵拉起、一鍵回滾。感興趣的同學點下方連結即可免費使用。

免費使用：https：//www。aliyun。com/product/yunxiao/appstack