擁抱雲時代的前端開發架構——微前端

微前端架構旨在解決單體應用在一個相對長的時間跨度下，由於參與的人員、團隊的增加，從一個普通應用演變成一個巨石應用 (Frontend Monolith)，隨之而來的應用不可維護的問題。這類問題在企業級 Web 應用中尤爲常見。

微前端的價值

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

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

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

  1. 解決產品側的擴展性和組合性。化整爲零，自由組合。

  2. 解決能力輸出的「最後一公里」。

  3. 雲生態中的「新物種」 — 微應用。

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

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

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

微前端的問題域

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

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

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

微前端包括 3 部分：

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

  1. 微應用的註冊、異步加載和生命週期管理；

  2. 微應用之間、主從之間的消息機制；

  3. 微應用之間的安全隔離措施；

  4. 微應用的框架無關、版本無關；

  5. 微應用之間、主從之間的公共依賴的庫、業務邏輯 (utils) 以及版本怎麼管理；

  6. 微應用獨立調試、和主應用聯調的方式，快速定位報錯（發射問題）；

  7. 微應用的發佈流程；

  8. 微應用打包優化問題；

  9. 微應用專有云場景的出包方案；

  10. 漸進式升級：用微應用方案平滑重構老項目。

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

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

微前端的基本原理

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

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

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

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

雲時代的前端開發模式

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

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rYNsKPhw2zR84-4K62gliw

猜你喜歡