更新時間:2020-07-24 來源:黑馬程序員 瀏覽量:
自SpringCloud問世以來,微服務以席卷之勢風靡全球,企業架構都在從傳統SOA向微服務轉型。然而微服務這把雙刃劍在帶來各種優勢的同時,也給運維、性能監控、錯誤的排查帶來的極大的困難。
在大型項目中,服務架構會包含數十乃至上百個服務節點。往往一次請求會設計到多個微服務,想要排查一次請求鏈路中經過了哪些節點,每個節點的執行情況如何,就稱為了亟待解決的問題。于是分布式系統的APM管理系統應運而生。
什么是APM系統?
APM系統可以幫助理解系統行為、用于分析性能問題的工具,以便發生故障的時候,能夠快速定位和解決問題,這就是APM系統,全稱是(Application Performance Monitor)。
谷歌公開的論文提到的 Google Dapper可以說是最早的APM系統了,給google的開發者和運維團隊幫了大忙,所以谷歌公開論文分享了Dapper。
而后,很多的技術公司基于這篇論文的原理,設計開發了很多出色的APM框架,例如Pinpoint、SkyWalking等。
而SpringCloud官網也集成了一套這樣的系統:Spring Cloud Sleuth,結合Zipkin。
APM的基本原理
目前大部分的APM系統都是基于Google的Dapper原理實現,我們簡單來看看Dapper中的概念和實現原理。
先來看一次請求調用示例:
1、服務集群中包括:前端(A),兩個中間層(B和C),以及兩個后端(D和E)
2、當用戶發起一個請求時,首先到達前端A服務,然后A分別對B服務和C服務進行RPC調用;
3、B服務處理完給A做出響應,但是C服務還需要和后端的D服務和E服務交互之后再返還給A服務,最后由A服務來響應用戶的請求;
如何才能實現跟蹤呢?
Google的Dapper設計了下面的幾個概念用來記錄請求鏈路:
·Span:請求中的基本工作單元,每一次鏈路調用(RPC、Rest、數據庫調用)都會創建一個Span。大概結構如下:
·Trace:一次完整的調用鏈路,包含多個Span的樹狀結構,具有唯一的TraceID
一次請求的每個鏈路,通過spanId、parentId就能串聯起來:
當然,從請求到服務器開始,服務器返回response結束,每個span存在相同的唯一標識trace_id。
APM的篩選標準
目前主流的APM框架都會包含下列幾個組件來完成鏈路信息的收集和展示:
·探針(Agent):負責在客戶端程序運行時搜索服務調用鏈路信息,發送給收集器
·收集器(Collector):負責將數據格式化,保存到存儲器
·存儲器(Storage):保存數據
·UI界面(WebUI):統計并展示收集到的信息
因此,要篩選一款合格的APM框架,就是對比各個組件的使用差異,主要對比項:
·探針的性能
主要是agent對服務的吞吐量、CPU和內存的影響。如果探針在收集微服務運行數據時,對微服務的運行產生了比較大的性能影響,相信沒什么人愿意使用。
·collector的可擴展性
能夠水平擴展以便支持大規模服務器集群,保證收集器的高可用特性。
·全面的調用鏈路數據分析
數據的分析要快 ,分析的維度盡可能多。跟蹤系統能提供足夠快的信息反饋,就可以對生產環境下的異常狀況做出快速反應,最好提供代碼級別的可見性以便輕松定位失敗點和瓶頸。
·對于開發透明,容易開關
即也作為業務組件,應當盡可能少入侵或者無入侵其他業務系統,對于使用方透明,減少開發人員的負擔。
·完整的調用鏈應用拓撲
自動檢測應用拓撲,幫助你搞清楚應用的架構
接下來,我們就對比下目前比較常見的三種APM框架的各項指標,分別是:
·Zipkin:由Twitter公司開源,開放源代碼分布式的跟蹤系統,用于收集服務的定時數據,以解決微服務架構中的延遲問題,包括:數據的收集、存儲、查找和展現。
·Pinpoint:一款對Java編寫的大規模分布式系統的APM工具,由韓國人開源的分布式跟蹤組件。
·Skywalking:國產的優秀APM組件,是一個對JAVA分布式應用程序集群的業務運行情況進行追蹤、告警和分析的系統。現在是Apache的頂級項目之一。
三者對比如下:
可見,zipkin的探針性能、開發透明性、數據分析能力都不占優,實在是下下之選。
而pinpoint在數據分析能力、開發透明性上有較大的優勢,不過Pinpoint的部署相對比較復雜,需要的硬件資源較高。
Skywalking的探針性能和開發透明性上具有較大優勢,數據分析能力上也還不錯,重要的是其部署比較方便靈活,比起Pinpoint更適合中小型企業使用。
因此,本文會帶著大家學習Skywalking的使用。
猜你喜歡: