关于前端:美业微前端的落地

2020 年 4 月，有赞美业的前端团队历经 7 个月工夫，实现了美业 PC 架构从单体 SPA 到微前端架构的设计、迁徙工作。PPT 在去年 6 月份就有了，当初再整顿一下造成文章分享给大家。

目录

• Part 01“大话”微前端

  • 微前端是什么
  • 背景
  • 指标
  • 达成价值
  • 毛病

• Part 02 架构与工程

  • 微前端计划有哪些
  • 架构设计选型留神点
  • 需要剖析
  • 设计准则
  • 利用架构图
  • 零碎拆分
  • 时序图
  • 前端流程图

• Part 03 关键技术

  • 关键技术一览
  • 架构外围
  • 注册核心
  • 代码复用
  • 子利用

• Part 04 我的项目施行

  • 立项前的心路
  • 参考微前端材料
  • 进行 PC 架构优化打算
  • 危险
  • 迭代立项
  • 停顿
  • 后续打算

Part 01“大话”微前端

把这个事件的前因后果讲清楚

微前端是什么

想要答复这个问题间接给一个定义其实没那么难，然而没接触过的同学未必了解。所以须要先介绍一下背景，再解释会更容易明确。

这张图，展现了软件开发前端后分工的三个期间：

1. 单体利用：在软件开发初期和一些小型的 Web 网站架构中，前端后端数据库人员存在同一个团队，大家的代码资产也在同一个物理空间，随着我的项目的倒退，咱们的代码资产倒退到肯定水平就被变成了巨石。
2. 前后端拆散：前端和后端团队拆分，在软件架构上也有了拆散，彼此依附约定去合作，大家的生产资料开始有了物理上的隔离。
3. 微服务化：后端团队依照理论业务进行了垂直畛域的拆分繁多后端系统的复杂度被失去分治，后端服务之间依附近程调用去交互。这个时候前端须要去调用后端服务时候，就须要退出一层 API 网关或者 BFF 来进行接入。

当初很多互联网公司的研发团队的工作模式更凑近这种，把整个产品拆分成多个阿米巴模式的业务小组。
在这种研发流程和组织模式下，后端的架构曾经通过微服务化造成了拆分可调整的状态，前端如果还处于单体利用模式，不谈其它，前端的架构曾经给合作带来瓶颈。
另外 Web 3.0 时代降临，前端利用越来越重，随着业务的倒退迭代和我的项目代码的沉积，前端利用在勤奋的生产下演变成了一个硕大无朋。人关注复杂度的能力无限，维度大略维持在 5~8 左右。单体利用聚合的生产资料太多，带来复杂性的维度太多，也容易引发更多的问题。简而言之，传统的 SPA 曾经没方法很好的应答疾速业务倒退给技术底层的考验。
咱们的产品和前端我的项目也同样遇到了这个问题。如何解决这个问题呢？
其实后端的倒退曾经给出了可借鉴的计划，在理念上参照微服务 / 微内核的微前端架构应时而生。
想要解决这个问题，在吸引力法令的指引下咱们遇到了微前端架构，也验证了它确实帮忙咱们解决了这个难题。

当初给出咱们的微前端这样一种定义：

微前端是一种相似于微内核的架构，它将微服务的理念利用于浏览器端，行将 Web 利用由单体利用转变为多个小型前端利用聚合为一的利用。多个前端利用还能够独立运行、独立开发、独立部署。

背景

1. 美业 PC 作为一个单体利用经验 4 年迭代开发，代码量和依赖宏大，纯业务代码经统计有 60 多万行
2. 工程方面，构建部署的速度极慢，开发人员本地调试体验差效率低，一次简略的构建 + 公布须要 7 +8=15 分钟以上
3. 代码方面，业务代码耦合重大，影响范畴难以收敛，屡次带来了“蝴蝶效应”式的的线上 Bug 和故障
4. 技术方面，通用依赖降级带来的改变和回归老本微小，波及例如 Zent 组件、中台组件等依赖包相干的日常需要和技术升级简直不可推动
5. 测试方面，单利用应答多人和多我的项目公布，单利用公布总和高且十分频繁，每次的集成测试都有抵触解决和新问题裸露的危险
6. 组织方面，单利用也无奈很好应答业务小组的开发组织模式，边界职责不清晰且模块开发易烦扰
7. 架构方面，前端无奈和后端造成对应的畛域利用开发模式，不利于业务的下沉，也无奈反对前端能力的服务化和对技术栈的演进依赖

