DCOS实践分享(4)：如何基于DC/OS整合SMACK(Spark, Mesos, Akka, Cassandra, Kafka)

这篇文章入选CSDN极客头条

http://geek.csdn.net/news/detail/71572

当前，要保证业务的市场竞争力，仅靠设计一个可用并且好看的产品，已经完全不能满足要求。全球消费者都希望产品能够足够的智能化，通过大数据分析来改善他们的用户体验。简言之，物联网和大数据终将成为改变生活的技术驱动力。

近几年涌现了大量的技术架构与设计模式，开发者和科学家可以利用它们为大数据和物联网开发实时的数据分析工作流应用。其中批处理架构，流式处理架构，lambda架构，Kappa架构，都是其中的代表。所有这些架构，都需要一个易扩展的大数据处理平台作为基础。于是2014年底，一组可相互兼容，互相协作的开源组件被整合起来作为这个基础平台。SMACK应运而生。

SMACK包括Spark, Mesos, Akka, Cassandra, 以及Kafka，功能如下：

  • 包含广泛应用于大数据数据处理场景的轻量级工具包
  • 包含被健壮测试并广泛应用的开源软件，有强大的社区支持
  • 可保证低延时下的可伸缩性和数据备份。
  • 统一的集群管理平台来管理多样的，不同负载的应用。

在部署具体的应用的时候，大数据平台往往要和普通应用一起配合使用，近年来，普通应用微服务化，容器技术如火如荼，我们需要一个平台技能管理容器，也能管理大数据平台。

能够管理容器的框架很多，有Docker阵营的，Kubernetes阵营的，各有优劣。能够管理大数据的平台也很多，从Hadoop到Spark。但是部署的时候，往往需要各个集群分开运维，容器应用一个集群，Hadoop一个集群，Spark一个集群，增加了运维的难度和硬件的开销。DC/OS解决了这个问题，它可以将容器，普通应用，大数据应用在同一个框架管理起来，共享资源，简化运维。

本文将带大家来领略如何基于DC/OS的SMACK运行一个应用，以及SMACK中的各个组件如何整合。

总体架构

下图是一个基于SMACK的经典应用的总体架构。此应用会接入大量的数据，并对数据做分析。具体说来，此应用从用户家里的智能仪表收集能源使用数据，这些数据会被大数据分析，从而生成一个地区的能源消耗分布图。可以被相关部门用于预估另一个地区的能源消耗。

如图所示，智能仪表的数据会通过互联网调用计量服务的HTTP接口，发送到数据中心。计量服务将消息通过Kafka发送到模拟器服务。模拟器服务奖数据存储在Cassandra里面。

Spark从Cassandra里面读取数据进行分析，将分析的结果存入Cassandra。

模拟器服务可以将Cassandra中的分析结果读出。

当用户从手机和电脑上打开网页的时候，网页访问计量服务的HTTP接口，计量服务从模拟器服务读取分析结果，展示给用户。

详细设计

前提条件

  • 安装一个DC/OS集群
  • 部署一个DC/OS命令行工具

DC/OS服务

接下来，我们要保证所有必需的DC/OS的服务都处于正常状态。下面列表中的某些服务是DC/OS的核心组件，我们把他们列在这里，是因为我们的应用十分依赖于这些组件。

Marathon

Marathon是DC/OS的核心组件，DC/OS安装好后就自带Marathon。在使用他之前，我们最好查看一下他的状态。

dcos marathon about | jq ".elected == true"

Marathon LB - external (用于外部访问的Marathon负载均衡器)

默认的Marathon负载均衡器框架会创建一个用于外部访问的负载均衡器实例。

如需详细了解DC/OS如何使用Marathon负载均衡器框架，可访问此链接。

快速安装：

dcos package install marathon-lb

Marathon负载均衡器是基于haproxy的，可用过下面的URL访问http://p1.dcos:9090/haproxy?stats。Mesos DNS作为DC/OS内部的DNS会记录Marathon负载均衡器的域名为marathon-lb.marathon.mesos。Mesos DNS也是DC/OS的核心组件。Marathon负载均衡器会被安装在任一DC/OS的公网节点上，例如p1是一个公网节点的域名，可以通过http://p1.dcos访问Marathon负载均衡器。

Marathon LB - internal (用于内部访问的Marathon负载均衡器)

需要创建另一个Marathon的负载均衡器，用于内部组件的相互访问，而不需要内部组件之间的网络流量也经过公网。

快速安装：

cat < marathon-internal-lb-options.json
{ "marathon-lb":{ "name":"marathon-lb-internal", "haproxy-group":"internal", "bind-http-https":false, "role":"" } }
EOF
dcos package install --options=marathon-internal-lb-options.json marathon-lb

