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


Example of integration Akka with existing java project

如果我已经有了使用spring和servlet容器的现有javaWeb应用程序。在其中整合Akka的正确方法是什么？

就像我要让Actor1和Actor2互相交流一样。开始使用这些演员的入口点是什么？(比如：1。把它放在那里2。更改配置3。获取对参与者的引用)

我找到了http://doc.akka.io/docs/akka/2.2-m3/general/configuration.html，但他没有给我胶水。只想得到真正的集成示例。

是否有一些简单的集成示例？

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

应用程序相当大。有些组件/对象可以离开自己的生命，也就是说脱离了直接的客户端请求，它可以做一些并行的事情。就像一些单例对象中有可变的状态。

问题是我不知道在哪里可以申请演员，我正在调查。但我已经有了很多同步块。

而且，我相信，这已经是演员可能被应用的某种迹象。(因为我不确定，可能我忘了放一些同步的，当然也没有集成测试)

关于配置，我只是不确定是否应该为let actrors/akka在那里配置application.conf(因为文档本身描述了它)。

我看到的：

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

我可以做得很好。

SomeManager用于controller中。所以，有一个控制者演员也很好？我想收到(onReceive方法)的反馈。

这是有争议的…这也是我需要一些例子的原因之一。

我相信我可以通过去掉所有的synchronized/whait/notify东西、将责任转移给参与者、使用消息作为与他们之间的通信方式来改进应用程序。

或者像这样，它可以是角色写入属性文件：

编辑：

例如，现在我发现：要使actor1向actor2发送消息，我使用一个技巧：

1
2
3
4
5
6
7
8
9
// 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发送消息：

1
2
@Override
public void preStart() {

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

相关讨论

回答我自己的问题。只是想分享我的想法，我的想法。好的。

如果我们已经有了基于servlets/spring mvc的现有工作Web应用程序，那么通常没有理由切换到Actors/AKKA(或将参与者引入现有系统，只是为了对其进行黑客攻击)，如果在我们的应用程序中我们：好的。

  • 不具有：线程工作者逻辑，当任务在后台被拆分时。(通常典型的Web应用程序没有此功能)，比如长时间计算。(平行)。
  • 有：如果我们有顺序调用——当一个组件调用另一个组件时，那么调用另一个，其中调用相互依赖：例如控制器调用组件，组件将一些数据保存到某个列表(可变，但同步为同步列表)。
  • 没有空闲时间用Akka Actors替换所有Spring控制器或使用不同的服务器(而不是Tomcat)(没有那么多经理/产品所有者允许您这样做)

在这个简单的系统中拥有参与者有什么问题：好的。

  • 通过组件而不是调用常规方法(使用opp的优势，实现接口，有几个实现，但参与者通常是final class)来传递大量消息(将命令包装到参与者/从参与者发出的类)。好的。

  • 把消息作为string来处理，也不是很好的解决方案，因为很难调试。好的。

  • 在这样一个系统中(比如MVC站点)，通常没有那么多东西需要同步(它已经相当于stateless)。通常每个控制器/组件中有0..2个mutable shared data。这并不难同步(只是养成一个习惯，把所有公共的和共享的东西放在类的顶部进行同步(这样状态就可以被识别/本地化)。有时您只需要EDCOX1×6或使用Java EDCOX1×7包装器类型。好的。

当参与者可能被用于现有应用程序时。用例可能如下所示：好的。

  • 当我们进行长期的搜索时，它会经过几个来源(类似线程工作者)。有多个/多个MasterActor->SiteSearchActor(就像这里描述的计算PI)。主宰者有最终的结果。其中，SiteSearchActor计算(搜索多个站点)多个客户机。
  • 或者当我们有任何线程分叉时，不使用当前的servlet分叉
  • 当我们确信/发现我们的系统将被数以百万计的客户机使用时(即使是简单的逻辑)，我们应该提前考虑scalability和performance。(
    • 演员很好-我们可以把一个作品从一个演员委托给N个演员。
    • actors在处理线程时最安全的处理器类型(10000个客户机不需要10000个线程，在大多数情况下，足够多的线程有4个线程(例如，与处理器核心的数量相同))。

但总的来说，我同意这篇关于concurrency和parallelism的文章。如果我有机会从头开始制作一个应用程序，我会在不使用servlets容器的情况下使用AKKA，并且在需要使用消息(命令类)和OOP时(一般Web应用程序中没有这么多OOP)。无论如何，我应该说。但是没有人会阻止以OOP的方式保留某些业务逻辑，行动者只是一种沟通粘合剂)。例如，这比使用JMS好得多/简单得多。好的。

但正如我所说：好的。

演员/Akka擅长：好的。

  • 服务/控制器(而不是servlet/SpringMVC)
  • 像逻辑这样的线程工作者
  • 尤其是对于从头开始的项目(当当前的基础结构不使您在应用actor one时遇到障碍时)。

    • 我现在唯一的问题是江户十一〔九〕号。假设我们知道：好的。

    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.

    Ok.

    如果对于带有n的akka/servlets(actors，其中n远小于1000)，我们有相同的场景，那么我们很可能会有更好的性能(因为除了队列本身之外，没有人阻止任何人，所以不需要从一个线程切换到另一个线程)。好的。

    但是，即使有一个为基于servlet(线程模型)的应用程序提供10000个客户机的系统，以及100个客户机，它也可能工作得很好。如果我们有一个连接池(当然我们有)，那么它与actor的队列(收件箱)的工作是相同的，它安排客户机访问某些服务。它可以在k次中提高我们的性能(其中k比没有pool-letting线程时的性能高出许多)。好的。

    问题是：好的。

    不将AKKA应用于现有的基于servlet的应用程序是一个很好的理由吗？好的。

    Taking this a an argument: Even having old system on Servlers, with
    connection pool may improve the performance to 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).

    Ok.

    这样想有意义吗？好的。

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

    Ok.

    即使servlets模型不好(处理来自连接池的连接创建的其余(活动)线程中的锁)。好的。

    连接池可能已经足够好了，在比较AKKA和基于servlets的东西时会忘记连接池。我们仍然可以调整应用程序，更改连接池中的max-connection。通常，我们会尽力使应用程序无状态，所以在大多数情况下，我们不会同步任何东西。好的。

    但当然，对于整个应用程序只有一个连接池是不好的。如果与参与者比较，每个参与者都有各自的连接池(邮箱)，并且每个参与者可能负责接受HTTP请求。那型号当然更好。好的。

    附笔。在大多数情况下**未来**已经足够好了。如果你想"安全"地将状态存储在其中(这与未来基本上是不同的)，那么参与者是好的。好的。

    更新：有些人认为使用演员一点都不好。好的是-纯功能方法或者scalaz已经提供的东西(我猜还有Haskell)，但是还没有远程调用。好的。好啊。

    我也遇到了类似的问题。

    我同意在少量用户的简单Web应用程序中添加AKKA几乎没有什么好处。

    但我不认为很难将Akka连接到现有的SpringMVC应用程序上。如果您的项目需要扩展，您可以将@service层包装成actors。因此，@控制器不需要在演员内部。

    以下是关于将Spring与Akka合并的演示：https://www.youtube.com/watch？V= FLUFF9BMQYY

    演示文稿的源代码：https://github.com/jsuereth/spring-akka-sample/tree/master/src/main/java/org/springframework/samples/travel