摘要：容器之間相互隔離的優(yōu)點(diǎn)使得容器成為了分布式系統(tǒng)中合適的基本單元。分布式系統(tǒng)設(shè)計(jì)模式在面向?qū)ο缶幊瘫皇褂昧藥啄曛螅O(shè)計(jì)模式出現(xiàn)并被編成文檔。

在20世紀(jì)80年代末和20世紀(jì)90年代初，面向?qū)ο缶幊虖氐赘母锪塑浖_(kāi)發(fā)方法，普及了將應(yīng)用程序作為模塊化組件的創(chuàng)建方法。隨著基于容器化軟件組件的微服務(wù)架構(gòu)的逐漸普及，現(xiàn)在在分布式系統(tǒng)開(kāi)發(fā)中也發(fā)生著類似的革命。容器之間相互隔離的優(yōu)點(diǎn)使得容器成為了分布式系統(tǒng)中合適的基本單元。隨著這種架構(gòu)類型的成熟，我們可以看到設(shè)計(jì)模型的出現(xiàn)，從容器的角度來(lái)思考問(wèn)題可以將低層次代碼細(xì)節(jié)抽象化。

這篇論文描述了我們觀察到的三種基于容器分布式系統(tǒng)的設(shè)計(jì)模型：?jiǎn)蝹€(gè)容器模式，密切合作模式容器的單節(jié)點(diǎn)模式，以及分布式算法的多節(jié)點(diǎn)模式。跟面向?qū)ο缶幊痰脑O(shè)計(jì)模式類似，這些模式包含了最佳實(shí)踐，簡(jiǎn)化了開(kāi)發(fā)，使系統(tǒng)更加可靠。

在面向?qū)ο缶幊瘫皇褂昧藥啄曛螅O(shè)計(jì)模式出現(xiàn)并被編成文檔。這些模式被編纂好，并且被規(guī)整成解決特別常見(jiàn)的編程問(wèn)題的方法。這個(gè)編纂進(jìn)一步提高了編程最前沿的技術(shù)，因?yàn)樗梢宰尳?jīng)驗(yàn)不那么豐富的人也寫(xiě)出很好的代碼，并且讓重復(fù)使用的庫(kù)文件的蓬勃發(fā)展，這些庫(kù)文件可以讓開(kāi)發(fā)代碼更加可靠、快速。

前分布式系統(tǒng)工程的技術(shù)水準(zhǔn)，比起面向?qū)ο箝_(kāi)發(fā)，更像是20世紀(jì)80年代的編程的水平。顯然，MapReduce模式將“大數(shù)據(jù)”編程的力量帶入廣泛的領(lǐng)域和更多的開(kāi)發(fā)者是一個(gè)巨大的成功，將正確的模式放在合適的位置可以很大程度上提高分布式系統(tǒng)編程的質(zhì)量、速度和可達(dá)性。雖然MapReduce的成功受限于單個(gè)編程語(yǔ)言，在Apache Hadoop生態(tài)系統(tǒng)范圍內(nèi)，只對(duì)一種編程語(yǔ)言（java）產(chǎn)生了影響。為分布式系統(tǒng)開(kāi)發(fā)一款全面的一套模式需要一個(gè)非常通用，與語(yǔ)言無(wú)關(guān)的交流工具來(lái)呈現(xiàn)系統(tǒng)的精髓。

