本文首发于微信公众号：大迁世界, 我的微信：qq449245884，我会第一工夫和你分享前端行业趋势，学习路径等等。
更多开源作品请看 GitHub https://github.com/qq449245884/xiaozhi，蕴含一线大厂面试残缺考点、材料以及我的系列文章。
前言
最近笔者在工作上始终听到后端工程师们在议论 Microservices(微服务) 的架构设计，听到的当下立马去查问才晓得原来 Microservices 这麽潮，身为前端工程师的我当然也心愿前端也能够有这麽新鲜的架构，于是这篇文章就要来跟读者介绍 Micro Frontends（微前端）。
什麽是 Microservices？
在开始进入本篇文章主题之前要先跟读者们介绍什麽是 Microservices。
Microservices 是一种软件架构，专一开发在每一个小型性能或者服务上，最初再利用模组化的形式组合出一个大型的应用程式。
如果读者是前端工程师的话可能会感觉下面的叙述很像是 ES6 module 的架构，开发者只须要专一在每个 module 上的开发，最初再利用 Bundler 打包这些 module 造成一个残缺的页面甚至是应用程序，像下图这样。
不过后端跟前端齐全不一样，后端是藉由一个又一个的 request 来 real time 的执行相干的代码，所以在 Microservices 的架构中，想要让一个又一个的服务能相互沟通，这时候就是要仰赖各个 API 了。
但这时候会有一个很大的问题，如果这三个 Service 对于前端来讲有高度相依性，以上图为例：一个残缺的购物网站必须要先让使用者登入后才能够进行购买商品以及去购物车结帐，这时候在 Client 端就必须要别离打三次 API 并且相互期待才能够实现这整个流程，甚至如果刚好不小心有一个 Service 坏了须要重新启动，这时候可能会先产生一个过渡期的 API 防止 Client 端打到有问题的 Service，可是 Client 端也不可能每次都会去记住这个新产生的 API，所以这势必会造成一个很大问题。
这时候其实能够在这些 Services 上增加一个 API Gateway，对于 Client 端来说我只须要对到一个 Gateway 就好，对于这个 Gateway 来说我一样是去呼叫各个 Service 并且把资源都解决完后再回传给前端。
如果有读者自身是 SRE 相熟 Docker 或者 K8s 这种用来主动部属容器化应用程式的平台，对于下面这张图应该更相熟了！像 K8s 就有相似 API Gateway 的 Ingress 而 Docker 则有 routing mesh。
不过光有 API Gateway 其实还没方法凸显 Microservices 的特色，在 Microservices 的架构中其实每个 Service 都能够有本人的 DB，目标就是为了不要让每个 Service 之间会相互关联。
但这样做其实有几个毛病
很难保证数据的一致性
以上图为例，如果明天有一个 member 被登记帐号，但这个 member 在被登记帐号之前在 shopping cart 这个 Service 中有待结帐商品，这时候就会呈现 member 数据不统一的问题。
DB 数据遗失
当某一个 Service 坏了须要重启，这时候 DB 的数据有可能就会遗失导致后续的数据呈现谬误。
为了改善这些毛病这时候就能够将这些 Service 的 DB 设计成可弃性，换句话说就是这些 DB 只是用来作为短期的数据存取而已，背地还有一个共用的大数据库去更新这些数据，通常都会利用 Redis 这种 cache DB 来进行设计。
为什麽须要 Microservices？
Microservices 的益处就是能够专一开发在每个小服务上，举例来说以一个购票网站可能会在短时间内涌入大量的流量，这时候 race condition 就显得相当重要，这时候就能够利用 Go 语言进行开发，亦或者是要开发一个以效力为主的服务，这时候就能够用 Rust 进行开发。
下面也提到 Microservices 必须要仰赖 API 之间的沟通，所以通常在企业等级的产品上都会有拆分模组贩售的需要，如果这时候就是利用 Microservices 架构进行开发的话就很好拆分每个服务了。
这些都是应用 Microservices 后所能带来的益处，所以如果读者明天须要开发一个十分複查且宏大的平台，这时候无妨能够利用 Microservices 的架构进行开发喔！
Monolithic Architecture(单体式架构)
讲完了 Microservices 后置信读者应该对于这种架构有了初步的意识，与 Microservices 不一样的架构就是 Monolithic Architecture(单体式架构)。
一般来说咱们失常开发都是应用 Monolithic Architecture，在 Monolithic Architecture 的架构中都会把平台中所有内容都包装起来，像下图这样：
这种架构不是不好，但如果明天想要拆分或者裁减平台上的 Service 其实都会比拟麻烦一些，而且也会怕牵一发而动全身，甚至所有的 Service 背地都会连到同一个 DB，这样极有可能会让 DB connection 同时连线过高导致 request 始终发送失败，所以这也是 Microservices 想要解决的其中一个痛点。
什麽是 Micro Frontends(微前端)？
Micro Frontends 能够想像成前端版的 Microservices，在后端的世界中强调一个又一个 Service 而在前端的世界中则是强调一个又一个的 modules，如何将网页中每一个 module 无效的拆分就是 Micro Frontends 要做的工作。
Micro Frontends 的实现形式
接下来要跟读者介绍的是 Micro Frontends 的实现形式，其实 Micro Frontends 有蛮多种实现形式的：
iframe
透过 iframe 的个性让每个被载入的区块页面都能够独立运行，如果须要有数据上的沟通也能够利用 window.postMessage 来实现，但这样做会有十分多的毛病，像是有可能载入同样的代码、UI 难以管制、甚至可能会有潜在的平安危险，所以笔者还是倡议读者不要用此形式来进行 Micro Frontends 的实现形式。
Client side 利用 JavaScript 载入 module
这个办法简略又粗犷，就是利用 JavaScript create 出 script tag 后，接著再用 script tag 去载入相干的 module，最初再将其内容塞进去对应的 div 内，但毛病就是无奈应用 SSR，整体写法会像下图这样。
Web Components
Web Components 能够说是最多人拿来探讨的 Micro Frontends 的实现形式了，尽管咱们在现今的网页架构中能够自在地 import 大佬们写好的组件，但不免都会遇到以下几个问题：
- 组相依性的问题：须要装置只有该组件才会应用的 library，这会造成整个
node_modules相当宏大。 - Scope 问题：前端为了款式上的变动通常都会有藉由许多的
className来进行款式上的改变，但有可能因为该组件也有撰写一样的className导致很多时候都须要各种 override，长期下来也会是一种我的项目保护上的累赘。 - 版本相容性问题：只有框架进行大改版，基本上就很容易呈现组件无奈兼容新版本的情况，这时候只能组件作者降级版本之后能力再次应用，置信这个情况也是许多开发者都会面临到的窘境。
因而 Web Components 的呈现就是心愿能够解决上述的问题，而 Web Components 一共由以下三种元素组成：
Custom elements
自订一个语意化标签来援用 components，并且利用 JavaScript 来建设 custom elements、shadow DOM、HTML templates 三者之间的关联，这种自定义标签会像这样：<my-custom-element></my-custom-element>。
Shadow DOM
Shadow DOM 简略来说就是在现有的 DOM tree 中产生出一个齐全独立于其余元素的 sub DOM tree，藉由此办法就能够让 sub DOM tree 本人独立运作并且不会烦扰到其余 DOM tree 上的元素。
HTML templates
利用 <template> 以及 <slot> 元素产生出具备複用性的 HTML 样板。
感觉上 Web Components 的设计准则就能够当作是 Micro Frontends 的最好的实现形式，透过上述的三种形式就能够产生出一个独立于本来我的项目而且又不会影响到页面的 modules。
可是这种开发方式其实不太合乎每一种框架的设计理念 (可能只有 Angular 体系最适宜 XD)，而且会让一个 reusable component 开发起来蛮简短的，所以 Micro Frontends 还是没有被很多前端工程师所器重。
Webpack Module Federation
假如咱们明天有 A、B 两个我的项目，其中 A 我的项目有组件发现是能够让 B 我的项目进行複用的，这时候咱们会有以下几种作法达到这个需要：
- 将 A 我的项目中能够被複用的组件手动複制其代码至 B 我的项目。
- 将 A 荐中能够被複用的组件发佈到 npm 上，并且在 B 我的项目中装置。
- 交融 A 我的项目与 B 我的项目并用 monorepo 的架构进行开发。
置信不论是哪个办法都相当複杂而且后续的保护老本也很高，而且随著我的项目越来越大，之后的网站性能也是问题，即使用了 code splitting 或者是 dynamic import 能提昇的效力也无限。
不过这个声音 Webpack 听到了，在 Webpack 5 诞生后推出了一个全新的技术叫 Module Federation，Module Federation 的诞生就是为了帮忙开发者能够 import 内部我的项目曾经 bundle 好的文件，不必再经由额定的装置步骤相当不便。
Webpack Module Federation
下面介绍完 Micro Frontends 的实现形式后，接下来就要进入本篇文章的实战篇了，这边笔者会以 Webpack Module Federation 进行 Demo。
首先笔者先介绍 Webpack Module Federation 的相干设定，在 Webpack Module Federation 的世界中咱们一共会分为 Remote 以及 Host 两种设定区块，别离代表的是 modules export 以及 import 的局部，首先先介绍 Remote 的局部，在这个 plugin 中咱们一共能够设定几个内容：
name
设定 export 进来的名字。
filename
设定 export 进来的文件名称，最终的应用形式会在下方的 import 区块做介绍，官网倡议应用 remoteEntry.js 作为命名。
exposes
exposes 就是负责设定 modules 中须要被 export 的 components 文件 path alias，通常这边的写法都会是 './componentName': 'componentPath‘，在 key 的局部会用相对路径的写法起因是将来在 import 的时候就能够用上方设定好的 name 作为文件抓去的进入点。
举例来说：咱们有一个 Button.jsx 的文件，这时候咱们就能够在 exposes 的区块写上 './Button': './src/Button'，到时候在 import 的时候就能够写上 name/Button 的形式抓去这个文件了。
shared
shared 则是当 components 有应用到雷同的第三方组件时，能够用来设定的相干标准，基本上 shared 一共有三种出现形式：
- Array syntax：只有在 Array 内写上 package name 即可，写法上会像这样：shared: [‘lodash’]
- Object syntax：能够更具体的设定 package，会以 package name 作为 Object key，前方的 value 则能够设定此 package 的版本，写法上会像这样：
shared: {lodash: '^4.17.0'} - Object with sharing hints：基于 Object syntax 的架构上，填入 Webpack Module Federation 可声援的相干 Sharing hints。
在 Object with sharing hints 这边一共能够设定十分多种内容，笔者这裡只单纯阐明几个最罕用的 sharing hints，想要理解所有的 sharing hints 的读者能够参考这个连结。
- eager：让 Webpack 能够直接存取 modules，如果设定为 false 则应用 async fetch 的形式去获得拆散后的 chunk，若设定为 true 则会打包到 remoteEntry 不便进行间接抓取。
- requiredVersion：设定此 package 的版本。
- singleton：应用 singleton 就代表此 package 只容许一个版本，并且只加载一次，通常在 react、react-dom 这种有 global internal state 的 libarary 加上此设定更是重要。
在 Shared 内笔者倡议的写法是基于目前我的项目的 package dependencies 上再额定叠加一些本人想要设定的 Object with sharing hints，最终设定完的长像会像下图这样：
这裡笔者揭示一下读者，如果读者在设定的过程中有遇到这个谬误：Uncaught Error: Shared module is not available for eager consumption
代表读者须要额定在新增一个档案将 component render 到 DOM 的相干程式码都複制下来，最初再到 index.jsx 中去 import 这个文件。
最终出现在网页上的画面就会像下图这样：
再来是 Host 的局部，基本上设定的内容跟 Remote 大同小异，差异在于 Remote 须要设定 exposes 的 components 以及 filename，而 Host 则是要设定该 Remote 的文件地位。
在文件地位中咱们会以三种内容组合，写法上会像这样：name@remoteURL/filename，其中 name 就是上方介绍到的 export 进来的名称，remoteURL 则是 Remote 区块内 Webpack config 中所设定的 output path 相干设定，而 filename 则是上方介绍到的 export 进来的文件名称。
最终的写法就会像下方这样：
于笔者在 shared 的区块都没有加上 eager: true ，所以这边在抓取 components 时都是用 async 的形式去抓取，因而笔者倡议会应用 <Suspense> 的形式进行 data fetching 这样会比拟平安喔！
最终出现在网页上的画面就会像下图这样：
事例地址：https://github.com/w5151381gu…
总结
这次介绍了 Micro Frontends 以及 Microservices 这两种目前最多人探讨的架构，心愿能够让读者更理解一些新时代的架构所带来的优缺点，文章的篇幅可能有点多，读者能够边看边消化一下这样能力更好的了解所有的内容。
代码部署后可能存在的 BUG 没法实时晓得，预先为了解决这些 BUG，花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。
交换
有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。