微前端熱度不再？qiankun 作者有話說

作者 ｜賈亞甯

嘉賓 ｜劉奎

近年來随着網際網路的飛速發展，很多企業的業務複雜度都會上升，參與業務的人員也越來越多，這帶來了嚴重的維護成本。為了解決這個問題，微前端一度成為技術熱點，各大公司相繼在微前端加大投入。面對微前端在落地實踐中暴露的一些問題，很多公司也相繼提出了解決方案，比如螞蟻集團的 qiankun，京東的 MicroApp 等等。

微前端是一種架構理念，它類似于微服務的架構，将微服務的理念應用于浏覽器端，即将單頁面前端應用由單一的單體應用轉變為把多個小型前端應用聚合為一的應用。各個前端應用還可以獨立開發、獨立部署。微前端聽起來美好，但是在具體的落地過程中會有很多問題：什麼場景适合微前端，如何判斷開展微前端的最佳時機？如何拆分業務最高效？微前端是否勢頭已過，它又将如何發展呢？

出于對以上問題的好奇，我們特地采訪了螞蟻集團體驗技術部前端工程師劉奎老師，同時他也是qiankun 作者，目前在 GitHub 上，qiankun 的 Contributor NO.1，妥妥的開源軟體愛好者。

同時，劉奎老師也是 3 月中旬上線的 QCon+ 案例研習社「微前端架構模式的實踐與探索」專題的講師，帶來了【螞蟻微前端研發模式的産品化探索】的分享。是以我們針對微前端技術的相關問題對劉奎老師進行了采訪，一起來看看他的實踐和思考吧。

InfoQ：你最近在負責什麼樣的工作呢？

劉奎：我目前在螞蟻的工作主要分兩部分：第一部分是和團隊同學一起，去定義螞蟻統一的微前端研發模式。這個研發模式不僅僅是去做一些微前端相關的基礎架構、庫的研發，更包括覆寫整個微應用研發生命周期中的一些産品化的流程設計。比如從一個微應用如何在内部研發平台上建立，到如何描述這個微應用跟其他微應用的關聯關系、怎麼在産品上清晰地表達出來，到如何實作微應用的灰階分發，以及最終上線後的監控、異常應急等能力。總的來講我們在做的是一個針對微前端場景特性的研發平台。

第二部分是基于目前的微前端應用模型，如何将這一套動态化的機制應用到其他的中台場景，進而将我們内部的中台研發模式統一，以便解決其中的一些共性問題。比如中台應用的頁面托管及灰階、應用多環境部署（公有雲、專有雲），這些是不論你是否使用微前端都會需要解決的問題。

InfoQ：在微前端的日常工作中，你有遇到過什麼困難嗎？可以具體分享一下嗎？

劉奎：從我的視角來看，微前端研發中有幾個比較典型，也是我們經常會讨論的問題：第一個是我們要如何對一個巨石應用做拆分，拆分的粒度和邊界是什麼；第二個是多個微應用之間如何去做依賴複用；第三個就是微應用如何治理的問題。

我們先來看第一問題。在對一個巨石應用做微前端拆分時，最常見的粒度是按頁面次元來拆，這通常是沒什麼問題的。但也有一部分場景，我們期望将頁面中某個局部的 UI 抽成一個微應用，供其他應用直接內建複用，這種時候就會比較糾結，到底是該往大了拆還是往小了拆？往大了拆容易出現一些組合場景不好複用進而造成代碼備援，往小了拆則可能導緻微應用之間協作起來特别麻煩，反而降低了開發效率。

這裡面其實涉及到一個問題，就是我們該怎麼劃分微應用的服務邊界。比較合理的方式是按照服務完整性去劃分，看這個微應用是否能獨立地、完整地提供一個服務出來。而不僅僅從前端元件的角度，去是看這個 UI 是不是可複用的。有一個簡單的評估手段：看你的微應用是否需要頻繁跟其他微應用通信？如果答案是肯定的，那你可能就需要考慮下拆分的粒度是否過細了。

第二個問題，也是社群經常會讨論的問題：如何做微應用之間的依賴複用。其實在大部分情況下，這都是一個僞命題，因為複用依賴會導緻微應用之間産生隐性的耦合，進而導緻微應用無法獨立地演進，而這正是與微前端架構背道而馳的。不過目前這個問題也不是無解的，基于 esm/bundless 等手段，我們可以實作微應用獨立運作時使用自有依賴，而被內建時則盡可能複用容器同版本的依賴，不過這個目前社群還未有成熟的方案，我們也正在探索當中。

第三個是微應用的治理問題。當我們在公司内大規模實踐微前端，或者微應用的數量變多、依賴關系變得複雜的時候，就很容易碰到架構治理相關的問題。比如如何確定宿主應用使用到比對環境的微應用資源，而不會因為線上引用了線下的微應用導緻故障；比如如何確定應用之間的高可用等級是對等的，而不會因為一個核心鍊路的應用，依賴了一個低服務級别的應用，而導緻服務經常不可用的問題。要治理這些問題，我們需要盡早地從平台側出發，做相關的研發階段的資料收集跟統計，然後基于這些資料參考，去設計我們體系化的産品及研發思路，從整個平台層面收斂掉研發流程。

InfoQ：你認為哪些場景下适合采用微前端，哪些場景不适合呢？

劉奎：回答這個問題之前，我們可能要先來回答一下微前端解決了什麼問題。

從工程角度來看，微前端其實解決的是在前端技術高速疊代、組織架構頻繁變更的背景下，如何通過一些實體隔離的手段降低系統元件間的耦合，進而確定每個元件的開發獨立、傳遞獨立，進而實作整個系統漸進式演進的能力。

從産品角度來看，微前端解決的是如何在技術棧無感覺的情況下，實作整個産品的平台性及動态性。針對不同的場景及使用者角色，動态地将來自不同系統的服務組裝起來。

明白了這兩個要點，我們就能回答這個問題了，簡單來說就是：

如果你不是要在一個長尾應用上做持續傳遞，你就不需要微前端；如果你的産品都是同一個小的團隊開發的，你就不需要微前端；如果你的産品沒有內建 / 被內建的訴求，你就不需要微前端。反之亦然。