所以，很幸運(yùn)能夠看到過(guò)去兩年內(nèi)，越來(lái)越多的人選擇使用容器技術(shù)。容器和容器鏡像正是分布式系統(tǒng)模式開(kāi)發(fā)所需要的抽象。至今為止，容器和容器鏡像已經(jīng)在很大程度上受到了歡迎，因?yàn)樗且环N更好，更可靠的通過(guò)產(chǎn)品來(lái)交付軟件的方法。因?yàn)槿萜魇敲荛]的，包含了依賴關(guān)系，并且有一個(gè)原子的部署信號(hào)("succeeded”／“failed”)，他們很大程度上提升了之前在數(shù)據(jù)中心或云端部署軟件的技術(shù)。但是容器不僅僅只是一個(gè)很好的部署工具，我們認(rèn)為容器最終會(huì)成為面向?qū)ο筌浖到y(tǒng)中的對(duì)象一樣，并且因此驅(qū)使了分布式系統(tǒng)設(shè)計(jì)模式的發(fā)展。在接下來(lái)的部分，我們會(huì)解釋為什么我們相信會(huì)是這樣，并且描述出現(xiàn)的一些在未來(lái)幾年中可以使分布式系統(tǒng)規(guī)整化的設(shè)計(jì)模式。

容器為定義接口提供了一個(gè)自然的邊界，類似于對(duì)象邊界。容器不僅能夠暴露專用應(yīng)用功能，還能夠通過(guò)這個(gè)接口跟管理系統(tǒng)掛鉤。

傳統(tǒng)的容器管理接口是極其有限的。對(duì)容器的有效操作為：run，pause和stop。雖然這個(gè)接口十分有用，但是更豐富的接口可以給系統(tǒng)開(kāi)發(fā)者和操作者提供更多的實(shí)用功能。考慮到目前幾乎所有現(xiàn)代編程語(yǔ)言對(duì)HTTP服務(wù)器的開(kāi)發(fā)以及對(duì)json這種數(shù)據(jù)格式的普遍支持，很容易讓容器提供一個(gè)基于HTTP管理的API。

“upward”方向，容器可以暴露一套豐富的應(yīng)用程序信息，包括應(yīng)用專用監(jiān)控參數(shù)（QPS，應(yīng)用程序健康等等），用戶感興趣的信息（threads，stack，lock contention，network，message statistics等等），組件配置信息和組件日志。一個(gè)具體例子就是，Kubernetes，Aurora，Marathon和其它容器管理系統(tǒng)允許用戶通過(guò)特定的HTTP端點(diǎn)（比如，”/health”）來(lái)定義健康檢查。對(duì)于之前說(shuō)過(guò)的“upword”API的其它元素的標(biāo)準(zhǔn)化支持就更少了。

“downward”方向，容器接口提供一個(gè)地方來(lái)定義生命周期，使得寫(xiě)管理系統(tǒng)控制的軟件組件更加容易。比如，集群管理系統(tǒng)通常會(huì)將“priorities”歸到任務(wù)中，即使集群訂閱超額，高優(yōu)先級(jí)的任務(wù)也會(huì)保證運(yùn)行。這個(gè)保證通過(guò)殺死已經(jīng)在運(yùn)行的低優(yōu)先級(jí)的任務(wù)來(lái)完成，低優(yōu)先級(jí)的任務(wù)要等到資源可用的時(shí)候才會(huì)再繼續(xù)完成。驅(qū)逐只要通過(guò)簡(jiǎn)單的殺死低優(yōu)先級(jí)的任務(wù)就可以實(shí)施，但是這就給開(kāi)發(fā)人員帶來(lái)了很多不必要的負(fù)擔(dān)，他們需要在代碼中處理任務(wù)被殺掉的情況。相反，如果在應(yīng)用系統(tǒng)和管理系統(tǒng)中定義了正式的生命周期，應(yīng)用程序組件就會(huì)變得更加可管理，因?yàn)殚_(kāi)發(fā)者可以依照正式的生命周期來(lái)開(kāi)發(fā)。比如，Kubernetes使用Docker的“優(yōu)雅終止”功能，通過(guò)SIGTERM信號(hào)來(lái)警告容器，它在一個(gè)自定義的時(shí)長(zhǎng)之后會(huì)接受到SIGKILL信號(hào)，并被終止。這就允許應(yīng)用程序通過(guò)完成當(dāng)前任務(wù)，把狀態(tài)寫(xiě)入磁盤等等操作之后再終止。你可以想象擴(kuò)展這種機(jī)制用來(lái)支持序列化和恢復(fù)，使得有狀態(tài)的分布式系統(tǒng)狀態(tài)管理更加容易。

