.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和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和分布式跟踪的登场时间。

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的原因。

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兼容驱动程序。

一旦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赞助方案出炉啦