关于javascript:Node.js大型应用程序的可靠性

Node.js reliability for large application

我是Node.js的新手,目前正在质疑它的可靠性。

基于我到目前为止看到的,似乎存在一个重大缺陷:任何未捕获的错误/异常都会导致服务器崩溃。当然,您可以尝试对代码进行防弹或在关键区域放置try / catch,但几乎总会有漏洞漏掉。如果一个有问题的请求可能影响所有其他请求,这似乎很危险。我发现有2种解决方法:

  • 使用守护程序或永久模块在崩溃时自动重启服务器。我不喜欢的事情是服务器仍然停机一两秒(对于一个大型站点,可能是数百(数千?)的请求)。

  • 使用process.on('uncaughtException')捕获未捕获的异常。这种方法的问题(据我所知)是没有办法获得引起异常的请求的引用。因此,特定请求被挂起(用户看到加载指示符直到超时)。但至少在这种情况下,仍然可以处理其他无问题的请求。

  • 任何Node.js老手都能投入吗?


    对于自动重启和负载平衡,我建议你查看Learnboost的平衡器。

    它允许您在负载均衡器后面重新加载工作程序,而不会丢弃任何请求。它会停止向工作人员发送新请求,但是对于已经提供服务的现有请求,它会提供workerTimeout宽限期,以便在真正关闭进程之前等待请求完成。

    您可以将此策略调整为也由uncaughtException事件触发。


    您可以完全控制基本过程,这是一项功能。

    如果将Node与Apache / PHP设置进行比较,后者实际上只相当于拥有一个简单的Node服务器,该服务器将每个传入请求发送到它自己的进程,该进程在处理请求后终止。

    如果您愿意,可以在Node中进行设置,在许多情况下,这样的设置可能是个好主意。关于Node的好处是你可以打破这种模式,例如你可以让主进程或另一个永久进程在请求传递给它的处理程序之前进行会话处理。

    Node是一个非常灵活的工具,如果您需要这种灵活性,这是很好的,但它需要一些技巧来处理。


    如果未捕获,未捕获的异常将使服务器崩溃。像调用拼写错误的函数一样的东西。我使用process.on('uncaughtException')来捕获此类异常。如果您使用它,是的,发送到process.on('uncaughtException')的错误信息量较少。

    我通常包含一个像nomnom这样的模块来允许命令行标志。我包括一个名为--exceptions的,当设置时,绕过process.on('uncaughtException')。基本上,如果我发现未捕获的异常正在发生,那么我在开发中使用--exceptions启动应用程序,以便在引发该错误时不会捕获它,这会导致Node吐出堆栈跟踪然后死掉。这告诉你它发生了什么,以及在什么文件中。

    捕获异常是处理异常的一种方法。但是,就像你说的那样,这意味着如果发生错误,可能会导致用户没有收到回复,等等。我实际上会建议让错误导致服务器崩溃。 (我在应用程序中使用process.on('uncaughtException'),而不是web服务器)。永远使用。事实是,网络服务器可能更好地崩溃,然后暴露您需要修复的内容。

    假设您使用的是PHP而不是Node。 PHP不会突然崩溃服务器(因为它没有真正服务)。它吐出了非常丑陋的错误。当然,它不会导致整个服务器停机,然后不得不重新启动。没有人希望他们的客户有任何停机时间。但这也意味着问题将持续存在并且不那么明显。我们都看到过有错误的站点,并且它们没有得到很快修补。如果这样的错误是把一切都放下来进行一次小昙花一现(说实话,在大图中并不是那么糟糕)那么它肯定会引起人们的注意。您会看到它发生并将跟踪该错误。

    事实是,任何系统中都存在错误,与语言或平台无关。为了让你知道它们发生了,它们可能会更好地致命。随着时间的推移,它会让您更加了解这些错误是如何发生的。我不了解你,但我知道很多PHP开发人员一次又一次地犯同样的错误。


    异常不会使服务器崩溃,它们会引发异常。

    node.js中导致整个过程失败的错误是另一回事。

    您最好的选择(您应该使用任何技术),只需尽快测试您的应用程序,看它是否合适。