簡介： 微前端架構旨在解決單體應用在一個相對長的時間跨度下，由于參與的人員、團隊的增加，從一個普通應用演變成一個巨石應用(Frontend Monolith)，隨之而來的應用不可維護問題。這類問題在企業(yè)級 Web 應用中尤為常見。今天，我們就來聊聊擁抱云時代的前端開發(fā)架構：微前端。

作者 | 克軍

?阿里妹導讀：微前端架構旨在解決單體應用在一個相對長的時間跨度下，由于參與的人員、團隊的增加，從一個普通應用演變成一個巨石應用(Frontend Monolith)，隨之而來的應用不可維護問題。這類問題在企業(yè)級 Web 應用中尤為常見。今天，我們就來聊聊擁抱云時代的前端開發(fā)架構：微前端。

?

微前端的價值

阿里云提供的很多商業(yè)化產(chǎn)品和服務，本質上是對外提供「能力」，普惠中小企業(yè)。目前，能力輸出主要是通過 OpenAPI，用以集成到企業(yè)自己的業(yè)務場景中，這里主要解決的還是企業(yè)底層的能力問題——無需雇傭算法工程師，就可以擁有語音、圖像識別等能力。安全也是一樣，不需要找安全專家，普通的工程師就可以通過控制臺高效地處理各種安全事件。

但是，隨著云技術不斷的下沉，與產(chǎn)業(yè)結合的越來越緊密，OpenAPI 唯有把粒度做得越來越細，才能滿足各種各樣的業(yè)務場景，但同時企業(yè)側的學習成本和開發(fā)復雜度自然就上去了。控制臺做為管（理）控（制）這些能力的工具，目前也只能算是「標品」，必須為了滿足不同體量、不同業(yè)務特點的需求，靈活地組合和部署，就像是用戶自己開發(fā)的一樣。

綜上所述，微前端的價值有 3 點：

解決產(chǎn)品側的擴展性和組合性。化整為零，自由組合。
解決能力輸出的「最后一公里」。
云生態(tài)中的「新物種」 — 微應用。

如果微前端只存在工程上的價值，那它是不值得大張旗鼓去做的。

我認為，前端團隊需要在這個方面做出業(yè)務價值。如果你問我 Ant Design 有什么技術價值？它的價值就是有大量的企業(yè)在用，形成某種能力依賴，不需要找設計師或者多么資深的前端工程師，就可以做出看上去很專業(yè)的后臺界面。

在這條價值鏈路上，OpenAPI 太底層，控制臺不靈活，UI 庫太通用。其中的空白點是綁定能力的商業(yè)化組件。舉個例子，企業(yè)的后臺管理頁上，可以直接 inside 一個「漏洞管理」的微前端應用，和一個 DataV 的微前端應用展示數(shù)據(jù)，只需要簡單配一下即可，不用開發(fā)，就能做到“就像自己開發(fā)的一樣”。反過來也一樣，ISV 在阿里云的產(chǎn)品平臺上，不僅可以通過小程序的形式，也可以通過微前端應用的形式輸入自己的服務。

?

微前端的問題域

簡單地說，搞微前端目的就是要將產(chǎn)品原子化（跟原子化的 OpenAPI 一個道理），再根據(jù)客戶業(yè)務場景組合。每個功能模塊能單獨迭代，自由集成當然好，但維護成本怎么控制。怎么調試、公共組件版本控制、眾多同窗微應用之間怎么“和諧相處”等等。微前端并非只是解決在頁面上異步加載一個模塊就完事了，更多的是將改造引發(fā)的一系列問題需要通過體系化的方案解決，否則就變成反生產(chǎn)力工具。

目前，阿里的微前端方案有 qiankun(乾坤)、Magix、icestack、以及內部很多的微前端解決方案。或多或少都帶有一些自身的業(yè)務特色，沒有明確提出標準，或者明確定義微前端的技術體系到底包含哪些內容。這方面有項目落地的團隊真應該再進一步瞄準更高的價值點做，同時廣泛交流，這樣才能更快得出標準化的東西。我們團隊也在實踐中，這里我拋出一些開放性問題討論。

