Mesos container在360廣告系統的應用
女主宣言
本文來自4月14號360高級工程師李冬在第九期360互聯網技術訓練營上的分享。作者將技術與業務相結合，講解Mesos與container的技術架構，面對當前的業務痛點，可以解決哪些問題，並且如何應用到360商業廣告系統中。
PS：豐富的一線技術、多元化的表現形式，盡在「HULK一線技術雜談」，點關注哦！
背景簡介
大家好！今天我給大家分享的是mesos container在360商業廣告部門的應用。
我是一名SRE工程師，我們負責管理與維護360商業廣告平台，說起SRE工程師大家可能會想到谷歌公司，因為SRE畢竟是谷歌提出的概念。
作為SRE工程師我想說一下我們的自我修養。我們的主要工作是減少瑣事，不斷的擴大服務規模，同時我們還要保證整個系統的高可靠性和可維護性，不能隨著業務規模的不斷增大，招攬越來越多的人來維護業務是不合理的。
我們廣告通過360搜索或者360手機端的應用進行展示，比如在360搜索輸入「鮮花」會有廣告展示，每天有數百億次的投放與展示，手機端主要通過360的手機安全衛士，手機助手等等的一些應用進行廣告的投放與展示。
Why container?
說一下為什麼要使用容器解決我們的問題，還有演講的主題為什麼不寫Why Docker？
說到容器大家第一時間會想到Docker，它實現了一個容器引擎（Docker engine）。除了Docker，在容器生態圈還有一些公司他們實現了自己的容器引擎，比如CoreOS的RKT，比如我們使用的Mesos的容器引擎（Mesos containerizer），這些引擎不依賴於Docker本身，可以解決穩定性和擴展性的問題。
業務痛點
我先不說我們為什麼用容器解決這些問題，說一下業務上我們有哪些痛點，並且這些問題可能大家都會碰到。
1、數據中心遷移
這個問題大家多數都會遇到，在遷移過程中要把之前的業務熟悉一遍，需要重新部署，測試還會遇到一些環境配置不一致的問題。
2、故障恢復
伺服器宕機之後，傳統業務都部署在物理伺服器上，這樣也需要重新部署，這樣會帶來很多麻煩。
3、操作系統不一致
現在我們很多不同的操作系統，比如centos5、6、7都在用，遷移的時候很麻煩，還有一些系統內核的Bug需要去解決。
4、生產環境配置不一致
生產環境有一些伺服器工程師都可以登錄，如果改了一些配置導致線上出現問題的情況也是可能發生的。
5、測試環境不一致
可能每個人申請一台虛擬機專門做測試，導致測試結果也不一致。
6、服務的擴展性較低
傳統業務擴容一般需要一台中控機或者有一套部署環境，每一次都需要重新添加一批伺服器進行擴容。
7、伺服器資源利用率問題
使用物理機部署服務，每一天都有服務的高峰低谷，由於採用靜態資源劃分的方式，資源利用率非常低會給公司造成很多資源上的浪費。
下面我來說一下我們為什麼要用Docker來解決我們的問題。
Docker有一個隱喻叫「集裝箱」。其實Docker的英文翻譯是「碼頭工人」，這個隱喻給使用者很多暗示，告訴大家快來使用docker吧，使用Docker就像使用集裝箱一樣，能夠隨時隨地的，無拘無束的啟動你的應用。像Docker官方的口號一樣build、ship、and Run Any APP Anywhere，Docker為什麼可以解決我們遇到的這些業務痛點呢？因為集裝箱是有固定的標準，它的大小一致，這樣貨物在公路、鐵路、海洋運輸就不用考慮貨物的尺寸等問題了，並且依賴大型機械化進行轉運，等於是實現了一套標準的運輸體系，可以給整個世界帶來很大的商業潛力。
Docker的標準化怎麼實現？
正如我上面說到的，Docker的實質化就是標準，Docker的標準化是怎麼實現的呢？
首先，Docker有自己標準化的文檔管理方式，它的標準化文檔方式就是有自己的Docker file，可以定義一系列的軟體系統版本。
第二點，Docker有對應用的統一操作方法，在物理環境不同的應用有不同的啟動方法，如果你用Docker啟動程序，可以通過docker run的方式來啟動。在服務遷移過程中只要使用Docker run命令來啟動你的程序就可以了。
第三點，為了維護生產環境的一致性和配置變更的冪等性，docker 創造性的使用了類似 git管理代碼的方式對環境鏡像進行管理。每次都需要docker pull下載鏡像，Docker container本身只有container layer這一層可寫，你每次重新部署的時候這一層是會被刪掉的，這樣可以保證Docker實際環境每次都是冪等的。
在服務容器化過程中可能遇到的問題
在服務容器化過程當中，我們可能會遇到哪些問題？當大家使用物理機的時候，為了ssh登陸伺服器，每台伺服器都會開通SSH服務並且添加對應的賬號。如果你使用Docker服務還要開通SSH服務的22埠，你需要考慮一下你的服務是否真的需要登錄到容器中，或者你容器化的方式是否正確或者它是否適合你的業務。還有一些人這樣使用Docker：在容器中開放rsync服務埠，甚至還有在Docker container裡面部署puppet agent同步工具，這樣做我覺得是完全沒有必要的。我們都是不支持SSH或者類似的服務連接到Docker內部的。
如果你不讓我登錄到物理機上，不讓我連到Docker內部，我怎麼看我的日誌呢？
我們有一套日誌系統，後端對接的服務是elasticsearch，會使用Docker的syslog模塊通過UDP的方式寫入Graylog里，graylog或者grafana都可以進行展示、查詢，這樣我們就可以及時的發現線上的問題。
Docker的網路性能
使用了Docker，大家可能會考慮，它的網路性能會怎麼樣，我們其實也做過一些調研。我們主要用的是Hostonly 和Bridge這兩種模式，如果用Hostonly基本和直接在物理伺服器上運行程序的性能是差不多的，現在我們也有團隊專門做calico服務方面的研究，比如你有一些爬蟲服務，可能希望有一些獨立的外網IP，可以考慮使用Calico為一個container單獨分配外網IP。
或者有網路隔離的需求的話，也可以使用calico服務。由於我們主要針對是私有雲，直接用hostonly模式多一些。
存儲鏡像
關於Docker倉庫，大家可能會問服務容器化之後，主要用什麼倉庫存儲鏡像呢？哪種鏡像倉庫比較好？之前我們搭建過Docker官方的倉庫，只有單節點不是高可用的，數據可靠性也不是非常好，我們是用的無認證模式。
現在我們使用了Harbor，用這個系統做了二次開發，後端存儲用的S3存儲系統，數據可靠性是非常高的，多機房之間可以進行數據同步，支持用戶認證，大家根據自己的用戶密碼進行登錄上傳鏡像等操作。之後我們還會做一個Docker倉庫的CDN化，多機房直接訪問CDN服務下載鏡像。
怎樣把數據寫到本地
大家使用Docker可能會考慮數據怎麼寫到本地，我們使用mesos+Docker之後，是不是所有服務都要需要無狀態的呢？我們推薦無狀態服務運行在mesos+Docker之上。但是如果你有把日誌落到本地的需求，我們現在也是可以支持的。
我列出的這些產品，比如cephfs，mysql，kafka，HDFS，aerospike，redis都是數據持久化的一種方式，比如流式數據一般用kafka多一些，數據直接通過kafka消費出來，通過一些計算模型後再重新寫入kafka，或者如果想數據落到本地的需求直接在Container中掛載cephfs也是可以的。
服務的註冊和發現
關於服務的註冊和發現，大家可能會有一些問題。比如我用了mesos+Docker之後，我們的一些服務是在mesos-slave節點之間飄逸的，有可能因為一台物理機宕機了，你的服務會在另外一台mesos-slave節點上啟動，我怎麼知道我的服務啟動到具體哪台IP或者具體哪台機器上呢？
我們服務發現主要用的是mesos-dns還有marathon，底層數據依賴於zookeeper。還有一些公司可能用etcd或者consul，我們也有在用不過比較少。
關於使用了Docker，服務如何進行調度？還有Docker服務如果對於本地數據有依賴的話需要如何載入？希望大家可以帶著問題思考一下，一會兒我會詳細說明。
Why Mesos?
為什麼要用mesos？
當前遇到的一個背景就是在當前互聯網環境下，越來越多的分散式計算系統產生。
如果說維護一個大型業務團隊需要部署的框架或者分散式系統非常多，但是市面上又沒有一種系統能夠把所有的應用框架都部署到一個集群里，這樣就會導致我之前說的比如資源利用率會很低，可維護性很低。因為不同的集群有不同的配置，所以我們就想把這些多個應用布到一個大型的資源池裡，這樣可以更好的共享硬體資源。因為我們的服務都是支持動態擴縮容的，這樣也可以簡化一些部署上的邏輯，並且最大化的利用資源，最終實現服務可調度，數據可以共享。
使用mesos的優點
1、資源利用率非常高
因為之前大家用物理伺服器的時候，是靜態資源劃分的方式，這種方式資源浪費得比較多。因為服務每天都有高峰和低谷時段，如果你用mesos的話，使用了動態服務擴縮容，比如白天廣告展示的量會非常大，最高的時候每秒已經超過一百萬，但是在晚上訪問量非常低，你就可以把這批機器資源釋放出來，供一些離線業務運行，比如hadoop。可以達到最大化的資源利用率。
2、便捷性
mesos本身支持對所有資源打標籤，大家可以打固定的標籤。這樣在提交資源的時候，可以根據你想要的資源提出申請。比如你想要一個GPU的資源，比如你要1核的我就會分配給你一核的，像乘坐飛機一樣，你想坐頭等艙只要有資源就可以分配給你，mesos也是這樣，我們支持埠，CPU，內存、硬碟等等的劃分。
3、可擴展性非常好
因為它本身的設計原理是兩極調度框架，這樣帶來的好處是它非常的簡單。因為mesos本身只負責資源調度，把任務調度交給了運行在它之上的具體框架進行調度。所以如果你要橫向擴展mesos的話，非常方便。
4、模塊化
因為mesos支持在mesos API之上定義各種各樣的framework，大家可以自由添加framework，我們主要用的marathon，flink等官方與自定義framework，具體使用哪種框架，大家可以根據需要去設計。
mesos的目標
mesos的目標，其實主要就是給我們帶來資源的高利用率，支持多種多樣的自定義框架，包括當前支持的還有以後新產生的分散式計算框架等，都可以建立在mesos之上。
可擴展性。現在全球節點最大的是twitter有45000個mesos-slave。
可靠性。因為mesos採用的是熱備的方式，存在一個master節點，如果遇到主從節點切換的時候非常快，大概10秒鐘就能完成。
mesos的架構
mesos的主要組成是由zookeeper實現master的高可用，還可以保證數據的一致性，保存所有的mesos sleve節點和信息。mesos master主要用於接收agent上報給mesos master的資源，mesos master會分配offer給具體給它之上運行的framework。
Framework是基於mesos API定義的調度器，會根據調度需求分配具體的offer。
最底層是mesos agent，用來接受和執行mesos master發給它的命令，通過mesos agent之上的executor啟動task
mesos的實現
mesos是用的兩萬行的c++代碼編寫而成，故障恢復使用的是zookeeper，框架都是可拓展的、可以自定義的，並且是模塊化的。是Apache頂級的孵化項目，同時還是開源的，項目成立於2009年。
mesos的結果
mesos給我們帶來的是更高的資源利用率與可靠性。
mesos master的故障恢復機制
接下來說一下mesos master的故障恢復機制。
因為mesos master只有一個軟體狀態，只會列出它之上的framework以及mesos-slave的信息，在mesos master需要進行切換的時候，通過zookeeper進行leader的重新選取，選取好新的leader後，只需要所有的framework和mesos-slave節點重新註冊到新的mesos master之上，時間就10秒鐘左右。如有你有上萬台機器，可能會同時連mesos master會不會造成大量的鏈接導致master服務不可用，官方有這樣的設置可以設定鏈接的比例來進行控制。
mesos的生態圈有哪些框架
marthon framework
·運行長任務。從應用框架字面的意思，任務就像跑長跑一樣，這個框架其實就是運行長任務(long running job )的。
·服務發現。marathon還可以實現服務發現，有比較好的API介面，比如我有一個APP id對應具體機器的IP是什麼。
·健康檢測&事件通知機制。marathon支持對你所啟動的任務進行健康檢測，比如埠或者你自定義命令都可以，有事件通知機制，正因為有了事件通知機制才可以在馬拉松之上建立一些實時的服務發現，知道哪些服務宕掉了，在哪些新節點啟動了，可以保證我們的實時發現服務，重新指向新的伺服器。
·WebUI。marathon有自己的web UI，可以通過界面直接操作，非常方便。
·限定條件。你可以設定一大堆的限定條件，比如我之前說的像你選飛機的艙位一樣，你設定了網卡必須是萬兆的，marathon會根據你設定的限定條件，幫你選擇對應資源。
·Labels。labels標籤也是我們常用的，隨著資源利用率越來越大，可能有各種應用，大家可以加上各種的標籤，方便的查詢。
·數據持久化。數據持久化也是支持的，可以支持掛載本地卷。
·服務的預熱。這個功能用得不是特別多，比如你在服務啟動的時候會需要啟動時間，這個時間健康檢測是失敗的，你可能需要設定一個預熱時間，保證服務啟動之後正常的健康檢測才生效。
·優雅退出。優雅退出這個問題，大家可能都會遇到，比如像C++不涉及內存自動回收可能需要程序上設計優雅退出的問題，你可以通過marathon設置一個退出時間，保證你的服務正常退出之後，才把以前的服務都退掉，新的服務啟動。
·支持自定義的containerizer和GPU資源的調度。
Marathon-lb
marathon-lb是我們用的一個實時發現的服務，marathon-lb是基於haproxy和marathon eventbus機制設計的。其實除了mrathon-lb還有一些其他的服務實時發現，但是都是基於marathon的事件通知機制設計的。因為marathon有事件匯流排的實時更新，可以實時的改變服務後端的IP。如果有宕機或者有服務自動擴縮容的話，marathon-lb可以實時改變haproxy的配置，marathon-lb主要是通過第四層IP加埠的方式進行服務代理，marathon-lb支持TCP或者HTTP的代理方式。
Mesos-DNS
我們還使用了mesos官方的mesos-DNS服務，用於一些對實時性要求不高的服務，比如我們把STORM容器化以後nimbus和 supervisor之間的通信可能就不是那麼頻繁，如果有nimbus宕機的情況，只需要通過mesos-dns就可以重新發現appid對應的新的nimbus IP。你可以使用mesos-DNS發現appid對應的所有後端節點的IP，可以保證你的服務節點隨時都可以訪問到你想訪問到的IP。mesos-DNS有一定的延遲性，我們測試大概有十幾秒。
Mesos VS YARN
我說一下在我們做技術選型的時候，我們也做過mesos和yarn方面的調研。
mesos主要是能調度各種樣的資源，有CPU，內存、埠、硬碟；yarn主要是CPU和內存。
兩者都是兩極調度策略但是又有不同。
mesos本身只做資源的調度，不負責具體任務的調度，把任務調度交給framework調度。
yarn全都是yarn本身進行資源調度，一個程序提交給它一個任務都由yarn來決定是否接受或者拒絕這個資源，而mesos卻不同。
mesos因為是對物理資源進行管理與調度的，yarn主要基於hadoop來做。
根據需要，我們最後還是選擇了mesos來作我們的分布資源管理框架。
Mesos VS Kubernetes
說起mesos可能很多同學覺得使用了marathon 提供了容器任務的管理能力，可能就需要跟
kubernetes系統進行比較一下。
本身來講，mesos和kubernetes是兩個東西，mesos是一個分散式的資源管理框架，被稱為分散式系統的內核。假如你有很多物理資源，你想把它整合成一個邏輯資源層面的物理資源池，那麼你用mesos是最合適不過的了。
mesos解決問題的核心是如何把資源整合成一個大型的物理資源池，它上面運行什麼，怎麼跑它並不關注。
kubernetes主要是一個自動化的容器操作平台，操作主要包括部署、調度還有節點集群間的擴容等等。
kubernetes解決問題的核心主要是圍繞容器來做的，這兩個系統本身沒有可比性。因為mesos
支持很多framework，比如marathon可以實現容器的調度，所以大家就會把這兩個平台進行比較。
如果你想搭建這樣一個容器管理平台或者調度平台，從我個人來講第一點從任務上來講，marathon只支持長任務型的，kubernetes支持的比較廣，比如支持長時間任務(long running job)，節點後台支撐型（node-daemon）等等各種各樣的任務。
說一下穩定性方面，kubernetes是谷歌官方推出的，它的更新比較頻繁，更新頻繁可能帶來的就不是特別穩定，大家可能理解我可以多做一些線下測試，但是事實確實是這樣的，kubernetes更新非常頻繁。mesos一般每半年更新一次，一年發布兩個版本，會經過充分測試。mesos產品設計因為是開源的，是Apache基金會下面的頂級項目，會在社區跟大家進行投票與溝通，決定未來我們的產品怎麼做，我們會增加哪些功能。
第三種主要是從功能上來講，kubernetes是由谷歌做的，所以它的考慮會非常全面，它的生態非常全面，你想要的功能基本都有，包括網路kubernetes其實也是有的，其實kubernetes本身的網路做得不是特別好，很多用kubernetes都是用calico實現的。mesos 系統的設計思路則定義了任務調度和功能上整體依賴於調度器的設計，所以可以把 mesos 看成一個大樂高底層的基礎板。
對於這兩個框架，選擇哪一個都沒有對與錯，只有適合與否，選擇一個適合你們的工具才是最重要的。
mesos /container在360的一些應用
我說一下mesos /container在360的一些應用。
我們從2015年開始，就對分散式的調度系統或者容器調度平台進行了調研，最後選擇使用mesos，因為我們想構建一個大型的物理資源池。在2016年業務正式上線，包括之後說的一些服務的容器化，2016年我們也使用了chronos，可以運行一些物理機上運行的crontab 任務，長時間支持服務在線運行。2017年我們已經實現了兩個機房各部署了一個大型的資源池，節點達到了單集群最大1000個以上，任務達到5000個以上，10個以上的自定義framework。
解決的問題
部署
現在部署可能你只需要在marathon上改變你的鏡像(image)地址，或者只需要把instance數改大就可以擴容。
故障恢復
故障恢復，如果有一台mesos-slave宕掉了，會自動在其他的節點上啟動。
服務降級
關於服務降級，我們的資源池伺服器是有限的，1000台伺服器如果資源快用滿了，有些業務就需要做服務降級，不是所有業務都有動態擴縮容。我們主要處理廣告業務，廣告業務實時日誌流比較多，在資源不夠的時候，會讓某些業務降級。平時每秒處理20萬條，降級時讓它每秒處理10萬條或者5萬條，有一定數據延遲也沒有關係，因為數據不會丟只會慢慢處理完。
服務發現
關於服務發現，現在有了mesos-dns和marathon-lb我們可以做到實時的服務發現，因為是動態資源劃分，我們的任務就可能實時變化。
storm集群的容器化
上圖是原來通過物理級部署的，所有的supervisor節點都是一台台物理機還要單獨部署一個ninmbus，如果nimbus節點宕掉非常麻煩，比如有些同學說我可能會用keepalived做高可用，這確實是一種方案，但是如果你的集群需要頻繁的擴容或者縮容就會非常麻煩，你要是不對資源進行動態管理的話，勢必帶來的就是資源的浪費，因為不可能一天24小時都滿負荷運行。
把服務容器化之後，所有的supervisor都運行在container(mesos-slave)中，supervisor節點會通過 mesos-DNS發現ninmbus(master)的IP。現在集群資源都是動態利用的。
圖片服務的容器化
重點說一下圖片服務的容器化。
圖片服務主要用的PHP7來做的，我們也會面臨像阿里一樣在雙十一的時候，因為廣告展示與投放量非常大，每秒達到上百萬次，因為給用戶進行展示與投放的圖片會根據用戶的習慣去動態的縮放與拼接。如果我放著很多機器專門用來做圖片服務，可能也可以達到你的需求，但是在空閑時間段比如夜裡資源浪費得非常多，對資源的利用率不是非常好。
我們就制定了這樣一套方案，首先把PHP服務容器化，之後我們根據亞馬遜AWS的策略，做了自己的方案，跑一個long running job，根據marathon的API獲取你的圖片服務具體是哪台機器，由於所有機器上的監控都用了二次開發，通過API介面能獲取負載、CPU，內存等等信息。當圖片伺服器的負載上升了肯定是壓力最大的時候，這樣我們只需要設定一個閾值。
比如系統負載大於10超過10次，就進行一次擴容，擴容的倍數是1.5倍，原來我有10台機器，現在要擴容到15台。大家可能會問你這個最大能擴到多少？我一定要設定一個最大值不能無限的擴。比如我們設定一個36，最大擴到36台，在5分鐘內可能判斷10次，如果這個負載水平一直很高，就不進行縮容。
我肯定還會設定一個最低值，比如最低值是6台，可能到了夜裡直接減為6台，每次都需要通過marathon的API實時發現後端所有機器計算出一個平均值。服務的監控，我們對每台mesos slave都有監控，具體的container我們做了非同步，通過非同步把日誌寫到graylog中，監控日誌傳輸通過UDP協議。如果發生網路中斷的情況也不會有太大影響，因為UDP是可丟的不可靠的。
其他
我們還有其他服務的一些容器化，有Web service相關的，aerospike服務，通過組播實現集群之間的通信部署起來比較方便，marathon-lb也是完全的Docker化的，畢竟是代理層像lvs一樣，可能會有服務瓶頸。kafka mirrormaker我們用來進行多機房之間的數據傳輸，原來直接部署在物理機上，這樣雖然不會有太大問題，如果宕掉之後數據不能在多個集群當中進行同步，對實時性不能要求那麼高。如果做了容器化之後是可調度的，都是可高可用的，我們會保證服務的可靠性。redis也有做容器化，支持數據的落地和持久化，因為我們有cephfs還有更多的一些無狀態的服務也運行在mesos之上。
最後我要說一下我們的服務ci/cd是怎麼做的，ci/cd主要是通過GitLab runner。我們會定義一個Gitlab-CI，可以直接把你提交的代碼進行Docker build，把鏡像自動提交到對應的倉庫，通過API修改marathon上面對應的地址，最後實現上線自動化。
未來計劃
未來我們想做的，因為cephfs的量不是很大，cephfs之後想上一些寫入量比較大的業務，看看效果如何。我們不是做公有雲的對於calico的需求不是那麼急切，之前一直沒有上這個服務。之後我們可能會做一些calico相關的，比如一些爬蟲的應用，如果用公司的Nat代理的話，可能遇到一些IP被封，導致整個代理IP都不能訪問對應的網站就有一些問題了。
還有一些實時的機器學習，現在機器學習主要都基於離線業務來做，實時學習比較少，marathon和mesos本身是支持的。
謝謝大家！
TAG:HULK一線技術雜談 |