基于模塊聯(lián)邦與大倉模式的商家巨石應(yīng)用拆分實(shí)踐
一、背景
商家后臺(tái)前端代碼目前代碼量達(dá)到十萬級(jí)，每個(gè)迭代團(tuán)隊(duì)需要在同一倉庫中迭代幾十個(gè)需求，在日漸龐大的巨石應(yīng)用下如此活躍的迭代，開發(fā)效率與構(gòu)建效率上給我們帶來了一些挑戰(zhàn)，我們需要優(yōu)化以下幾點(diǎn)：
- 代碼構(gòu)建體量大，隨著時(shí)間推移，構(gòu)建速度的優(yōu)化空間較少。
- 巨石應(yīng)用下各個(gè)業(yè)務(wù)模塊沒有做物理拆分，管理與維護(hù)難度提升。
- 應(yīng)用粒度較粗，在發(fā)布節(jié)點(diǎn)上需要對應(yīng)用做進(jìn)一步拆分以優(yōu)化發(fā)布粒度。
- 巨石應(yīng)用下，組件與業(yè)務(wù)的關(guān)系需要梳理，避免出現(xiàn)重復(fù)開發(fā)的情況。
微前端是目前解決應(yīng)用拆分的主要解決方案，但是由于其隔離性的機(jī)制使得各個(gè)子應(yīng)用間完全隔離，使得用戶在開發(fā)子應(yīng)用時(shí)無法訪問其他子應(yīng)用頁面，這對于各子應(yīng)用存在關(guān)聯(lián)關(guān)系需要同時(shí)訪問開發(fā)的場景開發(fā)效率較低，并且目前市面上已經(jīng)完全封裝的主流微前端框架對我們來說是黑盒，無法做到高度自定義，無法滿足特定拆分需求，因此我們決定采用模塊聯(lián)邦與大倉模式結(jié)合的方式解決以上問題。
二、目標(biāo)
提升構(gòu)建與維護(hù)效率
將巨石應(yīng)用進(jìn)行拆分，獨(dú)立開發(fā)與部署、提升構(gòu)建部署效率與代碼維護(hù)效率。
雖是單個(gè)子應(yīng)用開發(fā)，但可全量訪問巨石應(yīng)用模塊
由于商家內(nèi)部各應(yīng)用間在業(yè)務(wù)上存在上下游的關(guān)系，我們在開發(fā)D子應(yīng)用時(shí)，需要在其上游的C、B子應(yīng)用中進(jìn)行相關(guān)配置，它們之間是強(qiáng)綁定的關(guān)系，結(jié)論就是：需要在本地開發(fā)時(shí)，能夠同時(shí)使用其他子應(yīng)用的頁面模塊的功能。
三、技術(shù)方案
以上提到的提升構(gòu)建與維護(hù)效率，目前微前端與MF方案都是支持的，關(guān)鍵點(diǎn)在于如何在本地開發(fā)能夠訪問到平臺(tái)的全量功能。本地代碼已經(jīng)有了，啟動(dòng)本地進(jìn)程即可，那么，其他子應(yīng)用如何訪問?
微應(yīng)用代理
如果是從本地再啟動(dòng)其他應(yīng)用，這其實(shí)就背離了應(yīng)用拆分的初衷，同時(shí)也降低了本地開發(fā)的效率，同時(shí)隨著子應(yīng)用越來越多，本地進(jìn)程也會(huì)越來越多，這可能會(huì)大大影響本地開發(fā)效率。看來本地啟動(dòng)行不通，那么從哪里訪問呢?對了，線上不是可以訪問到其他模塊嗎?但是怎么將本地開發(fā)與線上的模塊結(jié)合呢?由于目前商家后臺(tái)使用了MF方式在路由層或vue文件內(nèi)遠(yuǎn)程引入MF模塊，那么是否可以通過MF模塊轉(zhuǎn)發(fā)的方式將遠(yuǎn)程組件代理至本地組件呢?
以上的組件代理插件實(shí)質(zhì)上是用于做MF組件加載管理的chrome插件，可以控制基座應(yīng)用加載的模塊是線上的還是本地。
代理方案如下
- 用戶首次進(jìn)入線上測試環(huán)境，會(huì)加載遠(yuǎn)程應(yīng)用入口文件，代理插件會(huì)將入口文件根據(jù)用戶配置轉(zhuǎn)發(fā)至對應(yīng)的本地地址。
- 進(jìn)入路由訪問，由于上一步對遠(yuǎn)程應(yīng)用入口做了代理，加載的模塊被代理至本地，這樣用戶就可以在線上訪問到本地頁面，實(shí)現(xiàn)本地開發(fā)。
- 在線上基座應(yīng)用與本地應(yīng)用間建立websocket鏈接，本地應(yīng)用代碼更改后通知線上基座應(yīng)用刷新頁面。
下面是具體實(shí)現(xiàn)：
generateRedirectUrl = (details: UrlDetailsType) => {
if (details.url.includes(MICRO_ONLINE_LOAD_PATH)) {
const redirectUrl = this.generateDefaultProxyUrl({ originUrl: details.url })
if (redirectUrl) {
console.log('觸發(fā)代理', `${details.url}代理至${redirectUrl}`)
this.checkMicroAppStatus({ originUrl: details.url, redirectUrl })
return {
redirectUrl,
}
}
}
if (details.url.includes('t1-dev.dewu.net:98')) {
console.log("details.url.includes('t1-dev.dewu.net:98')", details.url);
const redirectUrl = this.generateOnlineUrlByLocal({ originUrl: details.url })
if (redirectUrl) {
console.log('觸發(fā)代理', `${details.url}代理至${redirectUrl}`)
this.checkMicroAppStatus({ originUrl: details.url, redirectUrl })
return {
redirectUrl,
}
}
}
}- 文件內(nèi)容代理為本地文件后，此時(shí)對應(yīng)的模塊加載path還是會(huì)加載線上路由，這里同樣需要做內(nèi)容代理。
- 由于是基于線上測試環(huán)境開發(fā)，本地開發(fā)的頁面不僅需要在線上展示，并且本地代碼更新后需要觸發(fā)線上頁面更新，這是必不可少的步驟，我們基于websocket將本地與線上進(jìn)行連接。
- 不同子應(yīng)用動(dòng)態(tài)設(shè)置socketUrl與PingUrl。
function getHost() {
if (process.env.SOCKET_SERVER) {
return new URL(process.env.SOCKET_SERVER);
}
return location;
}
function getSocketUrl() {
let h = getHost();
let host = h.host;
host = `localhost:${PORT}`;
const isHttps = h.protocol === 'https:';
return `ws://${host}`;
}
function getPingUrl() {
const h = getHost();
return `${h.protocol}//${h.host}/__umi_ping`;
}- 建立websocket連接，并定時(shí)觸發(fā)連接檢測。
let pingTimer = null;
let isFirstCompilation = true;
let mostRecentCompilationHash = null;
let hasCompileErrors = false;
let hadRuntimeError = false;
const pingUrl = getPingUrl();
if (!window[`${APP_NAME}UmiEntry`]) {
const socket = new WebSocket(getSocketUrl(), 'webpack-hmr');
socket.addEventListener('message', ({ data }) =>
__awaiter(void 0, void 0, void 0, function* () {
data = JSON.parse(data);
if (data.type === 'connected') {
console.log(`[webpack] connected.`);
// proxy(nginx, docker) hmr ws maybe caused timeout,
// so send ping package let ws keep alive.
pingTimer = setInterval(() => socket.send('ping'), 30000);
} else {
handleMessage(data).catch(console.error);
}
}),
);
}- 本地需求開發(fā)共享部署態(tài)代碼的store與路由跳轉(zhuǎn)。
- 需求開發(fā)完成后進(jìn)行單個(gè)應(yīng)用部署，由于是本地代理，不影響測試訪問。
基于模塊聯(lián)邦
前面的代理機(jī)制依賴于MF的遠(yuǎn)程加載，模塊聯(lián)邦加載機(jī)制可參考「掘金」平臺(tái)中題目為“最詳細(xì)的Module Federation的實(shí)現(xiàn)原理講解” 這篇文章。基于模塊聯(lián)邦的微前端落地方案可以參考之前的一篇文章 基于Module Federation的模塊化跨棧方案探索。
本地與部署態(tài)基座應(yīng)用通過MF方案加載子應(yīng)用，同時(shí)部署態(tài)新增動(dòng)態(tài)加載保證遠(yuǎn)程組件的實(shí)時(shí)性，在加載入口文件處進(jìn)行監(jiān)控告警。
基座應(yīng)用為部署態(tài)，在進(jìn)行MF加載時(shí)，通過chrome插件動(dòng)態(tài)控制加載子文件路徑，開發(fā)態(tài)子應(yīng)用共享部署態(tài)代碼的store，路由注冊等基礎(chǔ)配置。
加載態(tài)依賴chrome插件做動(dòng)態(tài)代理，實(shí)現(xiàn)本地與其他測試環(huán)境構(gòu)建代碼的動(dòng)態(tài)切換，同時(shí)子應(yīng)用與部署態(tài)代碼建立websocket代碼更新鏈接，在子應(yīng)用更新代碼時(shí)，實(shí)時(shí)刷新線上頁面。同時(shí)支持端口的動(dòng)態(tài)配置，一鍵關(guān)閉。
效果
以上介紹加載鏈路保證了構(gòu)建部署提速與功能的完整，較好的解決了應(yīng)用拆分功能不完備問題。本次架構(gòu)優(yōu)化將構(gòu)建由15s減少至2.0s。業(yè)務(wù)需求部署速度由8min減少至2min。
四、應(yīng)用拆分
大倉模式
應(yīng)用拆分只是目的，要實(shí)現(xiàn)這個(gè)目標(biāo)不僅僅要做拆分，對于商家后臺(tái)來說各個(gè)應(yīng)用間的復(fù)用同等重要，由于是業(yè)務(wù)解耦，這意味著各應(yīng)用間存在更多可復(fù)用的功能與模塊。
同時(shí)不僅是商家后臺(tái)的部分模塊也會(huì)在交易后臺(tái)使用，既要保證應(yīng)用業(yè)務(wù)的解耦，同時(shí)要保證組件充分復(fù)用，大倉模式是目前最合適的方案。
大倉模塊化共享
由于商家后臺(tái)各個(gè)子應(yīng)用由于同屬商家整條業(yè)務(wù)鏈路，存在眾多可共用的組件和模塊，而npm發(fā)布模式本身給業(yè)務(wù)組件與業(yè)務(wù)項(xiàng)目帶來了一定隔離性，同時(shí)因?yàn)楦髯討?yīng)用業(yè)務(wù)上存在關(guān)聯(lián)，很多大型模塊需要被多個(gè)子應(yīng)用引入，而這些大型模塊的迭代通常比較頻繁，同時(shí)需要對業(yè)務(wù)請求進(jìn)行封裝。這里我們使用了基于大倉模式的源碼引入以達(dá)到代碼共用的目的。組件開發(fā)鏈路如下：
這里體現(xiàn)的是源碼引入的方式，在構(gòu)建態(tài)進(jìn)行通用模塊的打包構(gòu)建，這一點(diǎn)目前能跑通的背景是商家后臺(tái)本身是一個(gè)完整的應(yīng)用，現(xiàn)有的模式同樣是一個(gè)組件被多個(gè)模塊所使用，同時(shí)測試階段也是全量回歸。以下是大倉組件基礎(chǔ)鏈路：
- 組件構(gòu)建發(fā)布使用標(biāo)準(zhǔn)的cli規(guī)范。
- 在提交MR節(jié)點(diǎn)與發(fā)布節(jié)點(diǎn)新增自動(dòng)化卡口。
- 通過依賴分析自動(dòng)化檢測單測運(yùn)行范圍。
- 組件發(fā)布時(shí)發(fā)布通知，提醒組件使用者，并運(yùn)行業(yè)務(wù)單測。
之后會(huì)對該部分做詳細(xì)介紹。
五、總結(jié)與思考
單應(yīng)用構(gòu)建->單頁面構(gòu)建?
以上主要講述了MF方案如何將本地結(jié)合線上開發(fā)，這里僅對微應(yīng)用級(jí)別做了解耦，基于MF的模塊化實(shí)現(xiàn)，由于remoteMicro實(shí)質(zhì)上是創(chuàng)建了一個(gè)引用路徑到require函數(shù)的映射然后代理至本地，那么對于不同模塊，在能力上是具備模塊化代理的能力的，基于目前MF按需構(gòu)建(僅構(gòu)建暴露出去的組件模塊)的規(guī)則，我們可以對某個(gè)模塊的映射對象里的xxx.async.js做代理。這樣就可以實(shí)現(xiàn)頁面粒度的按需構(gòu)建，在部署構(gòu)建提速上有很大潛力。
本篇文章主要介紹了如何對商家巨石應(yīng)用做拆分，包括拆分方案的介紹，如何同時(shí)保證單個(gè)構(gòu)建與功能完整性，并且針對微應(yīng)用代理加載進(jìn)行了進(jìn)一步探索，接著介紹了大倉模式下需要遵循的規(guī)范以及未來的規(guī)劃。大倉模式目前在前端平臺(tái)已經(jīng)持續(xù)不斷地完善，將來應(yīng)該會(huì)針對此模式做更詳細(xì)的介紹，在拆分這件事情上，對于構(gòu)建本身或許能被更加細(xì)粒度化，構(gòu)建文件的代理本質(zhì)上減少了代碼的構(gòu)建量，目前是通過人為控制的方式，此次驗(yàn)證了模塊聯(lián)邦支持可代理與動(dòng)態(tài)更改expose。基于這兩個(gè)特性，是否能將構(gòu)建做到更加局部化，這可能會(huì)成為構(gòu)建優(yōu)化的方向。應(yīng)用拆分一方面提升了開發(fā)人員的開發(fā)與部署效率，同時(shí)也對業(yè)務(wù)迭代流程做了業(yè)務(wù)解耦，明確了責(zé)任邊界，更有利于后臺(tái)應(yīng)用的開發(fā)需求管理，降低需求代碼維護(hù)成本。
