共计 4227 个字符，预计需要花费 11 分钟才能阅读完成。
hel-micro，模块联邦 sdk 化，免构建、热更新、工具链无关的微模块计划，欢送关注与理解
微前端的起源
在 微前端 这个概念呈现之前，咱们或多或少都可能联想到另一个词性上有些类似的概念 微服务，它从呈现后便始终都很炽热，并一直催生着后端架构体系的演进，而此刻咱们如果细品一下这微字头的两兄弟，探索他们的诞生起因，会有很多有意思的点。
咱们暂且忘掉这兄弟两，到一个更高的角度会发现，很多新概念的诞生，肯定可能顺藤摸瓜的追溯到一个某个原点上，这个原点咱们能够把它比作宇宙诞生的奇点，压抑了足够久之后产生了大爆炸，而后逐步向外扩散生成万物原型，so…… 咱们复盘一下处在这个信息高速时代，当网络带宽越来越大，覆盖范围越来越广，提早越来越低，触达人群越来越多的时候，让 web 从 1.0 进化 2.0、3.0、4.0，在这个全民入网的时代，网络条件如此优越的时代，是什么开始按捺不住那宏大的能量，开始胡作非为的爆炸起来了呢？
爆炸的数据
聪慧的你肯定意识到了，它就是 数据 ，优越的网络条件如同肥沃的土壤，让全民皆参加到内容生产当中，于是乎海量的数据疯狂成长，让咱们进入了 大数据 时代，面对如此澎湃的体量，云计算 、 分布式 等新概念簇拥而出，有了用武之地，或者说数据的爆炸倒逼着这些技术的产生与倒退。
再回到 微服务 与微前端 两兄弟上，想一下是不是同样的也正因为数据的爆炸，须要精细化的经营各种场景，让咱们传统的单体服务架构上不得不承载着越来越多的业务呢？
这种蕴含 n 个服务形成的一个后盾我的项目，从开发侧看，只能在既有的技术栈上不停的叠加新性能，当新的技术福利诞生时想作替换将是一场噩梦，从运维测看，因整个我的项目打包在一起形成了一个产物，而不得不面对任何一点批改都必须全副一起公布的繁琐。
于是乎 微服务 诞生了，将这种巨石服务或按各职责、或按性能、或按业务等维度作为拆分的维度，拆解成一个个服务，可独立构建、独立部署，通过 rpc 通信做到利用的语言架构无关，让开发者不再捆绑到某一个编程语言上，当然了，作为拆的代价，服务注册、服务治理、服务发现、服务熔断、服务监控、链路追踪等新机制的引入带来了更高的复杂度，所以服务的拆分肯定是一个渐进式的过程，为了拆而拆必然带来运维上的更高老本与挑战。
重刷存在感的微前端
和 微服务 不一样的是，如果咱们不死磕 微前端 概念，而是从 拆字这个角度来看，其实 微前端 其实从 html 诞生那天开始始终都存在，我么认真回忆一下，传统的服务器端渲染，是不是一个路由对应着服务器端一个 html 页面的字符串返回呢，这一个返回对应着后端的一个页面模板，不论它是动态生成的还是动静生成的，它在后端的目录构造里都是一个个独立存在的文件，所以咱们始终都是在用 微前端 搭建我的项目的视图局部。
随着前端的业务复杂度极巨俯冲，传统的服务端渲染形式给前端工程化带来了微小的挑战，因为工程化的根底是组件化，而后端的模板引擎所反对的组件化天生有着用绵软有力的感觉，无论是书写体验还是调试体验都远远弱于浏览器端渲染，而随着作为浏览器端主战场的不二人选 js，生态周边越来越丰盛与弱小，如 node 的诞生为前端工程化催生了大量优良的构建工具、编译工具，js 引擎的性能也始终在攀升，js 本身的标准和语言个性也一直的进化，以及和相干组件化开发的优良库如春笋版冒出（react、vue、angular、svelte…）, 良好的 npm 生态让库共享大海捞针等，在这种有利于前端工程化的土壤培养下，让咱们面对简单的前端我的项目时，如可疏忽 seo 优化，首屏速度等因素时（只管也有相似的解决方案），偏向于从服务器渲染迁徙到浏览器端渲染了。
微前端之 5 个核心思想
前端工程化也面临着后端同样的问题，一个工程随着工夫流逝会逐步重叠大量业务，从而让一个前端我的项目缓缓演变成一个巨石利用，基于此背景下在 micro-frontends 上对微前端做了如下论述：
微前端背地的想法是将网站或 Web 应用程序视为由 独立团队领有 的 性能的组合 。每个团队都有 不同的业务畛域 或工作 ，它关怀和专一于，一个团队是 跨职能 的，从数据库到用户界面，端到端地 开发其性能，但这个想法并不陈腐，它与自蕴含零碎的概念有很多共同之处。在过来，这种办法被称为垂直零碎的前端集成。但微前端显然是一个更敌对、更简洁的术语。
并进一步提炼出以下 5 点微前端的核心思想
- 与技术无关
每个团队都应该可能抉择和降级他们的堆栈，而无需与其余团队协调。自定义元素是暗藏实现细节同时为其他人提供中性界面的好办法。 - 隔离团队代码
不要共享运行时，即便所有团队都应用雷同的框架。构建自蕴含的独立应用程序。不要依赖共享状态或全局变量。 - 建设团队前缀
就尚无奈隔离的命名约定达成统一。命名空间 CSS、事件、本地存储和 Cookie，以防止抵触并明确所有权。 - 优先应用本机浏览器性能而不是自定义 API
应用浏览器事件进行通信，而不是构建全局 PubSub 零碎。如果你真的须要构建一个跨团队的 API，尽量让它尽可能简略。 - 构建弹性站点
即便 JavaScript 失败或尚未执行，您的性能也应该很有用。应用通用渲染和渐进加强来进步感知性能。
微前端之模块联邦
以上阶段 1 里强调的 5 点个性看起来仿佛给微前端下了一个相当完满的定义，以至于起初的各种微前端框架都在这 5 个核心思想领导上来做实现，直到 2020 年 webpack 5 module federation（以下咱们简称 MF）模块联邦诞生，并对此个性在官网做了一个很简略的介绍：
模块联结的动机，让多个独自的构建应该可组合为一个应用程序, 这些独自的构建之间不应该有依赖关系，因而它们能够独自开发和部署，这通常被称为 微前端，但不限于此。
细细玩味这段话，咱们发现 webpack 5 视角下的 微前端 仅须要蕴含 3 个特点：独立开发、独立部署、运行时组合。
如果你基于 webpack 5 MF 公布过近程模块，你会晓得它并不蕴含 micro-frontends 站点里提到的 隔离团队代码 这个关键点，只管咱们晓得波及到代码运行隔离须要用上 shadowrealm(将来的隔离计划)、proxy window、iframe 等计划，但 MF 并未强调这一点，所以看起来 MF 了解下的微前端是阉割版的微前端？
再思考微前端
咱们将 micro-frontends 和 webpack 5 两个出处的微前端定义做一个比照，并提出一个灵魂的拷问，是否以下表白成立？
事实上随着模块联邦这个概念开始逐步深入人心，微前端架构曾经决裂出两个方向：
容器型微前端
咱们把以 single-spa 为代表的这一类计划统称为 微容器，在 single-spa 走红之后市面很多基于 single-spa 二次封装的库如雨后春笋般涌出，典型的代表作如阿里的 qiankun，意在解决一些 single-spa 未解决的问题并让其更适宜企业级开发，同时也诞生了很多非 singlespa 系的框架，如京东的 micro-app、腾讯的 wujie 等，它们的细节实现各有差别，蕴含 js 沙箱隔离、css 隔离、iframe 编排、启用 web-component、window 代理、接入过程等各个中央的细节也各有千秋，但它们都一个很显著的特点，对应的模块粒度是整个利用，做出的产品能够了解为一种以宏观态的形式来组合多个利用交付给用户应用。
试想一下，你不会极其到以运行时隔离的形式去渲染多个按钮吧？
模块型微前端
相较于 微容器 宏观态的组合利用形式，微模块 则能够形容为宏观态的组合形式，它的粒度更小，小到能够是一个函数，一个根底的组件，对于开发者来说，引入 微模块 和引入一个一般的 js 包没有任何区别，他们在应用上也并无任何区别，但恰好是这一点！是它和 微容器 最大差别之一，微模块 的应用形式回归到了 js 语法自身。
微容器 和微模块 在开源社区均有很多实现，它们的特点很显著
所以基于两种计划搭建的微前端架构也是区别非常明显的
微前端技术该如何选型
咱们只有深刻理解到 微模块 是人造就假设运行在同一个宿主里（即同个一 js 环境里），它要解决的外围问题是大规模独立构建的利用间如何疾速动静共享公共模块这个辣手问题。
例如你有 100 个外部的前端我的项目依赖了 lodash-1.0.0，忽然该库裸露了一个破绽，你须要 100 个前端我的项目全副从新构建降级到 1.0.1 才代表平安解决此破绽问题，而基于模块联邦的 lodash，你仅须要构建一次 mf-lodash，其余我的项目即可援用到最新的平安代码。
再综合思考到两个以下关键点，就很容易得出技术如何选型的论断了：
- 1 是否须要多技术栈混合开发（react、vue…）
- 2 是否须要多版本技术栈同时迭代等(vue2, vue3…)
因为 微模块 是宏观态的组合形式，它能够迅速的将你逐步宏大的利用拆为一个个可独立部署的组件并再次组合起来，绝对于 微容器 计划，大多数时候或者你的新我的项目并不需要染指 微容器。
当你须要组合一些第三方利用或本人的其余技术栈利用，并须要让它的就是被隔离起来平安的运行时，微容器 是你武器库里适宜拿进去的强力武器。
事实上它们搭配起来混合应用将是相辅相成的完满组合，你能够先应用微容器再接入微模块做跨利用模块动静共享，或先应用微模块再套上微容器做运行时隔离，取决于你的我的项目倒退到了什么阶段。
混合架构的微前端实际
实际上，咱们在这方面曾经做了大量的工程实际，微容器推出了无界，微模块推出了 hel-micro
这里给出一个混合架构的例子可供大家参考：wujie 和 hel-mico 搭建微前端，大家能够将此思路复制到其余社区计划，例如（micro-app + mf）（qiankun + hel-micro）等。
例子里有无界容器里加载近程 react 组件的示例
有无界容器里加载近程 lodash 模块的示例
对于 hel-micro 与 wujie
hel-micro 是业内里首个模块联邦 sdk 化，免构建、热更新、工具链无关的微模块计划，让模块联邦技术从构建工具插件层面晋升到 sdk 层面，应用更灵便，模块流通性更好（工具链无关）。
无界微前端是一款基于 Web Components + iframe 微前端框架，具备成本低、速度快、原生隔离、性能强等一系列长处。
它们均已在腾讯云、腾讯新闻的多个 toB、toC 场景经验考验，期待你的关注与理解，让咱们一起在微前端畛域摸索出更多的可能性。
总结
本文探讨了很多对于微前端的新了解，你了解到究极奥义了么，是不是和你和你之前所接触的微前端概念有所不同呢，冀望你能在 容器型微前端 和 模块型微前端 之间找到最佳的平衡点并付诸实践。
