MicroFrontend on Time Friend

前端微服务化进阶4 - 跨框架共享组件(微件化)

Sat, 22 Jun 2019 22:17:36 +0000

在微前端中,我们可以根据自己的业务需求,让子模块使用不同框架技术栈.虽然到了这一步已经很美好了,那这就是微前端的终点吗?

答案是否定的,微前端的边界还可以更进一步的拓宽.

上一篇微前端的文章 https://time-friend.com/archive/qh7x5i5szfh/ 给大家介绍了,如何在相同技术栈的子模块之间,相互调用React组件.

那今天要说的就是,如何在不同技术栈之间的子模块相调用不同技术栈的组件.

最终,我们只需要根据我们的需求调用相关功能的组件,我们不需要管他是 react ,vue或者是angular写的.

你只管用,只知道他是一个组件就好了,不用关心太多~ 对于团队的组件积累,是有极大好处的.

场景

一般情况下,一个公司的前端团队的技术栈都是统一的.但也有前端团队使用不统一技术栈的时候. 比如:

时代的变迁,升级技术栈导致内部技术栈不统一
项目众多,因为需求不一致,其他的技术栈对于项目更加有力
…其他管理原因

当我们已经使用微前端架构来构建我们的项目的时候,我们的子模块有可能因为我们项目的需求导致使用了其他的技术栈,

如果我们使用了其他的技术栈,我们原来封装的组件就不能在新的项目中用了,所以我们需要要求组件可以跨框架共享使用.

我们该怎么做?

这里有提到微件仓库模块,这是一个单独的项目.你可以理解是以前的旧项目,当你需要这个旧项目的某一个组件的时候,可以直接从这个项目里面拿.

你也可以做成一个只提供组件的项目,毕竟在运行时一个子模块挂载到我们的项目中来是没有任何资源消耗的.

我们只要知道我们需要的组件从哪里来就行了,然后根据组件还有之前定义好的路由找到这个组件,调用他,使用他就好了.

基于Web component封装我们的组件

不同框架开发的组件,差异很大.想要串在一起使用,基本上是不可能的. 好在目前所有的框架都支持让组件以webcomponent的形式存在.

react: https://react.docschina.org/docs/web-components.html

vue : https://github.com/vuejs/vue-web-component-wrapper

angular: https://www.angular.cn/guide/elements#transforming-components-to-custom-elements

关于Web Components 的详细介绍

https://developer.mozilla.org/zh-CN/docs/Web/Web_Components

加载性能

如果一个页面依赖了很多跨框架的组件,必然出现网络方面的性能问题.

我们会在请求的中间加一层node服务,当页面请求多个跨框架的组件的时候,我们的node就会合并成单个文件,并且保存在硬盘上.

所以说,当这个页面被请求过之后,页面零散的组件便会合并在一起,第二次其他用户请求就不会有这种合并文件的处理,直接返回静态资源给客户端.

这种方式也不会对nodejs有太多额外的压力,

因为现在的页面结构还是相对静态稳定的,没有太多的动态定制化的东西.这个方案足以应付大多数的应用场景.

尾巴

经过不停的探索,微前端终于走到了微件化的这一步,感慨颇多~

我们从一个窗口只能加载单个页面, 再到多个页面(SPA), 再到现在的多个项目(微前端), 然后再可以控制不同组件在多个项目之间随意组合(微件化).

微前端的应用边界应该还可以拓展的更宽,还可以开发出更多惊喜的操作.

前端微服务化进阶3 - 跨模块共享组件

Sun, 12 May 2019 22:17:36 +0000

前端微服务化之后,我们会面临一个问题: 模块之间重复代码不能复用的问题.

如果使用npm管理我们的重复代码,我们会多出维护npm包的成本. 在子模块更新npm包版本,也是一件很麻烦的事情. 在js文件体积上也没有任何的优化.

组件共享

今天我们就来聊一聊如何在多个模块中同时使用一个组件.

思路

在base模块管理公共组件,将组件封装成动态组件,这样在打包的时候我们就可以将该组件切割成单独文件了. 当其他的子模块需要这个组件的时候,向Base模块动态获取.

实践

动态组件的封装

为了让其他模块可以按需加载我们的公共组件,我们需要对已有的组件封装成动态组件.

我这里使用的是 umi/dynamic,

他是基于https://github.com/jamiebuilds/react-loadable 封装了一层. 有兴趣的小伙伴可以自行了解.

import React from 'react';
import dynamic from 'umi/dynamic';
import PageLoading from '@/components/PageLoading'

export const Demo = dynamic(import( `../Demo`), {loading: () => <PageLoading />})

export default Demo;

对外提供获取动态组件的方法

在加载Base模块的时候,我们可以在window下暴露一个调用该模块动态组件的方法

