摘要：極大地降低了平臺(tái)的復(fù)雜度，更加方便企業(yè)開發(fā)人員實(shí)現(xiàn)各種業(yè)務(wù)應(yīng)用，幫助企業(yè)輕松打造基于云計(jì)算的軟件基礎(chǔ)設(shè)施。本文將從實(shí)際案例出發(fā)，結(jié)合不同的使用場(chǎng)景，為各位介紹的這些特性。是未來數(shù)據(jù)中心操作系統(tǒng)的核心。

隨著 Docker 技術(shù)的日漸火熱，本就火爆的云計(jì)算行業(yè)進(jìn)入了一個(gè)加速階段。云計(jì)算最大的特點(diǎn)是彈性和靈活，幫助企業(yè)應(yīng)對(duì)復(fù)雜的業(yè)務(wù)需求。由于云計(jì)算的IT構(gòu)架和上一代的IT構(gòu)架有很大不同，云原生應(yīng)用（Cloud Native Application）概念應(yīng)運(yùn)而生。

云原生應(yīng)用的優(yōu)點(diǎn)體現(xiàn)在具有良好的可擴(kuò)展性、伸縮性和容錯(cuò)性；不過想要享用云原生應(yīng)用的種種良好特性并不是輕松的事，企業(yè)開發(fā)人員在開發(fā)業(yè)務(wù)應(yīng)用的時(shí)候，還要考慮未來應(yīng)用的可擴(kuò)展性和容錯(cuò)性，不免增加了開發(fā)的復(fù)雜度。PaaS 的出現(xiàn)，正是要幫助開發(fā)人員降低云原生應(yīng)用的開發(fā)復(fù)雜度，讓開發(fā)人員還是專注于業(yè)務(wù)應(yīng)用的開發(fā)，為開發(fā)人員屏蔽底層細(xì)節(jié)。

早器的 PaaS 平臺(tái)過于復(fù)雜和笨重，沒有得到廣泛的應(yīng)用，而基于 Docker 和 Mesos 打造的 DCOS 是下一代輕量級(jí) PaaS 平臺(tái)的典型代表。DCOS 極大地降低了 PaaS 平臺(tái)的復(fù)雜度，更加方便企業(yè)開發(fā)人員實(shí)現(xiàn)各種業(yè)務(wù)應(yīng)用，幫助企業(yè)輕松打造基于云計(jì)算的軟件基礎(chǔ)設(shè)施。

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

橫向擴(kuò)展，自動(dòng)恢復(fù)

快速部署，高效迭代

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

如果對(duì) PaaS、DCOS 不太了解的人一一解釋這些概念，不免有些晦澀。本文將從實(shí)際案例出發(fā)，結(jié)合不同的使用場(chǎng)景，為各位介紹 DCOS 的這些特性。

登陸爬蟲

通過本案例說明，如何在DCOS上從頭開始設(shè)計(jì)一個(gè)微服務(wù)架構(gòu)的應(yīng)用，在獲得彈性擴(kuò)展、高可用的特性下，如何進(jìn)行服務(wù)發(fā)現(xiàn)

在線會(huì)議系統(tǒng)

通過本案例說明，如何改造原有的互聯(lián)網(wǎng)應(yīng)用上云，以及借助容器的快速部署特性，架構(gòu)持續(xù)集成

文章分類與熱詞統(tǒng)計(jì)

通過本案例說明，如何在DCOS上實(shí)現(xiàn)大數(shù)據(jù)應(yīng)用，以及借助 Mesos 實(shí)現(xiàn)混合部署，提高資源利用率

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

Marathon：Marathon 是一個(gè) Mesos 的框架，能夠支持在集群環(huán)境中管理長(zhǎng)運(yùn)行服務(wù)，可以理解是分布式的 Init.d，它能夠運(yùn)行任何 Linux 二進(jìn)制發(fā)布版本如 Nginx 等，并可以對(duì)應(yīng)用的分布式多進(jìn)程進(jìn)行管理。

