目錄
mesos簡介
zookeeper簡介
marathon簡介
docker叢集實踐
mesos叢集部署
一、mesos簡介
mesos是apache下的開源分布式資源管理架構，它被稱為分布式系統的核心。mesos最初是由加州大學伯克利分校的amplab開發，後在twitter得到廣泛使用。
mesos-master：主要負責管理各個framework和slave，并将slave上的資源配置設定給各個framework。
mesos-slave：負責管理本節點上的各個mesos-task，比如：為各個executor配置設定資源。
framework：計算架構，如：hadoop、spark、kafaka、elasticserach等，通過mesosschedulerdiver接入mesos
executor：執行器，就是安裝到每個機器節點的軟體，這裡就是利用docker的容器來擔任執行器的角色。具有啟動銷毀快，隔離性高，環境一緻等特點。
mesos-master是整個系統的核心，負責管理接入mesos的各個framework(由frameworks_manager管理)和slave(由slaves_manager管理)，并将slave上的資源按照某種政策配置設定給framework(由獨立插拔子產品allocator管理)。
mesos-slave負責接受并執行來自mesos-master的指令、管理節點上的mesos-task，并為各個task配置設定資源。mesos-slave将自己的資源量發送給mesos-master，由mesos-master中的allocator子產品決定将資源配置設定給哪個framework，目前考慮的資源有cpu和記憶體兩種，也就是說，mesos-slave會将cpu個數的記憶體量發送給mesos-master，而使用者送出作業時，需要指定每個任務需要的cpu個數和記憶體。這樣當任務運作時，mesos-slave會将任務放導包含固定資源linux container中運作，以達到資源隔離的效果。很明顯，master存在單點故障問題，為此mesos采用了zookeeper解決該問題。
framework是指外部的計算架構，如果hadoop、mesos等，這些計算架構可通過注冊的方式接入mesos，以便mesos進行統一管理和資源配置設定。mesos要求可接入的架構必須有一個排程子產品，該排程器負責架構内部的任務排程。當一個framework想要接入mesos時，需要修改自己的排程器，以便向mesos注冊，并擷取mesos配置設定給自己的資源，這樣再由自己的排程器将這些資源配置設定給架構中的任務，也就是說，整個mesos系統采用了雙層排程架構：第一層，由mesos将資源配置設定給架構。第二層，架構自己的排程器将資源配置設定給自己内部的任務。
目前mesos支援三中語言編寫的排程器，分别是c++、java、python。為了向各種排程器提供統一的接入方式，mesos内部采用c++實作了一個mesosschedulerdriver(排程驅動器)，framework的排程器可調用該driver中的接口與mesos-master互動，完成一系列功能(如注冊，資源配置設定等。)
executor主要用于啟動架構内部的task。由于不同的架構，啟動task的接口或者方式不同，當一個新的架構要接入mesos時，需要編寫一個executor，告訴mesos如何啟動該架構中的task。為了向各種架構提供統一的執行器編寫方式，mesos内部采用c++實作了一個mesosexecutordiver(執行器驅動器)，framework可通過該驅動器的相關接口告訴mesos啟動task的方式。
整體架構如圖1.1-1所示：
圖1.1-1總體架構
圖1.1-1展示了mesos的重要組成部分，mesos由一個master程序管理運作着每個用戶端節點的slave程序和跑任務的mesos計算架構。
mesos程序通過計算架構可以很細緻的管理cpu和記憶體等,進而提供資源。每個資源提供都包含了一個清單(slave id,resource1：amount1,resource2,amount2,…)master會根據現有的資源決定提供每個計算架構多少資源。例如公平分享或者根據優先級分享。
為了支援不同種的政策，master通過插件機制新增額一個allocation子產品使之配置設定資源更簡單友善。
一個計算架構運作在兩個組建之上，一個是scheduler，他是master提供資源的注冊中心，另一個是executor程式，用來發起在slave節點上運作計算架構的任務。master決定給每個計算架構提供多少計算資源，計算架構的排程去選擇使用哪種資源。當一個計算架構接受了提供的資源，他會通過mesos的任務描述運作程式。mesos也會在相應的slave上發起任務。
資源提供案例,如圖1.1-2所示：
圖1.1-2資源提供案例
下面我帶大家一起熟悉圖1.1-2的流程步驟：
slave1報告給master他擁有4核cpu和4g剩餘記憶體，marathon調用allocation政策子產品，告訴slave1計算架構1應該被提供可用的資源。
master給計算架構1發送一個在slave上可用的資源描述。
計算架構的排程器回複給master運作在slave上兩個任務相關資訊，任務1需要使用2個cpu，記憶體1g，任務2需使用1個cpu，2g記憶體。
最後，master發送任務給slave，配置設定适當的給計算架構執行器，繼續發起兩個任務(圖1.1-2虛線處)，因為任有1個cpu和1g記憶體未配置設定，allocation子產品現在或許提供剩下的資源給計算架構2。
除此之外，當任務完成，新的資源成為空閑時，這個資源提供程式将會重複。
二、zookeeper簡介
zookeeper是一個分布式的，開放源碼的分布式應用程式協調服務，是google的chuby一個開源的實作，是hadoop和hbase的重要元件。它是一個分布式應用提供一緻性服務的軟體，提供的功能包括：配置維護、名字服務、分布式同步、組服務等。
1.2.1zookeeper角色
leader(上司者)：負責投票發起和決議，更新系統狀态。
follower(跟随者)：follower用于接收客戶請求并向用戶端傳回結果，在選主過程中參與投票。
observer(觀察者)：observer可以接受用戶端連接配接，将寫請求轉發給leader節點，但observer不參加投票過程，隻同步leader的狀态，observer的目的是為了拓展系統，提高讀取速度。
client(用戶端)：請求發起方。
1.2.2zookeeper工作原理
zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實作這個機制的協定叫做zab協定。zab協定有兩種模式，它們分别是恢複模式(選主)和廣播模式(同步)。當服務啟動或者在上司者崩潰後，zab就進入了恢複模式，當上司者被選舉出來，且大多數server完成了和leader的狀态同步以後，回複模式就結束了。狀态同步保證了leader和server具有相同的系統狀态。
為了保證事物的順序一緻性，zookeeper采用了遞增的事物id号(zxid)來辨別事物。所有的提議(proposal)都在被提出的時候加上了zxid。實作中zxid是一個64位的數字，它高32位是epoch用來辨別leader關系是否改變，每次一個leader被選出來，它都會有每一個server在工作過程中三種狀态。
q looking：目前server不知道leader是誰，正在搜尋。
q leading：目前server即為選舉出來的leader。
q following：leader已經選舉出來，目前server與之同步。
1.2.3zookeeper選舉流程
當leader崩潰或者leader失去大多數的follower，這時候zk進入恢複模式，恢複模式需要重新選舉出一個新的leader，讓所有的server都恢複到一個正确的狀态。
zk的選舉算法有兩種：
基于basic paxos實作
基于fast paxos算法實作
系統預設的選舉算法為fast paxos。
1.2.4zookeeper同步流程
選完leader以後，zk就進入狀态同步過程。
leader等待server連接配接。
follower連接配接leader，将最大的zxid發送給leader。
leader根據follower的zxid确定同步點。
完成同步後通知follower已經成為uptodate狀态。
follower收到uptodate消息後，又可以重新接受client的請求進行服務。
1.2.5zookeeper工作流程
leader三大功能：
恢複資料
維持與learner的心跳，接收learner請求并判斷learner的請求消息類型
learner的消息類型主要有ping消息、request消息、ack消息、revalidate消息，根據不同的消息類型，進行不同的處理。
ping消息是指learner的心跳資訊；request消息是follower發送的提議資訊，包括寫請求及同步請求；ack消息是follower的對提議的回複，超過半數的follower通過，則commit該提議；revalidate消息是用來延長session有效時間。
follower主要四大功能：
向leader發送請求（ping消息、request消息、ack消息、revalidate消息）。
接收leader消息并進行處理。
接收client的請求，如果為寫請求，發送給leader進行投票。
傳回client結果。
follower的消息循環處理如下幾種來自leader的消息：
ping消息：心跳消息。
proposal消息：leader發起的提案，要求follower投票。
commit消息：伺服器端最新一次提案的資訊。
uptodate消息：表明同步完成。
revalidate消息：根據leader的revalidate結果，關閉待revalidate的session還是允許其接受消息。
syn消息：傳回sync結果到用戶端，這個消息最初由用戶端發起，用來強制得到最新的更新。
三、marathon簡介
marathon是一個mesos架構，能夠支援運作長服務，比如web應用等。它是叢集的分布式init.d能夠原樣運作任何linux二進制釋出版本，如tomcat、play等等。它也是一種私有的pass，實作服務的發現，為部署提供rest api服務，有授權和ssl、配置限制，通過haproxy實作服務發現和負載平衡。
四、docker叢集實踐
1.4.1叢集環境準備
1.4.2zookeeper僞叢集安裝部署
部署zookeeper需要java支援, 主流1.7，穩定最新1.8，開發最新1.9，這邊選擇yum安裝即可支援zookeeper
1.4.2.1zookeeper配置檔案詳解
1.4.2.2zookeeper配置檔案修改
由于是僞叢集的配置方式，b(ip位址)都是一樣，是以不同的zookeeper執行個體通信端口号不能一樣，是以要給它配置設定不同的端口号。
1、建立三個目錄來存放zookeeper的資料
2、生成三份zookeeper配置檔案
3、修改zk2、zk3對應的資料存放目錄以及端口
1.4.2.3zookeeper角色檢視
1、啟動zookeeper并檢視角色
2、連接配接zookeeper
五、mesos叢集部署
安裝mesosphere倉庫，需要在mesos master和mesos slave節點安裝。
1.5.1mesos_master部署
1.5.2mesos_slave部署
1.5.3mesos_web界面
通路：http://192.168.56.11:5050，如圖1.5-1所示：
圖1.5-1tasks表格沒有任何條目
運作mesos任務，可以在web界面檢視task如圖1.5-2所示：
圖1.5-2運作mesos任務
1.5.4marathon調用mesos運作docker容器
通過marathon預設監聽8080端口,通過marathon建立項目，如圖1.5-3所示：
圖1.5-3marathon界面
下面通過mesos排程，使用marathon來建立一個nginx鏡像的docker容器,marathon啟動時會讀取/etc/mesos/zk配置檔案，marathon通過zookeeper來找到mesos master。
marathon有自己的rest api，我們通過api的方式來建立一個nginx的docker容器。首先建立如下的配置檔案nginx.json
使用curl的方式調用
通路docker随機啟動的端口31011，如圖1.5-4所示：
圖1.5-4成功通路nginx界面
在marathonweb界面檢視，如圖1.5-5所示：
圖1.5-5marathonweb界面檢視nginx已經在運作
在mesos界面檢視，如圖1.5-6所示：
圖1.5-5mesos界面檢視nginx tasks
也可以點選marathon左上角的建立進行建立容器。
注意：這裡哪nginx來舉例，注冊中心的marathon+mesos+docker叢集是不适合用于服務的，也就是說不适合于對外開放端口的。比如說爬蟲，因為不開放端口，需要做的僅僅是從隊列中取資源，然後處理，存庫。
這個僅僅是job的釋出管理運作，還有沒ci，也就是說持續內建，後期我會釋出jenkins+docker+mesos+marathon+git持續內建的方案，如果将代碼釋出結合dco架構。
作者介紹 徐亮偉
進階工程師，專攻自動化運維、監控、雲計算領域。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-06-06</b>