對(duì)于更加復(fù)雜的生命周期的例子，考慮到Android的Activity模型，這個(gè)模型包含了一系列的回調(diào)函數(shù)（比如onCreate（），onStart（），onStop（），…）和一個(gè)狀態(tài)機(jī)來(lái)定義何時(shí)觸發(fā)這些回調(diào)函數(shù)。沒(méi)有了正式的生命周期，健壯，開(kāi)發(fā)可靠的安卓應(yīng)用程就更加難了。在基于容器的系統(tǒng)中，這就對(duì)應(yīng)了自定義的一些鉤子，這些鉤子會(huì)在容器創(chuàng)建時(shí)，容器開(kāi)始運(yùn)行時(shí)，容器結(jié)束運(yùn)行前等情況下被調(diào)用。

除了單個(gè)容器的接口，我們也看到了一些跨容器的設(shè)計(jì)模式。我們之前就已經(jīng)確認(rèn)了幾個(gè)這樣的模式。這種單節(jié)點(diǎn)的模式包括了同時(shí)運(yùn)行在單個(gè)主機(jī)上的共生容器。容器管理系統(tǒng)支持同時(shí)運(yùn)行多個(gè)容器作為一個(gè)整體單元，所以抽象（Kubernetes叫它“pods”，Nomad叫它“task groups”）是一個(gè)用來(lái)啟動(dòng)我們之前描述過(guò)的模式的必需功能。

1. sidcar模式

對(duì)于多個(gè)容器配置來(lái)說(shuō)，第一個(gè)，也是最普遍的情況就是sidcar模式。Sidecar擴(kuò)展并且提高了大多數(shù)的容器。比如，主容器可能是一個(gè)網(wǎng)頁(yè)服務(wù)器，它可能跟“l(fā)ogsaver” sidecar容器配對(duì)，然后saidecar容器從本地磁盤收集網(wǎng)頁(yè)服務(wù)器的日志，并且將他們stream到集群存儲(chǔ)系統(tǒng)。圖1展示的就是sidcar模式的一個(gè)例子。另一個(gè)普遍的例子就是從本地磁盤內(nèi)容服務(wù)的網(wǎng)頁(yè)服務(wù)器，這個(gè)sidecar會(huì)定期跟git庫(kù)進(jìn)行內(nèi)容管理系統(tǒng)或者其它數(shù)據(jù)源的存儲(chǔ)進(jìn)行同步。這兩個(gè)例子在谷歌是十分普遍的。因?yàn)樵谕粋€(gè)機(jī)器上的容器可以共享一個(gè)本地磁盤數(shù)據(jù)卷，所以sidecar是可能做的。