Chronos：Chronos 是一個(gè)具備容錯(cuò)特性的作業(yè)調(diào)度器， 也是一個(gè) Mesos 的框架，支持使用 Mesos Slave 作為作業(yè)執(zhí)行器，用于在分布式環(huán)境下替代 cron。

服務(wù)發(fā)現(xiàn)：服務(wù)發(fā)現(xiàn)是指，任何一個(gè)應(yīng)用的實(shí)例能夠以編程的方式獲取當(dāng)前環(huán)境的細(xì)節(jié)，而新的實(shí)例可以嵌入到現(xiàn)有的應(yīng)用環(huán)境而不需要人工干預(yù)。簡(jiǎn)單地說，在一個(gè)集群環(huán)境下，隨著應(yīng)用實(shí)例的增減或遷移，服務(wù)發(fā)現(xiàn)保證該服務(wù)仍然可以通過服務(wù)訪問地址被訪問。

持續(xù)集成：持續(xù)集成（Continuous Integration）是一種實(shí)踐，可以讓團(tuán)隊(duì)在持續(xù)的基礎(chǔ)上收到反饋并進(jìn)行改進(jìn)，不必等到開發(fā)周期后期才尋找和修復(fù)缺陷。通俗一點(diǎn)兒說，就是對(duì)于開發(fā)人員的代碼提交，都自動(dòng)地把代碼庫(kù)中的代碼進(jìn)行編譯、測(cè)試、打包。

微服務(wù)：微服務(wù)是一種新興的應(yīng)用軟件架構(gòu)，它通過一組服務(wù)的方式來構(gòu)建一個(gè)應(yīng)用，服務(wù)獨(dú)立部署在不同的進(jìn)程中，不同服務(wù)通過一些輕量級(jí)交互機(jī)制來通信，例如 REST。每個(gè)服務(wù)可獨(dú)立擴(kuò)展伸縮，并且定義了明確的邊界，不同的服務(wù)甚至可以采用不同的編程語言來實(shí)現(xiàn)，由獨(dú)立的團(tuán)隊(duì)來維護(hù)。

數(shù)人云：數(shù)人云是國(guó)內(nèi)第一款數(shù)據(jù)中心操作系統(tǒng)，基于Mesos管理容器生產(chǎn)環(huán)境，并集成了 Marathon、Chronos 等組件，對(duì)企業(yè)數(shù)據(jù)中心提供集群管理，容器管理，服務(wù)發(fā)現(xiàn)，持續(xù)集成等服務(wù)。

該系統(tǒng)是一套實(shí)時(shí)的登陸爬蟲系統(tǒng)，用戶輸入待爬取網(wǎng)站的用戶名和密碼，系統(tǒng)會(huì)自動(dòng)登陸賬號(hào)，并爬取賬號(hào)內(nèi)頁面數(shù)據(jù)，以報(bào)告的形式提供給用戶。這套系統(tǒng)常用于金融征信，評(píng)級(jí)機(jī)構(gòu)獲得用戶的登錄信息，通過爬蟲系統(tǒng)爬取該用戶的信用相關(guān)信息，形成信用報(bào)告。

先了解一下微幅架構(gòu)的幾個(gè)主要的設(shè)計(jì)理念：

通過服務(wù)實(shí)現(xiàn)組件化。微服務(wù)使用服務(wù)的形式來實(shí)現(xiàn)各個(gè)功能組件模塊，各個(gè)模塊間的依賴通過服務(wù)的方式來組織，即一個(gè)模塊通過遠(yuǎn)程過程調(diào)用來依賴另一個(gè)模塊，每個(gè)模塊是一個(gè)微服務(wù)。

企業(yè)按照業(yè)務(wù)功能來組織團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)負(fù)責(zé)一個(gè)微服務(wù)，可以做到“誰構(gòu)建，誰運(yùn)行”，這將極大降低運(yùn)維復(fù)雜度，縮短上線周期。

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

微服務(wù)構(gòu)架使得持續(xù)集成和持續(xù)交付變得更加便捷。有了微服務(wù)，集成和交付的單元從大而全的整體應(yīng)用變成了各個(gè)微服務(wù)，每個(gè)微服務(wù)都可以靈活地集成和交付。

