阿里巴巴搜索無狀態服務的秒級彈性調度

摘要： 目前阿里巴巴搜索的分散式服務一般都是基於Hippo+Carbon來調度的，包括部署、擴縮容、名字服務註冊。

原文：http://click.aliyun.com/m/44047/

背景

目前阿里巴巴搜索的分散式服務一般都是基於Hippo+Carbon來調度的，包括部署、擴縮容、名字服務註冊。如下圖：

其中：

• Hippo：一層調度（資源調度），解決機器資源分配問題，將一個物理機分成很多資源，根據應用單機不同的資源需求動態創建不同規格的容器(Docker)。一個容器被視作一個Slot。可以參考阿里巴巴搜索混部解密
• Carbon：二層調度（業務調度），基於各種服務狀態決策單機服務是否正常，以決策是否需要自動做機器遷移。同時實現服務的各種運維操作。
• Drogo：業務管控系統，管理由多個二層調度管理的多個業務集群，並封裝成用戶操作的UI及API，作為用戶及三方服務對接的入口。

Hippo + Carbon 的組合，可以簡單理解為Yarn + Slider，或者Cloud Provider + Kubernetes。

這個架構提供了輕量容器的管理、異常機器的自動替換、應用的一鍵部署，包攬了用戶日常的所有運維操作，達到了自動化、自助化的運維效果。但是對於服務容量來說，它不是彈性的。彈性的服務調度，主要解決服務容量自動化擴縮問題。

彈性調度

在目標服務流量上漲時，服務各種指標(例如CPU)上漲，導致服務質量下降。彈性調度自動發現這種情況，並做出擴容請求。相反，在服務流量較低時，彈性調度能夠自動縮容，讓服務始終保持在一個健康且不浪費的容量狀態。

彈性調度在實現上包含以下部分：

• 指標的透出：無論是服務主動彙報還是被動收集，需要有metric系統持有服務的實時指標。
• 決策：決策系統是整個彈性調度的大腦，決策演算法需要的數據(如metrics)需要各個系統透出，並決策出擴縮容的目標，然後提交給「執行」系統
• 執行：執行系統真正地去完成決策目標，例如擴縮容，也可能是動態改變單容器資源

對應到搜索中無數據服務的彈性調度，如圖：

原有方案：基於Carbon調度

無論是基於什麼調度器來調度應用服務，流程上目前是相差無幾的。2017年雙11 SP服務是基於Carbon來調度的。整體的結構如下圖：

上圖中：

• 一個服務就是一個Role，服務下有多個instance，本質上是一個Hippo Slot
• 一個Slot由動態創建的容器、容器中的包(鏡像)、進程構成
• Drogo 引導用戶將服務的部署plan提交給Carbon
• Carbon 對服務做穩定性調度，確保服務的instance健康可服務；一個Carbon可以調度若干個Role
• Hippo 提供Slot的管理，提供拉起Slot的能力 (拉包、啟動進程及守護)
• Carbon 向Hippo請求及歸還Slot
• Decision 是讓整個服務動態化(動態擴縮容)的決策大腦，決策的依據是服務instance的各種指標(主要還是CPU)，決策的結果提交給Drogo
• Kmonitor 收集服務各個Slot的各種指標，並提供統一的數據查詢

在整個系統中主要有兩個問題：

• Decision決策擴容時，擴容速度達不到秒級
• Decision的決策在面臨複雜業務服務時，不夠智能

第一個問題中，擴容的速度受很多方面的影響，需要針對每個問題進行優化：

對於第二個問題，我們準備與演算法團隊合作，讓專業的人做專業的事。接下來講講圍繞Fiber調度器的彈性調度。

新的方案：基於Fiber調度

Fiber是一個同Carbon相同角色的調度器。Fiber服務本身只能解彈性調度執行的問題。基於Fiber，我們優化了整個系統的各個部分。

Fiber

在Fiber調度中，我們整個系統演化成下圖：

在Fiber中增加了一個Slot Buffer，用作調度過程中向Hippo申請分配及歸還Slot的一個中間緩衝。前面提到一個Slot從無到有是有代價的，而Slot Buffer的提出，則是讓Slot提前準備好，Role的擴容請求只是在Fiber進程內改變下Slot的數據結構歸屬關係。但是Buffer本質上還是存在浪費資源的嫌疑，佔用了整個Hippo集群的公共資源。因此，在Fiber中我們預期的使用方式：

• 若干個Role共用同一個Buffer，整個系統的調度是努力在多個服務(Role)間取得資源的最高性價比使用。這也是Decision需要升級的地方。
• 共用同一個Buffer意味著多個服務具有相同的服務啟動Plan，服務之間的差異性(一般就是業務數據)需要調度器與應用之間確定一個新的交互協議，也就是服務需要由調度器驅動來熱載入業務數據。

針對第二點，Fiber調度器中相應發生了些變化：

• Slot的構成，在進程之上增加了app data，稱為業務數據。進程最好能支持熱載入業務數據(熱載入更快)。舉個例子，一個支持servlet的web容器(如tomat)是一個進程，各個servlet的包就是業務數據，希望在tomcat中可以熱載入不同的servlet。這樣就可以省掉tomcat的啟動時間。
• Fiber需要在某個Slot從Buffer中重新分配給新的Role時，及時通知更新hot plan。為了實現的容錯性，我們實現為類似Carbon中設置Slot啟動Plan一樣的目標式方式，自然地也需要支持rolling、甚至最小可用度保證等功能。