首先必須明確微前端不是框架、不是工具/庫，而是一套架構體系，它包括若干庫、工具、中心化治理平臺以及相關配套設施。

微前端包括 3 部分：

微前端的基礎設施。這是目前討論得最多的，一個微應用如何通過一個組件基座加載進來、腳手架工具、怎么單獨構建和部署、怎么聯(lián)調。
微前端配置中心：標準化的配置文件格式，支持灰度、回滾、紅藍、A/B 等發(fā)布策略。
微前端的可觀察性工具：對于任何分布式特點的架構，線上/線下治理都很重要。

微前端具體要解決好的 10 個問題：

微應用的注冊、異步加載和生命周期管理；
微應用之間、主從之間的消息機制；
微應用之間的安全隔離措施；
微應用的框架無關、版本無關；
微應用之間、主從之間的公共依賴的庫、業(yè)務邏輯(utils)以及版本怎么管理；
微應用獨立調試、和主應用聯(lián)調的方式，快速定位報錯（發(fā)射問題）；
微應用的發(fā)布流程；
微應用打包優(yōu)化問題；
微應用專有云場景的出包方案；
漸進式升級：用微應用方案平滑重構老項目。

通過問題理解問題是一種思考方式，相信大家能溝通通過微前端三大組成部分和它要解決的 10 個問題，能夠有一個大概的理解。下面，看一下我歸納的微前端的架構體系（如圖）：

通過上圖，很明顯的看出前后端分工，以及線上微應用相關配置流程。整體運行環(huán)境以及開發(fā)流程是非常復雜的，留到大會的時候再詳細講解。

?

微前端的基本原理

如下圖所示，微前端的工程化是從傳統(tǒng)前端工程化體系升級上來的。

比如構建，增加微應用類型的項目構建，有動態(tài)的打包策略。傳統(tǒng)項目管理工具通常是命令行工具，包括構建、發(fā)布、測試，會升級為項目工作臺，通過 Web 界面管理項目。一個項目包括哪些微應用，版本，發(fā)布策略等在配置中心統(tǒng)一管理。一個大型應用被「碎片化」后，還要能做到「一目了然」。哪個模塊報錯，加載失敗等異常發(fā)生第一時間反應在配置中心里。

下面的原型圖，就是一個最基本的配置中心的樣貌。微前端體系要可控、可觀察。

通過多個微應用的組合，能夠在變化如此復雜的需求中，更好的更快的賦能業(yè)務。

?

云時代的前端開發(fā)模式

前端開發(fā)從 PC 時代到移動時代，從刀耕火種的原始運維到云計算時代，回顧起來，我們會發(fā)現(xiàn)——開發(fā)模式跟時代背景真是密不可分。前端奮斗 20 年才把頁面寫好，而現(xiàn)在又變成「切頁面」了，只是此「切」非彼「切」。云時代的開發(fā)模式注定是「碎片化」的，開發(fā)是面向模塊的，而頁面只是一種組合場景，一種運行時容器。

我想，未來的產(chǎn)品開發(fā)主要時間是在「編排」——編排服務、編排邏輯、編排組件、編排訪問策略、編排流程。到了云時代，一家企業(yè)只要招幾個前端工程師就可以了，兼顧開發(fā)和運維、資產(chǎn)全部上云，運維任務通過控制臺就能完成。開發(fā)借助 Serverless 和編排工具就能實現(xiàn)無服務端。在未來，無論是前端工程師還是全棧工程師，都將不復存在，應該叫端到端(F2E -> E2E)工程師了。

?

總結

以上是生活随笔為你收集整理的未来，仅凭几个前端工程师，就能 hold 住一家企业吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。