我们想弄清楚，拆分 REST API 和 App Server 是否是一种好习惯。我们使用 NodeJ 对它们进行编码并将其托管在 AWS 上，还请注意，我们希望通过 API 连接其他客户端（Android/iOS）并拥有单独的数据库服务器。
我们的主要问题是：
它更安全吗？
不它不是。事实上，由于攻击面较大，它的安全性较低。并且您需要单独验证和授权每个服务。
更好的性能 ？
没有。在同一个应用程序中的函数调用比序列化->网络延迟（http（s）开销）->反序列化->处理->序列化->网络延迟（http（s）开销）->反序列化快得多
发展有什么特殊之处，我们必须考虑什么？
是的，部署策略、服务发现、上游服务不可用时的优雅降级。
那就是REST服务器关闭了？我们是否必须在 App Server 上缓存数据？
这取决于情况，这个问题没有普遍的答案。相信我，除了您的团队/产品负责人之外，没有人可以回答这个问题。大多数情况下，此决定将由您与消费者建立的合同驱动。我建议阅读有关部分响应的断路/优雅降级/http响应代码等
我们在客户端也有一些简单的逻辑，比如“密码忘记”，哪个服务器处理这个？（应用程序或 REST 服务器）它们中的哪一个处理身份验证？
从这个问题来看，我假设您还没有明确区分每个服务的个人职责。这就引出了一个问题，为什么在这个时间点将它们分成 2 个。为什么一开始就不能将所有功能都驻留在一个应用程序中。随着您的发展，当您开始感受到单体应用程序的痛苦时，您可以重新审视您的架构并将其分解为认为合适的小块。在我看来，对于较小的应用程序，单体架构比微服务更易于管理。
只是一个不起眼的建议，我不会命名一个服务 REST 和其他 App 服务器，这可能会给人一种印象，即您可能从不正确的角度看待这个问题。
在我看来，如果我的单体应用程序无法再管理，我会根据功能对其进行拆分（查看不相关的实体并将它们作为单独的服务取出）