微博平臺穩定性體系介紹
目錄介紹
1. 微博平臺業務介紹
2. 穩定性體系-整體方案介紹
3. 穩定性體系- 架構方案詳細介紹
4. 穩定性體系- 監控體系詳細介紹
5. 穩定性體系- 容量評估
6. 穩定性體系- 干預方式
隨著微博業務的快速發展，微博平臺的穩定性建設也越來越完善，應對線上突發問題的能力也越來越強。
1. 微博平臺業務介紹
微博平臺組負責微博的feed，評論，贊等核心業務的后臺接口開發和維護，系統的主要特點如下：
- 請求量大
? 日常晚高峰部分接口的qps能達到6w，大部分的接口的qps也在5千以上
- 依賴資源多，任何依賴的資源都有可能down掉
? 依賴MC,Redis,DB,RPC,HTTP,Hbase。僅核心池就依賴90多個MC端口,500多Redis端口,100多個db端口
- 大型運營活動及三節保障：
? 讓紅包飛
? 春晚
- 熱門突發事件：
? 范冰冰李晨的我們
? 周一見
各種各樣的情況需要我們能快速應對。
2. 穩定性體系整體方案介紹
3 . 架構體系詳細介紹
- 無單點設計
? 調用鏈路無單點
前端，隊列機，rpc 無狀態服務，可線性擴容
? 資源層分層設計
MC,Redis,DB 主從設計，其中mc 有三層設計：Master slave保障高可用，L1用來抗帶寬
- 自保護，防雪崩
? Tomcat 前端機
? RPC
? Fail Fast
? MC,Redis,DB,Hbase,Motan RPC 在后端資源出問題時可以自動降級請求調用
- Localcache 應對極熱的push數據
- 服務隔離
? 邏輯隔離， 拆分核心池，非核心池。防止非核心服務影響核心服務。
4 . 監控體系詳細介紹
此處的監控是業務層的監控，不包括運維層的監控。監控體系的基礎是日志體系，日志體系主要包括：
? 請求日志
記錄用戶的請求參數， 4xx 、 5xx 數量，平均耗時等，包括nginx層，tomcat層，業務層
? Trace 日志
通過 requestId 串聯所有的日志，用于定位分析問題
? 性能統計日志
包括 qps ，平均耗時， slow count ，耗時區間
? 分步耗時日志
分析定位哪一步性能差
? 線程池日志
監控體系主要包括：
【實時報警】：
? 實時監控接口健康狀況，變為紅色表示問題已經很嚴重。
? 可查看哪臺服務器有問題。
【監控類】：
1.【qps監控】
? 判斷是否流量突增導致容量不足
? 判斷是否單機房問題
2. 【平均耗時監控】
監控接口性能是否存在問題
3. 【4xx,5xx監控】
判斷接口是否存在異常
【問題定位類】：
1.【單機slow top】之前需要掃描nginx才能定位是否是單機問題，通過此監控，快速判斷是否單機問題。
2.【依賴資源整體slow 】
通過此監控，快速判斷哪類資源有問題
3.【具體資源slow top 5】
每種資源對應的端口或接口很多，
對具體資源進行慢請求的top5分析，可以快速找出具體哪些端口或接口有問題
4.【分步耗時】
某個接口中每一步的耗時情況，便于排查問題
5. 容量評估
壓測方式 ：
? 單機壓測
- tcpcopy線上引流：多臺引一臺或放大流量倍數
- 調整nginx權重
? 服務池壓測
- 機房間流量切換
- 線上逐步503服務器從nginx摘除
? 資源容災壓測
- touchstone:基于tc（延遲）和iptable（封禁）
評估結果
? 單機能承載的最大qps
? 服務池能承載的最大qps
? 水位預警
6 . 干預方式
降級
? 接口降級
整個接口降級
接口及參數匹配
? 非核心路徑降級
? 依賴資源降級
mc、redis、db、http、mcq
封殺
? uid
? appkey
? ip
切流量
? DNS層
? Nginx層
動態擴容：基于docker和 阿里云的動態擴容方式可以實現10分鐘擴容上百臺前端機的能力，期待春晚依賴混合云順利度過流量高峰。
來自：http://weibo.com/p/1001603939610718766471
來自：http://weibo.com/p/1001603939610718766471
本文由用戶 碼頭工人 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！