論文解讀：Design patterns for container-based distributed systems

這是由Kubernetes創始人發表的論文，總結了基於容器的分佈式系統的設計模式，讓咱們來一覽究竟吧。

論文認爲，繼OOP（面向對象編程）所引領的軟件開發革命以後，現在彷佛在分佈式系統開發中也發生着一場類似的革命：基於容器化組件構建的微服務架構。

容器的一大獨特優點在於：良好的邊界——剛好適合應用開發的隔離性。

做者總結了一些設計模式，而且分爲三大類型：

Single-container management patterns

• 容器的傳統接口有run(), pause(), stop()

• 能夠有更豐富的接口

  • 「向上看」的視角：metrics, config, logs等，一般用HTTP+JSON來暴露
  • 「向下看」的視角：lifecycle（提供生命週期回調鉤子）, priority（爲了空出資源給高優先級任務，甚至能提早關掉低優先級任務），"replicate yourself"（迅速建立一組相同的服務容器來應對突發流量）

接下來兩類都依賴Pod抽象（Kubernetes有提供），由於都涉及容器編排了，並且已進入Sevice Mesh這門新概念的範圍。

Single-node, multi-container application patterns

多個容器組成一個原子單位

Sidecar模式

• 例如：web server + log collector
• 前提是容器間能共享「存儲卷」之類的資源

爲何要用多容器，而非容器內多進程？

• 資源審計和分配：這點很重要，雖然多進程也勉強能作，但多容器作得更成熟
• 職責劃分、解耦
• 重用：若是一個容器包含多種進程，就笨重而難以重用了，小巧的單用途容器更適合重用
• 故障隔離：重啓一個容器，比修復容器內的故障進程要容易多了
• 交付隔離：每一個容器能獨立地升級/降級

Ambassador模式

• 相似於OOP的proxy模式
• 例如：memcache + twemproxy，考慮到本分類爲單結點多容器模式，所以twemproxy要和其中1個memcache部署到同一結點上
• 前提是容器間能共享localhost網絡接口

Adapter模式

• 例如：統一的metrics接口（JMX，statsd等統一收集到HTTP端點）
• 能夠免於修改已有的容器（由於已經以容器做爲軟件開發的單位了）

Multi-node application patterns

Leader election模式

• 領導者選舉這件事已經有不少庫了，但每每對編程語言有所限定
• 容器則對編程語言中立
• 容器只需構建一次就能重用，高度貫徹了抽象和封裝的原則

Work queue模式

• 傳統的工做隊列框架對編程語言有所限定
• 實現了run(), mount()接口的容器，可做爲「工做」的抽象
• 基於此可打造一種通用的工做隊列框架（多是Kubernetes的將來方向）
• 雖然沒給例子，但有些相似Mesos的可插拔調度器架構

Scatter/gather模式

• 這樣傳遞請求：client->root->server
• root結點把請求分發給不少servers，再把它們的響應彙總到一塊兒，交給client
• 例如：搜索引擎，分佈式查詢引擎
• 多個leaf容器+1個merge容器，就能實現通用的scatter/gather框架（可能也是Kubernetes的將來方向）

結語

總之，論文將容器視爲軟件開發的一等公民，像OOP的對象同樣重要，提倡單用途可組合可重用的容器。
這彷佛是對UNIX編程藝術的重申。