关于javascript:微前端自检清单

最近在做公司微前端，整顿了一份微前端搭建清单，如果你正在思考是否要做微前端，无妨做个参考。

• 需要剖析
• 技术计划剖析
• 拆分计划剖析
• 部署流程剖析

需要剖析

第一步，咱们须要进行需要剖析，以便真正分明咱们须要解决的问题是什么。

例如：

• 产品要新增一个业务模块
• 产品要批改我的项目款式
• 产品反馈我的项目启动太慢了
• 产品反馈页面跳转刷新很不敌对

前两个需要是典型的业务需要，它的外围在于解决公司的业务问题，对于这一类需要，通常技术难度都不大，开发者只须要依照原型图，编写出对应的页面就能够了。

后两个需要是典型的技术需要，它的外围在于解决技术问题。通常来说，技术需要和用户体验无关，但不会影响我的项目性能，所以个别产品很少会提技术需要，都是由开发同学主导。

目前很多公司都不太器重技术需要，次要是因为和公司业务无关，不能带来实在可见的收益。其实不然，一些技术需要往往能产生微小的老本收益，所以咱们在做技术需要时， 首先须要失去公司的反对 。

为什么抉择微前端

解决一个技术需要，有很多种办法，为什么选微前端？

咱们看过微前端的发展史就会明确，它并不是凭空出现的，而是我的项目在一直倒退过程中造成的，解决我的项目臃肿的技术计划。

一个我的项目在刚成立时，体量很小，但随着我的项目一直做大，可能会呈现以下问题：

• 工程收缩
• 分支凌乱
• 代码抵触
• 打包麻烦
• 保护艰难

对于这些问题，很难找到一个完满的解决方案，于是就诞生了微前端。

有了微前端之后，咱们能将一个大我的项目拆分成多个小我的项目，这样一来，每一个小我的项目就十分好优化了。在优化了所有的小我的项目后，咱们再将这些小我的项目组合起来，就能造成一个完满的大我的项目了。

在理论我的项目中，如果遇到以下问题，能够思考应用微前端：

• 我的项目太大，成为了典型的巨石利用，打包很慢。
• 我的项目开发者太多，多个同学开发同一套代码，经常出现代码抵触、或批改公共组件引发的 Bug。
• 我的项目太老，存在遗留模块，为了兼容它，限度了整个我的项目的倒退。
• 我的项目技术栈不对立，应用了多种不同框架，每一种框架又有多个版本共存的状况。
• 我的项目由多个团队协同开发，一个性能须要等其余团队开发好之后，能力接着开发。
• 我的项目每次公布都是全量公布，即便是上线一个小模块，也可能导致整个我的项目挂掉。
• 我的项目由多个零碎组成，实现一个性能须要一直地跳转多个零碎页。
• 我的项目开发人员流动大，存在一些祖传代码难以保护，个别人都不好改。
• 我的项目须要一些试验田计划，即须要在某些模块做一些新技术尝试、框架降级等。
• …

除此之外，还有很多理论状况没有列举结束，不过没关系，只有咱们明确了微前端的特点，就能判断任何状况。

微前端特点

微前端的外围是解决巨石利用，它都有这些特点：

• 简略、松耦合的代码库

  • 微前端架构偏向于编写和保护更小、更简略、更容易开发的我的项目。
  • 技术栈无关，各我的项目能够应用不同的技术栈。

• 增量降级

  • 反对渐进式重构，先让新旧代码谐和共存，再逐渐转化旧代码，直到整个重构实现。

• 独立部署

  • 每一个子利用都具备独立开发，继续部署，独立运行的能力。

• 团队自治

  • 各子项目之间不存在依赖关系，放弃隔离。
  • 繁多职责，每个子项目只做和本人相干的业务工作。

除此之外，微前端提供了一套新的生态系统。它通过拆分小我的项目，产生了大量的微利用。试想一下，如果大家都将微利用上传到云，那么就会构建一个十分弱小的微利用云生态。咱们在当前做需要时，兴许就是抉择各种适宜的微利用，而后拼接起来，就完事了。

对此放弃期待。

微前端的毛病

当然，微前端也不是万能的，它也存在以下问题：

• 拆分的粒度越小，便意味着架构变得复杂、保护老本变高。
• 技术栈一旦多样化，便意味着技术栈凌乱。
• 治理版本简单、依赖简单。
• 开发体验不太敌对，开发时可能须要同时启动多个我的项目。

这些问题大多是因为我的项目拆分成多个我的项目之后，引发的沟通合作问题。

技术计划调研

第二步，咱们须要确定具体的微前端实现形式。

实现微前端有很多种形式：

• 路由散发式

  • 通过 http 服务器的反向代理性能，来将申请路由到对应的利用上。
  • 这种形式只是在路由层面看起来是一个我的项目，但实际上只是通过 a 标签连贯了多个我的项目。

• 前端容器化

  • 应用 iframe 作为容器。
  • seo 不敌对。
  • 须要思考同源策略 cookie 治理。
  • 须要自建一套利用治理、利用通信机制。
  • 弹窗不敌对。
  • 浏览器后退按钮不敌对。

• 前端微服务化

  • 在不同的框架之上设计通信、加载机制，以在一个页面内加载对应的利用。
  • 罕用的框架：qiankun，single-spa 都是这样做的。
  • 最罕用的计划，适宜于疾速上手。

• 微件化

  • 打包出能够间接嵌入在页面上运行的代码，可能是一段 js，应用时间接引入即可。
  • 须要实现一套微件管理机制，老本太高。