這個(gè)系統(tǒng)在設(shè)計(jì)之初就考慮采用微服務(wù)架構(gòu)，以便部署在 DCOS 環(huán)境，并享受 DCOS 所帶來的各種特性。

該系統(tǒng)希望依照微服務(wù)架構(gòu)原則進(jìn)行設(shè)計(jì)，將功能模塊組件化，每個(gè)模塊實(shí)現(xiàn)一個(gè)獨(dú)立的功能，可多帶帶部署，模塊之間松散耦合。每個(gè)模塊可根據(jù)業(yè)務(wù)負(fù)載靈活地增加或縮減可承載容量，同時(shí)每個(gè)模塊由多個(gè)實(shí)例構(gòu)成，避免整個(gè)系統(tǒng)由于單點(diǎn)故障而造成系統(tǒng)癱瘓。

系統(tǒng)的業(yè)務(wù)需求大致如下圖所示。

在得到授權(quán)的情況下，用戶輸入所要爬取的網(wǎng)站的登陸用戶名和密碼，提交爬取任務(wù)；

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

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

由于數(shù)據(jù)是多實(shí)例并行爬取的，需要在爬取結(jié)束后進(jìn)行數(shù)據(jù)整合；

異步獲取結(jié)果；用戶登陸成功后，會(huì)提供一個(gè)查詢碼，并提示一段時(shí)間后進(jìn)行查詢；待爬取結(jié)束并形成后，用戶方可查詢到數(shù)據(jù)報(bào)告；

根據(jù)這些需求，需要以下系統(tǒng)組成：

一個(gè) web ui，與用戶交互；

模擬登陸模塊Loginer；

爬取模塊 Fetcher；

信息抽取模塊 Extractor；

信息整合模塊 Combiner；

ETL 模塊：用于清洗數(shù)據(jù)，形成最終報(bào)告；

系統(tǒng)設(shè)計(jì)如下圖所示。

用戶通過 Access portal 輸入待爬網(wǎng)站的用戶名和密碼，有些網(wǎng)站還需要輸入驗(yàn)證碼；

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

登陸成功后，Logginer 會(huì)將 cookie 和爬取任務(wù)一同寫入消息隊(duì)列，F(xiàn)etecher 負(fù)責(zé)領(lǐng)取任務(wù)，進(jìn)行頁面爬取； 爬取過程中，F(xiàn)etcher 需要攜帶 Cookie 訪問網(wǎng)站頁面；

Fetcher 將爬取的頁面存入消息隊(duì)列，由 Executor 負(fù)責(zé)從頁面中抽取需要的元素信息，并將這些信息放入緩存系統(tǒng)；

Combiner 負(fù)責(zé)將緩存中的數(shù)據(jù)進(jìn)行拼裝，并判斷爬取是否結(jié)束；若結(jié)束，將爬取結(jié)果存入數(shù)據(jù)庫(kù)；

ETL 模塊負(fù)責(zé)將爬取結(jié)果進(jìn)行清洗和整理，形成最終的報(bào)告；

用戶在等待一段時(shí)間后，可以查詢爬取結(jié)果，下載報(bào)告。

其中，F(xiàn)etcher、Extractor、Combiner 三個(gè)組件都需要了解本次抓取需要有多少 task，以及每個(gè) task 的狀態(tài)，以便判斷本次任務(wù)是否結(jié)束。

由于整個(gè)系統(tǒng)的每一個(gè)處理環(huán)節(jié)都是多實(shí)例的，模塊之間都不直接發(fā)生依賴關(guān)系，而是采用消息隊(duì)列或者存儲(chǔ)系統(tǒng)進(jìn)行解耦。

注：為了防止被某些網(wǎng)站限制 IP，還需要在 Loginer 前面增加一個(gè)代理層，每次使用隨機(jī)的代理服務(wù)器進(jìn)行網(wǎng)站訪問和登陸，這樣就避免了被封的風(fēng)險(xiǎn)。

