采用微前端架構(gòu)
考慮到關(guān)于微前端的第一篇文章的大量反饋，以及我們?cè)?DAZN 采用的方式收到的問(wèn)題，我決定分享更多有關(guān)這個(gè)話題的內(nèi)容。
在這篇文章中，我將一一介紹微前端架構(gòu)各種可能的實(shí)現(xiàn)。
盡管微前端是我們前端應(yīng)用的新模型，但許多公司都已經(jīng)試圖接受它們背后的原則，并且已經(jīng)締造了多種實(shí)現(xiàn)方式，來(lái)解決它們的前端和組織上的挑戰(zhàn)。
在開始考慮我們?nèi)绾卧O(shè)計(jì)我們的實(shí)現(xiàn)之前，我認(rèn)為值得一提的有一些方式，這不是一個(gè)詳盡的列表，但有趣的是，它們可以被用來(lái)了解可用的不同可能性：
- Spotify
在桌面端中使用微前端，利用 iframe 將同一視圖的不同部分拼接在一起。
iframe 之間的通信是通過(guò)事件總線進(jìn)行的，該事件總線很好地分離了應(yīng)用的不同部分，允許它們?cè)诓恢勒l(shuí)將要收聽消息或事件的情況下進(jìn)行通信。
此外，這種方法可以節(jié)省大量的時(shí)間來(lái)管理應(yīng)用內(nèi)存，因?yàn)槊看挝覀兏?iframe 位置時(shí)，所有對(duì)象都可以自動(dòng)進(jìn)行垃圾回收。
- 宜家
決定采用不同方式實(shí)施微前端，他們使用的是 Edge Side Includes（ESI）與 Client Side Includes（CSI）混合，我不想在這個(gè)技術(shù)上贅述，因?yàn)樗?a target="_blank">Gustaf的帖子中被廣泛提及，不過(guò)，它絕對(duì)是另一種動(dòng)態(tài)生成我們頁(yè)面內(nèi)容，并在 CDN 級(jí)別或客戶端緩存結(jié)果的機(jī)會(huì)，這取決于我們想采取的方法。
- OpenComponents
它是 Skyscanner、OpenTable 等幾家公司使用的有意思的框架。
OpenComponents 是一個(gè)以自我為中心(opinionated)的框架，它利用端到端組件（前端+后端）的概念，把這些組件提交給一個(gè)寄存器，然后用來(lái)組合一個(gè)應(yīng)用。
還有，在這種情況下，我們可以在 OpenComponents 項(xiàng)目網(wǎng)站上找到更多的信息。
在這 3 個(gè)實(shí)現(xiàn)之間，我們可以找到相似的地方，但其中的一些差異，會(huì)被中大型規(guī)模的組織用來(lái)創(chuàng)建獨(dú)立和技術(shù)不可知的微前端。這方面值得一提的是 Zalando 或 BuzzFeed 也是作為這個(gè)思想流派中的另一種貢獻(xiàn)者。
如果我們想總結(jié)一下到目前為止討論的實(shí)現(xiàn)，我們可以列出 3 種不同的方法：
。使用iframes + 事件總線
。使用 ESI 結(jié)合（或不結(jié)合）CSI
。使用 OpenComponents 或類似的運(yùn)行時(shí)/編譯時(shí)模板系統(tǒng)
“DAZN 采用的方式”
正如我在本文開頭所提到的，還有另一個(gè)實(shí)現(xiàn)要討論：DAZN 采用的方法。
DAZN 是一種 OTT 服務(wù)，可在多個(gè)國(guó)家/地區(qū)提供實(shí)時(shí)和點(diǎn)播內(nèi)容。我們的應(yīng)用不僅可以在網(wǎng)絡(luò)和移動(dòng)設(shè)備上使用，還可以在智能電視，機(jī)頂盒和控制臺(tái)上使用，這一點(diǎn)非常重要，因?yàn)槲覀兘?jīng)常遇到獨(dú)特的挑戰(zhàn)，我們需要開箱即用地來(lái)解決它們。
通常，當(dāng)我們開始一個(gè)微前端項(xiàng)目時(shí)，我們應(yīng)該問(wèn)自己幾個(gè)問(wèn)題，并基于與我們的決策面臨的相關(guān)挑戰(zhàn)的答案，例如：
- 我們想在同一視圖中使用多個(gè)微前端嗎？
- 我們?nèi)绾卧陧?yè)面之間切換路由？
- 我們?nèi)绾卧谖⑶岸酥g共享數(shù)據(jù)？
- 我們?nèi)绾紊晌⑶岸?？運(yùn)行時(shí)還是編譯時(shí)？
讓我們嘗試回答所有的這些問(wèn)題，以便理解我們采用的方法......
我們想在同一個(gè)視圖中使用多個(gè)微前端嗎？
不，我們希望每次加載 1 個(gè)微前端，這樣我們就沒(méi)有微前端之間的共享依賴關(guān)系，每個(gè)微前端都足夠小但不太小，我們完全控制最終的結(jié)果，它是獨(dú)立的技術(shù)和良好的封裝。
我們可以使用同一框架的不同版本，而不會(huì)影響其他微框架甚至不同的技術(shù)，從而不會(huì)對(duì)整個(gè)應(yīng)用產(chǎn)生任何影響。
我們遵循領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）實(shí)踐來(lái)切割我們的子域，并使它們真正獨(dú)立地映射產(chǎn)品團(tuán)隊(duì)結(jié)構(gòu)，并在由產(chǎn)品人員+前端開發(fā)人員+后端開發(fā)人員+功能測(cè)試+測(cè)試開發(fā)組成的大型組織內(nèi)創(chuàng)建垂直，這對(duì)于快速迭代非常有用，在大公司需要時(shí)，團(tuán)隊(duì)之間的速度會(huì)有所不同。
請(qǐng)記住，比你想象的更頻繁，我們的應(yīng)用并非完全地被用戶使用，例如，當(dāng)用戶通過(guò)身份驗(yàn)證時(shí)，將不會(huì)加載登錄/注冊(cè)微前端的所有代碼和依賴項(xiàng)，因?yàn)槲覀冎患虞d經(jīng)過(guò)驗(yàn)證的區(qū)域的微前端。
同時(shí)，當(dāng)用戶未經(jīng)過(guò)身份驗(yàn)證時(shí)，并不是 100％ 確定她將完成登錄的流程，并成功訪問(wèn)應(yīng)用的經(jīng)過(guò)身份驗(yàn)證的區(qū)域，請(qǐng)檢查你的用戶與你的用戶交互方式的統(tǒng)計(jì)信息應(yīng)用，如果你沒(méi)有使用它們，請(qǐng)使用 Google Analytics，Sentry，LogRocket 等工具投入適當(dāng)?shù)臅r(shí)間來(lái)創(chuàng)建正確的可觀察性。
請(qǐng)記住，微前端的目標(biāo)是幫助實(shí)現(xiàn)加載僅僅是用戶需要的 而不是更多。
我們?nèi)绾卧陧?yè)面之間切換路由？如何在微前端之間共享數(shù)據(jù)？
我們可以通過(guò)多種方式在后端，邊緣或客戶端實(shí)現(xiàn)這一點(diǎn)。我們選擇客戶端創(chuàng)建一個(gè)名為 Bootstrap 的 協(xié)調(diào)器(orchestrator)，它有 4 個(gè)主要目標(biāo)：
- 微前端之間的路由
- 加載和卸載微前端（每次 1 個(gè)，從不多個(gè)）
- 初始化檢索配置的應(yīng)用
- 公開 API 層以在微前端之間共享數(shù)據(jù)
我們?nèi)绾紊晌⒂^前端？運(yùn)行時(shí)或編譯時(shí)間？
我們喜歡我們用的人工制品的結(jié)果非常可預(yù)測(cè)，我們希望它們像 SPA 一樣高度安全，因此我們沒(méi)有采取在運(yùn)行時(shí)創(chuàng)建任何東西的路徑，但我們比較喜歡在編譯時(shí)生成微前端，把它們存儲(chǔ)在 AWS S3 上，并通過(guò) Cloudfront CDN 提供服務(wù)。
通過(guò)這種方式，我們不必?fù)?dān)心在我們?yōu)閼?yīng)用提供服務(wù)時(shí)擴(kuò)展我們的基礎(chǔ)架構(gòu)的問(wèn)題或發(fā)生不可預(yù)測(cè)的邊緣情況，我們可以在部署生產(chǎn)環(huán)境之前運(yùn)行端到端測(cè)試和性能測(cè)試，從而在上線之前對(duì)我們部署的內(nèi)容更有信心。
架構(gòu)
在我們的案例中，我們決定將應(yīng)用拆分為多個(gè)子域，以便提前研究用戶如何與我們的 Web 應(yīng)用進(jìn)行交互。對(duì)于綠地(green-field)項(xiàng)目，我建議深入了解你的用戶如何與你的 UX 和產(chǎn)品團(tuán)隊(duì)一起與應(yīng)用進(jìn)行交互，并遵循領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)用于定義子域及其相關(guān)的邊界上下文。
對(duì)于 DAZN 應(yīng)用，幾乎每個(gè)子域在技術(shù)上都被轉(zhuǎn)換為單頁(yè)應(yīng)用，但也有一些例外，例如，由于該子域的廣泛范圍，視頻播放器是一個(gè)組件，然后這些組件被導(dǎo)入到微前端內(nèi)部和任何其他庫(kù)一樣。
微前端由引導(dǎo)程序加載和協(xié)調(diào)，引導(dǎo)程序是嵌入在主 HTML 頁(yè)面中的簡(jiǎn)單的 vanilla javascript 應(yīng)用，它根據(jù)深層鏈接(deep-link)來(lái)請(qǐng)求加載不同的微前端，用戶狀態(tài)或任意請(qǐng)求都來(lái)自加載的微前端。
這就是我們的架構(gòu)的樣子：
引導(dǎo)程序在我們的應(yīng)用的生命周期中始終可用，它負(fù)責(zé)加載我們的微前端，并在設(shè)備和微前端之間暴露一層微小的抽象。
當(dāng)你的目標(biāo)是多個(gè)設(shè)備而不僅僅是瀏覽器時(shí)，也就是我們?cè)谠S多智能電視，機(jī)頂盒和控制臺(tái)上都可以使用我們的應(yīng)用時(shí)，這個(gè)細(xì)節(jié)變得更加相關(guān)，它們通常都有不同的要求和I/O API ，他們被順延封裝在引導(dǎo)程序級(jí)別。
通過(guò)這種方式，我們可以在多個(gè)設(shè)備中運(yùn)行微前端而無(wú)需更改一行代碼，因?yàn)橐龑?dǎo)程序正在抽象運(yùn)行微前端的平臺(tái)。
如果我們想總結(jié)應(yīng)用在瀏覽器中的加載方式，我們可以說(shuō)：
- 用戶在瀏覽器中輸入我們的域名請(qǐng)求我們的 Web 應(yīng)用
- 提供引導(dǎo)程序
- 引導(dǎo)程序初始化應(yīng)用，并從 API 層檢索一些配置
- 基于初始狀態(tài)和用戶請(qǐng)求（深層鏈接或默認(rèn) URL）加載正確的微前端
- 用戶沉浸在我們基于微前端的Web應(yīng)用中！
請(qǐng)記住，每個(gè)微前端都是獨(dú)立的，因此我們不會(huì)在微前端之間共享組件或邏輯。
如果你認(rèn)為這是浪費(fèi)時(shí)間和精力，你就無(wú)法想象每個(gè)團(tuán)隊(duì)在這個(gè)決策中獲得了多少獨(dú)立性。
代碼重復(fù)并不總是一種糟糕的做法，正如我們過(guò)去所了解的那樣，通?？鐖F(tuán)隊(duì)依賴和代碼抽象風(fēng)險(xiǎn)比創(chuàng)建相同組件的 3 到 4 倍更危險(xiǎn)和繁瑣。
我們注意到，花費(fèi)適當(dāng)?shù)臅r(shí)間來(lái)分析用戶流并識(shí)別子域可以減少重復(fù)次數(shù)。
此外，我們注意到使用微前端的話，由于最初分析項(xiàng)目并創(chuàng)建有意義的子域，因此跨團(tuán)隊(duì)的依賴關(guān)系并不像其他項(xiàng)目那樣經(jīng)常發(fā)生。
如果在你的情況下，它是絕對(duì)必須重用的組件，有一種方法可以使用 Web 組件來(lái)減輕重復(fù)，以標(biāo)準(zhǔn)化組件代碼，使用這種技術(shù)，它可以與任何框架結(jié)合使用，但這個(gè)討論應(yīng)該在另一篇帖子里??。
當(dāng)我們開始邁向微前端時(shí)，對(duì)我來(lái)說(shuō)非常清楚的是必須考慮開發(fā)團(tuán)隊(duì)的未來(lái)，而不僅僅是解決技術(shù)問(wèn)題。
借助微前端，我們能夠在不影響交付速度的情況下提供我所尋求的獨(dú)立性，每個(gè)團(tuán)隊(duì)都擁有端到端的特定域，保證了添加新功能，修復(fù)錯(cuò)誤或添加改進(jìn)的簡(jiǎn)單方法，沒(méi)有冒著對(duì)我們的多個(gè)開發(fā)中心傳播的其他應(yīng)用或依賴關(guān)系產(chǎn)生影響的風(fēng)險(xiǎn)。
與新開發(fā)人員加入公司以及在我的會(huì)談或在線研討會(huì)期間多次分享這些信息后，我知道你可能會(huì)有大量關(guān)于引導(dǎo)程序的問(wèn)題，它如何加載微前端，如何共享數(shù)據(jù)等等。
我將在下一篇文章中回答所有這些問(wèn)題，這些問(wèn)題將集中在引導(dǎo)程序上，所以請(qǐng)跟隨我，不要錯(cuò)過(guò)微前端世界中的深潛。
如果你對(duì)微型前端有任何好奇或疑問(wèn)，請(qǐng)隨時(shí)與我聯(lián)系，我總是熱衷于盡可能多地幫助社區(qū)??！
