如何接地气地接入微前端?

简介： 微前端带来明显好处的同时，也面临着痛点。对于已有站点，如何在老的技术栈基础上接入一个微前端？须要哪些通用功能？如何解决插件机制？本文分享一种微前端的接入方案和实现细则。

一 、前言

微前端，这个概念已经在国内不止一次的登上各大热门话题，它所解决的问题也很明显，这几个微前端所提到的痛点在咱们团队所维护的项目中也是很是凸显。

但我始终认为，一个新的技术、浪潮，往往被讨论最热门的必定是他背后所表明的杰出思考。

"微前端就是...xx 框架，xx 技术"

这种话就有点把这种杰出的思路说的局限了，我只能认为他是外行人，来蹭这个词的热度。

在我所负责的项目和团队中，已经有很是大的存量技术栈和页面已经在线上运行，任何迭代升级都必需要保证当心翼翼，万无一失。

能够说，从必定程度来说，微前端所带来的这些好处是从用户体验和技术维护方面的，对业务的价值并不能量化体现，落地这项技术秉着既要也要还要的指导方针。

咱们对存量技术栈必定须要保持敬畏，隔离，影响范围可控的几个基本要素，而后再考虑落地实施微前端方案。

因此，在这个基本要素和指导方针下，要落地这项新的技术，必定要充分了解当前改造站点所存在的技术方案、占比以及当前成熟的微前端框架已提供的能力差别，切勿生搬硬套。

二 、背景

我所在团队维护的项目都是些 PC 操做后台（Workstation），这些工做台会存在不一样的国家，不一样时区，不一样合做方等等问题。

若是须要开发一个新的页面需求，极可能投入进来的开发人员都来自不一样团队，此时咱们要在完成现有需求的同时还须要保证多个管理页面的风格统一，设计规范统一，组件统一，交互行为统一这很是困难。

当该业务须要迁移到另一个工做台时，虽然须要保持逻辑一致，但导航栏、主题等却不一样。

当前存量的方案都是采用 Java 直接进行 Template 渲染出 HTML，通过前面几代前辈的迭代，不一样系统中已经存在几种不一样技术栈产出的页面。

虽然都是 React 来实现的，可是前辈们都很是能折腾，没有一个是按照常规 React 组件形式开发出来的。

好比：

• 大部分页面是经过一份 JSON 配置，消费组件生成的页面。
• 部分页面是经过另一个团队定义的 JSON 配置消费组件生成的，与上面 JSON 彻底不同。
• 还有一部分页面，是经过一套页面发布平台提供的 JS Bundle 加载出来的。

面对这样的技术背景下，除了微笑的喊 MMP，含泪说着本身听不懂的话（存在即合理，不难要你干吗？），还得接地气地出这样一个落地方案。

三 、方案 & 流程图

首先，须要明确的分析出站点全部页面，所须要加载的通用特性：

上述是精简事后的一些通用功能特性，这里简单作下介绍：

• Layout Loader：用于加载不一样工做台的导航
• DADA Loader：用于加载 JSON 配置的页面
• Source Code Loader：用于加载 JS Bundle
• Micro Loader：用于处理微前端加载
• Log Report：用于日志埋点
• Time Zone：用于切换时区
• i18n：用于切换多语言
• Guider：用于统一管控用户引导

除此之外可能还会存在如下这些页面扩展能力：

• 安全监控
• 流量管控
• 弹窗管控
• 问卷调查
• 答疑机器人

粗略统一归类后来看，页面的大致加载流程应该是这样：

4、 实现细则

基于上述一个加载思路，首先须要作的是页面加载路径收口，须要保证全部页面的加载入口是在一个统一的 Loader 下，而后才能够较为系统的处理全部页面的加载生命周期。

在收敛的同时，一样须要保持开放，对核心加载路径要保持插件化开放，随时支持不一样的扩展能力，渲染技术栈接入。

1 、插件机制

因此，在主路径上，经过 Loader 加载配置进行处理，这份配置在主路径中提供上下文，而后交由插件进行消费，如图所示：

