关于前端:前端架构微前端系列一

背景

最近我的项目开发中应用了 qiankun 框架去做微前端，我是属于半懂不懂的状态，大略理解过微前端是什么，能够解决什么问题，然而没有并零碎的意识和从 0 实战过。

所以心愿通过几篇文章去重新认识 微前端 这一架构，次要会从几个方面：

• 是什么，以及为什么会呈现
• 实现原理，以及支流框架
• 我的项目实战

<!– more –>

倒退历程

微服务

在说微前端之前，咱们须要先理解一下后端的微服务，因为微前端自身就是汲取微服务理念而产生的，所以咱们先对微服务做一个简略的意识：

2014 年，Martin Fowler 与 James Lewis 独特提出了微服务的概念，定义了微服务是由以繁多应用程序形成的小服务，本人领有本人的过程与轻量化解决，服务依业务功能设计，以全自动的形式部署，与其余服务应用 HTTP API 通信。同时服务会应用最小的规模的集中管理 (例如 Docker) 能力，服务能够用不同的编程语言与数据库等组件实现 —— 维基百科 微服务。

微服务 架构，通常拿来比照的架构是 单体软件 架构，单体软件 存在以下几个问题：

• 所有性能耦合在一起，相互影响，最终难以治理
• 哪怕只批改一行代码，整个软件就要从新构建和部署，老本十分高
• 不可能每个性能独自开发和测试，只能整体开发和测试，导致必须采纳瀑布式开发模型

因而开始呈现将单体软件拆成一个个 性能单元服务 + 通信协定 组成，这种叫 面向服务 (service-oriented architecture，简称 SOA) 架构，也是微服务的雏形。

因而 微服务 架构的等于 面向服务 架构，它有多种实现计划，其中最佳实际是基于 Docker 容器实现的。

微服务的几大个性：

• 敏捷性，可疾速迭代本人的微服务
• 弹性部署，疾速继续集成与部署，服务独立性减少了应用程序应答故障的弹性
• 技术自在，能够自由选择最佳工具来解决他们的具体问题
• 可重复使用的代码，能够将专为某项性能编写的服务能够用作另一项性能的构建块

Ok，微服务理解到这里基本上就有大略的认知，微服务当然不只是这些，还有一些其余技术点，如：服务发现、事件流传等。

微前端

理解完微服务，那么微前端概念是什么开始提出的呢？

微前端 这个名词，第一次被提出还是在 2016 年底，那是在 ThoughtWorks Technology Radar。这个概念将微服务这个被广泛应用于服务端的技术范式扩大到前端畛域。
微前端是一种多个团队通过独立公布性能的形式来独特构建现代化 web 利用的技术手段及办法策略。—— 微前端的残缺介绍

简略的说，微前端架构是从微服务理念扩大而来的，一个实用于前端的微服务架构。

微前端

是什么

从下面倒退历程咱们对 微前端 架构有个简略认知和它的定义，接下来咱们通过不同类型的做比拟去对微前端做更深的认知。

单体巨石 VS 微前端

用单体巨石架构和微前端架构做一个比拟，能更好的了解微前端架构，具体如下图所示：

简略的讲，就是将本来耦合在一起的单体巨石利用依照肯定准则拆分成各种微前端小利用，最简略的拆分计划就是和微服务做一一映射。

组件 VS 微前端

咱们再从另外一个角度的去对待微前端，假如将微前端看做组件，是不是就好了解多了，只不过这个组件有点大，性能比拟齐全，没有对外提供参数配置。

然而从两者的理论利用场景来说，还是有很多不同的中央，具体如下：

• 从利用场景来看，组件是不可运行，被调用的，是利用中一部分，而微前端是残缺可运行的一个利用
• 从技术上来看，组件是基于某个框架实现的，而微前端利用不依赖任何框架，然而微前端架构会依赖某个框架实现

总结

微前端 架构，就是把简单问题简单化，每个 微前端 我的项目都只须要关怀本人的事件。因而 微前端 架构的外围思维如下：

