可以缩放supertokens核心API层吗？
我们正在使用Supertokens进行POC进行身份验证。我们需要无密码，电子邮件/密码和社交登录功能。对于所需的功能，Supertokens Core API层是否可扩展？如果是这样，推荐的缩放方法是什么？
We are doing a POC with SuperTokens for authentication. We require Passwordless, Email/Password, and Social Login functionality. With that functionality required, is the SuperTokens Core Api layer scalable? If so, what is the recommended approach for scaling?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Supertokens具有两组API：
您的应用程序的前端仅称为FDI API，然后我们的后端SDK称为CDI API。因此，您的后端是前端与超级核心核心服务之间的代理。
FDI API的可伸缩性（由您的前端称为）取决于您的API层的可扩展性 - 该层完全由您控制。
CDI API的可伸缩性（通过Supertokens Core Service暴露）取决于：
每个supertokens核心实例都是无状态的，可以轻松地向上 /向下缩放。但是，所有这些都需要连接到DB的同一实例，因此，这里的限制因素成为DB本身的可扩展性。
由于只有您的后端API层查询了Supertokens Core，因此建议与后端托管核心。
话虽如此，核心的一个实例可以每秒舒适地处理几百个请求。您可以通过设置进一步提高其性能：
最后，如果我们考虑不同类型的AUTH操作，则会验证是迄今为止最常见的操作（与登录 /输出或更改密码相比……）。默认情况下，supertokens以无状态的方式验证用户的会话。这意味着您的后端API层根本不需要查询核心以进行会话验证。
反过来，这意味着您可以轻松地扩展超级动物，以处理数百万的并发会话，并具有相当少数的核心实例。
SuperTokens has two sets of APIs:
Your app's frontend only calls the FDI APIs and in turn, our backend SDK calls the CDI APIs. So your backend is a proxy between the frontend and the SuperTokens core service.
The scalability of the FDI APIs (which is called by your frontend) is dependent on the scalability of your API layer - which is completely controlled by you.
The scalability of the CDI APIs (exposed via the SuperTokens core service) depends on:
Each SuperTokens core instance is stateless and can be scaled up / down easily. However, all of them need to connect to the same instance of a db and therefore the limiting factor here becomes the scalability of the db itself.
Since only your backend API layer queries the SuperTokens core, it is recommended to host the core in the same region as your backend.
That being said, one instance of the core can handle several hundred requests per second comfortably. You can further improve it's performance by setting:
Finally, if we consider the different types of auth operations, session verification is by far the most common operation (as compared to signing in / out or changing a password...). By default, SuperTokens verifies a user's session in a stateless manner. This means that your backend API layer doesn't need to query the core at all for session verification.
This in turn implies that you can easily scale SuperTokens to handle millions of users with hundreds of thousands of concurrent sessions with a fairly low number of core instances.