從上面的設(shè)計(jì)中可以看出，大部分服務(wù)之間都通過分布式消息隊(duì)列或存儲(chǔ)系統(tǒng)進(jìn)行交互，這樣做的好處使得服務(wù)之間實(shí)現(xiàn)了異步交互，降低了耦合性。但這種異步方式并不適應(yīng)于任何場(chǎng)合，例如 Loginer 的設(shè)計(jì)就必須采用同步調(diào)用的方式，主要原因是：

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

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

Loginer 采用 Selenium 或 Http Client 進(jìn)行模擬登陸，當(dāng)網(wǎng)站登錄頁需要進(jìn)行 JS 渲染的時(shí)候，就需要用到 Selenium；Selenium 通過瀏覽器 driver 打開瀏覽器，訪問登錄頁，開始進(jìn)行模擬操作；為了簡(jiǎn)化瀏覽器狀態(tài)的維護(hù)，在設(shè)計(jì)時(shí)限定每個(gè) Loginer 實(shí)例同時(shí)只能處理一個(gè)登錄請(qǐng)求，直到本次登錄完全結(jié)束，關(guān)閉瀏覽器，才可以處理下一個(gè)登錄請(qǐng)求。可見，每個(gè) Loginer 需要維持一個(gè)狀態(tài)機(jī)。

正因如此，Loginer 需要部署較多的實(shí)例數(shù)；另外，由于瀏覽器 driver 不夠穩(wěn)定，時(shí)而出現(xiàn)調(diào)用無效的情況，Loginer 需要有重啟機(jī)制；

數(shù)人云提供了一套完善的面向微服務(wù)架構(gòu)的服務(wù)發(fā)現(xiàn)方案，如下圖所示。

現(xiàn)有服務(wù)發(fā)現(xiàn)根據(jù) marathon+zookeeper+bamboo＋haproxy 一起工作解決，具體說明如下：

應(yīng)用動(dòng)態(tài)變化導(dǎo)致 marathon 將狀態(tài)信息寫入 zookeeper（包括所在的主機(jī) IP、端口等），然后把變化事件發(fā)給事件訂閱用戶， bamboo 作為訂閱用戶， marathon-leader 會(huì)將變化事件發(fā)送給 bamboo。

bamboo 拿到事件后，按照事件給定的應(yīng)用標(biāo)示去 zookeeper 中取對(duì)應(yīng)的狀態(tài)數(shù)據(jù)。

bamboo 拿到數(shù)據(jù)后按照預(yù)先設(shè)定的 haproxy 模版生成一個(gè)臨時(shí)配置文件。

bamboo 將臨時(shí)配置文件和現(xiàn)有 haproxy 配置文件進(jìn)行對(duì)比。

bamboo 對(duì)比后，如果一致將直接結(jié)束任務(wù)。如果不一致，檢查一下配置文件格式。

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

將 Loginer 通過數(shù)人云發(fā)布，發(fā)布應(yīng)用時(shí)指定應(yīng)用地址，即在 haproxy 上配置一個(gè)訪問端口，再有服務(wù)發(fā)現(xiàn)機(jī)制將請(qǐng)求轉(zhuǎn)發(fā)到具體的應(yīng)用實(shí)例，具體請(qǐng)見數(shù)人云用戶手冊(cè)。

如果某個(gè) Loginer 實(shí)例在處理登陸任務(wù)時(shí)出現(xiàn)異常，只需要結(jié)束進(jìn)程，該 Docker 容器會(huì)自動(dòng) stop；Marathon 監(jiān)聽到有應(yīng)用容器停止，會(huì)重新啟動(dòng)一個(gè)新容器以保證服務(wù)容量。注意，新容器不一定運(yùn)行在結(jié)束運(yùn)行的舊容器所在的主機(jī)，可以是指定集群范圍內(nèi)的任何主機(jī)，而服務(wù)發(fā)現(xiàn)會(huì)幫助我們自動(dòng)發(fā)現(xiàn)該容器并進(jìn)行請(qǐng)求轉(zhuǎn)發(fā)。

當(dāng)然，在橫向擴(kuò)展時(shí)，增加 Loginer 的實(shí)例數(shù)，不僅可以做到快速地平滑擴(kuò)展（業(yè)務(wù)不停），也會(huì)將新實(shí)例通過服務(wù)發(fā)現(xiàn)加入到轉(zhuǎn)發(fā)列表中。

