DCOS應用案例-不一樣場景的應用上雲遷移

時間 2019-12-10

標籤 dcos 應用案例不一樣場景遷移简体版

原文原文鏈接

0.前言

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

雲原生應用的優勢體如今具備良好的可擴展性、伸縮性和容錯性；不過想要享用雲原生應用的種種良好特性並非輕鬆的事，企業開發人員在開發業務應用的時候，還要考慮將來應用的可擴展性和容錯性，難免增長了開發的複雜度。PaaS 的出現，正是要幫助開發人員下降雲原生應用的開發複雜度，讓開發人員仍是專一於業務應用的開發，爲開發人員屏蔽底層細節。前端

早器的 PaaS 平臺過於複雜和笨重，沒有獲得普遍的應用，而基於 Docker 和 Mesos 打造的 DCOS 是下一代輕量級 PaaS 平臺的典型表明。DCOS 極大地下降了 PaaS 平臺的複雜度，更加方便企業開發人員實現各類業務應用，幫助企業輕鬆打造基於雲計算的軟件基礎設施。python

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

橫向擴展，自動恢復git
快速部署，高效迭代web
混合部署，提升資源利用率算法

若是對 PaaS、DCOS 不太瞭解的人一一解釋這些概念，難免有些晦澀。本文將從實際案例出發，結合不一樣的使用場景，爲各位介紹 DCOS 的這些特性。sql

登錄爬蟲shell

經過本案例說明，如何在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 等組件，對企業數據中心提供集羣管理，容器管理，服務發現，持續集成等服務。

1.登錄爬蟲-微服務架構典型

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

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

經過服務實現組件化。微服務使用服務的形式來實現各個功能組件模塊，各個模塊間的依賴經過服務的方式來組織，即一個模塊經過遠程過程調用來依賴另外一個模塊，每一個模塊是一個微服務。
企業按照業務功能來組織團隊，每一個團隊負責一個微服務，能夠作到「誰構建，誰運行」，這將極大下降運維複雜度，縮短上線週期。
微服務能夠方便地作到離散化數據管理。每一個微服務能夠自行管理各自的數據，包括不一樣業務的數據、不一樣微服務的配置等等，更加切實匹配業務需求。
微服務構架使得持續集成和持續交付變得更加便捷。有了微服務，集成和交付的單元從大而全的總體應用變成了各個微服務，每一個微服務均可以靈活地集成和交付。

這個系統在設計之初就考慮採用微服務架構，以便部署在 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 前面增長一個代理層，每次使用隨機的代理服務器進行網站訪問和登錄，這樣就避免了被封的風險。

第二步：服務發現

1 爲何須要服務發現

從上面的設計中能夠看出，大部分服務之間都經過分佈式消息隊列或存儲系統進行交互，這樣作的好處使得服務之間實現了異步交互，下降了耦合性。但這種異步方式並不適應於任何場合，例如 Loginer 的設計就必須採用同步調用的方式，主要緣由是：

用戶在輸入用戶名、密碼後，須要 Loginer 馬上進行模擬登錄以驗證輸入的正確性；
若是網站登錄頁的驗證碼是在用戶名、密碼輸入後才顯示，則還須要將驗證碼圖片返回給用戶，由用戶判別並輸入驗證碼信息（有的驗證碼可經過打碼服務直接獲取驗證碼信息，但並這並不適用於全部驗證碼系統）後，再進行登錄操做；

Loginer 採用 Selenium 或 Http Client 進行模擬登錄，當網站登陸頁須要進行 JS 渲染的時候，就須要用到 Selenium；Selenium 經過瀏覽器 driver 打開瀏覽器，訪問登陸頁，開始進行模擬操做；爲了簡化瀏覽器狀態的維護，在設計時限定每一個 Loginer 實例同時只能處理一個登陸請求，直到本次登陸徹底結束，關閉瀏覽器，才能夠處理下一個登陸請求。可見，每一個 Loginer 須要維持一個狀態機。

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

2 服務發現

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

現有服務發現根據 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 進行了優化，下降了運行帶來的系統開銷。

2.在線會議系統-互聯網持續集成典型

這是一個在線會議工具，用戶能夠經過微信登錄並接入系統，邀請好友開始遠程會議。該應用架構複雜度中等，爲典型的互聯網應用。

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

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

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

全部節點都部署在阿里雲，部分存儲服務使用了阿里雲服務。

系統痛點：

部署耗時：因爲咱們的服務較多，版本發佈的時候，須要每一個服務都單獨編譯、打包、部署，通常要1到2個小時才能完成部署任務；遷移麻煩：若是須要部署新的機器，每一個新機器還須要配置環境，很麻煩；擴展性差：如今的服務依賴都是單向直接依賴，沒有作負載均衡，不能擴展。

第一步：系統 Docker 化 & 上雲

通過對其業務流進行梳理，咱們大體獲得如下架構。

架構圖中包括如下內容：

每一個服務的端口使用；
服務間依賴關係；
服務是否有狀態；
分別標註對外服務、對內服務及存儲；

對應用大體作了如下改造：

服務節點 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 部署和配置持續集成過程仍顯得比較繁重，那麼經過數人云管理界面，經過簡單的操做就能夠實現自動構建的全過程，具體請參見數人云用戶手冊。

3.文章分類與熱詞推薦-混合部署、大數據典型

這是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 計算環境

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 計算任務的時候，能夠限定在該標籤範圍內執行。具體請參見數人云用戶手冊。

第一步：部署 Chronos 任務

將 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 文檔。