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

Posted 2020-09-22 沧海一滴

这篇文章入选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