數(shù)人云還在 Haproxy 設(shè)置了會(huì)話保持，如果是基于 cookie 的會(huì)話，Haproxy 會(huì)將同一會(huì)話請(qǐng)求轉(zhuǎn)發(fā)到同一容器。

至此，一套具備橫向擴(kuò)展能力，高可用的登陸爬蟲系統(tǒng)就設(shè)計(jì)完了。

回頭來看，整個(gè)系統(tǒng)就是一個(gè)數(shù)據(jù)處理的 pipeline，每個(gè)環(huán)節(jié)之間松散耦合，具備高可用，可以獨(dú)自做到橫向擴(kuò)容或縮減，基本符合了微服務(wù)架構(gòu)的特性。這樣的架構(gòu)也為持續(xù)集成創(chuàng)造了良好的基礎(chǔ)，我們會(huì)在下一個(gè)案例介紹基于DCOS的持續(xù)集成。

注：數(shù)人云新版的服務(wù)發(fā)現(xiàn)功能已經(jīng)修改了策略，不再需要用戶選擇將代理部在某幾臺(tái)主機(jī)上，而是由系統(tǒng)默認(rèn)安裝在集群除了 Master 之外的所有主機(jī)上，構(gòu)成一個(gè)覆蓋全計(jì)算資源的代理集群，確保服務(wù)發(fā)現(xiàn)的高可用；同時(shí)對(duì) proxy 進(jìn)行了優(yōu)化，降低了運(yùn)行帶來的系統(tǒng)開銷。

這是一個(gè)在線會(huì)議工具，用戶可以通過微信登陸并接入系統(tǒng)，邀請(qǐng)好友開始遠(yuǎn)程會(huì)議。該應(yīng)用架構(gòu)復(fù)雜度中等，為典型的互聯(lián)網(wǎng)應(yīng)用。

該應(yīng)用的技術(shù)架構(gòu)如下圖所示。

如圖所示，其架構(gòu)圖中包括 Redis，Mysql，OSS，file-server 等存儲(chǔ)節(jié)點(diǎn)，也包括 web-server，api-server，push server 等服務(wù)節(jié)點(diǎn)，還有前端的 nginx 反向代理等。

服務(wù)節(jié)點(diǎn)間存在相互依賴。

所有節(jié)點(diǎn)都部署在阿里云，部分存儲(chǔ)服務(wù)使用了阿里云服務(wù)。

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

經(jīng)過對(duì)其業(yè)務(wù)流進(jìn)行梳理，我們大致得到以下架構(gòu)。

架構(gòu)圖中包括以下內(nèi)容：

每個(gè)服務(wù)的端口使用；

服務(wù)間依賴關(guān)系；

服務(wù)是否有狀態(tài)；

分別標(biāo)注對(duì)外服務(wù)、對(duì)內(nèi)服務(wù)及存儲(chǔ)；

對(duì)應(yīng)用大致做了以下改造：

服務(wù)節(jié)點(diǎn) Docker 化；

服務(wù)節(jié)點(diǎn)無狀態(tài)化，具備橫向擴(kuò)展能力；

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

多實(shí)例化的服務(wù)之間進(jìn)行服務(wù)發(fā)現(xiàn)。

上云步驟：

為每一個(gè)子項(xiàng)目編寫 Dockerfile

安裝私有 Docker Registry

部署應(yīng)用

監(jiān)控與測(cè)試

持續(xù)集成是一種軟件開發(fā)實(shí)踐，即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成它們的工作，通過每個(gè)成員每天至少集成一次，也就意味著每天可能會(huì)發(fā)生多次集成。每次集成都通過自動(dòng)化的構(gòu)建（包括編譯，發(fā)布，自動(dòng)化測(cè)試）來驗(yàn)證，從而盡早地發(fā)現(xiàn)集成錯(cuò)誤。而Jenkins是一個(gè)自動(dòng)構(gòu)建服務(wù)，使用Java實(shí)現(xiàn)，有成百上千插件，使用他可以很方便實(shí)現(xiàn)持續(xù)集成。

