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

Example of integration Akka with existing java project

提问by ses

If I already have existing javaweb application that uses springand servletcontainer. What is the proper way to integrate Akka in it?

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

Like I'g going to have Actor1and Actor2that communicate with each other. What would be the entry point to start using those actors? (like: 1. put it there 2. change config 3. get reference to actor)

像I'g将不得不Actor1和Actor2与相互通信。开始使用这些演员的切入点是什么？（例如：1. 把它放在那里 2. 更改配置 3. 获取对演员的引用）

I found http://doc.akka.io/docs/akka/2.2-M3/general/configuration.htmlBut his does not provide me a glue. Just want to get real example of integration.

我找到了http://doc.akka.io/docs/akka/2.2-M3/general/configuration.html但他没有为我提供胶水。只是想获得集成的真实示例。

Is there some simple integration example?

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

EDIT:Application does some search, getting some data from outside, storing info to files.

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

The application is quite big. Some components/object can leave their own life, that is out of direct client requests, it can do some things is parallel. Like some singleton objects that has mutable state in it.

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

The thing is I do not know exactly where I can apply Actors, I'm investigation it. But what I have already is lots of synchronized blocks here and there.

问题是我不知道我可以在哪里应用演员，我正在调查它。但是我已经有很多同步的块在这里和那里。

