基于Netty的非阻塞REST框架

Vai*_*Raj 21 java rest nio resteasy netty

我正在开发一个需要高可伸缩性的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.我不认为我会在获得scalabiltiy方面帮助太大.
  4. RESTExpress - >它声称是基于Netty的RESTFull应用程序框架.但是,对于需要高度安全性的企业应用程序而言,它既没有一个像样的社区,也没有可信任(因为它是非常新的).

在得到上述发现之前,我想使用一些随时可用的框架并更快地完成工作.

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

Ada*_*ent 12

如果你真的想要非阻塞,你需要从头开始进行非阻塞,并拥有适当的REST客户端.否则,如我的评论中所述,性能差异可以忽略不计,并且在许多情况下NIO(带线程共享的Netty)更糟糕.

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

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


tru*_*tin 6

这是我知道的REST应用程序的微框架列表:

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