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

Question

如果您在 Node.js 中有一个 SSR Web 服务器和一个 API（也在 Node.js 中）来托管，“通常”是更好的设计来托管和扩展这些分组在一起，还是使用每个节点两者的集群？我附上了一张图表，以更好地解释我的意思。

我之所以问这个问题是因为互联网上的很多项目都显示 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 节点的情况下更改 API 节点，而且流量将在这两个部署组之间分配。如果您的 API 陷入困境，您的网页仍然会响应加载（假设初始渲染不依赖于 API 调用）。第二种方法的另一个好处是能够使用 Redis 或 Memcache 之类的东西来缓存 API 调用。

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