搭建 Jenkins

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

值得一提的是，數(shù)人云集群使用 Apache Mesos 進(jìn)行資源的統(tǒng)一調(diào)度，通過數(shù)人云可以快速搭建 Jenkins。把Jenkins運(yùn)行到 Mesos 上，或者說利用 Mesos 向 Jenkins 提供 slave 資源，一方面通過分布式特性加快構(gòu)建過程，另一方面也提高了資源利用率。通過配置 Jenkins-on-Mesos 插件，Jenkins Master 可以在作業(yè)構(gòu)建時(shí)根據(jù)實(shí)際需要?jiǎng)討B(tài)的向 Mesos 申請(qǐng) slave 節(jié)點(diǎn)，并在構(gòu)建完成的一段時(shí)間后將節(jié)點(diǎn)歸還給 Mesos。

具體教程請(qǐng)見 快速搭建 Jenkins 持續(xù)集成環(huán)境加速產(chǎn)品迭代。

代碼庫(kù)創(chuàng)建工程

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

鏡像構(gòu)建任務(wù)

在 Jenkins 里創(chuàng)建構(gòu)建任務(wù), 任務(wù)從 git repo 拉取代碼，指定 release 的 tag，使用 repo 里的Dockerfile，構(gòu)建 Docker 鏡像，并推送鏡像到 Registry 里。

根據(jù)不同的系統(tǒng)架構(gòu)，可以將構(gòu)建任務(wù)拆成不同的粒度。最簡(jiǎn)單的，一個(gè)任務(wù)構(gòu)建所有的子項(xiàng)目。如果項(xiàng)目比較復(fù)雜的情況下，每次構(gòu)建時(shí)間會(huì)比較長(zhǎng)，造成不必要的資源浪費(fèi)，那么可以將構(gòu)建任務(wù)拆分到顆粒度更小的子項(xiàng)目。

構(gòu)建觸發(fā)設(shè)置，可以為每次 push 后進(jìn)行構(gòu)建。但一般情況下，每個(gè)子項(xiàng)目也是有多人協(xié)作的，而且并不是每一次代碼提交都需要進(jìn)行構(gòu)建，因此構(gòu)建觸發(fā)策略設(shè)為 Tag push 觸發(fā)，及每當(dāng)增加 tag 時(shí)，觸發(fā)構(gòu)建任務(wù)。

鏡像發(fā)布任務(wù)

在 Jenkins 里新建任務(wù), 在這個(gè)任務(wù)里，通過調(diào)用數(shù)人云 Rest API 獲取認(rèn)證token, 發(fā)布應(yīng)用到 Mesos 集群。

可以設(shè)置發(fā)布任務(wù)的自動(dòng)觸發(fā)，比如當(dāng)一個(gè)構(gòu)建任務(wù)完成后觸發(fā)，或者每天晚上2點(diǎn)觸發(fā)，要根據(jù)不同的環(huán)境需要來進(jìn)行選擇。

發(fā)布腳本中，通過調(diào)用數(shù)人云 Rest API 獲取認(rèn)證 token, 以應(yīng)用的形式發(fā)布到數(shù)人云平臺(tái)。這里用curl命令發(fā)布應(yīng)用。也可以用 python、shell 等腳本調(diào)用 API 發(fā)布應(yīng)用，我們也推薦這樣做，可以更好的檢查調(diào)用API的返回。

以上，實(shí)現(xiàn)了整套系統(tǒng)上云以及構(gòu)建持續(xù)集成的過程。下一步便是構(gòu)建從開發(fā)、集成到生產(chǎn)的完整運(yùn)維體系。一般情況下，針對(duì)一個(gè)互聯(lián)網(wǎng)產(chǎn)品，開發(fā)環(huán)境由開發(fā)進(jìn)行構(gòu)建和發(fā)布，可以設(shè)置為 push 觸發(fā)或者前面提到的 tag push 觸發(fā)；集成環(huán)境由 QA 進(jìn)行構(gòu)建和發(fā)布，QA 定期發(fā)布并進(jìn)行集成測(cè)試，發(fā)現(xiàn)問題后再回退到之前版本；生產(chǎn)環(huán)境往往通過手動(dòng)方式觸發(fā)發(fā)布，在發(fā)布前需要做好客戶通知、應(yīng)急處理等各項(xiàng)準(zhǔn)備。

