为大量外部 API 请求扩展软件/硬件？答案

【问题标题】：Scaling Software/Hardware for a Large # of External API Requests?为大量外部 API 请求扩展软件/硬件？
【发布时间】：2011-11-15 01:42:19
【问题描述】：

我们有一个系统，它给出一批请求，对外部 3rd 方 API 进行等量调用。鉴于这是一个 I/O 绑定任务，我们目前使用大小为 20 的缓存线程池来服务这些请求。除上述以外，还有以下解决方案：

使用更少的机器和更多的内核（更少的上下文切换，能够支持更多的并发线程）

或

利用商品/廉价硬件（披萨盒）使用更多机器

我们每天收到的请求数量约为数百万。

我们使用的是 Java，所以这里的线程是内核，而不是“绿色”。

其他观点/想法：

【问题讨论】：

你有共享状态，用来处理请求吗？如果是这样，它的变化频率如何？这个共享状态的大小是多少？
第 3 方 api 有什么限制？如果您调用的 API 仍然是瓶颈，那么扩展您的堆栈是没有意义的。您可以缓存从它接收到的数据，或者使用一次调用服务/同时提供多个客户端的数据吗？
编辑了我原来的帖子来回答上面的问题。调用是完全独立的，所以没有数据需要缓存。

【解决方案1】：

在我看来，您根本不需要更多资源（更大的机器或更多的机器）。如果您说的是一天内最多 1000 万个请求，每个请求最多需要 2 秒，这意味着：

每秒约 110 个请求。那不是那么快。要求特别大吗？还是有大爆发？除了分派到第三方 API 之外，您是否还在进行繁重的处理？到目前为止，您还没有给我任何信息，这使我相信不可能在单个核心上运行您的整个服务。（如果您想拥有 n+2 冗余，请将其称为三台最小的机器。）
平均约 220 个活动请求。同样，对于单台机器来说，这似乎没有问题，即使使用（池化的）每个请求线程模型也是如此。你为什么不扩大你的游泳池规模并收工呢？这些真的是爆款吗？（您对延迟/可靠性的要求真的很严格吗？）它们在活动时是否需要大量 RAM？

您能否提供更多信息，说明您认为必须做出此选择的原因？

【讨论】：

【解决方案2】：

与使用大量线程相比，使用 node.js 的事件驱动 I/O 可能会更好，但需要注意的是，这可能意味着大量重写，而且 node.js 还相当年轻。

此SO article 可能会引起您的兴趣。

【讨论】：