微前端架构建议答案

【问题标题】：Micro frontend architecture advice微前端架构建议
【发布时间】：2018-06-03 23:21:42
【问题描述】：

我们希望在一个单页应用程序下呈现多个 Web 应用程序。我们正在寻找一个可以使用的微前端架构/框架。正如我们所看到的，这些是我们的实施选项：

使用single-spa开源框架：https://github.com/CanopyTax/single-spa
使用 Iframes（友好的 Iframes）托管应用程序（shell）并根据当前 url 加载每个应用程序。
编写我们自己的 Javascript 框架
其他？

当前状态是一个单体 FE 应用程序，它使用其他子应用程序作为内部 3rd 方包。这种方法对我们来说是不可扩展的，因为托管应用程序将所有产品构建在一起，并没有真正分开。

我们的要求是微前端的一般要求： 1.自主开发—— 每个团队都可以选择自己的框架并构建自己的产品，而不管其他产品。

独立部署 - 每个应用程序都可以在生产中升级，无需停机，也不会干扰其他应用程序。
共享组件 - 我们在我们的应用程序中使用 Angular4，并且我们已经编写了一个专有的 3rd 方库（共享组件和逻辑），应该在所有产品之间共享以实现相似的外观和感觉。
我们希望能够在不关心其他应用程序的情况下升级每个应用程序的框架（Angular、RXjs、Typescript 等以及我们的专有组件库）。

我们尝试使用 single-spa 框架，但遇到了一些问题，目前我们发现自己在思考这是否适合我们，或者我们是否应该尝试不同的方法。

我们在使用单一水疗池时遇到的问题是： 1.资产加载有问题。（我们必须在托管应用程序的根文件夹中拥有资产文件，并且在切换到另一个应用程序时会遇到资产冲突）。 2.我们仍然不知道如何处理所有应用程序的全局样式（我们使用sass进行样式，并且必须与每个应用程序的本地样式一起编译） 3. 升级 Angular 框架（或所有其他框架）对于一个应用程序是不可能的，要么全有要么全无（因为我们有一个 Angular 实例）。 4. 我们必须在宿主应用程序（shell）的另一端实现不同的捆绑开发。

当我们考虑 Iframe（使用友好的 Iframe）解决方案时，我们设想了所有子应用程序之间的完全分离，并且倾向于认为这对我们来说是一种更合适的方法。

使用 iframe 有什么陷阱吗？

谢谢，丹尼尔

【问题讨论】：

您可以分享您在这一年的研究/经验的结果，以改进这一点：stackoverflow.com/a/52719127/6432698 answer

标签： angular iframe web frontend

【解决方案1】：

我想将我的 2 美分添加到前端微服务可能的架构解决方案的主题中：

OpenTable 使用的 OpenComponents – https://github.com/opentable/oc
Zalando 的马赛克 – https://www.mosaic9.org/

希望你觉得它们有用。

【讨论】：

【解决方案2】：

由于您的问题有点宽泛，我将仅解决您对 iframe 使用的询问，因为在不了解具体情况（目标群体？、移动设备？、KPI 是什么？（性能、初始负载、开发成本、可重用性……）

iframe 有利于“完全”隔离（代码 + 样式），没有其他方法可以做到这一点，但是正因为如此，它们有很多的缺点：

在 iframe 之间共享数据需要在外部和内部 SPA 中进行编排，这涉及设置额外的安全措施（因为每个 SPA 都是公开的）
仅当它们位于同一个域中并且需要额外的 JS 代码时，才可以使用外部 SPA 来设置内部 SPA 的样式
仅当内部 SPA 与外部 SPA 位于同一域时，共享 cookie 才有效
在性能方面，每个 Iframe 都需要自己加载所有内容；重用资产、库等非常困难，并且涉及干预每个 SPA 的工具。

通常，如果您掌控一切，那么使用真正的微前端方法是比 Iframe 更好的解决方案。

【讨论】：

【解决方案3】：

你可以试试PuzzleJs。它被设计为网关和店面的微前端架构的框架解决方案。它正在用于我们的高流量电子商务网站的制作。你真的应该检查一下。

它实际上几乎涵盖了您的所有要求。

独立部署
独立源代码
独立技术

关于 iframe 解决方案，可能很难管理诸如 CORS 和与其他 iframe 的通信之类的事情。

但微前端解决方案仍不完美。当你真正深入研究它时，会有很多复杂性。

一些资产会尝试在全局范围内声明相同的变量，有时它们会有不同的版本，这会导致错误。所以团队之间不会完全独立。

记录和监控变得异常困难。 New Relic 之类的工具可以帮助您，但还不够。您应该实施自定义监控和错误报告工具。

