未來，僅憑幾個前端工程師，就能 hold 住一家企業嗎？
微前端架構旨在解決單體應用在一個相對長的時間跨度下，由于參與的人員、團隊的增加，從一個普通應用演變成一個巨石應用(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)工程師了。
