導讀：本文主要介紹百度搜索架構團隊在服務算力管理方向的工程實踐和相關經驗，涉及服務與容器算力的“時間”“空間”話題。
算力管理的核心目標，是實現算力需求與算力資源的最優匹配。搜索服務算力管理的發展經歷了以下3個階段：
2014年以前，搜索服務模塊都是直接部署在物理機上。這時物理機的CPU、內存、SSD等大小相對統一，個別空閒的機器會手工選擇一些模塊進行混部；夜間用戶流量低峯時候，會有BVC這樣離線計算框架，支持離在線任務混部，實現資源充分利用。
2014年～2018年間，搜索業務自研的PaaS實現了服務的半自動化的混部。半自動化體現於：混部策略由人工設計，執行過程爲命令式，容量管理由人工維護。這個階段，業務有項目上線，需要詢問容量專員，某些模塊的算力資源是否還有空閒，是否可以支持該項目消耗。對於大型項目，我們自研了全鏈路壓測技術，支持精確容量壓測，確保不出現系統級瓶頸。
2018年之後，搜索業務將服務託管至公司雲平臺上，利用雲平臺對服務進行自動伸縮、自動混部。業務上線前，不再需要詢問容量專員，直接在雲平臺提交擴容申請即可。這期間，我們把更重要的流量匹配到計算得更快的容器上，實現速度與成本兼顧。
搜索服務算力質量治理體系，分爲兩大部分：技術架構和運營體系。
充分依託彈性容器實例、智能監控、Service Mesh等公司雲平臺提供的技術產品，實現quota的智能管理，達到算力需求與資源更好的匹配。
成立委員會制度，通過委員會驅動成本和速度相關的優化、運作業務項目預算審批流程，在全局維度實現開源節流。
在用戶產品服務中，用戶流量是潮汐波動的，夜間用戶流量少了，利用率下降出現資源閒置，這時需要用雲的思想重新考慮這個問題。
雲原生應用12要素中提到“通過進程模式進行擴展”，意思是我們雲上的服務不應該是單點，而是由很多副本實例組成。低峯期並非利用率下降，而是需要的實例數減少了。所以，通過在夜間對實例縮容、白天高峯到來前擴容的潮汐方式，可以實現夜間賬單的下降。
雲平臺的本質之一是市場化：夜間供給大於需求時，容器單價下降，例如網約車價格。搜索業務基於cache技術進行內容失效預測，可提前在夜間算力更廉價時啓動計算任務，用戶在次日高峯期可獲得相對較新的結果。這是通過計算任務時間窗口遷移，實現整體資源賬單的優化。
在相同的時間點，通過對整個搜索服務集羣的計算任務分類，也存在可以挖掘優化的空間。具體任務類型包括：近線任務、異步任務、同步任務。
在線計算需要控制複雜度以保障較低的響應延遲，我們可以把複雜計算後的“好結果”寫入近線存儲或者cache中，當用戶在線查詢相關請求時候，就可以得到更好的結果反饋。這個best effect方式，並不需要容器有特別高的穩定性，可以採用更廉價的可搶佔式容器，來提供近線算力資源。
應用cache可以加速服務響應、降低cache後端資源成本。完整的cache時效性可以分爲三個級別：失效時立即更新；失效前在夜間提前更新；失效時立即發起更新，但不把更新結果同步用戶，異步更新給cache。在第三種場景下，需要保證計算的效果，又不需立即返回，則可選用穩定性稍好、處理速度稍慢的容器。
同步計算任務，需要立即計算結果並將結果返回給用戶。例如搜索業務的索引服務，大部分是用分片方式提供服務的。但在大規模分佈式場景下，分片多少會存在計算長尾，長尾分片可能索引了更復雜的文檔，或是文檔數量比平均值稍高。對於長尾分片，可以購買穩定性更好、速度更快、quota更大的容器；對於普通分片，計算複雜度相對較低，可購買quota相對較少的容器。實現容器的差異化採購。
容器規格的設置需要考慮很多因素。在搜索服務中，計算任務存在大量內存訪問，減少實例數可以降低內存複製成本，同時單容器流量增加，帶來內存訪問壓力增大，對性能影響是非線性的，傳統模式下需要通過大量線下測試來觀察。在雲原生系統中，依託雲原生監控機制，將模塊的流量、響應時間、資源使用量關係充分關聯，通過大規模樣本聚合分析，可以得到更具統計意義的性能曲線。
性能曲線可以得到服務的基本性能模式，根據服務的任務類型（近線、異步、同步等）運行不同的quota管理策略，預測未來一段時間服務的理想資源quota，最後產出伸縮事件，觸發PaaS進行調整。
性能優化項目上線後，會通過縮容釋放資源。傳統的方法，因線上穩定性要求，縮容需分批多次進行，效率低，且縮容到優化邊界時偏於保守，優化的成果不能充分釋放。在雲上使用新方法，即基於Service Mesh的能力，將縮容改爲切流，創建一個更小的調度集合，通過mesh切換和調度，大幅度縮短觀察週期和修復耗時，可以更充分地把優化成果釋放出來。
我們考慮這樣一個場景，如下trace圖，某個服務並行訪問A、B兩個下游，A的響應時間更長一些，所以提升A的性能可以縮短上層服務時間。但如果B中更快的容器（綠色）比A更多，則系統整體性能就不是最優的。這是通過增加A的快速容器讓A算得更快，可以縮短整體響應時間。
容器運行相同計算任務的速度，受宿主機硬件性能和硬件狀態影響。根據宿主機的硬件性能對容器運行計算任務的速度進行劃分，我們定義爲靜態分檔；根據容器宿主機的硬件狀態對容器運行計算任務的速度進行劃分，我們定義爲動態分檔。如下圖所示，部署在相同快速硬件型號上的A1～A4容器，A1容器因宿主機資源較空閒，計算速度更快。
完成分檔後，可通過更精細的流量調度，高效使用不同分檔的容器。我們將服務分爲高速單元和低速單元，高速單元部署在快速容器上，低速單元部署在低速容器上。處理請求時，首先進行流量類型識別，高優流量路由到高速服務單元上，再預估請求的計算複雜度，把更復雜的計算髮送到更快容器上，進一步提升請求的計算速度。
通過cache技術，可以在時間上實現任務計算窗口遷移，從而更好地使用容器。日間高峯期，將請求收集到請求數據中心；在夜間低峯期，預測cache失效的請求發送到請求隊列，經過請求代理重新計算更新cache，降低高峯期的流量。
以上，回顧了搜索服務算力管理的發展歷程，概覽了運營+技術的治理體系，重點介紹了技術架構側的近期業務特色工作，覆蓋時間和空間兩個方面。
時間方面，算力需求潮汐變化，傳統的方法供給按最大值購買。而基於雲原生技術，在低峯期可減少大量無效購買，增加適當購買廉價容器轉移高峯計算量。
空間方面，未經梳理的梳理需求看似雜亂無章，傳統的方法供給同樣是按最大值購買；基於雲原生技術，區分高低優先級的任務，用不同速度的容器來提供服務，可以達到更優的資源配置。
立足雲原生時代，搜索服務算力管理會進一步應用更靈活、更豐富的控制手段，保持對算力需求和資源更優配置的不斷追求。
本文分享自微信公衆號 - 百度開發者中心（baidudev）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
