Metrics：讓微服務運行更透明
內容來源：2018年1月11日，華為開發工程師鄭揚勇在「ServiceComb在線直播」進行《特性：Metrics》演講分享。IT 大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發布。
閱讀字數：1860 | 4分鐘閱讀
摘要
讓微服務運行狀態清晰可見。
Metrics是什麼
直譯是「度量」，不同的領域定義有所區別，在微服務領域中的定義：
「對微服務的某個指標給予一個可量化程度的測量」
Metrics應該具備的特性：
Comparative（可對比）：指標能夠在不同的微服務或同一個微服務的多個實例之間比較；
Understandable（易理解）：指標所衡量的對象、計算方法和輸出的結果值都是容易理解的；
Ratio（理想的比例）：理想結果可預見，可以立即用於比較。
如何判定Metrics實現的優劣？
衡量Metrics實現優劣的標準有：
1、關鍵指標覆蓋全，這是能夠快速定位問題的基礎；
2、計量準確，錯誤的計量和演算法只會幫倒忙；
3、高性能低資源佔用，畢竟Metrics是可選模塊，要保證資源佔用不超過10%；
4、無侵入或低侵入，同樣，由於Metrics是可選模塊，讓用戶修改代碼是不可取的。
Metrics的分類
Metrics有很多種分類方式，在技術實現上我們偏向以取值方式區分為兩種。
1、直接取值。任何時候都能夠立刻獲取到最新值，例如資源使用率，包括CPU使用率，線程數，Heap使用數據等等，還有調用累加次數，當前隊列長度等等。
2、統計取值。經過一個特定的時間周期才能夠統計出值，這個時間間隔我們可以稱為窗口周期（Window Time）或統計周期，例如：
a) 多值取其一的，比如Max、Min、Median（中位值）;
b) 與時間相關的，比如TPS（transaction per second）；
c) 與個數相關的，比如累加平均值、方差等等；
獲取此類Metrics的值，返回的是上一個周期的統計結果，具有一定的延後性。
為什麼需要Metrics
上圖是傳統的單體應用，多模塊緊耦合，Client Application調用API，然後模塊在內部相互調用，還會涉及操作資料庫的一大堆邏輯，隨著功能的不斷增加，它的體積會越來越大，這樣的系統開發人員維護起來會頭暈腦脹，到某個階段重構幾乎是不可避免的。
但是這種單體應用卻很受系統運維人員歡迎，維護它的工作很簡單。
進入微服務時代之後，我們會將單體應用切分成很多微服務，還會使用負載均衡，這樣一個單體應用最終可能轉化為成百上千的微服務實例。
所以微服務化後，問題沒有消失，只是轉移了，開發人員把這個「鍋」甩給了運維人員。因此微服務平台化或上雲成為趨勢，通過自動化程度很高的平台工具降低運維人員的負擔。要使這些平台工具發揮作用，例如制定報警策略、彈性伸縮策略等等，必須提供豐富的Metrics數據作為支撐。
開源領域的Metrics比較
由於Metrics的重要性日漸凸顯，開源領域已有較多實現，熱門的包括Netflix Servo、Dropwizard Metrics和Spring Boot Actuator等，比較如下：
我們結合ServiceComb Java Chassis的優勢，更進一步開發了包含關鍵指標無侵入自動打點，豐富的統計維度和極低的資源佔用等諸多優點的Metrics系統。
ServiceComb Java Chassis
中的Metrics
ServiceCombJava Chassis是一個包含了服務註冊，服務發現，服務配置以及管理功能的微服務框架，因此我們決定提供內置的更強大的Metrics功能：
1、開箱即用，不寫一行代碼輸出關鍵Metrics，全面覆蓋調用數、TPS、Latency等；
2、基於Netflix Servo，使用固定統計周期（稍後會詳細介紹）；
3、多維度統計，幫助用戶抽絲剝繭快速定位問題，支持的維度包括：
a) 微服務實例（Instance）級和操作（Operation）級；
b) 操作結果成功（Success）和失敗（Failed）（開發中）；
c) Transport區分Rest和Highway（評估中）。
依賴關係
Metrics-Core是我們的核心功能模塊，之上的Metrics-Extension模塊用於擴展。在Metrics Extension裡面，我們實現了Prometheus的集成，它依賴於Prometheus Java Client和Metrics-Core。
Metrics默認輸出列表
其中對於時延類的Metrics，都包含max、min、average三個指標。
使用多周期適應不同的場景需求
為了具備高性能的同時又能保持極低的開銷，我們使用固定周期的方式實現Metrics統計，同時支持多周期以適應不同的場景需求，多周期的原理可以看下面的例子：
例如統計報告中的日報、周報、月報、季報、年報就是使用了多周期滿足不同的統計需求。
支持Health Check
微服務很可能依賴資料庫、其它微服務或中間件，這些組件狀態正常是微服務能夠正常提供服務的前提，通過Health Check使得微服務支持檢查依賴組件的狀態並返回，可以用於制定策略，也可以用於Dashboard展現。
相比使用Metrics返回一個狀態值，Health Check的返回更豐富，可以附帶額外信息，例如詳細的錯誤Trace。
未來的開發計劃
未來Java Chassis Metrics將強化如下幾個方面的內容：
1、我們需要實現或對接一個更優秀的可視化界面用於展示Metrics的更多特性，僅僅是集成Prometheus是不夠的(SCB-252)；
2、我們將研究如何與主流的監控系統例如Zabbix、Nagios、Cacti等更簡單高效的集成，以及提出通用的集成第三方監控系統的方案；
3、我們將強化Metrics作為數據源，如何更好的支持在監控系統中制定報警、彈性伸縮等策略，降低運維人員的工作量，提升運維效率。
如何參與到ServiceComb社區
官網：http://servicecomb.incubator.apache.org/cn/
通過訂閱郵件列表參與討論：
2、收到來自dev-help的郵件後，再回復任意內容來確認訂閱郵件列表
在Apache JIRA(https://issues.apache.org/jira/browse/SCB)上提issue或查看最新的開發任務及進展；
關注微信小助手獲取信息：
加入微信群進行交流；
通過Github(https://github.com/apache?q=servicecomb)發起PR
今天的分享就到這裡，謝謝大家！
TAG:IT大咖說 |