摘要：馬拉松會匹配每個和提供的資源，然后通過將任務(wù)下發(fā)下去。對外暴露的就是負載均衡的某個服務(wù)，后面自動將流量轉(zhuǎn)發(fā)到某個容器的端口上。還有一直辦法是用內(nèi)網(wǎng)的，這個會維護現(xiàn)有的容器列表端口，并且返回任意一個的端口，頁實現(xiàn)了負載均衡和服務(wù)發(fā)現(xiàn)功能。

演講嘉賓
數(shù)人云COO 謝樂冰
在德國工作十年，回國后加入惠普電信運營商部門，擁有多年項目經(jīng)驗和創(chuàng)業(yè)公司工作經(jīng)驗。在數(shù)人云負責產(chǎn)品售前和運營，專注行業(yè)的技術(shù)應(yīng)用領(lǐng)域，為金融、電信、電商等行業(yè)提供服務(wù)。

因為我自己寫了十幾年的Java，經(jīng)常把容器和十年前的Java做比較。一個公司說自己是做“Java”的，實際上涵義是背后一整套企業(yè)IT基礎(chǔ)架構(gòu)。軟件一般都是各個集成商（東軟、文思）大量碼農(nóng)兄弟們開發(fā)，主要還是用Windows。打成了WAR、EAR包之后交付給甲方，就可以在Linux環(huán)境下跑起來。同樣Weblogic WAS這些中間件在底層計算集群之上，實現(xiàn)了企業(yè)服務(wù)的大規(guī)模運行。

中間件之下是IOE昂貴的高性能硬件，雖然也是集群化，主要依靠Scale up來提升性能。雖然中間件理論上實現(xiàn)了應(yīng)用和硬件資源解耦，但實際上依然對硬件有非常苛刻的要求，特別是跑數(shù)據(jù)庫的部分。

整個架構(gòu)為了向上實現(xiàn)SOA的架構(gòu)，雖然現(xiàn)實中90%以上頂多做到了“面向?qū)ο蟆保⒉环恋KJava（J2EE）作為企業(yè)服務(wù)交付的“通用”形式，成為了開發(fā)單位和運行單位共同接受的標準。所以Java背后代表的不僅僅是一個語言，還是一個完整的IT基礎(chǔ)架構(gòu)和產(chǎn)業(yè)鏈 —— 昂貴的高性能硬件、閉源的中間件軟件、Java作為交付接口、SOA架構(gòu)和開發(fā)與運維分離的模式。

背后還有兩個隱性的英雄，一個是北大青鳥這樣的培訓(xùn)機構(gòu)，大量產(chǎn)出Java程序員。另外就是Oracle數(shù)據(jù)庫，當然這些年輕程序員寫的代碼效率不太高的時候，全靠數(shù)據(jù)庫來救場了。當然這一切還是傳統(tǒng)的企業(yè)業(yè)務(wù)決定的，例如ERP、CRM等等，并發(fā)較低、強事物性和強一致性、邏輯和關(guān)聯(lián)關(guān)系復(fù)雜。

如今時代發(fā)展到了藍色的部分，云計算時代的IT架構(gòu)底層不再是幾臺小機或者一堆刀片，更多的是企業(yè)私有云甚至是公有云，IaaS實現(xiàn)了資源層管理的自動化和標準化。

容器就像當年的Java一樣，成為了開發(fā)和運維共同認可的接口。容器成為了應(yīng)用上“云”的標準交付方式，不管是Java、Python還是C，只要用Docker打包，就可以丟到這個那個“云”上跑起來。

當然在底層各種計算資源（公有云、私有云甚至物理機）之間，也需要一個中間件來作為容器的大規(guī)模運行環(huán)境。下面是成千上萬的主機，上面是烏央央的容器，中間的云計算中間件實現(xiàn)了兩者的解耦。上面支撐的軟件架構(gòu)是“微服務(wù)”架構(gòu)，就像當年的SOA。整體上也是實踐了Devops一套運維開發(fā)方式。就像傳統(tǒng)中間件包括了運行環(huán)境、消息隊列、ESB（服務(wù)發(fā)現(xiàn)）和數(shù)據(jù)抽象等等，云計算中間件也都有類似的服務(wù)，例如Mesos、K8s這些容器運行環(huán)境，就對應(yīng)著跑EJB的Weblogic Application Server。

