分散式系統設計：PART I 單點模式

本書要介紹分散式系統，它是由運行在許多不同機器上的不同組件組成的應用程序。但是，本書的第一部分專門討論在於單個節點上的模式。理由很簡單，容器是本書所介紹的模式的基礎構件，位於同一台機器上的多個容器組也是構成分散式系統模式的原子元素。

動機

雖然你可能很清楚為什麼將分散式應用程序分割為一組容器運行在不同的機器上，但是你可能想問為什麼要將組件運行在在同一台機器的不同容器中。為了理解這些容器組的動機，思考容器化背後的目標是很有必要的。通常，容器的目標是圍繞特定資源建立邊界（例如，此應用程序需要兩個內核和8GB的內存）。同樣，邊界可以描繪團隊所有權（例如，該團隊擁有該鏡像）。最後，邊界還可以分散關注點（例如，這個鏡像是做某件事的）。

上述這些原因都表明了將單台機器上的應用程序拆分為一組容器的意義。首先考慮資源隔離，假設一個應用程序可能由兩個組件組成：一個是面向用戶的應用程序伺服器，另一個是後台配置文件載入器。很顯然，對於面向終端用戶的程序，請求延遲是最高優先順序，因此面向用戶的應用程序需要足夠的資源以確保其高速響應。另一方面，後台配置載入器主要是儘力而為服務；如果在用戶請求量較高的時段內及時有些輕微的延遲，系統也會正常工作。同樣，後台配置載入器不應該影響最終用戶接收的服務質量。由於這些原因，管理員希望將面向用戶的服務和後台的配置載入器分離到不同的容器中。這使管理員可以將不同的資源需求和優先順序分別附加到兩個不同的容器上，例如，確保後台載入器在服務程序空閑或者無負載時可從服務程序借用一定的資源。同樣，如果存在由內存泄漏或其他內存資源過度使用導致的資源爭用問題時，可確保在兩個容器的達到單獨資源需求之前終止後台載入程序。

除了此資源隔離之外，還有其他將單節點應用程序拆分為多個容器的原因。考慮團隊任務的規模，六到八人的團隊規模是十分合理的。為了能夠以這種方式構建團隊，並且仍然需要構建完整的系統，我們需要為每個團隊分配小型且重點突出的工作。此外，如果設計合理，通常一些可重複使用的模塊，可供許多團隊使用。例如，考慮讓本地文件系統與git源代碼庫保持同步的任務。如果將此Git同步工具作為單獨的容器來構建，那麼可以在PHP，HTML，JavaScript，Python和眾多其他Web服務環境中重複使用它。如果在每個容器中均單獨部署，例如，將Python運行時和Git同步不可分割地綁定在一個容器中，那麼這種情況下模塊化復用是不可能的。

最後，即使應用程序很小，並且所有容器都由一個團隊擁有，但關注點分離可確保您的應用程序能就有較好的可理解性，並且可以易於測試，更新和部署。小型、重點突出的應用程序更易於理解，與其他系統的耦合更少。這意味著在部署git同步容易時無需重新部署應用伺服器，讓rollouts依賴和影響範圍更小。這反過來又會使得rollout和rollback更加可靠，同時為部署應用程序帶來更大的靈活性和靈活性。

總結

我希望上述這些例子會促使您考慮將應用程序（即使是單個節點上的應用程序）分解為多個容器。後續章節描述的一些模式，可以幫助時引導您構建模塊化容器組。與多節點分散式模式相比，所有單點模式都假設模式中所有容器之間是緊密依賴關係。特別是，假設模式中的所有容器都可以可靠地在一台機器上共同調度。文章還假定模式中的所有容器都可以任意共享文件系統的卷以及諸如網路命名空間、共享內存等其他關鍵容器資源。這種緊密的分組在Kubernetes中被稱為pod，但這個概念通常適用於不同的容器協調器。

推薦閱讀：