关于微前端的 11 个常见误解

破除关于微前端的迷思。最初发表于Bits and Pieces。

微前端是多年来兴起的新趋势。凭借新的方法和已解决的挑战，它正逐渐成为主流。然而，许多误解显而易见，导致许多人难以理解微前端的含义。

简而言之，微前端就是将微服务的一些优势融入到前端。它的意义远不止于此，而且我们不应忘记，微服务也并非万能的。

提示：要在微前端或任何其他项目之间共享 React/Angular/Vue 组件，请使用Bit等工具。Bit 允许您从任何代码库中“获取”组件，并将它们共享到bit.dev中的集合中。它使您的团队可以在任何代码库中使用和开发您的组件。使用它来优化协作、加快开发速度并保持一致的 UI。

误解

虽然选择微前端的一些原因也可以总结出来，但在本文中，我想列出过去几个月我听到的最常见的误解。我们先从一个显而易见的误解开始。

1. 微前端需要 JavaScript

当然，目前许多可用的微前端解决方案都是 JavaScript 框架。但这怎么会错呢？JavaScript 不再是可有可无的。每个人都渴望高度交互的体验，而 JS 在提供这种体验方面发挥着至关重要的作用。

除了上述优势之外，快速的加载时间、易于访问的 Web 应用以及其他因素也应考虑在内。因此，许多 JavaScript 框架都提供了同构渲染的功能。最终，这不仅能够在客户端进行拼接，还能在服务器上准备好所有内容。根据性能需求（例如，从初始到首次有效渲染的时间），此选项听起来很不错。

请记住，同构渲染有其自身的挑战。

然而，即使没有 JavaScript 的同构渲染解决方案，我们在这方面也做得很好。如果我们想在不使用 JavaScript 的情况下构建微前端，我们当然可以做到。存在许多模式，其中相当一部分根本不需要 JavaScript。

考虑一下“老”模式之一：使用<frameset>。听到你笑了吗？其实，在过去，这已经允许一些如今人们尝试的拆分方式（详见下文）。一个页面（可能由其他服务渲染？）负责菜单，而另一个页面负责页眉。

<frameset cols="25%,*,25%">
  <frame src="menu.html">
  <frame src="content.html">
  <frame src="sidebar.html">
</frameset>

如今，我们使用了更灵活（且仍在积极支持）<iframe>的元素。它们提供了一些不错的功能——最重要的是，它们将不同的微前端彼此隔离。仍然可以通过 进行通信postMessage。

2. 微前端仅适用于客户端

继 JavaScript 误解之后，这是下一个层次。当然，在客户端有多种技术可以实现微前端，但实际上，我们甚至不需要任何<iframe>或类似的技术就能让微前端工作起来。

微前端可以像服务器端包含一样简单。借助边缘端包含等高级技术，它的功能将更加强大。如果我们想排除在微前端功能中实现微前端的场景，那么即使是简单的链接也能正常工作。最终，微前端解决方案也可以像微型、独立的服务器端渲染器一样简单。每个渲染器可能小到一个页面。

下图说明了反向代理中发生的更高级的拼接。

当然，JavaScript 确实有很多优势，但它仍然很大程度上取决于你试图用微前端解决的问题。根据你的需求，服务器端解决方案可能仍然是最佳（或至少是更好）的选择。

3. 你应该使用多个框架

几乎每个关于微前端的教程，不同的部分不仅由不同的团队开发，而且使用的技术也不同。这很荒谬。

是的，通过合理的微前端方法，使用不同的技术应该是可行的，但这不应该成为最终目标。我们采用微服务，也不是为了在后端形成真正的技术拼凑（或者应该说是“混乱”）。如果我们使用多种技术，那只是因为我们获得了特定的优势。

我们的目标始终是实现某种程度的统一。最好的方法是设想一个全新的领域：接下来我们会做什么？如果答案是“使用单一框架”，那么我们就走在了正确的道路上。

从长远来看，在你的应用程序中使用多个框架可能会有多种原因。这可能是由于遗留问题，可能是出于方便，也可能是为了验证概念。无论原因是什么：能够使用这种场景仍然很好，但这绝不应该是理想的状态。

无论你的微前端框架多么高效，使用多个框架总是会带来不可忽略的代价。这不仅会延长初始渲染时间，还会增加内存消耗。便捷模型（例如，某个框架的模式库）无法使用。这将导致进一步的重复。最终，应用程序的错误数量、不一致的行为以及感知到的响应速度都会受到影响。

4. 按技术组件划分

总的来说，这没什么意义。我还没见过哪个微服务后端的数据处理在一个服务中，而API在另一个服务中。通常，一个服务由多个层组成。虽然像日志记录这样的技术特性肯定会被引入到通用服务中，但有时也会使用像Sidecar这样的技术。此外，服务内部也期望使用通用的编程技术。

对于微前端来说，情况也一样。为什么一个微前端只负责菜单？难道每个微前端都没有菜单，需要根据菜单进行相应的填充吗？这种划分应该由业务需求决定，而不是技术决策。如果你读过一些领域驱动设计，你就会知道，它的核心在于定义这些领域——而这个定义与任何技术需求都无关。

考虑以下拆分：

这些是技术组件，与微前端无关。在真实的微前端应用中，屏幕可能看起来如下：

当然，这里的拼接要复杂得多，但这正是完善的微前端应用程序应该为您提供的！

