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