本文講的是<b>彈性內建Apache Mesos與Apache Kafka架構</b>，【編者的話】本文由Mesosphere公司的Derrick Harries和Kafka項目代碼送出者Joe Stein合作撰寫，介紹了如何将Mesos與Kafka內建以簡化海量流資料的管理和配置工作。
流資料無處不在并持續增長——監控公司IT基礎設施的應用程式産生的名額資料流、零售行業訂單和物流産生的資料流、物流網裝置産生的活動資料流、金融公司的股票行情自動收錄器産生的資料流等等。這些越來越需要可以大規模實時處理所有這些流資料的基礎設施平台并使其可用于公司資料中心裡的各種應用程式。
Apache Mesos是一個叢集管理平台，可以對分布式應用程式或者架構提供高效的資源隔離和共享功能，它位于應用程式層和作業系統之間，使得其易于在大規模叢集環境中有效部署和管理各種應用。
下圖是Mesos架構的快速概述，其由Masters、Slaves和架構組成。
Mesos Master負責處理Slave節點和架構間的資源通訊，在任何情況下都隻能有一個Master作為上司在運作，在Master崩潰的情況下通常至少有一個備用機制來處理故障轉移（在代理模式下備用機制就是把資料傳輸到Master上）。Master負責為任務配置設定資源（在排程器和Slave節點之間），管理狀态還有維持高可用等等。
Mesos Slave在其服務運作節點啟動本地程序，這些程序是由執行器在Linux容器中啟動的，Linux容器是這些程序的父容器，除了容器自身的程序之外。
架構接收來自Master提供的Slave節點的資源（比如CPU和記憶體），架構由以下兩個部分組成：
排程器
排程器提供了如何管理架構内任務做什麼的基礎功能，其負責管理Slave節點運作成功和失敗間的狀态、任務失敗、内部應用程式配置和故障、對外通訊等等。
執行器
執行器在伺服器上執行應用程式代碼，在容器内部其他的程序也可以同樣啟動，這取決于應用程式本身的配置。通常情況下，執行器在伺服器上運作的業務邏輯代碼可以通過“Thin Lay”與Master互動。
首先，我們開始在Marathon上運作Kafka，但實際上我們将會遇到了如下一系列問題。
第一，Marathon不是為了管理有狀态服務而設計的，在有失敗發生或者一個簡單的服務重新開機的場景下，Marathon會随機的在任何符合服務定義限制的資源上重新開機服務，這樣對于有狀态服務是不适合的，因為這樣的話需要很高的操作代價來将本地狀态遷移到新的服務上。Kafka類似于其它各種存儲系統一樣都需要在本地磁盤上維護它自己的資料。在Marathon上運作Kafka意味着在Kafka Broker上的一個簡單的重新開機操作将會遷移每個Broker到不同的伺服器上，使得Broker需要從剩餘的Broker複制所有它自己的資料。因為通常Kafka存儲了大量的資料，這可能意味着會産生不必要的TB級資料的複制操作。使用者希望如果一個Broker發生了重新開機，Kafka Broker叢集可以等待直至重新開機操作完成，如果發生了嚴重的錯誤，仍然可以移走該Broker。
第二，Marathon不允許使用者選擇性地對從屬于這些程序子集的應用狀态進行負載均衡。在Kafka上，可以進行叢集擴充，使用者可以選擇性地從剩餘的叢集節點遷移一些分區資料到最新重新開機的Broker上。目前的Kafka叢集擴充操作還得通過管理界面手動進行。在叢集中啟動新的Broker不會配置設定任何資料，使用者必須選擇性地從剩餘的叢集節點遷移一些分區資料到新啟動的Broker上，同時Kafka不支援限額，是以遷移分區資料的操作必須仔細地分階段完成，避免網絡飽和和Kafka叢集内部的複制流量。Marathon沒有提供鈎子來允許應用程式執行特定的業務邏輯來進行故障檢測以及處出來流程。
鑒于如上提到的這些缺點，我們決定尋求将Kafka和Mesos內建在一起的架構方法。
下圖是Kafka Mesos架構的各種元件工作流程圖：
排程器在Marathon上運作，這樣如果排程器程序被殺死，Marathon可以在另外一個Mesos Slave節點上啟動新的排程器。
執行器作為排程器的中間人與Kafka Broker叢集互動，執行器尋找Kafka的二進制發行tgz壓縮包，然後執行相關的代碼，這樣就不僅允許使用者運作不同版本的Kafka，還可以給Kafka打更新檔，然後通過已配置的自動化部署平台運作模拟測試。
如果你想親自動手，這裡是Kafka Mesos架構的快速入門：
打開兩個終端視窗，進入從git clone的目錄後檢查kafka-mesos.proterties檔案，確定排程器已經配置在你的叢集上。
在第一個終端視窗運作：
在第二個終端視窗運作：
到了這一步你就會有三個Kafka Broker在運作了，更多的指令如下：
除了CLI指令行方式外，Kafka Mesos架構排程器還提供了Restful API來進行管理配置。
為了獲知Mesos Kafka排程器運作在哪台機器上，使用者需要查詢如下的Marathon API接口：
添加一個Broker：
啟動Broker：
查詢Broker的運作狀态：
已有的Kafka工具、消息生産者和消費者都可以工作在Kafka Mesos架構上，工作方式跟之前沒有運作在Mesos上一樣，使用者可以通過CLI或者Restful API發現其它Kafka Broker。
Kafka Mesos架構和DCOS前途無量，我們獲得了很多關于接下來如何以及繼續發展的回報和想法。這兒有一些目前正在讨論的如何改進內建的特性，不過沒有按照一定的順序羅列，其中的大部分特性我們正在将其添加到Apache Kafka項目中：
繼續支援新的Kafka和Mesos特性，修正bug。
将Kafka指令（比如kafka-topic等）內建到架構排程器中，這樣可以通過CLI或者Restful API來使用。
支援叢集的自動伸縮（包括自動重新配置設定Kafka分區），這樣可以在已知的流量低谷期之外充分利用Broker的資源（CPU、記憶體等等）。
機架感覺分區，改善容錯能力。
提供鈎子程式這樣消息生産者和消費者也可以從排程器啟動，并通過叢集管理。
按照負載和流量自動重新分區。
在接下來的時間裡，很多公司都期待着為它們增長的資料做更多的工作。單一整體集中式部署資料庫的時代一去不複返了，現在很多公司正在擴充新的專業分布式系統來處理海量資料，但是它們迫切需要減少部署和管理硬體資源工作的複雜度，進而避免淪為IT基礎設施的奴隸的風險。不僅Kafka會成為公司資料管道設施的核心，使得資料可以流向多種多樣的系統，而且由于像Kafka這樣的大資料技術将會繼續迅猛發展，是以像Mesos這樣的叢集管理系統也會日益重要。
=========================================================
譯者介紹
胡震， 曾任網際網路金融創業公司首席架構師&CTO，現在平安金融科技中心架構組負責技術管理和架構設計工作。
原文釋出時間為：2015-09-04
本文作者：國會山上的貓TuxHu
本文來自雲栖社群合作夥伴DockerOne，了解相關資訊可以關注DockerOne。
原文标題：彈性內建Apache Mesos與Apache Kafka架構