貓頭鷹的深夜翻譯：分佈式系統Toolkit模式

過去幾年容器逐漸成爲了打包和部署代碼的流行的方式。容器鏡像解決不少現有的打包和部署工具所帶來的問題，初次之外，還爲咱們提供了構建分佈式應用的全新的思路。就如SOA提倡將應用拆分爲模塊化的內聚的服務，容器應當進一步提倡將這些服務拆分爲緊密協做的模塊化容器。經過構建應用邊界，容器使用戶可以使用模塊化，可重用的組件構建其服務，從而使得服務比單機容器構建的應用程序更可靠，更具可擴展性而且構建速度更快。

從VM向容器的演變從各類角度來講就如同當年從單機應用轉化爲模塊化的面向對象的應用程序。容器鏡像提供的抽象層與面向對象編程中類的抽象邊界有很大的共同點，並且也提升了開發者的效率和程序的質量。就像正確的編碼方式是將關注點分離爲模塊化對象同樣，在容器中打包應用程序的正確方法是將關注點分離爲模塊化容器。根本上來講，這意味着不只要將整個應用程序分解，並且要將任何一個服務器中的各個部分分解爲多個模塊化容器，這些容器易於參數化和重複使用。這就像現代語言中的標準語言庫，大多數應用程序開發人員能夠將由其餘人編寫的模塊化容器組合在一塊兒，並使用更高質量的組件更快地構建應用程序。

從模塊化容器方面進行思考的好處不少，特別是模塊化容器提供如下內容：

加快應用的開發，由於容器能夠在團隊甚至是大型社區之間進行復用

支持敏捷團隊，由於容器邊界是一個自然的邊界，劃分給各個團隊。

支持關注點分離，並專一於開發特定功能從而減小複雜的依賴和不可測試組件。

從模塊化容器構建應用程序意味着考慮協做提供服務容器的共生組，而不是一個容器提供一個服務。在Kubernetes中，這種模塊化容器服務的實施者是Pod。一個Pod是指一組共享文件系統，內核命名空間和IP地址的一組容器。Pod在K8s集羣中是調度的基本單位，正是由於Pod中容器的共生特性要求它們共同安排在同一臺機器上，而可靠地實現這一點的惟一方法是將容器組做爲原子調度單元。

當你從Pod的角度思考時，天然會出現一些模塊化應用程序開發的通用模式，這些模式會屢次重複出現。我相信，隨着咱們在Kubernetes的開發中向前發展，將會發現更多這些模式，但這裏有三個咱們常見的模式：

例子1：Sidecar容器

Sidecar容器拓展而且增強主容器，他們融合當前已有的容器而且將它們完善。舉個例子，假設有一個運行這Nginx web應用的容器。添加另外一個容器將文件系統與git倉庫同步，在容器間共享文件系統，從而實現git的提交併部署。可是這種模塊化實現使得git同步器能夠交給另外一個容器開發，而且跨不一樣的web服務器複用。由於這種模塊化，你只須要編寫並測試單個git同步應用而且提供給多個應用使用。而若是有別的團隊開發了這個工具，你甚至不須要重複開發。

例子2：Ambassador容器

Ambassador容器代理外界至本地的鏈接。好比，如今有一個Redis集羣，包含多個讀者和單個寫者。 你能夠建立一個Pod，包含主應用和Redis ambassador容器。ambassador容器做爲代理分離讀寫請求分別交給對應的服務器。由於這兩個容器共享一個網絡命名空間，即他們共享一個IP地址，所以主應用能夠用localhost訪問ambassador服務，無需經過服務發現。從主應用的視角來看，就彷彿在localhost上鍊接了redis集羣。這種方式很是方便，不只由於不一樣的團隊能夠管理本身的組件，並且由於在開發環境中，你能夠跳過代理，直接鏈接到Redis集羣上。

例子3：Adapter容器

Adapter容器標準化輸入輸出。假設如今須要監控N個應用，每一個應用可能使用了不一樣的方法來輸出監控數據（好比JMX, StatsD等）。可是每一個監控系統都但願用一個一致的數據模型來管理收集的數據。經過使用Adapter模式來組合容器，你能夠建立一個pod將應用容器和適配器容器組合起來，從而將同質的監控數據轉化爲單個同一個的表現形式。一樣的，由於這些Pod共享命名空間和文件系統，這兩個容器間的協做簡單明。

Refrence

Sidecar Pattern
Ambassador Pattern