当REST客户端和服务器在同一台服务器上时如何避免网络调用
我有一个 Web 应用程序，其中两个主要组件是网站（在 Groovy 和 Grails 中实现）和后端 RESTful Web 服务（使用 JAX-RS (Jersey) 和 Spring 实现）。这两个都将在 Glassfish 中运行。该网站将调用 RESTful Web 服务。在许多情况下，这些组件将驻留在单独的服务器上，因此网站将通过网络调用 RESTful Web 服务。但是，如果我在同一个 Glassfish 服务器中运行这两个应用程序，是否可以进行任何优化来避免网络调用？换句话说，我正在寻找一些与 EJB 的 REST 远程/本地接口等效的东西。谢谢！
I have a web application in which two of the major components are the website (implemented in Groovy and Grails) and a backend RESTful web service (implemented using JAX-RS (Jersey) and Spring). Both of these will be running in Glassfish. The website will make calls to the RESTful web service. In many cases, these components will reside on separate servers, so the website will make calls over the network to the RESTful web service. If, however, I run both applications in the same Glassfish server, are there any optimizations that can be made to avoid the network call? In other words, I'm looking for some equivalent of EJB's remote/local interfaces for REST. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不要担心网络呼叫。您的流量通常永远不会离开本地接口，因此您不会消耗任何带宽。序列化/反序列化会损失一些性能，但是您需要问自己，减少这种影响是否值得开发一个复杂的代理架构。我认为大多数情况下你会发现答案是否定的。
Don't sweat the network call. Your traffic will generally never leave the local interface so you won't be consuming any bandwidth. You lose a bit of performance from serialization/deserialization, but you'll need to ask yourself if reducing the impact of this is worth developing a complicated proxy architecture. I think it most cases you'll find the answer to be no.
不确定您是否会找到任何简单的解决方案：您当然可以添加自己的附加代理层，但我真的不会担心它。无论如何，本地网络 I/O（localhost 或 127.0.0.1）经过大量优化，您实际上不会注意到。
根据您的实现，Spring 确实支持许多远程技术（旧列表位于 http://static.springsource.org/spring/docs/2.0.x/reference/remoting.html），但你会发现所有这些的关键是网络传输：它们包装它以各种不同的方式，但最终几乎所有交钥匙远程技术都会在某个时间点进入网络。通过不使用 HTTP，您可能会获得一些效率，但您可能会失去通过使用 Jersey 获得的一些松散耦合。
如果您不太害怕紧密耦合，也许您可以将通过 Jersey 公开的实际对象放入 Glassfish 范围的 Spring 上下文中，并直接调用方法：尽管耦合更紧密，所以我建议坚持使用 HTTP 调用。
Not sure you will find any trivial solutions: you could of course add your own additional proxy layer, but I really wouldn't worry about it. Local network I/O (localhost or 127.0.0.1) is so heavily optimized anyway that you really won't notice.
Depending on your implementation Spring does support a number of remoting technologies (an old list is at http://static.springsource.org/spring/docs/2.0.x/reference/remoting.html), but you will find that key to all of these is the network transfer: they wrap it up in a variety of different ways but ultimately almost all turnkey remoting technologies drop into the network at some point in time. You may gain SOME efficiency by not having to use HTTP, but you will probably lose some of the loose coupling you gained by using Jersey.
If you are not too afraid to tightly couple maybe you can put the actual objects you are exposing via Jersey into a Glassfish-wide Spring context and invoke the methods directly: much tighter coupling though, so I'd say stick with the HTTP calls.
是的，如果您的服务器和客户端都驻留在同一个 JVM 中，您可以避免网络调用。您应该能够使用 Jersey Client API 创建您自己的 Connector 实现来覆盖默认 HTTP 调用并处理请求/响应。这是可以帮助您入门的博客 - http://www.theotherian.com/2013/08/jersey-2.0-server-side-client-in-memory-connector.html
恕我直言，应避免不必要的网络开销全部费用。尽管这种开销只有几毫秒，但在为您的 Web 应用程序构建功能时，您会增加此类服务调用，所有这些毫秒将在您的应用程序上增加大量的延迟。
Yes, you can avoid a network call if your server and client both reside in the same JVM. You should be able to use Jersey Client API to create your own implementation of Connector to override default HTTP calls and handle request/response. Here is the blog that can get you started - http://www.theotherian.com/2013/08/jersey-2.0-server-side-client-in-memory-connector.html
IMHO, an unnecessary network overhead should be avoided at all cost. Even though this overhead would be only a few milliseconds, but while building features for your web application, you would increase such services call and all these milliseconds will add up to a good amount of latency on your application.