摘要：極大地降低了平臺的復雜度，更加方便企業開發人員實現各種業務應用，幫助企業輕松打造基于云計算的軟件基礎設施。本文將從實際案例出發，結合不同的使用場景，為各位介紹的這些特性。是未來數據中心操作系統的核心。

隨著 Docker 技術的日漸火熱，本就火爆的云計算行業進入了一個加速階段。云計算最大的特點是彈性和靈活，幫助企業應對復雜的業務需求。由于云計算的IT構架和上一代的IT構架有很大不同，云原生應用（Cloud Native Application）概念應運而生。

云原生應用的優點體現在具有良好的可擴展性、伸縮性和容錯性；不過想要享用云原生應用的種種良好特性并不是輕松的事，企業開發人員在開發業務應用的時候，還要考慮未來應用的可擴展性和容錯性，不免增加了開發的復雜度。PaaS 的出現，正是要幫助開發人員降低云原生應用的開發復雜度，讓開發人員還是專注于業務應用的開發，為開發人員屏蔽底層細節。

早器的 PaaS 平臺過于復雜和笨重，沒有得到廣泛的應用，而基于 Docker 和 Mesos 打造的 DCOS 是下一代輕量級 PaaS 平臺的典型代表。DCOS 極大地降低了 PaaS 平臺的復雜度，更加方便企業開發人員實現各種業務應用，幫助企業輕松打造基于云計算的軟件基礎設施。

DCOS 主要帶來以下幾方面好處：

橫向擴展，自動恢復

快速部署，高效迭代

混合部署，提高資源利用率

如果對 PaaS、DCOS 不太了解的人一一解釋這些概念，不免有些晦澀。本文將從實際案例出發，結合不同的使用場景，為各位介紹 DCOS 的這些特性。

登陸爬蟲

通過本案例說明，如何在DCOS上從頭開始設計一個微服務架構的應用，在獲得彈性擴展、高可用的特性下，如何進行服務發現

在線會議系統

通過本案例說明，如何改造原有的互聯網應用上云，以及借助容器的快速部署特性，架構持續集成

文章分類與熱詞統計

通過本案例說明，如何在DCOS上實現大數據應用，以及借助 Mesos 實現混合部署，提高資源利用率

Mesos：Mesos是一個分布式資源管理器，支持在多種計算集群框架（frameworks）間共享服務器集群資源，提高了集群資源占用率的同事，避免了每種框架的資源沖突。為了滿足復雜的資源調度方法，Mesos 通過資源提供（resource offer）實現了基于 DRF 算法的二層資源調度機制。Mesos是未來數據中心操作系統（DCOS）的核心。

Marathon：Marathon 是一個 Mesos 的框架，能夠支持在集群環境中管理長運行服務，可以理解是分布式的 Init.d，它能夠運行任何 Linux 二進制發布版本如 Nginx 等，并可以對應用的分布式多進程進行管理。

Chronos：Chronos 是一個具備容錯特性的作業調度器， 也是一個 Mesos 的框架，支持使用 Mesos Slave 作為作業執行器，用于在分布式環境下替代 cron。

服務發現：服務發現是指，任何一個應用的實例能夠以編程的方式獲取當前環境的細節，而新的實例可以嵌入到現有的應用環境而不需要人工干預。簡單地說，在一個集群環境下，隨著應用實例的增減或遷移，服務發現保證該服務仍然可以通過服務訪問地址被訪問。

持續集成：持續集成（Continuous Integration）是一種實踐，可以讓團隊在持續的基礎上收到反饋并進行改進，不必等到開發周期后期才尋找和修復缺陷。通俗一點兒說，就是對于開發人員的代碼提交，都自動地把代碼庫中的代碼進行編譯、測試、打包。

微服務：微服務是一種新興的應用軟件架構，它通過一組服務的方式來構建一個應用，服務獨立部署在不同的進程中，不同服務通過一些輕量級交互機制來通信，例如 REST。每個服務可獨立擴展伸縮，并且定義了明確的邊界，不同的服務甚至可以采用不同的編程語言來實現，由獨立的團隊來維護。

