1

我对我正在处理的应用程序的设计有疑问。

我制作了一个 24/7 开放的单片 Java 应用程序，类似于游戏服务器。我只是想说它是一个单一的 jar 应用程序，而不是一个基于模块化 servlet/页面的 Web 应用程序。

我现在想向这个应用程序添加一个 RESTful API。因此人们/客户可以向我的应用程序发出 HTTP 请求以获取某些信息。由于我的 java 应用程序的整体性，我不确定如何实现它。另一件重要的事情：我期望每秒有多个请求，所以如果我可以让现有的 http 服务器处理请求，并以某种方式将它们转发到我的应用程序以设置回复，并让 http 服务器发送，那就太好了再说一遍。

我想到的一些事情：

  • 将我的应用程序包装在 tomcat 应用程序中，尽管我不确定 tomcat 是否可以连续运行应用程序，而不是根据请求映射到 servlet。

  • 打开一个套接字并自己解析传入的http请求（或者可能有一个lib？）。我担心这会对性能产生影响，并且宁愿使用现有的 http 服务器，因为它们针对高流量进行了优化。

  • 使用现有的 http 服务器来处理请求（apache、lighttp、...）并让它通过 scgi 之类的东西将请求转发到我的应用程序，或者使用可以通过 XMLRPC 转发的服务器。是否有任何其他技术/协议可以做到这一点？

关于如何处理这个问题的任何建议？谢谢！

4

1 回答 1

0

我会尽可能将您的 RESTful 服务端点与您的原始应用程序分离。这允许您进行扩展（为您的 REST 端点添加多个服务器），还可以更改您的原始应用程序，而无需直接更改您的 REST API。

Clients <== REST (HTTP) ==> RESTful endpoint <== legacy (sockets) ==> Legacy backend

因此，您的 REST 服务器一方面是您的客户的服务提供者，但同时也代表您原始后端的客户。

我将设计 RESTful API，然后选择一个现有的 Java REST 框架，如 Restlet，并实现 REST 服务本身。同时，您可以使用套接字开始在 REST 服务器和原始后端之间实现网关。

注意可伸缩性和性能（即，您可能希望将连接池用于rest <=> backend桥接，而不是为每个传入的 API 请求生成套接字）并考虑 HTTP 的可能优势。只要您的后端应用程序逻辑允许，当您能够使用缓存等时，您可能会受益。

于 2011-01-07T15:23:07.783 回答