我们在服务器上运行的节点应用程序受到了很多打击，必须编译一个zip文件才能下载。到目前为止效果很好但我很紧张我们会遇到性能成为问题的地步。 （该应用程序当前在ubuntu 14.04计算机上运行forever。）
我现在被要求为应用添加各种新功能，这些功能更加次要，不应该降低主要功能（zip下载）的性能。如果应用程序受到太多次攻击以支持主压缩过程，那么这些附加功能会失败是可以的。
这里的最佳做法是什么？为辅助功能创建REST API并将所有内容放入等待列表中？它肯定不足以创建第二个应用程序并在每次主zip过程完成时生成一个新进程？如何确保最多冗余？我不是在谈论多核cluster设置或load-balancing on NGINX，而是在应用程序级别上优先处理应用程序功能的智能方法。
我希望这不是太广泛。干杯
答案 0 :(得分：1)
首先，一切都应该使用异步I / O，服务器中的任何地方都没有同步I / O.这是构建可扩展的node.js服务器的第一条规则。
其次，应允许具有任何重要CPU使用率的最高优先级任务使用多个核心。如果您说，最高优先级的任务是创建zip下载，那么您应该确保该操作可以利用多个核心。
您可以通过群集（您的整个服务器运行多个实例，每个实例可以位于单独的核心上）或创建一组专门用于创建zip文件的进程，然后在主进程中创建工作队列来实现提供这些其他过程的工作，并从中获取结果。第二个选项可能比聚类更复杂，但它确实优先考虑zip文件的创建，因此只有一个核心服务于其他服务器需求以及所有其他处理zip文件创建的核心。群集共享所有服务器负责的核心。
在纯服务器应用程序级别，您的服务器可以维护所有传入工作的工作队列，无论哪种类型，它都可以优先处理该工作。例如，如果API调用进入并且队列中已经存在N个zip文件请求，则可能会立即使API调用失败，从而使其无法在服务器上构建。我不认为我会亲自推荐该解决方案，除非您的API调用操作非常繁重，因为如果开发人员经常只是失败，他们就很难可靠地使用您的API。他们通常会发现API有时候比定期失败更慢。
您甚至可能不需要使用队列，您可以使用计数器来跟踪进程中的ZIP文件请求数量＃34;但是您必须绝对确定在所有情况下，柜台都是准确的。如果计数器中出现累积错误，那么在服务器重新启动之前，您可能最终会失败所有API请求。