這篇文章入選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

DCOS實踐分享(4)：如何基於DC/OS整合SMACK(Spark, Mesos, Akka, Cassandra, Kafka)