將Apache Mesos與Apache Kafka彈性集成

【編者的話】本文由Mesosphere公司的Derrick Harries和Kafka項目代碼提交者Joe Stein合作撰寫，介紹了如何將Mesos與Kafka集成以簡化海量流數據的管理和配置工作。

Kafka 和 Mesos 是非常知名和成功的Apache項目，它們每個都獲得了大型社區的支持，還有 Confluent 和 Mesosphere 這樣的公司各自圍著它們構筑生態系統。最近,兩家公司合作使Kafka成為Mesosphere數據中心處理系統（ DCOS ）的 首批認證服務之一 。

流數據無處不在并且持續增長中——監控公司IT基礎設施的應用程序產生的指標數據流、零售行業訂單和物流產生的數據流、物流網設備產生的活動數據流、金融公司的股票行情自動收錄器產生的數據流等等。這些越來越需要可以大規模實時處理所有這些流數據的基礎設施平臺并使其可用于公司數據中心里的各種應用程序。

鑒于Kafka獨特的實時移動大量數據的能力，使得它特別適合管理流數據，許多組織使用Kafka增強實時數據監測、分析、安全、欺詐檢測和流處理能力。Kafka在公司的數據中心集成各種系統時也起著關鍵作用。Apache Mesos抽象了數據中心資源，從而使其易于部署和管理分布式應用程序和系統。這篇文章介紹了如何在Mesos上運行Kafka集群來簡化管理大規模流數據的任務。

Apache Kafka的快速概述：

Kafka是一個分布式、高吞吐量、低延遲的發布-訂閱類型的消息系統。自從2011年開源以來，Kafka已經在業內得到了廣泛采用，比如在 LinkedIn、Netflix、Uber這樣的互聯網公司還有像Cisco和高盛這樣的傳統行業公司。在這些公司中Kafka被用來構筑關鍵數據的主干管道，每天實時移動的消息有數千億條之多。

Apache Mesos：一分鐘內0到60

Apache Mesos是一個集群管理平臺，可以對分布式應用程序或者框架提供高效的資源隔離和共享功能，它位于應用程序層和操作系統之間，使得其易于在大規模集群環境中有效部署和管理各種應用。

下圖是Mesos架構的快速概述，其由Masters、Slaves和框架組成。

Mesos Master

Mesos Master負責處理Slave節點和框架間的資源通訊，在任何情況下都只能有一個Master作為領導在運行，在Master崩潰的情況下通常至少有一個備用機制來處理故障轉移（在代理模式下備用機制就是把數據傳輸到Master上）。Master負責為任務分配資源（在調度器和Slave節點之間），管理狀態還有維持高可用等等。

Mesos Slave

Mesos Slave在其服務運行節點啟動本地進程，這些進程是由執行器在Linux容器中啟動的，Linux容器是這些進程的父容器，除了容器自身的進程之外。

Mesos框架

框架接收來自Master提供的Slave節點的資源（比如cpu和內存），框架由以下兩個部分組成：

1.調度器

調度器提供了如何管理框架內任務做什么的基礎功能，其負責管理Slave節點運行成功和失敗間的狀態、任務失敗、內部應用程序配置和故障、對外通訊等等。

2.執行器

執行器在服務器上執行應用程序代碼，在容器內部其他的進程也可以同樣啟動，這取決于應用程序本身的配置。通常情況下，執行器在服務器上運行的業務邏輯代碼可以通過“Thin Lay”與Master交互。

讀者可以在這兒閱讀到更多的有關Mesos架構方面的信息。

Marathon

Marathon 是一個Mesos框架，便于啟動任何可長時間運行的應用程序，從而不需要為特定的應用定制開發框架。Marathon自動提供了很多在集群環境中運行應用需要的特性，比如高可用性、節點約束、應用健康檢查、腳本語言API和服務發現、一個易于使用的Web用戶界面。然而Marathon框架的簡潔也帶來了在伸縮性和定制化方面的損失，應用程序沒有規定應該如何按照一定的約束來分配資源，例如數據保護或數據關聯性分析。

首先，我們開始在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集成在一起的框架方法。

在Mesos上運行Kafka：框架

