node.js - 独立的 REST API 和应用服务器

Question

我们想弄清楚，拆分 REST API 和应用服务器是否是一个好的做法。我们使用 NodeJs 对它们进行编码并将其托管在 AWS 上，还请注意，我们希望使用 API 连接其他客户端(Android/iOS)并拥有单独的数据库服务器。

我们的主要问题是:

• 这样更安全吗？
• 性能更好？
• 开发有哪些特殊之处是我们必须考虑的？
• 那么 REST 服务器已关闭？我们必须在应用程序服务器上缓存数据吗？
• 我们在客户端也有一些简单的逻辑，例如“密码忘记”，哪个服务器处理这个？ (应用程序或 REST 服务器)
• 他们中的哪一个负责身份验证？

Answer 1

it is more secure ?

没有。它不是。事实上，攻击面越大，它的安全性就越低。并且您需要单独对每个服务进行身份验证和授权。

better performance ?

不。同一应用程序中的函数调用比序列化 -> 网络延迟(http(s) 开销) -> 反序列化 -> 处理 -> 序列化 -> 网络延迟(http(s) 开销) -> 反序列化快得多

there are special features of the development, which we must consider?

是的，部署策略、服务发现、上游服务不可用时的优雅降级。

that is then the REST server is down? do we have to cache the data on the App Server?

这个要看具体情况，这个问题没有统一的答案。相信我，除了你的团队/产品负责人之外，没有人可以回答这个问题。大多数情况下，这个决定将由您与消费者签订的契约(Contract)决定。我建议阅读有关断路/优雅降级/部分响应的http响应代码等内容

we also have some simple logic on the client side like "password forget", which server handle this ? (App- or REST server) which of them handle the authentication ?

从这个问题来看，我假设您还没有明确区分每项服务的单独职责。这就引出了一个问题，为什么此时将它们分成 2 部分。为什么不能一开始就将所有功能都驻留在一个应用程序中。随着您的发展，当您开始感受到单体应用程序的痛苦时，您可以重新审视您的架构并将其分解成它认为合适的小块。在我看来，对于较小的应用程序，单体架构比微服务更易于管理。

只是一个谦虚的建议，我不会将一项服务命名为 REST 和其他应用程序服务器，这可能会给人一种印象，即您可能从错误的角度看待这个问题。

在我看来，如果我的单体应用程序不再易于管理，我会根据功能对其进行拆分(查看不相关的实体并将它们作为单独的服务取出)