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