hel-micro,modulefederationsdk,build-free,hotupdate,toolchain-independentmicro-modulesolution,欢迎关注和了解微前端的由来在微前端这个概念出现之前，我们或多或少可以联想到另一种词性相似的概念微服务，自出现以来就非常火爆，不断推动着后端架构体系的演进。的诞生原因有很多有趣的地方。先不说这两兄弟，从更高的角度来看，我们会发现很多新概念的诞生都有一定的渊源，可以类比为宇宙的诞生。经过足够长的时间，发生了大爆炸，然后逐渐扩散开来，形成了万物的原型，所以……让我们回顾一下，在这个高速信息化的时代，当网络带宽越来越大的时候，当覆盖范围越来越广，延迟越来越低，接触到的人越来越多的时候，让web从1.0进化到2.0、3.0、4.0。在这个全民上网的时代，在网络条件如此优越的时代，为什么会挡不住庞大的能量，开始肆无忌惮的爆发？爆炸性数据你必须足够聪明才能意识到它是数据。优越的网络条件就像沃土，让全民参与内容生产。于是，海量数据疯狂增长，我们进入了大数据时代。面对如此庞大的体量，云计算、分布式技术等新概念纷至沓来，有了用武之地，或者说数据的爆炸式增长，倒逼着这些技术的出现和发展。回到微服务和微前端这两兄弟，想一想是不是也是一样，因为数据的爆炸式增长，需要对各种场景进行精细化运营，以至于我们传统的单体服务架构要承载越来越多的业务？这种由n个服务组成的后台项目，从开发的角度来看，只能在已有的技术栈上不断叠加新的功能。当新的技术收益诞生时，要取代它们将是一场噩梦。从运维的角度来说，因为整个项目是打包在一起形成一个产品，所以我们不得不面对所有修改同时发布的繁琐。结果，微服务诞生了。这种单体式服务可以按照各种职责、功能或业务维度划分成一个个的服务，通过rpc通信独立构建和部署。它与应用程序的语言架构无关，让开发者不再受限于某种编程语言。当然，作为拆解的代价，服务注册、服务治理、服务发现、服务熔断、服务监控、链接跟踪等新机制的引入带来了更高的复杂度，所以服务的拆分必须是一个循序渐进的过程，拆分为了拆分，必然会带来更高的成本和运维方面的挑战。微前端和微服务的区别在于，如果我们不拘泥于微前端的概念，而是从拆分字符的角度来看，其实微前端其实从HTML的那一天就已经存在了出生于。我们仔细想想。在传统的服务端渲染中，一个路由是否对应服务端一个html页面的字符串返回？这个返回在后台对应一个页面模板，不管是静态生成还是动态生成，它在后台的目录结构都是一个独立的文件，所以我们一直使用微前端来搭建项目的视图部分。随着前端业务复杂度的大幅提升，传统的服务端渲染方式给前端工程化带来了极大的挑战，因为工程化的基础是组件化，而组件化是后端模板引擎支持的天生柔软。无力感，无论是编写经验还是调试经验，都远弱于浏览器端渲染，而作为浏览器端js的最佳人选，生态环境也越来越丰富强大，比如birth的节点。前端工程催生了一大批优秀的构建工具和编译工具，js引擎的性能也在不断提升，js本身的规范和语言特性也在不断进化，相关组件化开发的优秀库雨后春笋般的（react,vue,angular,svelte...），良好的npm生态让库共享变得简单等等，在这种有利于前端工程的土壤下，让我们面对复杂的前端——端项目，如SEO优化，首屏速度等因素（虽然也有类似的解决方案），倾向于从服务端渲染迁移到浏览器渲染。微前端的5大核心思想前端工程也面临着和后端一样的问题。一个项目会随着时间的推移逐渐堆叠大量的业务，这样一个前端项目就会慢慢演变成一个巨石应用。基于这一背景，微前端对微前端做了如下解释：微前端背后的思想是将网站或网络应用程序视为由独立团队拥有的功能组合。每个团队都有其关心和关注的不同业务领域或任务，一个团队是跨职能的，端到端地开发其功能，从数据库到用户界面，但这个想法并不新鲜，它是同自包含系统的概念有很多共同点。过去，这种方法被称为垂直系统的前端集成。但微前端显然是一个更友好、更不简洁的术语。并进一步细化了以下5点微前端的核心思想与技术无关每个团队都应该能够在不与其他团队协调的情况下选择和升级他们的堆栈。自定义元素是隐藏实现细节同时为其他人提供中性界面的好方法。隔离团队代码不要共享运行时，即使所有团队都使用相同的框架。构建自包含的独立应用程序。不要依赖共享状态或全局变量。建立团队前缀就尚不能隔离的命名约定达成一致。命名空间CSS、事件、LocalStorage和Cookie，以避免冲突并明确所有权。优先使用本机浏览器功能而不是自定义API，以使用浏览器事件进行通信，而不是构建全球PubSub系统。如果您确实需要跨团队构建API，请尝试使其尽可能简单。构建弹性站点即使JavaScript失败或尚未执行，您的功能也应该可以正常工作。使用通用渲染和渐进增强来提高感知性能。上述微前端模块联合阶段1所强调的五个特点，似乎已经给微前端一个完美的定义，以至于各种微前端框架都是在这五个核心思想的指引下实现的，直到2020年，webpack5modulefederation（以下简称MF）modulefederation诞生了，官网上对这个特性做了很简单的介绍：motivationofmodulefederation,sothatmultipleseparatebuildsshouldbecombinedintooneapplication,这些有独立构建之间应该没有依赖关系，所以它们可以独立开发和部署，这通常被称为微前端，但不限于此。仔细琢磨这段话，我们发现从webpack5的角度来看微前端只需要包含三个特性：独立开发、独立部署、运行时结合。如果你发布过基于webpack5MF的远程模块，你就会知道它并没有包含微前端站点中提到的隔离团队代码的关键点，虽然我们知道代码需要shadowrealm（未来的隔离解决方案）runningisolation),proxywindow,iframe等解决方案，但是MF并没有强调这一点，所以看起来MF理解的微前端是微前端的阉割版？重新思考微前端我们比较了微前端和webpack5微前端的定义，提出了一个灵魂的问题。以下表达式是否正确？事实上，随着模块联邦概念的逐渐流行，微前端架构已经分裂为两个方向：基于容器的微前端。我们把这种以single-spa为代表的解决方案统称为微容器，在single-spa中已经流行起来。之后市场上涌现出很多基于single-spa二次封装的库。典型代表作，如阿里的qiankun，旨在解决single-spa的一些未解决的问题，使其更适合企业级开发。同时诞生了很多非singlespa的框架，比如京东的微信、腾讯的无界等，实现细节各不相同，包括js沙箱隔离、css隔离、iframe编排、启用web-component、window代理，以及访问流程每个地方的细节也不同，但是都有一个非常显着的特点。对应的模块粒度是整个应用。做出来的产品可以理解为将多个应用以宏观状态组合起来交付给用户的一种方式。试想一下，您不会极端到以运行时隔离的方式呈现多个按钮，对吧？相对于宏状态与微容器的组合应用方式，微模块可以说是微状态的组合。它的粒度更小，小到可以是一个函数，也可以是一个基本组件。对于开发者来说，引入微模块和普通的js包没有区别，使用上也没有区别，而恰恰是这样！这是它与微容器最大的区别之一。微模块的使用返回到js语法本身。开源社区中有很多微容器和微模块的实现。它们的特点很明显，因此基于这两种解决方案构建的微前端架构也大不相同。如何选择微前端技术类型？我们只需要深刻理解微模块是自然的。假设它们运行在同一台主机上（也就是在同一个js环境中），那么它需要解决的核心问题是如何在大型独立构建的应用程序之间快速、动态地共享公共模块。比如你内部有100个前端项目依赖lodash-1.0.0，突然库中暴露出一个漏洞，你需要重建并升级所有100个前端项目到1.0.1来解决这个问题漏洞安全。Module-based对于federatedlodash，只需要构建一次mf-lodash，其他项目可以参考最新的安全代码。考虑到以下两个关键点，很容易得出技术如何选择的结论：1.是否需要多技术栈混合开发（react,vue...）2.是否需要多技术栈版本技术栈同时迭代等（vue2,vue3...）因为微模块是微状态的组合，可以快速的把你越来越大的应用拆解成可以独立部署和组合的组件又是他们。与微容器方案相比，很多时候可能你的新项目并不需要涉及微容器。当你需要结合一些第三方应用或者你自己的其他技术栈应用，需要让它们隔离安全运行时，微容器是你武器库中合适的有力武器。事实上，如果它们结合使用，它们将是一个相得益彰的完美组合。可以先使用微容器，再接入微模块实现跨应用模块的动态共享，也可以先使用微模块，再使用微容器进行运行时隔离。由你决定。项目处于开发的哪个阶段。混合架构的微前端实践其实我们在这方面做了大量的工程实践，微容器推出无界，微模块推出hel-micro这里有一个混合架构的例子供大家参考：wujie和hel-mico搭建一个微前端，你可以把这个思路copy到其他社区解决方案中，比如(micro-app+mf)(qiankun+hel-micro)等，例子中有加载远程react的例子无界容器中的组件。有一个在无界容器中加载远程lodash模块的示例。关于hel-micro和wujiehel-micro是业界首款模块联邦SDK，免构建、热更新、独立于工具链微模块方案，让模块联邦技术从构建工具插件升级级别到sdk级别，使用更灵活，模块循环更好（工具链无关）。无界微前端是基于WebComponents+iframe的微前端框架，具有成本低、速度快、原生隔离、功能强大等一系列优势。都在腾讯云和腾讯新闻的多个toB和toC场景进行了测试。期待您的关注和理解，让我们一起探索微前端领域的更多可能。总结本文讨论了很多关于微前端的新认识。你明白终极意义吗？跟你和你之前接触的微前端的概念有什么区别吗？希望大家多多了解容器式微前端和模块化微前端。找到微前端之间的最佳平衡并将其付诸实践。
