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

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

一前言

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

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

"微前端就是...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：用于统一管控用户引导

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

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

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

四实现细则

基于上述一个加载思路，首先需要做的是页面加载路径收口，需要保证所有页面的加载入口是在一个统一的 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 & countryresource: {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 测试流程，通过分批迁移同时梳理出微前端注册表。

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

3 微前端形态

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

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

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

五总结

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

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

当前，通过 SchemaResolver，可以针对不同角色提供不同的开放能力：

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

原文链接：https://developer.aliyun.com/article/779730?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

如何接地气地接入微前端?相关推荐

vue接入微前端无界框架总结
写在前面: 这里就不介绍为什么使用微前端,真正做前端同学应该都知道的.本文主要是做个总结我在公司项目中实际使用微前端,项目已经在公司生产上运行了4个月左右了,目前没有发现什么问题,在此记录下,方便以后 ...
三、如何手动实现一个微前端框架雏形
如何手动实现一个微前端框架雏形一.了解微前端 1. 什么是微前端为了解决一整块儿庞大的前端服务所带来的变更和拓展方面的限制,将整体前端服务拆分成一些更小.更简单的,能够独立开发.测试部署的小块儿. ...
给3月要跳槽的前端提个醒！不了解微前端就别去面试了，不然……
在后端架构发展史上,如果要找一个低耦合高内聚架构模式的典范,微服务当仁不让. 在互联网业务急速扩张的背景下,微服务架构解决了后端服务中的"重",让每个服务都能够独立部署.独立扩展, ...
微前端架构在容器平台的应用
源宝导读:随着业务的发展,天际-星舟平台未来需要解决与其他云共创共建,跨团队高效协作等诸多问题,而星舟现有的技术架构将难以支撑.本文将介绍星舟平台如何通过向更先进的"微前端"架构演 ...
Bifrost微前端框架及其在美团闪购中的实践
Bifrost(英 ['bi:frɔst])原意彩虹桥,北欧神话中是连通天地的一条通道.而在漫威电影<雷神>中,Bifrost是神域--阿斯加德(Asgard)的出入口,神域的人通过它自由 ...
乾坤微前端_最全汇总之微前端知识和实战（EMP技术方案）
我们团队在早早聊的B站直播间分享了EMP微前端---团队半年以来的技术果实.分享的内容全在这里,会讲述微前端的由来,解决的问题,以及EMP微前端方案的不同之处,更有四个实战项目的总结,欢迎大家一起探讨 ...
前端路由跳转丢失端口号_如何在应用架构中设计微前端方案 icestark
文末福利:淘系前端团队 618 实践小册微前端在 2016 年 ThoughtWorks 的一个技术雷达上面提出后,不断有团队尝试将单体的前端 web 应用按不同维度进行拆分或者组合,再聚合到一个整 ...
万字长文阐述前端技术浪潮与应用
把握方向,迎接机遇,迎娶白富美,走向人生巅峰. 前端技术浪潮与应用一.前端基建 01.前端可视化 02.前端跨端跨栈 03.微前端 04.前端稳定性/质量保障体系 05.总结二.前端行业新资讯 ① ...
基于京东micro-app微前端框架的项目实践
1.微前端应用介绍 1.1.微前端概念微前端的概念是由ThoughtWorks在2016年提出的,它借鉴了微服务的架构理念,核心在于将一个庞大的前端应用拆分成多个独立灵活的小型应用,每个应用都可以独 ...

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

一前言