window.getDynamicComponent = async function(name) {
 let component = null;
 component = await import(`@/components/dynamic/${name}`);
 return component[name];
};

子模块调用公共组件

因为base模块提供了一个获取公共组件的全局方法, 我们就可以在任何模块任何需要调用公共组件的地方去是使用它了.

 // 获取组件
 let component = await window.getDynamicComponent('Demo')

为了方便这种公共组件的使用,我们可以将这一方法封装成一个组件. 在调用公共组件,我们只需要声明就好了.

import React, { Component } from 'react';

// Matrix 在黑客帝国中是母体的意思
export default class Matrix extends Component {
 state = {
 DynamicComponent: null
 }

 static defaultProps = {
 $name: ""
 }

 async componentWillMount() {
 this.renderComponent()
 }

 componentWillReceiveProps(nextProps) {
 this.props = nextProps
 this.renderComponent()
 }

 async renderComponent() {
 const { $name } = this.props;
 try {
 if ($name) {
 const component = await window.getDynamicComponent($name)
 this.setState({
 DynamicComponent: component
 })
 }
 } catch (error) {
 this.setState({
 DynamicComponent: null
 })
 console.error(error)
 }
 }


 render() {
 const { DynamicComponent } = this.state;
 // 继承所有props
 return DynamicComponent && <DynamicComponent {...this.props} />;
 }
}

在实际页面中调用我们的公共组件

前端微服务化进阶2 - 本地开发指南

Mon, 22 Apr 2019 22:17:36 +0000

使用single-spa构建我们的微服务化的前端应用之后,其实有一个问题会一直困扰着我们, 就是如何有效的开发?如何与我们平时开发的前端应用一样简单,容易上手. 今天就以umi子模块为例,希望给到大家一个思路

今天我就介绍一种方法,希望对大家有帮助.

模块加载器

是否还记得我之前的模块加载器, https://time-friend.com/archive/1a60cede/

我们只需要将原来模块的加载器,封装成npm包.

然后在我们开发子模块项目的时候,运行我们的加载器

// umi src/app.js
import bootstrap from '@demo/demo-module-dev-loader' //封装过后的npm包
import store from 'store'; // 我们用于通讯的store文件

export async function render(oldRender) {
 if (process.env.NODE_ENV === 'development') {
 const main = oldRender();
 const res = await window.fetch('./project.json');
 let currentProject = await res.json();
 bootstrap({
 main,
 store, 
 prefix: currentProject.prefix
 });
 } else {
 oldRender();
 }
}

module-dev-loader

我们的demo-module-dev-loader里一样会有一个 Bootstrap.js文件,我们对他进行一些小的修改.

import * as singleSpa from 'single-spa';
import { registerApp,registerLocal } from './Register'

export default async function bootstrap (local) {
 // 拿到我们的项目配置文件,但是我们的本地是没有这个文件的.

 // 我们需要通过webpack代理到我们的线上测试环境,来拿到这个文件
 // 我们需要通过webpack代理到我们的线上测试环境,来拿到这个文件
 // 我们需要通过webpack代理到我们的线上测试环境,来拿到这个文件

 // 重要的事情说三遍
 const projectConfig = await window.SystemJS.import('/project.config.js')
 const res = await window.fetch('/project.json')
 const currentProject = await res.json()
 let {projects} = projectConfig;

 // 移除当前项目,因为当前项目会使用registerLocal方法注册
 projects = projects.filter(ele => ele.name !== currentProject.name)

 // 注册我们的线上测试环境的
 for (let index = 0; index < projects.length; index++) {
 const project = projects[index];
 await registerApp({
 name: project.name,
 main: `${project.main}`,
 store: project.store,
 base: project.base,
 prefix: project.prefix
 });
 }
 // 重点!!!
 // 注册本地正在开发的模块
 local && registerLocal(local)
 singleSpa.start();
}

registerLocal 方法展示

// Register.js
// 在原来registerApp上做了一些删减,大概的原理是一模一样的
export function registerLocal({base,main,prefix,store,name='local'}){
 // 导入store模块
let storeModule = {}, customProps = { globalEventDistributor: globalEventDistributor };

storeModule = store && { storeInstance: null };

 // 注册应用于事件派发器
 if (storeModule.storeInstance && globalEventDistributor) {
 // 取出 redux storeInstance
 customProps.store = storeModule.storeInstance;
 // 注册到全局
 globalEventDistributor.registerStore(storeModule.storeInstance);
 }

 singleSpa.registerApplication(name, async ()=> main, base ? (() => true) : hashPrefix({prefix}),customProps);
}


