问Java中的Akka类型演员

EN

在我们开始之前，：问题是关于“类型化角色”模块的。它将很快被阿克卡式所取代，这是对这个问题的一个更好的处理，它避免了下面解释的缺点--如果您对键入的演员感兴趣，请看akka类型的！

我将列举一些使用您所引用的类型化角色实现的缺点。不过，请注意，我们刚刚合并了一个新的阿克卡式模块，它将类型安全带回到akka演员的世界。为了这篇文章，我将不深入探讨为什么编写打印版本是如此艰巨的挑战，现在让我们来回答“为什么不使用(旧的)类型的演员”这个问题。

--首先是，它们从未被设计成工具包的核心。它们构建在Akka提供的消息传递基础设施之上。请注意，由于这个消息传递基础设施，我们能够实现位置透明性，以及Akka的众所周知的性能。他们大量使用反射和JDK代理来转换到和从方法到消息发送。这是非常昂贵的(就时间而言)，并将表演降级约10倍，而不是普通的Akka演员，参见下面的“乒乓”基准(使用这两种风格实现，发送方告诉演员，演员回复- 100.000次)：

Unit = ops/ms
Benchmark                                                Mode   Samples         Mean   Mean error    Units
TellPingPongBenchmark.tell_100000_msgs                   thrpt       20 119973619.810 79577253.299   ops/ms
JdkProxyTypedActorTellPingPongBenchmark.tell_100000_msgs thrpt       20  16697718.988   406179.847   ops/ms

Unit = us/op
Benchmark                                                Mode   Samples         Mean   Mean error    Units
TellPingPongBenchmark.tell_100000_msgs                   sample  133647        1.223        0.916    us/op
JdkProxyTypedActorTellPingPongBenchmark.tell_100000_msgs sample  222869       12.416        0.045    us/op

(基准测试保存在akka/akka-长凳-jmh中，并使用OpenJDK JMH工具通过sbt jmh插件运行。)

其次，使用方法对分布式系统进行抽象并不是解决这个问题的好方法(哦，我是如何记住RMI的.我们不要再去那里了)。使用这种“看起来像一种方法”使您不再考虑消息丢失、重新排序以及所有在分布式系统中可能发生和确实发生的事情。它还鼓励(让“太容易做错事”)使用像def getThing(id: Int): Thing这样的签名--这会生成阻塞代码--这对性能来说是可怕的！您确实希望保持异步和响应性，这就是为什么在尝试使用这些(基于代理的)类型的参与者时，您最终会得到大量的未来。

--最后是--基本上失去了一个主要的Actor功能。演员可以执行的三个规范操作是: 1)发送消息；2)启动子参与者；3)根据接收到的消息改变自己的行为(见Carl关于演员模型的原始论文)。第三种功能用于漂亮的状态机模型。例如，您可以说(在普通的akka演员中)是become(active)，然后是become(allowOnlyPrivileged)，在receive实现之间切换--使有限状态机实现(我们也有一个用于FSMs的DSL)成为joy的工作对象。您不能在JDK代理类型的参与者中很好地表达这一点，因为您不能更改公开的方法集。一旦您开始使用状态机进行思维和建模，这将是一个主要的缺点。

A新希望(第1集)：请看一看罗兰德·库恩( Roland )撰写的即将推出的akka型模块 (预览版很快将包括在2.4版中)，我很肯定你会喜欢你会发现的那种类型安全的东西。而且，这种实现最终将比当前的非类型化参与者更快(由于答案已经很长--短版本:基本上，由于新的实现，我们将删除大量的分配)，因此这里省略了一些细节。

我希望你会喜欢这个彻底的答案。欢迎在这里或akka-用户上询问后续问题--我们的官方邮件列表。哈金快乐！

类型化的Actors为您提供了一个以您的域的术语定义的静态契约--您可以将它们的消息命名为它们的消息(这些消息将被委托给底层实现并异步执行)，这些操作在您的域中是有意义的，避免在您的域中使用反射(TypedActors在幕后使用JDK代理，所以仍然在进行反射，您只需要担心它，就可以根据传递给活动对象/类型化的参与者及其返回类型的参数进行类型检查)。文件化在这一点上非常清楚，但我知道对于那些新的基于参与者的并发性，额外的例子总是有帮助的，所以如果您还在摸索不同的地方，可以随意问更多的问题/评论。

但是，你们是否真的有很多公司，他们没有专业的开发人员，而是一个庞大的Infra，可以根据我们的需要横向扩展，所以性能并不总是最好的“追求它”，而是响应，信息驱动，弹性和弹性，现在多亏了我们的类型演员，被那些对Akka或反应性编程一无所知的开发人员所使用。

不要误解我的意思，我每天都在使用纯Akka类型，但是对于交付团队，我们有这样一个框架，使用类型化的参与者，我们的消费者使用POJO，而不知道他们是在反应系统中编码。这是个很棒的特征。