總之，“容器”背后不是單個技術(shù)，而是完整的以開源軟件為主的云計算IT基礎(chǔ)架構(gòu)和相應(yīng)的開發(fā)和運維流程。當年虛擬機出現(xiàn)讓大家嘗到一點點云的滋味，但是畢竟局限于資源層，對開發(fā)、業(yè)務(wù)和軟件架構(gòu)沒有影響。如今容器影響這么大，大家終于成為了應(yīng)用上云的突破口，將對大家未來的職業(yè)生涯產(chǎn)生巨大的影響。就像今天很難招聘到懂EJB的大學畢業(yè)生，過兩年很快容器和背后的互聯(lián)網(wǎng)開源技術(shù)棧就會成為主流。

言歸正傳，下面我來一步一步地介紹Mesos的實戰(zhàn)。說起Mesos，大家往往第一個問題是Mesos和K8s有啥區(qū)別，哪個更好。我覺得這兩個就像iOS和安卓，已經(jīng)成為了新一代輕量調(diào)度框架的主流。兩者都是源于Google的Borg，但Google自己沒有使用任何一個。K8s勝在開發(fā)者多，用Go語言開發(fā)，社區(qū)活躍。Mesos是Apache項目，已經(jīng)誕生了7年，目前有過超過萬臺規(guī)模的部署。總體上我們認為Mesos比較適合目前階段的大規(guī)模生產(chǎn)環(huán)境部署，K8s目前還處于快速更新的階段，兩者都有很好的未來。當然Mesos也能兼容大數(shù)據(jù)等框架，未來目標是逐步把各種集群化的應(yīng)用（Kafka集群例如）都搬到Mesos上來，實現(xiàn)一鍵安裝和自動擴展。

下面是一點點Mesos的科普，其實市面上類似的文章已經(jīng)不少，這里我特別推薦平安科技余何老師的《PaaS實現(xiàn)與運維管理：基于Mesos +Docker+ELK的實戰(zhàn)指南》，內(nèi)容非常詳細。

用兩句俗話說Mesos和K8s的原理，就是像使用一臺電腦一樣使用整個集群，類似集群的操作系統(tǒng)。單機的操作系統(tǒng)是管理單機的計算、存儲和IO，集群操作系統(tǒng)是管理管理一堆機器的資源。目前聚焦在計算和內(nèi)存之上，存儲部分需要多帶帶的分布式存儲（例如Ceph和GlusterFS），網(wǎng)絡(luò)需要SDN的支持。不過傳統(tǒng)上IOE也是各管一攤了。

原理看起來也不復(fù)雜，Mesos 在每臺Slave主機上安裝一個Agent，不斷地把剩余資源上報到Master。報告內(nèi)容類似 { (node1, <2 CPUs, 4 GB>),(node2, <3 CPUs, 2 GB>) }，這樣Master就知道各個機器的剩余資源情況了，非常簡單。

Master上面有很多框架Framework，例如Docker和Spark。你就可以把他們理解為Linux里面安裝的JRE和Golang、C的運行類庫。你想在Mesos上跑啥“語言”，就要部署個框架，例如跑Docker的框架就是Marathon。Mesos會把整個集群的資源按照一定的算法分配給各個框架，這個就是所謂資源調(diào)度的過程。因為Slave上報資源情況是不斷更新的，所以就是所謂動態(tài)資源調(diào)度。

每個框架收到分配的資源之后，會自行決定將任務(wù)和資源匹配，然后通過Master將任務(wù)下發(fā)到Slave上執(zhí)行。Slave上面有每種任務(wù)的執(zhí)行器（Executor），就是運行環(huán)境。例如Docker任務(wù)的執(zhí)行器是Mesos預(yù)裝，其他類型任務(wù)執(zhí)行器可能會實時下載。所以通過安裝不同的框架+執(zhí)行器，就可以支持各種“分布式”的任務(wù)系統(tǒng)。請注意這里說的一定是集群化的系統(tǒng)，如果是單點部署一個MySQL之類的就意義有限了。

