對于普通系統或者服務來說，一般通過打日志來進行埋點，然后再通過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已經達到開箱即用的強大優勢)，希望得到的數據像下面這樣：

?

?

解釋一下這個數據是怎么來的（或者這個實驗的服務架設）：

后端：提供數據庫的查詢，隊列的接口等一系列數據操作的地方；

前置：提供接口的過濾和處理，可以把他理解為一個邏輯后端，或者一個API網關；

請求：提供請求，或者模擬串行或并行請求；

?

這樣從邏輯上理解就是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

總結

以上是生活随笔為你收集整理的NET Core微服务之路：SkyWalking+SkyApm-dotnet分布式链路追踪系统的分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。