歡迎光臨
每天分享高質量文章

NET Core微服務之路:SkyWalking+SkyApm-dotnet分佈式鏈路追蹤系統的分享

對於普通系統或者服務來說,一般通過打日誌來進行埋點,然後再通過elk或splunk進行定位及分析問題,更有甚者直接遠程服務器,直接操作查看日誌,那麼,隨著業務越來越複雜,企業應用也進入了分佈式服務化的階段,傳統的日誌監控等方式無法很好達到跟蹤呼叫、排查問題等需求,可以想象,如果你的服務節點達到有很多很多(兩位數以上吧),而沒有一個自動跟蹤系統,那查找一個問題將成為噩夢。

 

那麼,服務之間呼叫的問題是:

 

  • 如何快速發現問題?

  • 如何判斷故障影響範圍?

  • 如何梳理服務依賴以及依賴的合理性?

  • 如何分析鏈路性能問題以及實時容量規劃?

  • 如何在分佈式服務進行日誌監控呢?

 

首先大家會想到分佈式鏈路追蹤系統,說到這,就得講 OpenTracing 規範,OpenTracing 是一個輕量級的標準化層,它位於應用程式/類庫和追蹤或日誌分析程式之間。詳細介紹見 《opentracing文件中文版》。在谷歌論文《Dapper, 大規模分佈式系統的跟蹤系統》的指導下,許多優秀的APM應運而生,分佈式追蹤系統發展很快,種類繁多,給我們帶來很大的方便。雖然目前市面許多優秀的APM系統,但是作為我們.NET程式員的選擇卻就少之又少了(甚至沒得選),幾乎各大分佈式追蹤系統均提供java版的支持,而.NET上卻只有SkyWalking的SkyAPM-dotnet一直在默默的支持著,辛苦了,大佬們。

 

好吧,既然不能做到技術選型,那麼我們就開始工作吧。SkyWalking和Elasticsearch的安裝,網上一抓一大把,這裡不在重覆的介紹“如何安裝”和“如何使用”。

 

從SkyAPM-dotnet中,我們可以拿到團隊的官方示例,https://github.com/SkyAPM/SkyAPM-dotnet/tree/master/sample,她分為請求端,前置端和後端(當然,你喜歡怎麼叫都行),我稍微修改一下,做了一些資料和請求數上的調整,本篇代碼不是重點(SkyAPM-dotne已經達到開箱即用的強大優勢),希望得到的資料像下麵這樣:

 

 

解釋一下這個資料是怎麼來的(或者這個實驗的服務架設):

  1. 後端:提供資料庫的查詢,佇列的接口等一系列資料操作的地方;

  2. 前置:提供接口的過濾和處理,可以把他理解為一個邏輯後端,或者一個API網關;

  3. 請求:提供請求,或者模擬串行或並行請求;

 

這樣從邏輯上理解就是1->2->3->2->1,其實一個請求從頭到尾然後在傳回到前端也都是這樣的,你可以把他想象成我們常見的三層模型、等等。

啟動三個節點後,通過SkyWalking可以看到,Service數量是3,正是我們創建的三個服務節點,Endpoint表示所有連接的數量,DB和Cache作為資料庫(或快取)的數量,MQ的數量、平均吞吐量、網絡拓撲圖等等。

整個界面一目瞭然,更多詳細介紹可查看官網解釋。

 

 

 

 

在.NET的生態圈中,曾經有ButterFly這樣的原生.NET框架來實現我們整個系統的鏈路追蹤,只是作者表示已不在維護,ButterFly放棄的原因之一也是因為.NET開源專案的參與者太少了,光靠一人之力是沒法做出一個穩定高效可用於生產的APM。作者轉而投入到了Skyapm-dotnet 所以,在.NET上,我們優先選擇有良好支持的skyapm-dotnet!

原文地址:https://www.cnblogs.com/SteveLee/p/10463200.html


.NET社區新聞,深度好文,歡迎訪問公眾號文章彙總 http://www.csharpkit.com