本文作者Ross Jimenez來自CenturyLink Labs，他受到了Iron.io一篇介紹容器微服務(wù)的相關(guān)文章的啟發(fā)，于是介紹了自己團(tuán)隊在構(gòu)建Panamax的時候所用到的微服務(wù)的理念，此外作者還大致介紹了微服務(wù)和容器技術(shù)相結(jié)合之后的優(yōu)勢，以及他們怎樣通過微服務(wù)化的容器來構(gòu)建工作流模型。

通過Docker容器可以構(gòu)建具有特定功能的工作流，也可以讓容器在后臺執(zhí)行一系列的異步任務(wù)，我們所開發(fā)的Panamax項目，其工作模式正是依據(jù)Docker容器的這一特性進(jìn)行設(shè)計的。我偶然在Iron.io看到這篇有趣的文章，“Docker化的微服務(wù)的短暫生命周期”，盡管我已經(jīng)對Iron.io所提供的服務(wù)很熟悉，但是通過這篇文章，我更深入地了解他們?nèi)绾问褂萌萜?，特別是使用短生命周期的容器來完成他們的服務(wù)，這的確給了我很多啟發(fā)，于是我寫下了這篇博客。

我們在項目中也一直使用短生命周期的容器，并把它們作為工作流中的一系列的功能性的容器，但是具體的使用方式和Iron.io有所不同。在Iron.io中，這些具有特定功能的工作流可以被一個事件觸發(fā)，或者可以被提前指定好，并且可以按照即時的需求在后臺完成對應(yīng)的工作。在我們的使用環(huán)境中，工作流中的最初的幾步要求先被完成，整個工作流能否順利執(zhí)行要依賴與工作流開始幾步所產(chǎn)生的輸出結(jié)果。

Panamax中工作流的用例：

在Panamax項目中，我們希望其中的一個功能是幫助我們的用戶在云服務(wù)平臺上遠(yuǎn)程啟動一個集群，這樣用戶就可以輕易地在上面部署Panamax模板。我們目前已經(jīng)可以實現(xiàn)在遠(yuǎn)程基礎(chǔ)設(shè)施上部署模板，但是這需要對基礎(chǔ)設(shè)施進(jìn)行相關(guān)的設(shè)置，并且安裝遠(yuǎn)程代理/適配器，這些都是相互獨立的過程。

讓我們通過一個例子，來看如何進(jìn)行端對端的自動化操作。這個例子可能是一個比較簡化的例子，假設(shè)這里的功能需要三個基本的步驟來完成：

虛擬機(jī)創(chuàng)建—在提供集群服務(wù)的云服務(wù)平臺上開啟虛擬機(jī)對虛擬機(jī)進(jìn)行管理/編排工作—（Kubernetes、 CoreOs 等等）Panamax遠(yuǎn)程客戶端/適配器的安裝以及代理注冊服務(wù)

讓我們來繼續(xù)討論，對于上面這幾個步驟，由于每一步的相關(guān)執(zhí)行邏輯都被封裝在對應(yīng)的Docker容器中，所以每一個容器僅僅負(fù)責(zé)執(zhí)行一些指定的步驟。理論上我們可以通過并行的方式來同時啟動這些容器，但是實際上我們會受到一定的限制，當(dāng)前這一步如果想要正常運(yùn)行，就必須要從前一步的運(yùn)行結(jié)果中取得某些數(shù)據(jù)（舉例來說，如果我們不知道在step1中所創(chuàng)建的服務(wù)器的地址，那么在step2中我們就無法安裝對應(yīng)的編排工具）

工作流的執(zhí)行

在嘗試處理不同例子的過程中，我們逐漸構(gòu)建起了一個一般性的通用框架，我們可以用這個來進(jìn)行基于容器的工作流的編排，就像我們在上面所描述的那樣。此外，我們的框架還需要完成以下的工作：

接收將要被執(zhí)行的工作流的描述信息（也就是一個容器的列表）按照正確的順序啟動容器并且對執(zhí)行過程進(jìn)行監(jiān)控在工作流的不同執(zhí)行階段對數(shù)據(jù)進(jìn)行打包和調(diào)度報告當(dāng)前工作流的執(zhí)行情況