举个例子，拿一个独立的 JS Bundle 类型的子应用来讲：

<div id="root"></div>
<script src="https://cdn.address/schema-resolver/index.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/layout.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/source-code.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/micro-loader.js"></script>
<script src="https://cdn.address/schema-resolver/plugin/i18n.js"></script>

<script>
  SchemaResolver.render(
    {
      micro: true,
      host: "dev.address",
      hfType: "layout1",
      externals: ["//{HOST}/theme1/index.css"],
      // host is cdn prefix, the resource maybe in different env & country
      resource: {
        js: "/index.js",
        css: "/index.css",
      },
    },
    { container: document.querySelector("#root") }
  );
</script>

经过上述的 Plugin 引入，便可开启和消费不一样的配置。

这里引入了 Layout Plugin，该插件会消费 hfType 字段而后去加载对于的 Layout 资源提供 Container 交给下一个环节。

按照配置，当前页面开启了微前端，那么 Micro Loader 将会消费提供下来的 Container，而后创建沙箱（这里基于 qiankun），再提供 Container 出来。

最后交由 SourceCode Plugin 进行 Bundle 加载运行和渲染。若是这里是另一种渲染协议或者技术栈，则能够根据不一样配置交由不一样插件消费 Container。

这个过程当中，每一个环节的插件是不依赖的，可插拔的。

好比：

若是不加载 Layout Plugin 将不会消费 hfType 字段，也就不会将 Layout 插件逻辑注入到getContainer方法中，那么将直接获得由最外层下穿的 Container 进行渲染，也就不会有菜单相关透出。

若是不加载 Micro Plugin 一样不会有微前端的逻辑注入，也就不会创建沙箱，那么页面渲染流程将会按照常规模式继续运行。

2 、安全迁移

对于我所在团队负责的项目来讲，万万作不得一刀切的方案，因此针对现有存量页面，须要完整分析当前存量技术栈：

针对上述存量页面来讲，须要从左到右分批进行页面级别控制上线部署，对于左侧部分页面甚至须要作些项目改造后才可部署接入上线。

这类迁移测试须要处理出一套自动化 e2e 测试流程，经过分批迁移同时梳理出 微前端注册表 。

有了这两项流程保证及范围控制，当前方案所上线内容彻底可控，剩下要处理的大部分就是较为重复的体力活了，覆盖率也可量化。

三、 微前端形态

按照上述方案迁移，那么预期的微前端形态将会是：

• 每一个开启微前端的页面均可成为主应用。
• 微前端是插件可选项，若是由于微前端致使的业务异常可随时关闭。
• 同为微前端的页面路由相互之间切换可实现局部刷新形态，而跳转至非微前端注册表中的页面则会直接页面跳转。随着微前端页面覆盖率提升，局部刷新的覆盖率也会逐渐提升。
• 可经过不一样扩展插件，加载不一样技术栈类型的存量页面，转换为对应子应用。

在 SchemaResolver 中的注册和调用路径以下：

五 、总结

透过技术看本质，微前端所表明的杰出思惟，才是真正解决具体问题关键所在，只有解决了具体的业务问题，这项技术才有价值转换。

不要为了微前端作微前端，不要为了小程序作小程序。

当前，经过 SchemaResolver，能够针对不一样角色提供不一样的开放能力：

• 针对平台管理员，提供插件能力开放全局扩展能力。
• 针对页面开发者，提供标准化接入方案路径，提供多种技术栈接入能力，并没有感知提供微前端，多语言，埋点，菜单，主题加载等能力。解耦了不一样系统公共能力，同时，这种方式可让页面开发者快速将具体业务逻辑迁移到其余平台。
• 针对第三方接入者，不须要关心了解系统菜单、主题接入方式，提供统一的接入口径，经过微前端隔离技术栈、隔离子应用样式。最后经过统一的页面系统管控，轻松入住对应平台，同时能够全局看到站点页面状况。

做者：开发者小助手_LS
原文连接本文为阿里云原创内容，未经容许不得转载