雖然創(chuàng)建sidecar容器的功能到主容器里永遠(yuǎn)可行，但是使用分開(kāi)的容器有以下幾點(diǎn)好處。首先，容器是資源賬戶和分配的單元，那么比如一個(gè)網(wǎng)頁(yè)服務(wù)器容器的cgroup可以被配置，那樣的話，它就會(huì)提供持續(xù)的低延遲反應(yīng)到問(wèn)題，雖然logsaver容器在網(wǎng)頁(yè)服務(wù)器不忙的時(shí)候被配置來(lái)清除空閑CPU周期。第二，容器是打包的單元，所以將服務(wù)和日志保存分到不同的容器可以讓兩個(gè)獨(dú)立的編程團(tuán)隊(duì)之間的可靠性分開(kāi)，并且允許他們獨(dú)立測(cè)試，跟一起測(cè)試的時(shí)候是一樣的。第三，容器是重復(fù)使用的單元，所以sidecar容器可以跟很多不同的主容器（比如logsaver容器可以被任意產(chǎn)生日志的組件使用）。第四，容器控制邊界錯(cuò)誤服務(wù)，使得整個(gè)系統(tǒng)能夠正確推出（比如，網(wǎng)頁(yè)服務(wù)器即使在日志保存運(yùn)行失敗的狀態(tài)下也能夠繼續(xù)服務(wù)）。最后一點(diǎn)，容器是配置的單元，每個(gè)功能都可以更新，并且必要的時(shí)候能獨(dú)立回滾。（但是要注意的是，最后一點(diǎn)好處也有不好的地方——總體系統(tǒng)的測(cè)試模型必須要考慮到在生產(chǎn)過(guò)程中所有的容器版本組合，這些版本可能會(huì)很大，因?yàn)槿萜骺傮w上來(lái)說(shuō)通常不能自動(dòng)升級(jí)。當(dāng)然，單一的應(yīng)用程序沒(méi)有這個(gè)問(wèn)題，組件化的系統(tǒng)在某種程度上更容易測(cè)試，因?yàn)樗麄兪窃诟〉目梢元?dú)立測(cè)試的單元的基礎(chǔ)上測(cè)試的）。注意，這五點(diǎn)優(yōu)點(diǎn)應(yīng)用于我們接下來(lái)在論文中描述的容器模式。

2. Ambassador模式

接下來(lái)要說(shuō)的是我們觀察到的ambassador模式。Ambassador容器代理服務(wù)會(huì)跟主容器進(jìn)行交流。比如，開(kāi)發(fā)者可能匹配一個(gè)正在跟twenproxy ambassador進(jìn)行交流的memcache。應(yīng)用程序相信這只是跟單個(gè)在本地主機(jī)上的memcache交流，但是現(xiàn)實(shí)中，twenproxy正在跟多個(gè)memcache集群中的其他節(jié)點(diǎn)的分布式安裝進(jìn)行共享。這個(gè)容器模式以三種方式簡(jiǎn)化了編程：他們只需要思考編程，依據(jù)他們連接到本地主機(jī)的單個(gè)服務(wù)器，他們可以通過(guò)運(yùn)行真正的memcache實(shí)例來(lái)多帶帶測(cè)試他們的應(yīng)用程序，而且他們也可以利用其他的應(yīng)用程序（可能會(huì)用不同語(yǔ)言編寫(xiě)）重新使用twenproxy ambassador。Ambassadors也是可能的因?yàn)樵谕粋€(gè)機(jī)器上分享同一個(gè)本地主機(jī)網(wǎng)絡(luò)接口。這個(gè)模式的例子如圖片2所示的。

3. 適配器模式

最后一個(gè)要說(shuō)的是我們觀察到的適配器模式。相比于用外部的簡(jiǎn)化來(lái)呈現(xiàn)應(yīng)用程序的ambassador模式，適配器用的事簡(jiǎn)化的，均質(zhì)的應(yīng)用程序來(lái)呈現(xiàn)外部世界。他們是通過(guò)將多容器間輸出和接口標(biāo)準(zhǔn)化才做到這樣的。適配器模式具體的例子就是，適配器確保所有在一個(gè)系統(tǒng)內(nèi)的容器都有相同的監(jiān)控接口。現(xiàn)在應(yīng)用程序使用很多種方法來(lái)輸出他們的參數(shù)（比如，JMX，statsd等等）。但是對(duì)于單個(gè)監(jiān)控工具來(lái)說(shuō)，收集，集合，以及從異構(gòu)應(yīng)用程序呈現(xiàn)數(shù)據(jù)就很容易，如果所有應(yīng)用程序呈現(xiàn)一致的監(jiān)控界面的話。在谷歌，我們通過(guò)編碼規(guī)范來(lái)完成，但是只有在你從scratch創(chuàng)建自己的軟件的時(shí)候才有可能。適配器模式讓異構(gòu)的舊世界和開(kāi)源應(yīng)用程序呈現(xiàn)統(tǒng)一的接口，不需要修改原始程序。主容器能夠跟適配器通過(guò)本地主機(jī)或者共享的本地?cái)?shù)據(jù)卷交流。詳情請(qǐng)查看圖3。注意，一些已經(jīng)存在的監(jiān)控方法能夠跟多種類型的后端，他們?cè)诒O(jiān)控系統(tǒng)中使用專用應(yīng)用程序代碼，提供了一個(gè)不那么清潔的關(guān)注點(diǎn)的隔離。

