腾讯开源的 hel 提供了加载远程模块的能力，谈谈它的实现原理

candyTong
4,863 阅读8分钟

本文正在参加「金石计划 . 瓜分6万现金大奖」

腾讯开源的 hel，提供了一种运行时引入远程模块的能力，模块部署在 CDN，远程模块发布后，不需要重新构建发布，就能生效。

个人觉得它的实现原理非常的不错，因此分享给大家。

远程模块可以作为微模块（模块级别的微前端），是页面级别的微前端的一种补充，因为页面级别的微前端，如 qiankun、无界等，它们的粒度太粗了，有时候需要更细粒度的微前端，例如：组件、函数级别的。这种场景，就可以使用远程模块，来实现微模块的效果。

远程模块使用示例

import helMicro from 'hel-micro';

export async function callRemoteMethod() {
  const lib = await helMicro.preFetchLib('hel-tpl-remote-lib');
  return lib.num.random(22);
}
  1. 引入 hel-micro 模块
  2. 通过 helMicro.preFetchLib 拉取远程模块
  3. 调用远程模块

整个使用过程非常的简单易懂，但这样无法使用 TS 类型检查。

于是又有了以下的写法：

需要先在项目入口调用：

await helMicro.preFetchLib('hel-tpl-remote-lib');

然后代码中就可以这样使用了：

import remoteLib from 'hel-tpl-remote-lib';

function callRemoteMethod() {
  return remoteLib.num.random(19);
}

TS 类型则是由 hel-tpl-remote-lib 这个 npm 仓库提供。

hel 核心原理

概念约定

image-20221212224712919

  • 远程模块

    发布 CDN，在浏览器运行时，调用 helMicro.preFetchLib 真正拉取代码

  • 代理模块

    用于开发时的类型提示，上传到 npm。开发时安装并使用该 npm 包，可以获得 TS 类型提示

  • 元数据

​ 元数据是一份 json 配置清单，是在远程模块构建完成后，从构架产物中提取生成的。它记录了远程模块的名称、入口脚本路径等信息

hel 运行流程

image-20221213213539182

  1. 当调用 helMicro.preFetchLib 时，先拉取元数据，从元数据中获取到入口脚本的 url，然后拉取远程模块入口并执行，最后 helMicro.preFetchLib 将模块返回，代码中就可以直接使用了。
  2. import 代理模块，实际上是从远程模块的缓存中读取模块。因此，必须要等待 helMicro.preFetchLib 拉取完成后，import 的代理模块才能够获取到远程模块

hel 的默认拉取元数据的方式，是根据远程模块名称，到 unpkg CDN 对应的 npm 包下，获取元数据 meta_data.json 文件。这个拉取元数据的过程也可以开发者自定义。

整个流程非常简单，但难度在于，如何构建打包出代理模块和远程模块

模块构建

代理模块

代理模块负责以下内容：

  • 在运行时读取远程模块的缓存
  • 用于提供 TS 类型支持

运行时读取远程模块的缓存

hel 提供了 exposeLib 函数，用于读取远程模块的缓存

打包代理模块时，参考以下代码作为构建入口：

import type { LibProperties } from './你真正的模块代码';
import { exposeLib } from 'hel-lib-proxy';

// 读取远程模块缓存，远程模块名为：hel-tpl-remote-lib
export const lib = exposeLib<LibProperties>('hel-tpl-remote-lib');

// export 类型
export type Lib = LibProperties;

// export 远程模块的缓存代码
export default lib;

该入口文件主要做了以下事情：

  • export 导出 TS 类型
  • 使用 exposeLib，将远程模块的缓存，暴露出来

以上述代码作为入口打包，实际上并没有将模块真实代码打包到产物中。因此代理模块，是一个非常小的模块，没有任何的模块逻辑。

在项目中使用远程模块 hel-tpl-remote-lib，最后打包只会打包代理模块这一小部分代码，不会将真正的代码打包到项目的产物中，因此还能提升项目的构建速度。

真正的代码，是运行时，在 preFetchLib 拉取远程模块时加载并运行的。

提供 TS 支持

只需要在 package.json 中声明 typing 字段：

{
   "main": "hel_proxy/entry.js",
   "typings": "typings/index.d.ts",
}

  • typing 的值为构建时生成的 TS 类型声明文件的路径。

  • main 则用于声明代理模块的入口，指向的是打包后的产物。

发布

代理模块直接发布到 npm 即可，按 npm 包的用法正常引入和使用即可

远程模块

远程模块的职责如下：

  • 提供远程模块的真实运行代码
  • 通知 hel 的 preFetchLib 函数，远程模块加载完成
  • 提供 index.html，用于提取元数据，例如提取出远程模块的入口（加载时，需要首先拉取哪些代码）

要做到以上的内容，远程的模块，也需要用一个入口文件再包一层，伪代码如下：

import { libReady } from '@tencent/hel-lib-proxy';

async function main() {
  // 这里是 import 真正的模块代码了
  const lib = await import('./你真正的模块代码');
  // 注意此处传递的是 default
  libReady('hel-tpl-remote-lib', lib.default);
}

