摘要：或許你的第一次微服務體驗，就從本文開始在本文中，和等紛紛亮相，并配有詳細的代碼說明。該角色與本地網絡及的配置設置相關。由于會在虛擬機初始化過程中自動執行配置任務，因此惟一的解決辦法就是將相關內容提取至多帶帶的劇本當中

這是一篇“溫和有趣”的技術文章，如果你初識Docker，對微服務充滿興趣，不妨一讀。或許你的第一次微服務體驗，就從本文開始……
在本文中，Mesos、Zookeeper、Marathon、Bamboo + HaProxy、Logstash、MesosDns、ElasticSearch和Kibana + Nginx等紛紛亮相，并配有詳細的代碼說明。本文旨在從最初的安裝和環境基礎建立開始，一步步指引你搭建自己的集群，實現你的目標架構，并在其上運行分布式服務。
小數友情提示：本文篇幅很長，干貨多多，值得收藏。

當開發者開始構建自己的第一款微服務應用程序時，大家通常不會過多考慮編排之類的問題。這時我們掌握的有兩到四臺服務器，而Ansible腳本已經能夠解決大部分問題。不過一旦大家的應用程序規模更大，或者各位決定使用一套環境承載多個不同項目，那么必然需要更多服務器……還有一款用于管理各服務器之上運行的服務。

不過剛剛我們已經提到了Ansible，難道它還不足以解決問題？這個嘛……答案是否定的。Ansible只能解決一項難題——部署。利用它，大家仍然需要搞定其它多種與微服務相關的問題：我們必須記得每臺服務器中還有多少剩余資源、手動管理各清單文件以匹配服務器容量、監控應用程序是否正常運行、當節點出現故障時進行服務回彈以及控制端口號沖突等等。如果大家擁有四臺服務器與十項服務，那么這些問題就變得比較明顯了。

而以此為基礎，我們就需要求助于Mesos了。Mesos是什么？這是一款集群管理器，其能夠幫助大家在分布式環境之下運行應用程序。Mesos的關鍵優勢包括：

資源管理與使用效率；

應用程序生命周期控制；

Docker容器支持能力。

最后一點也使得Mesos成為我們最為完美的解決方案選項。

由于找到七臺無需使用的服務器對于任何企業都是一項難題，因此我們在這里使用Vagrant（這是一款管理虛擬化流程的完美工具）在一臺本地設備（惠普Z230，i7-4770 3.40 GHz，16 GB內存）上構建自己的集群。另外，我們也提到了Ansible是一種便捷的部署方式，因此我們完全可以將整個安裝流程拆分成多個Ansible角色，從而封裝其內部所需要使用的標準Linux命令。

首先，我們需要建立Mesos集群基礎——這是一系列虛擬機系統，供我們在以下步驟中使用。這項工作利用Vagrant能夠輕松完成。
以下為來自Vargantfile的部分代碼：

如大家所見，我們可以使用一點Ruby代碼執行以下步驟：

基于CentOS 7.1鏡像構建虛擬機；

設置各虛擬機的資源上限（CPU與內存）；

將其與一套網絡相結合；

*利用每臺主機上的一組預定義變量啟動一套Ansible劇本（ansible/master.yml）。

簡單來講，Vagrant文件負責描述如何構建7套虛擬機系統：3套主虛擬機、3套從虛擬機與1套日志存儲（從技術層面講，這部分也應該進行分布處理，不過主機設備的資源較為有限）。大家需要做的是利用下面這條簡單命令將其投入運行：

`vagrant up`

前三步都是由Vagrant實現的，也不屬于我們今天的討論重點。接下來讓我們正式進入主題，通過Ansible設置集群。

正如大家在Vagrantfile當中所見，這里有3套主劇本及其各自角色：

主角色- 主機包含:
Mesos主實例；
Zookeeper實例；
Marathon實例；
Bamboo + HaProxy實例；

節點- 主機包含：
Mesos從實例；
Docker服務；
Logstash實例；
MesosDns實例；

日志- 主機包含：
ElasticSearch實例；
Kibana + Nginx實例。