在單個(gè)機(jī)器上移動(dòng)合作的容器，讓創(chuàng)建合作的多節(jié)點(diǎn)分布式應(yīng)用程序更加容易。之后我們接下來(lái)會(huì)具體描述一下這些分布式系統(tǒng)模式中的三種。比如之前章節(jié)提過(guò)的那些模式，這些也要求為Pod抽象提供系統(tǒng)支持。

1. leader選舉模式

分布式系統(tǒng)中常見(jiàn)問(wèn)題之一就是leader選舉。副本被普遍使用在一個(gè)組件的多個(gè)相同的實(shí)例之間共享負(fù)載，副本的另一個(gè)更加復(fù)雜的作用就是在應(yīng)用程序需要區(qū)分副本跟設(shè)置來(lái)作為“l(fā)eader”。其它的副本對(duì)于快速取代leader的位置是十分快速的，如果之前的副本失敗了的話。一個(gè)系統(tǒng)甚至可以平行運(yùn)行多個(gè)leader選舉，比如，要定義多個(gè)碎片中每一個(gè)的leader。運(yùn)行l(wèi)eader選舉有很多庫(kù)。用起來(lái)又復(fù)雜又難理解，要正確使用真的很困難，另外，他們的限制之處在于，只能用特定的編程語(yǔ)言來(lái)寫(xiě)。把leader選舉庫(kù)連接到應(yīng)用程序的另一種方法就是使用leader選舉容器。leader選舉容器，每一個(gè)都跟需要leader選舉的應(yīng)用程序的實(shí)例同步，而且能夠在他們自己之間進(jìn)行選舉，同時(shí)他們也可以在本地主機(jī)上呈現(xiàn)一個(gè)簡(jiǎn)化的HTTP API給每一個(gè)需要leader選舉的應(yīng)用程序容器（比如，becomeLeader，renewLeadership等等）。這些leader選舉容器只能被創(chuàng)建一次，隨后簡(jiǎn)化的接口可以由應(yīng)用程序開(kāi)發(fā)人員重新使用，不管他們選擇什么語(yǔ)言來(lái)實(shí)現(xiàn)。在軟件工程領(lǐng)域，這是最好的抽象和封裝的代表。

2. work quene模式

雖然work queen跟leader選舉一樣，是一種很好研究的項(xiàng)目，因?yàn)橛泻芏嗫蚣芸梢詠?lái)實(shí)現(xiàn)他們，他們同時(shí)也是分布式系統(tǒng)模式例子，這個(gè)模式可以從面向容器的架構(gòu)中受益。在之前的系統(tǒng)中，框架限制于單個(gè)語(yǔ)言環(huán)境編程（比如，Celery for Python），或者work和二進(jìn)制的分布練習(xí)留給了實(shí)現(xiàn)它的人（比如，Condor）。實(shí)現(xiàn)run（）和mount（）接口的容器可用性使實(shí)現(xiàn)一個(gè)通用的work queen框架十分簡(jiǎn)單，這個(gè)框架可以處理任意的進(jìn)程中打包為容器的代碼，并且創(chuàng)建一個(gè)完整的work queen系統(tǒng)。開(kāi)發(fā)者只能選擇去創(chuàng)建一個(gè)可以在文件系統(tǒng)處理輸入數(shù)據(jù)文件的容器，并且將之轉(zhuǎn)化為一個(gè)輸出文件；這個(gè)容器將會(huì)變成work queen的一個(gè)階段。用戶的代碼整合到這個(gè)共享的work queen框架的方式圖4中已經(jīng)闡述了。