And, it is already, I believe, kind of sign that the actors might be applied. (because I'm not sure, maybe I forgot to put some synchronized, and of course there are no integration tests for it)

而且，我相信，这已经是演员可能会被应用的迹象。（因为我不确定，也许我忘了放一些synchronized，当然也没有针对它的集成测试）

About configuration, I'm just not sure should I configure some application.conf for let Actrors/Akka live there (since documentation itself describes it).

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

What I see:

我所看到的：

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

I could make it SomeManagerActor

我可以做到 SomeManagerActor

SomeManageris used from controller. Thus, it would be nice to have controller Actor as well ? I it want to receive feedback into (onReceive() method).

SomeManager使用自controller. 因此，也有控制器 Actor 会很好吗？我想将反馈接收到 ( onReceive() 方法中）。

This is kind of disputable... That's one more reason why I need some example.

这有点有争议......这是我需要一些例子的另一个原因。

I believe I can improve application by getting rid of all synchronized/whait/notifystuff, moving responsibilities to actors, using messages as a way of communication with/between them.

我相信我可以通过摆脱所有synchronized/whait/notify东西，将责任转移给演员，使用消息作为与他们/他们之间的交流方式来改进应用程序。

Or like thisit could be the actor to write to property files:

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

EDIT:

编辑：

For example, for now what I found: To make Actor1 send message to Actor2 I use a trick:

例如，现在我发现：为了让 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 has a method preStart()that is started as soon as I get reference to it (above). And it sends message to Actor2:

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.

但我不确定为什么初始化两个演员来完成他们的工作是好的。

回答by ses

Answering my question. Just to share my thoughts, what I came up with.

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

If we already have existing working Web application based on Servlets/Spring MVC, it seems that often there is no good reason switching to Actors/AKKA(or introducing actors to the existing system just for hack of it) if in our application we:

如果我们已经基于Servlet的/ Spring MVC的现有工作的Web应用程序，似乎往往没有好的理由切换到Actors/ AKKA（或引入者对现有系统只是为了破解版）如果我们的应用：

• Don't have:Thread workerslogic when tasks are splitting over the background. (usually, the typical web application doesn't have this), like long long calculations. (parallelism).
• Have:If we have sequential calls - when one component calls another one, then that calls another one, where the calls are depended on each other: Like Controllers call Component, Component save some data to some List (which is mutable, but synchronized as Synchronized-list ).
• Do not havefree time to replace all Spring Controllers by Akka actors or using different servers at all (not Tomcat) (there are not so many managers/product owners who would allow you to do that)

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

What is wrong having Actors in this simple system:

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

• Having tons of messages(classes that wrap commands to/from actors) that come through the components instead of calling general methods(using advantages of OPP, implementing interfaces, having several implementations - but Actors usually final class).

• Having messages as a string, not a good solution either - since it's hard to debug.

• In such a system (like MVC site), usually, there are no so many things to synchronize (it is already quite stateless). There are 0..2 mutable shared datain each Controller/Component. Which is not so hard to synchronize (just make a habit to put synchronize everything common and shared at the top of your classes (so that states are recognizable/localized). Sometimes you just need to synchronized collectionor use java Atomicwrapper type.

• 有大量的消息（包装到/来自actor的命令的类）通过组件而不是调用通用方法（使用OPP的优点，实现接口，有几个实现——但通常是Actors final class）。

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

• 在这样的系统中（比如MVC站点），通常没有那么多东西需要同步（已经相当了stateless）。mutable shared data每个控制器/组件中有 0..2 个。这并不难同步（只需养成将所有公共和共享的同步放在类顶部的习惯（以便状态可识别/本地化）。有时您只需要synchronized collection或使用 javaAtomic包装器类型。

When the Actors might be used though for an existing application. Use cases are might be like this:

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

• when we have long-lived search, that goes through several sources (kind of thread worker). Having several/pull of MasterActor-> SiteSearchActor(like it was described for computation PIhere). The MasterActor has the final result. Where SiteSearchActor calculates (do search over several sites) for several clients.
• or when we have any thread forks, out of current servlet ones
• when we know for sure / figured out that our system will be used by millions of clients (even with simple logic), we should think in advance about scalabilityand performance(
  • actors scale good - we can delegate one work from one actor to N-ones.
  • actors safes processor type when working with threads (no need 10000 threadsfor 10000 clients, in most cases enough have 4 threads(the same amount as processors core let's say) )

• 当我们进行长期搜索时，它会通过多个来源（一种线程工作者）。有几个/拉MasterActor-> SiteSearchActor（就像PI这里描述的计算一样）。MasterActor 有最终结果。SiteSearchActor 为多个客户端计算（在多个站点上搜索）的地方。
• 或者当我们有任何线程分叉时，在当前的 servlet 中
• 当我们确定/弄清楚我们的系统将被数百万客户使用时（即使是简单的逻辑），我们应该提前考虑scalability和performance（
  • 演员的规模很好——我们可以将一位演员的一项工作委托给 N 个演员。
  • 演员保险箱使用线程时，处理器类型（无需10000个螺纹为10000级的客户，在大多数情况下，有足够4个线程（相同数量的处理器核心假设））

But in general, I agree with thisarticle about concurrencyand parallelism. If I have chance to make an application from scratch, I would use Akka without Servlets containerand caring somehow about messages(command classes) and OOPwhen it needs to be used (there are not so many OOPin general web-applications. I should say anyway. But nobody prevent keep some business logic in OOPway, actors just a communication glue). That is much better/simpler than using JMS for example.

但总的来说，我同意这个文章关于concurrency和parallelism。如果我有机会，使从头开始申请，我会用阿卡没有的Servlet容器和有关消息的关怀不知何故（指挥类）和OOP时需要使用它（有没有这么多OOP在一般的网络应用程序。我应该说无论如何。但没有人阻止保留一些业务逻辑OOP，参与者只是一种通信胶水）。例如，这比使用 JMS 好/简单得多。

But like I said:

但就像我说的：

Actors / Akka is good for:

演员 / Akka 适用于：

1. Services/Controllers (instead of Servlet/SpringMVC ones)
2. Thread workers like logic
3. Especially for a project from scratch (when current infrastructure does not make you barriers applying actor one).

1. 服务/控制器（而不是 Servlet/SpringMVC 的）
2. 线程工作者喜欢逻辑
3. 特别是对于从头开始的项目（当当前的基础设施不会使您成为应用演员的障碍时）。

---

---

The only question I have now is performance comparison. Assuming we know that:

我现在唯一的问题是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.

在一个 JVM 中拥有 10000 个线程，并且在我们的 MVC 控制器/服务中为共享可变数据提供同步和锁，从性能的角度来看，这可能非常糟糕。由于有许多可能的锁，线程彼此并发（共享资源的竞争者或竞争者）。

If we have the same scenario for AKKA/Servlets with N (actors, where N much more lessthan 1000), we most likely would have much better performance (since nobody blocks anyone, except the queue itself, no need to switch from one thread to another).

如果我们对 AKKA/Servlets 有相同的场景，有 N 个（演员，其中 N 远小于1000），我们很可能会有更好的性能（因为除了队列本身，没有人阻止任何人，不需要从一个线程切换到另一个）。

But even if having a system with 10000 clients for Servlet based (thread model) application, with 100 clients it might work very well. And If we have a pool of connection (certainly we have) it does the same work as Actor's queue (inbox), scheduling clients to have access to some piece of service. It could improve our performance in K times (where K is much more that if we didn't have a pool - letting thread block each other desperately).

但是，即使系统有 10000 个客户端用于基于 Servlet 的（线程模型）应用程序，100 个客户端也可能工作得很好。如果我们有一个连接池（当然我们有），它会做与 Actor 的队列（收件箱）相同的工作，安排客户端访问某些服务。它可以将我们的性能提高 K 倍（如果我们没有池，K 会更多 - 让线程拼命地相互阻塞）。

The question is:

问题是：

Is it a good reason to not apply AKKA for existing servlet based application?

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

Taking this is an argument: Even having an old system on Servers, with connection poolmay 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).

这是一个论点：即使在服务器上使用旧系统， connection pool也可以将性能提高到一个很好的水平。而且这个级别很可能已经足够好，以便不将 AKKA 应用于现有的 Servlet 应用程序，例如尝试更改 servlet 模型（与 AKKA 之上的控制器相比，这应该是糟糕的）。

Does it make sense to think like this?

这样想有意义吗？

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

考虑连接拉取是一种 INBOX（如在 AKKA 中）调度命令（连接）。

Even if Servlets model is bad(having a deal with locks in the rest(active) thread that is creating by connection coming from connection pool).

即使Servlets 模型不好（处理由来自连接池的连接创建的其余（活动）线程中的锁）。

It might be good enough with the connection pool, which is forgotten when comparing Akka to servlets based stuff. We still can tune our application, changing MAX-CONNECTION in the connection pool. And usually, we do all our best to make application stateless, so, in most cases, we do not synchronize anything.

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

But of course, it is bad having only Oneconnection pool for Wholeapplication. If comparing to Actors each actor has each own connection pool (mailbox), and each actor might be responsible for accepting HTTP requests. That model certainly better.

但是当然，整个应用程序只有一个连接池是不好的。如果与 Actor 相比，每个 Actor 都有自己的连接池（邮箱），并且每个 Actor 可能负责接受 HTTP 请求。那个模型肯定更好。

P.S. In most cases, Futures are good enough. Actors are good if you want "safety" to store the state in it (that differs it from the Future basically).

PS 在大多数情况下，Future已经足够好了。如果您希望“安全”将状态存储在 Actors 中（这与 Future 基本上不同），Actors 是很好的。

UPDATE:Some peoplebelieve that it is a bad idea at all to use Actors. What is good is - pure functional approach or something that scalazalready provides (as well as HaskellI guess) - but not for remote calls yet.

更新：有些人认为使用 Actors 是一个坏主意。什么是好的 - 纯函数方法或scalaz已经提供的东西（以及Haskell我猜的） - 但还没有用于远程调用。

回答by Kaspars Rinkevics

I have come across a similar problem.

我遇到了类似的问题。

I agree that there is little benefit of adding AKKA to simple web appliaciton with a small number of users.

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

But I don't think that it is hard to attach AKKA to existing spring mvc app. In case your project needs to scale you can wrap your @Servicelayer into actors. Hence, @Controllersdo not need to be inside actors.

但我认为将 AKKA 附加到现有的 spring mvc 应用程序并不困难。如果您的项目需要扩展，您可以将@Service层包装到角色中。因此，@Controllers不需要在 actor 内部。

Here is a presentation on merging spring with akka: https://www.youtube.com/watch?v=fALUf9BmqYE

这是关于将 spring 与 akka 合并的演示：https: //www.youtube.com/watch?v =fALUf9BmqYE

Source code for the presentation: https://github.com/jsuereth/spring-akka-sample/tree/master/src/main/java/org/springframework/samples/travel

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