我应该如何在同一系统上组织多个 Express 服务器?
我使用一台服务器来托管多个 Node.js Web 应用程序,这些应用程序分布在多个域中。我当前的做法是为不同端口上的每个应用程序运行 Express 服务器,并运行一个基本服务器,将请求简单地路由(重定向)到正确的端口/Express 服务器。这是可行的,但这意味着我的基础服务器正在路由每个 HTTP 请求(并通过手动重定向它),并且我的用户看到我的应用程序托管在 [hostname.com]:8000。
经过一番研究后,我发现我可以使用 http-proxy路由需求,但我仍然想知道是否有在同一系统上运行多个 Express 服务器的最佳实践。我打算这样做:
每个 Web 应用程序都有自己的文件夹,具有完整的 Express 文件夹结构(app.js、路由、视图等)。应用程序将按域分组,因此示例文件夹结构如下是:
hostname.com/
app.js
routes/
views/
...
app1/
app1.js
routes/
views/
...
app2
...
hostname2.com/
app.js
routes/
views/
...
我必须使用节点(或使用 永远 单独运行每个 app.js,我' m 当前正在使用),并且每个人都必须使用内部不同的端口,跨应用程序重定向指向目标应用程序的端口。
这就是我目前的计划。它有哪些问题,我应该尽量避免哪些陷阱? 最重要的是,是否有一个既定的解决方案来解决这个问题 - 使用 Node.js/Express 在同一系统上托管多个 Web 应用程序的问题?
编辑:我确实计划最终使用 WebSockets 和 HTTPS,并且我的设置可以支持的带宽量对我来说并不重要 - 这是一个开发服务器(至少目前如此)。感谢 David Ellis 提出 WebSockets 问题。
第二次编辑:感谢 EhevuTov 和 David Ellis 的回答,他们都提供了很大的帮助。我仍在确定我的应用程序的整体结构,看起来这个问题已由 这个 StackOverflow 问题
第三次编辑:自从发布这个问题以来,我已经取得了一些进展(尽管我还有很长的路要走)。查看我的 GitHub 存储库中的此文件,它利用了我的内容从这个问题的答案中学到了!
I'm using one server to host multiple Node.js web apps, which are distributed across multiple domains. My current practice is to run an Express server for each app on a different port, and to run a base server that simply routes (redirects) requests to the correct port/Express server. This works, but it means that my base server is routing every single HTTP request (and by manually redirecting it), and that my users see my apps as hosted at [hostname.com]:8000.
After a bit of research, I've found that I can use http-proxy for my routing needs, but I'd still like to know if there's a best practice for running multiple Express servers on the same system. Here's how I'm planning on doing it:
Each web app will have its own folder, with a complete Express folder structure (app.js, routes, views, etc.) Apps will be grouped by domain, so an example folder structure would be:
hostname.com/
app.js
routes/
views/
...
app1/
app1.js
routes/
views/
...
app2
...
hostname2.com/
app.js
routes/
views/
...
I'll have to run each app.js separately with node (or with forever, which I'm currently using), and each one will have to use a different port internally, with cross-app redirects being pointed at the port of the target app.
So, that's my current plan. What are the problems with it, and what pitfalls should I try to avoid?
Most importantly, is there an established solution to this problem - the problem of hosting multiple web apps on the same system with Node.js/Express?
EDIT: I do plan to eventually use WebSockets and HTTPS, and the amount of bandwidth my setup can support is of little importance to me - this is a development server (at least for now). Thanks to David Ellis for bringing up the issue of WebSockets.
SECOND EDIT: Thanks to both EhevuTov and David Ellis for their answers, both of which helped greatly. I'm still settling on an overall structure for my application, and it looks like that question is addressed in some detail by this StackOverflow question
THIRD EDIT: I've come a ways since posting this question (though I have much further to go). Check out this file in my GitHub repository, which leverages what I learned from the answers to this question!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
由于 Express 使用 Connect,我非常确定您可以使用 Connect 的虚拟主机中间件。它的运行方式与其他产品上的其他虚拟主机模块类似。我没有多个域来测试并向您展示正确的代码,但我认为它是这样的:
如果您发现一台 Express 服务器还不够,那么请考虑使用 API 中的 Node.Cluster 。如果这还不够,那么当前的做法是在 Express 服务器前面放置一个 asnyc 反向代理(例如 Nginx),并将代理指向您的 Express 服务器。
Since Express uses Connect, I'm pretty sure you can use Connect's virtual host middleware. It operates similar to other vhost modules on other products. I don't have multiple domains to test and show you proper code, but I would think it's something like this:
If you get to the point where one Express server isn't enough, then look into using the Node.Cluster from the API. If that also isn't enough, then the current practice is to put a asnyc reverse proxy such as Nginx in front of your Express servers and point the proxies to your Express servers.
如果您不需要使用 WebSocket(或任何 HTTP 1.1 功能),您可以使用 NginX 作为代理。
优点是 NginX 可以处理的总负载比 Node 更高(基本上是静态编译并专门用于此类事情),但你失去了传输任何数据的能力(一次发送较小的块)。
对于较小的站点,或者如果您不确定将来需要什么功能,最好坚持使用
node-http-proxy
并且仅在可以演示代理时才切换到 NginX是您服务器上的瓶颈。幸运的是,如果您稍后需要的话,NginX 的设置并不困难。If you don't need to use WebSockets (or any HTTP 1.1 feature, really), you can use NginX as your proxy instead.
The advantage is the total load NginX can handle versus Node is higher (being statically compiled and specialized for this sort of thing, basically), but you lose the ability to stream any data (sending smaller chunks at a time).
For a smaller site, or if you're unsure what features you'll need in the future, it's probably better to stick with
node-http-proxy
and only switch to NginX if you can demonstrate the proxy is the bottleneck on your server. Fortunately NginX isn't hard to set up if you do need it later.