Java 阿卡或反应堆
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/16595393/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Akka or Reactor
提问by David Riccitelli
I am in the process of starting a new project (java-based). I need to build it as a modular, distributed and resilient architecture.
我正在启动一个新项目（基于 Java）。我需要将其构建为模块化、分布式和弹性架构。
Therefore I would like to have the business processes to communicate among themselves, be interoperable, but also independent.
因此，我希望业务流程能够相互通信，可以互操作，但也可以独立。
I am looking right now at two frameworks that, besides their difference in age, express 2 different views:
我现在正在研究两个框架，除了它们的年龄差异外，还表达了两种不同的观点：
- Akka (http://akka.io)
- Reactor (https://github.com/reactor/reactor)
What I should consider when choosing one of the above frameworks?
在选择上述框架之一时，我应该考虑什么？
As far as I understand till now, Akka is still somehow coupled (in a way that I have to 'choose' the actor I want to send the messages to), but very resilient. While Reactor is loose (as is based on event posting).
到目前为止，据我所知，Akka 仍然以某种方式耦合（在某种程度上，我必须“选择”我想要向其发送消息的演员），但非常有弹性。而 Reactor 是松散的（基于事件发布）。
Can someone help me understand how make a proper decision?
有人可以帮助我了解如何做出正确的决定吗？
UPDATE
更新
After reviewing better the Event Busof Akka, I believe in some way the features expressed by Reactorare already included in Akka.
在仔细阅读了 Akka的Event Bus之后，我相信Reactor 表达的功能在某种程度上已经包含在 Akka 中。
For example the subscription and event publishing, documented on https://github.com/reactor/reactor#events-selectors-and-consumers, can be expressed in Akka as following:
例如订阅和事件发布，记录在https://github.com/reactor/reactor#events-selectors-and-consumers，可以用 Akka 表示如下：
final ActorSystem system = ActorSystem.create("system");
final ActorRef actor = system.actorOf(new Props(
new UntypedActorFactory() {
@Override
public Actor create() throws Exception {
return new UntypedActor() {
final LoggingAdapter log = Logging.getLogger(
getContext().system(), this);
@Override
public void onReceive(Object message)
throws Exception {
if (message instanceof String)
log.info("Received String message: {}",
message);
else
unhandled(message);
}
};
}
}), "actor");
system.eventStream().subscribe(actor, String.class);
system.eventStream().publish("testing 1 2 3");
Therefore it seems to me now that the major differences between the two are:
因此，现在在我看来，两者之间的主要区别是：
- Akka, more mature, bound to Typesafe
- Reactor, early stage, bound to Spring
- Akka，更成熟，绑定Typesafe
- Reactor，早期阶段，绑定到 Spring
Is my interpretation correct? But what is conceptually the difference between the Actor in Akka and the Consumer in Reactor?
我的解释正确吗？但是Akka 中的 Actor 和 Reactor 中的 Consumer 在概念上有什么区别？
回答by Jon Brisbin
This is an excellent question and the answer will change over the weeks to come. We can't make any promises of what inter-node communication will look like right now just because it's too early. We still have some pieces to put together before we can demonstrate clustering in Reactor.
这是一个很好的问题，答案将在未来几周内发生变化。我们不能仅仅因为现在太早而对节点间通信的样子做出任何承诺。在我们演示 Reactor 中的集群之前，我们还有一些东西要放在一起。
With that said, just because Reactor doesn't do inter-node comms OOTB doesn't mean it can't. :) One would only need a fairly thin network layer to coordinate between Reactors using something like Redis or AMQP to give it some clustered smarts.
话虽如此，仅仅因为 Reactor 不进行节点间通信 OOTB 并不意味着它不能。:) 只需要一个相当薄的网络层就可以使用 Redis 或 AMQP 之类的东西在 Reactor 之间进行协调，以赋予它一些集群智能。
We're definitely talking about and planning for distributed scenarios in Reactor. It's just too early to say exactly how it's going to work.
我们肯定是在讨论和规划 Reactor 中的分布式场景。现在说它会如何运作还为时过早。
If you need something that does clustering right now, you'll be safer choosing Akka.
如果您现在需要一些可以进行聚类的东西，那么选择 Akka 会更安全。
回答by Roland Kuhn
It is hard to tell at this point because Reactor is still a sketch and I (Akka tech lead) do not have insight into where it will go. It will be interesting to see if Reactor becomes a competitor to Akka, we are looking forward to that.
现在很难说，因为 Reactor 仍然是一个草图，我（Akka 技术负责人）不知道它会去哪里。看看 Reactor 是否会成为 Akka 的竞争对手会很有趣，我们很期待。
As far as I can see, from your requirements list Reactor is missing resilience (i.e. what supervision gives you in Akka) and location transparency (i.e. referring to active entities in a fashion which lets you abstract over local or remote messaging; which is what you imply by “distributed”). For “modular” I do not know enough about Reactor, in particular how you can look up active components and manage them.
据我所知，从您的需求列表中，Reactor 缺少弹性（即在 Akka 中为您提供的监督）和位置透明性（即以一种方式指代活动实体，让您可以对本地或远程消息进行抽象；这就是您暗示为“分布式”）。对于“模块化”，我对 Reactor 知之甚少，尤其是如何查找活动组件并管理它们。
If you start a real project now and need something which satisfies your first sentence, then I don't think it would be controversial to recommend Akka at this point (as Jon also noted). Feel free to ask more concrete questions on SO or on the akka-user mailing list.
如果你现在开始一个真正的项目并且需要满足你第一句话的东西，那么我认为此时推荐 Akka 不会有争议（正如 Jon 也指出的）。请随时在 SO 或akka-user 邮件列表上提出更具体的问题。
回答by Stephane Maldini
Reactor is not bound to Spring, it's an optional module. We want Reactor to be portable, a foundation as Jon outlined.
Reactor 没有绑定到 Spring，它是一个可选模块。我们希望 Reactor 是可移植的，这是 Jon 概述的基础。
I won't be confident about pushing in production as we are not even Milestone (1.0.0.SNAPSHOT), in that regard, I would have a deeper look at Akkawhich is a fantastic asynchronous framework IMO. Also consider Vert.xand Finaglewhich might be adapted if you look either for a platform (the former) or for composable futures (the latter). If you look after a wide range of asynchronous patterns, maybe GParswill provide you a more complete solution.
我对推动生产没有信心，因为我们甚至不是 Milestone (1.0.0.SNAPSHOT)，在这方面，我会更深入地研究Akka，这是一个非常棒的 IMO 异步框架。还可以考虑Vert.x和Finagle，如果您寻找平台（前者）或可组合的期货（后者），它们可能会被改编。如果您关注广泛的异步模式，也许GPars会为您提供更完整的解决方案。
In the end, we might certainly have overlaps, in fact we're leaning toward a mixed approach (flexible composable eventing, distributed, and not bound to any dispatching strategy) where you can easily find bits from RxJava, Vert.x, Akkaetc. We are not even opinionated by the language choice, even if we are strongly committed to Groovy, people have already started Clojureand Kotlinports. Add to this mix the fact that some requirements are driven by Spring XDand Grails.
最后，我们肯定会有重叠，事实上我们倾向于混合方法（灵活的可组合事件，分布式，并且不受任何调度策略的约束），您可以轻松地从RxJava、Vert.x、Akka等中找到位. 我们甚至对语言选择没有自以为是，即使我们坚定地致力于 Groovy，人们也已经开始Clojure和Kotlin 移植。再加上一些需求是由Spring XD和Grails驱动的事实。
Many thanks for your witnessed interest, hopefully you'll have more comparison points in a couple of months :)
非常感谢您的关注，希望您在几个月内有更多的比较点:)
