java - 将Akka与现有Java项目集成的示例

Question

如果我已经有使用java和spring容器的servlet Web应用程序。将Akka集成到其中的正确方法是什么？

就像我将要彼此通信的Actor1和Actor2一样。开始使用这些参与者的切入点是什么？ (例如:1.放到那里2.更改配置3.获取对actor的引用)

我发现http://doc.akka.io/docs/akka/2.2-M3/general/configuration.html，但是他没有给我胶水。只想获得集成的真实示例。

有一些简单的集成示例吗？

编辑:
应用程序进行一些搜索，从外部获取一些数据，然后将信息存储到文件中。

应用程序很大。一些组件/对象可以离开自己的生命，这是出于直接客户的请求，它可以并行执行某些事情。就像某些具有可变状态的单例对象一样。

问题是我不知道可以在哪里申请Actors，我正在调查中。但是我已经在这里和那里有很多同步块(synchronized block)。

而且，我认为，已经有可能采取行动者的迹象。 (因为我不确定，也许我忘了放置一些同步的，并且当然没有集成测试)

关于配置，我只是不确定是否应该配置一些application.conf以便让Actrors/Akka住在那里(，因为文档本身描述了)。

我所看到的:

@Component("someManager")
public class SomeManager {
 List<Some> something;  // mutable state, that why I use locks here.
 // methods: add(), delete(), update()  
}

我可以把它变成 SomeManagerActor SomeManager是从 controller使用的。因此，最好还具有 Controller Actor？我想接收反馈到( onReceive()方法)。

这有点争议...这就是为什么我需要一些 示例的另一个原因。

我相信我可以通过消除所有 synchronized/whait/notify的东西，将职责移交给参与者，使用消息作为与他们之间/之间进行交流的方式来改善应用程序。

或像 this一样，它可以是 Actor 来写入属性文件:

编辑:

例如，现在，我发现了:为了使Actor1向Actor2发送消息，我使用了一个技巧:

// somewhere in existing code
public void initActors() {

        ActorSystem system = ActorSystem.create(example");

        // initializing
        final ActorRef actor1 = system.actorOf(Props.create(Actor1.class), "actor1");

}

Actor1有一个 preStart()方法，一旦我获得对它的引用，它便会立即启动(如上所述)。然后它向Actor2发送消息:

@Override
public void preStart() {

But I'm not sure that it is good why to initialize two actors to do their work.

Answer 1

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

如果我们已经有基于Servlets/Spring MVC的现有Web应用程序，那么似乎通常没有充分的理由切换到Actors/AKKA(或为现有的hack引入actor到现有系统中)，如果在我们的应用程序中:

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

有:如果我们有顺序调用-当一个组件调用另一个组件时，则
call 另一个， call 之间相互依赖:喜欢
Controller 调用Component，Component将一些数据保存到某些List
(这是可变的，但已同步为Synchronized-list)。

没有足够的空闲时间来由Akka actor或使用不同的服务器(不是Tomcat)来替换所有Spring Controller(没有太多的经理/产品所有者允许您这样做)

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

具有通过组件来的消息(用于包装来自actor的命令)的类，而不是调用常规方法(利用OPP的优点，实现接口(interface)，具有多个实现-但Actor通常final class)。

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

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

当Actors可用于现有应用程序时。用例可能是这样的:

当我们进行长期搜索时，它会涉及多个来源(线程 worker 的种类)。具有几/拉的MasterActor-> SiteSearchActor(就像描述用于计算PI here一样)。 MasterActor具有最终结果。 SiteSearchActor为多个客户端计算(在多个站点进行搜索)的位置。

或当我们有任何线程派生时，当前servlet中的

当我们确定/知道我们的系统将被数百万的客户使用(即使使用简单的逻辑)时，我们应该事先考虑scalability和performance(

Actor 的规模很好-我们可以将一件 Actor 从一位 Actor 委派给N位 Actor 。

actors使用线程时可以保护处理器类型(对于不需要 10000个线程 10000个客户端，在大多数情况下，足够 4个线程(与处理器核心的数量相同))

但总的来说，我同意this有关concurrency和parallelism的文章。如果我有机会从头开始制作应用程序，则可以在不使用Servlets容器和 的情况下使用Akka ，而不用关心何时需要使用消息(命令类)和 OOP 消息(一般来说OOP并不多) Web应用程序。无论如何我应该说，但是没有人能阻止以OOP方式保留一些业务逻辑，而参与者只是通信胶水)。例如，这比使用JMS更好/更简单。

但是就像我说的:

Actor /Akka擅长:

服务/ Controller (而不是Servlet/SpringMVC)

像逻辑

这样的线程 worker

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

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

having 10000 threads in one JVM with synchronized and locks for shared mutable data in our MVC Controllers/Services are might be very bad from the performance perspective. Since there are many possible locks, threads that are concurrent (a rival or competitor for a hared resource) to each other.

如果我们对AKKA/Servlet使用N(actor，其中N比1000多了，而比N多得多)具有相同的方案，那么我们很可能会具有更好的性能(因为除了队列本身之外，没有人阻塞任何人，因此无需切换一个线程到另一个线程)。

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

问题是:

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

Taking this is an argument: Even having an old system on Servers, with connection pool may improve the performance to a good level. And this level, most likely, might be good enough in order NOT to apply AKKA to existing Servlet application, like trying to change servlet model (that' supposed to be bad comparing to Controllers on top of AKKA).

这样思考是否有意义？

Consider connection pull is kind of INBOX (like in AKKA) scheduling the commands (connection).

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

使用连接池可能就足够了，在将Akka与基于servlet的东西进行比较时会忘记它。我们仍然可以调整应用程序，更改连接池中的MAX-CONNECTION。通常，我们会尽力使应用程序变为无状态，因此，在大多数情况下，我们不会同步任何内容。

但是，当然，只有不好。整个应用程序只有一个连接池。如果与Actor进行比较，则每个actor都有自己的连接池(邮箱)，并且每个actor可能负责接受HTTP请求。该模型肯定更好。

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

更新:
Some people认为使用Actors根本不是一个好主意。好的是-纯函数方法或 scalaz已经提供的功能(以及我猜的 Haskell)-但尚不能用于远程调用。