1. 首頁 > 生活百科 > >

微服務架構體系的深度治理 什么是架構體系？( 五 )

小知識架構體系


3、針對核心服務的異常有專門的一個監控表格 ， 會列出最近發生的核心鏈路服務上的異常 ， 點擊這上面的任何一個異常 ， 也可以進入對應的調用鏈 。
【微服務架構體系的深度治理 什么是架構體系？】以上就是基于動態調用鏈進行線上故障定界定位的常用模式 。
【容量規劃】線上的流量今天漲一點 ， 明天漲一點 ， 如果麻痹大意的話 ， 說不定哪天服務就被沖垮了 ， 所以要對線上的流量時時進行規劃 ， 以做到心里有數 。
容量規劃有兩種形式 ， 一種是容量預估 ， 另一種是性能壓測 。
系統或者服務上線之前 ， 首先要進行容量的預估 ， 一般做法是基于經驗 ， 同時結合對業務的前景預期 ， 先估算出一個總的調用量 ， 比如1億的PV ， 可能會有10%的流量落在購物車服務上 ， 購物車服務就是1000萬的PV ， 一次購物車訪問會產生2次數據庫調用 ， 那么它的關聯數據庫就會有2000萬的一個調用量 ， 這樣 ， 基于圖上從左至右 ， 層層分解之后 ， 就可以獲取到每個服務節點上攤到的訪問量 ， 再結合運維部門的單機容量指標 ， 就可以估算出整個集群需要多少的軟硬件資源 。
系統或者服務一旦上線之后 ， 它的性能就開始處于不斷“劣化”的狀態 ， 上線前預估的指標會越來越不準 ， 這時候就需要通過線上性能壓測來對實時容量進行監控 。 做線上性能壓測也要遵循一定的規律 ， 不是說一上來就做全鏈路壓測 。 同樣是基于上圖中的調用關系 ， 線上性能壓測首先需要在調用鏈的末梢 ， 也就是對數據庫或者緩存先進行壓測 ， 以保證它們不是瓶頸 ， 再對調用數據庫或者緩存的上一級節點進行壓測 ， 再一級一級往上壓測 ， 最終覆蓋整個鏈路 ， 實現全鏈路壓測 。
可見 ， 全鏈路壓測的前提是單點壓測 ， 需要先把單點壓測能力做好 ， 才能做全鏈路壓測 。
在壓測的時候 ， 由于流量是模擬的 ， 數據也是“偽造”的 ， 所以一定要做好隔離 ， 各種各樣的隔離 ， 尤其是數據的隔離 ， 我個人不建議將“染色”的壓測數據和真實的線上業務數據共表存儲 ， 最好將“染色”數據單獨表進行存儲 ， 并通過分表策略進行區隔 。
以上就是性能規劃 ， 包含了容量預估與性能壓測兩大能力 。
【微服務關聯資源的治理】對于線上任何資源 ， 如果只有服務對它進行調用 ， 那么完全可以基于服務對資源的調用日志來分析資源的使用狀況、性能狀況 。
比如 ， 對于數據庫 ， 可以匯總對某個數據庫訪問的所有服務的調用日志 ， 多維統計之后 ， 就能知道數據庫整體被調用狀況 ， 及數據庫中表的調用的分布狀況 ， 每個表的被調用狀況 ， 包括被寫入了多少數據、被刪除了多少數據、被修改了多少數據 ， 每次查詢的調用延時統一匯總之后 ， 推算出每個表的查詢操作的整體表現及相關的慢查詢等等 。
對分布式緩存 ， 也可以匯總所有的讀、寫操作 ， 并計算出讀寫比例 ， 也可以基于每次的調用結果（是否為null、是否異常）匯總出命中率 ， 正常的緩存表現應該是讀多寫少 ， 如果推算出的讀寫比例是讀少寫多 ， 或者命中率偏低 ， 說明緩存的使用策略有問題 ， 需要進行改進 。
對消息隊列也類似 ， 可以通過調用日志 ， 計算出單位時間內寫入的消息量 ， 以及被消費的消息量 ， 據此推算出消息隊列當前的堆積情況 。
通過調用日志獲取的資源的使用及性能狀況 ， 比通過資源自身的監控所獲取到的相關指標會更客觀一些 ， 畢竟它代表了應用/服務的真實感受 。 比如對于數據庫的訪問 ， 請求需要先通過服務的數據庫連接池 ， 再穿越網絡 ， 最后才到達數據庫 ， 這中間任何一個環節出現問題 ， 都會影響到最終的調用效果 。
除此之外 ， 還可以通過服務的調用日志對資源的使用狀況進行優化 。 對線上運維而言 ， 比較頭疼的問題是資源分出去之后就收不回來了 ， 因為你也不知道資源是否還在使用 ， 如果結合服務側的調用日志監控來做資源使用判定的話 ， 則能有效的解決這個問題 ， 比如說 ， 如果通過調用日志發現對某個namespace下的緩存已經沒有調用了 ， 那完全可以考慮將這個namespace的緩存資源釋放掉 。
【微服務線上生命周期管理】我們目前針對微服務的線上生命周期管控的能力是基于螞蟻金融云的能力來構建的 ， 螞蟻金融業在它的云上彈性計算資源的基礎上 ， 通過整合資源編排及資源調度的能力 ， 構建了微服務的綜合管控平臺 ， 通過這個平臺 ， 可以比較方便的進行服務的上線、下線、擴容、縮容等操作 。

推薦閱讀