.NET环境大规模使用OpenTracing

Donald

作者: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赞助方案出炉啦

阅读 2.1k

布道者,Linux基金会(LFAPAC)

110 声望
390 粉丝
0 条评论

布道者,Linux基金会(LFAPAC)

110 声望
390 粉丝
文章目录
宣传栏