答案
1) 我是否将 Angular 模块作为自己的微服务?
是,如果 Angular 模块由“静态”内容组成和/或不需要应用程序服务器。例如,“静态”是指纯 HTML/javascript,而不是对另一个服务或后端的单个 AJAX/SOAP/REST 调用。
是,如果 Angular 应用程序是轻量级的可独立部署的 Web 应用程序 (HTML+JS+WebServices)。
否,如果您决定将 Angular+SpringBoot 组合“转变”为微服务。参照。解释如下。
2)如果第一个问题是真的,所有前端微服务都运行吗
在同一个 AWS 实例上还是分开?
视情况而定。参照。解释如下。
为什么
我认为回顾微服务架构中微服务的真正特征非常重要。为此,我将从维基百科中引用一些有趣的部分(以及其他部分):
- 微服务架构中的服务可独立部署
- 服务是围绕业务能力组织的
- 微服务不是单一应用程序中的一个层。相反,它是一个独立的业务功能,具有清晰的接口,并且可以通过自己的内部组件实现分层架构
- 主要优势有:模块化、可扩展性(尤其是横向)、集成和交付(CI、CD)
因此,严格定义微服务的不是技术(Angular、Spring Boot)或层(后端、前端)。
相反,您必须问自己:
- 您希望达到的粒度级别
- 我想让什么可独立部署(或容器化)
- 我打算如何扩展?
-
我想如何提供更新?
(非详尽列表...)
最后,你可能会想出至少两种可能性:
案例 (1) 可能类似于:
AWS Instance1
Docker container
SpringBoot + Angular app (JS+WS)
AWS Instance2
Docker container
SpringBoot + Angular app (JS+WS)
而 case (2) 类似于:
AWS Instance1
SpringBoot
Angular app1 (JS+WS)
Angular app2 (JS+WS)
AWS Instance2
SpringBoot
Angular app1 (JS+WS)
Angular app2 (JS+WS)
在最新示例中,我将两个相似的微服务放在一起(app1 和 app2)来说明共存的可独立部署的业务单元。
其他技术组合(也有实际依赖关系!)是可能的。一个例子:
AWS.Instance1 (Front-End)
ApplicationServer
MicroService1 (facing REST-API)
MicroService2 (AngularJS app + REST)
AWS.Instance2 (Back-end)
ApplicationServer
MicroService3 (business/core REST-API)
...
这里的前端 (MS2) 使用一个可以调用后端函数 (MS3) 的 REST 外观 (MS1)。单独更新每个组件并进行扩展很容易,您必须创建两个具有相似布局的新 AWS 实例。只是一种味道...
您会注意到,可独立部署并不意味着任何依赖。 (微)服务之间会(并且经常)存在逻辑/功能依赖关系,因此这里的关键字是独立的-deployable。
希望对你有帮助!