Aaron Stannard谈Akka.NET 1.1

.NET Actor F# C#

摘要

Akka.NET 1.1近日发布，带来新特性和性能提升。InfoQ采访了Akka.net维护者Aaron Stannard，了解更多有关Akka.Streams和Akka.Cluster的信息。Aaron还阐述了与Akka for JVM实现有关的路线图计划。

正文

Akka.NET 1.1近日发布，带来新特性和性能提升。InfoQ采访了Akka.net维护者Aaron Stannard，了解更多有关Akka.Streams和Akka.Cluster的信息。Aaron还阐述了与Akka for JVM实现有关的路线图计划。

InfoQ：这个版本有什么突出的特性？

Aaron Stannard：Akka.NET 1.1的主要目标是将Akka.Cluster由Beta测试版程序包变成最终版（RTM）程序包。该版本还提供了测试工具，对在生产环境里运行Akka.NET集群的过程中可能出现的大量各种不同的网络场景进行了测试。

不要低估我们付出的巨大努力；Akka.Cluster Beta测试版最初发布于2014年8月。所以，我们大约花了两年的时间开发Akka.Cluster，收集生产用户的反馈。在1.1版本开发的最后阶段，我们主要是提升可靠性和集群系统的速度，以便它可以用于高可用工作负载。已经有银行、医疗保健提供商、能源生产商、船队和车队管理企业、SaaS企业及其他许多用户在生产环境中使用了Akka.NET。Akka.Cluster是他们最希望看到其发布的东西。

1.1版本的另外一个突出的特性是Akka.Streams的第一个Beta版本；该模块引入了一种使用Akka.NET构建响应式应用程序的全新方法，允许开发人员将一系列的异步操作表示成大量可以互联和重用的流处理图。你可以从我们的文档中看到Akka.Streams图可能的样子。

InfoQ：Akka.Net 1.1带来了什么性能提升？

Stannard：最显著的性能提升包括：

• 将所有Actor的内存占用减少了34%；
• 将每个Akka.Remote连接（支撑Akka.Cluster网络连接的子系统）的吞吐量提高了5倍；
• 改正了多处内存过度使用的地方，最明显的是日志系统；

虽然我们一直在不断地度量、测试、提升Akka.NET的性能，但是性能不是这个版本的真正目的。性能的提升源于我们找到了更为健壮的方法实现Akka.NET使用的部分内部构件。

InfoQ：在这个版本中，您最喜欢的特性是什么？

Stannard：说来真奇怪，在1.1版本中，我最喜欢的部分是一个和我无关的部分：Akka.Streams。

关于Akka.Streams，真正引人注目的是，它让用户仅仅使用几行代码就可以简洁地表达复杂的工作流，包括传统上非常困难的并发编程问题，比如退避和节流。在没有经验的情况下，我昨天使用Akka.Streams在几个小时的时间里就重写了WebCrawler Akka.Cluster演示程序中处理繁重任务的部分。我还使用一些内置的缓冲流解决了那个代码库中存在多年的节流问题。和第一次使用Actor一样，第一次使用Akka.Streams也让我很激动：我意识到，我使用了一种以前从未使用过的全新的编程方法。

InfoQ：你们是如何制定路线图的？

Stannard：Akka.NET当前的路线图是由多个因素促成的；与原先的Akka for JVM实现一致就是一个重要因素。我们受益于他们的经验和用户报告的Bug，因此，遵循他们的实现有巨大的好处。

InfoQ：遵循Akka for JVM的实现方式让你们获得了哪些好处？

Stannard：开发人员永远不要忘记，“生产时间（time-in-production）”是度量代码库健康情况及其思想的最有价值的指标。和专有的单业务线应用程序相比，一个有着几千名用户、在几千台服务器上7x24小时运行的大型开源项目，其在生产环境中累计运行的时间会更多。那意味着，更多的Bug、设计缺陷会更快地被发现，生产力就可以获得更频繁地改进。这就可以解释，为什么在Daily WTF上有关可怕的代码炸弹的文章中，几乎所有多年未能发现的代码炸弹都是来自用途单一的专有代码或者应用不广泛的开源软件。这就是为什么我们要设法遵循Akka for JVM的思路——他们的设计来源于在生产环境中长时间的运行。

InfoQ：你们的路线图和Akka for JVM有什么不同？

Stannard：Akka.NET本身已经在生产环境中使用了很长时间了。我们已经从客户那里获得我们自己的生产力改进/Bug/不同的想法。.NET和JVM生态系统的巨大差别也是我们制定路线图时必须考虑的。例如，.NET开发人员特别喜欢依赖注入框架，而那在Scala开发中往往并不多见。那种差别会对路线图的制定产生影响，将来，我们可能会选择设计不同于JVM的东西，例如让DI支持成为一等特性，而不是一个插件。

也有一些Akka for JVM中有的模块，我们并没有多大的兴趣移植——比如Apache Camel集成。我还没有见过哪家.NET工场用它。还有Akka.HTTP，这是一个我们多年来一直在开发的怪物级模块。我们近期内不会移植，因为相对于我们现在要提供给用户的一切，它的价值较低。

一般而言，我们的用户往往在服务器端应用程序中使用Akka.NET。他们真正想要的是我们的高可用（HA）模块，像Akka.Cluster、Persistence、Streams和Sharding，全部运行在Linux上的.NET Core上。所以接下来，影响我们路线图的主要任务可能是，Akka.NET提供对.NET Core的初步支持。

InfoQ：Akka.NET主要是C#的，但也有F# API。您在实现中使用了F#？

Stannard：就我个人而言，我并不怎么用F#，但我正要改变那种情况。我维护我们的构建系统。该系统用F#编写，使用了FAKE。我大部分的F#使用经验都来自那里。我正计划在不久的将来构建一些供Petabridge内部使用的应用程序，我考虑在Windows Azure Service Fabric上使用Suave及Akka.Cluster来实现。无疑，Akka.NET让我爱上了函数式编程。许多FP的基础概念，如模式匹配和“流迭代（stream iteration）”，是Actor系统的主要部分。在任何.NET开发人员的职业发展中，F#都会自然地成为Akka.NET的下一个步骤。

Akka.NET是一个托管在GitHub上的开源项目。Akka.NET网站提供了详细的文档。

查看英文原文：Q&A on Akka.NET 1.1 with Aaron Stannard