摘要：容器之間相互隔離的優(yōu)點使得容器成為了分布式系統(tǒng)中合適的基本單元。分布式系統(tǒng)設計模式在面向對象編程被使用了幾年之后，設計模式出現(xiàn)并被編成文檔。

在20世紀80年代末和20世紀90年代初，面向對象編程徹底改革了軟件開發(fā)方法，普及了將應用程序作為模塊化組件的創(chuàng)建方法。隨著基于容器化軟件組件的微服務架構的逐漸普及，現(xiàn)在在分布式系統(tǒng)開發(fā)中也發(fā)生著類似的革命。容器之間相互隔離的優(yōu)點使得容器成為了分布式系統(tǒng)中合適的基本單元。隨著這種架構類型的成熟，我們可以看到設計模型的出現(xiàn)，從容器的角度來思考問題可以將低層次代碼細節(jié)抽象化。

這篇論文描述了我們觀察到的三種基于容器分布式系統(tǒng)的設計模型：單個容器模式，密切合作模式容器的單節(jié)點模式，以及分布式算法的多節(jié)點模式。跟面向對象編程的設計模式類似，這些模式包含了最佳實踐，簡化了開發(fā)，使系統(tǒng)更加可靠。

在面向對象編程被使用了幾年之后，設計模式出現(xiàn)并被編成文檔。這些模式被編纂好，并且被規(guī)整成解決特別常見的編程問題的方法。這個編纂進一步提高了編程最前沿的技術，因為它可以讓經(jīng)驗不那么豐富的人也寫出很好的代碼，并且讓重復使用的庫文件的蓬勃發(fā)展，這些庫文件可以讓開發(fā)代碼更加可靠、快速。

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

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

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

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

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

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

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

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

1. sidcar模式

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

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

2. Ambassador模式

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

3. 適配器模式

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

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

1. leader選舉模式

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

2. work quene模式

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

3. Scatter/gather模式

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

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

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

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

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

如果需要轉載，請聯(lián)系我們哦，尊重知識產(chǎn)權人人有責；）
原文鏈接