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！