數人云：數人云是國內第一款數據中心操作系統，基于Mesos管理容器生產環境，并集成了 Marathon、Chronos 等組件，對企業數據中心提供集群管理，容器管理，服務發現，持續集成等服務。

該系統是一套實時的登陸爬蟲系統，用戶輸入待爬取網站的用戶名和密碼，系統會自動登陸賬號，并爬取賬號內頁面數據，以報告的形式提供給用戶。這套系統常用于金融征信，評級機構獲得用戶的登錄信息，通過爬蟲系統爬取該用戶的信用相關信息，形成信用報告。

先了解一下微幅架構的幾個主要的設計理念：

通過服務實現組件化。微服務使用服務的形式來實現各個功能組件模塊，各個模塊間的依賴通過服務的方式來組織，即一個模塊通過遠程過程調用來依賴另一個模塊，每個模塊是一個微服務。

企業按照業務功能來組織團隊，每個團隊負責一個微服務，可以做到“誰構建，誰運行”，這將極大降低運維復雜度，縮短上線周期。

微服務可以方便地做到離散化數據管理。每個微服務可以自行管理各自的數據，包括不同業務的數據、不同微服務的配置等等，更加切實匹配業務需求。

微服務構架使得持續集成和持續交付變得更加便捷。有了微服務，集成和交付的單元從大而全的整體應用變成了各個微服務，每個微服務都可以靈活地集成和交付。

這個系統在設計之初就考慮采用微服務架構，以便部署在 DCOS 環境，并享受 DCOS 所帶來的各種特性。

該系統希望依照微服務架構原則進行設計，將功能模塊組件化，每個模塊實現一個獨立的功能，可多帶帶部署，模塊之間松散耦合。每個模塊可根據業務負載靈活地增加或縮減可承載容量，同時每個模塊由多個實例構成，避免整個系統由于單點故障而造成系統癱瘓。

系統的業務需求大致如下圖所示。

在得到授權的情況下，用戶輸入所要爬取的網站的登陸用戶名和密碼，提交爬取任務；

模擬用戶行為登陸，登陸過程中要判斷用戶名、密碼的正確性，如果有驗證碼，需要讓用戶判斷驗證碼圖片并輸入驗證碼信息；

成功登陸后，即開始爬取賬戶頁面，根據報告要求，從頁面中抽取出有效信息，形成報告；

由于數據是多實例并行爬取的，需要在爬取結束后進行數據整合；

異步獲取結果；用戶登陸成功后，會提供一個查詢碼，并提示一段時間后進行查詢；待爬取結束并形成后，用戶方可查詢到數據報告；

根據這些需求，需要以下系統組成：

一個 web ui，與用戶交互；

模擬登陸模塊Loginer；

爬取模塊 Fetcher；

信息抽取模塊 Extractor；

信息整合模塊 Combiner；

ETL 模塊：用于清洗數據，形成最終報告；

系統設計如下圖所示。

用戶通過 Access portal 輸入待爬網站的用戶名和密碼，有些網站還需要輸入驗證碼；

Loginer 接收到用戶信息后，開始模擬用戶登陸；模擬登陸可以采用 Selenium 或 Http Client 兩種，需要渲染頁面時使用 Selenium，否則用 Http Client 就夠了；

登陸成功后，Logginer 會將 cookie 和爬取任務一同寫入消息隊列，Fetecher 負責領取任務，進行頁面爬取； 爬取過程中，Fetcher 需要攜帶 Cookie 訪問網站頁面；

Fetcher 將爬取的頁面存入消息隊列，由 Executor 負責從頁面中抽取需要的元素信息，并將這些信息放入緩存系統；

Combiner 負責將緩存中的數據進行拼裝，并判斷爬取是否結束；若結束，將爬取結果存入數據庫；

ETL 模塊負責將爬取結果進行清洗和整理，形成最終的報告；

用戶在等待一段時間后，可以查詢爬取結果，下載報告。

其中，Fetcher、Extractor、Combiner 三個組件都需要了解本次抓取需要有多少 task，以及每個 task 的狀態，以便判斷本次任務是否結束。