总体来说，臃肿的单体利用模式，给开发人员带来了无法忍受的难处，给疾速撑持业务带来了很大的瓶颈，也没有信念应答接下来的业务的持续拓展。对美业 PC 进行架构调整就是十分迫切和有价值的事件了

指标

1. 业务架构层面，围绕美业 PC 的业务状态、我的项目架构以及发展趋势，将大型多团队协同开发的前端利用视为多个独立团队所产出性能的组合。
2. 技术架构层面，解耦大型前端利用，拆分成基座利用、微前端内核、注册核心、若干独立开发部署的子系统，造成分布式体系的中心化治理零碎。
3. 软件工程方面，保障渐进式迁徙和革新，保障新老利用的失常运行。

达成价值

业务价值

• 实现了前端为维度的产品的原子化，如果整合新业务，子利用能够疾速被其余业务集成
• 以业务畛域划分，让组织架构调整下的我的项目多人合作更职责清晰和成本低，且适应组织架构调整
• 减慢零碎的熵增，铺平业务倒退路线。

工程价值

• 实现了业务子利用独立开发和部署，构建部署的期待耗时从 15 分钟降到了 1 分半
• 反对渐进式架构，零碎子利用之间依赖无关，能够单个降级依赖，技术栈容许不统一，技术迭代的空间更大
• 前端能力可能服务化输入
• 架构灵便，新的业务能够在不减少现存业务开发人员认知累赘的前提下，自在成长有限拓展

毛病

一个架构的设计其实对整体的一个衡量和取舍，除了价值和劣势之外，也带来一些须要去思考的影响。

Part 02 架构与工程

从全局视角把握成绩

微前端计划有哪些

1. 应用 HTTP 服务器反向代理到多个利用
2. 在不同的框架之上设计通信、加载机制
3. 通过组合多个独立利用、组件来构建一个单体利用
4. 应用 iFrame 及自定义消息传递机制
5. 应用纯 Web Components 构建利用
6. 联合 Web Components 构建

每种计划都有本人的优劣，咱们兄弟团队采纳了最原始的网关转发配置相似 Nginx 配置反向代理，从接入层的角度来将零碎组合，然而每一次新增和调整都须要在运维层面去配置。

而 iframe 嵌套是最简略和最疾速的计划，然而 iframe 的弊病也是无奈防止的。
Web Components 的计划则须要大量的革新老本。
组合式利用路由散发计划革新老本中等且满足大部分需要，也不影响个前端子利用的体验，是过后比拟先进的一种计划。

架构设计选型留神点

• 如何升高零碎的复杂度？
• 如何保障系统的可维护性？
• 如何保障系统的可拓展性？
• 如何保障系统的可用性？
• 如何保障系统的性能？

综合评估之后咱们选用了组合式利用路由散发计划，然而依然有架构整体蓝图和工程实现须要去设计。

需要剖析

1. 子利用独立运行 / 部署
2. 核心管制加载（服务发现 / 服务注册）
3. 子利用专用局部复用
4. 标准子利用的接入
5. 基座利用路由和容器治理
6. 建设配套基础设施

设计准则

1. 反对渐进式迁徙，平滑过渡
2. 拆分准则对立，尝试畛域划分来解耦

利用架构图

零碎拆分

这里拆分须要阐明三个点：

• 独立部署（服务注册）：上传利用资源包（打包生成文件）到 Apollo 配置平台，是一个点睛之笔
• 服务化和 npm 包插件化的区别是不须要通过父利用构建来集成，彼此依赖无关，公布独立，更加灵便 / 牢靠
• 同时 Apollo 承载了注册核心的性能，能够省去子利用的 web 服务器的这一层，简化了架构

时序图

前端流程图

## Part 03 关键技术

落地中有哪些值得一提的技术细节

关键技术一览

咱们按我的项目拆分来结构化讲述，有架构外围、注册核心、子利用、代码复用四篇。
其中蕴含了这些技术点：

1. Apollo
2. Apollo Cli
3. Version Manage
4. Sandbox
5. RouterMonitor
6. MicroPageLoader
7. Shared Menu
8. Shared Common

