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