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