• 微利用化

  • 通过软件工程的形式，在部署构建环境中通过 webpack 打包，组合多个独立利用成一个单体利用。
  • 须要将多个我的项目打包成一个，所以技术栈须要放弃对立。

• 利用组件化

  • 将子项目都打包成 webComponent，在主我的项目中组合。
  • 须要思考 webComponent 兼容性。

下图是各种计划的优缺点：

这么多计划，各有利弊，咱们应该如何抉择呢？

• 如果只是想简略疾速的做拆散，不思考 seo，能够用 iframe。
• 如果想做拆散的同时，保持良好的单页体验，能够思考 single-spa、qiankun 框架。
• 如果公司有很强的技术能力，再思考自研或其余计划。

有了技术计划之后，微前端这条路就能够走通了，除此之外，还需思考过渡计划。

过渡计划

过渡计划指的是如何让微前端平滑上线。试想一下，如果在微前端革新时，我的项目来了新需要，这时应该怎么办？

对于这个问题，倡议在做微前端革新时，最好疾速上线：

1. 首先将整个原我的项目当成一个大的子项目，进行微前端革新。

2. 主我的项目疾速搭建好路由、子利用治理，而后立刻上线。

   1. 路由治理在解决子项目时，如果是原页面，先通过 a 标签跳转，如果是新页面，则应用前端 router 管制跳转。
   2. 后续逐步拆分子我的项目，如果有新的子项目拆分结束，只须要将 a 标签跳转改为前端 router 管制即可。
3. 做完前两步之后，咱们的架构就曾经变成了微前端架构。

拆分计划调研

第三步，咱们须要想想，咱们要怎么拆分咱们的我的项目呢？

常见的拆分计划如下：

• 依照业务拆分

  • 如：一个电商后盾，包含商品治理、商家治理、物流治理等。
  • 独立出每个业务我的项目，能够让整个我的项目构造清晰。

• 依照权限拆分

  • 如：一个经营后盾，管理员和一般经营看到的页面是不一样的。
  • 独立出不同的权限我的项目，能够突出每个我的项目的应用范畴。

• 依照变更的频率拆分

  • 如：一个我的项目中，蕴含很少改变的祖传我的项目和常常改变的业务我的项目。
  • 独立出变更频繁的我的项目，能够防止频繁更新可能导致整体我的项目挂掉的危险。
  • 独立出很少改变的我的项目，能够让咱们在外围业务上大展拳脚。

• 依照组织构造拆分

  • 如：一个性能简单的我的项目后盾，由多个团队共同开发而成。
  • 独立出不同团队的我的项目，能够防止开发抵触，部署抵触等问题。

• 追随后端微服务拆分

  • 如：后端曾经做了不同模块的微服务划分，前端能够间接依照后端来就行了。
  • 这种形式有利于前后端放弃对立。

到了这里，咱们曾经实现了微前端的拆分，但并不是拆完了就完结了，咱们还思考一些拆分后的问题。

例如：

• 主我的项目和子项目的款式是否须要复用？
• 我的项目权限，是离开还是在对立治理？
• 利用之间如何进行通信？

这些问题往往和业务相干，咱们在革新时自行判断即可。

部署流程查看

最初一步，咱们须要思考部署流程。

当微前端开发实现之后，咱们的我的项目由 1 个变成了 1 + n(子项目) 个，部署形式势必会发生变化。

传统的部署形式如下：

微前端我的项目部署形式如下：

能够看到，我的项目最终的构造曾经齐全不同了，开发，测试，部署的流程也都须要进行变动。

• 开发环境的部署
• 测试环境的部署
• 线上环境的部署

开发环境的部署

开发环境其实不须要部署，通常是前端启动一个 localhost 页面，去调后端的接口进行开发。

须要留神的是：

• 子项目需反对独立启动，而不是在开发时启动所有我的项目，只需启动与业务相干的子项目即可。
• 子项目需反对独立部署，开发实现之后，只须要部署与业务相干的子项目即可。

测试环境的部署

测试环境部署变动挺大的，而且波及到了跨部门沟通，所以应该审慎看待。

以前测试部署流程是：前端只须要提供一个打包文件，测试将文件解压后，放入指定的动态资源目录即可。

微前端之后的部署流程：前端须要提供主我的项目和相干子项目的打包文件，测试须要别离公布多个我的项目，能力进行测试。

这样改变之后，测试的工作质变大了，对于手动部署的测试来说，的确有很大的影响。为了缩小测试的工作量，咱们能够帮助测试来搭建一套自动化部署工具。

很多大厂都有本人外部的云服务平台，就像阿里云的 k8s 控制台一样，测试能够在管制台上抉择须要部署的前端、后端的分支，而后点击一键部署，就搞定了。

上线环境部署

对于线上环境来说，运行的是 1 个主我的项目和 n 个子我的项目，每个我的项目都是独立部署且互相独立的，非常适合容器化部署，即：每一个我的项目都被部署到一个 docker 中，彼此通过主我的项目进行关联。

如图，所有的子项目都交由主项目管理。

如果公司外部做了继续部署，部署就会更加简略。

思考与总结

本文从需要剖析开始，一步一步理清了微前端须要留神的各种问题，以及一些解决方案，心愿能对微前端感兴趣的你有所播种。

其实，微前端没有设想中的那么难，如果是用 qiankun、single-spa 等现成框架，学习老本都非常低，要害是要真正入手去做，只有开了头，前面的问题也就不是什么问题了。

最初，如果你对此有任何想法，欢送留言评论！