3. Scatter/gather模式

最后一個(gè)要強(qiáng)調(diào)的分布式系統(tǒng)模式就是Scatter/gather模式。在這樣一個(gè)系統(tǒng)中，一個(gè)外部客戶發(fā)送一個(gè)初始請(qǐng)求到“root”或者“parent”節(jié)點(diǎn)。這個(gè)root將請(qǐng)求分散到很多很多服務(wù)器上來(lái)執(zhí)行平行計(jì)算。每個(gè)碎片返回部分?jǐn)?shù)據(jù)，root將這個(gè)數(shù)據(jù)收集起來(lái)歸成單個(gè)的回應(yīng)到原始請(qǐng)求。這個(gè)模式在搜索引擎中是十分普遍的。開(kāi)發(fā)這樣一個(gè)分布式系統(tǒng)牽扯到很多樣板文件代碼：分散請(qǐng)求，收集回應(yīng)，與客戶端交互等等。代碼有很多是泛化的，再次，就如同在面向?qū)ο缶幊讨校a可以用這種方法被重構(gòu)，單個(gè)實(shí)現(xiàn)可以被提供的方法，這個(gè)方法也可以被用在任意容器中，只要他們實(shí)施一個(gè)特殊的接口就可以。特別是，為了實(shí)施一個(gè)Scatter/gather系統(tǒng)，用戶被要求提供兩個(gè)容器。第一，容器實(shí)施了樹(shù)結(jié)構(gòu)端節(jié)點(diǎn)；這個(gè)容器會(huì)執(zhí)行部分求值，并且返回對(duì)應(yīng)結(jié)果。第二個(gè)容器就是合并容器；這個(gè)容器帶走了所有樹(shù)結(jié)構(gòu)端節(jié)點(diǎn)的總生產(chǎn)額，并且將它們歸到單個(gè)回應(yīng)的組。

這樣的系統(tǒng)如圖5所示。

面相服務(wù)的架構(gòu)體系（SOA）更新地比原來(lái)早，和基于容器的分布式系統(tǒng)共享很多特征。比如，都強(qiáng)調(diào)可重用的定義好的通過(guò)網(wǎng)絡(luò)進(jìn)行通信的接口的組件。另一方面，SOA系統(tǒng)中的組件趨向于大粒度，相比于我們之前描述過(guò)的多容器模式，有更多的松耦合。此外，SOA中的組件實(shí)施商務(wù)活動(dòng)，我們?cè)谶@里重點(diǎn)關(guān)注的組件類似于比較容易創(chuàng)建分布式系統(tǒng)的通用庫(kù)。“微服務(wù)”這個(gè)詞語(yǔ)最近出來(lái)，描述的是我們?cè)谶@篇論文中討論過(guò)的組件的類型。

標(biāo)準(zhǔn)化管理接口的概念要至少要追溯到SNMP。SNMP主要關(guān)注管理硬件組件，而且現(xiàn)在還沒(méi)有出現(xiàn)用來(lái)管理微服務(wù)／基于容器的系統(tǒng)。這還是沒(méi)能阻止許多容器管理系統(tǒng)的開(kāi)發(fā)，包括Aurora，ECS，Docker Swarm，Kubernetes，Marathon和Nomad。

在第5節(jié)中提到的分布式算法都有段很長(zhǎng)的歷史。你們可以在Github上找到很多l(xiāng)eader選舉實(shí)施，雖然他們結(jié)構(gòu)上作為庫(kù)而不是獨(dú)立的組件。還是有很多受歡迎的work quene實(shí)現(xiàn)了的，包括Celery和Amazon SQS。Scatter/gather已經(jīng)成為一個(gè)企業(yè)的繼承模式。

如果需要轉(zhuǎn)載，請(qǐng)聯(lián)系我們哦，尊重知識(shí)產(chǎn)權(quán)人人有責(zé)；）
原文鏈接