從微前端到微后端，不可思議的前端架構(gòu)思考
背景
微服務(wù)的概念已經(jīng)過去了好久，微前端也已經(jīng)實(shí)踐了一段時(shí)間，在去年不同的分享會(huì)上都有聽到各家公司關(guān)于微前端的實(shí)踐，總體來說，微前端是因?yàn)榍岸思軜?gòu)的不斷演進(jìn)，結(jié)合后端微服務(wù)的理念而創(chuàng)造出來的，用于解決不同前端框架，甚至相同框架的不同版本，如何結(jié)合的問題。
微前端是一種類似于微服務(wù)的架構(gòu)，它將微服務(wù)的理念應(yīng)用于瀏覽器端，即將 Web 應(yīng)用由單一的單體應(yīng)用轉(zhuǎn)變?yōu)槎鄠€(gè)小型前端應(yīng)用聚合為一的應(yīng)用。各個(gè)前端應(yīng)用還可以獨(dú)立運(yùn)行、獨(dú)立開發(fā)、獨(dú)立部署。
之前和前端框架架構(gòu)的同學(xué)也聊了一下，一直思考的是，微前端目前如何落地，能解決什么問題，似乎目前這個(gè)場(chǎng)景更多的是解決歷史系統(tǒng)的遷移問題，在新系統(tǒng)上，前端，特別是在一個(gè)統(tǒng)一的體系中，很少會(huì)出現(xiàn)跨多語言，多架構(gòu)的場(chǎng)景。更多的是直接重構(gòu)掉，做一個(gè)新的。
既然前端能微前端，后端能不能微呢？微服務(wù)在某些場(chǎng)景下，解決了不同語言的互調(diào)問題，相對(duì)帶來的，其實(shí)還有配套的管理和調(diào)度系統(tǒng)，而前面說到，在單一語言領(lǐng)域內(nèi)，用戶可能更熟悉開發(fā)一個(gè)大系統(tǒng)，這就造成了系統(tǒng)越來越大，越來越復(fù)雜的情況。
在類似阿里的體系中，前端寫的 Node.js 系統(tǒng)非常多，特別是中后臺(tái)系統(tǒng)，搭配管理端和前臺(tái)，業(yè)務(wù)可以很復(fù)雜，前端可以拆分，而后端基本上都是一個(gè)，要微服務(wù)化，或者 FaaS 化，總有道不明的風(fēng)險(xiǎn)，這里的風(fēng)險(xiǎn)更多的是人員成本，人們總是說“明明跑的好好的，為什么要升級(jí)”。
這么說我們并不是想開歷史的倒車，讓熟悉傳統(tǒng)開發(fā)的用戶一步到服務(wù)化，甚至 Serverless 還是有一些困難的，特別是面對(duì) http 的傳統(tǒng)應(yīng)用，路由的思維以及方便的開發(fā)環(huán)境已經(jīng)非常成熟，不管是開發(fā)體驗(yàn)或者底層概念上都很難轉(zhuǎn)變。
我們?cè)O(shè)想過很多種方法讓應(yīng)用變輕，變薄，變得可維護(hù)，可擴(kuò)展。我們?cè)?Midway 中嘗試使用了IoC 的方式進(jìn)行解耦，使用裝飾器和注入替換傳統(tǒng)的實(shí)例化和調(diào)用。
但是這樣并沒有把應(yīng)用拆小，應(yīng)用還是原來的應(yīng)用，邏輯還在。
傳統(tǒng)的分布式調(diào)用是把系統(tǒng)拆成很多服務(wù)，但是這樣做在沒有成熟的配套前會(huì)犧牲可維護(hù)性，排查問題也會(huì)變得困難，同時(shí)資源的開銷也會(huì)難以評(píng)估。
那么，是否有辦法既方便的拆分應(yīng)用，又不影響原本的開發(fā)調(diào)試，資源評(píng)估，甚至是可維護(hù)性呢？
答案可能是有的。
我們一向擅長(zhǎng)用簡(jiǎn)單的方式解決復(fù)雜的問題，但這次有幾個(gè)問題。
1、本地開發(fā)的問題，不能影響開發(fā)
2、部署的問題，盡量減少成本消耗
3、我要拆得簡(jiǎn)單，容易理解和維護(hù)
4、面向未來擴(kuò)展，可遷移到微服務(wù)乃至 FaaS 場(chǎng)景
面對(duì)這么多問題，我們只能一一來思考和解決。
如何拆分
恰好在去年的 jsconf 2019 上，我們提出過一種把應(yīng)用變?yōu)楹瘮?shù)的拆分方法，把路由層（Router，Controller）單單獨(dú)拆分，同時(shí)將，業(yè)務(wù)邏輯（Service）垂直拆分的設(shè)想。
有誰還記得去年的 jsconf 2019 的拆分模型呢。
這種拆分方式將應(yīng)用分為兩類（Controller + Service），同時(shí)又將業(yè)務(wù)本身按照領(lǐng)域進(jìn)行了劃分。假如在這個(gè)基礎(chǔ)上，我們把路由也進(jìn)行領(lǐng)域（垂直劃分），是非常自然的，而原始目錄結(jié)構(gòu)中的?controller?目錄和?service?目錄也很好的印證了這個(gè)想法。
第二個(gè)問題是，拆分了之后，代碼的組織方式，開發(fā)模式有什么變化呢？
開發(fā)方式的變化
用戶是非常懶和挑剔的，任何增加成本減少收益的事情都是不會(huì)干的。如果調(diào)整了代碼組織方式，并且還要修改代碼，甚至調(diào)整原來習(xí)慣的開發(fā)方式的話，都會(huì)罵娘的。
代碼分離之后，管理方式還好說，現(xiàn)在可以用 git 分倉庫管理或者用類似 lerna 的工具來同倉庫管理。但是開發(fā)方式是實(shí)打?qū)嵉捏w驗(yàn)，如何在盡可能不修改的情況下來拆分邏輯，增加擴(kuò)展性呢？
這就需要框架加載方式的支持了。
我們以一個(gè) midway 項(xiàng)目舉例，使用了 lerna 管理 monorepo，模擬拆分的情況。
我們簡(jiǎn)化一下示例目錄結(jié)構(gòu)，大致如下。
main?為主 app，而?api?、book?、video?都是對(duì)應(yīng)的領(lǐng)域模塊（子應(yīng)用），包含對(duì)應(yīng)領(lǐng)域的能力，比如提供 API，圖書服務(wù)以及影視服務(wù)。
可以看到，我們的子包的目錄結(jié)構(gòu)和原本的大應(yīng)用是相同的，而文件也就是原來領(lǐng)域抽象的文件（原來的代碼寫的好的話）。
當(dāng)然，這樣拆了之后，肯定不能運(yùn)行。啟動(dòng)就會(huì)報(bào)錯(cuò)，找不到子包的文件，我們還需要對(duì)框架做一點(diǎn)點(diǎn)調(diào)整。
熟悉 Midway 框架的同學(xué)可能知道，IoC 是通過掃描目錄文件，預(yù)先加載到內(nèi)存中即可拿到實(shí)例，不過這個(gè)目錄結(jié)構(gòu)下，也是無法掃描到的。幸好我們的 IoC 容器支持傳入自定義掃描路徑，那么只需要做一點(diǎn)點(diǎn)小小的修改，讓 IoC 容器能拿到子包的路徑就行。
在 monorepo 下，子包也是一般的 npm 包，我們只要讓用戶定義就行了，比如有一個(gè)名叫?configuration.ts?的文件，內(nèi)容大概是這樣。
哇，這下我們只需要在框架里找到子包（lerna 下 resolve 能找到）的地址，加到掃描路徑里就行了。按照原來的依賴，我們對(duì)相應(yīng)子包（api）也增加依賴，用于提供 Restful API 服務(wù)。
這下，我們的?main?以及?api?包都能獨(dú)立開發(fā)，獨(dú)立工作了，而且和原來的開發(fā)模式完全保持一致。
使用的時(shí)候，是通過導(dǎo)入 npm 包的形式來進(jìn)行協(xié)作，使用的也是標(biāo)準(zhǔn)的?import?語法，以及?class?形式，沒有增加特別的語義，無需去額外學(xué)習(xí)。
這就是夢(mèng)想中的模式，我們似乎可以叫他“微后端”。
部署模型
開發(fā)模型上，我們把代碼變成了子模塊，通過 IoC 掃描的方式讓代碼的開發(fā)模式和以前完全一致，那部署呢？
由于主包沒有什么太大的變化，發(fā)布構(gòu)建的時(shí)候只要單獨(dú)發(fā)布?main?包即可，這種方式特別適合 CRM 后臺(tái)系統(tǒng)，多路由組合的情況。
最后
得益于 IoC 體系，我們能向其他場(chǎng)景去嘗試輸出這些能力。在 2019 年底我們開放了 midway-faas 體系的代碼，這就出現(xiàn)了一些從 midway 代碼轉(zhuǎn)變?yōu)?midway-faas 或者復(fù)用的需求，那么，我們是不是能夠?qū)⒁徊糠?midway（service）代碼，直接拷貝成一個(gè)新的模塊（子包）的形式，讓 midway-faas 的能夠運(yùn)行這些代碼呢？
這其實(shí)是個(gè) feature 預(yù)告，下一版本 midway，以及 midway-faas 已經(jīng)支持了這種擴(kuò)展模型，你可以隨時(shí)的去擴(kuò)展自己的可復(fù)用能力，也可以拆分自己的應(yīng)用，構(gòu)建垂直化領(lǐng)域模型代碼，甚至是從 midway 模塊遷移到 midway-faas 模塊。
技術(shù)永無止境，一切皆有可能，盡在 midway。
最后
如果你覺得這篇內(nèi)容對(duì)你挺有啟發(fā)，我想邀請(qǐng)你幫我三個(gè)小忙：
點(diǎn)個(gè)「在看」，讓更多的人也能看到這篇內(nèi)容（喜歡不點(diǎn)在看，都是耍流氓 -_-）
歡迎加我微信「qianyu443033099」拉你進(jìn)技術(shù)群，長(zhǎng)期交流學(xué)習(xí)...
關(guān)注公眾號(hào)「前端下午茶」，持續(xù)為你推送精選好文，也可以加我為好友，隨時(shí)聊騷。
