Angular 微服务，从 url 加载子项

Question

我最近开始思考如何在微服务架构中有效地实现 Angular。

假设我们有一个登录服务、一个用户管理服务和一个浏览、添加和编辑某些媒体的服务。每个服务都有自己的后端和前端，在自己的私有(private)容器中提供服务。因此，每个部分都通过明确定义的 API 进行隔离，以便与后端进行交互，并使用该 API 来隔离自己的用户界面。

现在，假设我想将这些微服务中的每一个绑定(bind)到一个应用程序中。我有两种方法(据我所知)可以做到这一点:

1. 我可以将服务器配置为将每个服务置于一个子 URL 下，并将应用程序设置为 SPA 数组，一种 MPA(多页面应用程序)。

2. 我可以创建一个主应用程序，在其中为我的每个微应用程序设置路由并按需加载它们(自定义 PreloadingStrategy，我正在看着你)。

3. ^{我还找到了this ，我个人不太看重这个过程，因为在事物的持续交付方案中你会失去微服务的许多好处。这旨在从微服务中创建一个 SPA 单体。}

现在，第一种选择似乎很麻烦，一点也不好玩。第二个对我来说很有趣。我看到这篇文章:https://coryrylan.com/blog/custom-preloading-and-lazy-loading-strategies-with-angular并立即开始思考；我如何利用它从 url 加载预构建的 Angular 模块而不是从文件系统打包它们？

所以我的问题是；以前有人做过吗？是否可以？这样做有安全问题吗？ 或者还有其他方法可以将我的微服务绑定(bind)到更大的应用程序中吗？

Answer 1

微服务本身不应该是一个目标，它是一种实现某些目标的方法。因此，您需要回答以下问题:您想实现什么目标？

人们开始在前端使用微服务的一个原因是可扩展性。如果您的应用程序足够大并且许多团队都使用一个前端，那么最好使用微服务来减少团队之间的依赖性，从而提高开发效率——每个团队都可以独立开发自己的部分。例如，Microsoft Azure 门户就是一个很好的例子。它有很多前端代码，许多团队同时在上面工作。

但这里重要的是部署。大多数前端作为一个组件部署，根据经典定义，前端微服务不完全是微服务。考虑查看 Angular 2 模块。通常人们在前端使用微服务术语实际上是一个模块，而不是可以单独开发和部署的专用组件。

如果您的应用程序足够小(3-4 名开发人员)并且显然不会发展到几个专门的前端团队，那么在前端使用微服务根本没有意义，因为这会增加额外的复杂性。

当前端部分之间的隔离非常大时，可以使用第一个选项，它们之间没有交互。例如，您有一些应用程序应该将用户视为具有相同样式、组件和单点登录的应用程序，但这些应用程序是完全不同的。那么最好将它们定位在不同的 url 中，不同的服务(甚至可能单独部署)在它们之间共享通用的样式和组件。这更容易实现。

当各部分相互关联时可以使用主应用程序，它实际上是一个前端应用程序。但这种方法更难实现，并且需要团队之间进行更多互动。

第三种方法也发生在提到的 post 中。 .