模型剖析 | 如何解決業務運維的四大難題？

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由 織雲平臺團隊 發表於 雲+社區專欄

前言

做爲業務運維，你是否常常會碰到這樣的問題：

1. 新業務上線，開發同窗會對服務作性能測試，可是換一種機型後的性能如何？服務版本更新後性能是否發生變化？

2. 節假日即將到來，某個業務預估用戶活躍度提高2倍，但假日結束後只上升了0.5倍，提早擴容的資源白白浪費，如何解決？不一樣活動影響不一樣服務模塊集羣，如何分析？

3. 某個業務下掛靠的服務模塊幾百個，如何分析出核心模塊和旁路模塊？

4. 多地分佈的業務，如何規劃？

帶着這些問題，咱們來看一下騰訊SNG運維是如何經過業務畫像來解決的。

經過分析模塊性能數據（CPU，內存，IO等）、路由關係（上下游訪問關係）、抓包關係（更底層的訪問關係）、活動指標（節假日和壓測演習帶來的下游模塊增加）得出業務畫像。

業務畫像類型

業務畫像包含了幾個模型，用來解決上面的四個問題：

1. 容量模型：經過自動化壓測不一樣配置，不一樣版本的TPS和其餘性能瓶頸。發現異常，推進性能優化，數據

2. 活動模型：分析業務歷史活動和關聯模塊的變化趨勢，評估將來活動的變化趨勢，解放人力，優化成本。

3. 鏈路核心視圖：根據不一樣業務場景過濾出核心鏈路訪問關係圖，可用於告警收斂，根因分析，架構優化。

4. SET規劃：業務條帶化，多地分佈，快速調度能力。

新業務上線，開發同窗會對服務作性能測試，可是換一種機型後的性能如何？服務版本更新後性能是否發生變化？

容量畫像：經過自動化壓測系統，壓測出服務在不一樣機型、不一樣版本的TPS閾值。經過閾值基準來自動化管理容量。基於TPS的容量管理相比傳統的基於單機性能（CPU、內存等）的容量管理更精細。

舉個很常見的例子，基於運維經驗，單機CPU使用率超過80%時，咱們會認爲這臺機器的負載很高，服務已經有超時的風險了，因此咱們通常會在單機CPU使用率達到70%左右就開始擴容。

可是，實際上有不少服務在CPU使用率30%左右就已經出現大量超時，具體緣由此文不細說。若是仍是按傳統的CPU使用率來評估，業務早已受影響。

TPS容量模型則很好的避免了這個問題，不一樣機型承載的TPS都有一個壓測閾值，只須要評估當前模塊下的TPS總量（服務框架自動上報），超過TPS閾值才觸發擴容。擴容的設備量也是基於不一樣機型的TPS標準來自動評估。

支持自動上報TPS數據的標準服務框架咱們使用TPS模型，剩餘非標準框架，也可經過壓測找出性能瓶頸，只是瓶頸指標從TPS變成了CPU/流量/或服務主被調次數。

節假日即將到來，某個業務預估用戶活躍度提高2倍，但假日結束後只上升了0.5倍，提早擴容的資源白白浪費，如何解決？不一樣活動影響不一樣服務模塊集羣，如何分析？

活動畫像：每一個核心鏈路視圖在每一個活動週期內的容量增加幅度，都會被記錄在活動模型內，用於評估後續活動的增加服務。

能夠看到，某次活動帶來的活躍用戶數增加，不一樣模塊的流量和CPU增加幅度都是不同的。

活動模型會將每一次活動用戶增加幅度和下游模塊的流量、CPU、TPS增加幅度都保存下來用於支撐後續活動關聯模塊的容量評估。

介紹一個基於活動模型評估活動容量的基礎模型：

活動關聯模塊，經過活動過程當中產品指標和模塊流量變化幅度分析得出

歷史增加幅度：模塊過去12個月活動對應產品指標的變化趨勢

容量指標增加幅度：TPS、流量、CPU絕對使用核心數三個指標在活動期間的增加幅度。

CPU的評估專門提一下，容量增加幅度須要計算某個指標的絕對值，因此CPU的維度咱們把CPU的使用率量化成了CPU絕對核心數。好比一個模塊包含了N種機型，每種機型的CPU使用率都不同，咱們會這樣算：

CPU_total_core=n∑1=A1_coreA1_CPU_average+...+An_coreAn_CPU_average

結合上述三個維度，能夠預估出最近一次活動對應模塊的容量增加幅度，容量託管後臺可根據容量預估結果制定不一樣的擴縮容或調度方案。

