是否有 CGI 的替代方案（我真的需要一个）吗？
我正在设计一个应用程序，该应用程序将包含 3-4 个服务，这些服务作为单独的进程运行并通过合适的 IPC 链接。 该系统将有一个网络界面，我想使用那里的任何网络服务器。
应该在某个 URL 下访问 Web 界面，该 URL 允许同一 Web 服务器上的其他 URL 执行完全不同的操作。 我计划使用该 URL 下面的路径来指定 Web 界面应该执行的操作。 它具有供其他应用程序通过网络使用以及供人们在浏览器中交互的设施。
即兴工作，我的工作方式如下：
- 让网络服务器为它收到的每个请求启动一个 CGI 进程（如 Apache 中的 SetHandler），
- 让 CGI 连接到 IPC
- ，让它从后端服务获取所需的任何内容，
- 让 CGI根据服务的答案返回 HTML / XML 和任何 HTTP 状态
现在，我真正想要的是避免前两个步骤，或者如果我不能，避免第二个步骤，因为我担心我在浪费不必要的开销（来自其他应用程序的请求可能很频繁）的性能。
例如，PHP 可以打开与 MySQL 数据库的持久连接，该连接在脚本运行时仍然存在，并且下次不需要重新创建，尽管我不知道它们实际上是如何做到的。 另外，据我了解，Apache 模块在服务器启动时加载一次，因此这可能会删除第一步，但会将我与 Apache 联系起来。
那么，将特定 URL 的处理程序挂接到不同的 Web 服务器的好方法是什么？ 我不想处理 HTTP，否则我可能只是使用第二个服务器的代理设置，但这似乎是重新发明轮子。 如果您认为 CGI 很好，并且有处理大量类似结构请求的示例，请告诉我。
I am designing an application that is going to consist of 3-4 services that run as separate processes and are linked by a suitable IPC. The system is going to have a web interface and I want to use whatever webserver is there.
The web interface should be accessed under some URL that allows to have other URLs on the same webserver doing totally different things. I'm planning to use the path below that URL to specify what the web interface should do. It has facilities for use by other applications over the net and for humans to interact with in a browser.
Off the cuff, I'd work as follows:
- make the webserver fire up a CGI process for every request it receives (like SetHandler in Apache)
- let the CGI connect to the IPC
- let it get whatever it needs from the backend services
- let the CGI return HTML / XML and whatever HTTP Status based on the services' answers
Now, what I really want is to avoid the first two steps, or if I can't, avoid the second one, because I'm afraid that I'm wasting performance on unneccesary overhead (the requests coming from other applications might be frequent).
PHP, for example, can open persistent connections to a MySQL database that survive the script's runtime and don't need to be recreated next time, though I don't know how they actually do it. Also, as I understand it, the Apache modules are loaded once when the server starts, so that might remove the first step but would tie me to Apache.
So, what are good ways to hook a handler for specific URLs into different webservers? I don't want to handle the HTTP, otherwise I might just use a proxy setup to a second server, but it just seems to be so reinventing-the-wheel. If you think, CGI is fine and have examples where it handles large numbers of request of a similar structure, please let me know.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，我之前忽略了这一点。 在这里解释我的问题让我想到了这个问题：
OK, I overlooked this previously. Explaining my question here brought me onto it:
即使在中等负载下，CGI 也是一个相当不可扩展的野兽。 FastCGI 是一个选项，但您可能还会找到 mod_XXXX 包，其中 XXXX 是您的语言名称。 例如，有一个针对 ruby、perl 和 python 的 mod，可能还有其他几个。
Even under moderate loads, CGI is a pretty unscalable beast. FastCGI is an option, but you'll probably also find a mod_XXXX package where XXXX is the name of your language. There's a mod for ruby, perl, and python for instance and probably a fair few others.