彈性調度的基本模式

?
?	?

?

方舟的彈性調度希望提供給用戶的不只是一種彈性操作集群資源的能力，而是要對所有用戶的成本和穩定性優化這件事負責。由于目標應用在各方面差異性很大，所涉及的配置項數以千計并且一直處于動態變化狀態，全靠人工進行配置管理非常不現實。

由此，方舟彈性調度提出了一種閉環反饋式的模式（如上圖所示）。彈性調度基礎能力基于應用分組運行情況和不同應用分組的策略配置參數，做出擴縮容決策，并通過方舟的容器操作服務調整集群容器數量；應用分組集群受到集群容器數量變化的影響，會產生不同的表現行為（例如擴容時集群平均CPU使用率會發生變化，服務rt會在一定范圍內下降等）；應用分組的表現在以實時數據提供給彈性決策的同時，也會進行歷史數據的離線存儲（Alimonitor/EagleEye等集團標準監控系統都提供了這樣的數據服務）；自動策略配置會周期性獲取這些歷史數據，并依照一定的算法，對不同的應用分組進行不同的策略配置，從而再次影響到彈性調度策略的決策。

?

這種模式的優越性在于：?

1.具備一定程度的自我進化能力。當應用分組剛剛接入彈性時，其大多數的策略參數都為默認值；而當彈性運行一段時間后，結合自動評估方式，各種參數會得到不斷的修正以達到更好的彈性效果。以服務安全策略為例：服務安全策略在實時決策階段概括起來就是對當前服務rt于服務的sla閾值進行比較，剛剛接入彈性時，服務的sla是基于服務接入彈性前的歷史rt來得到的，一般來說非彈性狀態下服務rt的表現，與彈性狀態下服務rt的表現是有很大的區別的，可能一開始由于服務sla設置得不合理（一般來說是過小），會出現“多擴”的現象，由服務rt違反sla引起的擴容會占到整體擴容原因的大多數。這種現象會被每天定時執行的分析任務捕捉到，判斷出sla設置得不合理，結合最近幾天的運行狀態，重新計算服務sla，由此提高閾值設置的合理性；

?

?
?	?

2.以更高的抽象層次來進行海量參數的配置，以解決普遍問題。還是以服務rt的sla閾值為例，當我們把配置視角關注到一個具體服務時，我們可能會糾結于一個服務它所對應的具體業務邏輯是什么、它涉及的調用鏈路是什么、上游服務對它的容忍性等等細節問題，那么這樣一來，面對菜鳥不同應用提供的成千上萬個服務，逐一配置根本不可能做到（注：每天都會服務會上線和下線，服務的業務邏輯也可能發生變化，配置是需要進行經常性更新的，這無疑使人工配置更加變得不現實）。而自動策略配置邏輯以更高的抽象層次來看待各項參數，對于服務rt，基于一個普遍適用的假設：“服務rt在一天當中的絕大多數時間都是處于合理狀態”，并且通過概率分布計算（服務rt真正的分布情況也可以通過歷史數據統計得到），可以得到一個數學意義上的sla閾值（以正態分布為例，求得一段時間內服務的平均rt和rt分布標準差，即能得到在不同概率下應該設置的閾值）。

?

?

?

?

?

?

如上圖的正態分布曲線，我們如果把閾值定為平均rt + 2個標準差，那么依照概率粗略計算，我們假設一天當中有將近33分鐘服務處于rt過高狀態（1440分鐘 * （1 - 0.9544）/ 2），由此就得到了一個數學上合理的閾值（這部分邏輯只是服務安全策略邏輯的一小部分，具體在后文介紹該策略時具體說明）。這樣一來，對于各式各樣的服務，只要能獲取到它的歷史監控數據，就能自動、快速地得到這個數學上的閾值。

?

?
?	?

彈性調度的架構體系

?

?

?

?

方舟彈性調度的三層決策：

1.第一層是策略決策，策略決策層由多個不同的策略組成，并且支持快速擴展。策略之間邏輯完全隔離，每個策略計算完成后都會獨立輸出動作（擴容、縮容、不變）和數量。為了能夠適應不同應用之間的異構，每個應用分組也可以根據實際情況啟動或關閉不同的策略。

2.第二層是聚合決策，聚合決策收集第一層所有策略的決策結果，并依據聚合規則得到一個合并后的<動作，數量>組。這一層的規則十分簡單：當同時存在擴容和縮容決策結果時，以擴容為準，忽視縮容結果；當存在多個擴容結果時，以擴容數量最多的結果作為最終結果；當存在多個縮容結果時，以縮容數量少的結果作為最終結果。

3.第三層是執行決策，這部分決策主要會考慮到一些規則，最終告訴擴縮容服務：要不要擴縮，要擴縮多少個容器，如果是縮容那么要縮容哪幾個具體容器，如果是擴容那么具體的容器規格、擴容到的機房等。

轉載于:https://www.cnblogs.com/ssyh/p/11048058.html

總結

以上是生活随笔為你收集整理的菜鸟弹性调度系统的架构设计——阅读心得的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。