本文讲的是<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框架