Aaron Stannard 谈 Akka.NET 1.1

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