阿卡或反应堆

我正在开始一个新的项目(基于 java)。我需要把它构建成一个模块化、分布式和弹性的架构。

因此,我希望业务流程之间能够相互通信,能够互操作,也能够独立。

我现在看到的这两个框架,除了年龄上的差异,还表达了两种不同的观点:

在选择上述框架之一时,我应该考虑什么?

据我所知,到目前为止,阿卡仍然是某种耦合(在某种程度上,我必须’选择’演员,我要发送的消息) ,但非常有弹性。而反应堆是松散的(因为是基于事件发布)。

有人能帮我理解如何做出正确的决定吗?

更新

在审查更好的 活动巴士的阿卡,我相信在某些方面的 由反应堆表示的特性已经包括在阿卡。

例如,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");

因此,在我看来,两者之间的主要区别是:

  • 阿卡,更成熟,在 Typesafe
  • 反应堆,早期阶段,注定春天

我的解释正确吗? 但是 在概念上,阿卡的参与者和反应堆的消费者之间的区别是什么

37553 次浏览

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.

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.

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.

If you need something that does clustering right now, you'll be safer choosing Akka.

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.

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.

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.

Reactor is not bound to Spring, it's an optional module. We want Reactor to be portable, a foundation as Jon outlined.

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 Akka which is a fantastic asynchronous framework IMO. Also consider Vert.x and Finagle which 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 GPars will provide you a more complete solution.

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, Akka etc. We are not even opinionated by the language choice, even if we are strongly committed to Groovy, people have already started Clojure and Kotlin ports. Add to this mix the fact that some requirements are driven by Spring XD and Grails.

Many thanks for your witnessed interest, hopefully you'll have more comparison points in a couple of months :)