Cat*_*esl 7 java deployment spring tomcat angularjs
我正在尝试部署一个角度应用程序,它与spring rest api进行通信.
spring应用程序托管在tomcat上,并按预期工作.
我的角度应用程序是一个简单的形式,在理论上也有效.现在我尝试在我的本地系统上部署它们,并将角度发布数据发送到tomcat服务器,它将由spring app处理.
由于这将是我将在未来几个月不断发展的事情,我正在寻找关于部署的最佳实践的建议.是否建议从tomcat容器中提供服务,还是应该分开关注点？我也希望通过这个实验了解可扩展性和体系结构,因此使用单独的vms,多个服务器,负载平衡等我很想理解并接收任何有用的建议或指示正确的方向.谢谢.
如果您希望应用程序大幅扩展(更多服务,频繁更改),则将用户界面与核心业务逻辑(后端)分离是一个不错的选择.
你迈出了第一步.
以下是我的经验以及我可以安全地说出的"推荐"设置:
Angular应用程序和Spring基于REST的应用程序是Web应用程序的两个完全不同的组件.它们是围绕不同的关注环境发展起来的.如果您单独处理(开发,构建和部署)它们,您将能够在不破坏整个应用程序的情况下维护它们.
将用户界面与核心业务逻辑分离也可以帮助您将不同的技术堆栈用于不同目的.对于构建UI更有效的方法可能不适用于后端,反之亦然
您提到这些组件将不断发展.通常,它们是分开进化的.这是单独部署管道的最佳情况(单独构建和部署它们).
该Angular应用程序可以上托管的node服务器,同时基于弹簧的后端API在Tomcat实例中运行.这也将帮助您根据哪个组件需要更多关注来单独对这些组件进行负载平衡.
由于这种分离,整个应用程序在停机期间不会停机.REST API可能因维护或故障而停机,但应用程序的UI可能仍处于运行状态,并且可以提供一些不依赖于后端的请求.这比完全没有的应用程序要好得多.
可以在UI层使用诸如特征切换之类的技术来禁用依赖于后端或完成一半的功能的某些部分.虽然可以在单个可部署的应用程序中执行此操作,但是当UI与后端逻辑分离时,理解和管理会更加清晰.后端可以有自己的功能切换框架(与UI层的框架不同).
将来,您可以向外部世界(或其他应用程序)打开REST API,并添加Angular应用程序可能不需要的更多服务.潜在地,专门的团队可以在设置中处理REST API组件,并且可能不将它们暴露给Angular代码.
我的最爱:将面向应用程序的Angular组件的公众视为Spring应用程序的"客户端"(REST API).这使得REST应用程序"通用"并且与Angular组件松散地耦合,从长远来看这具有巨大的优势.
话虽如此,可以在初始阶段开始为两者进行单一部署,但是您必须准备好在第一时间提取组件.
| 归档时间： |
|
| 查看次数： |
2066 次 |
| 最近记录： |