對於普通系統或者服務來說，一般透過打日誌來進行埋點，然後再透過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