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

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

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

Panamax中工作流的用例：

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

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

• 虛擬機創建—在提供集群服務的云服務平臺上開啟虛擬機
• 對虛擬機進行管理/編排工作—（Kubernetes、 CoreOs 等等）
• Panamax遠程客戶端/適配器的安裝以及代理注冊服務

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

工作流的執行

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

• 接收將要被執行的工作流的描述信息（也就是一個容器的列表）
• 按照正確的順序啟動容器并且對執行過程進行監控
• 在工作流的不同執行階段對數據進行打包和調度
• 報告當前工作流的執行情況

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

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

用于提供微服務的短生命周期容器

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

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

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

特定功能的容器工作流

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

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

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