部署生产Node.js服务器

我已经编写了一个Node.js应用程序，我希望它可以在我们的一台生产机器上运行。这似乎是一个很普遍的要求，但我找不到合适的解决方案。是否存在用于部署生产Node.js应用程序的既定解决方案？

该应用程序很简单（<100 LOC），但是需要非常高效，可靠并且可以连续运行数年而无需重新启动。它将在大型站点上运行，每秒有数十个连接。（该应用程序不用作网络服务器，它只有JSON API）

这是我考虑过的方法，但我仍然不确定：

使用框架（例如Express）

由于该应用程序需要高性能且非常简单，因此我想避免以框架形式添加膨胀。

使用以下命令启动服务器 nohup

这里的主要问题是异常处理，我们（显然）不希望整个服务器由于异常而崩溃。据我了解，将整个应用程序包装在一个try {} catch {}循环中将无济于事，因为在发生异常之后，JavaScript解释器处于不可预测的状态。那是对的吗？

使用永远的东西

我已经在我们的FreeBSD机器上安装了Forever，这非常容易出错。最终产生了无尽的进程，这些进程无法从Forever中永久杀死。我不得不kill -9跑回机器，对在Forever上运行生产应用程序的信心不大。看来Upstart（类似的工具，但更通用）不会在FreeBSD上运行。

托管解决方案（例如Heroku，Rackspace，Amazon EC2等）

这可能是最简单的解决方案，但对于其他Web服务器，我们已经拥有了不错的硬件。出于财务考虑，这没有任何意义。

当然必须对此有一些确定的解决方案？我想念什么吗？

• 除非您想自己处理会话，Cookie，中间件等，否则，您应该真正使用框架（我建议使用类似Express的东西，因为它已经过实战测试）。快递真的很轻。
• 使用nohup启动服务器：您不应该这样做，只需使用常规的“ node”命令启动它即可。Express也将路由包裹在try-catch中，因此您的服务器不会在路由中崩溃。但是，如果您的服务器确实存在严重问题，则不必担心重新启动服务器（此外，如果至少有2-3个进程，那么只有一个进程会死掉，因此至少还有1-2个进程会消失，而用户不会感觉不到）。
• 为了进行监视，我个人更喜欢操作系统级别的功能，例如Upstart和Monit。
• 托管解决方案：由于您已经拥有了自己的严肃硬件，因此无需在其他方面投入资金。只需使用负载平衡器（可能是nginx或node-http-proxy）来代理东西。

请参阅托管节点应用程序。

本教程将引导您设置一个服务器，该服务器可以为服务器端JavaScript应用程序托管node.js应用程序。现在，node.js托管选项归结为正在运行的与Web服务器通信的节点守护程序进程。大多数Web服务器可以将连接代理到其他端口，因此您可以使用Apache或nginx进行此操作。

尝试使用pm2，它是简单直观的CLI，可通过NPM安装。只需使用PM2启动您的应用程序，您的应用程序即可处理大量流量

PM2官方链接

如何使用PM2设置Node JS应用程序以进行生产

我认为这里有三个问题。

问题0：“我应该为我的节点应用程序使用框架吗？”

问题1：“如何在生产计算机上运行节点服务器？”

问题2：“如何将节点应用程序部署到生产中”。

对于问题1，我非常喜欢Cluster（尽管最新的Node版本具有类似的内置功能，因此您可以检查一下）。我在Monit / Upstart之类的工具上取得了很好的成功，它可以监视操作系统级别的事件并确保您的服务器运行状况良好。（这是在监视Ruby Thin服务器的N个集群，但是是一样的）。

您可能要根据流量在多台计算机上运行群集，然后在其前面放置一个负载平衡器。这取决于您的流量，完成请求所需的时间/阻止事件循环的时间以及每台计算机启动的处理器/节点实例的数量。

框架可为您提供更好的错误处理，并捕获将退出常规node.js应用程序的错误。如果没有框架，请确保已阅读node.js中的错误处理。

对于问题2，我认为节点社区还没有良好的部署标准。您可以尝试使用Ruby的Capistrano工具（这是有关使用Capinstrano部署集群的博客条目）。

Capistrano的坏处在于，它做出了一些可能不正确的假设（即：您正在部署Rails项目），因此您最终可能会与框架发生很多争执。

通常，我的goto部署解决方案是Python的Fabric工具，该工具为您提供了部署工具，并使您可以做所需的事情。

另一个部署选项是“云”，它带有Nodester之类的东西：让他们来照顾它。

在ServerFault上可能会得到更好的答案，但是此处使用来描述一个用户的体验supervisord。您将需要使用某种类型的进程监视程序来使node进程保持活动状态，并且另一个常见的建议似乎是以node某种方式反向代理到该进程的连接。我可能会投票赞成nginx（通过这种方式，您可以nginx处理所需的日志记录，身份验证或任何其他更高级别的HTTP功能，而不是通过某种方式将它们烘焙到节点中），但是前面提到的文章haproxy在这里和那里的评论中都提到了可能更轻巧。您对反向代理的选择可能很大程度上取决于您是否需要WebSocket支持。

我不确定节点是否还存在“标准”工作流程；它还不像Rails那样成熟，它具有多种使Web应用程序运行的方法。

Cloudkick的家伙为此写了一个很好的解决方案。这就是所谓的Cast，http://cast-project.org/。

在您的服务器和工作站上安装cast。您在服务器上启动强制转换代理，并使工作站与服务器强制转换实例签名。然后，您可以创建“捆绑包”，将它们上传到服务器，从它们创建/升级/销毁以及启动/停止实例。当服务崩溃时，Cast将自动重新启动您的服务。您还可以远程拖尾stdout / strerr，以及获取正在运行的实例和PID＃的列表，并从工作站管理实例/服务器（无需SSH）。这些文档有些过时了，但是结果值得一点点额外的工作。所有的交互/命令都是通过HTTPS和RESTful API实现的。

在此之前，我是使用SCP / SSH手动进行所有升级的。我们一直supervise在努力。我们没有回头。