文章目錄

• • 簡(jiǎn)介
  • Single-node multi-container patterns
  • • Sidecars extend and enhance
    • Ambassadors proxy and represent
    • Adapters normalize and present

簡(jiǎn)介

云原生（Cloud Native）不僅僅是趨勢(shì)，更是現(xiàn)在進(jìn)行時(shí)，它是構(gòu)建現(xiàn)代的，可彈性伸縮的，快速迭代的計(jì)算網(wǎng)絡(luò)服務(wù)的事實(shí)標(biāo)準(zhǔn)。其中容器編排系統(tǒng)Kubernetes和容器是基石。

英語好且想直接讀英文原版的朋友轉(zhuǎn)這里：Design Patterns for Container-based Distributed Systems，作者是Brendan Burns和David Oppenheimer，論文發(fā)表于2016年，是云原生領(lǐng)域系統(tǒng)設(shè)計(jì)的代表作。

跟我一樣不想讀那么長(zhǎng)英語的朋友看下來哈哈（好吧我偷偷的去拜讀了他的論文，果然通俗易懂）。

---

Single-node multi-container patterns

Container就好比OOP C++編程語言中的Object（Class），是容器分布式系統(tǒng)的最基礎(chǔ)對(duì)象。

在現(xiàn)實(shí)的設(shè)計(jì)中，需要把一個(gè)應(yīng)用拆為多個(gè)容器來實(shí)現(xiàn)，這么做的理由有三個(gè)：

針對(duì)資源建立邊界（不同的容器需要不同的CPU和內(nèi)存，根據(jù)實(shí)際需要進(jìn)行限制，而且不同容器間資源隔離，互不影響。

建立團(tuán)隊(duì)歸屬邊界，即一個(gè)Container有一個(gè)敏捷團(tuán)隊(duì)來own。

提供隔離（separation of concern）。容器的作用和職責(zé)應(yīng)該滿足單一職責(zé)的原則，按照領(lǐng)域模型設(shè)計(jì)的原則來進(jìn)行設(shè)計(jì)，這樣容易理解，也容易測(cè)試、更新和部署。

我對(duì)設(shè)計(jì)模式的看法一直很明確：具體問題具體分析，脫離了實(shí)際的辯論都是蝦扯蛋。一定要設(shè)計(jì)，一定不要過度設(shè)計(jì)。

---

為什么Pod（含有一個(gè)或者多個(gè)Container）是最小的部署單元，而不能直接是容器？這個(gè)問題前面幾篇就解答過了。Pod是一組共享生命周期，并部署在同一個(gè)節(jié)點(diǎn)的容器的組合，他們可以通過共享的volume/network和IPC來進(jìn)行通訊。之所以不是一個(gè)單一容器，而是多個(gè)容器來完成特定功能的原因在于：這些容器要完成的職責(zé)不同，根據(jù)單一職責(zé)（single responsibility）的原則，他們應(yīng)該屬于不同的組件；其次因?yàn)槁氊?zé)不同，維護(hù)他們的team也不同，迭代周期也不一樣；最后其中一些容器是可以被復(fù)用在其他的環(huán)境中的。所以從“解耦”和“復(fù)用”的設(shè)計(jì)原則出發(fā)，Kubernetes通過增加一個(gè)虛擬層即POD，給系統(tǒng)設(shè)計(jì)帶來了極大的靈活性，同時(shí)也產(chǎn)生了多種設(shè)計(jì)模式。即在一個(gè)POD中除了抗流量完成業(yè)務(wù)的容器外，還存在其他的輔助容器，可以分為兩類：1. Init Container 2. Sidecar container。

---

Sidecars extend and enhance

聽說過 “裝飾器模式” 嗎？

Sidecar 容器是與 Pod 中的主容器一起運(yùn)行的容器。Sidecar 模式可以在不更改的情況下擴(kuò)展并增強(qiáng)當(dāng)前容器的功能。

當(dāng)帶有單容器 Pod 正常運(yùn)行時(shí)，我們想在不接觸、不更改的情況下向當(dāng)前容器添加或擴(kuò)展一些功能，這種情況下，Sidecar 容器模式可以提供幫助。

舉個(gè)栗子，不然這樣我自己過段時(shí)間也看不懂了：

App Container是一個(gè)web server，sidecar container定期從github sync代碼下來，兩者通過Pod的volume來共享文件。這樣做的好處是把從github定期sync代碼的邏輯剝離出來，成為一個(gè)可以重用的模塊，并且能用到其他的場(chǎng)合。而app container只需要單純的做web服務(wù)就好，不需要考慮sync之類的邏輯。

什么時(shí)候考慮使用sidecar呢？當(dāng)這兩個(gè)container需要同時(shí)部署，但是各有自己的職責(zé)，而且可以分別去迭代和演進(jìn)，而且有重用的可能性。

那么什么時(shí)候不適合sidecar呢？當(dāng)這兩個(gè)container有不同的擴(kuò)容需求時(shí)候，即兩者需要獨(dú)立的擴(kuò)容時(shí)候，不要sidecar這種模式；另外，兩者的通信可能會(huì)帶來一些網(wǎng)絡(luò)的消耗，帶來一定的延遲，如果這點(diǎn)延遲是業(yè)務(wù)無法接受的話，也不要使用sidecar。

這樣就明了多了，我突然想到了 ORM 框架，也是這么個(gè)意思。

---

Ambassadors proxy and represent

聽說過 “代理模式” 嗎？

它是一種特殊的sidecar，其實(shí)就是app container的一個(gè)proxy，它來接流量，然后進(jìn)行處理，然后把流量轉(zhuǎn)發(fā)給app container，讓其完成真正的商業(yè)邏輯。

例如：我想給一個(gè)web server加上認(rèn)證邏輯或者SSL，但是我又不想改動(dòng)原來的web server或者改動(dòng)比較困難，我可以在其所在pod內(nèi)再部署一個(gè)proxy，讓這個(gè)proxy來處理這些認(rèn)證的邏輯，而原有的app container無需任何改動(dòng)。

---

Adapters normalize and present

了解過 “適配器模式” 嗎？

又是一種特殊的sidecar，如果希望對(duì)外輸出的內(nèi)容符合下游的要求而不對(duì)app container進(jìn)行修改，可以增加一個(gè)adapter的sidecar，由它來做類似日志轉(zhuǎn)換的事情。例如：

App container按照自身的要求生成日志并保存到文件系統(tǒng)中，另外的adapter container通過共享存儲(chǔ)讀取該日志，然后進(jìn)行日志轉(zhuǎn)換等工作，以便把內(nèi)容輸出給下游的metrics系統(tǒng)。

總結(jié)

以上是生活随笔為你收集整理的容器设计模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。