内部的Marathon负载均衡器在Mesos DNS中的域名为marathon-lb-internal.marathon.mesos。

Kafka

Kafka已经在DC/OS的服务库中，所以我们可以直接拿过来用，而不需要自己管理和维护一个Kafka集群

快速安装：

dcos package install --yes kafka

只需要运行下面的命令就可以验证服务的状态。

dcos package list kafka; dcos kafka help

Kafka服务作为Marathon的一个Job运行，从而可以实现长期运行，高可用，弹性伸缩。安装Kafka需要几分钟的时间，可以通过Marathon查看进度。

Kafka默认有三个Broker实例。你可以定制化Kafka服务，根据所需要处理的负载情况，创建更多的Broker。Kafka中的Topic的创建以及消息的消费都是由应用层进行处理。

Cassandra

作为大数据基础架构，把Cassandra运行在DC/OS上也是必须的。Cassandra已经放在了DC/OS的服务库中了。

快速安装：

$ dcos package install cassandra
Installing Marathon app for package [cassandra] version [1.0.0-2.2.5]
Installing CLI subcommand for package [cassandra] version [1.0.0-2.2.5]
New command available: dcos cassandra
DC/OS Cassandra Service is being installed.

安装Cassandra需要几分钟的时间。默认情况下，Cassandra会安装3个节点，其中2个是种子节点。

ssh到Cassandra集群

Cassandra集群已经运行起来了，下面需要连接到这个集群。让我们通过下面的命令先得到连接信息。

$ dcos cassandra connection
{
    "nodes": [
        "192.168.65.111:9042",
        "192.168.65.121:9042",
        "192.168.65.131:9042"
    ]
}

因为IP都是私有IP，因此我们首先要ssh到DC/OS集群中，然后才能练到Cassandra集群。

$ dcos node ssh --master-proxy --leader

现在我们进入到了DC/OS集群内部，可以直接连接Cassandra集群了。我们使用cqlsh客户端，选取一个Cassandra的节点进行连接。运行下面的命令。

$ docker run -ti cassandra:2.2.5 cqlsh 10.0.2.136
cqlsh>

创建keyspace

我们已经连接到了Cassandra集群，创建一个名为iot_demo的keyspace.

cqlsh> CREATE KEYSPACE iot_demo WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };

创建好了keyspace，我们可以添加一些表及模拟数据到keyspace里面，从而我们的应用可以使用Cassandra.

服务发现

基于DC/OS命令行的服务发现

我们可以使用DC/OS的工具进行服务发现。在Docker的Entrypoint里面，可以嵌入脚本，通过DC/OS的命令行发现服务，并export在环境变量里面。

Akka的服务发现

为了发现Akka节点，在Docker的entrypoint脚本docker-entrypoint.sh中，嵌入下面的命令：

export AKKA_SEED_NODES=`dcos marathon app show  | jq -r ".tasks[].host" | tr '\n' ','  | sed 's/,$//g'`

应用的配置可以使用这个环境变量。如果自己是Akka集群的第一个节点，则创建一个Akka集群，如果已经存在一个Akka集群，则可以发现并加入这个集群。

我们考虑了下面这个特殊的场景：

当前容器中的Akka节点是第一个节点，在这种特殊情况下，服务发现这一步的结果是发现了自己，此结果是正确的，做默认处理即可。

Kafka的服务发现

类似，我们同样可以在Docker的entrypoint里面嵌入下面的脚本发现Kafka的所有的broker。

export KAFKA_BROKERS_LIST=`dcos kafka connection --dns | jq -r ".names[]" | tr '\n' ','  | sed 's/,$//g'`

基于Marathon负载均衡器的服务发现

可以使用内部的和外部的Marathon负载均衡器作为服务发现的另一种方式。

应用层的部署

我们已经部署完了DC/OS的服务，并且配置了服务发现。接下来，我们来部署应用，使用这些DC/OS服务。

我们将使用Marathon部署应用层，从而达到应用的长时间运行。应用的组件会作为Marathon的任务运行在Docker里面。组件之间的相互配置和依赖关系，都可以通过Marathon来实现。

应用层保护两个微服务，计量服务和模拟器服务，另外还有一个简单的网页做展示。

计量服务

计量服务构成一个Akka集群，暴露REST接口被模拟器服务和网页访问。

计量服务定义为下面的json，发送给Marathon进行部署

{
  "id": "meter",
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "cakesolutions/iot-demo-meter"
    }
  },
  "labels":{
    "HAPROXY_GROUP":"external,internal"
  }