接下來，我們將分別考慮各個角色，但這里需要首先強調一點：每個角色都取決于“OS”角色。該角色與本地網絡及YUM repo的DNS配置設置相關。嚴格地講，我們應當將這種關聯性從劇本層級中剝離出來，但為了簡單起見，這里我們先讓其保持原狀。

Zookeeper屬于我們系統中的一大重要組成部分。它將幫助我們構建集群并允許來自Mesos生態系統中的其它應用程序（例如Bambbo、MesosDns）與之進行通信。

Zookeeper的安裝過程非常簡單，而且不需要什么技巧——從RPM軟件包中獲取一套repo即可。我發現很多朋友傾向于利用現有源代碼構建應用，但在這里我們將使用基于供應商的Mesosphere軟件包。

大家需要的就是安裝該軟件包，設置節點ID，更新配置并啟動該服務。

下面來看Zookeeper安裝任務中的代碼片段：

在這里，我們需要回顧一下前面提到過的Vagrantfile——大家還記得下面這部分內容嗎？

Vagrant將全部必要的變量傳遞至Ansible，因此我們可以輕松在角色中對其加以利用。

正如Zookeeper的配置一樣，我們只需要對其中的主機IP進行配置：

以下為我們集群最終狀態下的簡單Zookeeper UI（簡稱ZK UI）屏幕：

正如之前所提到，MesoSphere的工作人員非常貼心地把Mesos軟件包加以整合，因此整個安裝流程也將變得更加輕松。

其中惟一需要注意的是，Mesos實際上由兩部分構成：

主節點（負責全部管理邏輯）；

從節點（負責運行應用并收集與主機資源相關的信息）；

換句話來說，我們需要為主節點與從節點實現不同的安裝邏輯。幸運的是，Ansible能夠非常輕松地完成這項任務。

以下為Mesos安裝任務的代碼片段：

面向這二者，我們需要安裝“mesos”軟件包（請記住，相關repo由“OS”角色提供）與Zookeeper URL。

下一站是進行設定。在這里，我們只提供諸如主節點quorum size與從節點docker支持等強制性設定。如果大家希望了解更多與特定配置相關的內容，不妨閱讀Mesos官方說明文檔。

由于MesoSphere軟件包同時提供主與從服務，因此我們需要根據當前角色（主/從）禁用其中的冗余部分。

為實現這一目標，大家應當使用Ansible的“conditional”機制。如果大家曾經認真閱讀過“master”劇本，就會發現我們已經傳遞了一條特殊的mesos_type變量：

在Mesos安裝完成后，大家可以審視其Web UI并嘗試點擊其中的按鈕：http://192.168.99.11:5050。
需要注意的是，如果當前主機并非Mesos Master的集群主節點，那么UI會將大家重新定向至主節點主機。另外，由于我們在虛擬機當中使用了DNS快捷方式（例如“master1”），因此大家也應當在自己的主機設備上使用同樣的快捷方式。
好了，就是這樣——我們的集群已經構建完成了。

在痛飲慶功酒之前，我們還需要回顧其中一些有趣的細節。

首先，大家需要記住——每個任務都擁有自己的背景信息，我們將其稱為“sandbox”。大家可以將其打開并分析全部輸出結果（可參閱Marathon部分的截屏內容）。需要注意的是，Docker容器必須首先進行pull——因此，如果大家沒有分配足夠的時間用于容器啟動，那么任務可能無法在UI中w/o任何消息（大家仍然能夠在相關節點的/var/logs/messages中看到消息內容）：

要對其進行修復，需要如以上片段所示配置其中的

另外，也不要忘記設置運行狀態檢查的寬限時長（Java應用往往會長時間處于活動狀態）。否則大家的應用很可能被關閉，并在其重新啟動前進行回彈（運行狀態檢查設定問題稍后我們再繼續討論）：

由于我們需要在自己的從主機上運行Docker容器，因此在這些主機上安裝Docker本體就成了必要任務。幸運的是，其安裝過程非常簡單：

下面來看Docker安裝任務中的代碼片段：

該步驟后的集群狀態：

盡管我們的Mesos集群已經上線并開始運行，但我們仍然無法在其上運行自己的Docker容器。嚴格地講，這時我們能夠在Mesos上直接運行的只有一套Mesos框架。當然，我們還擁有另一個更符合需求的選項——Marathon。