下圖是Kafka Mesos框架的各種組件工作流程圖：

Kafka Mesos調度器：

調度器為Kafka集群提供了操作自動化功能，任何版本的Kafka都可以通過調度器運行在Mesos上，由調度器決定任務是否失敗、是否需要管理和集群伸縮，調取器的狀態由Zookeeper來維護，同時可以通過Restful API來進行配置和其它任務管理。

調度器在Marathon上運行，這樣如果調度器進程被殺死，Marathon可以在另外一個Mesos Slave節點上啟動新的調度器。

Kafka Mesos執行器

執行器作為調度器的中間人與Kafka Broker集群交互，執行器尋找Kafka的二進制發行tgz壓縮包，然后執行相關的代碼，這樣就不僅允許用戶運行不同版本的Kafka，還可以給Kafka打補丁，然后通過已配置的自動化部署平臺運行模擬測試。

讓我們開始：在Apache Mesos上安裝Apache Kafka

如果你想親自動手，這里是Kafka Mesos框架的快速入門：

打開兩個終端窗口，進入從git clone的目錄后檢查kafka-mesos.proterties文件，確保調度器已經配置在你的集群上。

在第一個終端窗口運行：

在第二個終端窗口運行：

到了這一步你就會有三個Kafka Broker在運行了，更多的命令如下：

管理Kafka Mesos框架

除了CLI命令行方式外，Kafka Mesos框架調度器還提供了Restful API來進行管理配置。

Restful API：

為了獲知Mesos Kafka調度器運行在哪臺機器上，用戶需要查詢如下的Marathon API接口：

curl -X GET -H "Content-type: application/json" -H "Accept: application/json" http://localhost:8080/v2/tasks

Restful API提供了與CLI命令行方式相同的所有特性，呈現為如下的格式：

*/api/brokers/<cli command>/id={broker.id}&<k>=<v>

添加一個Broker

“ http://localhost:7000/api/brok ... ot%3B

啟動Broker

“ http://localhost:7000/api/brokers/start?id=0"

查詢Broker的運行狀態

curl " http://localhost:7000/api/brokers/status *

已有的Kafka工具、消息生產者和消費者

已有的Kafka工具、消息生產者和消費者都可以工作在Kafka Mesos框架上，工作方式跟之前沒有運行在Mesos上一樣，用戶可以通過CLI或者Restful API發現其他Kafka Broker。

當為了高可用性在Marathon上運行框架調度器時，首先要從Marathon API中尋找調度器的主機地址和端口，然后調用調度器查找Kafka Broker。Mesos DNS也可以用來給Broker分配靜態DNS名稱。一旦用戶連接上了Broker，非常棒！

接下來會發生的

Kafka Mesos框架和DCOS的未來是光明的，我們獲得了很多關于接下來如何以及繼續發展的反饋和想法。這兒有一些目前正在討論的如何改進集成的特性，不過沒有按照一定的順序羅列，其中的大部分特性我們正在將其添加到Apache Kafka項目中：

○繼續支持新的Kafka和Mesos特性，修正bug

○將Kafka命令（比如kafka-topic等）集成到框架調度器中，這樣可以通過CLI或者Restful API來使用

○支持集群的自動伸縮（包括自動重新分配Kafka分區），這樣可以在已知的流量低谷期之外充分利用Broker的資源（CPU、內存等等）。

○機架感知分區，改善容錯能力

○提供鉤子程序這樣消息生產者和消費者也可以從調度器啟動，并通過集群管理

○按照負載和流量自動重新分區

在接下來的時間里，很多公司都期待著為它們增長的數據做更多的工作。單一整體集中部署數據庫的時代一去不復返了，現在很多公司正在擴展新的專業分布式系統來處理數據，但是它們需要減少部署和管理硬件資源的復雜度，從而避免淪為IT基礎設施的奴隸的風險。不僅Kafka會成為公司數據管道設施的核心，使得數據可以流向多種多樣的系統，而且像Mesos這樣的集群管理系統也會日益重要，因為像Kafka這樣的大數據技術將會繼續迅猛發展。

原文鏈接： Making Apache Kafka Elastic With Apache Mesos （翻譯：胡震）