以管理Docker任務(wù)的Marathon框架為例，它收到了Master提供的資源之后，一個是負責進行任務(wù)調(diào)度，而且還能夠通過Health Check監(jiān)控任務(wù)是否還活著，發(fā)現(xiàn)失敗就重新下發(fā)任務(wù)。

這些都是常規(guī)性的解釋，下面我們看看Mesos集群，看看如何一步步搭建。初始一般需要準備3臺主機承載Master節(jié)點，任意多的Slave，這里建議也是3臺。還有幾臺機器存放log等等。下面的一些圖片來自前兩天數(shù)人云公眾號（dmesos）翻譯的文章《初次微服務(wù)體驗：從Docker容器農(nóng)場說起》。

第一步 部署Zookeeper，負責整個集群的分布式一致性，例如Master領(lǐng)導(dǎo)選舉

第二步，部署Mesos本身。我們的分布部署了3個Master，管理3個Slave節(jié)點。大家注意到，配置Mesos的時候最重要的參數(shù)就是Zookeeper，不但Master要通過ZK來進行領(lǐng)導(dǎo)選舉，而且Slave也可以通過ZK來知道誰是活躍的Master.

到這一步，理論上已經(jīng)可以用Mesos來管理集群下發(fā)任務(wù)了，大家看見下圖里面資源（Slave）、任務(wù)（正在執(zhí)行的已經(jīng)介紹的）。

甚至還能看到該任務(wù)的Stdout輸出，就和SSH進去操作一樣。

不過僅僅有Mesos，還要自己來編寫框架調(diào)用接口發(fā)布任務(wù)，非常不方便。所以需要一個框架來跑容器任務(wù)，那就是馬拉松（Marathon）。顧名思義用來跑各種長時間運行的服務(wù)，類似Linux里面的Inti.d，例如各種網(wǎng)站服務(wù)。馬拉松是用Scala編寫的，本身提供自己的Web管理界面，通過這個界面我們可以“遙控”Mesos來下發(fā)并保證Docker任務(wù)長久穩(wěn)定執(zhí)行。

馬拉松的界面也非常直接，大家看看發(fā)布Docker任務(wù)的界面，基本就是填入Docker Run后面的那些參數(shù)，然后告訴馬拉松要發(fā)布多少份。馬拉松會匹配每個Task和Mesos提供的資源，然后通過Mesos將任務(wù)下發(fā)下去。

結(jié)果

服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)是個比較晦澀的翻譯（Service Discovery），大概不妨粗略地理解成負載均衡算了。例如馬拉松下發(fā)了100個網(wǎng)站的容器，每個容器有自己IP（一般是宿主機）和端口。顯然前面需要擋一個負載均衡來分配流量。對外暴露的就是負載均衡的某個服務(wù)URL，后面自動將流量轉(zhuǎn)發(fā)到某個容器的IP+端口上。

我們這里用HAProxy來做負載均衡，有個服務(wù)叫Bamboo會不斷從ZK讀出Mesos狀態(tài)并且更新HAProxy的配置文件。這樣新發(fā)下來的Docker會自動添加上HAProxy，而死掉的會被移除。

還有一直辦法是用內(nèi)網(wǎng)的DNS，這個DNS會維護現(xiàn)有的容器列表（IP+端口），并且返回任意一個的IP+端口，頁實現(xiàn)了負載均衡和服務(wù)發(fā)現(xiàn)功能。不過目前Mesos DNS還不太成熟，我們一般用HAProxy。

幾百個Docker撒出去，絕對不可能再登到主機上去找看日志。日志必須集中收集，并且提供檢索功能，才能有效的Debug。解法也不新奇，無非是ELK。請注意Docker日志可以直接從API讀出，另外需要增加一些應(yīng)用、主機和容器有關(guān)的Meta Data。

