最佳实践：部署Angular应用和Spring REST Api

Question

我正在尝试部署一个与Spring REST API通信的Angular应用程序。

Spring应用程序托管在Tomcat上，并正常工作。

我的Angular应用程序是一个简单的表单，在理论上也可以工作。现在我尝试将两者都部署到我的本地系统，并将Angular发送的数据发送到Tomcat服务器，在那里它将由Spring应用程序处理。

由于这将是我未来几个月持续开发的项目，因此我正在寻求有关部署最佳实践的建议。推荐从Tomcat容器中同时提供两者，还是应该分离关注点？我还希望通过这个实验了解可扩展性和架构，因此使用单独的虚拟机、多个服务器、负载平衡等方面我很想了解并接受任何有用的建议或指导。谢谢。

- Catresl

Answer 1

将用户界面与核心业务逻辑（后端）分离是一个好的选择，如果你期望你的应用程序得到大规模扩展（更多服务、频繁变更）。

你已经迈出了第一步。

以下是我的经验和我可以安全地说的“推荐”设置：

- Angular 应用程序和基于 Spring 的 REST 应用程序是您 Web 应用程序的两个不同组件。它们围绕不同的关注点上开发，您将能够在不破坏整个应用程序的情况下很好地维护它们，如果您单独处理它们（开发、构建和部署）。 - 将用户界面与核心业务逻辑分离也有助于您为不同目的使用不同的技术栈。对于构建 UI 而言效果更好的可能并不适用于后端，反之亦然。 - 您提到这些组件将不断发展。通常情况下，它们会分别发展。这是单独的部署管道（分别构建和部署它们）的最佳情况。 - Angular 应用程序可以托管在 node 服务器上，而基于 Spring 的后端 API 运行在 Tomcat 实例上。这也将帮助您基于哪个组件需要更多关注来分别负载平衡这些组件。 - 由于这种分离，完整的应用程序在停机时间内不会完全停止。REST API 可能因维护或故障而停机，但应用程序的 UI 可能仍然运行并为一些不依赖于后端的请求提供服务。这比应用程序完全不可用要好得多。 - 可以在 UI 层使用功能切换技术来禁用某些依赖于后端或未完成的功能部分。虽然可以在单个可部署的应用程序中执行此操作，但当 UI 从后端逻辑中分离出来时，理解和管理起来更加清晰。后端可以有自己的功能切换框架（与 UI 层不同）。 - 将来，您可以将 REST API 公开给外界（或其他应用程序），并添加更多可能不需要的 Angular 应用程序的服务。潜在地，一个专门的团队可能在设置中工作于 REST API 组件，因此不将其暴露给 Angular 代码是有意义的。 - 我最喜欢的是：将你的应用程序公共面向的 Angular 组件视为 Spring 应用程序（REST API）的“客户端”。这使得 REST 应用程序变得“通用”且与 Angular 组件松耦合，在长期运行中具有巨大优势。 话虽如此，在初始阶段使用单个部署也是可以的，但您必须准备在第一次机会时将组件提取出来。

- iCrus