5. 你不应该分享任何东西

不。你应该分享那些有意义的东西。你绝对不应该分享所有东西（参见下一点）。但为了保持一致，你至少需要分享一套原则。无论是通过共享库、共享 URL，还是仅仅是构建或设计应用程序时使用的文档，都无关紧要。

对于微服务，这种“无共享”架构如下图所示。

在浏览器中，这会导致使用，<iframe>因为目前没有其他方法可以防止资源泄漏。使用 Shadow DOM 可以隔离 CSS，但脚本级别仍然能够触及所有内容。

即使我们愿意遵循无共享架构，也会遇到麻烦。仅仅为了让简单组件保持活动状态而重复的资源会严重损害感知性能。

诚然，共享越深入（例如，通过应用外壳使用附加到 DOM 的共享库），问题就可能出现。然而，另一方面，共享越松散（例如，仅仅是一个指定基本设计元素的文档），就越容易出现不一致的情况。

6. 你应该分享一切

绝对不行。如果真是这样，那么单体应用更合理。性能方面，这可能已经是个问题了。我们可以惰性加载什么？可以移除什么？但真正的问题是依赖管理。什么都不能更新，因为这可能会破坏某些功能。

共享部件的优点在于一致性保证。

现在，如果我们共享所有内容，就会引入复杂性来保持一致性。但这种一致性也是无法维护的，因为复杂性会在各个方面引入错误。

这个问题的根源在于“依赖地狱”。下图很好地说明了这一点。

简而言之，如果一切都依赖于其他一切，我们就会有依赖问题。仅仅更新一个盒子就会影响整个系统。一致性？真的。简单吗？绝对不是。

7. 微前端仅适用于 Web

他们为什么要这么做？没错，到目前为止，我们主要涉及的是 Web，但这些概念和想法可以应用到任何类型的应用程序（移动应用、客户端应用……，甚至是 CLI 工具）。在我看来，微前端只是“插件架构”的一个新奇说法。至于插件接口如何设计，以及使用插件运行应用程序需要什么，则是另一回事。

下图展示了一个相当通用的插件架构。感谢Omar Elgabry提供。

目前还不清楚它在哪里运行。它可以在手机上运行，​​也可以在 Windows 上运行，还可以在服务器上运行。

8. 微前端需要大型团队

再说一遍，为什么？如果解决方案超级复杂，我肯定会找一个更简单的。有些问题需要复杂的解决方案，但通常情况下，好的解决方案都是简单的。

根据具体情况，甚至可能不需要分布式团队。拥有分布式团队是微前端有意义的原因之一，但并非唯一原因。另一个很好的原因是功能的粒度。

如果从业务角度看待微前端，就会发现能够启用和关闭特定功能非常有意义。不同的市场可以使用不同的微前端。回到简单的权限级别，这很有意义。无需编写代码来根据特定条件启用或禁用某些功能。所有这些都留给一个通用层，只需根据（可能是动态的）条件激活或停用即可。

这样，那些不能（或不应该）使用的代码也不会被交付。虽然这不应该成为保护层，但它确实提供了一个便利（和性能）层。用户不会感到困惑，因为他们看到的只是他们能做的事情。他们看不到具体功能。这些功能甚至都不会被交付，所以不会在不可用的代码上浪费任何字节。

9. 微前端无法调试

我担心这种说法部分正确，但总的来说，不应该如此，而且（剧透！）也不必如此。任何类型的实现（或者为了讨论起见，称之为底层架构）都可能严重影响开发体验。解决这个问题的唯一方法是以开发人员为先。实现的首要规则应该是：确保调试和开发可行。拥抱标准工具。

有些微前端框架根本不支持这一点。有些需要在线连接、专用环境、多个服务……这不应该成为常态。绝对不是常态。

10. 微服务需要微前端（反之亦然）

虽然解耦的模块化后端确实可以为前端解耦奠定良好的基础，但一般来说，情况并非如此。完全可以有一个需要模块化前端的单体后端，例如，为了简化个性化设置，并可能结合授权、权限和市场功能。

同样道理，微服务后端也并不适用于将类似的模式应用于前端。许多微服务后端由单一用途的应用程序运行，这些应用程序不会在功能上有所增长，而只是在外观上有所改变。

11. 微前端需要 Mono Repo

我已经读过几次，说要创建微前端解决方案需要利用 Mono 仓库，最好使用像 Lerna 这样的工具。但我并不认同这一点。当然，Mono 仓库有一些优势，但也存在明显的缺点。

虽然有些微前端框架需要联合 CI/CD 构建，但大多数不需要。需要联合 CI/CD 构建的微前端框架通常需要一个 Mono 仓库，因为这样一开始就更容易正确设置。但对我来说，这相当于重新打包了单体应用。如果你在 Mono 仓库中进行了联合构建，那么你就可以忽略两个让微前端如此有趣的重要因素：

1. 独立部署
2. 独立开发

无论如何，如果你看到一个需要 Mono 仓库的微前端解决方案：运行。一个精心设计的整体式架构可能会更好，因为从长远来看，它不会带来分布式系统的所有问题。

结论

微前端仍然不适合所有人。我不认为微前端是未来，但我也确信它在未来会扮演重要的角色。

您认为微前端在哪些方面表现突出？欢迎您提出任何意见或见解！