由于整個系統的每一個處理環節都是多實例的，模塊之間都不直接發生依賴關系，而是采用消息隊列或者存儲系統進行解耦。

注：為了防止被某些網站限制 IP，還需要在 Loginer 前面增加一個代理層，每次使用隨機的代理服務器進行網站訪問和登陸，這樣就避免了被封的風險。

從上面的設計中可以看出，大部分服務之間都通過分布式消息隊列或存儲系統進行交互，這樣做的好處使得服務之間實現了異步交互，降低了耦合性。但這種異步方式并不適應于任何場合，例如 Loginer 的設計就必須采用同步調用的方式，主要原因是：

用戶在輸入用戶名、密碼后，需要 Loginer 立刻進行模擬登陸以驗證輸入的正確性；

如果網站登陸頁的驗證碼是在用戶名、密碼輸入后才顯示，則還需要將驗證碼圖片返回給用戶，由用戶判別并輸入驗證碼信息（有的驗證碼可通過打碼服務直接獲取驗證碼信息，但并這并不適用于所有驗證碼系統）后，再進行登陸操作；

Loginer 采用 Selenium 或 Http Client 進行模擬登陸，當網站登錄頁需要進行 JS 渲染的時候，就需要用到 Selenium；Selenium 通過瀏覽器 driver 打開瀏覽器，訪問登錄頁，開始進行模擬操作；為了簡化瀏覽器狀態的維護，在設計時限定每個 Loginer 實例同時只能處理一個登錄請求，直到本次登錄完全結束，關閉瀏覽器，才可以處理下一個登錄請求?？梢姡總€ Loginer 需要維持一個狀態機。

正因如此，Loginer 需要部署較多的實例數；另外，由于瀏覽器 driver 不夠穩定，時而出現調用無效的情況，Loginer 需要有重啟機制；

數人云提供了一套完善的面向微服務架構的服務發現方案，如下圖所示。

現有服務發現根據 marathon+zookeeper+bamboo＋haproxy 一起工作解決，具體說明如下：

應用動態變化導致 marathon 將狀態信息寫入 zookeeper（包括所在的主機 IP、端口等），然后把變化事件發給事件訂閱用戶， bamboo 作為訂閱用戶， marathon-leader 會將變化事件發送給 bamboo。

bamboo 拿到事件后，按照事件給定的應用標示去 zookeeper 中取對應的狀態數據。

bamboo 拿到數據后按照預先設定的 haproxy 模版生成一個臨時配置文件。

bamboo 將臨時配置文件和現有 haproxy 配置文件進行對比。

bamboo 對比后，如果一致將直接結束任務。如果不一致，檢查一下配置文件格式。

bamboo 如果配置文件格式異常，將結束任務。如果正常，將 reload haporxy 加載新配置文件。

將 Loginer 通過數人云發布，發布應用時指定應用地址，即在 haproxy 上配置一個訪問端口，再有服務發現機制將請求轉發到具體的應用實例，具體請見數人云用戶手冊。

如果某個 Loginer 實例在處理登陸任務時出現異常，只需要結束進程，該 Docker 容器會自動 stop；Marathon 監聽到有應用容器停止，會重新啟動一個新容器以保證服務容量。注意，新容器不一定運行在結束運行的舊容器所在的主機，可以是指定集群范圍內的任何主機，而服務發現會幫助我們自動發現該容器并進行請求轉發。

當然，在橫向擴展時，增加 Loginer 的實例數，不僅可以做到快速地平滑擴展（業務不停），也會將新實例通過服務發現加入到轉發列表中。

數人云還在 Haproxy 設置了會話保持，如果是基于 cookie 的會話，Haproxy 會將同一會話請求轉發到同一容器。

至此，一套具備橫向擴展能力，高可用的登陸爬蟲系統就設計完了。

回頭來看，整個系統就是一個數據處理的 pipeline，每個環節之間松散耦合，具備高可用，可以獨自做到橫向擴容或縮減，基本符合了微服務架構的特性。這樣的架構也為持續集成創造了良好的基礎，我們會在下一個案例介紹基于DCOS的持續集成。