[架构外围]音讯通信

[架构外围]路由散发

当浏览器的门路变动后，最先承受到这个变动的是基座的 router，全副的路由变动由基座路由 RouterMonitor 主持，因为它会去劫持所有引起 url 变动的操作，从而获取路由切换的机会。如果是 apps/xxx/# 之前的变动，只会拦挡阻止浏览器再次发动网页申请不会下发，没有波及 #之前的 url 变动就下发到子利用，让子利用路由接管。

[架构外围]利用隔离

次要分为 JavaScript 执行环境隔离 和 CSS 款式隔离。

JavaScript 执行环境隔离：每当子利用的 JavaScript 被加载并运行时，它的外围实际上是对全局对象 window 的批改以及一些全局事件的的扭转，例如 JQuery 这个 js 运行之后，会在 window 上挂载一个 window.$ 对象，对于其余库 React、Vue 也不例外。为此，须要在加载和卸载每个子利用的同时，尽可能打消这种抵触和影响，最广泛的做法是采纳沙箱机制 SandBox。
沙箱机制的外围是让部分的 JavaScript 运行时，对外部对象的拜访和批改处在可控的范畴内，即无论外部怎么运行，都不会影响内部的对象。通常在 Node.js 端能够采纳 vm 模块，而对于浏览器，则须要联合 with 关键字和 window.Proxy 对象来实现浏览器端的沙箱。

CSS 款式隔离：当基座利用、子利用同屏渲染时，就可能会有一些款式互相净化，如果要彻底隔离 CSS 净化，能够采纳 CSS Module 或者命名空间的形式，给每个子利用模块以特定前缀，即可保障不会互相烦扰，能够采纳 webpack 的 postcss 插件，在打包时增加特定的前缀。
对于子利用与子利用之间的 CSS 隔离就非常简单，在每次利用加载是，就将改利用所有的 link 和 style 内容进行标记。在利用卸载后，同步卸载页面上对应的 link 和 style 即可。

[架构外围]外围流程图

咱们把路由散发、利用隔离、利用加载、通用业务逻辑收纳到到了微前端内核的二方包中，用作各个业务线复用，在外部达成对立约定。

[注册核心]Apollo

其实大部分公司在落地微前端计划的时候，并有没所谓的注册核心的概念。为什么咱们的微前端也会有注册核心这个概念和理论存在呢？选型的思考点也次要来自咱们后端的微服务架构。

为什么抉择引入注册核心减少整体架构的复杂度？

两个起因：

1. 咱们的子利用之间尽管不须要通信，然而也存在基座利用须要所有子利用的资源信息的状况，用来保护路由对应子利用资源地址的映射。大部分公司落地时候，都把子利用的地址信息硬编码到了基座。这样子利用增删改时候，就须要去重新部署基座利用，这违反了咱们解耦的初衷。注册核心把这份映射文件从基座剥离进去了，让架构具备了更好的解耦和柔性。
2. 要晓得咱们的子利用的产物入口是 hash 化的上传到 CDN 的 JS 文件，同时防止子利用公布也须要公布基座利用。有两个解决方案，一种是减少子利用的 Web 服务器，能够通过固定的 HTTP 服务地址拿到最新的动态资源文件。一种就是减少注册核心，子利用公布就是推送新的 JS 地址给到 注册核心，子利用的架构就能够更薄。

须要一个注册核心的话，咱们也有两种计划，一种是本人自研一个专门服务于本人的微前端，尽管能够更加贴合和聚焦，然而作为注册核心，高可用的技术底层要求下的熔断降级等机制必不可少，这些研发难度大老本也高。还有一种是间接利用成熟的提供注册核心能力的开源我的项目或者依赖公司的曾经存在的技术设施组件。

最初咱们确定在选用公司外部的根底技术设施的 Apollo 我的项目，劣势有这么两方面。

1. 我的项目自身开源，成熟水平很高，在多环境、即时性、版本治理、灰度公布、权限治理、凋谢 API、反对端、简略部署等功能性方面做得很不错，是一个值得信赖的高可用的配置核心。
2. 公司外部针对做了私有化定制和部署，更加适配业务，并且在 Java 和 Node 场景下都有稳固和应用，有保护人员值班。

子利用的打包构建体验

1. 定位：一个子利用构建完是一个带 hash 的动态资源，期待被基座加载。

