作者：Austin Parker
OpenTracing的最大优势之一是围绕它构建的社区，涵盖各种语言和技术。考虑到这一点，我很高兴今天在OpenTracing博客上发表一篇由Aaron Stannard撰写的客座文章。Aaron Stannard是Petabridge的创始人兼首席执行官，Petabridge是一家帮助.NET公司构建大规模分布式系统的创业公司。他也是Akka.NET项目的联合创始人。你可以在Twitter上找到他，网址是https://twitter.com/Aaronontheweb
在过去的五年里，我一直担任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项目联合创始人
