微前端是前端开发中最具争议的话题之一。值得吗？你真的需要拆分你的应用程序吗？我现在真的需要切换到微前端吗？这是咨询公司为了赚更多钱而发明的另一个概念吗？尽管人们对微前端有很多误解，但我们不能否认微前端越来越受欢迎的事实。让我们来看看谁在使用微前端，为什么，以及一些易于上手的现成解决方案。微前端到底是什么？微前端试图将拆分大型后端系统的一些好处带到前端。最大的问题是部分总是被整体使用。后端系统从不作为一个整体使用，而前端直接负责用户体验（UX）。有很多方法可以解决这个问题。最简单的方法是用HTML输出替换现有的API数据交换模型，只是一个从一个服务（视图）到另一个服务（视图）的超链接。缺点是在大多数使用场景下，这肯定不能满足用户体验的需要。显然，我们需要更复杂的方法来将单独开发的用户界面小部件组合成一个连贯的前端界面。这可以被认为是分布式Web应用程序发展的下一步。微前端和组件、模块是什么关系？这是一个很好的问题。这些概念都意味着代码更容易重用，更容易通过拆分单元来指责。唯一的区别是层次结构：组件组成界面库。模块构成相应的运行时。包形成依赖关系。微前端构成了所呈现的应用程序。所以，如果微前端就像器官，包就像细胞，模块就像分子，组件就像原子。使用微前端的原因有很多，往往主要是为了技术本身，但理想情况下，微前端的使用是基于真实的业务场景，或者是出于提升用户体验的需要。微前端解决方案的核心在于追求以下特点：前端的每一部分都可以独立开发、测试和部署。前端各部分的增删改换无需重建。前端的每个部分都可以使用不同的技术。因此，微前端的本质在于解耦。在应用程序达到一定规模后，微前端开始变得有意义。好处之一是更多潜在的团队分裂可能性，包括组建更小的全栈团队。当满足以下一个或多个条件时，微前端值得考虑：多个团队贡献前端代码针对特定用户或用户组激活、停用、推出一部分前端允许外部开发人员扩展UIUI每天或每周将添加新功能而不影响系统的其余部分随着应用程序的增长保持开发速度不变不同的团队可以使用他们自己的工具谁在使用微前端越来越多的公司正在使用微前端，包括：DAZNElsevierentandoFiverrHelloFreshIKEABit.devMicrosoftOpenTableOpenMRSOttoSAPSixtSkyscannersmapiotSpotifyStarbucksThaliaZalandoZEISS...等等这些公司使用微前端的具体方式各不相同，但是使用微前端的意图是相似的。（上图由LucaMezzalira拍摄）名单每天都在增加，从ThoughtWorks、HLC等咨询公司到SalesPad、Apptio等SaaS提供商。但许多传统公司也押注于微前端。德国隐形冠军霍夫曼集团就是一例。霍夫曼集团是微前端的一个很好的例子，它不需要公司内部非常庞大的团队或资源。霍夫曼集团之所以选择微前端，正是因为它们与多个服务提供商打交道。微前端组件示例[Bit.dev]该平台和营销站点均基于React组件构建，由……Bit管理。查看他们的页面。将鼠标悬停在不同的组件上将显示它们最初属于哪个组件集。单击组件名称可以查看组件，甚至可以将此组件添加到您的项目中。此页面由两组组件构建而成，分别对应于GitHub上的两个不同存储库，[base-ui]（Bit.dev页面）和evangelist。base-ui组件集充当设计系统。evangelist组件集中的组件（用于营销页面）使用base-ui中的一些组件来保持跨不同微前端的统一样式。在这个例子中，Bit既用于实现自主交付，又用于保持不同微前端的接口一致。如何构建微前端不幸的是，这个有趣的问题只有一个模糊的答案：就像微服务一样，没有适用于所有人的单一方法，也没有行业标准。与微服务不同，微前端引入了根本差异，而不仅仅是实现细节。因此，我们需要区分微前端的使用范围。一些服务器端框架也允许客户端组合，但是，反之亦然。客户端框架客户端微前端框架有很多，其中一些还支持服务端渲染。以下框架实现了微前端模式（或类似微前端的模式）：PiralOpenComponentsqiankunLuigiFrint.js服务端框架还有很多服务端微前端框架。有些只不过是基于express的库或框架，但其他的则需要依赖您的基础设施。以下框架实现了微前端模式（或类似微前端的模式）：MosaicPuzzleJsPodiumMicromono辅助库还有一些辅助库提供基础设施，例如共享依赖项、路由事件、组合不同的微前端及其生命周期。这是一个[处理共享依赖项]的示例，使用导入映射、块（webpack内部使用的概念）等机制。以下库有助于减少样板代码：ModuleFederationSitelessSingleSPAPostal.jsEventBusmicro-frontendresearchI希望以后可以根据社区数据重新整理这部分内容。但我需要你在数据方面的帮助。我使用谷歌表格做了一个简单的调查，应该可以在5分钟内完成。请帮助宣传（例如通过Twitter）。太感谢了！调查将于8月底结束，结果将于9月初公布。微前端的下一步虽然有些人认为微前端将大量转向辅助库，如模块联合，但大多数人仍将使用自主开发的解决方案。好消息是，在许多框架下很容易编写代码来避免强供应商锁定。无论如何，微前端缺乏在技术层面交换解决方案的通用标准。此外，微前端仍然没有被社区广泛接受和采用。尽管微前端模式很受欢迎，但社区中仍有很多人对此存有疑虑。微服务不被视为特定场景的另一种工具，而是设计后端时的最佳实践和标准，这是有原因的。显然微服务不应该这样使用。因此，微前端也不应被视为灵丹妙药。结论微前端有很多现成的解决方案，很多项目都采用了微前端。这是一个强烈的信号：微前端已经准备就绪！我建议在开始具有一定规模的生产环境项目之前，研究各种模型和解决方案。我希望你喜欢这篇文章！我想知道你站在哪一边，为什么。你喜欢微前端，你能容忍微前端，还是讨厌微前端？
