回顧Java 發展，看 Docker 與Mesos | 數人云COO謝樂冰@KVM分享實錄

演講嘉賓

數人云COO 謝樂冰

在德國工做十年，回國後加入惠普電信運營商部門，擁有多年項目經驗和創業公司工做經驗。在數人云負責產品售前和運營，專一行業的技術應用領域，爲金融、電信、電商等行業提供服務。

回顧Java的發展軌跡看容器技術

由於我本身寫了十幾年的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與K8s的老生常談

言歸正傳，下面我來一步一步地介紹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之上，由於時間關係，下次再分享吧。

精彩問答

QQ羣

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協助網絡和虛擬機層面隔離