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