前言
“只要站在風口，豬也能飛起來”，這碗心靈雞湯不知道激勵了多少英雄豪傑踏上尋風口之路。而現如今，Docker這陣龍捲風呼嘯來襲，更讓衆人生起迎風而上、直衝雲霄的慾望。爲了找到這風口，騰訊數據平臺部開始全面擁抱Docker，基於多年的大數據集羣管理經驗，傾力打造DockerOnGaia雲平臺（簡稱Gaia雲），並動員將數平自身的核心繫統全面接入Gaia雲。
Lhotse系統作爲先鋒部隊，經過一段時間的改造-驗證-灰度，目前現網已經完全接入、穩定運營。本文旨在分享Lhotse接入Gaia雲的一些實踐經驗，拋磚引玉，期待更多的系統加入隊伍，一起在Docker雲中探索前行。
背景介紹
Lhotse是一個大數據任務調度系統，從架構上看是典型的Master-Agent分佈式架構，如下圖所示，作爲調度核心的Base統籌分配任務，交由對應類型的Runner執行：
到目前爲止，Lhotse線上支持68種Runner，分別對應68種不同的任務類型，集羣總機器數將近200臺。面對這種複雜多樣的系統環境，Lhotse接入Gaia雲的核心訴求是自動化，通過自動化來降低系統管理複雜度、提高運維效率。自動化運維可以總結爲兩點：
機器操作取代人工操作——將複雜枯燥的工作（比如資源分配、程序部署）交給雲平臺處理。
通用實現取代重複實現——雲平臺將一些通用性的基礎工作（比如進程監控、自動拉起）抽象成標準化服務，不必重複造輪子。
除了自動化之外，Gaia雲帶來的另一個核心點是透明化。它在應用的不同階段有不同的含義：
在應用部署階段，指的是機器集羣的透明化。集羣規模、機器分佈、機器規格等因素對用戶來說都是透明的，成羣的服務器被Gaia封裝成了一臺超級計算機。
在應用運行階段，指的是實例狀態/資源使用/歷史事件/系統日誌的透明化。通過Gaia封裝的API或者web portal，應用的一切運行動態盡在掌握，透明公開。
下面我們將分別從部署、調度、容錯、灰度升級、擴縮容及服務發現六個緯度，來討論Gaia雲如何爲Lhotse帶來自動化與透明化。
部署
Lhotse部署遇到的最大難點在於，每個類型的Runner所依賴的運行環境都有差異。例如，Pig Runner需要機器上預裝PigClient、Hadoop，而Compute Runner需要預裝PLC。極端的情況是，68種Runner對應68種不同的運行環境，要在200臺機器裏交叉部署，並且保證各個運行環境完整一致、相互不受影響，這對運維來說是極大的挑戰。
對症下藥，Gaia雲給我們開出Docker這一藥方，帶來了如下功效：
環境一致：將軟件運行環境（包括程序包、軟件依賴、配置文件等）鏡像化後，無論在哪臺機器運行，只要鏡像相同，容器啓動後的運行環境總是一致的。
環境隔離：在同一臺機器運行的多個容器，其運行環境(比如，軟件版本與配置)相互隔離、不受干擾。
版本管理：每次軟件升級可重新構建鏡像，通過鏡像tag來管理標註不同的版本，方便灰度、回滾。
快速部署：將軟件部署到新的機器，僅需獲取鏡像這一步操作，無需拷貝、安裝、配置等一系列過程。
現在，Lhotse的部署流程已經完全Docker化：我們將每個Base/Runner及其運行環境build成一個Docker鏡像，push到Gaia雲的Registry；每次啓動Base/Runner容器時，Gaia自動從Registry pull最新的鏡像。整個部署過程如下圖所示：
調度
有了自動化部署，我們可以方便地將Base/Runner發佈到集羣的任意機器。但接下來的問題是，選擇哪臺機器在什麼時候運行哪個程序——這是調度要解決的問題。
以前，Lhotse集羣的調度都是人工靜態處理，資源分配粒度只能到機器級別。這導致調度工作量大，資源利用率卻不高。如下兩圖分別展示了各個Runner機器的CPU與內存利用率（橫座標表示Runner類型編號，縱座標表示利用率數值）：
現在，得益於Gaia雲強大的調度能力，Lhotse已經告別了人工資源分配的時代，完全實現調度的自動化。Gaia的調度能力主要體現在兩個方面：
資源分配粒度精細到CPU與內存級別。Lhotse可以根據每個Runner的資源需求來設定具體的CPU個數、內存值。目前，Gaia正在規劃支持磁盤、網絡帶寬等其他資源，實現更精細化的調度。
集羣公平地與其他租戶共享（租戶可以是不同的系統，也可以是同一個系統內的不同模塊）。目前，Lhotse與Hermes系統共享集羣，如下圖所示，在Gaia中通過樹形隊列來抽象租戶層次：Lhotse與Hermes作爲頂級租戶，根據它們不同的資源需求(Lhotse偏向CPU密集，Hermes偏向memory密集)按比例瓜分集羣資源。在Lhotse租戶內部，Base租戶與Runner租戶根據同樣的調配邏輯來瓜分Lhotse的資源。這種層級化的多租戶資源調配，既實現了資源的最大化利用，也保證了資源共享的公平性、可控性。
容錯
如前文所言，Lhotse的Runner多達68種，任何一個Runner出錯，都有可能影響大批的調度任務。因此，對於每個Runner的監控及出錯處理至關重要。
以前，Lhotse通過自定義腳本來監控Runner進程，在發現錯誤的情況下自動重啓或拉起。這種方式存在兩點弊端：一是監控腳本本身也需要維護；二是隻能做本機重啓，無法跨機重試，對於機器掛掉的情況無能爲力。
現在，藉助Gaia雲的自動容錯機制，Lhotse從單機容錯上升爲集羣容錯，主要體現在兩個層面：
自動重試，包括本地重試和跨機重試。Gaia雲對於機器宕機、進程異常退出、OutOfMemory等異常都可以做到自動重試告警，且重試次數可以自行設定，本地重試優先於跨機重試。對於有本地上下文信息的Runner，可以設定較高的本地重試次數，以儘量保證效率。
自動屏蔽，即黑名單機制。當機器失敗達到預設的次數，將被推上黑名單，在一定的時間內對調度屏蔽，以儘量降低出錯的影響，且對業務來說是透明的。
灰度升級
爲了保證任務高併發和系統高可用，Lhotse每個Base/Runner應用需要運行多個實例，在Gaia雲中分別由Applicaiton和Instance來抽象：向Gaia提交Application時，可以指定Docker鏡像、Instance個數以及其他相關配置，如下圖表示了一個Runner應用的部署抽象：
在這種部署/運行模型下，對應用做灰度升級非常方便，只需選擇新版本的Docker鏡像，reload待升級的Instance：
既然可以將v1.0的實例reload成v2.0，當然也可以將v2.0的實例reload成v1.0。前者是升級，後者是回退。得益於Docker的鏡像管理特性，應用在Gaia雲中的升級與回退本質上是同類的操作。
擴縮容
按需彈性分配資源是雲計算的核心理念，擴縮容自然成爲雲平臺的標配特性之一。在Gaia雲中，擴縮容一個應用非常方便，只需選擇相應的Docker鏡像與實例個數，rampup待擴縮容的Application：
在實際運維中，Lhotse已經多次通過Gaia來擴容Runner，得益於Docker帶來的快速部署/啓動能力，可以輕鬆實現秒級擴容。
目前，儘管擴縮容過程是自動化執行的，但操作還需要人工進行觸發。實際上，作爲一個任務調度系統，Lhotse任務負載的時間分佈實際上是有規律、可預估的（通過監控數據發現，有相當一部分Runner的任務負載都在某種程度上遵循着二八定律，即有20%的時間處於高峯期，承受成倍於其他時間的負載）。下面兩圖分別展示了兩種Runner連續三天的任務負載分佈，可以看到，負載高峯通常是在凌晨某個時段。
因此，Lhotse擴縮容是可以基於時間/負載等因素來自動觸發的。Gaia雲根據業務系統的需求，正在規劃自動擴縮容的方案，後續Lhotse將保持跟進，第一時間驗證測試。
服務發現
從前文的架構圖上可以看到，Lhotse內部最基本的通訊路徑是——Runner向Base上報心跳。在靜態分配資源時代，Runner通過配置文件寫死IP來發現Base。這種方式在動態分配資源的Gaia雲中顯然是不可行的，需要新的服務發現機制。它要滿足兩個需求：
自動註冊/更新地址——當服務實例發生遷移或者新的服務實例部署時，需要對地址列表做自動更新。
自動負載均衡——當有服務有多個實例時，需要自動將訪問請求分配到某一個實例。
Gaia云爲此採納了基於“Etcd-Confd-HAProxy”的服務發現架構：Etcd作爲服務地址的存儲中心，HAProxy作爲服務訪問的代理(負載均衡)中心，Confd則是連接前兩者的紐帶，實現地址列表的自動更新（具體實現可以參考《構建一個高可用及自動發現的Docker基礎架構-HECD》)。基於這種服務發現機制，Runner發現Base的過程如下圖所示：
總結
本文分享了Lhotse系統接入Gaia雲，實現自動化運維的實踐經驗： 通過部署、調度、擴縮容自動化，釋放了人工運維的壓力；通過容錯、灰度升級、服務發現自動化，避免了重複造輪子。
當然，天下沒有免費的午餐，要享受Gaia雲帶來的自動化，對於老的系統可能會有一定的改造成本。比如，Lhotse在遷移過程中對代碼做了全面梳理，把所有寫死IP的代碼做了改造。不過，Lhotse的經驗表明，這樣的系統改造基本不涉及關鍵模塊（比如數據存儲、組件通訊、任務執行等），工作量相對不大。另外值得一提的是，在接入過程中，Gaia雲根據業務系統的特點不斷地演進平臺特性，儘可能地降低老系統的遷移成本。
作爲第一個抵達風口的“豬”，Lhotse乘風而起，扶搖直上雲端裏，吹響了全民擁抱Docker雲的號角，並且會繼續探索前行，爲大部隊點燈開道。與此同時，我們也期望Gaia雲持續優化完善，提供舒適的雲環境，讓我們沉浸其中、欲罷不能。