// 原来的registerApp方法,与以前一模一样,没有改动.
// 为了方便对比registerLocal,所以列出来 供大家参考
export async function registerApp(params) {
// 导入store模块
let storeModule = {}, customProps = { globalEventDistributor: globalEventDistributor };

// 尝试导入store
try {
 storeModule = params.store ? await window.SystemJS.import(params.store) : { storeInstance: null };
} catch (e) {
 console.log(`Could not load store of app ${params.name}.`, e);
 //如果失败则不注册该模块
 return
}
 // 注册应用于事件派发器
 if (storeModule.storeInstance && globalEventDistributor) {
 // 取出 redux storeInstance
 customProps.store = storeModule.storeInstance;

 // 注册到全局
 globalEventDistributor.registerStore(storeModule.storeInstance);
 }

 singleSpa.registerApplication(params.name, async ()=> await window.SystemJS.import(params.main), params.base ? (() => true) : hashPrefix(params), customProps);

}

umi插件

我们的umi插件也需要修改

前端微服务化进阶1 - 基于umi的子模块方案

Sat, 13 Apr 2019 22:17:36 +0000

距离第一篇聊前端微服务的文章已经时隔大半年,很多人对此感兴趣.

今天我们就聊一聊,我们如何基于umi来打造一个更完善的前端微服务的子模块.

如果你用的是react以外的前端技术栈, 我的很多处理做法也可以应用在其他技术栈上.

希望对你也有所帮助.

优秀的umi框架

在前端中后台项目上,前端微服务化的需求相对是比较旺盛一些的.

说到中后台,很多企业都是基于antd的组件来构建自己的项目.

自去年的see conf之后,蚂蚁的一款可插拔的企业级 react 应用框架 umi发布了.

这款框架与antd息息相关,antd结合umi使用那是相当的自然与流畅.

可以说,基于umi与antd构建的项目非常的漂亮.这么优秀的框架,如果让他适用于我们的前端微服务架构,岂不美哉?

umi也有相关的类似微服务方案: https://github.com/umijs/umi-example-monorepo

但是umi提供的方案,有很大的局限性. 如果可以接入single-spa的微服务方案,独立开发,独立部署等等的前端微服务化红利, 会让你的项目日后有更大的发展空间.

基于umi插件机制做到前端微服务化

umi 提供了非常强大的插件机制,正是由于这一点,我们才可以让umi也可以接入到微服务架构中来

umi插件介绍

umi插件的基本介绍:

https://umijs.org/zh/plugin/

umi插件开发

这里介绍了如何开发一个简单的umi插件:

https://umijs.org/zh/plugin/develop.html

接入single-spa的umi插件

export default (api, opts) => {
 // 以下的所有代码都写在这里面哦
};

渲染入口处理方法

定义一个动态的元素,当我们的base app 需要加载子模块的时候,会渲染出子模块需要渲染元素.

我们的子模块找到了自己模块需要渲染的节点的时候,就会渲染出来.

 const domElementGetterStr = `
 function domElementGetter() {
 let el = document.getElementById('submodule-page')
 if (!el) {
 el = document.createElement('div')
 el.id = 'submodule-page'
 }
 let timer = null
 timer = setInterval(() => {
 if (document.querySelector('#submoduleContent.submoduleContent')) {
 document.querySelector('#submoduleContent.submoduleContent').appendChild(el)
 clearInterval(timer)
 timer = null
 }
 }, 100)

 return el
 }`

使用single-spa-react

在umi的入口文件导入single-spa-react ,根据模块的属性来判断模块在运行时是否渲染在root节点上还是指定节点

在Webpack与Systemjs中构建你的Single-SPA微前端应用

Wed, 31 Oct 2018 01:00:00 +0000

这里给大家介绍一下基于Single-SPA编写的微前端应用在各种当下流行的构建工具中的使用方法.

Webpack 2+

在Webpack 2+版本中,支持import（）做代码分片. 在其他项目中 webpack2+的使用已经相当的广泛,这里就不做过多赘述.

import {registerApplication} from 'single-spa';

registerApplication('app-name', () => import('./my-app.js'), activeWhen);

function activeWhen() {
 return window.location.pathname.indexOf('/my-app') === 0;
}

SystemJS

在之前我们的项目中使用的就是SystemJS,方便部署应用后的二次构建.用起来页非常的方便.

import {registerApplication} from 'single-spa';

// Import the registered application with a SystemJS.import call
registerApplication('app-name-1', () => SystemJS.import('./my-app.js'), activeWhen);

// Alternatively, use the more out-of-date System.import (instead of SystemJS.import)
registerApplication('app-name-2', () => System.import('./my-other-app.js'), activeWhen);

function activeWhen() {
 return window.location.pathname.indexOf('/my-app') === 0;
}

Webpack 1

Webpack 1 不支持基于Promise的代码拆分.

想要按需加载,就必须在使用中用Promise二次的包装一次require.ensure