從技術角度來看，Marathon只是一款簡單的Java軟件包，且能夠通過jar命令進行啟動。但好在我們還擁有一套RPM軟件包，因此我們不需要擔心其“后臺化”、配置與控制等問題。此外，由于我們的軟件包由MesoSphere負責提供，因此其使用的是同樣的配置文件（Zookeeper URL），所以我們不需要對其另行設置。
Marathon安裝任務中的代碼片段：

Marathon還擁有一套Web UI，大家可以通過URL: http://master1:8080
進行訪問。

下面讓咱們找點樂子，部署一項簡單的REST服務（該服務及部署設定稍后另行討論）：

現在我們已經可以監控其狀態以及分配端口：

因此，我們可以對其進行調用并檢查其是否正常工作（當然，結果一切正常）。

我們甚至可以對服務進行規模擴展——如果有必要的話（目前規模擴展還沒有任何意義）：

另外，通過“sandbox”分析其日志（通過Mesos UI）：

在以上示例當中，我們只部署了一個服務實例。不過如果我們希望在其中使用大量實例與負載均衡機制，又該如何處理？這個嘛，作為答案的一部分，我們將采用HaProxy。這確實是一款非常出色的負載均衡器。不過如何對其進行配置？很簡單，交給Bamboo項目處理即可——它能夠與Zookeeper相對接，讀取Mesos狀態并生成HaProxy配置（利用每款Mesos應用的用戶定義角色）。

其安裝過程本來非常簡單，不過遺憾的是目前還沒有任何集成有Bamboo軟件包的公共RPM repo。大家可以對其進行手動構建，并通過本地文件實現安裝，但整個過程其實有點復雜。

以下為Bamboo安裝任務中的代碼片段：

在Bamboo安裝完成之后，大家可以通過其Web UI進行設置: http://master1:8000

另外也可以通過HaProxy訪問我們的服務: http://master1/services/fibonacci/1

請注意，我們在Bamboo安裝中使用了多帶帶的Ansible劇本（master_bamboo.yml）。之所以這樣處理，是因為我們需要借此保證其RPM軟件包在于劇本內運行之前被上傳至虛擬主機當中。

由于Vagrant會在虛擬機初始化過程中自動執行Ansible配置任務，因此惟一的解決辦法就是將Bamboo相關內容提取至多帶帶的劇本當中，并執行以下算法：

利用vagrant up啟動虛擬機；

將RPM文件通過SCP上傳至虛擬機當中；

對Vagrantfile中的ansible.playbook進行變更；

運行vagrant provision master1命令。

如大家所見，Bamboo是整套生態系統中最為雜亂的部分。所以我們不妨了解其替代方案——例如Marathon負載均衡器。

該步驟后的集群狀態：

我們一直沒有談到一個重要的問題——如果我們的服務需要彼此進行通信，該如何加以實現？我們是否能夠立足于單一Mesos集群內部實現服務發現？是的，答案是肯定的！相關方案也非常明確——MesosDns。這里我們的解決思路非常明確——讀取Mesos集群狀態并通過DNS（A與SRV記錄）及HTTP API進行發布。后一點非常重要，因為這將幫助我們輕松構建客戶端負載均衡w/o【1，2】。

整個安裝過程稍有些麻煩，不過沒什么特別之處需要注意。

以下為MesosDns安裝任務中的代碼片段：

Config文件中也沒有什么值得一提的內容：

大家可以通過以下SRV記錄請求檢查已安裝的實例:

http://172.17.42.1:8123/v1/services/_fibonacci-service._tcp.marathon.mesos.

歡呼！我們距離成功已經很近了！必須承認，如果大家已經耐著性子讀到這里，那么這個議題肯定非常有趣。

值得慶幸的是，這部分并沒有太多內容可談。日志記錄就是日志記錄。我們只需要將Logstash安裝在全部Mesos從節點當中即可……

以下為LogStash安裝任務中的代碼片段：

另外對其config文件進行配置，確保將數據發布至日志節點當中：

