.NET環境大規模使用OpenTracing

做者：Austin Parker

OpenTracing的最大優點之一是圍繞它構建的社區，涵蓋各類語言和技術。考慮到這一點，我很高興今天在OpenTracing博客上發表一篇由Aaron Stannard撰寫的客座文章。Aaron Stannard是Petabridge的創始人兼首席執行官，Petabridge是一家幫助.NET公司構建大規模分佈式系統的創業公司。他也是Akka.NET項目的聯合創始人。你能夠在Twitter上找到他，網址是https://twitter.com/Aarononth...

---

在過去的五年裏，我一直擔任Akka.NET開源項目的維護者和聯合創始人之一，該項目是最初在Scala開發，極受歡迎的Akka項目的C#和F#移植。我最初開始這個項目，是由於.NET生態系統缺少用於構建實時大型應用程序類型的工具和框架，就像那時我在MarkedUp開發的那種類型，MarkedUp是我運行的營銷自動化和分析的初創公司。

在關閉MarkedUp後，我繼續建立了Petabridge，這是一家致力於在.NET中支持和開發Akka.NET，和其餘分佈式系統技術的開源公司。

我很高興地報告說，如今.NET社區有一個更強大的開源生態系統，而且有更多的工具選擇，可用於構建我在2013-14年工做的.NET中的大規模應用程序類型。

隨着.NET Core的出現，整個.NET生態系統正在發生巨大變化，.NET Core是一種高性能，輕量級和100％跨平臺的.NET運行時（runtime）的新實現。這爲.NET開發者開闢了一個新的可能性，而這以前根本就沒有。

使用Akka.NET和Actor模型的大規模.NET

Akka和Akka.NET，若是你尚未據說過，是在通用虛擬機（分別是JVM和CLR）之上構建的actor模型的實現。演員（actor）模型是一個可追溯到早期20世紀70年代的舊概念，但近年來它從新煥發活力，由於它提供了一種易於在大型數據中心或公共雲環境中分發，可理解的計算模型。

你問，「可理解的計算模型」作什麼？具體來講，actor模型爲須要構建可擴展實時系統的開發者，找到了一個家，例如：

• 多人視頻遊戲；
• 分析（Analytics）；
• 營銷自動化；
• 醫療/醫療物聯網；
• 物流、交通和運輸；
• 能源；
• 金融；和
• 實時交易處理（ACH、支付處理器等）

全部這些應用程序的共同點是，它們履行了對客戶和利益相關者的義務，他們必須可以以一致的快速（實時）方式完成工做，而無論系統的總量（可擴展）。爲了使這些應用程序知足這兩個目標，它們必須是有狀態的，這意味着真實的來源來自應用程序內存，而不是外部數據庫。爲了使有狀態應用既具備容錯性，和高可用性，它們也必須分散（decentralized），狀態不能集中在一個區域，不然系統容易受到單點瓶頸和單點故障限制的影響。

這是actor模型容許開發者作的事情：構建高度分散、容錯、有狀態的應用程序，其中每一個工做（actor）單元都是自包含的私有狀態，不能直接從外部修改。修改actor的狀態的惟一方法，是經過向該actor發送一條消息，該actor最終將處理該消息，從而可能致使更新actor的狀態。

在.NET中，Akka.NET是構建這些類型應用程序的主要actor模型實現，它被數百家公司使用，包括戴爾、美國銀行、波音、S＆P Global、Becton Dickinson、美國能源部，Zynga等等。

然而，演員模型爲試圖大規模採用它的軟件團隊提出了一些重大挑戰，其中最痛苦的一個是大規模診斷和調試編程錯誤和網絡相關問題。這就是OpenTracing和分佈式跟蹤的登場時間。

使用OpenTracing以低成本瞭解複雜性

Akka.NET和大規模分佈式演員的問題在於，在任何特定時間，你的系統每秒均可以進行數千萬次交互，看起來與此太類似：

Akka.NET ActorSystem中的每一個actor一般都有一些少許的自包含狀態，一些消息處理代碼執行其實際工做，以及一些對它常常與之通訊的其餘actor的引用。演員經過來回傳遞消息來相互通訊。默認狀況下，在actor模型中傳遞的消息100％是異步的，actors一直按照它們被髮送的順序處理消息，可是一個actor可能必須處理來自許多其餘actor的消息。

Actor能夠跨進程和網絡邊界透明地相互通訊，所以，發送到一個進程內的單個actor的消息可能最終傳播到多個進程。其中存在的問題是：這種位置透明性，使得演員如此擅長以可擴展的方式分配工做，這可能會使他們在生產中出現問題時進行調試時很是使人沮喪：知道出現問題的地點和時間變成一個非凡問題，尤爲是當你有數百萬次這樣的操做一直在發生時。

這是咱們發現OpenTracing特別有用的地方。

Akka.NET應用程序不做爲單線程，單體進程存在，它們是高度併發且一般是分佈式的進程。所以.NET中常見的傳統跟蹤工具，如Intellitrace，一般沒法幫助咱們回答系統內部「出了什麼問題？」。

咱們須要的是分佈式跟蹤工具，它們能夠從多個進程收集上下文，將它們關聯在一塊兒，並從分佈式系統的角度講述完整的故事。咱們須要可以回答諸如「akka.tcp://ClusterSys@10.11.22.248:1100/user/actorA/child2收到msg1後，發送給akka.tcp://ClusterSys@10.11.22.249:1100/user/processB/child1的是什麼？」，只有在這兩個進程上運行的分佈式跟蹤工具，纔能有效地回答這個問題，而這正是咱們在Petabridge上使用OpenTracing的緣由。

OpenTracing實施和優點