import {registerApplication} from 'single-spa';

 //app1 不使用按需加载与代码拆分 :(
import app1 from './app1';

// 不用按需加载与代码拆分,直接注册 :(
registerApplication('app-1', () => Promise.resolve(app1), activeWhen);


// app-2使用依赖加载方法
registerApplication('app-2', app2InPromise, activeWhen);

// 重新包装一次
function app2InPromise() {
 return new Promise((resolve, reject) => {
 require.ensure(['./app-2.js'], require => {
 try {
 resolve(require('./app-2.js'));
 } catch(err) {
 reject(err);
 }
 });
 });
}

function activeWhen() {
 return window.location.pathname.indexOf('/my-app') === 0;
}

Single-SPA微前端框架的使用Demo汇总

Wed, 31 Oct 2018 00:00:00 +0000

这些是在 github 能找到的 single-spa 微前端的 Demo:

single-spa-examples

这是一个 single-spa 做的官方例子,这是在线 demo.

simple-single-spa-webpack-example

这是基于 webpack 构建的使用例子,webpakc 版本可能有点低,但是思想是一样的.

single-spa-angular-cli-examples

基于 angular-cli 做的 angular 例子,适用于 angular 2.0+ 的版本.

single-spa-es5-angularjs

angularjs 的例子,也就是 angularjs1.0 的版本.

single-spa-portal-example

这已经是一个非常完整的多技术栈用例了,里面集成了多技术栈与模块之间通讯的思路,非常值得研究.

microfrontend-base-demo

这是在我们项目中萃取的 base 模块 demo

microfrontend-submodule-demo

这是在我们项目中萃取的子模块 demo

前端微服务化解决方案8 - 二次构建

Fri, 07 Sep 2018 01:00:00 +0000

二次构建

进一步优化我们的微前端性能

在微前端这种形势的架构,每个模块都会输出固定的文件,比如之前说的:

项目配置文件
Store.js 文件
main.js 渲染入口文件

这三个,是微前端架构中每个模块必要的三个文件.

在模块加载器启动整个项目的时候,都必须要加载所有模块的配置文件与 Store.js 文件. 在前面的文章中有说 配置自动化的问题,这其实就是一种简单的二次构建. 虽然每一个模块的配置文件体积不是很大,但是每一个文件都会加载,是项目启动的必要文件. 每一个文件都会占一个 http 请求,每一个文件的阻塞都会影响项目的启动时间.

所以,我们的Store.js也必须是要优化的. 当然如果我们的模块数量不是很多的话,我们没有优化的必要.但是一旦项目变得更加庞大,有好几十个模块. 我们不可能一次加载几十个文件,我们必须要在项目部署之后,还要对整个项目重新再次构建来优化与整合我们的项目.

我们的 Store.js 是一个 amd 模块,所以我们需要一个合并 amd 模块的工具.

Grunt or Gulp

像这样的场景,用 grunt,gulp 这样的任务管理工具再合适不过了. 不管这两个工具好像已经是上个世纪的东西了,但是他的生态还是非常完善的.用在微前端的二次构建中非常合适.

例如 Gulp:

const gulp = require("gulp");
const concat = require("gulp-concat");

gulp.task("storeConcat", function () {
 gulp
 .src("project/**/Store.js")
 .pipe(concat("Store.js")) //合并后的文件名
 .pipe(gulp.dest("project/"));
});

像这样的优化点还有非常多,在项目发布之后,在二次构建与优化代码. 在后期庞大的项目中,是有很多空间来提升我们项目的性能的.

未完待续 …

前端微服务化解决方案 1 - 思考

前端微服务化解决方案 2 - Single-SPA

前端微服务化解决方案 3 - 模块加载器

前端微服务化解决方案7 - 静态数据共享

Thu, 06 Sep 2018 01:00:00 +0000

在前面的一些介绍,相信你对微前端已经有了一个相对完整的认知. 下面介绍一下,再开发过程中我的一些小技巧与处理方法.

动态入口

当有新的子模块会挂载到项目中的时候,在 UI 中肯定需要一个新的入口进入子模块的 UI. 而这样一个入口,是需要动态生成的.

例如:图中左边的菜单,不应该是代码写死的.而是根据每个模块提供的数据自动生成的.

不然每次发布新的模块,我们都需要在最外面的这个框架修改代码.这样就谈不上什么独立部署了.

静态数据共享

想要达到上面所的效果,我们可以这样做.

// ~/common/menu.js

import { isUrl } from '../utils/utils'
let menuData = [
 {
 name: '模块1',
 icon: 'table',
 path: 'module1',
 rank: 1,
 children: [
 {
 name: 'Page1',
 path: 'page1',
 },
 {
 name: 'Page2',
 path: 'page2',
 },
 {
 name: 'Page3',
 path: 'page3',
 },
 ],
 }
]
let originParentPath = '/'
function formatter(data, parentPath = originParentPath, parentAuthority) {
 ...
}