…
}

Marathon的任务定义包含一个特殊的标签HAPROXY_GROUP，通过这个标签，Marathon负载均衡器知道是否暴露这个应用。”external”是默认的用于外部访问的Marathon负载均衡器，说明外部可以访问这个服务。

“internal”是用于内部访问的Marathon负载均衡器，说明此服务可以通过下面的DNS，被内部的其他组件访问：marathon-lb-internal.marathon.mesos:1900。模拟器服务就可以使用这个DNS访问计量服务的REST API。

用于外部访问的Marathon负载均衡器需要保证内部的DNS marathon-lb.marathon.mesos:19002可以在外网上被解析为p1.dcos:19002。

网页就需要使用这个外网可访问的域名，因为网页是运行在浏览器里面的，在数据中心外，无法使用内部DNS.

接下来，我们调用下面的命令部署计量服务。

dcos marathon app add meter.json
The Marathon jobs can be redeployed by using either Marathon API, either DC/OS CLI. Traditionally now we’ve been using the Marathon API, directly or with the Python driver.

模拟器服务

模拟器服务的Marathon的json如下：

{
  "id": "simulator",
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "cakesolutions/iot-demo-simulator"
    }
  },
  "env": {
    "METER_HOST": "marathon-lb-internal.marathon.mesos",
    "METER_PORT": "19002"
  },
  "labels":{
    "HAPROXY_GROUP":"external"
  }
}

类似，我们通过下面的命令将模拟器服务作为Marathon的任务运行，从而实现长时间运行。

dcos marathon app add simulator.json

模拟器服务需要知道计量服务的API，所以我们将计量服务的DNS作为环境变量传给了模拟器服务。

用于外部访问的Marathon负载均衡器需要保证内部的DNS marathon-lb.marathon.mesos:19001可以在外网上被解析为p1.dcos:19001。从而可以被网页访问。

网页客户端

网页也使用Marathon的json如下：

{
  "id": "web",
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "cakesolutions/iot-demo-web",
    }
  },
  "env": {
    "METER_HOST": "p1.dcos",
    "METER_PORT": "19002",
    "METER_HOST": "p1.dcos",
    "METER_PORT": "19001"
  },
  "labels":{
    "HAPROXY_GROUP":"external"
  }
}

将网页运行为Marathon的任务。

dcos marathon app add web.json

网页需要能够在浏览器中访问计量服务和模拟器服务，因而两个服务的DNS都作为环境变量传给了网页的Docker.

P1.dcos是DC/OS公网节点的DNS域名，Marathon的负载均衡器会运行在这个公网节点上。


METER_HOST=p1.dcos
METER_PORT=19002
SIMULATOR_HOST=p1.dcos
SIMULATOR_PORT=19001

总结

到此，我们看到了SMACK中的框架如何运行在DC/OS上，例如Kafka, Cassandra这些复杂的组件如何被方便的安装和配置，如何基于这些框架构建自己的服务。

因而我们可以得出结论，DC/OS的确是：

  • 在生产环境部署容器应用的最方便的方式
  • 充分高效率利用我们的基础架构的最方便的方式
  • 非常方便的将不同的框架安装在同一个集群环境中。
  • 提供了一种非常方便的方式对服务进行弹性伸缩。

总而言之，DC/OS是能够解决您数据中心问题的完整解决方案。诚如大家所知，DC/OS是基于Mesos的，是高可靠的，是被生产环境验证过的。

http://www.cnblogs.com/popsuper1982/p/5585437.html

 

时间： 2024-08-06 03:41:07

DCOS实践分享(4)：如何基于DC/OS整合SMACK(Spark, Mesos, Akka, Cassandra, Kafka)的相关文章

基于MaxCompute的图计算实践分享-常见问题解决及优化指南

免费开通大数据服务:https://www.aliyun.com/product/odps 常见问题FAQ Q:Graph 能支持多少节点的进行计算? A:默认最多1000个节点,通过配置odps.graph.worker.num,可以使用多达3000个节点   Q:Graph 单个节点支持多少内存? A:默认内存范围为[2048, 32768] 单位为M,通过配置odps.graph.worker.memory 设置所需内存,如果单个节点需要设置超过32768M的内存,请找ODPS 管理员修改

DC/OS 1.10：一个面向容器化未来的平台

本文讲的是DC/OS 1.10:一个面向容器化未来的平台[译者的话]本文介绍了Mesosphere平台即将推出的最新版本的特性,创造性地引入了Kubernetes作为容器编排引擎,作为面向容器化的未来的一个平台,值得期待. [烧脑式Kubernetes实战训练营]本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理.Kubernetes DNS与服务发现.基于Kubernetes和Jenkins的持续部署方案 .Kubernetes网络部署实践.监控.日志.Kubernetes