• 技术不可知 ，每个 微前端 都应该抉择本人的技术栈和技术进化路线，而不是和其余团队保持一致，同时架构师应该思考的是 如何高效的提供可复用的 WebComponent 会成为外围问题
• 环境隔离 ， 微前端 架构中每个子项目不共享运行时环境，即是：不依赖共享状态或全局变量，同时也能够通过命名标准（如：前缀）或命名空间，去隔离每个微前端利用
• 原生 API 优先，应用 用于通信的原生浏览器事件机制，而不是本人构建一个 PubSub 零碎
• 独立性 ， 微前端 架构中每个子项目是残缺的，能够独立运行、独立开发、独立部署
• 高可用 ， 微前端 架构是高可用的，即便某个子利用异样也不会影响其余子利用的拜访

以上就是要实现 微前端 架构所须要思考的点，同时也是架构中的外围思维。

毛病

微前端架构在下面形容了很多劣势，然而如果没做好架构设计，它也可能会带来一些问题，因而咱们须要提前理解 微前端架构 可能会带来的缺点：

• 减少运维老本，因为由本来只须要公布一个利用，变成须要公布 N 个利用
• 拆分粒度越小，架构越简单，开发保护老本越高
• 微前端反对不同技术栈，那么也带来了不同技术栈带来技术栈凌乱的危险，同时也进步了开发保护老本
• 微前端架构自身就是将我的项目齐全独立，可能导致局部公共代码无奈通用
• 还有一些其余问题，如：当采纳某类微前端框架减少开发成本等

下面这些问题，在我的项目是否要用微前端架构都须要思考的事件，然而也有一句话能够提供给大家参考。

工程就是衡量的艺术，而微服务（microframeworks）架构给你提供了一个能够衡量的维度。

理解完是什么，接下来就当我的项目中要施行 微前端 架构的时候要怎么做了。

怎么做

在我的项目要施行 微前端 架构，次要有几个工作项：

• 首先，就是须要搞清楚如何将我的项目拆分一个个微前端子项目
• 其次，选型，采纳哪种微前端框架去施行
• 最初，应用渐进式计划去施行，而不是一口气全切换，如果是新我的项目间接采纳微前端架构，那么这里举荐采纳Monorepo 大仓 + 微前端，这里会让极大升高我的项目的治理老本。

如何拆分

微前端架构次要工作就是拆分，那么问题来了，咱们应该根据什么样的规范去拆分呢？咱们大体能够从下几点去思考：

• 第一，拆分条件，我的项目是否适宜微前端架构
• 第二，拆分准则，我的项目拆分时候须要遵循的设计准则
• 第三，拆分办法，我的项目拆分能够根据哪些因素进行拆分

拆分条件

咱们要对我的项目进行微前端架构设计的时候，咱们应该从上面几方面去思考是否适宜：

• 是否有疾速迭代的需要，如果有疾速迭代需要，则示意业务须要疾速响应，那么采纳微前端架构去拆分，不仅反对疾速迭代，还反对业务疾速试错
• 是否有代码提交呈现大量抵触，如果有，则示意代码治理老本较高，微前端架构能够升高我的项目的治理老本
• 是否小性能须要期待大版本的场景，如果有，则示意小性能会影响到大版本的性能，这个时候微前端架构的 独立公布 个性，可随时回滚，危险变小，工夫变短，影响面小，从而升高大版本公布延期危险

从下面几个方面，咱们能够很清晰的判断以后我的项目是否须要做微前端架构调整，只有这个时候，微前端的拆分才是有确定收益的，减少的运维老本才是值得的。

拆分准则

当咱们面对须要拆分微前端的时候，以下几个准则能够作为参考：

• 繁多职责准则，每个微前端只需关怀本人的业务规定，确保职责繁多，防止职责穿插
• 服务自治准则，每个微前端的开发，必须领有开发、测试、运维、部署等整个过程，示意该利用能够独立运行而不须要依赖其余利用
• 继续演进准则，单体架构向微服务架构拆分过程中，无奈做到欲速不达，应逐渐拆分细化，继续演进，防止微服务数量的霎时爆炸性增长
• 服务粒度适中，先粗后细的准则，再依照拆分条件判断粗粒度的微前端是否须要拆分
• 防止循环依赖，循环依赖的状况会导致微前端在迭代公布的时候不晓得优先公布哪个，在拆分的时候须要思考，针对依赖局部进行下沉，拆分成公共模块
• 横向拆分准则，拆分微前端应该依照依赖档次的横向去拆，而不是纵向拆分，因为拆分越深，保护老本越高