// 在这里,我们对外导出 这个模块的菜单数据
export default menuData

// Store.js
import { createStore, combineReducers } from 'redux'
import menuDate from './common/menu'
import createHistory from 'history/createBrowserHistory'
const history = createHistory()
...

// 我们拿到数据之后,用一个reducer函数返回我们的菜单数据.
function menu() {
 return menuDate
}

...


// 最终以Store.js对外导出我们的菜单数据,在注册的时候,每个应用都可以拿到这个数据了
export const storeInstance = createStore(combineReducers({ namespace: () => 'list', menu, render, to }))

当我们的 Base 模块,拿到所有子模块的菜单数据,把他们合并后,就可以渲染出正确的菜单了.

前端微服务化解决方案6 - 构建与部署

Wed, 05 Sep 2018 01:00:00 +0000

微前端打包构建

微前端项目的打包,是有一些需要注意的点以 webpack 为例:

amd 模块

在之前的文章,我们有提到我们的加载器,是基于 System.js 来做的. 所以我们微前端的模块最终打包,是要符合模块规范的. 我们使用的是amd模块规范来构建我们的模块.

指定基础路径

因为模块打包后,调用模块出口文件的,是模块加载器. 为了清晰的管理每个模块,并且正确的加载到我们每一个模块的资源, 我们给模块的资源都指定一个publicPath.

下面给出一个简单的 webpack 配置,这些配置我只是列出一些必要选项. 并不是一个完整的 webpack 配置,后续我会提供完整的微前端的 Demo,提供大家参考这些配置都是基于 create-react-app 的配置做的修改. 只要明白了配置的意图,明白我们打包出来的最终是一个什么样的包, 不管打包工具以后怎么变,技术栈怎么变,最后都是可以对接到微前端中来.

这里给出 project.json 的内容,便于后面的配置文件的阅读

// project.json
{
 "name": "name", //模块名称
 "path": "/project", //模块url前缀
 "prefix": "/module-prefix/", //模块文件路径前缀
 "main": "/module-prefix/main.js", //模块渲染出口文件
 "store": "/module-prefix/store.js",//模块对外接口
 "base": true // 是否为baseapp
 }


// 引入项目配置文件,也是前面说的 模块加载器必要文件之一
const projectConfig = require('./project.json')

let config = {
 entry: {
 main: paths.appIndexJs, //出口文件,模块加载器必要文件之一
 store: paths.store // 对外api的reducer文件,模块加载器必要文件之一
 },
 output: {
 path: paths.appBuild,
 filename: '[name].js?n=[chunkhash:8]',
 chunkFilename: 'static/js/[name].[chunkhash:8].chunk.js',
 publicPath: projectConfig.prefix, //在output中指定模块配置好的 publicPath
 libraryTarget: 'amd', //对外输出 amd模块,便于 system.js加载
 library: projectConfig.name, //模块的名称
 },
 },
 module: {
 rules: [
 {
 oneOf: [
 {
 test: [/\.bmp$/, /\.gif$/, /\.jpe?g$/, /\.png$/],
 // loader: 'happypack/loader?id=url',
 loaders: [{
 loader: require.resolve('url-loader'),
 options: {
 limit: 5000,
 name: 'static/media/[name].[hash:8].[ext]',
 publicPath: projectConfig.prefix, //我们需要在静态文件的loader加上publicPath
 },
 }]
 },
 {
 test: /\.(js|jsx|mjs)$/,
 include: paths.appSrc,
 loader: 'happypack/loader?id=babel',
 options: {
 name: 'static/js/[name].[hash:8].[ext]',
 publicPath: projectConfig.prefix, //在静态文件的loader加上publicPath
 },
 },
 {
 loader: require.resolve('file-loader'),
 exclude: [/\.(js|jsx|mjs)$/, /\.html$/, /\.json$/],
 options: {
 name: 'static/media/[name].[hash:8].[ext]',
 publicPath: projectConfig.prefix, //在静态文件的loader加上publicPath
 },
 },
 ],
 },
 ],
 },
}

部署

前端单页面的部署,不管怎么自动化,工具怎么变. 都是把打包好的静态文件,放到服务器的正确位置下. 微前端的部署,是一个应用聚合的过程,我们如何把一个个模块最后接入到一个完整的项目中的呢?

前端微服务化解决方案5 - 路由分发

Tue, 04 Sep 2018 01:00:00 +0000

路由分发式微前端

从应用分发路由到路由分发应用

用这句话来解释,微前端的路由,再合适不过来.

路由分发式微前端，即通过路由将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决。就当前而言，通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。但是它们并不是，每次用户从 A 应用到 B 应用的时候，往往需要刷新一下页面。 – 引用自 phodal 微前端的那些事儿

