尋找一個無阻塞的方式來處理某一事件路由

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，所以這裏關於業務邏輯的擔憂並不總是適用。