作者 ｜賈亞寧
嘉賓 ｜劉奎
近年來隨著網際網路的飛速發展，很多企業的業務複雜度都會上升，參與業務的人員也越來越多，這帶來了嚴重的維護成本。為了解決這個問題，微前端一度成為技術熱點，各大公司相繼在微前端加大投入。面對微前端在落地實踐中暴露的一些問題，很多公司也相繼提出瞭解決方案，比如螞蟻集團的 qiankun，京東的 MicroApp 等等。
微前端是一種架構理念，它類似於微服務的架構，將微服務的理念應用於瀏覽器端，即將單頁面前端應用由單一的單體應用轉變為把多個小型前端應用聚合為一的應用。各個前端應用還可以獨立開發、獨立部署。微前端聽起來美好，但是在具體的落地過程中會有很多問題：什麼場景適合微前端，如何判斷開展微前端的最佳時機？如何拆分業務最高效？微前端是否勢頭已過，它又將如何發展呢？
出於對以上問題的好奇，我們特地採訪了螞蟻集團體驗技術部前端工程師劉奎老師，同時他也是qiankun 作者，目前在 GitHub 上，qiankun 的 Contributor NO。1，妥妥的開源軟體愛好者。
同時，劉奎老師也是 3 月中旬上線的 QCon+ 案例研習社「微前端架構模式的實踐與探索」專題的講師，帶來了【螞蟻微前端研發模式的產品化探索】的分享。因此我們針對微前端技術的相關問題對劉奎老師進行了採訪，一起來看看他的實踐和思考吧。
InfoQ：你最近在負責什麼樣的工作呢？
劉奎：
我目前在螞蟻的工作主要分兩部分：第一部分是和團隊同學一起，去定義螞蟻統一的微前端研發模式。這個研發模式不僅僅是去做一些微前端相關的基礎框架、庫的研發，更包括覆蓋整個微應用研發生命週期中的一些產品化的流程設計。比如從一個微應用如何在內部研發平臺上建立，到如何描述這個微應用跟其他微應用的關聯關係、怎麼在產品上清晰地表達出來，到如何實現微應用的灰度分發，以及最終上線後的監控、異常應急等能力。總的來講我們在做的是一個針對微前端場景特性的研發平臺。
第二部分是基於目前的微前端應用模型，如何將這一套動態化的機制應用到其他的中臺場景，進而將我們內部的中臺研發模式統一，以便解決其中的一些共性問題。比如中臺應用的頁面託管及灰度、應用多環境部署（公有云、專有云），這些是不論你是否使用微前端都會需要解決的問題。
InfoQ：在微前端的日常工作中，你有遇到過什麼困難嗎？可以具體分享一下嗎？
劉奎：
從我的視角來看，微前端研發中有幾個比較典型，也是我們經常會討論的問題：
第一個是我們要如何對一個巨石應用做拆分，拆分的粒度和邊界是什麼；第二個是多個微應用之間如何去做依賴複用；第三個就是微應用如何治理的問題。
我們先來看第一問題。在對一個巨石應用做微前端拆分時，最常見的粒度是按頁面維度來拆，這通常是沒什麼問題的。但也有一部分場景，我們期望將頁面中某個區域性的 UI 抽成一個微應用，供其他應用直接整合複用，這種時候就會比較糾結，到底是該往大了拆還是往小了拆？往大了拆容易出現一些組合場景不好複用從而造成程式碼冗餘，往小了拆則可能導致微應用之間協作起來特別麻煩，反而降低了開發效率。
這裡面其實涉及到一個問題，就是我們該怎麼劃分微應用的服務邊界。比較合理的方式是按照服務完整性去劃分，看這個微應用是否能獨立地、完整地提供一個服務出來。而不僅僅從前端元件的角度，去是看這個 UI 是不是可複用的。有一個簡單的評估手段：
看你的微應用是否需要頻繁跟其他微應用通訊？如果答案是肯定的，那你可能就需要考慮下拆分的粒度是否過細了。
第二個問題，也是社群經常會討論的問題：如何做微應用之間的依賴複用。其實在大部分情況下，這都是一個偽命題，因為複用依賴會導致微應用之間產生隱性的耦合，進而導致微應用無法獨立地演進，而這正是與微前端架構背道而馳的。不過目前這個問題也不是無解的，基於 esm/bundless 等手段，我們可以實現微應用獨立執行時使用自有依賴，而被整合時則儘可能複用容器同版本的依賴，不過這個目前社群還未有成熟的方案，我們也正在探索當中。
第三個是微應用的治理問題。當我們在公司內大規模實踐微前端，或者微應用的數量變多、依賴關係變得複雜的時候，就很容易碰到架構治理相關的問題。比如如何確保宿主應用使用到匹配環境的微應用資源，而不會因為線上引用了線下的微應用導致故障；比如如何確保應用之間的高可用等級是對等的，而不會因為一個核心鏈路的應用，依賴了一個低服務級別的應用，而導致服務經常不可用的問題。要治理這些問題，我們需要儘早地從平臺側出發，做相關的研發階段的資料收集跟統計，然後基於這些資料參考，去設計我們體系化的產品及研發思路，從整個平臺層面收斂掉研發流程。
InfoQ：你認為哪些場景下適合採用微前端，哪些場景不適合呢？
劉奎：
回答這個問題之前，我們可能要先來回答一下微前端解決了什麼問題。
從工程角度來看，微前端其實解決的是在前端技術高速迭代、組織架構頻繁變更的背景下，如何透過一些物理隔離的手段降低系統元件間的耦合，從而確保每個元件的開發獨立、交付獨立，進而實現整個系統漸進式演進的能力。
從產品角度來看，微前端解決的是如何在技術棧無感知的情況下，實現整個產品的平臺性及動態性。針對不同的場景及使用者角色，動態地將來自不同系統的服務組裝起來。
明白了這兩個要點，我們就能回答這個問題了，簡單來說就是：
如果你不是要在一個長尾應用上做持續交付，你就不需要微前端；如果你的產品都是同一個小的團隊開發的，你就不需要微前端；如果你的產品沒有整合 / 被整合的訴求，你就不需要微前端。反之亦然。