值得注意的是，將多份環(huán)境進(jìn)行統(tǒng)一發(fā)布管理，還需要配備配置服務(wù)器用于管理不同環(huán)境的配置信息，而這是另一個(gè)話題了。

重要提示：數(shù)人云新版已發(fā)布了持續(xù)集成服務(wù)，上述通過 Jenkins 部署和配置持續(xù)集成過程仍顯得比較繁重，那么通過數(shù)人云管理界面，通過簡(jiǎn)單的操作就可以實(shí)現(xiàn)自動(dòng)構(gòu)建的全過程，具體請(qǐng)參見數(shù)人云用戶手冊(cè)。

這是DCOS上的大數(shù)據(jù)項(xiàng)目。項(xiàng)目來源自一個(gè)互聯(lián)網(wǎng)媒體客戶，需求是將積累的媒體文章進(jìn)行分類，并找出能代表一篇文章的關(guān)鍵詞作為文章標(biāo)簽，用于進(jìn)行文章的分類或熱詞統(tǒng)計(jì)等數(shù)據(jù)分析，文章數(shù)量近5萬余篇，且在不斷增加。

項(xiàng)目選用 Apache Spark 作為計(jì)算框架，并通過 Spark MLlib 提供的 LDA 算法對(duì)文章進(jìn)行聚類，得到“文章-主題”和“主題-關(guān)鍵詞”矩陣，并以主題詞作為文章標(biāo)簽，對(duì)文章進(jìn)行歸類。

Apache Spark 作為一個(gè)分布式大數(shù)據(jù)計(jì)算框架，與 Apache Mesos 完美結(jié)合。Mesos 作為 Spark 集群的資源調(diào)度器，可以將 Mesos 集群的資源以粗、細(xì)兩種粒度分配給 Spark；在 Spark 完成計(jì)算任務(wù)后，Mesos 可以將資源回收，供其他服務(wù)使用。

從上圖看出，項(xiàng)目一共包括數(shù)據(jù)預(yù)處理、模型訓(xùn)練、預(yù)測(cè)訓(xùn)練集三個(gè)離線計(jì)算任務(wù)，和一個(gè)提供預(yù)測(cè)、添加文章、熱詞查詢等功能的服務(wù)模塊。

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

本案通過數(shù)人云管理 Mesos 集群，通過 Marathon 管理長(zhǎng)運(yùn)行的服務(wù)型應(yīng)用，通過 Chronos 管理離線計(jì)算任務(wù)，同時(shí)在集群中部署了 HDFS 分布式文件系統(tǒng)以及私有 Docker Registry。

其中，MySQL 用于存放每天的新文章數(shù)據(jù)，以及預(yù)測(cè)后的結(jié)果數(shù)據(jù)集；Nginx 用于對(duì)外提供服務(wù)。每天晚上2點(diǎn)運(yùn)行 Spark 計(jì)算任務(wù)，更新模型并對(duì)訓(xùn)練集數(shù)據(jù)重新預(yù)測(cè)。

Spark 采用 Mesos 作為資源調(diào)度器時(shí)，由 Mesos 統(tǒng)一調(diào)度計(jì)算資源，因此，Spark 集群無需部署，Mesos 集群即為 Spark 集群。

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

本案存儲(chǔ)層選用了 HDFS。Spark 連接 HDFS 時(shí)擁有數(shù)據(jù)位置識(shí)別能力，并會(huì)從集群內(nèi)距離最近的節(jié)點(diǎn)處讀取數(shù)據(jù)，從而最大程度降低數(shù)據(jù)在網(wǎng)絡(luò)中的傳輸需求。為了充分發(fā)揮 Spark 的數(shù)據(jù)位置識(shí)別能力，大家應(yīng)當(dāng)讓 Spark 計(jì)算任務(wù)與 HDFS 節(jié)點(diǎn)共同部署在一個(gè)集群中。