每一次活動評估結束後，須要對比現網真實數據和評估結果。差別超過20%的模塊會被要求作二次分析，增長更多高級維度優化評估模型。好比模塊業務場景維度，某些離線場景，咱們會單獨打標，使用專門的算法進行評估。

*某個業務下掛靠的服務模塊幾百個，如何分析出核心模塊和旁路模塊？*

核心鏈路視圖

業界流行的鏈路視圖方案是google dapper模型。可是體量龐大的社平業務由於歷史緣由，短時間內將全部業務都增長上報各類鏈路節點信息是不現實的。

因而咱們採用另一種方法來實現核心鏈路視圖的繪製：根據路由、抓包、主被調關係梳理出接入->邏輯->存儲三層的完整調用關係鏈路。結合不一樣的場景，在完整關係鏈的基礎上根據服務主被調次數，出入包量等指標作進一步過濾。最終得出業務核心關係鏈。

未經處理過的業務鏈路視圖看起來是這樣的：

通過抓包數量、主被調次數過濾後的核心業務鏈路視圖是這樣的：

核心鏈路視圖能夠用於告警關聯分析，根因分析，活動實時大盤視圖等業務場景。

*多地分佈的業務，如何規劃？*

SET規劃

對於一些要求高可用低延遲的業務就能夠經過業務畫像來實現業務多地分佈了。

SET畫像包含了：

1. 可視化視圖：業務核心鏈路

2. 多地數據同步策略：這是SET畫像的核心能力，對於多地分佈的業務，難點就是如何實現多地數據一致。社交類業務形態主要是多讀少些，咱們使用單點寫，多點讀的策略規劃多地分佈架構。如圖：全部的寫請求都收歸到深圳（因寫入量相對少，跨地域訪問的延時用戶並沒有明顯感知），深圳存儲的數據經過同步中心同步到其餘地域。全部的讀請求都讀本地存儲。

3. 可度量指標：核心業務指標（好比承載多少用戶，上傳多少張圖片等）、達到對應指標時各模塊的容量等維度。

拿空間業務舉例：

業務目前主要分佈在深圳、上海、天津三地，每一個地域能夠承載各1/3的用戶接入，每一個地域的SET容量維持在50%，當一地故障時，另外兩地能夠分別承載25%的用戶。

根據核心鏈路內模塊的不一樣功能分類，劃分不一樣子功能SET。

根據同地域不一樣機房分類，劃分不一樣子機房SET。

下圖是空間基於SET畫像的業務架構示例：用戶經過手Q接入，在空間上層接入獲取用戶的讀寫操做，將讀請求路由到本地，寫請求路由到深圳SET。底層數據經過同步中心經過到異地。進而實現了空間的多地分佈。

隨着後端服務的不斷迭代，SET核心指標也會不斷變化，咱們經過按期的SET調度演習來保證SET畫像的準確性。演習過程當中咱們能夠找出SET內瓶頸模塊，提早修正模塊容量。

SET建調度的流量變化：

結語

業務畫像的目的是將多年運維經驗的沉澱成模型，自動化解決運維問題。

容量模型提供基礎支撐數據到容量託管平臺，上百個模塊全自動擴縮容，容量穩定保持在45%左右。

活動模型智能預估業務活動期間各核心模塊的容量變化趨勢，提供預估結論到資源池，自動完成模塊活動前擴容，活動後縮容，節約大量人力，預估準確率80%。

核心鏈路視圖解決了社平業務複雜架構模型自動化梳理，目前統一告警ROOT平臺使用核心鏈路視圖作告警收斂以及根因分析。業務上雲過程當中，也會使用鏈路視圖分析優化業務架構。

SET規劃則主要解決了業務多地分佈，持續保證業務高可用。業務多地分佈，經歷了天津機房爆炸，深圳光纜被挖斷等大規模故障的檢驗。

業務畫像隨着業務的海量和多樣化也在不斷變化，同時也會根據運維需求沉澱出更多的業務畫像。在處理平常的運維困難中，須要不斷積累，多多關注業務的需求，善於總結。但願這些可以給你們帶來一些啓發。

問答

Angular2如何處理http響應？

相關閱讀

HTTP/2之服務器推送(Server Push)最佳實踐

如何備份你的MySQL數據庫

MySQL 8.0 版本功能變動介紹

雲學院 · 課程推薦 | 騰訊高級工程師，帶你快速入門機器學習

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/dev...

搜索關注公衆號「雲加社區」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社區！