2. 怎么做：

   1. 打包一个单入口的动态资源, 同时裸露全局办法给基座
   2. 每次构建生成带 hash 的入口 app.js
   3. 获取打包产出生成上传配置
   4. 依据环境参数上传到 apollo

3. 体验如何

   十分轻量，毋庸公布，构建即可

子利用如何推送打包实现的 cdn 地址给 Apollo

1. 获取打包实现的产物的 JSON，获取入口文件 Hash，和以后我的项目的根底信息。
2. 基于上述配置生成内容，而后调用 Apollo 平台凋谢的 API 上传到 Apollo。

如何进行多环境公布及服务链合作

1. 环境次要分为测试、预发、生产。
2. 打包实现后，依据微前端构建平台指定环境。
3. 推送配置时候，指定 Apollo 对应的环境集群就好了。
4. 基座利用在运行时候，会依据环境与 Apollo 交互对应环境集群的注册表信息。

[代码复用]子利用之间如何复用公共库

1、增加 shared 为近程仓库

git remote add shared http://gitlab.xxx-inc.com/xxx/xxx-pc-shared.git

2、将 shared 增加到 report 我的项目中

git subtree add --prefix=src/shared shared master

3、拉取 shared 代码

git subtree pull --prefix=src/shared shared master

4、提交本地改变到 shared

git subtree push --prefix=src/shared shared hotfix/xxx

注：如果是新创建子利用 1-2-3-4；如果是去批改一个子援用 1-3-4

[代码复用]应用 shared 须要留神什么

1. 批改了 shared 的组件，须要 push 改变到 shared 仓库
2. 如果一个 shared 中的组件被某个子利用频繁更新，能够思考将这个组件从 shared 中移除，内化到子利用中

[子利用]子利用如何接入

首先，咱们须要明确咱们对子利用的定位：

一个子利用构建完后是一个带 hash 的动态资源，期待被基座加载，而后在核心渲染视图，同时领有本人的子路由

第一步，依据咱们的模板新建一个仓库，并置入对应子利用的代码

第二步，接入 shared 以及批改一系列配置文件

第三步，进行开发所须要的转发配置

第四部，运行，并尝试打包部署

[子利用]子利用能独立调式吗？怎么基座利用联调？

1. 开启基座，端口和资源映射到本地再调式
2. Zan-proxy
3. 本地 Nginx 转发

[子利用]子利用开发体验

Part 04 我的项目施行

一个问题从呈现到被解决走过的波折路线

1. 立项前的心路

0. 看过微前端这个概念，感觉花里胡哨，捉弄名词，强行造出新概念。
1. 对我的项目的目前呈现的问题有个大略感知（是个问题）
2. 从业务登程利用现有常识背景思考解决伎俩（简直无解）
3. 回忆理解过微前端架构的概念和场景，感触到两者有符合（人生若只如初见）
4. 参考行业的解决方案印证，决定用微前端来脱掉收缩的包袱（原来是该拆了）
5. 首先把我的项目在前端架构优化理了一遍，输入架构图（我的项目整体上探路）
6. 接下来梳理各个业务模块的依赖，看下有哪些（子利用剖析）
7. 大量和不同人的聊天、理解、探讨，获取撑持技术选型的信息（外界专家）
8. 确定微前端架构在美业下的落地根本模型（架构根本）
9. 进行概要技术设计（具象化）
10. 明确迭代范畴
11. 技术评审
12. 拉帮结伙 / 分工
13. kickoff
14. 然而故事才刚刚开始…

2. 参考微前端材料

3. 进行 PC 架构优化打算

4. 危险

预知

1. 开发人员投入度有余
2. 技术上的不确定性来更多工期危险
3. 细节的技术实现须要打磨耗时超出预期
4. 局部性能难以实现

意外

1. 对我的项目架构了解不精确
2. 工作拆分和边界了解不到位
3. 测试人员投入有余
4. 合作摩擦

5. 迭代立项

6. 停顿

1. PC 微前端基座利用已上线
2. PC 数据拆分成子利用已上线
3. 协调中台前端抽取了美业微前端内核
4. 通用工具办法和枚举的可视化
5. 搭配 Apollo 平台造成了前端子利用资源的注册核心
6. 子利用接入文档输入
7. 若干前端技术体系的优化

7. 后续打算