分布式系統(tǒng)設(shè)計(jì)模式
概述
這篇文章是對于【分布式系統(tǒng)設(shè)計(jì)模式】的個(gè)人理解和部分翻譯。
文章探討了關(guān)于《基于容器化軟件組件的微服務(wù)架構(gòu)》。
其實(shí)容器化編程的發(fā)展路徑和面向?qū)ο缶幊逃挟惽ぶ?-
都是將復(fù)雜的系統(tǒng)進(jìn)行抽象、解耦，然后通過一定的方式組合起來。
既然我們要組合，肯定會有面對不同情況的不同組合方式。所以，這些不同的組合方式也會有幾個(gè)常用的固定模式。
而這個(gè)正式我們要探討的--分布式系統(tǒng)設(shè)計(jì)模式。
說到分布式，第一個(gè)聯(lián)想到的應(yīng)該就的容器化。
為什么？其實(shí)容器化和分布式本沒有交集，只是因?yàn)槲覀儼l(fā)現(xiàn)容器化是一個(gè)實(shí)現(xiàn)分布式的高效的方法。
容器化設(shè)置了一個(gè)天然的邊界，邊界之外用接口進(jìn)行通信。
有了這個(gè)邊界的好處就是，任何意料之外的情況都可以被限制在最小的影響范圍，畢竟我們構(gòu)建的是一個(gè)大型的復(fù)雜系統(tǒng)。
我認(rèn)為，用FMEA模型能很好的描述為什么會采用容器化去解構(gòu)分布式系統(tǒng)。(FMEA，可以理解為：失控的狀態(tài)一定會發(fā)生，我們要做的是控制失控的范圍)
所以，我們接下來要說的設(shè)計(jì)模式基本上都是和容器相關(guān)，我們需要把容器作為一等公民去看。
畢竟這是寫 Kubernetes 的哥們寫的。
單容器管理者模式 (Single-container management patterns)
我們?yōu)槿萜髟黾右恍┛煽亟涌冢热?run(), stop(), pause()，使得容器對外來說是可控的。
也正是因?yàn)閺V泛的 http 協(xié)議支持，你完全可以通過 http 和 JSON這樣的序列化方式去構(gòu)造你應(yīng)用的對外的 API。
一般來說我們的設(shè)計(jì)方針都是一個(gè)容器提供一種服務(wù)。同時(shí)容器會為其上下游提供接口。
什么接口？
向上，提供容器本身豐富的信息接口。能夠?yàn)樘囟ǖ谋O(jiān)控容器運(yùn)行狀態(tài)的應(yīng)用提供信息。
向下，提供了控制容器本身的接口。使得分布式系統(tǒng)能夠更有效的管理整個(gè)應(yīng)用的生命周期，以及應(yīng)用的優(yōu)先級。
比如，一個(gè)集群的管理系統(tǒng)，能夠設(shè)置集群處理任務(wù)的優(yōu)先級。（比如 K8s 中的搶占式調(diào)度）
所以一旦采用這種模式的話，你會需要一個(gè)統(tǒng)一的管理平臺，通過接口去管理（組管理）單個(gè)容器。
單節(jié)點(diǎn)-多容器應(yīng)用模式 (Single-node, multi-container application patterns)
這種模式比較好理解，有些容器應(yīng)用是需要“共生”的，所以我們會將其放在同一個(gè)節(jié)點(diǎn)上。
一旦這樣，分布式系統(tǒng)會對容器組做聯(lián)合調(diào)度。
比如 K8s 里將調(diào)度單位描述成了 Pods（一個(gè) Pod 可能包含多個(gè)容器），Nomad 則稱其為 task groups。
下面幾個(gè)就是常用的單節(jié)點(diǎn)多容器的設(shè)計(jì)模式：
副載模式（Sidecar pattern）
多容器部署最通用的一種模式，就是 sidecar 模式。
其實(shí)大家都直接稱呼 Sidecar 模式，不會翻譯成副載。
那 Sidecar 是個(gè)啥樣子呢？
舉個(gè)例子吧：我們有一個(gè)主容器是 Web Server，我們需要收集 Web Server 所產(chǎn)生的日志。
所以我們會有一個(gè)專門的 sidecar 容器，負(fù)責(zé)收集日志并把日志存儲到集群的存儲系統(tǒng)。
另外一個(gè)例子，就是主容器的內(nèi)容呈現(xiàn)，是由一個(gè) sidecar 容器去實(shí)時(shí)同步的。
還有個(gè)例子是為一個(gè) Http Web Server 提供 Https 功能。
你會發(fā)現(xiàn) Sidecar 是主容器的一種擴(kuò)展和升級，這種模式的好處在于，因?yàn)槭侨萜鞲綦x，所以能夠保證從屬容器不會在主容器需要資源的時(shí)候占用過多的資源，因?yàn)榉峙滟Y源的最小單位就是容器。同時(shí)，sidecar 一般在功能上比較專職，又是容器化的，所以可以很方便的進(jìn)行單獨(dú)的部署、升級。
大使模式（Ambassador pattern）
大使模式實(shí)現(xiàn)方式是在節(jié)點(diǎn)中增加一個(gè)通訊代理。他解決的問題是：
為某些年久失修的外部服務(wù)，增加一個(gè)調(diào)用代理，調(diào)用者是我們節(jié)點(diǎn)上的應(yīng)用。
大使模式給開發(fā)者的好處是：
他們只要考慮應(yīng)用與本地服務(wù)的連接
他們可以在本地進(jìn)行測試
調(diào)用的外部服務(wù)語言無關(guān)
其實(shí)有個(gè)很典型但是非容器化的例子，就是 Ribbon 中的客戶端負(fù)載。
和大使模式很像，所有的請求流量都先經(jīng)由客戶端的負(fù)載均衡器決定了流量流向--我們在大使容器中現(xiàn)決定流量流向，然后直接調(diào)用真正的服務(wù)。
聰明的你會發(fā)現(xiàn)，我們似乎可以在大使容器中做很多手腳，比如熔斷，路由，流量監(jiān)控，安全控制等等（有點(diǎn)像服務(wù)端的 API 網(wǎng)關(guān)）。
沒錯(cuò)，所以我們得出了一些使用該模式的場景（來自docs.microsoft.com/en...）:
客戶端連接語言無關(guān)，框架無關(guān)
將客戶端連接的問題與應(yīng)用分離，解耦開發(fā)
為年久失修的應(yīng)用程序提供云或集群支持
適配器模式（Adapter pattern）
和 Ambassador 相比，Adapter 模式向外部呈現(xiàn)了一個(gè)統(tǒng)一的接口。（方向反了一下）
最典型的例子應(yīng)該就是容器管理平臺，所有系統(tǒng)中的容器都會有一套統(tǒng)一的監(jiān)控接口。
現(xiàn)在的容器多種多樣，不過只要保證每個(gè)容器都有統(tǒng)一的不變的對外監(jiān)控接口，對于單獨(dú)的監(jiān)控工具來說就不難實(shí)時(shí)收集各個(gè)容器的數(shù)據(jù)了。
單節(jié)點(diǎn)多容器的模式主要就是上面三種。
多節(jié)點(diǎn)應(yīng)用模式 (Multi-node application patterns)
和單節(jié)點(diǎn)多應(yīng)用模式一樣，我們同樣要求實(shí)現(xiàn)這個(gè)模式的系統(tǒng)支持 K8s 中 Pod 這樣的概念。
領(lǐng)導(dǎo)人選舉 (Leader election pattern)
在分布式系統(tǒng)中，老生常談的問題了，就是領(lǐng)導(dǎo)人選舉。
一般領(lǐng)導(dǎo)人選擇是怎樣一種狀態(tài)呢？就是在分布式系統(tǒng)中，存在一個(gè)或者多個(gè)領(lǐng)導(dǎo)人，還有剩下的作為工作節(jié)點(diǎn)。
一旦有領(lǐng)導(dǎo)人節(jié)點(diǎn)掛了，工作節(jié)點(diǎn)按照一定算法升級成為領(lǐng)導(dǎo)人節(jié)點(diǎn)。
領(lǐng)導(dǎo)人選舉算法是十分復(fù)雜的算法（至少對我來說），甚至有些算法庫還是語言限定的，所以，更好的方式就是通過容器去使用這個(gè)領(lǐng)導(dǎo)人選舉功能。
那為什么要分為領(lǐng)導(dǎo)節(jié)點(diǎn)和工作節(jié)點(diǎn)呢？
當(dāng)然是為了更好分配任務(wù)，分配好了任務(wù)，就能保證系統(tǒng)處在一個(gè)高效的狀態(tài)下運(yùn)行。避免出現(xiàn)有些工作節(jié)點(diǎn)空閑，有些工作節(jié)點(diǎn)忙的現(xiàn)象。整個(gè)模式的思想還是中心化治理最高效的方針。
工作隊(duì)列模式 (Work queue pattern)
我覺得，分布式系統(tǒng)中的工作隊(duì)列模式，其實(shí)表達(dá)了一個(gè)具有拓?fù)潢P(guān)系的分布式系統(tǒng)。每個(gè)步驟都是單獨(dú)的，但是他們的輸入可能需要依靠上一個(gè)輸出，亦或者，他們的輸出會成為下一個(gè)的輸入。
這個(gè)模式好在他語言無關(guān)，我只要知道我的容器的輸入輸出，然后將它放在合適的位置就可以了。
同時(shí)還需要一個(gè)專門進(jìn)行作業(yè)管理的容器進(jìn)行任務(wù)的分發(fā)。
我在網(wǎng)上并沒有找到過多的關(guān)于描述 Work queue pattern 的資料。
似乎這種設(shè)計(jì)模式的叫法不太一樣。
向量化模式 (Scatter/gather pattern)
這是一種有點(diǎn)廣播競爭的模式。
一個(gè)外部請求會先被發(fā)送到一個(gè)“根”或“父”節(jié)點(diǎn)。
然后根節(jié)點(diǎn)擴(kuò)散請求并讓服務(wù)端同時(shí)進(jìn)行競爭，然后每個(gè)競爭者都會返回一部分請求的結(jié)果，根節(jié)點(diǎn)再把碎片結(jié)果揉成一個(gè)完整的返回。
這樣的模式其實(shí)對于開發(fā)者的要求還是比較高的，因?yàn)橐獙Ψ植际饺蝿?wù)處理中產(chǎn)生的異常有很好的把控，同時(shí)涉及到了分布式任務(wù)一致性。
一般實(shí)現(xiàn)這種模式需要至少 2 個(gè)容器，一個(gè)是用來進(jìn)行任務(wù)分發(fā)的，還有一個(gè)是進(jìn)行結(jié)果歸總的。
總結(jié)
面向?qū)ο缶幊绦枰嫦驅(qū)ο蟮脑O(shè)計(jì)模式作為支撐。
容器化的分布式系統(tǒng)也一樣，需要容器的設(shè)計(jì)模式作為支撐。
上面我們分析了三種容器架構(gòu)下的設(shè)計(jì)模式，一共 7 種。
上面這 7 中模式會以組合的形式出現(xiàn)在分布式系統(tǒng)之中，畢竟分布式系統(tǒng)是一個(gè)復(fù)雜系統(tǒng)。
這篇文章所依據(jù)的論文，雖說是分布式系統(tǒng)的設(shè)計(jì)模式，但是其實(shí)會涉及到很多經(jīng)典的企業(yè)集成模式。所以我在這里向大家推薦一本書《企業(yè)集成模式》。
可別以為是講企業(yè)管理的，這是給開發(fā)者看的。
好吧，暫時(shí)先這樣吧。
參考
segmentfault.com/a/11...
www.usenix.org/system...
zhuanlan.zhihu.com/p/...
作者：steak
鏈接：https://juejin.cn/post/6844903875883827208
來源：稀土掘金
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。