介紹
在傳統的可變服務器基礎架構中，服務器會不斷更新和修改。使用此類基礎架構的工程師和管理員可以通過SSH連接到他們的服務器，手動升級或降級軟件包，逐個服務器地調整配置文件，以及將新代碼直接部署到現有服務器上。換句話說，這些服務器是可變的;它們可以在創建後進行更改。由可變服務器組成的基礎設施本身可稱爲可變，傳統或（貶低）手工藝。
不可變基礎架構是另一種基礎架構範例，其中服務器在部署後永遠不會被修改。如果需要以任何方式更新，修復或修改某些內容，則會根據具有相應更改的公共映像構建新服務器以替換舊服務器。經過驗證後，它們就會投入使用，而舊的則會退役。
不可變基礎架構的好處包括基礎架構中更高的一致性和可靠性，以及更簡單，更可預測的部署過程。它可以緩解或完全防止可變基礎架構中常見的問題，例如配置漂移和雪花服務器。但是，有效地使用它通常包括全面的部署自動化，雲計算環境中的快速服務器配置，以及處理狀態或短暫數據（如日誌）的解決方案。
本文的其餘部分將：
- 解釋可變和不可變基礎架構之間的概念和實際差異
- 描述使用不可變基礎架構的優勢並將複雜性置於語境中
- 概述不可變基礎架構的實現細節和必要組件
可變和不可變基礎設施之間的差異
可變基礎和不可變基礎設施之間最根本的區別在於它們的核心政策：前者的組件旨在在部署後進行更改;後者的組成部分旨在保持不變並最終被替換。本教程將這些組件作爲服務器，但是還有其他方法可以實現不可變的基礎結構，例如容器，它們應用相同的高級概念。
爲了更深入，基於服務器的可變基礎架構和不可變基礎架構之間存在實際和概念上的差異。
從概念上講，這兩種基礎設施在處理服務器的方法（例如創建，維護，更新，銷燬）方面差異很大。這通常用“寵物與牛”類比來說明。
實際上，可變基礎架構是一種更老的基礎架構範例，它早於核心技術，如虛擬化和雲計算，使不可變的基礎架構成爲可能和實用的。瞭解這段歷史有助於將兩者之間的概念差異以及在現代基礎設施中使用其中一個或另一個的含義進行背景化。
接下來的兩節將更詳細地討論這些差異。
實際差異：擁抱雲
在虛擬化和雲計算成爲可能並且廣泛可用之前，服務器基礎架構以物理服務器爲中心。這些物理服務器創建起來既昂貴又耗時;初始設置可能需要數天或數週，因爲訂購新硬件，配置機器，然後將其安裝在colo或類似位置需要多長時間。
可變基礎設施起源於此。由於更換服務器的成本非常高，因此儘可能在儘可能短的停機時間內儘可能長時間地使用您運行的服務器是最實際的。這意味着對於常規部署和更新有很多適當的更改，但對於出現問題時的臨時修復，調整和補丁也是如此。頻繁手動更改的結果是服務器變得難以複製，使每個服務器成爲整個基礎架構中獨特且易碎的組件。
虛擬化和按需/雲計算的出現代表了服務器架構的轉折點。虛擬服務器雖然規模較小，但成本較低，可以在幾分鐘而不是幾天或幾周內創建和銷燬。這使得新部署工作流和服務器管理技術首次成爲可能，例如使用配置管理或雲API快速，編程和自動配置新服務器。創建新虛擬服務器的速度和低成本使得不變性原則變得切實可行。
傳統的可變基礎設施最初是在使用物理服務器決定其管理可行性時開發的，並且隨着技術的不斷改進而不斷髮展。在部署之後修改服務器的範例在現代基礎設施中仍然很常見。相比之下，不可變基礎架構從一開始就設計爲依賴基於虛擬化的技術來快速配置架構組件，如雲計算的虛擬服務器。
概念差異：寵物與牛，雪花與鳳凰
雲計算先進的基本概念變化是服務器可以被認爲是一次性的。考慮丟棄和更換物理服務器是非常不切實際的，但使用虛擬服務器，這樣做不僅可行而且簡單有效。
傳統可變基礎架構中的服務器是不可替代的，獨特的系統必須始終保持運行。通過這種方式，它們就像寵物一樣：獨一無二，無法模仿，並且傾向於手工製作。失去一個可能是毀滅性的。另一方面，不可變基礎架構中的服務器是一次性的，易於複製或使用自動化工具進行擴展。通過這種方式，他們就像牛一樣：牛羣中的衆多羣體中沒有一個人是獨一無二或不可或缺的。
引用Randy Bias，他首先將寵物與牛類比應用於雲計算：
在舊的做事方式中，我們將服務器視爲寵物，例如Bob郵件服務器。如果鮑勃摔倒，那就全都動手了。首席執行官無法收到他的電子郵件，這是世界末日。以新的方式，服務器被編號，就像牛羣中的牛一樣。例如，www001到www100。當一臺服務器發生故障時，它會被取回，射擊並在線路上更換。
另一種類似的方式來說明服務器處理方式之間差異的含義是雪花服務器和鳳凰服務器的概念。
雪花服務器類似於寵物。它們是手工管理的服務器，經常更新和調整到位，從而形成獨特的環境。 Phoenix服務器與牛類似。它們是始終從頭開始構建的服務器，並且易於通過自動化過程重新創建（或“從灰燼中升起”）。
不可變的基礎設施幾乎完全由牛或鳳凰服務器製成，而可變基礎設施允許一些（或許多）寵物或雪花服務器。下一節將討論兩者的含義。
不可變基礎設施的優勢
要了解不可變基礎架構的優勢，有必要將可變基礎架構的缺點置於語境中。
可變基礎架構中的服務器可能會受到配置偏差的影響，這種情況在未記錄的情況下，即興更改會導致服務器的配置變得越來越不同，並且與審覈，批准和最初部署的配置之間的配置越來越不同。這些越來越像雪花的服務器難以重現和替換，使得縮放和恢復問題變得困難。即使複製問題來調試它們也會變得具有挑戰性，因爲創建與生產環境匹配的臨時環境很困難。
在許多手動修改之後，服務器的不同配置的重要性或必要性變得不清楚，因此更新或更改任何配置可能會產生意想不到的副作用。即使在最好的情況下，也不能保證對現有系統進行更改，這意味着依賴於這樣做的部署可能會導致失敗或將服務器置於未知狀態。
考慮到這一點，使用不可變基礎架構的主要好處是部署簡單性，可靠性和一致性，所有這些最終可以最大限度地減少或消除許多常見的痛點和故障點。
已知良好的服務器狀態和較少的部署失敗
不可變基礎架構中的所有部署都是通過基於經過驗證和版本控制的映像配置新服務器來執行的。因此，這些部署不依賴於服務器的先前狀態，因此不會失敗 - 或者只是部分完成 - 因爲它。
配置新服務器時，可以在投入使用之前對其進行測試，將實際部署過程減少到單個更新，以使新服務器可用，例如更新負載均衡器。換句話說，部署變爲原子：要麼成功完成，要麼沒有任何變化。
這使得部署更加可靠，並且還確保始終知道基礎結構中每個服務器的狀態。此外，此過程可以輕鬆實現藍綠色部署或滾動版本，這意味着無需停機。
沒有配置漂移或雪花服務器
通過使用文檔檢查更新的映像到版本控制並使用自動，統一的部署過程來部署具有該映像的替換服務器來實現不可變基礎結構中的所有配置更改。 Shell訪問服務器有時完全受限制。
通過消除雪花服務器和配置漂移的風險，這可以防止複雜或難以重現的設置。這還可以防止有人需要修改一個知之甚少的生產服務器，這種生產服務器存在高錯誤風險並導致停機或意外行爲。
一致的登臺環境和輕鬆的水平擴展
由於所有服務器都使用相同的創建過程，因此沒有部署邊緣情況。通過簡化複製生產環境，可以防止混亂或不一致的登臺環境，並通過無縫地允許您向基礎架構添加更多相同的服務器來簡化水平擴展。
簡單的回滾和恢復過程
使用版本控制來保留圖像歷史記錄也有助於處理生產問題。用於部署新映像的相同過程也可用於回滾到舊版本，在處理停機時添加額外的彈性並縮短恢復時間。
不可變基礎設施實施細節
不可變的基礎架構在其實現細節方面有一些要求和細微差別，特別是與傳統的可變基礎架構相比。
通過簡單地遵循不變性的關鍵原則，技術上可以實現獨立於任何自動化，工具或軟件設計原則的不可變基礎設施。但是，強烈建議使用以下組件（大致按優先順序）以實現大規模實用性：
- 雲計算環境中的服務器，或其他虛擬化環境（如容器，但會改變下面的一些其他要求）。這裏的關鍵是通過自定義映像快速配置隔離實例，以及通過API或類似工具創建和銷燬的自動化管理。
- 整個部署管道的完全自動化，理想情況下包括創建後的圖像驗證。設置此自動化會顯着增加實施此基礎架構的前期成本，但這是一次性成本，可以快速攤銷。
- 面向服務的體系結構，將您的基礎架構分離爲通過網絡進行通信的模塊化邏輯離散單元。這使您可以充分利用雲計算的產品，這些產品同樣面向服務（例如IaaS，PaaS）。
- 無狀態，易變的應用程序層，包括您的不可變服務器。這裏的任何東西都可以在任何時候（易變）快速銷燬和重建，而不會丟失任何數據（無狀態）。
- 持久數據層，包括：
- 集中式日誌記錄，包含有關服務器部署的其他詳細信息，例如通過版本或Git提交SHA進行映像識別。由於服務器在此基礎結構中是一次性的（並且經常處理），因此即使在限制shell訪問或服務器被銷燬之後，外部存儲日誌和指標也允許調試。
- 數據庫和任何其他有狀態或短暫數據的外部數據存儲，如DBaaS /雲數據庫和對象或塊存儲（雲提供或自我管理）。當服務器易變時，您不能依賴本地存儲，因此您需要將該數據存儲在其他位置。
- 工程和運營團隊致力於協作並致力於該方法。對於最終產品的所有簡單性，在不可變的基礎架構中有許多移動部件，沒有人會知道所有這些部件。此外，在此基礎架構中工作的某些方面可能是新的或在人們的舒適區之外，例如調試或在沒有shell訪問的情況下執行一次性任務。
有許多不同的方法來實現這些組件。選擇一個主要取決於個人偏好和熟悉程度，以及您希望自己構建多少基礎架構而不是依賴付費服務。
CI / CD工具可以成爲部署管道自動化的好地方; Compose是DBaaS解決方案的一個選項; rsyslog和ELK是集中式日誌記錄的流行選擇; Netflix的混沌猴在你的生產環境中隨機殺死服務器，對你的最終設置來說是一次真正的試驗。
結論
本文介紹了不可變基礎架構，它與舊式可變基礎架構之間的概念和實際差異，使用它的優勢以及實現的詳細信息。
知道是否或何時應該考慮遷移到不可變的基礎設施可能很困難，並且沒有明確定義的截止點或拐點。一種方法是實現本文中推薦的一些設計實踐，例如配置管理，即使您仍然在很大程度上可變的環境中工作。這將在未來更容易過渡到不變性。
如果您的基礎架構包含上述大多數組件，並且您發現自己遇到了擴展問題或者對部署過程的笨拙感到沮喪，那麼現在可以開始評估不變性如何改善您的基礎架構。
您可以從幾家公司（包括Codeship，Chef，Koddi和Fugue）那裏瞭解更多有關其不可變基礎架構實施的文章。