此外分布式系統(tǒng)不能沒有監(jiān)控，黑盒子等于無法運行，所以監(jiān)控要分為如下三個層面。

主機監(jiān)控：這個并非Mesos的關(guān)注點，因為主機是資源層，本身也有自己的監(jiān)控體系

容器層面的監(jiān)控，主要是用cAdvisor，包括CPU、內(nèi)存和IO

最最重要的是應(yīng)用層監(jiān)控，因為PaaS本身對外提供服務(wù)，所以監(jiān)控的關(guān)注點應(yīng)該是全局最終結(jié)果和邏輯正確性，而不是太糾結(jié)于個別主機和容器的

這個是分布式系統(tǒng)和傳統(tǒng)系統(tǒng)最大的區(qū)別，關(guān)注點不再是個別容器和主機，而是業(yè)務(wù)本身。這種系統(tǒng)設(shè)計本來就是希望軟件脫離對特定和單點硬件的依賴，通過集群化實現(xiàn)大規(guī)模系統(tǒng)的高性能和高可用。所以監(jiān)控不再是著眼于“源頭”，而是看重效果。很多時候平臺的自愈機制甚至“埋沒”了底層的一些故障，那么就讓他被埋沒了，只要最后效果能夠得到保證。

分布式系統(tǒng)在應(yīng)用層監(jiān)控要求遠遠大于普通的IT系統(tǒng)，例如下面是一個HTTP返回狀態(tài)嗎的直方圖，這樣能很快發(fā)現(xiàn)是否出現(xiàn)大規(guī)模異常，并且通過日志系統(tǒng)來定位問題。

分布式系統(tǒng)和傳統(tǒng)IT區(qū)別，就像市場經(jīng)濟和計劃經(jīng)濟一樣，不是要處處完全可控有計劃，在最終結(jié)果保持可控情況下，突出靈活性、自由度和彈性，支持業(yè)務(wù)多變和快速發(fā)展。

這樣一個基本的分布式系統(tǒng)就搭建完畢，當然如果是生產(chǎn)級別還需要有大規(guī)模集群運行調(diào)優(yōu)、集群化HAProxy，監(jiān)控和報警對接、多租戶管理、F5的對接、和Openstack等等的IaaS對接等，這樣就需要數(shù)人云這樣的商業(yè)化開源方案來支持了。

此外經(jīng)常有用戶問到，啥樣的應(yīng)用可以上云呢，下面的表格回答了這個問題。

可以看到，這個問題的回答并不是黑白分明。最理想的當然是完全的微服務(wù)架構(gòu)，可以發(fā)揮全部的作用。當然90%應(yīng)用目前還是有狀態(tài)應(yīng)用，所以可以快速擴張，但是無法收縮，需要實現(xiàn)Graceful Stop功能，慢慢地收縮。所謂的無狀態(tài)化改造，無非就是很標準互聯(lián)網(wǎng)架構(gòu)，不要用J2EE內(nèi)置的Session就好。

本來今天還要展示一個我們的客戶案例，如何將一個分布式系統(tǒng)遷移到Mesos之上，因為時間關(guān)系，下次再分享吧。

Q1：當初剛接觸Linux的時候，最開始是在Virtualbox等虛擬機這種模擬環(huán)境里面摸索 Linux，代價低，比較容易動手和入門。對有一定基礎(chǔ)的運維人員（但剛接觸容器集群），你建議用什么配置的環(huán)境測試做 方便入門（比如測試 Mesos+ZooKeeper+Marathon+Docker）
A1：虛擬機就可以，VARGANT

Q2：Docker的數(shù)據(jù)持久存儲采用何種存儲，用Ceph之類？
A2：對，各種分布式存儲，例如Glusterfs

Q3：我想問一下K8s＋Docker 現(xiàn)在用作生產(chǎn)的話夠成熟嗎？ K8s能達到高可用了嗎？
A3：小集群的話可以倒騰倒騰，K8s的源碼有浙大張磊老師的書

