過去幾年容器逐漸成為了打包和部署**的流行的方式。容器映象解決很多現有的打包和部署工具所帶來的問題，初次以外，還為我們提供了構建分布式應用的全新的思路。就如soa提倡將應用拆分為模組化的內聚的服務，容器應當進一步提倡將這些服務拆分為緊密協作的模組化容器。通過構建應用邊界，容器使使用者能夠使用模組化，可重用的元件構建其服務，從而使得服務比單機容器構建的應用程式更可靠，更具可擴充套件性並且構建速度更快。
從vm向容器的演變從各種角度來說就如同當年從單機應用轉化為模組化的物件導向的應用程式。容器映象提供的抽象層與物件導向程式設計中類的抽象邊界有很大的共同點，而且也提高了開發者的效率和程式的質量。就像正確的編碼方式是將關注點分離為模組化物件一樣，在容器中打包應用程式的正確方法是將關注點分離為模組化容器。根本上來說，這意味著不僅要將整個應用程式分解，而且要將任何乙個伺服器中的各個部分分解為多個模組化容器，這些容器易於引數化和重複使用。這就像現代語言中的標準語言庫，大多數應用程式開發人員可以將由其他人編寫的模組化容器組合在一起，並使用更高質量的元件更快地構建應用程式。
從模組化容器方面進行思考的好處很多，特別是模組化容器提供以下內容：
加快應用的開發，因為容器可以在團隊甚至是大型社群之間進行復用
支援敏捷團隊，因為容器邊界是乙個天然的邊界，劃分給各個團隊。
支援關注點分離，並專注於開發特定功能從而減少複雜的依賴和不可測試元件。
當你從pod的角度思考時，自然會出現一些模組化應用程式開發的通用模式，這些模式會多次重複出現。我相信，隨著我們在kubernetes的開發中向前發展，將會發現更多這些模式，但這裡有三個我們常見的模式：
sidecar容器拓展並且加強主容器，他們融合當前已有的容器並且將它們完善。舉個例子，假設有乙個執行這nginx web應用的容器。新增另乙個容器將檔案系統與git倉庫同步，在容器間共享檔案系統，從而實現git的提交並部署。但是這種模組化實現使得git同步器可以交給另乙個容器開發，並且跨不同的web伺服器復用。因為這種模組化，你只需要編寫並測試單個git同步應用並且提供給多個應用使用。而如果有別的團隊開發了這個工具，你甚至不需要重複開發。
ambassador容器**外界至本地的連線。比如，現在有乙個redis集群，包含多個讀者和單個寫者。 你可以建立乙個pod，包含主應用和redis ambassador容器。ambassador容器作為**分離讀寫請求分別交給對應的伺服器。因為這兩個容器共享乙個網路命名空間，即他們共享乙個ip位址，因此主應用可以用localhost訪問ambassador服務，無需通過服務發現。從主應用的視角來看，就彷彿在localhost上連線了redis集群。這種方式非常方便，不僅因為不同的團隊可以管理自己的元件，而且因為在開發環境中，你可以跳過**，直接連線到redis集群上。
adapter容器標準化輸入輸出。假設現在需要監控n個應用，每個應用可能使用了不同的方法來輸出監控資料（比如jmx, statsd等）。但是每個監控系統都希望用乙個一致的資料模型來管理收集的資料。通過使用adapter模式來組合容器，你可以建立乙個pod將應用容器和介面卡容器組合起來，從而將同質的監控資料轉化為單個同乙個的表現形式。同樣的，因為這些pod共享命名空間和檔案系統，這兩個容器間的協作簡單明。
sidecar pattern
ambassador pattern
貓頭鷹的深夜翻譯 使用組合模式來開關燈
設計模式可能是部落格圈最熱門的話題之一。但是，用來說明每個設計模式的例子通常不是很形象。為了挽救這一點，這篇部落格將用乙個簡單有效的例子來解釋組合模式。我們不會再重複解釋這個模型的概念。唯一需要記住的是組合模式通常用在乙個樹結構的遞迴操作上。假設有一棟建築，這個建築有幾層樓，每層樓有幾個房間。這個建...
分布式 分布式系統的設計
在計算機領域，當單機效能達到瓶頸時，一般有兩種方式解決效能問題 而分布式系統的設計說白了就是 如何合理將乙個系統拆分成多個子系統部署到不同機器上。講設計方法前，先介紹分布式系統的特性 1 分布性 空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。2 對等性 分布式系統中的計...
分布式系統中的分布式事務
分布式事務中可以借助mq訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣，怎麼保證兩個伺服器的...