建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
?前言
最近筆者在工作上一直聽(tīng)到后端工程師們?cè)谡務(wù)?Microservices(微服務(wù)) 的架構(gòu)設(shè)計(jì)，聽(tīng)到的當(dāng)下立馬去查詢(xún)才知道原來(lái) Microservices 這麼潮，身為前端工程師的我當(dāng)然也希望前端也可以有這麼新穎的架構(gòu)，于是這篇文章就要來(lái)跟讀者介紹 Micro Frontends（微前端）。
成都創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)瑞金,十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專(zhuān)業(yè),歡迎來(lái)電咨詢(xún)建站服務(wù):18982081108
什麼是 Microservices？
在開(kāi)始進(jìn)入本篇文章主題之前要先跟讀者們介紹什麼是 Microservices。
Microservices 是一種軟件架構(gòu)，專(zhuān)注開(kāi)發(fā)在每一個(gè)小型功能或者服務(wù)上，最后再利用模組化的方式組合出一個(gè)大型的應(yīng)用程式。
如果讀者是前端工程師的話(huà)可能會(huì)覺(jué)得上面的敘述很像是 ES6 module 的架構(gòu)，開(kāi)發(fā)者只需要專(zhuān)注在每個(gè) module 上的開(kāi)發(fā)，最后再利用 Bundler 打包這些 module 形成一個(gè)完整的頁(yè)面甚至是應(yīng)用程序，像下圖這樣。
不過(guò)后端跟前端完全不一樣，后端是藉由一個(gè)又一個(gè)的 request? 來(lái) real time 的執(zhí)行相關(guān)的代碼，所以在 Microservices 的架構(gòu)中，想要讓一個(gè)又一個(gè)的服務(wù)能互相溝通，這時(shí)候就是要仰賴(lài)各個(gè) API 了。
但這時(shí)候會(huì)有一個(gè)很大的問(wèn)題，假如這三個(gè) Service 對(duì)于前端來(lái)講有高度相依性，以上圖為例：一個(gè)完整的購(gòu)物網(wǎng)站必須要先讓使用者登入后才可以進(jìn)行購(gòu)買(mǎi)商品以及去購(gòu)物車(chē)結(jié)帳，這時(shí)候在 Client 端就必須要分別打三次 API 并且互相等待才可以完成這整個(gè)流程，甚至假如剛好不小心有一個(gè) Service 壞了需要重新啟動(dòng)，這時(shí)候可能會(huì)先產(chǎn)生一個(gè)過(guò)渡期的 API 避免 Client 端打到有問(wèn)題的 Service，可是 Client 端也不可能每次都會(huì)去記住這個(gè)新產(chǎn)生的 API，所以這勢(shì)必會(huì)造成一個(gè)很大問(wèn)題。
這時(shí)候其實(shí)可以在這些 Services 上添加一個(gè) API Gateway，對(duì)于 Client 端來(lái)說(shuō)我只需要對(duì)到一個(gè) Gateway 就好，對(duì)于這個(gè) Gateway 來(lái)說(shuō)我一樣是去呼叫各個(gè) Service 并且把資源都處理完后再回傳給前端。
如果有讀者本身是 SRE 熟悉 Docker 或者 K8s 這種用來(lái)自動(dòng)部屬容器化應(yīng)用程式的平臺(tái)，對(duì)于上面這張圖應(yīng)該更熟悉了！像 K8s 就有類(lèi)似 API Gateway 的 Ingress 而 Docker 則有 routing mesh。
不過(guò)光有 API Gateway 其實(shí)還沒(méi)辦法凸顯 Microservices 的特色，在 Microservices 的架構(gòu)中其實(shí)每個(gè) Service 都可以有自己的 DB，目的就是為了不要讓每個(gè) Service 之間會(huì)互相關(guān)聯(lián)。
但這樣做其實(shí)有幾個(gè)缺點(diǎn)
很難保證數(shù)據(jù)的一致性
以上圖為例，假如今天有一個(gè) member 被注銷(xiāo)帳號(hào)，但這個(gè) member 在被注銷(xiāo)帳號(hào)之前在** shopping cart** 這個(gè) Service 中有待結(jié)帳商品，這時(shí)候就會(huì)出現(xiàn) member 數(shù)據(jù)不一致的問(wèn)題。
DB 數(shù)據(jù)遺失
當(dāng)某一個(gè) Service 壞了需要重啟，這時(shí)候 DB 的數(shù)據(jù)有可能就會(huì)遺失導(dǎo)致后續(xù)的數(shù)據(jù)出現(xiàn)錯(cuò)誤。
為了改善這些缺點(diǎn)這時(shí)候就可以將這些 Service 的 DB 設(shè)計(jì)成可棄性，換句話(huà)說(shuō)就是這些 DB 只是用來(lái)作為短期的數(shù)據(jù)存取而已，背后還有一個(gè)共用的大數(shù)據(jù)庫(kù)去更新這些數(shù)據(jù)，通常都會(huì)利用 Redis 這種 cache DB 來(lái)進(jìn)行設(shè)計(jì)。
為什麼需要 Microservices？
Microservices 的好處就是可以專(zhuān)注開(kāi)發(fā)在每個(gè)小服務(wù)上，舉例來(lái)說(shuō)以一個(gè)購(gòu)票網(wǎng)站可能會(huì)在短時(shí)間內(nèi)涌入大量的流量，這時(shí)候 race condition 就顯得相當(dāng)重要，這時(shí)候就可以利用 Go 語(yǔ)言進(jìn)行開(kāi)發(fā)，亦或者是要開(kāi)發(fā)一個(gè)以效能為主的服務(wù)，這時(shí)候就可以用 Rust 進(jìn)行開(kāi)發(fā)。
上面也提到 Microservices 必須要仰賴(lài) API 之間的溝通，所以通常在企業(yè)等級(jí)的產(chǎn)品上都會(huì)有拆分模組販?zhǔn)鄣男枨?，假如這時(shí)候就是利用 Microservices 架構(gòu)進(jìn)行開(kāi)發(fā)的話(huà)就很好拆分每個(gè)服務(wù)了。
這些都是使用 Microservices 后所能帶來(lái)的好處，所以假如讀者今天需要開(kāi)發(fā)一個(gè)非常複查且龐大的平臺(tái)，這時(shí)候不妨可以利用 Microservices 的架構(gòu)進(jìn)行開(kāi)發(fā)喔！
Monolithic Architecture(單體式架構(gòu))
講完了 Microservices 后相信讀者應(yīng)該對(duì)于這種架構(gòu)有了初步的認(rèn)識(shí)，與 Microservices 不一樣的架構(gòu)就是 Monolithic Architecture(單體式架構(gòu))。
一般來(lái)說(shuō)我們正常開(kāi)發(fā)都是使用 Monolithic Architecture，在 Monolithic Architecture 的架構(gòu)中都會(huì)把平臺(tái)中所有內(nèi)容都包裝起來(lái)，像下圖這樣：
這種架構(gòu)不是不好，但假如今天想要拆分或者擴(kuò)充平臺(tái)上的 Service 其實(shí)都會(huì)比較麻煩一些，而且也會(huì)怕?tīng)恳话l(fā)而動(dòng)全身，甚至所有的 Service 背后都會(huì)連到同一個(gè) DB，這樣極有可能會(huì)讓 DB connection 同時(shí)連線(xiàn)過(guò)高導(dǎo)致 request 一直發(fā)送失敗，所以這也是 Microservices 想要解決的其中一個(gè)痛點(diǎn)。
什麼是 Micro Frontends(微前端)？
Micro Frontends 可以想像成前端版的 Microservices，在后端的世界中強(qiáng)調(diào)一個(gè)又一個(gè) Service 而在前端的世界中則是強(qiáng)調(diào)一個(gè)又一個(gè)的 modules?，如何將網(wǎng)頁(yè)中每一個(gè) module 有效的拆分就是 Micro Frontends 要做的工作。
Micro Frontends 的實(shí)現(xiàn)方式
接下來(lái)要跟讀者介紹的是 Micro Frontends 的實(shí)現(xiàn)方式，其實(shí) Micro Frontends 有蠻多種實(shí)現(xiàn)方式的：
iframe
透過(guò) iframe? 的特性讓每個(gè)被載入的區(qū)塊頁(yè)面都可以獨(dú)立運(yùn)行，假如需要有數(shù)據(jù)上的溝通也可以利用 window.postMessage 來(lái)完成，但這樣做會(huì)有非常多的缺點(diǎn)，像是有可能載入同樣的代碼、UI 難以控制、甚至可能會(huì)有潛在的安全風(fēng)險(xiǎn)，所以筆者還是建議讀者不要用此方式來(lái)進(jìn)行 Micro Frontends 的實(shí)現(xiàn)方式。
Client side 利用 JavaScript 載入 module
這個(gè)方法簡(jiǎn)單又粗暴，就是利用 JavaScript create 出 script tag? 后，接著再用 script tag 去載入相關(guān)的 module，最后再將其內(nèi)容塞進(jìn)去對(duì)應(yīng)的 div? 內(nèi)，但缺點(diǎn)就是無(wú)法使用 SSR，整體寫(xiě)法會(huì)像下圖這樣。
Web Components
Web Components 可以說(shuō)是最多人拿來(lái)討論的 Micro Frontends 的實(shí)現(xiàn)方式了，雖然我們?cè)诂F(xiàn)今的網(wǎng)頁(yè)架構(gòu)中可以自由地 import 大佬們寫(xiě)好的組件，但難免都會(huì)遇到以下幾個(gè)問(wèn)題：
- 組相依性的問(wèn)題：需要安裝只有該組件才會(huì)使用的 library，這會(huì)造成整個(gè) node_modules 相當(dāng)龐大。
- Scope 問(wèn)題：前端為了樣式上的變化通常都會(huì)有藉由許多的 className? 來(lái)進(jìn)行樣式上的改動(dòng)，但有可能因?yàn)樵摻M件也有撰寫(xiě)一樣的 className 導(dǎo)致很多時(shí)候都需要各種 override，長(zhǎng)期下來(lái)也會(huì)是一種項(xiàng)目維護(hù)上的負(fù)擔(dān)。
- 版本相容性問(wèn)題：只要框架進(jìn)行大改版，基本上就很容易出現(xiàn)組件無(wú)法兼容新版本的狀況，這時(shí)候只能組件作者升級(jí)版本之后才能再次使用，相信這個(gè)狀況也是許多開(kāi)發(fā)者都會(huì)面臨到的困境。
因此 Web Components 的出現(xiàn)就是希望可以解決上述的問(wèn)題，而 Web Components 一共由以下三種元素組成：
Custom elements
自訂一個(gè)語(yǔ)意化標(biāo)簽來(lái)引用 components，并且利用 JavaScript 來(lái)建立 custom elements、shadow DOM、HTML templates 三者之間的關(guān)聯(lián)，這種自定義標(biāo)簽會(huì)像這樣：
Shadow DOM
Shadow DOM 簡(jiǎn)單來(lái)說(shuō)就是在現(xiàn)有的 DOM tree 中產(chǎn)生出一個(gè)完全獨(dú)立于其他元素的 sub DOM tree，藉由此方法就可以讓 sub DOM tree 自己獨(dú)立運(yùn)作并且不會(huì)干擾到其他 DOM tree 上的元素。
HTML templates
利用 ? 以及
感覺(jué)上 Web Components 的設(shè)計(jì)準(zhǔn)則就可以當(dāng)作是 Micro Frontends 的最好的實(shí)現(xiàn)方式，透過(guò)上述的三種方式就可以產(chǎn)生出一個(gè)獨(dú)立于原本項(xiàng)目而且又不會(huì)影響到頁(yè)面的 modules。
可是這種開(kāi)發(fā)方式其實(shí)不太符合每一種框架的設(shè)計(jì)理念(可能只有 Angular 體系最適合XD)，而且會(huì)讓一個(gè) reusable component 開(kāi)發(fā)起來(lái)蠻冗長(zhǎng)的，所以 Micro Frontends 還是沒(méi)有被很多前端工程師所重視。
Webpack Module Federation
假設(shè)我們今天有 A、B 兩個(gè)項(xiàng)目，其中 A 項(xiàng)目有組件發(fā)現(xiàn)是可以讓 B 項(xiàng)目進(jìn)行複用的，這時(shí)候我們會(huì)有以下幾種作法達(dá)到這個(gè)需求：
- 將 A 項(xiàng)目中可以被複用的組件手動(dòng)複制其代碼至 B 項(xiàng)目。
- 將 A 薦中可以被複用的組件發(fā)佈到 npm 上，并且在 B 項(xiàng)目中安裝。
- 融合 A 項(xiàng)目與 B 項(xiàng)目并用 monorepo 的架構(gòu)進(jìn)行開(kāi)發(fā)。
相信不管是哪個(gè)方法都相當(dāng)複雜而且后續(xù)的維護(hù)成本也很高，而且隨著項(xiàng)目越來(lái)越大，之后的網(wǎng)站性能也是問(wèn)題，即便用了 code splitting 或者是 dynamic import 能提昇的效能也有限。
不過(guò)這個(gè)聲音 Webpack 聽(tīng)到了，在 Webpack 5 誕生后推出了一個(gè)全新的技術(shù)叫 Module Federation，Module Federation 的誕生就是為了幫助開(kāi)發(fā)者可以 import 外部項(xiàng)目已經(jīng) bundle 好的文件，不用再經(jīng)由額外的安裝步驟相當(dāng)方便。
Webpack Module Federation
上面介紹完 Micro Frontends 的實(shí)現(xiàn)方式后，接下來(lái)就要進(jìn)入本篇文章的實(shí)戰(zhàn)篇了，這邊筆者會(huì)以 Webpack Module Federation 進(jìn)行 Demo。
首先筆者先介紹 Webpack Module Federation 的相關(guān)設(shè)定，在 Webpack Module Federation 的世界中我們一共會(huì)分為 Remote 以及 Host 兩種設(shè)定區(qū)塊，分別代表的是 modules export 以及 import 的部分，首先先介紹 Remote 的部分，在這個(gè) plugin 中我們一共可以設(shè)定幾個(gè)內(nèi)容：
name
設(shè)定 export 出去的名字。
filename
設(shè)定 export? 出去的文件名稱(chēng)，最終的使用方式會(huì)在下方的 import? 區(qū)塊做介紹，官方建議使用 remoteEntry.js 作為命名。
exposes
exposes? 就是負(fù)責(zé)設(shè)定 modules? 中需要被 export? 的 components? 文件 path alias?，通常這邊的寫(xiě)法都會(huì)是 './componentName': 'componentPath?' ，在 key? 的部分會(huì)用相對(duì)路徑的寫(xiě)法原因是未來(lái)在 import? 的時(shí)候就可以用上方設(shè)定好的 name 作為文件抓去的進(jìn)入點(diǎn)。
舉例來(lái)說(shuō)：我們有一個(gè) Button.jsx? 的文件，這時(shí)候我們就可以在 exposes? 的區(qū)塊寫(xiě)上 './Button': './src/Button'? ，到時(shí)候在 import? 的時(shí)候就可以寫(xiě)上 name/Button 的方式抓去這個(gè)文件了。
shared
shared 則是當(dāng) components 有使用到相同的第三方組件時(shí)，可以用來(lái)設(shè)定的相關(guān)規(guī)范，基本上 shared 一共有三種呈現(xiàn)方式：
- Array syntax：只要在 Array 內(nèi)寫(xiě)上 package name 即可，寫(xiě)法上會(huì)像這樣：shared: ['lodash']
- Object syntax：可以更詳細(xì)的設(shè)定 package，會(huì)以 package name 作為 Object key，后方的 value 則可以設(shè)定此 package 的版本，寫(xiě)法上會(huì)像這樣：shared: { lodash: '^4.17.0' }
- Object with sharing hints：基于 Object syntax 的架構(gòu)上，填入 Webpack Module Federation 可支援的相關(guān) Sharing hints。
在 Object with sharing hints 這邊一共可以設(shè)定非常多種內(nèi)容，筆者這裡只單純說(shuō)明幾個(gè)最常用的 sharing hints，想要了解所有的 sharing hints 的讀者可以參考這個(gè)連結(jié)。
eager：讓 Webpack 可以直接存取 modules，如果設(shè)定為 false 則使用 async fetch 的方式去取得分離后的 chunk，若設(shè)定為 true 則會(huì)打包到 remoteEntry 方便進(jìn)行直接抓取。
requiredVersion：設(shè)定此 package 的版本。
singleton：使用 singleton 就代表此 package 只允許一個(gè)版本，并且只加載一次，通常在 react 、 react-dom 這種有 global internal state 的 libarary 加上此設(shè)定更是重要。
在 Shared 內(nèi)筆者建議的寫(xiě)法是基于目前項(xiàng)目的 package dependencies 上再額外疊加一些自己想要設(shè)定的 Object with sharing hints，最終設(shè)定完的長(zhǎng)像會(huì)像下圖這樣：
這裡筆者提醒一下讀者，假如讀者在設(shè)定的過(guò)程中有遇到這個(gè)錯(cuò)誤：Uncaught Error: Shared module is not available for eager consumption
代表讀者需要額外在新增一個(gè)檔案將 component render 到 DOM 的相關(guān)程式碼都複制上去，最后再到 index.jsx? 中去 import 這個(gè)文件。
最終呈現(xiàn)在網(wǎng)頁(yè)上的畫(huà)面就會(huì)像下圖這樣：
再來(lái)是 Host 的部分，基本上設(shè)定的內(nèi)容跟 Remote 大同小異，差別在于 Remote 需要設(shè)定 exposes 的 components 以及 filename ，而 Host 則是要設(shè)定該 Remote 的文件位置。
在文件位置中我們會(huì)以三種內(nèi)容組合，寫(xiě)法上會(huì)像這樣：name@remoteURL/filename? ，其中 name 就是上方介紹到的 export 出去的名稱(chēng)，remoteURL 則是 Remote 區(qū)塊內(nèi) Webpack config 中所設(shè)定的 output path 相關(guān)設(shè)定，而 filename 則是上方介紹到的 export 出去的文件名稱(chēng)。
最終的寫(xiě)法就會(huì)像下方這樣：
于筆者在 shared 的區(qū)塊都沒(méi)有加上 eager: true ?，所以這邊在抓取 components 時(shí)都是用 async 的方式去抓取，因此筆者建議會(huì)使用
最終呈現(xiàn)在網(wǎng)頁(yè)上的畫(huà)面就會(huì)像下圖這樣：
事例地址：https://github.com/w5151381guy/micro-frontend-practice
總結(jié)
這次介紹了 Micro Frontends 以及 Microservices 這兩種目前最多人討論的架構(gòu)，希望可以讓讀者更了解一些新時(shí)代的架構(gòu)所帶來(lái)的優(yōu)缺點(diǎn)，文章的篇幅可能有點(diǎn)多，讀者可以邊看邊消化一下這樣才能更好的理解所有的內(nèi)容。
本文名稱(chēng)：后端有微服務(wù)，那前端呢？初探微前端的世界
分享路徑：http://www.dlmjj.cn/article/ccejhgc.html
