Node.js事件系统与Akka的参与者模式有何不同？

我已经工作Node.js了一段时间，并认为自己在Java方面非常出色。但是我刚刚发现Akka并立即对其演员模式感兴趣（据我了解）。

现在，假设我的JavaScript技能与我的Scala / Java技能相当，那么我想专注于这两个系统的实用性。特别是在Web服务方面。

据我了解，Node非常擅长处理许多并发操作。我认为用于资产管理系统的良好Node Web服务将擅长处理许多同时提交更改的用户（在大型，繁忙的应用程序中）。

但是，在了解了Akka的演员之后，它似乎在同一件事上表现出色。我喜欢将工作减少到一口大小的想法。另外，几年前，我涉足了Erlang，并爱上了它使用的消息传递系统。

我在处理复杂业务逻辑的许多应用程序上工作，我想是时候该重拾一个了。特别是升级旧的Struts和C＃应用程序。

无论如何，避免圣战，这两个系统在本质上有何不同？似乎两者都朝着相同的目标发展。也许Akka的“自我修复”架构具有优势。

编辑

看来我获得了接近的票数。请不要将此问题当作“哪个更好，节点还是akka？”。我要寻找的是事件驱动库（如Node）和基于参与者的库（如Akka）的根本区别。

无需赘述（对于Node.js，我了解得很少），主要区别在于Node.js仅支持并发而没有并行性，而Akka支持两者。这两个系统都是完全由事件驱动的，并且可以扩展到较大的工作量，但是缺乏并行性使得在Node.js中很难（例如，并行性是通过启动多个节点并相应地调度请求来明确编码的；因此在运行时不灵活） ，但由于Akka具有可调多线程执行程序，因此在Akka中相当容易。给定较小的隔离工作单元（角色调用），Akka将自动为您并行执行。

另一个重要的区别是，Akka包含一个用于以结构化方式处理故障的系统（通过让每个参与者受其父监督，这是强制性的），而Node.js依赖于约定，以便作者在回调之间传递错误条件。潜在的问题是异步系统无法使用基于同步堆栈的系统采用的标准异常处理方法，因为在发生回调错误时，“调用”代码将移至其他任务。将故障处理内置于系统后，使建立在该系统上的应用程序更可靠的可能性更高。

以上内容并非详尽无遗，我敢肯定还有更多差异。

我还没有使用Akka，但是它看起来像erlang，但是在Java中。在erlang中，所有过程都像Akka中的actor，它们都有邮箱，您可以在它们之间发送消息，也可以有主管等。

Node.js使用协作并发。这意味着您在允许时具有并发性（例如，当您调用io操作或某些异步事件时）。当您进行一些长时间的操作（在长循环中计算某些内容）时，整个系统块都会出现。

Erlang使用抢占式任务切换。当您的循环很长时，系统可以暂停它以运行其他操作，并在一段时间后继续。对于大型并发，如果仅执行短操作，则Node.js很好。两者都支持数百万个客户端：http : //blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/ 2011年至今为100万/

在Java中，您需要线程来进行任何并发操作，否则您将无法在erlang所执行的函数内部暂停执行（实际上erlang在函数调用之间会暂停，但这在所有函数中都会发生）。您可以暂停消息之间的执行。

我不确定这是否是公平的比较。我将其更多地理解为“基于事件的系统与参与者模型相比如何？”。正如Scala在Akka中或C＃在Orleans中一样，Node.js可以支持actor模型，实际上检查nactor，似乎有人已经在尝试它。

至于事件系统与参与者模型之间的比较，我会让明智的人对此进行描述。关于Actor模型的几点简要说明：

• 演员模型基于消息
• 角色模型倾向于与分布式系统（集群）配合得很好。当然可以基于事件的系统可以进行分发，但是我认为参与者模型内置了有关分发计算的分发。可以将新的请求路由到其他筒仓中的新演员，不确定在基于事件的情况下如何工作。
• Actor模型支持失败，因为如果群集1的每个应用程序出现故障，观察者通常可以找到其他筒仓来完成工作

另外，请看戏剧。这是另一个nodejs actor模型实现。