總結下來可以看出，在Carbon中某個服務的啟動/更新是Carbon與Hippo協作的結果；而在Fiber中，還包括了Fiber與服務之間的協作。理想中Fiber的使用方式，舉個tomcat載入web .war包的例子：

• buffer中提前準備好了很多已經運行的tomcat進程，整體上就是很多Slot
• 業務方A需要部署服務A，提供了自己開發的業務.war包，提交到Fiber中
• Fiber從Buffer拿出指定數量的Slot，並通知這些Slot上的tomcat進程熱載入用戶的.war包
• Decision發現服務A負載較高，發出擴容請求
• Fiber從Buffer拿出更多Slot，並熱載入.war包
• Buffer容量不足，從Hippo集群補充冷Slot，並準備好Slot (拉包、啟動容器、啟動tomcat)
• Decision發現服務A負載過低，發出縮容請求
• Fiber歸還Slot到Buffer，Buffer過大則歸還部分Slot回Hippo

Decision

Decision的改進主要是站在決策服務的角度，把服務框架化，能夠讓演算法同學比較容易地參與進來。Decision的主要挑戰還是在演算法上。在基於Carbon的決策系統中，決策的參照還只是單個服務(Role)的數據。而在基於Fiber的系統中，Decision在決策某個服務擴縮容情況時，還需要參考其他服務的負載情況。例如，在資源緊缺的情況下，Decision需要優先保障高優先順序的服務A，那麼就需要犧牲低優先順序的服務的可服務性，調配資源過來。

應用及成果

今年雙11 基於Fiber的彈性調度主要在TPP上應用。雙11當天過了0點高峰後全天開啟，擴縮容次數超過萬次，調度的Role上百個。

TPP單機房所有Role (主要用作TPP場景的物理隔離) 都在一個Fiber調度器中調度。TPP對Fiber中的app data應用得比較輕量，僅僅是一個集群標識，用於某個從Buffer中拿出來的Slot被分配到某個Role時，可以正確地將該Slot同步到名字服務中。Fiber中除掉app data的調度外，最主要的是解決了Slot Buffer的問題。但影響擴容速度的還有很大一部分取決於服務的預熱，尤其是TPP這種Java應用。

Fiber目前並沒有解決服務預熱的問題。所以預熱的控制完全交給了TPP自己。目前TPP針對容量大的Role(通常也是優先順序高的業務)，會定時對Buffer中的Slot做預熱，以保障這些Role拿到的Slot可以儘可能快地對外服務。而其他Role則是在Slot交給Role時進行預熱。關於TPP的資源隔離，可以參考TPP多租戶隔離之資源清理 以及TPP穩定性之場景隔離和多租戶

在整個鏈路中，總結下來，為了提高擴容的響應速度，除了Fiber的實現外，還包括：

• TPP管控系統中對Buffer Slot的預熱
• TPP Glaucus啟動中對預熱的支持，以及服務的穩定性，避免新Slot接流量時出現毛刺
• 為了Decision獲得快速的決策效果，metric系統Kmonitor也做了不少優化，將metric的實時性提高到了5s精度
• Decision 中的演算法部分為了貼合TPP各種複雜的場景，例如突增流量，做了不少貼近TPP特點的優化。
• 演算法部分在Decision框架中，由Kmon Watch驅動以5s一次的頻率進行決策 (metric精度是5s)

雙11當天Decision決策出的擴縮容中，擴容速度整體上可以達到20秒：

• metric的實時性5秒
• 分配到進程運行的Slot消耗5秒
• 預熱時間分兩種情況
• 在Buffer中被預熱：Slot拿出來後到可提供服務消耗10s
• 未在Buffer預熱：預熱時間50s (跟蹤樣本)

未來

基於Fiber的彈性調度，在2017年的雙11與TPP合作上，更多的是一次大膽的嘗試，離我們理想中的秒級彈性調度還有很大差距。在未來我們還有很多需要突破的地方，例如：

• Fiber 對app data的管理形成閉環，從部署到名字服務同步，到物理Role的遷移等有自己的體系，而不是部分依賴於Role的管理
• Fiber 中對Buffer的管理能夠適應更多的需求，例如Buffer Slot的健康、Buffer的資源分級
• 進一步地能否降低Buffer的大小依賴，讓其只是一個Slot緩衝帶(較小的size)，而不是Slot池
• Drogo對Fiber的接入及運維包裝，讓應用接入更容易；在servless方向做嘗試
• Decision 在演算法模型方面能夠更統一地處理相似服務的決策，摒除掉各種特殊情況的處理
• SP不存在預熱問題，配合運維繫統的完善遷移上來實現<10s級的擴容調度
• TPP在Java服務方面的預熱能否發生質變
• 藉助於集團的存儲計算分離，也許能支持部分有狀態服務

參考

• 關於Decision的演算法實現，決策的大腦，參考 [阿里百萬級QPS資源調度系統揭秘
  ]
• 關於TPP在擴容過程中如何用降級等手段減小對外服務的異常率，參考TPP多租戶隔離之資源清理 以及TPP穩定性之場景隔離和多租戶

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