我为频繁使用的 API 设置的服务器

Question

我很快就会为我即将启动的应用程序购买一堆服务器，但我担心我的设置。我很感激我得到的任何反馈。

我有一个应用程序，它将使用我编写的 API。其他用户/开发人员也将使用此 API。API 服务器将接收请求并将它们中继到工作服务器。该 API 将仅保存用于日志记录、身份验证和速率限制的请求的 mysql 数据库。

每个工作服务器都做不同的工作，并且在未来扩展时，我将添加更多工作服务器来处理工作。API 配置文件将被编辑以记录新的工作服务器。工作服务器将进行一些处理，有些会将图像的路径保存到本地数据库，以便稍后由 API 检索以在我的应用程序上查看，有些将返回处理结果的字符串并将其保存到本地数据库.

你觉得这个设置有效吗？有没有更好的方法来重构它？我应该考虑哪些问题？请看下图，希望能帮助理解。

Answer 1

更高的可用性

正如 Chris 所说，您的 API 服务器是布局中的单点故障。您正在设置的是消息队列基础设施，许多人以前已经实施过。

继续沿着相同的路径

您提到在 API 服务器上接收请求并将作业插入到每个服务器上运行的 MySQL 数据库中。如果您想继续走这条路，我建议删除 API 服务器层，并将工作人员设计为直接从您的 API 用户接收命令。您可以使用循环 DNS 之类的简单方法将每个 API 用户连接直接分发到可用的工作节点之一（如果连接不成功，则重试）。

使用消息队列服务器

更强大的消息队列基础设施使用专为此目的设计的软件，如ActiveMQ。您可以使用 ActiveMQ 的 RESTful API 来接受来自 API 用户的 POST 请求，空闲的工作人员可以获取队列中的下一条消息。但是，这对于您的需求来说可能有点过头了——它是为延迟、速度和每秒数百万条消息而设计的。

使用动物园管理员

作为中间立场，您可能需要查看Zookeeper，即使它不是专门的消息队列服务器。我们使用 $work 就是为了这个目的。我们有一组运行 Zookeeper 服务器软件的三台服务器（类似于您的 API 服务器），并有一个 Web 前端来处理来自用户和应用程序的请求。Web 前端以及 Zookeeper 后端与工作器的连接，有一个负载平衡器，以确保我们继续处理队列，即使服务器因维护而停机。工作完成后，worker 告诉 Zookeeper 集群作业已完成。如果一个工人死亡，该工作将被发送到另一个工作来完成。

其他问题

• 确保在工作人员没有响应的情况下完成作业
• API 如何知道作业已完成，并从工作人员的数据库中检索它？
• 尝试降低复杂性。您是否需要在每个工作节点上都有一个独立的 MySQL 服务器，或者它们是否可以与 API 服务器上的 MySQL 服务器（或复制的 MySQL 集群）通信？
• 安全。任何人都可以提交工作吗？有认证吗？
• 哪个工人应该得到下一份工作？您没有提到任务预计需要 10 毫秒还是 1 小时。如果它们很快，您应该删除层以降低延迟。如果它们很慢，你应该非常小心，以确保较短的请求不会被一些长时间运行的请求所困。