未來，僅憑幾個(gè)前端工程師，就能 hold 住一家企業(yè)嗎？
微前端架構(gòu)旨在解決單體應(yīng)用在一個(gè)相對(duì)長的時(shí)間跨度下，由于參與的人員、團(tuán)隊(duì)的增加，從一個(gè)普通應(yīng)用演變成一個(gè)巨石應(yīng)用(Frontend Monolith)，隨之而來的應(yīng)用不可維護(hù)問題。這類問題在企業(yè)級(jí) Web 應(yīng)用中尤為常見。今天，我們就來聊聊擁抱云時(shí)代的前端開發(fā)架構(gòu)：微前端。
微前端的價(jià)值
阿里云提供的很多商業(yè)化產(chǎn)品和服務(wù)，本質(zhì)上是對(duì)外提供「能力」，普惠中小企業(yè)。目前，能力輸出主要是通過 OpenAPI，用以集成到企業(yè)自己的業(yè)務(wù)場景中，這里主要解決的還是企業(yè)底層的能力問題——無需雇傭算法工程師，就可以擁有語音、圖像識(shí)別等能力。安全也是一樣，不需要找安全專家，普通的工程師就可以通過控制臺(tái)高效地處理各種安全事件。
但是，隨著云技術(shù)不斷的下沉，與產(chǎn)業(yè)結(jié)合的越來越緊密，OpenAPI 唯有把粒度做得越來越細(xì)，才能滿足各種各樣的業(yè)務(wù)場景，但同時(shí)企業(yè)側(cè)的學(xué)習(xí)成本和開發(fā)復(fù)雜度自然就上去了?？刂婆_(tái)做為管(理)控(制)這些能力的工具，目前也只能算是「標(biāo)品」，必須為了滿足不同體量、不同業(yè)務(wù)特點(diǎn)的需求，靈活地組合和部署，就像是用戶自己開發(fā)的一樣。
綜上所述，微前端的價(jià)值有 3 點(diǎn)：
- 解決產(chǎn)品側(cè)的擴(kuò)展性和組合性?；麨榱悖杂山M合。
- 解決能力輸出的「最后一公里」。
- 云生態(tài)中的「新物種」 — 微應(yīng)用。
如果微前端只存在工程上的價(jià)值，那它是不值得大張旗鼓去做的。
我認(rèn)為，前端團(tuán)隊(duì)需要在這個(gè)方面做出業(yè)務(wù)價(jià)值。如果你問我 Ant Design 有什么技術(shù)價(jià)值?它的價(jià)值就是有大量的企業(yè)在用，形成某種能力依賴，不需要找設(shè)計(jì)師或者多么資深的前端工程師，就可以做出看上去很專業(yè)的后臺(tái)界面。
在這條價(jià)值鏈路上，OpenAPI 太底層，控制臺(tái)不靈活，UI 庫太通用。其中的空白點(diǎn)是綁定能力的商業(yè)化組件。舉個(gè)例子，企業(yè)的后臺(tái)管理頁上，可以直接 inside 一個(gè)「漏洞管理」的微前端應(yīng)用，和一個(gè) DataV 的微前端應(yīng)用展示數(shù)據(jù)，只需要簡單配一下即可，不用開發(fā)，就能做到“就像自己開發(fā)的一樣”。反過來也一樣，ISV 在阿里云的產(chǎn)品平臺(tái)上，不僅可以通過小程序的形式，也可以通過微前端應(yīng)用的形式輸入自己的服務(wù)。
微前端的問題域
簡單地說，搞微前端目的就是要將產(chǎn)品原子化(跟原子化的 OpenAPI 一個(gè)道理)，再根據(jù)客戶業(yè)務(wù)場景組合。每個(gè)功能模塊能單獨(dú)迭代，自由集成當(dāng)然好，但維護(hù)成本怎么控制。怎么調(diào)試、公共組件版本控制、眾多同窗微應(yīng)用之間怎么“和諧相處”等等。微前端并非只是解決在頁面上異步加載一個(gè)模塊就完事了，更多的是將改造引發(fā)的一系列問題需要通過體系化的方案解決，否則就變成反生產(chǎn)力工具。
目前，阿里的微前端方案有 qiankun(乾坤)、Magix、icestack、以及內(nèi)部很多的微前端解決方案?；蚨嗷蛏俣紟в幸恍┳陨淼臉I(yè)務(wù)特色，沒有明確提出標(biāo)準(zhǔn)，或者明確定義微前端的技術(shù)體系到底包含哪些內(nèi)容。這方面有項(xiàng)目落地的團(tuán)隊(duì)真應(yīng)該再進(jìn)一步瞄準(zhǔn)更高的價(jià)值點(diǎn)做，同時(shí)廣泛交流，這樣才能更快得出標(biāo)準(zhǔn)化的東西。我們團(tuán)隊(duì)也在實(shí)踐中，這里我拋出一些開放性問題討論。
首先必須明確微前端不是框架、不是工具/庫，而是一套架構(gòu)體系，它包括若干庫、工具、中心化治理平臺(tái)以及相關(guān)配套設(shè)施。
微前端包括 3 部分：
- 微前端的基礎(chǔ)設(shè)施。這是目前討論得最多的，一個(gè)微應(yīng)用如何通過一個(gè)組件基座加載進(jìn)來、腳手架工具、怎么單獨(dú)構(gòu)建和部署、怎么聯(lián)調(diào)。
- 微前端配置中心：標(biāo)準(zhǔn)化的配置文件格式，支持灰度、回滾、紅藍(lán)、A/B 等發(fā)布策略。
- 微前端的可觀察性工具：對(duì)于任何分布式特點(diǎn)的架構(gòu)，線上/線下治理都很重要。
微前端具體要解決好的 10 個(gè)問題：
- 微應(yīng)用的注冊(cè)、異步加載和生命周期管理;
- 微應(yīng)用之間、主從之間的消息機(jī)制;
- 微應(yīng)用之間的安全隔離措施;
- 微應(yīng)用的框架無關(guān)、版本無關(guān);
- 微應(yīng)用之間、主從之間的公共依賴的庫、業(yè)務(wù)邏輯(utils)以及版本怎么管理;
- 微應(yīng)用獨(dú)立調(diào)試、和主應(yīng)用聯(lián)調(diào)的方式，快速定位報(bào)錯(cuò)(發(fā)射問題);
- 微應(yīng)用的發(fā)布流程;
- 微應(yīng)用打包優(yōu)化問題;
- 微應(yīng)用專有云場景的出包方案;
- 漸進(jìn)式升級(jí)：用微應(yīng)用方案平滑重構(gòu)老項(xiàng)目。
通過問題理解問題是一種思考方式，相信大家能溝通通過微前端三大組成部分和它要解決的 10 個(gè)問題，能夠有一個(gè)大概的理解。下面，看一下我歸納的微前端的架構(gòu)體系(如圖)：
通過上圖，很明顯的看出前后端分工，以及線上微應(yīng)用相關(guān)配置流程。整體運(yùn)行環(huán)境以及開發(fā)流程是非常復(fù)雜的，留到大會(huì)的時(shí)候再詳細(xì)講解。
微前端的基本原理
如下圖所示，微前端的工程化是從傳統(tǒng)前端工程化體系升級(jí)上來的。
比如構(gòu)建，增加微應(yīng)用類型的項(xiàng)目構(gòu)建，有動(dòng)態(tài)的打包策略。傳統(tǒng)項(xiàng)目管理工具通常是命令行工具，包括構(gòu)建、發(fā)布、測試，會(huì)升級(jí)為項(xiàng)目工作臺(tái)，通過 Web 界面管理項(xiàng)目。一個(gè)項(xiàng)目包括哪些微應(yīng)用，版本，發(fā)布策略等在配置中心統(tǒng)一管理。一個(gè)大型應(yīng)用被「碎片化」后，還要能做到「一目了然」。哪個(gè)模塊報(bào)錯(cuò)，加載失敗等異常發(fā)生第一時(shí)間反應(yīng)在配置中心里。
下面的原型圖，就是一個(gè)最基本的配置中心的樣貌。微前端體系要可控、可觀察。
通過多個(gè)微應(yīng)用的組合，能夠在變化如此復(fù)雜的需求中，更好的更快的賦能業(yè)務(wù)。
云時(shí)代的前端開發(fā)模式
前端開發(fā)從 PC 時(shí)代到移動(dòng)時(shí)代，從刀耕火種的原始運(yùn)維到云計(jì)算時(shí)代，回顧起來，我們會(huì)發(fā)現(xiàn)——開發(fā)模式跟時(shí)代背景真是密不可分。前端奮斗 20 年才把頁面寫好，而現(xiàn)在又變成「切頁面」了，只是此「切」非彼「切」。云時(shí)代的開發(fā)模式注定是「碎片化」的，開發(fā)是面向模塊的，而頁面只是一種組合場景，一種運(yùn)行時(shí)容器。
我想，未來的產(chǎn)品開發(fā)主要時(shí)間是在「編排」——編排服務(wù)、編排邏輯、編排組件、編排訪問策略、編排流程。到了云時(shí)代，一家企業(yè)只要招幾個(gè)前端工程師就可以了，兼顧開發(fā)和運(yùn)維、資產(chǎn)全部上云，運(yùn)維任務(wù)通過控制臺(tái)就能完成。開發(fā)借助 Serverless 和編排工具就能實(shí)現(xiàn)無服務(wù)端。在未來，無論是前端工程師還是全棧工程師，都將不復(fù)存在，應(yīng)該叫端到端(F2E -> E2E)工程師了。
