> 作者：郭凌波
> [恒生LIGHT云社区](https://developer.hs.net/thread/1020 "恒生LIGHT云社区")

### 一、什么是微前端？

“微前端”一词最早于2016年底在《ThoughtWorks Technology Radar》中提出，它将微服务的概念扩展到前端世界，目的是构建一个在微服务架构上功能丰富且强大的前端应用。

大型组织的组织结构、软件架构在不断地发生变化。移动优先、App中台、中台战略等，各种口号在不断提出和演进。同时业务也在不断地发展，而现有 Web
应用不能很好的拓展和部署，随着时间的推移，各个项目变得越来越臃肿，web 应用变得越来越难以维护。

微前端将微服务的理念应用于浏览器端，让Web应用由单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、开发和部署。

### 二、实施微前端的六种方式：

#### 1 路由分发式

路由分发式微前端，即通过路由将不同的业务分发到不同独立前端应用上。其通常可以通过反向代理（Nginx/HSIAR）来实现，配合使用应用框架自带的路由管理。

就当前而言，通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端”方案。但是这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。

系统整体结构如图：

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/v6lytx8mHzvvKHuwV8pe549mnG0balFVCIS77kVp_thumb.png "1320")

#### 2 iFrame前端容器化

iFrame 作为一个古老而普通的技术，但却一直很管用。采用 `<iframe>`标签将另一个Web页嵌入到当前页面中来，使得多web应用能在一个web中打开。

其可以创建一个全新独立的宿主环境，使不同的前端应用之间可以相互独立运行，但会抛弃网站对SEO的支持、失去页面之前交互的能力。

在很多业务场景下，难免会遇到一些难以解决的问题，那么可以使用iframe 来作为保底的手段。

#### 3 前端微服务化

前端微服务化，是微服务架构在前端的实施。每个前端应用技术栈、开发、部署、构建都是完全独立自主运行的，最后通过模块化的方式组合成一个完整的应用。

采用这种方式意味着，一个页面上可以同时存在两个以上的前端应用在运行。

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/nu5bgSL0uUGhsOCu07Q6npMkv3FV4AGkY5AS8NLA_thumb.png "1321")

目前主流的框架有 [Single-SPA](https://single-spa.js.org/)、[qiankun](https://qiankun.umijs.org/)、[Mooa](https://github.com/phodal/mooa)，后两者都是基于 Single-SPA 的封装。

#### 4 微应用

微应用化是指在开发时应用都是以单一、微小应用的形式存在的，而在运行时，则是通过构建系统合并这些应用，并组合成一个新的应用。

微应用化大都是以软件工程的方式来完成前端应用的聚合，因此又可以称之为组合式集成。微应用化只能使用唯一的一种前端框架。

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/5Joj0nnTKLKgE6p78WvC7yxiHeKM4ECrRJSGT8U7_thumb.png "1322")

#### 5 微件化

微件化（Widget）是一段可以直接嵌入应用上运行的代码，它由开发人员预先编译好，在加载时不需要再做任何修改或编译。微前端下的微件化是指，每个业务团第编写自己的业务代码，并将编译好的代码部署到指定的服务器上，运行时只需要加载指定的代码即可。

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/tnoXa92oJ2hNwGIrTpg0nSmjA58AeTtaq223sGq4_thumb.png "1323")

#### 6 Web Components

Web Components 是一套不同的技术，允许开发者创建可重用的定制元素（它们的功能封装在代码之外）并且在您 Web 应用中使用它们。

在真正的项目上使用 Web Components 技术，离现在还有一些距离，结合 Web
Components 来构建前端应用，是一种面向未来演进的架构。或者说在未来可以采用这种方式来构建应用。

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/dROduIyCmB79kBGKd27bAXjRznNvsANnbQ3NEcyv_thumb.png "1324")

微前端几种方式对比

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/dWMJaFU6sTCYy8mWZ8XXUlrcsnzaV6R3waPdCmNx_thumb.png "1325")

### 三、真实的业务场景

在真实的业务场景中，往往是上面提到六种方式中的几种的结合使用，或者是某种方式的变种

假设现有三个内部系统，下面称之为 old-a、old-b 和 C，其中，old-a 和 old-b 是老旧的前后端未分离项目，C 为前后端分离的 SPA 应用（React+HUI），三个系统的架构图大致如下：

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/YRvT2sPGVKRoU0EVNohNAtdKxPhXcQPUBanJN37v_thumb.png "1326")

可以看到，old-a 运行在一台服务器 1 上，old-b
运行在服务器 2 上，C 系统的前端资源在服务器 2 上，并且 C 没有自己的域名。

三个系统均在后端同学维护和开发，他们的需求如下：

1、统一的域名

2、统一的界面和交互

3、系统需要方便拓展

考虑开发同学的需求和开发成本、维护成本、未来的可拓展性，系统改造关键点如下：

1、申请统一的域名（暂且称之为 crm.mi.com）

2、将 old-a 和old-b 两个老旧的系统样式调整，像系统 C 靠拢

3、三个系统使用统一的菜单和权限

4、三个系统使用统一的 SSO

5、C 系统和正在开发的N个系统使用CI/CD解决打包和手动复制的问题

对于上面几种方式，在具体的实施使用了路由分发、iFrame、应用微服务化、微应用化的融合方式。或者说是某种方案的变种，因为改造之后同时具备了这几种方案的特点。

对于 C 系统和正在开发的N个系统使用
single-spa 做改造，对于老旧的系统 old-a 和
old-b 使用iFrame接入。改造后如下图：![1.png](https://developer.hs.net/storage/attachments/2021/06/04/RLH292r00wFxtnZLs8n4pqJr4hHQKieN7ku38L9S_thumb.png "1327")

此时，两个老系统分别部署在各自的服务器，C和未来的多个应用部署在同一台服务器。然后在 Nginx 层为老系统分配了两个路由，分别将请求打到各自的服务器，根路由打到C和XX应用的服务器。

使用 React 框架的C和XX应用基于single-spa改造后，那么老系统iFrame 如何接入？

在配置菜单时，老系统路由会被带上标识，统一交给其中一个应用以iFrame 的方式处理：

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/mVrzMovbyGZDzt1j8uFff4FYmnfF5Sdp4LCTfZbo_thumb.png "1328")

改造后微前端架构图：

![1.png](https://developer.hs.net/storage/attachments/2021/06/04/JTMWuTB9UMEt8wFPiZMg4r9xzWZM1nhZJXPJ8QPS_thumb.png "1329")

### 四、总结

微前端不是一个框架或者工具，而是一套架构体系。这套体系除了微前端的基础设施外还需要具备微前端配置中心（版本管理、发布策略、动态构建、中心化管理）、微前端观察工具（应用状态可见、可控）等。

整个体系的搭建将是一个庞大的工程，目前大部分团队是在使用微前端的模式和思想来解决现有系统中的痛点。就像我们的HUI前端框架，经历HUI1时的微应用模式到现在HUI2的微件化模式，结合恒生统一权限管控体系操作员中心和恒生统一网关服务HSIAR，在我们统一运维监控平台天鉴管理下形成了一套完整的微前端方案，减少了业务部门和客户自研的开发工作。

ITPub博客

网页上的微服务—微前端架构实践

最新文章