阿裡妹導讀：微前端架構旨在解決單體應用在一個相對長的時間跨度下，由于參與的人員、團隊的增加，從一個普通應用演變成一個巨石應用(Frontend Monolith)，随之而來的應用不可維護問題。這類問題在企業級 Web 應用中尤為常見。今天，我們就來聊聊擁抱雲時代的前端開發架構：微前端。
微前端的價值
阿裡雲提供的很多商業化産品和服務，本質上是對外提供「能力」，普惠中小企業。目前，能力輸出主要是通過 OpenAPI，用以內建到企業自己的業務場景中，這裡主要解決的還是企業底層的能力問題——無需雇傭算法工程師，就可以擁有語音、圖像識别等能力。安全也是一樣，不需要找安全專家，普通的工程師就可以通過控制台高效地處理各種安全事件。
但是，随着雲技術不斷的下沉，與産業結合的越來越緊密，OpenAPI 唯有把粒度做得越來越細，才能滿足各種各樣的業務場景，但同時企業側的學習成本和開發複雜度自然就上去了。控制台做為管（理）控（制）這些能力的工具，目前也隻能算是「标品」，必須為了滿足不同體量、不同業務特點的需求，靈活地組合和部署，就像是使用者自己開發的一樣。
綜上所述，微前端的價值有 3 點：
- 解決産品側的擴充性群組合性。化整為零，自由組合。
- 解決能力輸出的「最後一公裡」。
- 雲生态中的「新物種」 — 微應用。
如果微前端隻存在工程上的價值，那它是不值得大張旗鼓去做的。
我認為，前端團隊需要在這個方面做出業務價值。如果你問我 Ant Design 有什麼技術價值？它的價值就是有大量的企業在用，形成某種能力依賴，不需要找設計師或者多麼資深的前端工程師，就可以做出看上去很專業的背景界面。
在這條價值鍊路上，OpenAPI 太底層，控制台不靈活，UI 庫太通用。其中的空白點是綁定能力的商業化元件。舉個例子，企業的背景管理頁上，可以直接 inside 一個「漏洞管理」的微前端應用，和一個 DataV 的微前端應用展示資料，隻需要簡單配一下即可，不用開發，就能做到“就像自己開發的一樣”。反過來也一樣，ISV 在阿裡雲的産品平台上，不僅可以通過小程式的形式，也可以通過微前端應用的形式輸入自己的服務。
微前端的問題域
簡單地說，搞微前端目的就是要将産品原子化（跟原子化的 OpenAPI 一個道理），再根據客戶業務場景組合。每個功能子產品能單獨疊代，自由內建當然好，但維護成本怎麼控制。怎麼調試、公共元件版本控制、衆多同窗微應用之間怎麼“和諧相處”等等。微前端并非隻是解決在頁面上異步加載一個子產品就完事了，更多的是将改造引發的一系列問題需要通過體系化的方案解決，否則就變成反生産力工具。
目前，阿裡的微前端方案有 qiankun(乾坤)、Magix、icestack、以及内部很多的微前端解決方案。或多或少都帶有一些自身的業務特色，沒有明确提出标準，或者明确定義微前端的技術體系到底包含哪些内容。這方面有項目落地的團隊真應該再進一步瞄準更高的價值點做，同時廣泛交流，這樣才能更快得出标準化的東西。我們團隊也在實踐中，這裡我抛出一些開放性問題讨論。
首先必須明确微前端不是架構、不是工具/庫，而是一套架構體系，它包括若幹庫、工具、中心化治理平台以及相關配套設施。
微前端包括 3 部分：
- 微前端的基礎設施。這是目前讨論得最多的，一個微應用如何通過一個元件基座加載進來、腳手架工具、怎麼單獨建構和部署、怎麼聯調。
- 微前端配置中心：标準化的配置檔案格式，支援灰階、復原、紅藍、A/B 等釋出政策。
- 微前端的可觀察性工具：對于任何分布式特點的架構，線上/線下治理都很重要。
微前端具體要解決好的 10 個問題：
- 微應用的注冊、異步加載和生命周期管理；
- 微應用之間、主從之間的消息機制；
- 微應用之間的安全隔離措施；
- 微應用的架構無關、版本無關；
- 微應用之間、主從之間的公共依賴的庫、業務邏輯(utils)以及版本怎麼管理；
- 微應用獨立調試、和主應用聯調的方式，快速定位報錯（發射問題）；
- 微應用的釋出流程；
- 微應用打包優化問題；
- 微應用專有雲場景的出包方案；
- 漸進式更新：用微應用方案平滑重構老項目。
通過問題了解問題是一種思考方式，相信大家能溝通通過微前端三大組成部分和它要解決的 10 個問題，能夠有一個大概的了解。下面，看一下我歸納的微前端的架構體系（如圖）：
通過上圖，很明顯的看出前後端分工，以及線上微應用相關配置流程。整體運作環境以及開發流程是非常複雜的，留到大會的時候再詳細講解。
微前端的基本原理
如下圖所示，微前端的工程化是從傳統前端工程化體系更新上來的。
比如建構，增加微應用類型的項目建構，有動态的打包政策。傳統項目管理工具通常是指令行工具，包括建構、釋出、測試，會更新為項目工作台，通過 Web 界面管理項目。一個項目包括哪些微應用，版本，釋出政策等在配置中心統一管理。一個大型應用被「碎片化」後，還要能做到「一目了然」。哪個子產品報錯，加載失敗等異常發生第一時間反應在配置中心裡。
下面的原型圖，就是一個最基本的配置中心的樣貌。微前端體系要可控、可觀察。
通過多個微應用的組合，能夠在變化如此複雜的需求中，更好的更快的賦能業務。
雲時代的前端開發模式
前端開發從 PC 時代到移動時代，從刀耕火種的原始運維到雲計算時代，回顧起來，我們會發現——開發模式跟時代背景真是密不可分。前端奮鬥 20 年才把頁面寫好，而現在又變成「切頁面」了，隻是此「切」非彼「切」。雲時代的開發模式注定是「碎片化」的，開發是面向子產品的，而頁面隻是一種組合場景，一種運作時容器。
我想，未來的産品開發主要時間是在「編排」——編排服務、編排邏輯、編排元件、編排通路政策、編排流程。到了雲時代，一家企業隻要招幾個前端工程師就可以了，兼顧開發和運維、資産全部上雲，運維任務通過控制台就能完成。開發借助 Serverless 和編排工具就能實作無服務端。在未來，無論是前端工程師還是全棧工程師，都将不複存在，應該叫端到端(F2E -> E2E)工程師了。
原文釋出時間：2019-12-30
作者：克軍
本文來自阿裡雲合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。