模型剖析 | 如何解决业务运维的四大难题？
歡迎大家前往騰訊云+社區，獲取更多騰訊海量技術實踐干貨哦~
本文由織云平臺團隊 發表于云+社區專欄
前言
作為業務運維，你是否經常會碰到這樣的問題：
新業務上線，開發同學會對服務做性能測試，但是換一種機型后的性能如何？服務版本更新后性能是否發生變化？
節假日即將到來，某個業務預估用戶活躍度提升2倍，但假日結束后只上升了0.5倍，提前擴容的資源白白浪費，如何解決？不同活動影響不同服務模塊集群，如何分析？
某個業務下掛靠的服務模塊幾百個，如何分析出核心模塊和旁路模塊？
多地分布的業務，如何規劃？
帶著這些問題，我們來看一下騰訊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畫像包含了：
可視化視圖：業務核心鏈路
多地數據同步策略：這是SET畫像的核心能力，對于多地分布的業務，難點就是如何實現多地數據一致。社交類業務形態主要是多讀少些，我們使用單點寫，多點讀的策略規劃多地分布架構。如圖：所有的寫請求都收歸到深圳（因寫入量相對少，跨地域訪問的延時用戶并無明顯感知），深圳存儲的數據通過同步中心同步到其他地域。所有的讀請求都讀本地存儲。
拿空間業務舉例：
業務目前主要分布在深圳、上海、天津三地，每個地域可以承載各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 版本功能變更介紹
云學院 · 課程推薦 | 騰訊高級工程師，帶你快速入門機器學習
此文已由作者授權騰訊云+社區發布，原文鏈接：cloud.tencent.com/developer/a…
搜索關注公眾號「云加社區」，第一時間獲取技術干貨，關注后回復1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在云加社區！
總結
以上是生活随笔為你收集整理的模型剖析 | 如何解决业务运维的四大难题？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： websocket学习和群聊实现
- 下一篇： 【BZOJ 1877】 [SDOI200