基于Netty的非阻塞REST框架

时间:2013-11-03 21:15:14

标签: java rest netty nio resteasy

我正在开发一个需要高可扩展性的RESTfull应用程序。我正在考虑基于Netty的RESTfull应用程序框架。我浏览了一些可用的选项,并尝试将它们作为非阻塞实现提供。以下是我的发现:

  1. rest.li - >仍处于基于Netty的NIO实施的实验阶段。所以,不准备生产。
  2. RESTEasy - >支持Netty 4.x的标准JBoss项目。但是,RESTEasy不是基于Netty的完整堆栈NIO实现,而是Netty和RESTEasy之间的缓冲交换。它没有利用Netty的优势。因此,可扩展性不如基于Netty的框架所预期的那么高。
  3. Netty-http组件 - >另一个选项是Apache Camel集成,同时使用Netty-http组件作为端点,将请求路由到bean中公开的服务。我认为它与RESTEasy相同,只有Netty-http组件使用基于Netty的NIO功能,而系统的其余部分将使用旧的IO。我认为我不会在获得可塑性方面做太多帮助。
  4. RESTExpress - >它声称是RESTFull应用程序的基于Netty的框架。但是,对于需要高度安全性的企业应用程序而言,它既没有一个体面的社区,也没有可信任(因为它是非常新的)。
  5. 在得到上述发现之前,我想使用一些随时可用的框架并更快地完成工作。

    我知道这是一个基于意见的问题。但是,我仍然非常需要帮助为我的应用程序选择正确的框架。如果以防万一,没有基于Netty的REST框架:在我的应用程序中使用基于Netty的低级NIO代码是否明智?任何帮助赞赏。提前致谢。

7 个答案:

答案 0 :(得分:12)

如果你真的想要非阻止,你需要从头开始进行非阻塞并拥有proper REST clients。否则如my comment中所述,性能差异可以忽略不计,并且在许多情况下NIO(Netty with thread sharing)更糟糕。

我知道只有两个库从头开始进行非阻塞Vert.x,有些Finagle(其他东西,如非阻塞数据访问)。

您还应该了解可以使用JAX-RS支持NIO的Tomcat和其他各种servlet容器。问题是,即使支持NIO,它仍然是每个请求的单个线程。只有Play,Finagle,Vert.x和纯Netty(不管NIO)支持不同的共享线程模型,因此具有不同的并发机制。

答案 1 :(得分:6)

以下是我了解REST应用程序的微框架列表:

请随时评论答案 - 我会更新答案以添加更多内容。

答案 2 :(得分:3)

你看过Play吗?

您似乎倾向于使用Netty,但如果您愿意环顾四周,那么非常简单的Grizzly + Jersey设置可能会表现得非常好。哎呀,一个简单的Glassfish 4.0 JAX-RS应用也可以很好用。

答案 3 :(得分:0)

您可以在Spring Framework 4.2.5.RELEASE中查看AsyncRestTemplate。它可以在Netty上使用。

  

注意:默认情况下,AsyncRestTemplate依赖于标准JDK工具来建立HTTP连接。您可以使用接受AsyncClientHttpRequestFactory的构造函数切换到使用不同的HTTP库,例如Apache HttpComponents,Netty和OkHttp。

答案 4 :(得分:0)

还有一个框架使用Netty和RxJava,它被称为datamill

如果您对使用功能性反应式风格构建Web应用程序感兴趣,那么应该考虑它。

答案 5 :(得分:0)

Spring 5附带了一个名为WebFlux的反应式Web框架。您可以选择Netty或Undertow等多个服务器。一个反应性非阻塞WebClient也被添加到Spring,它也支持反应性Mongo,Redis和Cassandra(我想更多即将推出)。

Spring的'Spring的观点'也将获得基于Spring 5的新版本(2.0)。在撰写本文时,它将于2月发布expected

有关Spring的反应堆栈的更多信息:https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html

答案 6 :(得分:0)

Undertow 3.0将位于Netty (instead of XNIO)的顶部。完美,超轻,简单的API,可构建诸如REST API服务器之类的应用程序。我将其用于几乎所有的Java微服务。