浅析微前端基础原理

一、什么是微前端

为了解决庞大的一整块后端服务带来的变更与扩展方面的限制，出现的微服务架构：

微服务是面向服务架构（SOA）的一种变体，把应用程序设计成一系列松耦合的细粒度服务，并通过轻量级的通信协议组织起来。
具体地，将应用构建成一组小型服务。这些服务都能够独立部署、独立扩展，每个服务都具有稳固的模块边界，甚至允许使用不同的编程语言来编写不同服务，也可以由不同的团队来管理。

然而，越来越重的前端工程也面临同样的问题，自然地想到了将微服务思想应用（照搬）到前端，于是有了微前端（micro-frontends）的概念：

即，一种由独立交付的多个前端应用组成整体的架构风格。具体的，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的小块，而在用户看来仍然是内聚的单个产品。

二、微前端的价值

微前端架构具备以下几个核心价值：
● 技术栈无关：主框架不限制接入应用的技术栈，子应用具备完全自主权。
● 独立开发、独立部署：子应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新。
● 独立运行时： 每个子应用之间状态隔离，运行时状态不共享

微前端架构主要在于解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用（Frontend Monolith）后，随之而来的应用不可维护的问题。

三、最早的微前端

single-spa

single-spa 是一个将多个单页面应用聚合为一个整体应用的 JavaScript 微前端框架。 使用 single-spa 进行前端架构设计可以带来很多好处，例如:
● 在同一页面上使用多个前端框架而不用刷新页面 (React, Vue, Angular, Ember… )
● 独立部署每一个单页面应用
● 新功能使用新框架，旧的单页应用不用重写可以共存
● 改善初始加载时间，迟加载代码

它一开始的定位其实是想在一个页面或一个项目使用多个前端框架，后续才被发展为解决“巨石”应用拆分的问题，也就大家推崇的开发模式，应用的功能实现与技术栈无关，独立开发，独立部署。

我们先来看看它的两种应用渲染方式，基于路由控制的应用渲染和不受路由控制的应用渲染，这两种方式奠定后续的微前端发展的基础。

1.基于路由控制的应用渲染

import { registerApplication, start } from 'single-spa';

singleSpa.registerApplication(
  appName, // 应用名称
  applicationOrLoadingFn, // 应用或者应用的加载函数
  activityFn, // 激活应用的函数
);

import { registerApplication, start } from 'single-spa';

singleSpa.registerApplication(
  'optimus',
  () => System.import('https://xxxx.cdn.com/flabfe/optimus/0.8.26/index.js'),
  location => location.pathname.startsWith('/optimus'),
);

基于路由控制的应用渲染，依赖了下面三部分的实现：

a.路由控制

在 single-spa 里面，它会监听 hashchange 和 popstate 事件，如果有变化的话，执行一遍所有应用的激活函数&