在SaaS或其它互联网软件中,新版本即使在开发/测试环境验证OK,也不敢保证上到生产环境就万无一失、用户是否喜欢,要可靠、稳定上线,最好要经过A/B测试与灰度发布。
新版本部署到生产环境之后,先不让普通用户使用,而是让测试人员或自动化到生产环境验证OK,再逐步放开部分用户使用新版本。如果发现问题,影响范围比较小,同时,可立即停用新版本与回滚。
在微前端中,整个软件由很多小块微前端动态拼装出来的,版本的多样化更加明显,也不能使用负载均衡控制(会造成长期缓存失效);如果写路由控制,微前端的个数足够多时就要写到手抖,经常的变更也更加容易出现问题。
在react-micro-frontend-server-go中,我们使用“用户分组隔离”与“激活百分比”来控制每个APP版本的用户服务范围,满足A/B测试与灰度发布的需求。在每个APP版本的元信息中,使用这两个字段(extra.userGroup、extra.activationPercent)标记其服务的范围。本文也主要讲解这两点的设计与体验。
继续阅读→
在设计React微前端方案时,已经考虑了对微前端APP的开发没有入侵。原有SPA的代码要上React微前端,可以做到原有JS代码改动不到100行,唯一的前提条件是已经使用CSS模块化避免全局污染、全局冲突。开发人员在本地开发微前端APP时,仍然有原先SPA般的开发体验。
本文主要从两个样例中讲解:
- react-micro-frontend-app-example,只依赖框架引入的公共库,使用Redux,也使用子APP做子路由。讲解原有APP如何搬迁到微前端。
- react-micro-frontend-app-example-echarts,相比app-example,还引入ECharts。讲解如何把ECharts也当作为一个微前端。当然也可以把ECharts包含在自身内部,但是与别的微前端APP就无法共用一份ECharts JS代码,用户浪费加载时间。
继续阅读→
在初始构建React微前端
时,我是想每个微前端APP版本如何兼容发布到K8s平台上面,像后端一样部署上去就可以路由到新版本,所以,在URL Path上添加Git Revision信息。但是,这样做造成微前端APP新版本发布之后,浏览器无法重用以前版本的任何资源,没有全部遵守“缓存为王”、“客户体验至上”的设计原则。
为了重用以前版本缓存的部分资源(JS/CSS/图片等),构建微前端APP时需固定发布的URL路径,只有文件内容Hash发生变化时才使用新的文件名。我们使用Webpack构建React微前端
工程,相关配置项也是在Webpack配置脚本中修改。
文本演示如何尽可能地重用以前APP版本的资源文件。
继续阅读→
渐进式Web应用(PWA)的好处:添加到主屏幕、缓存加速启动、离线运行、渐进式更新、通知等功能,不支持PWA的浏览器可以像以前一样使用网页。PWA上线时需要开启HTTPS协议,本地调试可以是HTTP协议。
在构建React微前端之后,相关资源都是动态选择,造成PWA安装时不好确定缓存哪些内容。本文例程使用postMessage()
的方式在主线程与Service Worker线程之间传递数据,让Service Worker线程取得微前端元信息。
给React微前端Demo网站添加PWA功能的操作步骤如下:
1. 添加 PWA manifest
在网站的根目录中添加文件rmf-pwa.webmanifest
,内容如下:
{
"short_name": "Micro Frontends",
"name": "React Micro Frontends Demo",
"icons": [
{
"src": "favicon.ico",
"sizes": "64x64 32x32 24x24 16x16",
"type": "image/x-icon"
},
{
"src": "logo192.png",
"type": "image/png",
"sizes": "192x192"
},
{
"src": "logo512.png",
"type": "image/png",
"sizes": "512x512"
}
],
"start_url": "/",
"display": "standalone",
"theme_color": "#000000",
"background_color": "#ffffff"
}
在网站配置文件site_config.yaml
的htmlBegin
添加:
<link rel="manifest" href="/rmf-pwa.webmanifest"/>
有了这份清单,Chrome浏览器就可以识别我们的网站为PWA,就能安装并添加到主屏幕或桌面。
继续阅读→
传统单页面应用(SPA)是整体一块部署上线,服务器返回不同的SPA版本即可。而微前端是要求每小块APP都可以独立部署上线,同时又提供SPA般的体验。为了满足微前端+SPA
的需求,服务器需要有动态返回每小块APP对应版本的能力。只使用Nginx部署前端资源,是无法达到这个目标。
先看看我们如何设计react-micro-frontend-server-go来满足Demo网站的微前端服务诉求,再探讨一下满足7x24小时微前端的运维平台应该有哪些特点。
本地部署样例,见: https://github.com/kinsprite/react-micro-frontend-server-go/releases/tag/v2.3.0
继续阅读→
大系统拆分成微前端之后,为了提升用户体验,都是按需延时加载相关的CSS/JS。微前端框架react-micro-frontend-framework的职责:
- 提供微前端APP注册接口。有了注册接口才能让框架反向找到微前端APP的React组件。
- 作为整个前端的底座,负责启动React框架、渲染root节点,提供按需渲染某个微前端APP的接口——React中以组件的方式。
- 找到相关微前端的资源位置,按照依赖次序加载CSS/JS。
- 提供多个微前端之间的通信机制——全局Redux Store。
- 提供前端公共库服务——符号导出。
选择React做微前端框架的其中一个原因是:React Router支持动态路由,都是在渲染每层路由组件时判断加载什么内容。而别的路由框架就不是这个样子,有的是静态配置路由,如果它支持Middleware或者Hook机制,还能玩微前端,否则就得重新开发一个路由框架。所以,统一技术栈选择React
+ React Router
,让微前端更加容易落地。
继续阅读→
工程化的内容很多,但是本文只关注与微前端构建相关的内容:统一构建脚本,Webpack按规则导入/导出JS模块符号,生成元信息(入口文件路径、微前端定义信息、GitRevision等)。
虽然Create React App
可以构建SPA,但是满足不了我们微前端的构建需求。同时,Create React App没有提供可回调的方式让我们扩展,于是只能新建构建脚本:react-micro-frontend-scripts。该项目脚本内容大部分来源于Create React App,目前只支持TypeScript + ESLint + PostCSS
。在实际项目中,可以调用该项目脚本,使用函数回调的方式定制自己的内容。在几个微前端App样例中,也是这种方式使用,有的已添加自身的定制参数。
继续阅读→
在前端领域,用户体验放到第一位。在复杂业务操作的前端项目中,SPA的体验要比多页面或iframe嵌套的效果好很多。我们不能为了代码解耦、浏览器中无冲突而放弃SPA。
在以前的项目中,我们已经使用npm
发包的方式将代码分割到多个仓库。在集成前端应用时,再使用npm
和Webpack
工具构建成一个SPA。但仍有一个明显的缺点:每次底层组件更新时,上层SPA都需要重新集成打包、部署。同时,底层组件个数不少又经常更新,上层SPA频繁地集成与部署,让人很反感。
参照后端微服务,微前端(或称为前端微服务)也应该有以下特点:独立开发、独立部署、灰度发布。选择Micro frontends + SPA
是最佳的DevOps与体验方案。经过几天的奋战,已经实现了一个基于React框架的微前端Demo,见: https://micro.qinzhiqiang.cn 。
继续阅读→