Q4：還有就是Mesos能否和Openstack結(jié)合起來，生產(chǎn)環(huán)境有沒有Docker和Openstack結(jié)合的案例
A4：必須可以，我們就和Openstack廠商一起合做生產(chǎn)系統(tǒng)部署了。可以這么說，完整的DCOS是包括IaaS+PaaS，如果企業(yè)要對底層資源嚴格管理，就需要IaaS

Q5：我想問下Docker的性能，尤其是網(wǎng)絡(luò)部分，比物理機和普通虛擬機差很多么，用集群性能會不會好些呢
A5：如何是Host模式，Docker網(wǎng)絡(luò)性能和物理機一樣，具體可以看 這里有一篇IBM的論文，討論了差別：
http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B/$File/rc25482.pdf

Q1：一直想問Doceker會不會一定成為下一代虛擬化。
A1：反正Docker已經(jīng)基本成為了開發(fā)和運維和廠商都比較接受的上云交付形式。

Q2：容器算不算虛擬化的一種，一臺服務(wù)器，上邊跑很多虛擬機怎么更好的提升性能。
A2：最好不要把容器當成虛擬機，虛擬機的意思是和特定IP或者宿主機綁定，而容器特點是在云上飄來飄去。例如經(jīng)常有需求是給容器分配IP，其實就是當虛擬機了

Q3：有開源版供學習嗎？
A3：Mesos這些都是開源的，可以參考平安余何老師的著作,數(shù)人云管理平臺本身是不開源的。

Q1：ELK本身也是Docker來部署么？
A1：目前有狀態(tài)的服務(wù)很多都有Mesos框架，但是在生產(chǎn)環(huán)境中產(chǎn)品化還不多。我們目前不建議客戶數(shù)據(jù)庫等應(yīng)用放上來。背后邏輯也是這些服務(wù)，一般還不太需要動態(tài)擴展和更新，就算實在互聯(lián)網(wǎng)公司里面。下一步我們也會推出企業(yè)應(yīng)用商店，會把一些經(jīng)過測試已經(jīng)產(chǎn)品化的集群化組件放出來，這個還需要一些時間。

Q2：首先說一下我還沒有完全拜讀完，這個話題很熱，我也很感興趣。我想問的問題，不是具體的技術(shù)問題。我是想問一下：傳統(tǒng)的數(shù)據(jù)中心和傳統(tǒng)的企業(yè)業(yè)務(wù)，如何在這場技術(shù)大潮中轉(zhuǎn)移到新的技術(shù)架構(gòu)。例如我們現(xiàn)在的數(shù)據(jù)中心怎樣轉(zhuǎn)移到您今天分享的這種架構(gòu)上來？
A2：四個字“業(yè)務(wù)驅(qū)動”，不上云就宕機，或者看著滿地黃金撿不起來，就自然有動力了。
一般說來是7個字，新業(yè)務(wù)上新平臺。互聯(lián)網(wǎng)的成功在于不是頂層設(shè)計，而是消費者的業(yè)務(wù)驅(qū)動。
當然，對于技術(shù)水平較高的大型企業(yè)，未來交付形式普遍容器化之下。他們引入容器的核心目的是推進自身架構(gòu)云化改造。

Q3：你們回答的是什么應(yīng)用適合上云還是容器云？
A3：首先“容器”是應(yīng)用上云的Gateway，所以可以說泛指上云的應(yīng)用，云端應(yīng)用最好都符合Cloud Native架構(gòu)。當然IaaS也是云，傳統(tǒng)有狀態(tài)應(yīng)用理論上無需改造也能上虛擬機。不過傳統(tǒng)應(yīng)用強烈和底層硬件特定能力綁定，而虛擬機網(wǎng)絡(luò)IO不一定滿足需要，所以上云的過程同樣需要改造。例如數(shù)據(jù)庫分片來減少單節(jié)點壓力等等。

Q4：安全性呢，公司有的業(yè)務(wù)不敢輕易放上去，這方面的問題如何解決
A4：適合內(nèi)部私有云，公有云需要底層IaaS協(xié)助網(wǎng)絡(luò)和虛擬機層面隔離