main().catch(console.error);

加载入口时立即调用 main 函数：

  • import 真正的模块代码
  • 调用 libReady 并传入远程模块的值，该函数会通知 preFetchLib，远程模块已经加载完成

如果一个远程模块，依赖另外一个远程模块，怎么办？

假如：hel-tpl-remote-lib 依赖 other-lib，other-lib 为另一个远程模块。即

// hel-tpl-remote-lib 的模块代码
import xxx from "other-lib"

那就 import other-lib 前，先执行 preFetchLib，拉取 other-lib。这样 other-lib 的代理模块，就能正确获取到内容。

import { LIB_NAME } from '../src/configs/subApp';
import { libReady } from '@tencent/hel-lib-proxy';

async function main() {
  // 如有其他远程包依赖并且需要在内部使用静态导入的语法，可使用 preFetchLib 来加载这些包体
  const { preFetchLib } = await import('@tencent/hel-micro');
  await preFetchLib('other-lib');

  // 必须要用动态 import，因为如果当前包，还依赖其他的 hel 微前端依赖，需要 preFetchLib 之后，再进行引入。
  const lib = await import('./你真正的模块代码');
  // 注意此处传递的是 default
  libReady('hel-tpl-remote-lib', lib.default);
}

如果存在嵌套的远程模块，就必须要用动态 import 引入真正的模块代码

await import('./你真正的模块代码')

元数据提取

hel 通过分析 index.html，来提取元数据，最重要的是要提取出模块的入口脚本，因为打包产物可能会有多个文件，要确定哪个才是入口。

假如有以下 HTML：

<!doctype html>
<html lang="en">
<script>
    这是一串内联 script
</script>
<script 
   src="https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/static/js/main.5ab2b93c.chunk.js"
></script>
</html>

那么会提取到两个入口脚本：

  • 内联脚本：内联脚本会被提取出来，存放到单独的文件，该文件的路径会被记录到元数据
  • main.5ab2b93c.chunk.js

上述 index.html 会得到以下元数据（节选）：

{
    bodyAssetList: [
      {
        "tag": "script",
        "attrs": {
          "src": "https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/hel_userChunk_1.js"
        }
      },
      {
        "tag": "script",
        "attrs": {
          "src": "https://unpkg.com/hel-tpl-remote-lib@2.0.0/hel_dist/static/js/main.5ab2b93c.chunk.js"
        }
      }
    ]
}

注意这里的资源路径是完整的 url 了。

preFetchLib 函数会读取元数据，然后拉取这些入口脚本。

发布

开源版本的 hel，远程模块和元数据，同样会发布到 npm。这样就可以从 unpkg 这个 CDN，直接拉取到元数据和远程模块

从元数据的入口脚本可以看出，入口脚本的路径，已经是指向了 unpkg

小结

以上内容，就是一个完整的 hel 的原理：

  • 在页面初始化前，先 preFetchLib 拉取远程模块，然后直接可以拿到远程模块的对象
  • 然后代理模块也能够从缓存中，获取到远程模块的内容

难点则在于如何打包远程模块和代理模块，需要遵守特定的规范：

  • 远程模块，则需要处理嵌套的远程模块，然后通知 preFetchLib 函数，加载完成
  • 代理模块，需要导出 TS 类型，并读取远程模块的缓存并导出
  • 元数据，需要根据 index.html 提取出入口脚本

但你觉得这就完了吗？其实没有。

元数据的妙用

hel 提供了自定义拉取元数据的能力，这意味着，我们有了控制的返回元数据的能力，元数据中有远程模块的入口，因此能控制拉取的远程模块。

下面是一个例子：

image-20221213215942195

元数据通过版本管理平台的接口拉取。

通过在版本管理平台上配置，可以返回的元数据的对应的远程模块版本，从而做到控制远程模块的版本号，能做到回滚，灰度等能力。

上述版本管理平台，其实在腾讯内部已经实现，但目前仍未开源，但从 github 上已经看到是计划中了

有了自定义拉取元数据的能力，这个过程就会有非常大的自由度，由此可以衍生出一个非常大的微模块生态。理论上可以做到但不限于以下的效果：

  • 控制全局的远程模块的版本
  • 快速回滚能力
  • 灰度能力、AB test 能力，根据地域分布、用户等条件分发不同的元数据
  • 按项目维度，进行版本控制，不同的项目，返回不同的元数据，从而使用不同的远程模块版本
  • ……

总结

不过截止目前（2022.12.13），开源 hel 目前提供的部署方式，只是部署到 unpkg CDN 上，对于公司项目来说，不太适合，需要提供更多的最佳实践；它的开源生态，也有待完善。

但不得不承认的是，hel 的整个思路，的确是较为优秀，值得学习和研究， 能够作为一种优秀的远程模块/微模块方案。

最后也希望 hel 能越做越好吧~

如果这篇文章对您有所帮助，可以点赞加收藏👍，您的鼓励是我创作路上的最大的动力。也可以关注我的公众号订阅后续的文章：Candy 的修仙秘籍（点击可跳转）

avatar
文章
阅读
粉丝

友情链接：