注：數人云新版的服務發現功能已經修改了策略，不再需要用戶選擇將代理部在某幾臺主機上，而是由系統默認安裝在集群除了 Master 之外的所有主機上，構成一個覆蓋全計算資源的代理集群，確保服務發現的高可用；同時對 proxy 進行了優化，降低了運行帶來的系統開銷。

這是一個在線會議工具，用戶可以通過微信登陸并接入系統，邀請好友開始遠程會議。該應用架構復雜度中等，為典型的互聯網應用。

該應用的技術架構如下圖所示。

如圖所示，其架構圖中包括 Redis，Mysql，OSS，file-server 等存儲節點，也包括 web-server，api-server，push server 等服務節點，還有前端的 nginx 反向代理等。

服務節點間存在相互依賴。

所有節點都部署在阿里云，部分存儲服務使用了阿里云服務。

部署耗時：由于我們的服務較多，版本發布的時候，需要每個服務都多帶帶編譯、打包、部署，一般要1到2個小時才能完成部署任務；遷移麻煩：如果需要部署新的機器，每個新機器還需要配置環境，很麻煩；擴展性差：現在的服務依賴都是單向直接依賴，沒有做負載均衡，不能擴展。

經過對其業務流進行梳理，我們大致得到以下架構。

架構圖中包括以下內容：

每個服務的端口使用；

服務間依賴關系；

服務是否有狀態；

分別標注對外服務、對內服務及存儲；

對應用大致做了以下改造：

服務節點 Docker 化；

服務節點無狀態化，具備橫向擴展能力；

抽離配置文件，解耦組件間依賴；

多實例化的服務之間進行服務發現。

上云步驟：

為每一個子項目編寫 Dockerfile

安裝私有 Docker Registry

部署應用

監控與測試

持續集成是一種軟件開發實踐，即團隊開發成員經常集成它們的工作，通過每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而盡早地發現集成錯誤。而Jenkins是一個自動構建服務，使用Java實現，有成百上千插件，使用他可以很方便實現持續集成。

搭建 Jenkins

對于 Jenkins 的安裝和部署，這里不再累述。

值得一提的是，數人云集群使用 Apache Mesos 進行資源的統一調度，通過數人云可以快速搭建 Jenkins。把Jenkins運行到 Mesos 上，或者說利用 Mesos 向 Jenkins 提供 slave 資源，一方面通過分布式特性加快構建過程，另一方面也提高了資源利用率。通過配置 Jenkins-on-Mesos 插件，Jenkins Master 可以在作業構建時根據實際需要動態的向 Mesos 申請 slave 節點，并在構建完成的一段時間后將節點歸還給 Mesos。

具體教程請見 快速搭建 Jenkins 持續集成環境加速產品迭代。

代碼庫創建工程

需要內部的代碼庫或者公共代碼庫為每一個組件創建一個項目。本案使用了 Github 作為代碼庫，Jenkins 已原生支持 Github。這里要注意的是，需要保證 Jenkins 有權限 pull/push 上面我們所創建的 git repo。另外，工程要包含 Dockerfile，以便在構建過程中生成 Docker 鏡像。

鏡像構建任務

在 Jenkins 里創建構建任務, 任務從 git repo 拉取代碼，指定 release 的 tag，使用 repo 里的Dockerfile，構建 Docker 鏡像，并推送鏡像到 Registry 里。

根據不同的系統架構，可以將構建任務拆成不同的粒度。最簡單的，一個任務構建所有的子項目。如果項目比較復雜的情況下，每次構建時間會比較長，造成不必要的資源浪費，那么可以將構建任務拆分到顆粒度更小的子項目。

構建觸發設置，可以為每次 push 后進行構建。但一般情況下，每個子項目也是有多人協作的，而且并不是每一次代碼提交都需要進行構建，因此構建觸發策略設為 Tag push 觸發，及每當增加 tag 時，觸發構建任務。

鏡像發布任務

在 Jenkins 里新建任務, 在這個任務里，通過調用數人云 Rest API 獲取認證token, 發布應用到 Mesos 集群。

