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

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

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

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

整個架構為了向上實現SOA的架構，雖然現實中90%以上頂多做到了“面向對象”，但并不妨礙Java（J2EE）作為企業服務交付的“通用”形式，成為了開發單位和運行單位共同接受的標準。所以Java背后代表的不僅僅是一個語言，還是一個完整的IT基礎架構和產業鏈 —— 昂貴的高性能硬件、閉源的中間件軟件、Java作為交付接口、SOA架構和開發與運維分離的模式。

背后還有兩個隱性的英雄，一個是北大青鳥這樣的培訓機構，大量產出Java程序員。另外就是Oracle數據庫，當然這些年輕程序員寫的代碼效率不太高的時候，全靠數據庫來救場了。當然這一切還是傳統的企業業務決定的，例如ERP、CRM等等，并發較低、強事物性和強一致性、邏輯和關聯關系復雜。

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

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

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

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

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

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

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

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

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

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

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

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

第一步 部署Zookeeper，負責整個集群的分布式一致性，例如Master領導選舉

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

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

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

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

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

結果

服務發現

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

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

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

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

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

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

容器層面的監控，主要是用cAdvisor，包括CPU、內存和IO

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

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

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

分布式系統和傳統IT區別，就像市場經濟和計劃經濟一樣，不是要處處完全可控有計劃，在最終結果保持可控情況下，突出靈活性、自由度和彈性，支持業務多變和快速發展。

這樣一個基本的分布式系統就搭建完畢，當然如果是生產級別還需要有大規模集群運行調優、集群化HAProxy，監控和報警對接、多租戶管理、F5的對接、和Openstack等等的IaaS對接等，這樣就需要數人云這樣的商業化開源方案來支持了。

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

可以看到，這個問題的回答并不是黑白分明。最理想的當然是完全的微服務架構，可以發揮全部的作用。當然90%應用目前還是有狀態應用，所以可以快速擴張，但是無法收縮，需要實現Graceful Stop功能，慢慢地收縮。所謂的無狀態化改造，無非就是很標準互聯網架構，不要用J2EE內置的Session就好。

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

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

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

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

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

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

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

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

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

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

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

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

Q4：安全性呢，公司有的業務不敢輕易放上去，這方面的問題如何解決
A4：適合內部私有云，公有云需要底層IaaS協助網絡和虛擬機層面隔離