在模块加载器那一章的示例代码,已经非常充分了展示了路由分发应用的步骤.

在单页面前端的路由,目前有两种形式, 一种是所有主流浏览器都兼容多 hash 路由, 基本原理为 url 的 hash 值的改变,触发了浏览器 onhashchange 事件,来触发组件的更新

还有一种是高级浏览器才支持的 History API, 在 window.history.pushState(null, null, "/profile/");的时候触发组件的更新

// hash 模式,项目路由用的是hash模式会用到该函数
export function hashPrefix(app) {
 return function (location) {
 let isShow = false;
 //如果该应用 有多个需要匹配的路劲
 if (isArray(app.path)) {
 app.path.forEach((path) => {
 if (location.hash.startsWith(`#${path}`)) {
 isShow = true;
 }
 });
 }
 // 普通情况
 else if (location.hash.startsWith(`#${app.path || app.url}`)) {
 isShow = true;
 }
 return isShow;
 };
}

// pushState 模式
export function pathPrefix(app) {
 return function (location) {
 let isShow = false;
 //如果该模块 有多个需要匹配的路径
 if (isArray(app.path)) {
 app.path.forEach((path) => {
 if (location.pathname.indexOf(`${path}`) === 0) {
 isShow = true;
 }
 });
 }
 // 普通情况
 else if (location.pathname.indexOf(`${app.path || app.url}`) === 0) {
 isShow = true;
 }
 return isShow;
 };
}

// 应用注册
export async function registerApp(params) {
 // 第三个参数为,该模块是否显示
 singleSpa.registerApplication(
 params.name, // 模块名字
 () => SystemJS.import(params.main), // 模块渲染的入口文件
 params.base ? () => true : pathPrefix(params) // 模块显示的条件
 );
}

路由分发应用

当 url 前缀,与配置中的 url 前缀保持一致的时候, singleSpa 会激活对应的模块,然后把模块内容渲染出来.

前端微服务化解决方案4 - 消息总线

Mon, 03 Sep 2018 01:00:00 +0000

微前端的消息总线,主要的功能是搭建模块与模块之间通讯的桥梁.

黑盒子

问题 1:

应用微服务化之后,每一个单独的模块都是一个黑盒子, 里面发生了什么,状态改变了什么,外面的模块是无从得知的. 比如模块A想要根据模块B的某一个内部状态进行下一步行为的时候,黑盒子之间没有办法通信.这是一个大麻烦.

问题 2

每一个模块之间都是有生命周期的.当模块被卸载的时候,如何才能保持后续的正常的通信?

ps. 我们必须要解决这些问题,模块与模块之间的通讯太有必要了.

打破壁垒

在 github 上single-spa-portal-example,给出来一解决方案.

基于 Redux 实现前端微服务的消息总线(不会影响在编写代码的时候使用其他的状态管理工具).

大概思路是这样的:

每一个模块,会对外提供一个 Store.js.

这个文件里面的内容,大致是这样的.

import { createStore, combineReducers } from "redux";

const initialState = {
 refresh: 0,
};

function render(state = initialState, action) {
 switch (action.type) {
 case "REFRESH":
 return { ...state, refresh: state.refresh + 1 };
 default:
 return state;
 }
}

// 向外输出 Store
export const storeInstance = createStore(
 combineReducers({ namespace: () => "base", render })
);

对于这样的代码,有没有很熟悉? 对,他就是一个普通的 Store 文件, 每一个模块对外输出的Store.js,就是一个模块的 Store.

Store.js 如何被使用?

我们需要在模块加载器中,导出这个 Store.js

于是我们对模块加载器中的Register.js文件 (该文件在上一章出现过,不懂的同学可以往回看)

进行了以下改造:

前端微服务化解决方案3 - 模块加载器

Mon, 03 Sep 2018 00:00:00 +0000

微前端的模块加载器,主要功能为:

项目配置文件的加载
项目对外接口文件的加载(消息总线会用到,后续会提)
项目入口文件的加载

以上也是每一个单模块,不可缺少的三部分

配置文件

我们实践微前端的过程中,我们对每个模块项目,都有一个对外的配置文件. 是模块在注册到 singe-spa 时候所用到的信息.

{
 "name": "name", //模块名称
 "path": "/project", //模块url前缀
 "prefix": "/module-prefix/", //模块文件路径前缀
 "main": "/module-prefix/main.js", //模块渲染出口文件
 "store": "/module-prefix/store.js",//模块对外接口
 "base": true
 // 当模块被定性为baseApp的时候,
 // 不管url怎么变化,项目也是会被渲染的,
 // 使用场景为,模块职责主要为整个框架的布局或者一直被渲染,不会改变的部分
 }

