我最近写了关于 为什么值得采用微前端架构的五个原因 。 当然，凡事有利有弊。 微前端是一种全新的架构方法，很可能代表 Web 开发的未来。 同时，它们也存在一些陷阱，了解它们对于能够完全解决或避免它们至关重要。

在本文中，您将学习我和我的团队在使用微前端时学到的最重要的课程。 在两年的时间里，我们发现了这个架构的许多问题，并犯了同样多的错误。 因此，是时候分享它们以帮助您解决或避免它们了。

让我们首先回顾一下微前端架构是什么，然后深入了解它们的陷阱以及如何避免它们中的每一个。

简而言之，微前端

Martin Fowler 将微前端开发方法定义为：

一种架构风格，将可独立交付的前端应用程序组合成一个更大的整体。

当应用于 Web 开发时，它意味着将许多独立的小型前端应用程序作为同一个网站或 Web 应用程序的一部分。 正如这里 已经提到的 ，我的团队成功地使用了这种方法。 特别是，我们有机会利用它的所有优势，例如可扩展性、技术独立性和可维护性。 另一方面，从长远来看，我们注意到了一些严重的问题。 因此，我们决定放弃这种架构方法，转而采用更传统的单体架构。

这意味着我们不仅了解了微前端带来的好处，还了解了它们的主要缺点。 现在让我们深入研究它们，看看我们应该做些什么来避免或解决它们。

1. 冗余依赖

根据定义，每个微前端应用程序都独立于其他应用程序。 换句话说，微前端架构涉及多个前端应用程序，它们应该能够在没有其他应用程序的情况下也能工作。 为此，它们中的每一个都有自己的依赖项。 因此，从整体上看，您正在失去使用包管理器的好处。 事实上，您的整个应用程序可能包含许多版本的相同库，分散在微前端中。

这无疑是一个问题，因为它使您的 Web 应用程序不必要地大于其单体应用程序。 这取决于最终用户，他们被迫下载更多数据。 此外，这会影响渲染时间，从而影响 Google Web Vitals 分数，也会影响您网站的 SEO。

如何解决这个问题

一个可能的解决方案包括三个步骤。 首先，确定所有微前端的通用库集。 其次，创建一个包含所有共享库的微前端。 然后，更新您的微前端，使其构建的包从该共享项目中导入所需的库。

正如 Martin Fowler 在最初的 博客文章 中所描述的那样，在应用程序之间共享依赖关系存在许多障碍，并且不能被认为是一件容易完成的任务。 因此，当您尝试实现此目标时，请记住这一点。

2. 冲突和重叠的风格

同样，技术和团队的独立性很好，但也会带来一些问题。 在处理样式时尤其如此。 事实上，从业务角度来看，每个微前端不可能有自己的风格。 这是因为您绝对不希望您的应用程序看起来由许多补丁组成。 在风格、UI 和 UX 方面，一切都应该看起来一致。

将多个前端作为同一个应用程序的一部分而产生的另一个问题是，您最终可能会无意中覆盖 CSS 规则。 在处理微前端时，CSS 方面不受欢迎的重叠变得很常见，您可能会在部署应用程序后发现它们。 原因是每个团队通常只在自己的应用程序上工作，在部署之前看不到全局。

这些问题会对您的品牌声誉产生负面影响。 此外，最终用户将为这些不一致付出代价，尤其是在 UI 方面。

如何解决这个问题

当涉及到 UI 和 UX 时，唯一可能的解决方案是确保每个团队相互交谈并考虑到相同的结果。 此外，在上述共享微前端项目中添加样式组件可能会有所帮助。 然而，这将使每个微前端应用程序都依赖于它，并因此破坏了底层的独立性。 但至少它会阻止您的应用程序作为一个整体看起来是异构的。

如果你想避免 CSS 重叠，一个解决方案是在前端容器中添加一个 ID  <div> 。 然后，配置 webpack 以在每个 CSS 规则之前插入此 ID。 否则，您可以决定采用 CSS 方法，例如 BEM（Block-Element-Modifier）。 这鼓励您将网站视为可重用组件块的集合，其类名在您的项目中应该是唯一的。 阅读 BEM 简介 以了解有关此系统如何工作的更多信息。

3.表现不佳

因此，在同一页面上运行多个 JavaScript 前端应用程序会降低整个应用程序的速度。 这是因为每个框架实例都需要 CPU、RAM 和网络带宽方面的资源。

另外，请记住，在测试与其他人隔离的微前端时，您可能不会注意到这一点。 当一个框架的多个实例同时运行时，问题就开始了。 这是因为，如果它们独立运行，它们就不必像部署时那样共享底层机器的资源。

如何解决这个问题

解决这个问题的一个想法是加强团队沟通，以避免进行相同的调用和阐述。 然后，将他们的结果存储在每个微前端可以访问的地方，或者允许他们在执行繁重的操作之前进行通信，以验证之前是否已经检索或生成了相同的数据。

此外，在性能方面，您必须使用其所有微前端测试应用程序，并且不要仅依赖在每个微前端上进行的测试。

4. 前端之间的通信

最初，您不需要让您的微前端进行通信，除非在极少数情况下。 这可能会让你误以为它会一直这样。 此外，虽然微前端架构模式是关于独立的，但这与通信相反。

当整个应用程序增长时，使您的微前端能够轻松地相互通信可能会成为当务之急。 最重要的是，如果您想一遍又一遍地重复相同的操作，特别是如果它们不是幂等的。

此外，如上所述，通信是实现更高性能所必需的。 例如，您不希望您的应用程序两次调用相同的 API 来检索相同的数据并不必要地减慢您的服务器。

如何解决这个问题

解决方案是根据存储在 cookie 或 localStorage 中的共享状态或自定义事件来实现自定义消息传递层。 您可以想象，实现这一点需要付出一定的代价，并且很快就会变得复杂且难以处理。 另外，考虑到通信会引入开销。 因此，您必须确保您正在构建的内容会带来真正的好处，并且不会进一步减慢您的应用程序的速度。

5. 团队之间的沟通问题

大型团队中的沟通可能是个问题，但没有什么比几个团队之间的沟通更糟糕的了。 这是因为让多个团队在不同的代码库上工作意味着找到可重用的特性、功能和实用程序变得更加困难。 这在代码可发现性和可重用性方面很糟糕。 换句话说，您可能很容易在不同的微前端中重复实现相同的组件。

如何解决这个问题

解决方案是从一开始就支持团队之间的通信逻辑。 如上所述，这涉及为所采用的每种技术创建一个具有可重用资源的项目。 但是拥有这样一个项目而不使其保持最新状态将使其毫无用处。

因此，您必须允许每个团队向其添加组件和库。 此外，拥有一个致力于此的团队可以使整个过程更容易。 事实上，对于一个独立且孤立的团队来说，了解哪些元素将由多个微前端共享可能并不容易。

此外，不要将技术独立性视为几个孤立的团队。 相反，让团队相互交谈并保持最新状态对于项目的成功至关重要。 因此，在采用微前端架构时，培养沟通文化必须是关键要素之一。

结论

在本文中，我们研究了微前端架构方法的五个最大缺陷，并以我的团队两年来每天使用它所积累的经验为后盾。 尽管微前端方法允许开发人员将前端应用程序分成更小的独立部分，但这并不意味着每个团队也应该被隔离。 相反，共享解决方案、组件、资源和知识是成功的关键。

不幸的是，作为一个团队，我们并不知道这一点。 因此，我们被迫放弃了我们的微前端之旅。 但我们从这次冒险中学到了很多东西，我希望分享导致我们失败的主要原因以及如何避免或抵消它们是有用的。