還有一個需要解決的有趣問題是，如何在容器之間進(jìn)行數(shù)據(jù)的遷移。我們通過使用Unix的管道模型（piping model），來解決這個問題。我們會attach到一個運(yùn)行容器的標(biāo)準(zhǔn)輸出，并將輸出的內(nèi)容捕獲，之后再將數(shù)據(jù)寫入工作流鏈中下一個容器的標(biāo)準(zhǔn)輸入流中。隨著工作流中的后續(xù)步驟被不斷執(zhí)行，前面幾個步驟的輸出結(jié)果就變成了接下來幾個步驟的輸入結(jié)果。

開始的時候，我們將這個框架集成到了Panamax項目中，但是我們很快就要將這個框架以單獨的項目的形式發(fā)布出來，這樣就可以幫助其他開發(fā)者輕松實現(xiàn)類似的工作模式。

用于提供微服務(wù)的短生命周期容器

下面讓我們討論一下在具有特定功能的工作流中使用容器的優(yōu)點:

容器可以運(yùn)行在任何支持容器工作方式的計算資源上，所以通過容器構(gòu)建的整個工作流或者是工作流中的某些步驟也可以直接在這些計算資源上運(yùn)行。使用容器可以很方便地對所執(zhí)行的任務(wù)進(jìn)行邏輯單元的劃分，并且容器之間的隔離性可以使其在基于微服務(wù)的設(shè)計模式中很好地進(jìn)行工作。只有在容器實際執(zhí)行的時候，計算資源才會被消耗，也就是說，只有在具體執(zhí)行任務(wù)的時候才需要計算資源。工作流的模塊化性質(zhì)可以使得工作流中的每個步驟或者每一個邏輯單元，都變得容易進(jìn)行 修改/擴(kuò)展/重組/架構(gòu)解耦。

考慮到在采用上述策略后，我們整個過程中的每一步都是解耦的，這樣的話，對某個邏輯單元進(jìn)行重用，就會變得很容易。這就是微服務(wù)架構(gòu)的一個令人興奮的優(yōu)點：即對于工作單元的可組合的能力。工作單元可以被重新排序，容易修改并且易于擴(kuò)展。雖然，我們用于工作的容器都是用GoLang語言來構(gòu)建的，但實際上，每一個容器都相當(dāng)于是一個黑盒，因此，開發(fā)者可以用任何他們自己希望的方式來實現(xiàn)。這與Panamax的遠(yuǎn)程客戶端/適配器的概念很相似，它們同樣都是被封裝在容器中。

特定功能的容器工作流

我希望通過上面的介紹，你已經(jīng)對這個模式的具體工作方式有了一些了解。雖然我們這里討論的是一個很具體的例子，對于這種工作模式來說，還存在著更多的可能性。這種模式里構(gòu)建即時所需的傳感器驅(qū)動（on-demand sensor driven）和基于事件的架構(gòu)（event based architectures）的能力使我感到非常興奮， 此外，對于如何計算資源被消耗的過程方面，也給了我很多啟發(fā)。如果Docker允許你在亞秒級別啟動一個容器，在許多情況下，解決方案可以被完全重新構(gòu)建，目的是要使得解決方案更加能基于事件驅(qū)動（event driven）以及滿足實時需求（on-demand）。這意味著資源密集型的解決方案將變得更少。因為計算資源只有在短生命周期容器存在的情況下才會被需要。

還存在一種可能的解決方案：構(gòu)建基于容器的函數(shù)庫，這個函數(shù)庫可以幫助非技術(shù)型用戶很容易地通過可視化的方式構(gòu)建他們自己的工作流。比如傳感器類型的容器可以查詢API、 執(zhí)行容器可以執(zhí)行工作單元。最后再說一點，雖然我們目前只開發(fā)了最基本的順序工作流，一旦你在實際工作中需要使用更復(fù)雜的工作流，只要遵照一些工作流模式的簡單的邏輯規(guī)則， 你就完全有可能自己構(gòu)建出一個獨特的解決方案。將上面提到的所有的這些優(yōu)勢結(jié)合在一起，再加上容器的“到處運(yùn)行”的特性，我想以后可能會產(chǎn)生出許多令人稱贊產(chǎn)品。

原文鏈接：http://dockerone.com/article/195