构建具有高可扩展性的 RESTful API [关闭]

Question

我正在寻找构建一个 RESTful API，该 API 将负责根据多个移动应用程序发送的数据（存储在 Amazon redshift 数据库中）插入数据。

我已经开发了一个 API，您可以在这里找到：https://github.com/Noeru14/fms。它使用杜松子酒：https://github.com/gin-gonic/gin。如果我打开了太多并行连接，它会崩溃/无法正常工作。

我的一个朋友谈到了使用 Node，因为它可以实现非常短的客户端-服务器交互。

我想知道构建一个 RESTful API 必须考虑哪些因素，该 API 每秒可以使用 Go 和 Node 处理多达数十万个请求。你也知道它在 Golang 中是否可行？

非常感谢。

Answer 1

在 Go 中是可行的，在 Node 中也是可行的。它也适用于其他语言，如 Erlang 或 Python。但既然你问的是 Node，那么这就是我要回答的问题。

Node 中高并发最重要的是永远不要阻塞事件循环或做任何阻塞操作（除非它是事件循环的第一个滴答声）。这是人们做的第一件事并破坏了并发性 - 比如不时地放一个看起来很无辜的fs.statSync()（有关此类错误的示例，请参见this answer，就在堆栈上的answers中溢出）。在第一次滴答之后使用任何阻塞操作（包括长时间运行的for 或while 循环）总是一个错误，实际上我认为它应该抛出异常。

另一件事虽然在所有情况下都不是一个彻底的错误，但仍可能损害可伸缩性，那就是在您的应用程序中存储任何状态。如果您需要任何持久状态（并尝试不惜一切代价最小化这种需求），那么您应该为此使用数据库。对于需要在请求之间快速共享的数据，例如会话数据，您应该使用像 Redis 这样的快速数据库，但前提是您无法使用 JWT 等实现相同的目标。

更喜欢水平而不是垂直可扩展性，因为在某些时候不会有更大的服务器，但总会有更多的服务器。

总结一下：

1. 永远不要阻塞事件循环
2. 在外部进程中执行所有 CPU 密集型计算
3. 永远不要阻塞事件循环
4. 使用 Redis 或 Memcached 共享状态
5. 永远不要阻塞事件循环
6. 使用集群实现水平可扩展性
7. 永远不要阻塞事件循环

我有没有提到从不阻塞事件循环？

Answer 2

首先，使用“net/http”包具有实现简单路由器甚至自定义中间件（如身份验证）所需的一切，使用路由框架进行简单路由并不是很有效。并且您可以设计应用程序以支持多个服务器上的多个实例。

这是我在 Go 中的一个示例：https://github.com/efimovalex/EventKitAPI/tree/master/consumerapi，它使用内存中的工作池