微服務，通常都是用複雜的、大規模分散式集群來實現的。微服務構建在不同的軟體模塊上，這些軟體模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千台伺服器，橫跨多個不同的數據中心。因此，就需要一些可以幫助理解系統行為、用於分析性能問題的工具。 API網關Ocelot 作為微服務 ...
微服務，通常都是用複雜的、大規模分散式集群來實現的。微服務構建在不同的軟體模塊上，這些軟體模塊，有可能是由不同的團隊開發、可能使用不同的編程語言來實現、有可能布在了幾千台伺服器，橫跨多個不同的數據中心。因此，就需要一些可以幫助理解系統行為、用於分析性能問題的工具。
API網關Ocelot 作為微服務的一個重要組件，出現在系統邊界上的一個面向API的、串列集中式的強管控服務，這裡的邊界是企業IT系統的邊界，主要起到隔離外部訪問與內部系統的作用。通過API網關對外發佈的通常是OpenAPI,在它的後面有眾多的分散式應用，如微服務、消息收發、分散式資料庫、分散式緩存、分散式對象存儲、跨域調用，這些組件共同構成了繁雜的分散式網路。
當應用A發出某個請求時，其背後可能有數十個甚至更多的服務被調用，可謂是“牽一發而動全身”。 如果將分散式系統比作高速公路網，每個前端的請求就相當於高速上行駛的車輛，而處理請求的應用就是高速上的收費站，在收費站上將車輛通行信息記錄成日誌，包括時間、車牌、站點、公路、價格等，如果將所有收費站上的日誌整合在一起，便可以通過唯一的車牌號確定該車的完整通行記錄；分散式調用系統跟蹤和監控就是類比這種思想，對每一次請求進行跟蹤，進而明確每個請求所經過的應用、耗時等信息。
Butterfly被設計為分散式追蹤和APM的Server端，它將包含Collector，Storage，獨立的Web UI，並使用Open Tracing規範來設計追蹤數據。目前僅根據規範實現了Open Tracing API,後續還會相容google的opencensus。這裡順便提下為什麼我們不用zipkin 或是Jaeger，他們只做了tracing，Butterfly比他們多一點就是同時要做metrics和預警，就是要做立體化監控系統。目前Butterfly也是在起步階段，還有非常多的功能需要開發，目前有兩個事情的優先順序比較高一個應用程式進程級別的metrics，一個是後端collector和es的性能優化，歡迎各位同學加入一起開發，我們相信通過不斷的建設，我們.NET社區一樣可以達到Java的高度。回想Ocelot 的發展歷程，2016年才是到現在已經開發了2年時間，完成了3.0版本的開發，現在已經是一個日趨成熟的API網關，通過API網關連接後面的服務，像今天和大家分享的最近我業餘時間在開發的分散式跟蹤的支持，這項任務在一年前提出來，https://github.com/TomPallister/Ocelot/issues/19 這裡有我們的討論，現在集成Butterfly 來實現這個功能，讓我們的微服務能夠可運維。
Butterfly.Client.AspNetCore 為我們提供了在ASP.NET Core項目集成Butterfly的組件，使用很簡單，只需要在ConfigureServices 註冊Butterfly services
public void ConfigureServices(IServiceCollection services)
{
//your other code
services.AddButterfly(option =>
{
option.CollectorUrl = "http://localhost:9618";
option.Service = "my service";
});
}其中http://localhost:9618 是Butterfly的服務端，提供了UI，我們在瀏覽器通過http://localhost:9618 就可以訪問到。
那麼在API網關Ocelot 中集成Butterfly 有什麼不一樣呢？ 我們在Ocelot項目中加入上述代碼後，我們已經可以在Butterfly UI上看到我們的追蹤數據，只是數據沒有連成一條鏈。那麼我們做集成的工作主要就是以下2點：
一、將追蹤數據串起來，讓我們可以在Butterfly UI上直觀的看到各個節點的數據
二、Ocelot 本身需要加入到系統跟蹤的數據定義
Ocelot 集成Butterfly 實現分散式跟蹤的代碼目前還沒有加入主幹，可以在我的代碼庫的分支https://github.com/geffzhang/Ocelot/tree/Monitoring 下看到，我們首先在Ocelot的路由配置中加入一個配置項，表示是否啟用分散式追蹤：
{
"ReRoutes": [
{
"DownstreamPathTemplate": "/api/values",
"DownstreamScheme": "http",
"UpstreamPathTemplate": "/api/values",
"UpstreamHttpMethod": [ "Get" ],
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 5002
}
],
"HttpHandlerOptions": {
"AllowAutoRedirect": true,
"UseCookieContainer": true,
"UseTracing": true
}
},
UseTracing 表示是否啟用分散式追蹤，預設為false，也就是不啟用。 然後在Ocelot.DependencyInjection.IOcelotBuilder 加個介面方法：
方法的實現也非常簡單：
主要就是加入Ocelot 本身需要加入到系統跟蹤的數據定義，實現上主要使用DiagnosticSource， 官方的文檔：https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md 。類似於asp.net core 有個 Diagnostics中間件https://github.com/aspnet/Diagnostics，主要功能是用於報告和處理ASP.NET Core中的異常和錯誤信息，以及診斷Entity Framework核心遷移錯誤。其中還有其他幾項功能，歡迎頁，錯誤代碼頁、如404 頁等。以及一個還算不錯的日誌查看功能，這個功能也是很多人需要的功能，直接線上查看日誌。
實現了Butterfly 的介面ITracingDiagnosticListener ，通過DI 註入後Butterfly 會幫我們註冊好。
下麵我們要把我們的分散式追蹤數據串起來，OpenTracing（鏈接：opentracing.io）通過提供平臺無關、廠商無關的API，使得開發人員能夠方便的添加（或更換）追蹤系統的實現。OpenTracing正在為全球的分散式追蹤，提供統一的概念和數據標準。標準的中文版是我們的MVP吳晟翻譯的，同時他也是OpenTracing的主要成員 ： https://wu-sheng.gitbooks.io/opentracing-io/content/。
在廣義上，一個trace代表了一個事務或者流程在（分散式）系統中的執行過程。在OpenTracing標準中，trace是多個span組成的一個有向無環圖（DAG），每一個span代表trace中被命名並計時的連續性的執行片段。
分散式追蹤中的每個組件都包含自己的一個或者多個span。例如，在一個常規的RPC調用過程中，OpenTracing推薦在RPC的客戶端和服務端，至少各有一個span，用於記錄RPC調用的客戶端和服務端信息。
一個父級的span會顯示的並行或者串列啟動多個子span。在OpenTracing標準中，甚至允許一個子span有個多父span（例如：並行寫入的緩存，可能通過一次刷新操作寫入動作）。
所以集成的關鍵點就在tracerId和spanId的關聯關係的Id 處理上。
tracerid 代表是全局的id，類似於Ocelot的RequestId http://ocelot.readthedocs.io/en/latest/features/requestid.html，存放在http header 里，它的key是ot-traceid，所以在Ocelot裡面可以把全局的RequestId設置為ot-traceid 。
同時還需要處理spanid，使得下游的的組件的spanid是它上一級的spanid，也是存放在http header 里，它的key是ot-spanId，我們在OcelotRequestTracer 以及OcelotHttpTracingHandler 需要處理spanid
上面我們說完了代碼集成工作，我們來看看效果吧,我搭了一個Demo環境，服務前端—>Ocelot –>服務後端。Butterfly為每個請求生成全局唯一的ID（Traceld），通過它將不同系統的“孤立的”調用信息關聯在一起，還原出更多有價值的數據。
上圖是一條API調用請求的調用鏈，在Span列可以看到請求中間過程所經過的一系列應用組件，可以看到最先經過請求端的HttpClient組件，後續調用Ocelot、HttpClient、backend等，形成調用樹（樹上的縮進表示嵌套關係），從調用樹上很容易看到前端請求的完整處理過程。在上圖所示的頁面中也清晰地展示了每塊應用處理請求得具體耗時，非常直觀地進行定位；此外，點擊具體的組件，可以看到這個組件中的日誌記錄
對於分散式調用跟蹤系統而言，它並不僅僅提供了調用鏈這一功能，因為它對所有中間件的調用做埋點，所以中間件上的所有情況都可以監控的到。因此，在形成調用鏈的過程中也會形成一份詳細的調用監控報表，它與其他監控的不同之處在於：該監控報表是帶有上下鑽取功能的報表。因為調用鏈是詳細的底層統計，對上可以形成的報表維度是非常豐富的，在上圖所示的調用報表裡，不僅可以看到服務的情況，還可以下鑽到它所調用服務的情況；另外從監控報表上還可以進行調用鏈的下鑽，查看清晰的調用鏈信息。目前Butterfly這塊功能也是需要繼續開發的功能，歡迎各位同學一起加入開發。
還有鏈路分析，鏈路與調用鏈不同，鏈路是一個統計學的概念，而調用鏈是單體調用的過程。分析鏈路的拓撲形態分析：分析來源、去向，識別不合理來源；
上圖是全局調用拓撲圖，可以明顯的看到不同的服務之間存在複雜的調用關係，也可以查看某個服務和其他服務之間的調用關係以及調用的頻次； 通過該拓撲圖，架構師可以清楚地觀察到系統上的調用情況。
