node.js - React/Nextjs SSR & API - 云架构偏好

Question

如果您有 Node.js 中的 SSR Web 服务器和要托管的 API(也在 Node.js 中)，那么将它们组合在一起托管和扩展，或者使用集群中的每个 Node 来同时托管和扩展这“通常”是更好的设计吗？我附上了一张图表来更好地解释我的意思。

我之所以问这个问题，是因为互联网上的很多项目都显示 Express API 和 React SSR 是在同一个存储库中构建并一起部署的。这通常违背了我认为的标准程序，但我开始怀疑自己并希望从社区获得一些意见。

在配置 A 中，每个云服务器都有两个进程，一个 next.js Web 服务器和一个 Node.js Express API。配置 B 将这两个分开。

以下是我可以看到的一些明显的优点 - 缺点，但我想知道我是否忽略了一些明显的东西，或者是否有一个原因导致大多数开发人员选择一条路径而不是另一条路径。

配置A

优点

• 成本更低(SSR 和 API 之间的网络流量可以在本地完成)
• 更轻松地设置和维护云基础架构
• 共享代码(全部在 JS 中 - 通过包含本地代码模块)

缺点

• 可能无法很好地扩展(如果 API 的每个服务器都使用 80% 的 CPU，那么即使您不需要额外的 SSR 容量，您也将被迫扩展这两个服务器)
• 安全风险(如果有人闯入您的网络服务器，那么他们可以直接访问连接到数据库的服务器)
• 单点故障(即使只有网络服务器受到 DDOS，API 也会受到影响)

配置B

优点

• 更好的可扩展性
• 更好的安全性(如果实现正确)
• 更轻松的部署(重新启动服务器仅影响目标实例)

缺点

• 定价可能更高
• 来自 SSR 的 API 调用速度较慢(预渲染)
• 重复代码(例如 React JWT 解码等)

Answer 1

一般来说，解决方案 B 是生产环境中的首选方法。正如您所提到的，可扩展性会更好，并且您能够在不影响 SSR Node 的情况下更改 API Node ，并且流量将在这两个部署组之间分配。如果您的 API 陷入困境，您的网页仍会响应加载(假设初始渲染不依赖于 API 调用)。第二种方法的另一个好处是能够使用 Redis 或 Memcache 等缓存 API 调用。

如果您只是部署一个小项目或预计流量不大，您可能不需要方法 B 的复杂性，这就是为什么很多人选择走路线 A 的原因，因为您根本不需要额外的复杂性。