软件技术学习笔记

最近一个多月都在忙于项目，没有时间记录新的知识。我们起了一个全新的前端项目，技术选型是React + SSR + Dva。要求的起点也比较高：用户导航首屏SSR，其它时候CSR；代码要求SSR与CSR复用；所有的请求经过Node层；页面显示、接口请求均要求小于1秒。

为了容易定位调用链路的性能点，我们加入了Jaeger Open Tracing，这就涉及到链路追踪上下文的传递。

随着业务的发展，单页面应用(SPA)开发的前端系统也越来越复杂，这时需要多个团队并行开发。为了提高生产效率，每个团队需要能够独立开发、部署与维护，于是引入了与后端微服务相似的“微”架构：微前端与SSR微服务。即使一个团队，为了新特性不影响其它部分、能够更快速的上线，也引入了“微”架构。无逻辑的前端静态资源服务，就不在讨论之列。

本文主要探讨React与Vue的微前端 + SSR微服务。

单页面应用(SPA)在处理大数据与强交互的方面有优势，但是其缺点是首屏加载比较慢、很难进行搜索引擎优化(SEO)。在工具软件上，选择SPA是正确的。但是，以静态内容展现为主的网站，如果选择SPA，给用户的体验不好。前端使用React框架时，可以选择服务端渲染(SSR)的方式解决该问题。

大部分网站，即使是以静态内容展现为主的网站，其中也包含一部分动态内容与交互。本文就演示：使用React服务端渲染的同时，也在前端动态渲染一些组件（为了让只搞过SPA的同学更容易理解，暂时称之为“SPA片段”），目的是完成动静分离、页面骨架快速显示。同时，“SPA片段”这种方法，可以用来逐渐替换“祖传”的老代码到React组件。导出静态路由之后，还可以使用SSR来生成页面缓存或静态页面。

在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般的开发体验。

本文主要从两个样例中讲解：

1. react-micro-frontend-app-example，只依赖框架引入的公共库，使用Redux，也使用子APP做子路由。讲解原有APP如何搬迁到微前端。
2. react-micro-frontend-app-example-echarts，相比app-example，还引入ECharts。讲解如何把ECharts也当作为一个微前端。当然也可以把ECharts包含在自身内部，但是与别的微前端APP就无法共用一份ECharts JS代码，用户浪费加载时间。

渐进式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的职责：

1. 提供微前端APP注册接口。有了注册接口才能让框架反向找到微前端APP的React组件。
2. 作为整个前端的底座，负责启动React框架、渲染root节点，提供按需渲染某个微前端APP的接口——React中以组件的方式。
3. 找到相关微前端的资源位置，按照依赖次序加载CSS/JS。
4. 提供多个微前端之间的通信机制——全局Redux Store。
5. 提供前端公共库服务——符号导出。

选择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 。