DockOne微信分享（七十八）：中英人寿保险有限公司基于容器技术的实践分享

本文讲的是DockOne微信分享(七十八):中英人寿保险有限公司基于容器技术的实践分享[编者的话] 中英人寿在移动应用开发与运维上引入DevOps,极大的提升了开发效率,进而实现持续交付能力.持续交付让移动应用上线的速度从以月为单位提升到周甚至到天. 通过在企业云上使用(Docker.Git.Jenkins etc)搭建自动化部署流水线, 使软件的构建.测试.部署的过程自动化实现.随着IT架构向云架构的转型,在架构级管理工具上采用虚拟化容器管理,实现从IaaS到PaaS的转变.对移动应用系统进行

DC/OS关键技术与应用场景

本文讲的是DC/OS关键技术与应用场景[编者的话]文章首先对数据中心操作系统内的主要技术,包括Mesos.Yarn.Kubernetes和容器进行了阐述.根据国内外电信运营商的现状和面临的问题,提出了一种解决方案,并对技术实现及选型建议进行了讨论.最后对电信运营商应用DC/OS关键技术的案例进行了简要介绍. 引言 随着越来越多的平台.架构.系统.组件和工具等通过开源社区.小微型初创项目而衍生,不再由IT或互联网巨头独自垄断,这为IT领域各项技术的快速.活跃发展提供了良好的温床,开源技术的迅速发展

微信小程序第一手实践分享

本文讲的是微信小程序第一手实践分享,今天是微信小程序正式上线的第一天,从小程序公布.内测到今天,市面上对于小程序众说纷纭,小程序的到来给我们(微信开发)带来了什么,仅仅是又多了一种推广渠道吗?又或者是真的像外界说的那样它将取代APP?今天就和大家分享我个人对小程序的理解以及开发过程中的一些体会. 一.如何理解小程序 张小龙是基于他对未来服务场景--所见即所得的信息交互过程提出的小程序,他认为微信新形式的服务不应当只是停留在原有公众号订阅.推送的基础上:而应当更类似于APP支持一些扩展开发的能力但

打造云上代码交付链，CodePipeline实践分享

在2017在线技术峰会--首届阿里巴巴研发效能嘉年华上,来自阿里云飞天研发部的工程师莫源分享了<打造云上代码交付链,CodePipeline实践分享>.他在云计算和云平台.持续集成流程.DevOps的基础上,详细分享了Alibaba Cloud CodePipeline优于Jenkins的性能和实践. 以下内容根据直播视频整理而成. 直播视频:https://yq.aliyun.com/edu/lesson/549 PDF下载:https://yq.aliyun.com/attachment/

Mesosphere协同其数据合作伙伴在容器2.0时代和DC/OS上的赌注

本文讲的是Mesosphere协同其数据合作伙伴在容器2.0时代和DC/OS上的赌注[编者的话]本文为Mesosphere在其官方博客中发布的关于容器2.0时代中其数据合作伙伴及DC/OS的介绍. 今天我们宣布,我们已经和产业领导者Confluent以及DataStax公司联合,把他们的产品与商业支持一并整合进DC/OS中.这个重要的里程碑已经进一步说明现在是Container 2.0的时代了. 简而言之,Container 2.0是关于数据库容器,消息系统和其他应用服务-(状态服务)的优势的进

蒋帆：区块链落地实践分享

本文讲的是蒋帆:区块链落地实践分享 分享主题:区块链落地时的问题域和主要实践方法,如"区块风暴工作坊"."区块链的敏捷开发与Devops实践"."内建安全的区块链应用"等关键活动. 讲师介绍:蒋帆,Fabulous J,ThoughtWorks高级咨询师,在北京与厄瓜多尔,从事信息安全与隐私加密协议研发,熟悉密码学.数字货币与网络通讯协议等领域. 分享内容如下:1.ThoughtWorks 在中国区为客户提供的区块链服务 2.Blockchain

分享几个基于Windows Server 2008域的新应用

域控制器(DC)的安全,特别是其物理安全让管理员颇为担心.http://www.aliyun.com/zixun/aggregation/32995.html">在Windows Server 2008中新增了一种特殊的域控制器即只读域控制器(RODC),借助RODC我们可以在无法保证物理安全性的网络节点中部署只读域控制器. 域是微软局域网解决方案的重要组成部分,几乎每一个Windows Server版本的发布都会在域方面有非常大的改进和提升.作为微软最新版本的Windows Server