Petabridge專業支持大規模採用Akka.NET的用戶，這意味着咱們必須提供各類工具來幫助他們的生活更輕鬆。這就是爲何咱們開始建立Phobos，這是Akka.NET的監控和跟蹤解決方案。

咱們但願經過開發某種分佈式跟蹤實現，幫助咱們的用戶解決這個Akka.NET可觀察性問題，這些實現能夠輕鬆地包含在他們的應用程序代碼。但咱們遇到了一個小問題：咱們的客戶沒法接受單一供應商的解決方案做應用程序性能監視，他們確定不會接受只適用於Akka.NET，而不適用於其餘重要的.NET技術，如ASP.NET Core和SignalR。

OpenTracing爲咱們優雅而簡單地解決了這個問題：經過瞄準OpenTracing標準，而不是任何單一的銷售解決方案，如Zipkin或Jaeger，咱們能夠爲咱們的客戶打開門口，讓他們選擇他們想要的任何跟蹤解決方案。咱們也知道，咱們極可能會爲.NET用戶建立一些兼容OpenTracing的驅動程序，他們但願可以使用咱們和其餘依賴該標準的產品。

所以，咱們針對優秀的OpenTracing C#庫構建了Phobos的跟蹤功能，並設計了Zipkin和Jaeger等工具基於OpenTracing綁定的第一方集成。這大大下降了咱們的開發成本，增長了用戶享受的選擇自由。

每次演員發送或接收消息時，咱們都會建立一個新的Span，並將跟蹤標識符傳播到咱們在演員之間傳遞的每條消息中，包括經過網絡傳遞。咱們可以構建全部這些，所以它在幕後工做，而不須要太多的手動儀器（instrumentation）。能夠確定的是，OpenTracing容許咱們使用Jaeger製做像這樣的可理解的圖形：

在這種狀況下，咱們正在建模一個「扇出」（「fan out」）調用，其中一個節點經過網絡向許多其餘節點發出呼叫，使用傳統工具難以捕獲的東西，由於它涉及多個節點上的大量併發處理和每一個人之間的異步溝通。可是使用OpenTracing的標準，咱們很容易使用像Jaeger這樣的工具來實現這一點，Jaeger在C#中有一個很好的OpenTracing兼容驅動程序。

在.NET中建立OpenTracing驅動程序

一旦Phobos徹底支持OpenTracing，做爲咱們最終用戶的集成點，咱們就知道任何擁有內部或第三方跟蹤解決方案，但自己不支持OpenTracing的Akka.NET用戶最終均可以找到一種方法使用OpenTracing庫來將事情聯繫在一塊兒。

可是，咱們決定加倍努力，採用一些已經在.NET社區中流行的現有工具，或者經過爲這些產品推出第一方OpenTracing驅動程序和適配器來下降進入門檻。

咱們建造的第一個是Petabridge.Tracing.Zipkin，一個用於Zipkin的高性能OpenTracing兼容驅動程序；咱們想在內部使用Zipkin，並但願原生支持像Kafka的傳送選項。

在許多.NET用戶的要求下，咱們構建的第二個也是更有趣的是Microsoft Application Insights OpenTracing適配器，用於咱們的Akka.NET跟蹤產品。

對Azure上運行的用戶，咱們但願可以支持Application Insights做爲的跟蹤目標，可是沒有用於將Application Insights插入OpenTracing的內置解決方案。所以，咱們遵循了Microsoft團隊編寫的標準文檔，該文檔容許咱們在OpenTracing的詞典之上映射Application Insights常規，而且可以建立一個開源軟件包Petabridge.Tracing.ApplicationInsights，它彌合了這二者之間的差距技術，使Application Insights在大型Akka.NET應用程序中完美可行。

咱們在發佈軟件包以後發現，即使是微軟自己也在使用OpenTracing和咱們的Application Insights驅動程序來內部測試他們本身的一些雲應用程序。對於整個.NET生態系統中的每一個人來講，這是一件好事：隨着OpenTracing繼續得到牽引力，它將有助於推進其做爲行業標準實踐的使用。

隨着咱們繼續推進大規模.NET系統的規模和速度的界限，像咱們這樣的組織將繼續投資OpenTracing等技術，以及其有前途的監控對手OpenMetrics，以限制運行這些系統的運營和管理成本。到目前爲止，OpenTracing已經爲咱們的公司和整個Akka.NET項目帶來了驚人的表現，咱們期待在將來看到更多。

-Aaron Stannard，
Petabridge首席執行官
Akka.NET項目聯合創始人

---

2019年KubeCon + CloudNativeCon中國論壇提案徵集（CFP）現已開放

KubeCon + CloudNativeCon 論壇讓用戶、開發人員、從業人員匯聚一堂，面對面進行交流合做。與會人員有 Kubernetes、Prometheus 及其餘雲原生計算基金會 (CNCF) 主辦項目的領導，和咱們一同探討雲原生生態系統發展方向。

2019年中國開源峯會提案徵集（CFP）現已開放

在中國開源峯會上，與會者將共同合做及共享信息，瞭解最新和最有趣的開源技術，包括 Linux、容器、雲技術、網絡、微服務等；並得到如何在開源社區中導向和引領的信息。

大會日期：

• 提案徵集截止日期：太平洋標準時間 2 月 15 日，星期五，晚上 11:59
• 提案徵集通知日期：2019 年 4 月 1 日
• 會議日程通告日期：2019 年 4 月 3 日
• 幻燈片提交截止日期：6 月 17 日，星期一
• 會議活動舉辦日期：2019 年 6 月 24 至 26 日

2019年KubeCon + CloudNativeCon + Open Source Summit China贊助方案出爐啦