可以設置發布任務的自動觸發，比如當一個構建任務完成后觸發，或者每天晚上2點觸發，要根據不同的環境需要來進行選擇。

發布腳本中，通過調用數人云 Rest API 獲取認證 token, 以應用的形式發布到數人云平臺。這里用curl命令發布應用。也可以用 python、shell 等腳本調用 API 發布應用，我們也推薦這樣做，可以更好的檢查調用API的返回。

以上，實現了整套系統上云以及構建持續集成的過程。下一步便是構建從開發、集成到生產的完整運維體系。一般情況下，針對一個互聯網產品，開發環境由開發進行構建和發布，可以設置為 push 觸發或者前面提到的 tag push 觸發；集成環境由 QA 進行構建和發布，QA 定期發布并進行集成測試，發現問題后再回退到之前版本；生產環境往往通過手動方式觸發發布，在發布前需要做好客戶通知、應急處理等各項準備。

值得注意的是，將多份環境進行統一發布管理，還需要配備配置服務器用于管理不同環境的配置信息，而這是另一個話題了。

重要提示：數人云新版已發布了持續集成服務，上述通過 Jenkins 部署和配置持續集成過程仍顯得比較繁重，那么通過數人云管理界面，通過簡單的操作就可以實現自動構建的全過程，具體請參見數人云用戶手冊。

這是DCOS上的大數據項目。項目來源自一個互聯網媒體客戶，需求是將積累的媒體文章進行分類，并找出能代表一篇文章的關鍵詞作為文章標簽，用于進行文章的分類或熱詞統計等數據分析，文章數量近5萬余篇，且在不斷增加。

項目選用 Apache Spark 作為計算框架，并通過 Spark MLlib 提供的 LDA 算法對文章進行聚類，得到“文章-主題”和“主題-關鍵詞”矩陣，并以主題詞作為文章標簽，對文章進行歸類。

Apache Spark 作為一個分布式大數據計算框架，與 Apache Mesos 完美結合。Mesos 作為 Spark 集群的資源調度器，可以將 Mesos 集群的資源以粗、細兩種粒度分配給 Spark；在 Spark 完成計算任務后，Mesos 可以將資源回收，供其他服務使用。

從上圖看出，項目一共包括數據預處理、模型訓練、預測訓練集三個離線計算任務，和一個提供預測、添加文章、熱詞查詢等功能的服務模塊。

Spark 計算任務需要大量計算資源，主要工作時間在凌晨時間，這些資源在白天是閑置的。該系統還需要 Nginx、MySQL 等服務組件，如果能將它們混補在同一組服務器上，則可以降低成本，提高資源利用率。

本案通過數人云管理 Mesos 集群，通過 Marathon 管理長運行的服務型應用，通過 Chronos 管理離線計算任務，同時在集群中部署了 HDFS 分布式文件系統以及私有 Docker Registry。

其中，MySQL 用于存放每天的新文章數據，以及預測后的結果數據集；Nginx 用于對外提供服務。每天晚上2點運行 Spark 計算任務，更新模型并對訓練集數據重新預測。

Spark 采用 Mesos 作為資源調度器時，由 Mesos 統一調度計算資源，因此，Spark 集群無需部署，Mesos 集群即為 Spark 集群。

制作 Spark base 鏡像，這部分不再累述，請參見使用數人云運行 Spark，或者也可以使用數人云開放的 Spark base 鏡像：index.shurenyun.com/spark:1.5.0-hadoop2.6.0。

本案存儲層選用了 HDFS。Spark 連接 HDFS 時擁有數據位置識別能力，并會從集群內距離最近的節點處讀取數據，從而最大程度降低數據在網絡中的傳輸需求。為了充分發揮 Spark 的數據位置識別能力，大家應當讓 Spark 計算任務與 HDFS 節點共同部署在一個集群中。

數人云提供為主機打標簽的服務。如果 HDFS 只部署在集群的部分主機上，可以為這部分主機打上標簽，在部署 Spark 計算任務的時候，可以限定在該標簽范圍內執行。具體請參見數人云用戶手冊。

