本文将分享我和我的团队在使用微前端时学到的重要经验。在两年的时间里，我们发现了这种架构的许多问题，也犯了同样多的错误。所以，现在分享出来，以帮助你解决或避免它们。
让我们首先回顾一下什么是微前端架构，然后深入了解它们的陷阱以及如何避免每一个陷阱。
微前端简述
Martin Fowler将微前端开发方法定义为：
一种架构风格，独立交付的前端应用程序被组成一个更大的整体。
当应用于Web开发时，它意味着有许多独立的小型前端应用程序是同一个网站或Web应用程序的一部分。正如这里已经提到的，我的团队已经成功地使用了这种方法。特别是我们有机会利用它的所有优点，如可扩展性、技术独立性和可维护性。另一方面，从长远来看，我们注意到一些严重的问题。所以，我们决定放弃这种架构方式，转而回到更传统的单体架构。
这意味着，我们不仅学到了微前端的优点，也学到了它们的主要缺点。现在让我们深入了解它们，看看我们应该如何避免或解决它们。
1. 冗余的依赖关系
根据定义，每个微前端应用程序都是独立于其他应用程序的。换句话说，一个微型前端架构涉及到一个以上的前端应用程序，它们也应该能够在没有其他应用程序的情况下工作。为了实现这一点，它们中的每一个都有自己的依赖关系。所以，从整体上看，你会失去使用包管理器的好处。事实上，你的整个应用程序很可能由许多版本的相同库组成，分散在各个微前端。
这无疑是一个问题，因为它使你的网络应用不必要地比它的单体对应物大。这就落在了终端用户身上，他们被迫下载更多的数据。此外，这还会影响到渲染时间，从而影响到Google Web Vitals 的得分，也影响到你的网站的SEO。
如何解决这个问题
一个可能的解决方案包括三个步骤。首先，确定所有微前端的通用库集。第二，创建一个包含所有共享库的微前端。然后，更新你的微前端，使他们的构建包从这个共享项目中导入所需的库。
正如 Martin Fowler的原始博文中所描述的那样，这个想法来自于应用程序之间的共享依赖关系，这带来了许多障碍，不能被认为是一项容易完成的任务。因此，在你试图实现这一目标时，请记住这一点。
2. 冲突和重叠的风格
同样，技术和团队的独立性很好，但它也会带来一些问题。这在处理风格问题时尤其如此。事实上，从业务角度来看，每个微型前端都不能有自己的风格。这是因为你肯定不希望你的应用程序看起来由许多补丁组成。所有的东西都应该看起来一致，无论是在风格、用户界面还是用户体验方面。
另一个由多个前端作为同一应用程序的一部分而产生的问题是，你可能最终会出现无意的CSS规则覆盖。在处理微型前端时，CSS方面的非预期的重叠是很常见的，而且你可能在部署你的应用程序后才发现它们。原因是每个团队通常只在自己的应用程序上工作，而在部署前没有看到全貌。
这些问题会对你的品牌声誉产生负面影响。而且，终端用户将为这些不一致的地方付出代价，特别是在用户界面方面。
如何解决这个问题
当涉及到 UI 和 UX 时，唯一可能的解决方案是确保每个团队相互交谈并考虑到相同的结果。此外，在上述共享微前端项目中添加样式组件可能会有所帮助。然而，这将使每个微前端应用程序都依赖于它，并因此破坏了底层的独立性。但至少它会避免你的应用程序作为一个整体看起来是异构的。
如果你想避免 CSS 重叠，一个解决方案是在前端容器中添加一个 ID <div>。然后，配置 webpack 以在每个 CSS 规则之前插入此 ID。否则，您可以决定采用 CSS 方法，例如 BEM（Block-Element-Modifier）。这鼓励你将网站视为可重用组件块的集合，其类名在你的项目中应该是唯一的。
3. 性能不佳
在同一个页面上运行一个以上的JavaScript前端应用程序，会因此而降低整个应用程序的速度。这是因为每个框架实例都需要CPU、内存和网络带宽方面的资源。
另外，请记住，当测试你的微型前端与其他人隔离时，你可能不会注意到这一点。当一个框架的多个实例同时运行时，问题就开始了。这是因为，如果它们是独立运行的，它们就不必像部署时那样分享底层机器的资源。
如何解决这个问题
解决这个问题的一个想法是，加强团队沟通，避免做同样的调用和阐述。然后，将他们的结果存储在每个微前端都能访问的地方，或者让他们在执行繁重的操作之前进行沟通，以验证之前是否已经检索或生成过相同的数据。
另外，当涉及到性能时，你必须用所有的微前端来测试应用程序，而不要仅仅依靠对每个微前端的测试。
4. 前端之间的通信
最初，你不需要让你的微型前端进行通信，除非在极少数情况下。这可能会愚弄你，让你以为会一直这样。另外，虽然微前端的架构模式是关于独立性的，但这是与通信相对的。
当应用程序作为一个整体增长时，使你的微前端能够毫不费力地相互沟通可能会成为一个优先事项。最重要的是，如果你想不断地重复同样的操作，特别是在它们不是空闲的情况下。
另外，如上所述，为了实现更高的性能，沟通是必要的。例如，你不希望你的应用程序为了检索相同的数据而两次调用相同的API，并不必要地拖慢你的服务器。
如何解决这个问题
解决方案是基于存储在cookie或localStorage中的共享状态，或基于自定义定义的事件，实现一个自定义的信息传递层。正如你所想象的，实现这一点是有成本的，而且很快就会变得复杂和麻烦，难以处理。另外，要考虑到通信会引入开销。所以，你必须确定你所构建的东西会带来真正的好处，并且不会使你的应用程序变得更加缓慢。
5. 团队之间的沟通问题
大型团队的沟通可能是一个问题，但最糟糕的莫过于几个团队之间的沟通。这是因为有多个团队在不同的代码库上工作意味着寻找可重用的功能、函数和实用程序变得更加困难。这在代码的可发现性方面是很糟糕的，因此也是可重用的。换句话说，你可能会很容易地在不同的微观前台出现相同组件的重复实现。
如何解决这个问题
解决方案是在一开始就支持团队之间的沟通逻辑。如上所述，这涉及到为所采用的每种技术拥有一个具有可重复使用资源的项目。但是，有这样一个项目而不保持更新，会使它变得毫无用处。
因此，你必须允许每个团队向其添加组件和库。此外，拥有一个专门的团队可以使整个过程更容易。事实上，对于一个独立和孤立的团队来说，可能不容易理解哪些元素将被一个以上的微型前端所共享。
此外，不要把技术独立看成是几个孤立的团队。恰恰相反，让团队之间互相交流，并让自己保持最新的状态，对项目的成功至关重要。因此，在采用微型前端架构时，培养一种沟通文化必须是关键因素之一。
总结
在这篇文章中，我们看了微前端架构方法的五个最大的陷阱，并以我的团队两年来每天与之打交道时积累的经验为依据。尽管微前端方法让开发者把一个前端应用分成更小的独立部分，但这并不意味着每个团队也应该是孤立的。相反，分享解决方案、组件、资源和知识是成功的关键。
不幸的是，我们作为一个团队并不了解这一点。因此，我们被迫放弃了我们的微型前端之旅。但我们从这次冒险中学到了很多东西，我希望分享导致我们失败的主要原因以及如何避免或抵消它们是有用的。
原文标题：5 Pitfalls of Using Micro Frontends and How to Avoid Them
作者：Antonello Zanini