與此同時，我們還需要在這些節點上安裝ElasticSearch與Kibana。
ELK安裝任務中的代碼片段：

這里使用Docker的惟一理解就是其更為簡便。當然，我們也不需要也不應該將日志數據保存在容器當中。

在安裝完成之后，大家就可以通過Kibana的Web界面分析ES當中的日志了：http://log1:5601

下面就是我們的目標架構，或者說我們的最終構建成果。看起來不錯，對吧？
圖十八
在我們的腳本當中，惟一的單點故障來源就是HaProxy/Bamboo。不過大家可以將二者部署至全部主節點當中并面向用戶使用基于DNS的輪循機制，從而輕松解決這個問題。

到這里我們已經擁有了自己的集群。現在，是時候考慮我們計劃運行于其上的分布式服務了（運行簡單應用太過無聊，這里不再贅述）。

我已經開發出了一套基于REST服務的小巧SpringBoot，其能夠計算斐波那契序列中的第N個數字。這項服務的核心功能在于，其可以調用自身其它實例以計算該序列中的前一個值。

我知道，這種實現方式效率極低而且很容易導致死鎖（大家不妨想想這是為什么），但我在這里主要是借此對跨服務通信進行說明。
該服務利用MesosDns HTTP API進行服務發現：

另外還有一套客戶端負載均衡機制（我們當然需要盡可能減少故障點數量，對吧？）：

在我們開始部署工作之前，首先需要為自己的應用程序構建一套Docker鏡像。在這里我就不贅述整個流程了，感興趣的朋友可以查看Gradle配置與Docker說明文件了解相關內容。

完成之后，我們將該鏡像發布至一套Docker注冊表當中（也可以通過Gradle實現），這樣Marathon就能夠通過從節點上的Docker實例對其進行下載了。大家可以在這里找到我創建的示例: https://hub.docker.com/r/krestjaninoff/fibonacci-service/

最后也是最重要的部分，Marathon。如之前所提到，我們可以利用Marathon UI實現部署任務。不過這并不是最具“技巧性”的辦法。Marathon也擁有自己的REST API，我們可以通過簡單的“curl”客戶端對其加以使用：

以下為SpringBoot mesos installation manifest中的代碼片段：

讓我來簡單介紹一下該配置文件中的內容（各部分逐一說明）：

應用程序 id (在Bamboo配置中使用);

資源限制（如果該集群不具備必要容量，應用程序將不會啟動——這一點對于基于虛擬機的集群尤為重要）與實例數量；

容器設置：

forcePullImage是在正確時間點對容器進行更新的惟一方式；

SpringBoot允許我們通過各環境變量進行config文件覆蓋，因此這是一種良好的容器操作方式；

由于$HOST變量負責提供DNS名稱（這一點甚至在Marathon官方說明文件中亦沒有體現），因此從Docker容器內獲取主機本地IP的惟一方式就是默認Docker網絡接口172.17.42.1；

backoff因數/設定避免集群運行“異常”應用，即無法正常啟動并將因此造成反復嘗試的應用（具體方式為延后每一次啟示嘗試）；

運行狀態檢查允許Marathon了解應用實例處于正常運行抑或是必須執行回彈；

upgradeStrategy幫助大家在無需接入能力的前提下實現應用更新（首先延后新版本，而后停止當前版本）。

最后要提到的是Bamboo，其同樣可以通過REST API進行配置。這項任務非常簡單：

到這里，我們就已經擁有了“deploy”角色……
以下為Deployment安裝任務中的代碼片段：

大家可以通過運行“deploy”劇本的方式進行調用：

到這里全部結束！

調用該服務 curl http://master1:5000/service/fibonacci/15 (或者直接調用curl http://node2:31135/15);

檢查結果（正確值為610）；

檢查日志內容(http://log1:5601)。

最后一點非常有趣。大家可以看到哪臺主機被調用或者響應耗費了多長時間：

好了，今天的文章到這里就結束了。沒錯，其篇幅遠超一般的“Hello World”指南——不過平心而論，內容還是非常有趣的，對吧？

英文原文鏈接：http://trustmeiamadeveloper.com/2015/12/17/mesos-as-a-docker-containers-farm/