共计 4687 个字符，预计需要花费 12 分钟才能阅读完成。
作者：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 赞助方案出炉啦
