akka java 例子_将Akka与现有Java项目集成的示例

小编典典

回答我的问题。只是分享我的想法，我想到了什么。

如果我们已经有基于Servlets / Spring MVC的现有Web应用程序，那么似乎没有充分的理由切换到Actors/

AKKA(或者为了现有的系统引入actor引入现有系统)，如果在我们的应用程序中：

无需： 线程 任务在后台拆分时的逻辑。(通常，典型的Web应用程序没有此功能)，例如长而长的计算。( 并行性 )。

拥有： 如果我们有顺序调用-当一个组件调用另一个组件时，则该调用又调用另一个彼此依赖的组件：与控制器调用组件一样，组件将一些数据保存到某个列表中(该列表是可变的，但同步为同步列表)。

没有足够的 时间来由Akka actor来替换所有Spring Controller或根本不使用其他服务器(不是Tomcat)(没有那么多的经理/产品所有者可以让您这样做)

在这个简单的系统中拥有Actor有什么问题：

具有通过组件 而不是调用常规方法*(利用OPP的优点，实现接口，具有多个实现-但Actor通常)的 大量消息 ( 将消息 封装到actor或从actor封装的类)。*final class

将消息作为string，也不是一个好的解决方案-因为很难调试。

在这样的系统中(例如MVC站点)，通常没有太多要同步的东西(已经很同步了stateless)。mutable shared data每个控制器/组件中都有0..2 。同步起来并不难(只需养成使所有常见和共享的东西都同步到类顶部的习惯(这样就可以识别/本地化状态)。有时，您只需要synchronized collection使用或使用Java Atomic包装器类型即可。

但是，何时将Actor用于现有应用程序。 用例可能是这样的：

当我们进行长期的搜索时，它会涉及多个来源(例如线程工作者)。具有MasterActor- /的多个/拉数SiteSearchActor(就像PI 在这里为计算所描述的)。MasterActor具有最终结果。SiteSearchActor为多个客户端计算(在多个站点进行搜索)的位置。

或当我们有任何线程分叉时，从当前servlet的线程分叉中

当我们确定/确定我们的系统将被数百万个客户使用(即使使用简单的逻辑)时，我们应该事先考虑scalability和performance( 演员的规模很好-我们可以将一件作品从一位演员委托给N位演员。

演员保险箱使用线程时，处理器类型(无需 10000个螺纹 为 10000级的客户 ，在大多数情况下，有足够 4个线程 (相同数量的处理器核心假设))

但总的来说，我同意这个文章关于concurrency和parallelism。如果我有机会，使从头开始申请，我会用阿卡

没有的Servlet容器 和 有关消息的关怀不知何故 (指挥类)和 OOP

时需要使用它(有没有这么多OOP在一般的网络应用程序。我应该说但是，没有人能阻止保持某些业务逻辑OOP，参与者只是沟通的粘合剂)。例如，这比使用JMS更好/更简单。

但是就像我说的：

演员/ Akka擅长：

服务/控制器(而不是Servlet / SpringMVC的)

线程工作者喜欢逻辑

特别是对于从头开始的项目(当当前的基础结构不会妨碍您应用actor时)。

我现在唯一的问题是performance comparison。假设我们知道：

从性能的角度来看，在我们的MVC控制器/服务中在一个JVM中具有10000个线程并具有同步和锁定以共享可变数据可能是非常糟糕的。由于存在许多可能的锁，所以线程是并发的(彼此竞争的资源的竞争者或竞争者)。

如果我们对具有N个(角色，N远远 小于 1000)的AKKA /

Servlet，具有相同的方案，则我们很可能会具有更好的性能(因为除了队列本身之外，没有人阻塞任何人，因此无需从一个线程切换到其他线程)到另一个)。

但是，即使对于基于Servlet(线程模型)应用程序的系统而言，它具有10000个客户端，但如果有100个客户端，它的性能可能会很好。而且，如果我们有一个连接池(肯定有)，它的作用与Actor的队列(收件箱)相同，则安排客户端访问某些服务。它可以提高K倍的性能(其中K比没有池的情况要多得多-

让线程拼死地互相阻塞)。

问题是：

不将AKKA应用于现有的基于servlet的应用程序是否有充分的理由？

以此为理由：即使在服务器上具有旧系统， connection

pool也可能将性能提高到一个不错的水平。而且此级别很可能足以将其不应用AKKA到现有的Servlet应用程序，例如尝试更改servlet模型(与AKKA之上的Controllers相比，这是很糟糕的)。

这样思考是否有意义？

考虑到连接拉是一种INBOX(类似于AKKA)，用于调度命令(连接)。

即使 Servlets模型不好 (处理来自连接池的连接创建的rest(active)线程中的锁)。

使用连接池可能就足够了，在将Akka与基于servlet的东西进行比较时会忘记它。我们仍然可以调整应用程序，更改连接池中的MAX-

CONNECTION。通常，我们会尽力使应用程序变为无状态，因此，在大多数情况下，我们不会同步任何内容。

但是，当然，对于 整个*应用程序只有 一个

连接池是很糟糕的。如果与Actor进行比较，则每个actor都有自己的连接池(邮箱)，并且每个actor可能负责接受HTTP请求。该模型肯定更好。*

PS在大多数情况下，Future足够好。如果您希望“安全”将状态存储在状态中(最好与“将来”有所不同)，则参与者是很好的。

更新： 有些人认为使用Actors根本不是一个好主意。好的是-纯函数方法或scalaz已提供的功能(Haskell我猜也是这样)-但尚不适用于远程调用。

2020-12-03