將 Spark 計算任務通過 Chronos 發布到集群中，Chronos 是一個具備容錯特性的作業調度器，支持使用 Mesos 作為作業執行器，用來在分布式環境下替代 cron。

制作任務鏡像

因為代碼和配置文件變動相對頻繁，因此基于 Spark base 鏡像制作一個包含二進制包和配置文件的任務鏡像。

Spark 項目的目錄如下：

├── README.md
├── build.sbt
├── conf
├── project
├── src
└── target

其中，conf 中包含了 Spark 的配置文件：spark-env.sh，spark-defaults.conf。

任務鏡像的 Dockerfile 如下：

FROM index.shurenyun.com/spark:1.5.0-hadoop2.6.0

ADD target/scala-2.10/spark_lda.jar .
ADD conf .

CMD ./run.sh

Spark 程序通過 SBT 編譯，二進制包生成在 target/scala-2.10/spark_lda.jar。

根據調試或部署的需要，將 Spark 的配置目錄導入并替換原文件，便于配置更新。

運行腳本run.sh是具體的 spark-submit 指令：

bin/spark-submit --class com.dataman.omega.service.Boot /opt/dist/spark/spark_lda.jar

將三個離線計算任務分別制作成鏡像，然后將制作好的鏡像上傳到到鏡像倉庫。

發布任務

Chronos 是一個具備容錯特性的作業調度器，支持使用 Mesos 作為作業執行器，用來在分布式環境下替代 cron。數人云已經集成 Chronos，并對外開放了發布定時任務的 REST API。為三個離線計算任務分別創建 Chronos 任務，名為preprocessJob,trainJob,predictJob。一個具體的定時任務發布指令如下：

curl -X POST https://api.shurenyun.com/api/v3/clusters/88/jobs 
      -H Content-Type: application/json 
      -H Accept: application/json 
      -H Authorization: 6d8c5051f09242408f966f762cc9b674 -d "{
        "name": "preprocessJob",
        "imageURI": "index.shurenyun.com/Spark_preprocess",
        "imageversion": "v1",
        "cpu": 4,
        "mem": 8192,
        "owner": "yma@dataman-inc.com",
        "ownerName": "yma",
        "schedule": "R/2016-03-15T02:00:00.000Z/P1D",
        "command": "",
        "parents": [
          ""
        ],
        "volumes": [
        ],
        "constraints":[["Tags", "LIKE", "HDFS"]]
      }"
 

有幾個注意的地方：

schedule：R/2016-03-15T02:00:00.000Z表示任務定為晚上2點開始執行，P1D表示每隔一天執行一次；

parents：該任務執行的先決條件，不能和 schedule 字段同時使用；由于 preprocessJob 是第一個執行任務，因此設置 了 schedule，后面的任務比如 trainJob，則要設置 parents 為preprocessJob；

command：原生 Chronos API 不允許該字段為空，數人云已經修補了該 bug。

具體的 API 說明請參見數人云 API 文檔。

Nginx，MySQL 這類長運行服務，通過 Marathon 發布。數人云已集成 Marathon，并提供了簡潔的 UI，具體方法請參見數人云手冊。

由于服務訪問大部分發生在白天，而 Spark 計算只在晚上進行，因此完全可以把以上任務和服務都混合部署在同一集群內，提高了整體資源利用率。

Mesos 具有處理各種異構任務負載的特性，因而使得在同一個平臺上管理大數據應用和 Web 應用成為可能。數人云集成了平臺監控工具，可以方便地監控集群、主機、應用三個層面的資源使用情況以及各種應用狀態，簡化了運維工作。

注：HDFS 也可以通過 Mesos 部署，如果有的小伙伴覺得部署原生 HDFS 很麻煩的話，可以參考將 HDFS 搬上數人云：輕松實現集群的擴展收縮。

本文針對不用的應用場景，提供了基于數人云 DCOS 的應用上云方案，并分別說明了 DCOS 的特性；其實，只要處理得當，每一個場景都是可以受用 DCOS 的多種特性的。

由于應用的多樣性和復雜性，應用上云并不止以上內容，更多內容請咨詢數人云。