当我们的模块,有多种 url 前缀的时候,path 也可以为数组形式

{
 "path": ["/project-url-path1/","/project-url-path2/"], //项目url前缀
 }

配置自动化

我们每个模块都有上面所描述的配置文件,当我们的项目多个模块的时候,我们需要把所有模块的配置文件聚合起来. 我这里也有写一个脚本.

micro-auto-config

使用方法:

npm install micro-auto-config -g

# 在项目根目录,用pm2启动该脚本,便可启动这个项目的配置自动化
pm2 start micro-auto-config

大概思路是:当模块部署,服务器检测到项目文件发生改变,便开始找出所有模块的配置文件,把他们合并到一起. 以数组包对象的形式输出一个总体的新配置文件 project.config.js. 当我们一个模块配置有更新,部署到线上的时候,项目配置文件会自动更新.

模块加载器

这个文件直接引入到 html 中,也就是上一篇文章中的single-spa-config.js 升级版. 在加载模块的时候,我们使用 SystemJS 作为我们的模块加载工具.

"use strict";
import "../libs/es6-promise.auto.min";
import * as singleSpa from "single-spa";
import { registerApp } from "./Register";

async function bootstrap() {
 // project.config.js 文件为所有模块的配置集合
 let projectConfig = await SystemJS.import("/project.config.js");

 // 遍历,注册所有模块
 projectConfig.projects.forEach((element) => {
 registerApp({
 name: element.name,
 main: element.main,
 url: element.prefix,
 store: element.store,
 base: element.base,
 path: element.path,
 });
 });

 // 项目启动
 singleSpa.start();
}

bootstrap();

Register.js

import "../libs/system";
import "../libs/es6-promise.auto.min";
import * as singleSpa from "single-spa";

// hash 模式,项目路由用的是hash模式会用到该函数
export function hashPrefix(app) {
 return function (location) {
 let isShow = false;
 //如果该应用 有多个需要匹配的路劲
 if (isArray(app.path)) {
 app.path.forEach((path) => {
 if (location.hash.startsWith(`#${path}`)) {
 isShow = true;
 }
 });
 }
 // 普通情况
 else if (location.hash.startsWith(`#${app.path || app.url}`)) {
 isShow = true;
 }
 return isShow;
 };
}

// pushState 模式
export function pathPrefix(app) {
 return function (location) {
 let isShow = false;
 //如果该模块 有多个需要匹配的路径
 if (isArray(app.path)) {
 app.path.forEach((path) => {
 if (location.pathname.indexOf(`${path}`) === 0) {
 isShow = true;
 }
 });
 }
 // 普通情况
 else if (location.pathname.indexOf(`${app.path || app.url}`) === 0) {
 isShow = true;
 }
 return isShow;
 };
}

// 应用注册
export async function registerApp(params) {
 singleSpa.registerApplication(
 params.name,
 () => SystemJS.import(params.main),
 params.base ? () => true : pathPrefix(params)
 );
}

//数组判断 用于判断是否有多个url前缀
function isArray(o) {
 return Object.prototype.toString.call(o) == "[object Array]";
}

未完待续 …

前端微服务化解决方案2 - Single-SPA

Sun, 02 Sep 2018 22:17:36 +0000

技术选型

经过各种技术调研我们最终选择的方案是基于 Single-SPA 来实现我们的前端微服务化.

你的浏览器不支持视频

Single-SPA

一个用于前端微服务化的 JavaScript 前端解决方案

使用 Single-SPA 之后,你可以这样做:

(兼容各种技术栈)在同一个页面中使用多种技术框架(React, Vue, AngularJS, Angular, Ember 等任意技术框架),并且不需要刷新页面.
(无需重构现有代码)使用新的技术框架编写代码,现有项目中的代码无需重构.
(更优的性能)每个独立模块的代码可做到按需加载,不浪费额外资源.
每个独立模块可独立运行.

下面是一个微前端的演示页面 (你可能需要科学的上网) https://single-spa.surge.sh/

以上是官方例子,但是官方例子中并没有解决一个问题.就是各种技术栈的路由实现方式大相径庭,如何做到路由之间的协同? 后续文章会讲解,如何解决这样的问题.

单体应用对比前端微服务化

普通的前端单体应用

微前端架构

Single-SPA 的简单用法

1.创建一个 HTML 文件

<html>
 <body>
 <div id="root"></div>
 <script src="single-spa-config.js"></script>
 </body>
</html>

2.创建 single-spa-config.js 文件

// single-spa-config.js
import * as singleSpa from "single-spa";

// 加载react 项目的入口js文件 (模块加载)
const loadingFunction = () => import("./react/app.js");

// 当url前缀为 /react的时候.返回 true (底层路由)
const activityFunction = (location) => location.pathname.startsWith("/react");

