關于不可變架構以及為什么需要不可變架構
2013年Chad Fowler在博客中提出了“不可變架構”的概念。不可變架構(II)能夠通過自動化和成功的編程模式為應用程序提供穩定性、高效性和保真度。雖然目前為止還不存在嚴格定義和標準化的不可變架構,但是基本的想法是使用不可變的編程概念來創建和操作你的架構:一旦實例化了一些東西,就永遠不改變它。取而代之的是,你可以通過替換另一個實例來達到改變行為的目的。不可變架構需要你的運行時環境全面自動化。只有這樣,計算環境才能擁有一個API來全方位地配置和監控它。因此,不可變架構只有在真正的云環境中才有可能完全實現。當然,也可以部分實現不可變架構來獲取一些好處,但只有徹底地實現它才有可能獲取真正的效率和彈性。
假設我們有一個應用。為了生產交付物,我們需要從源碼編譯。這就涉及了編譯源碼、處理和復制資源和其它的一些步驟。最終產生的可交付應用是:
- 單一不可變單元
- 編譯一次并存儲在倉庫中
- 每次改變后通過持續集成系統重新生成
當然應用不會直接運行在硅或者鋼鐵之上,通常服務器會有OS Kernel、Libraries、Runtime和App Server這些層。即使是最簡單的項目,應用都需要運行在多臺機器上,它們被組織成不同的環境,例如開發環境、測試環境和生產環境等等。需要將相同的應用部署到不同的機器上。通常需要系統管理員確保所有的機器都處于相同的狀態。接著所有的修改、補丁、升級需要在所有的機器中進行。隨著時間的推移,很難再確保所有的機器處于相同的狀態,同時越來越容易出錯。這就是傳統的可變架構中經常出現的問題。這是我們有了不可變架構,它將整個機器環境打包成一個單一的不可變單元,而不是傳統方式僅僅打包應用。這個單元包含了之前所說的整個環境棧和應用所有的修改、補丁和升級,這就解決了前面的問題。
手工架構的缺陷
從歷史上看,我們認為機器的正常運行和維護是可取的,因為所有的服務和應用都與它們的健康息息相關。在數據中心,由于硬件非常的昂貴,隨著時間的推移,我們需要小心翼翼地維護每個單獨的服務器來保護我們的投資。從云計算的概念考慮,這顯然是一個過時的觀點,我們應該放棄它以創造更具彈性、更簡單和更安全的服務與應用。種種原因表明,傳統長壽的由手工維持的基礎設施已經不足以運行現代在云端的分布式服務:
-
增加操作復雜性。分布式服務體系結構的興起以及使用了動態彈性導致了需要追蹤監控更多東西。在成百數千個實例中使用可變的維護方法來更新和補丁配置是非常困難的,當然也是容易出錯和需要耗費一定的時間。
-
部署慢,易出錯。當基礎設施是由來自可變維護方法(無論是通過腳本或配置管理工具)產生的雪花組件時,會有更過出錯的可能。偏離了一個從源直接控制的過程,意味著準確地知道你的基礎設施的狀態是不可能的。由于基礎設施以不可預測的方式在運行和時間浪費在了追逐配置漂移與調試運行時,保真度就丟失了。
-
識別錯誤和威脅,以減輕傷害。長時間運行和可變的系統依賴于識別出錯誤和威脅來防止損害。現在我們知道,近日高規格的公告和企業公布的損害都已經證明,這些是徒勞的。采用不可變架構和全自動重新生成計算資源,許多錯誤和威脅,不管是否能被檢測到,都可以減輕他們的損害。
-
消防演習。手工基礎設施允許我們以走捷徑的方式來自動化,但它會以意想不到的方式來咬我們,例如當一個云提供商重啟相關示例來進行更新或者打補丁。如果我們手動簡歷和維護我們的基礎設施,而不是常規的不可變架構自動化,這些事件就會成為消防演習。
不可變架構的優點
不可變架構與自然界如可保持先進的生物系統有諸多相似之處。保真度在人體內的主要機制是恒定的破壞和更換子組件。它強調了免疫系統,它通過破壞細胞來維持健康。它強調了增長系統,它允許不同的子系統隨著時間的推移通過破壞和更換而逐漸成熟。人類個體保持了自我和意圖感,而底層組件都在不停更換。使用不可變架構的系統管理并沒有什么不同。
如果你的應用能夠恰當使用并且完全自動化部署和恢復方法,不可變架構帶來的好處將會是多方面的:
-
簡化操作。當使用完全自動化部署方式時,你可以使用新版本的組件替換掉舊的來確保你的系統永遠保持在最初的良好狀態。由于不需要追蹤可變維護方法中出現的改變,維護成百上千個實例將會非常簡單。
-
持續部署,極少失敗。有了不可變架構,你能夠準確知道什么正在運行和它將怎樣表現,在生產環境部署升級將是常規的和持續的,同時極少會發生故障。所有的變化都是通過源碼控制和持續集成過程追蹤的。
-
減少錯誤和威脅。服務是建立在一個復雜的硬件和軟件的堆棧之上,并且隨著時間的推移,事情會出錯。通過自動化替換,而不是維護實例,事實上我們將會常規地頻繁重新生成實例。這就減少了配置漂移、脆弱性的表面和保持服務水平協議付出的努力水平。
-
云重啟?沒問題。有了不可變架構,你就能夠知道正在運行的東西,同時你的服務也就擁有了自動恢復方法,云重啟正在運行的實例將會在最小的關機時間下被小心處理。
我們必須非常努力地工作來保持一些東西,當這些東西是一個架子上的物理盒子,由于我們手動配置硬件,這是必要的工作。但通過邏輯隔離計算實例可以通過API調用在有效率的無限的云中實例化它們,“維護盒子”是智力的枷鎖。它將我們的注意力和精力捆綁在錯誤的東西上。將你的注意力從他們身上移開就能夠使你把重點放在你的應用程序的成功身上,而不是被高維護成本和采用新模式的難度不斷地拉下來。
感謝郭蕾對本文的審校。
給InfoQ中文站投稿或者參與內容翻譯工作,請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博(@InfoQ,@丁曉昀),微信(微信號: InfoQChina )關注我們,并與我們的編輯和其他讀者朋友交流(歡迎加入InfoQ讀者交流群 (已滿),InfoQ讀者交流群(#2)
)。
來自: http://www.infoq.com/cn/news/2016/01/Immutable-architecture