保持应用程序的 docker 化和自动缩放友好非常重要。使用这种架构，如果您有 4 个网关和一个店面，则可能会很棘手。

实施微前端架构的初始成本相当高。您应该仔细考虑您的时间和开发人员资源

性能是最重要的。您不想多次下载 react 或其他库，因为多个团队正在使用它们。您应该实施DllPluginn 以删除重复的代码。它会让一切变得更加困难。

还有很多我不记得的其他问题。如果你没有超过 50 名开发人员在同一个店面项目上工作，那么微前端就是一个矫枉过正的决定。

【讨论】：

【解决方案4】：

我们目前正在使用单水疗框架进行完全相同的工作。我们得出了和你一样的结论。对我们来说，一个主要问题是子应用程序的翻译，因为至少我们无法找到将它们捆绑到子应用程序的方法。样式等其他资产也是一个问题。

我的建议是等待angular elements，因为该框架并非设计用于微前端风格。

【讨论】：

不幸的是，在公告发布后，还没有更多关于角元素的信息。我希望有一个可用的路线图 - 但还没有 - 请参阅github.com/angular/angular/issues/20891。使用 vue 或 react 之类的框架，为微服务创建复合 UI 似乎很容易。使用 vue / react 和 webpack 或 browserify 可以捆绑一个组件和一个特定的 react 版本 - 参见例如stackoverflow.com/questions/25454029/…。
如果目标是拥有微前端，那么反应当然是更好的选择。令我难过的是，这里缺少太多的角度。角度元素的路线图会很高兴看到。

【解决方案5】：

您可以从每个应用程序中公开 Web 组件，并在主 SPA 中聚合/使用它们。所有浏览器以及所有领先的 SAP farmeworks（如 angular、ember、react、vue）都支持 Web 组件。这样您就不会绑定到任何特定的 SPA 框架，并且可以在任何地方恢复组件。

【讨论】：

【解决方案6】：

您可以将 ShadowDom v1.1 视为 Iframe 的替代品。我最近使用这种技术工作和部署银行应用程序来隔离父应用程序的样式（这是一个带有 jsp 服务器端模板的有状态应用程序）但这只会给您带来样式隔离。

最好为每个子应用程序使用不同的代码库。这样，您可以独立开发它们，迁移到不同的 Angular 版本，并单独部署。共享组件和专有的第 3 方库可以发布为 node_module，您可以将其导入每个子应用程序。（我想你应该有私有/内部工件存储库设置）

子应用之间的通信可以通过localStorate/sessionStorage来完成。您可以进一步将它们包装为共享服务并再次发布为 node_module 依赖项。

** 设置

yourcompany.com --> 父应用

yourcompany.com/app1.html --> 子应用程序 1 - 带有捆绑 js 文件和 css 的引导应用程序 yourcompany.com/app2.php --> child app 2 - 带有捆绑的 js 文件和 css 的引导应用程序 yourcompany.com/app3.jsp --> child app 3 - bootstrap application with bundled js files & css

** 或使用子域

yourcompany.com --> 父应用

app.yourcompany.com --> 子应用 1

blog.yourcompany.com --> 子应用 2

home.yourcompany.com --> 子应用 3

【讨论】：

【解决方案7】：

我相信我在this thread 上的回答会很足智多谋。但是要进一步澄清

鉴于主应用程序部署到 www.example.com，每个子应用程序必须通过强制导入来继承全局样式，即
```
@import url('https://www.example.com/path/to/global/style.css');
```
对于 Web 组件，单个子应用程序的样式不可转移。同样，必须强制从基础应用程序继承样式，如上所示。
由于每个子应用程序都可以独立构建，因此它与语言无关。一款应用可能会选择使用 Vue，而另一款则使用 Polymer。
使用 Web 组件与使用 iframe 类似，只是它更轻且旨在附加。

希望对你有帮助

【讨论】：

【解决方案8】：

这个话题已经很老了，但是，也许有人会觉得稍后阅读答案会很有趣，因为它仍然是一个非常好的话题。

您在问题中发布的这个包 - https://github.com/single-spa/single-spa 看起来非常好，我们尝试使用它，但是，它包含太多特定于框架的东西，这使得新工程师的入职变得非常困难。

我认为首先您需要为应用程序的微前端组合选择方法：

构建时组合
服务器端组合
客户端组合
路线组成

我尝试用文章https://medium.com/@danielostapenko/frontend-architecture-in-scale-for-large-organizations-593930ed10cd中的一些有用链接来描述它们

另外，我真的鼓励你看看 Webpack 5 提供的 Module Federation 功能。在微前端世界中工作看起来非常有前途和舒适。

【讨论】：