// 注册应用
singleSpa.registerApplication("react", loadingFunction, activityFunction);

//singleSpa 启动
singleSpa.start();

封装 React 项目的渲染出口文件

我们把渲染 react 的入口文件修改成这样,便可接入到 single-spa

前端微服务化解决方案1 - 思考

Sat, 01 Sep 2018 22:17:36 +0000

近几年,微服务架构在后端技术社区大红大紫,它被认为是 IT 软件架构的未来技术方向.我们如何借鉴后端微服务的思想来构建一个现代化前端应用? 在这里我提供一个可以在产品中真正可以落地的前端微服务解决方案.

微服务化后端前后端对比

后端微服务化的优势:

复杂度可控: 体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
独立部署: 由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。
技术选型灵活: 微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
容错: 当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
扩展: 单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。

前端微服务化后的优势:

复杂度可控: 每一个 UI 业务模块由独立的前端团队开发,避免代码巨无霸,保持开发时的高速编译,保持较低的复杂度,便于维护与开发效率。
独立部署: 每一个模块可单独部署,颗粒度可小到单个组件的 UI 独立部署,不对其他模块有任何影响。
技术选型灵活: 也是最具吸引力的,在同一项目下可以使用如今市面上所有前端技术栈,也包括未来的前端技术栈。
容错: 单个模块发生错误,不影响全局。
扩展: 每一个服务可以独立横向扩展以满足业务伸缩性，与资源的不必要消耗；

我们何时需要前端微服务化?

项目技术栈过于老旧,相关技能的开发人员少,功能扩展吃力,重构成本高,维护成本高.
项目过于庞大,代码编译慢,开发体差,需要一种更高维度的解耦方案.
单一技术栈无法满足你的业务需求

其中面临的问题与挑战

我们即将面临以下问题:

我们如何实现在一个页面里渲染多种技术栈?
不同技术栈的独立模块之间如何通讯?
如何通过路由渲染到正确的模块?
在不同技术栈之间的路由该如何正确触发?
项目代码别切割之后,通过何种方式合并到一起?
我们的每一个模块项目如何打包?
前端微服务化后我们该如何编写我们的代码?
独立团队之间该如何协作?

后续的文章我会一一解答以上问题,一起挖掘前端微服务的潜力. 跳出概念,实实在在的落地到你的项目中. 未完待续 …

前端微服务化解决方案 1 - 思考

前端微服务化解决方案 2 - Single-SPA

前端微服务化解决方案 3 - 模块加载器

前端微服务化解决方案 4 - 消息总线

前端微服务化解决方案 5 - 路由分发

MicroFrontend on Time Friend

前端微服务化进阶4 - 跨框架共享组件(微件化)

场景

我们该怎么做?

基于Web component封装我们的组件

关于Web Components 的详细介绍

加载性能

尾巴

相关系列文章

前端微服务化进阶3 - 跨模块共享组件

组件共享

思路

实践

动态组件的封装

对外提供获取动态组件的方法

子模块调用公共组件

前端微服务化进阶2 - 本地开发指南

模块加载器

module-dev-loader

registerLocal 方法展示

umi插件

前端微服务化进阶1 - 基于umi的子模块方案

优秀的umi框架

基于umi插件机制做到前端微服务化

umi插件介绍

umi插件开发

接入single-spa的umi插件

渲染入口处理方法

使用single-spa-react

在Webpack与Systemjs中构建你的Single-SPA微前端应用

Webpack 2+

SystemJS

Webpack 1

Single-SPA微前端框架的使用Demo汇总

single-spa-examples

simple-single-spa-webpack-example

single-spa-angular-cli-examples

single-spa-es5-angularjs

single-spa-portal-example

microfrontend-base-demo

microfrontend-submodule-demo

前端微服务化解决方案8 - 二次构建

二次构建

Grunt or Gulp

相关文章

前端微服务化解决方案7 - 静态数据共享

动态入口

静态数据共享

前端微服务化解决方案6 - 构建与部署

微前端打包构建

amd 模块

指定基础路径

部署

前端微服务化解决方案5 - 路由分发

路由分发式微前端

从应用分发路由到路由分发应用

路由分发应用

前端微服务化解决方案4 - 消息总线

黑盒子

问题 1:

问题 2

打破壁垒

Store.js 如何被使用?

前端微服务化解决方案3 - 模块加载器

配置文件

配置自动化

模块加载器

Register.js

前端微服务化解决方案2 - Single-SPA

技术选型

Single-SPA

单体应用对比前端微服务化

普通的前端单体应用

微前端架构

Single-SPA 的简单用法

1.创建一个 HTML 文件

2.创建 single-spa-config.js 文件

封装 React 项目的渲染出口文件

前端微服务化解决方案1 - 思考

微服务化后端前后端对比