數(shù)人云提供為主機(jī)打標(biāo)簽的服務(wù)。如果 HDFS 只部署在集群的部分主機(jī)上，可以為這部分主機(jī)打上標(biāo)簽，在部署 Spark 計(jì)算任務(wù)的時(shí)候，可以限定在該標(biāo)簽范圍內(nèi)執(zhí)行。具體請(qǐng)參見數(shù)人云用戶手冊(cè)。

將 Spark 計(jì)算任務(wù)通過 Chronos 發(fā)布到集群中，Chronos 是一個(gè)具備容錯(cuò)特性的作業(yè)調(diào)度器，支持使用 Mesos 作為作業(yè)執(zhí)行器，用來在分布式環(huán)境下替代 cron。

制作任務(wù)鏡像

因?yàn)榇a和配置文件變動(dòng)相對(duì)頻繁，因此基于 Spark base 鏡像制作一個(gè)包含二進(jìn)制包和配置文件的任務(wù)鏡像。

Spark 項(xiàng)目的目錄如下：

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

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

任務(wù)鏡像的 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 編譯，二進(jìn)制包生成在 target/scala-2.10/spark_lda.jar。

根據(jù)調(diào)試或部署的需要，將 Spark 的配置目錄導(dǎo)入并替換原文件，便于配置更新。

運(yùn)行腳本run.sh是具體的 spark-submit 指令：

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

將三個(gè)離線計(jì)算任務(wù)分別制作成鏡像，然后將制作好的鏡像上傳到到鏡像倉(cāng)庫(kù)。

發(fā)布任務(wù)

Chronos 是一個(gè)具備容錯(cuò)特性的作業(yè)調(diào)度器，支持使用 Mesos 作為作業(yè)執(zhí)行器，用來在分布式環(huán)境下替代 cron。數(shù)人云已經(jīng)集成 Chronos，并對(duì)外開放了發(fā)布定時(shí)任務(wù)的 REST API。為三個(gè)離線計(jì)算任務(wù)分別創(chuàng)建 Chronos 任務(wù)，名為preprocessJob,trainJob,predictJob。一個(gè)具體的定時(shí)任務(wù)發(fā)布指令如下：

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"]]
      }"
 

有幾個(gè)注意的地方：

schedule：R/2016-03-15T02:00:00.000Z表示任務(wù)定為晚上2點(diǎn)開始執(zhí)行，P1D表示每隔一天執(zhí)行一次；

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

command：原生 Chronos API 不允許該字段為空，數(shù)人云已經(jīng)修補(bǔ)了該 bug。

具體的 API 說明請(qǐng)參見數(shù)人云 API 文檔。

Nginx，MySQL 這類長(zhǎng)運(yùn)行服務(wù)，通過 Marathon 發(fā)布。數(shù)人云已集成 Marathon，并提供了簡(jiǎn)潔的 UI，具體方法請(qǐng)參見數(shù)人云手冊(cè)。

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

Mesos 具有處理各種異構(gòu)任務(wù)負(fù)載的特性，因而使得在同一個(gè)平臺(tái)上管理大數(shù)據(jù)應(yīng)用和 Web 應(yīng)用成為可能。數(shù)人云集成了平臺(tái)監(jiān)控工具，可以方便地監(jiān)控集群、主機(jī)、應(yīng)用三個(gè)層面的資源使用情況以及各種應(yīng)用狀態(tài)，簡(jiǎn)化了運(yùn)維工作。

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

本文針對(duì)不用的應(yīng)用場(chǎng)景，提供了基于數(shù)人云 DCOS 的應(yīng)用上云方案，并分別說明了 DCOS 的特性；其實(shí)，只要處理得當(dāng)，每一個(gè)場(chǎng)景都是可以受用 DCOS 的多種特性的。

由于應(yīng)用的多樣性和復(fù)雜性，應(yīng)用上云并不止以上內(nèi)容，更多內(nèi)容請(qǐng)咨詢數(shù)人云。