拆分办法

以上两个次要针对拆分的假如条件，当真正去拆分操作的时候，咱们该当从这些方面去动手：

• 依照业务畛域，参考畛域模型，将同类业务归为同一个微前端，依照繁多职责准则、性能完整性进行拆分
• 依照组织架构，应尽量避免对组织架构和团队的调整，防止因为性能的从新划分，而减少大量且不必要的团队之间的沟通老本
• 依照技术栈，简略点说 React 的技术栈放一个微前端，Vue 的技术栈放另外一个微前端
• 按需要迭代频率，将迭代频率高的放在一个微前端，频率低放在另外一个微前端

学会了拆分办法，外面的优先级应该有大略排序，业务畛域 > 组织架构 > 技术栈 > 需要迭代频率，我举荐的做法如下：

• 先依照业务畛域去拆分
• 拆分的粒度不够，还要再拆分就依照组织构造再拆分
• 再往下，就是依照技术栈拆分
• 再往下，就是需要迭代频率

微前端框架

理解完如何拆分，那么接下来就是对微前端架构实现的框架进行选型，上面是我从网上收集目前市场支流的几大微前端框架：

• single-spa，将多个单页面利用聚合为一个整体利用的 JavaScript 微前端框架
• qiankun，基于 single-spa，能更简略、无痛构建可用微前端架构的框架
• 无界，基于 iframe，实现路由同步机制的微前端架构框架
• micro-app，借鉴 WebComponent 思维，联合自定义的 ShadowDom，将微前端封装成一个类 WebComponent 组件的微前端框架
• webpack 模块联邦，在 webpack 构建时候加载近程利用而实现的微前端架构计划

以上，就是目前实现微前端架构的支流框架，当然每个框架都本人的优缺点，咱们在选型的时候次要还是通过以下几点去判断是否适宜：

• 对现有我的项目是否须要革新，革新老本多少
• 是否有学习老本，学习老本有多简单
• 将来是否足够的扩展性
• 团队内是否有相熟、精通该选型的人，否则遇到问题，容易入坑
• 我的项目保护的状况，issue 是否有响应，迭代是否在失常进行

到了这里，本篇介绍微前端架构基本上就完结了，尽管很多理论知识，然而咱们能够再次回顾一下，总结一下要点：

• 微前端架构源自微服务架构，两者次要都是为了解决巨石利用的痛点，迭代慢、开发简单
• 微前端架构拆分须要留神几个点：拆分条件、拆分准则和拆分办法
• 微前端架构支流框架：single-spa、qiankun、无界、micro-app、webpack 模块联邦等

当然，我不会只写实践知识点，前面我会针对每个框架的写一篇深刻实战文章，从背地原理，实用场景去一一形容，前端架构之路不好走，心愿大家一起致力加油。

其余概念

畛域驱动设计

要理解一个新的货色，首先弄明确它解决了什么问题？畛域驱动设计次要是为了解决：

• 帮忙团队更好了解业务世界
• 能帮助开发构建良好的设计
• 升高业务逻辑与开发逻辑的耦合，升高复杂性

那么当初，咱们就明确畛域驱动设计是什么了？它是强调业务概念、专业术语的开发设计理念。以下是一些官网解释，前面在前端架构系列文里，会写专门文章做深刻介绍：

畛域驱动设计（Domain-Driven Design，简称 DDD）是一种强调业务概念、专业术语以及准则的开发范式，旨在帮忙用户，团队和软件开发者来解决简单的信息系统和软件。它应用图形模型作为外围，其指标是使开发者可能了解、剖析和把握业务概念，并将这些概念转化为可操作的软件。——【ChatGPT 答复】

畛域模型

畛域模型 ，来自畛域驱动架构(DDD) 中的一个概念，与 开发模型 (解决理论问题所形象进去的概念模型) 设计模型 (形容了所要构建的零碎) 不同的是，畛域模型 是表白与业务相干的事实，它更加关注业务知识，是否显性化、清晰的表白业务语义。

参考资料

模块联邦在微前端架构中的实际
微服务是什么？—— 阮一峰
微前端的残缺介绍
畛域驱动架构（DDD）建模中的模型到底是什么？

更多精彩内容，能够到集体博客拜访：【qborfy 的集体博客】