寻找一个无阻塞的方式来处理某一事件路由

Question

我正在考虑以下用例使用的技术：

系统是事件驱动的 存在流量（其中大部分是没有叉子除了错误处理） 流本身应该是同步的，但无阻塞

我迄今为止的可能性是：

1. 纯java - 这使代码不太清楚，因为我有筑巢在彼此内部 回调，并有写都要亲力亲为
2. Apache的骆驼 - 使用骆驼的路线 即：

 
    from(URI) 
    .transform(creatUserExpression) //prepare msg to send to db 
    .inOut(DB.URI) //send to db 
    .transform(UserCreatedExpression) //prepare msg to send to next step 
    .inout(OtherService.URI) 
    .end(); 

这看起来像一个很好的解决方案，但骆驼适合处理我的所有业务逻辑 - 事件的所有流程？ 骆驼主要用于服务之间的整合，所以我们不知道这是否是正确的使用它的商业逻辑

java的RX - 看起来像一个可能的选择，仍然不够了解，生产是否准备好了？ 当前版本是0.20.7 - 还不是1.X版本

akka - 试图使用它的流量 - 但为了确保流量只有一种方式，我们需要使用FSM导致代码过于复杂，我们决定不这么做

任何其他建议可以理解

Answer 1

我同意你最典型的尝试和尽可能多的业务逻辑集成路线明确入住时间。 ESB上的业务逻辑通常是一个很大的问题，我认识的一些更僵化的架构师会在集成层中看到业务逻辑时闯入暴力脏话。当您使用ESB系统集成服务时，这种观点很有意义。

在SOA /服务世界中，您不希望生产者和消费者紧密耦合，并且向集成层添加业务逻辑会打破抽象。消费者应该能够使用来自SAP系统，C＃Web服务，Java服务或任何其他服务的数据，而无需知道生产者如何工作。它应该只是了解数据。

Apache Camel不是ESB，它是一个EIP工具包/框架。您也可以在客户端应用程序中使用Apache骆驼。这是我真正对骆驼情有独钟的原因之一。这是我可以用来创建整合路线的库。它非常灵活，可以在不需要全面服务器的情况下使用。

所以在你的情况下，我没有看到使用apache骆驼这个目的的问题。如果您要安装ServiceMix，FuseESB或另一个完整的ESB系统，您只会过分复杂化整个设置。

我的建议（这只是一个建议）是，在这种情况下，在你的路线中有业务逻辑不会是坏事，因为这不是真的（从你的描述）关于整合，而是利用骆驼的力量创造并维护一个事件系统。请记住，骆驼不带有运行时环境，因此您仍然需要在某个地方托管此路线。一个简单的运行时容器将是Apache Karaf。你可以使用这个OSGi内核来安装和运行你的路由。上次我检查Karaf项目就像解压缩到40MB以下，所以与其他一些运行时间相比，它非常小。

我已经使用Camel以这种方式为Android客户端创建和托管服务。我想我的主要信息是，骆驼可以被视为一个专注于集成的路由引擎或路由引擎生成器。骆驼不是ESB，所以这里关于业务逻辑的担忧并不总是适用。