作者| 阿里文娛高級開發工程師 金呈
出品 | CSDN（ID：CSDNnews）
概述
1. 背景
隨著業務形態發展，更多的生產力集中到業務創新，這背後要求研發能力的不斷升級。阿里文娛持續傾向用更加高效、穩定、低成本的方式支持快速軟件交付，保障高可用。於是運維力從 “HaaS”（Handwork as a Service）到“PaaS”再到“SaaS”（System as a Service），運維生產力從 Ops 到 DevOps 再到 NoOps。
在傳統應用容量管理模式下，應用、集群容量評估缺乏有效數據依據與支撐，往往犧牲效率或成本來平衡經驗決策風險，另一方面，人肉決策和執行難以滿足業務對穩定性和效能的追求。因此，阿里文娛急需一個能夠把優酷所有應用的容量管理起來的能力。
2. 目標
整體目標分成 2 個階段，一是摸清各應用容量水平，二是為所有應用賦予彈性伸縮的能力， 最終直觀看到各應用及總體資源使用率的明顯提升。
技術挑戰與解法
1. 單機性能
既然談到容量問題，已知的壓測方案有鏈路壓測方案、模擬流量壓測方案等。為什麼還要 自研一套基於單機引流的壓測方案來評估應用容量水平？
1）更接近日常真實水平；
2）無人工決策，純機器決策單機性能瓶頸；
3）全自動，比如配置成發佈結束後進行單機性能壓測。
2. 彈性
彈性指標選擇：僅靠集群 CPU 水位彈性確實可以解決絕大多數類型應用，但若基於集群QPS 水位則可更精準的進行彈性伸縮。
1）多維度彈性指標，同時也需要支持自定義指標；
2）多方位彈性方案，使用條件編排策略來達到多個彈性指標之間的協同。
技術方案
1. 全自動單機性能探索
與各接入層對接，自動配置權重完成單機引流，配合性能拐點算法支撐，完成自動識別性 能拐點並終止壓測，最後一併記錄單機能力值。並允許每天定時壓測、發佈結束壓測來感知每 天、或每次發佈給單機性能帶來的變化，使用戶更親近自身應用的容量水平。
2. 彈性伸縮
與底層交付系統聯動，打造從規劃，交付，計費，彈性水平擴展、回收、資源排布調度全 生命態面向業務需求的自驅動統籌調度資源管理系統。一方面，業務資源統一平臺構建與維護， 挖掘空閒資源，共享彈性計算力，整體提高部署密度，降低業務單位成本；另一方面，面向不 同應用場景，自動化容量管理，按需分配，保證應用服務可用性，提高容量運維效能。
3. 方案結合
全自動單機性能探索與彈性伸縮的結合框架，如下圖：
1）應用接入：無縫接入；
2）單機性能壓測自定義配置：無需再定義配置過多配置，默認“智能探索”可以支持大部分 場景；
3）單機引流：從集群中其他機器的流量引流至被壓測機器；
4）智能拐點識別：使用時間序列數據趨勢轉折點提取算法，進行拐點識別；
5）單機性能預測：詳見技術細節；
6）基礎彈性配置：詳見技術細節。
技術細節
1. 單機引流權重優化
1）調整權重就是調整單機流量，且權重越高，單機流量越高；
2）增加自動化調整權重策略方法。權重優化：用於已經識別出拐點，保證下一次壓測接近 MAX 權重保持平緩；權重遞增：用於未觸發拐點，保證下一次壓測能引更多的流量。
2. 響應時間拐點識別
使用算法：箱線圖。基於 IQR 定製多組 k 的箱線圖上限的異常提取，上限=Q3+k*IQR 實現。而效果能夠定位到多數拐點，並且一般拐點前的一個時間點的值為單機能力值。
3. 成功率拐點識別
0 錯誤代表 100%成功率
成功率拐點識別相比響應時間拐點識別更加嚴格。雖然同樣是“基於 IQR 定製多組 k 的箱 線圖”實現，但此時 k 必須收緊，因為成功率指標較為敏感，稍有波動就應該終止壓測。
4. 拐點提取參考了“時間序列數據趨勢轉折點提取算法”文章
比如在 3 個連續點 Xi、Xi+1、Xi+2 的判定上，它們的發展趨勢共有 9 種情況：當 Xi+2-Xi>0， 即圖 a，b，e 這 3 種情況屬於總體趨勢上升，當 Xi+2-Xi<0，即圖 f，g，i 這 3 種情況屬於總體 趨勢下降，當 Xi+2-Xi=0，即圖 c，d，h 這 3 種情況屬於總體保持不變。
而我們通過“基於 IQR 定製多組 k 的箱線圖”可以識別出上升和下降 2 種拐點，分別對應 不同的場景，如響應時間拐點識別（上升拐點識別），成功率拐點識別（下降拐點識別），而 k 的定義方式也參考近期數據。
比如某個應用日常響應時間穩定在 100-200ms 和某個應用日常響應時間穩定在 2-3ms 的 k值是不一樣的，不合適的 k 用在 2-3ms 的這種數據上會導致異常識別較為頻繁及不準確。
5. 單機性能預測方案
單機性能與什麼有關，系統指標？如果是 JAVA 應用還和 JVM 相關指標有關？而應用本身 有會有各種池的限制，如 JVM 相關池、TOMCAT 相關池、DB 相關池、Redis 相關池、隊列相 關池等，這些都可以作為預測單機性能的特徵。先基於 PCA 抽象出 N 個特徵，也稱降維，可 將兩兩線性相關的因素進行整合或排出，降維後建立線性迴歸模型，而擬合度較高的模型將予 以採納並進行預測。同時預測參數也需要實事求是，比如日常 CPU 區間為 2-60%，那預測參數 可以為 80%，此時若超過 100%那將毫無意義。
6. 流量驅動彈性方案
基於 CPU 指標的彈性伸縮：比如 CPU 超過 60%則執行彈性擴容，CPU 低於 20%則執行彈 性縮容。擴容與縮容允許按機器數比例進行伸縮：如按 5%的機器數進行彈性擴容。定義彈性區 間：如 10-20，機器數會在 10-20 區間變動。
一般低峰期會處在最低機器數區域，高峰則會處在最高機器數區域，基於外掛單機能力模 型。允許基於 QPS 水位指標進行彈性，可隨 QPS 增加而增加機器數，反之則減少機器數。
總結
自動化容量管理與彈性伸縮的深度結合解決了當前容量預估的問題，使得資源能夠被合理使用。一方面，用戶專注業務層，做基於業務需求的容量規劃、交付和維護，革命性改變生產關係，提高研發迭代效率；另一方面，更加細粒度的彈性伸縮，比如小時、分鐘的資源的快速流轉，資源粒度分解到具體硬件計算垂直伸縮，也是一種更優的解決方案，使得彈性更加迅速能做到秒級能力，進一步壓縮集群密度，降低單位成本。
☞“谷歌殺手”發明者，科學天才 Wolfram
☞漫畫：“哈夫曼編碼” 是什麼鬼？
☞數據庫激盪40年，深入解析PostgreSQL、NewSQL演進歷程
☞黑客用上機器學習你慌不慌？這7種竊取數據的新手段快來認識一下！
☞超詳細！一文告訴你SparkStreaming如何整合Kafka！附代碼可實踐
☞Libra的Move語言初探，10行代碼實現你第一個智能合約
閱讀更多 CSDN 的文章
