基於Netty的非阻塞REST框架

我正在研究一種需要高可伸縮性的RESTfull應用程序。我正在考慮基於Netty的RESTfull應用框架。我瀏覽了一些可用的選項，並試圖獲得他們可以提供的非阻塞實現。這裏是我的發現：基於Netty的非阻塞REST框架

rest.li - >仍然在基於Netty的NIO實現的實驗階段。所以，不準備生產。
RESTEasy - >支持Netty 4.x的標準JBoss項目。但是，RESTEasy不是基於Netty的完整堆棧實現，而是Netty和RESTEasy之間的緩衝區交換。它沒有考慮到Netty的優勢。因此，基於Netty的框架的可擴展性並不像預期的那麼高。
Netty的-HTTP組件 - >另一種選擇是Apache的駱駝集成度，同時使用了Netty-HTTP組件作爲路由請求從豆暴露在服務的端點。我認爲它與RESTEasy相同，只有Netty-http組件使用基於Netty的NIO功能，而系統的其餘部分將使用舊的IO。我認爲我不會在很大程度上提供幫助。
RESTExpress - >它聲稱是基於Netty的RESTFull應用框架。但是，它既沒有一個體面的社區，也沒有可信賴的（因爲它是非常新的），對於需要高度安全性的企業應用程序。

在得到上述發現之前，我想使用一些準備好的框架並使工作更快完成。

我知道這是一個基於觀點的問題。但是，我仍然非常需要幫助，爲我的應用程序選擇正確的框架。如果萬一，沒有基於Netty的REST框架：在我的應用程序中使用基於Netty的低級NIO代碼是否明智？任何幫助讚賞。提前致謝。

來源

2013-11-03 Vaibhav Raj

你可能會感到驚訝，BIO很多時候表現比NIO特別更好地爲短請求的情況下（即沒有保持活躍或網頁套接字）。大多數REST客戶端甚至REST通常都是短的請求。 –

使用NIO REST框架不會使您的應用程序具有神奇的可擴展性。讓你的應用程序無狀態並正確使用緩存標題是一個好的開始。 – eiden

@eiden我已經和Akka-Actors一起玩了遠程功能，使它成爲一個高度可擴展的分佈式應用程序。我只是想擺脫Servlet-API的阻塞性質。我已經開始和Spray + Akka Actors一起玩。 –

如果你真的想要非阻塞，你需要從頭開始非阻塞，並有proper REST clients。否則，如my comment中所述，性能差異可忽略不計，並且在許多情況下對於NIO（具有線程共享的Netty）而言更差。

我知道只有兩個庫從零開始非阻塞Vert.x並且有點Finagle（它缺少像非阻塞數據訪問的其他內容）。

您還應該瞭解Tomcat和可以與JAX-RS支持NIO一起工作的各種其他servlet容器。問題是即使支持NIO，它仍然是每個請求的單個線程。只有Play，Finagle，Vert.x和純Netty（不管NIO）支持不同的共享線程模型，因此具有不同的併發機制。

來源

2013-11-05 15:56:30

我沒有得到你想說的「正確的REST客戶端」。你能否給我提供更多的信息？感謝您的回覆。 –

我用鏈接編輯了答案。我的意思是支持永久連接或完全使用不同的協議。 Node.js和整個非阻塞/單線程事件循環的巨大推動力是因爲持久連接變得越來越普遍（Websockets，Comet等）。由於線程/請求，幾乎所有傳統的Java REST服務都會對流式REST API產生困難，因爲不管NIO如何，都會有10,000個長時間運行的請求。這就是說大多數REST客戶端會做GET/POST/DELETE/PUT作爲請求，然後立即關閉連接。 –