不少前端團隊都面臨着獨石應用的工程巨大、理解困難和合作混亂的種種問題，微前端或許是一種比較好的解決方案，它允許我們爲應用加入新功能而不影響整體結構。但同時，我們可能會付出一些代價，例如重複依賴、團隊自治帶來的工作方式分散等問題。採用微前端具體有哪些風險與挑戰？我們應該如何應對？如何判斷自己的團隊是否適合微前端？不妨來看看字節跳動在落地微前端的過程中的踩坑填坑經驗。
許多企業都從微服務中嚐到了甜頭，但是你是否想過，微服務模式的火在某一天也會燒到前端？
2019年4月，ThoughtWorks技術雷達將微前端納入了ADOPT階段，該階段代表ThoughtWorks認爲該項技術或者模式值得被行業採用。
在微前端方案中，Web 應用程序被分拆爲多個模塊，每個模塊可以獨立開發、部署和測試。好處顯而易見，與微服務相似，鬆耦合允許我們更改一個模塊而不影響其他模塊，微前端可以減少團隊間的依賴，增加靈活性。但缺陷也十分明顯，作爲一個更分散的架構，微前端不可避免地導致我們需要管理更多的庫和工具，這增加了運維複雜性。另外，如果不同開發團隊使用不同的技術棧，也會帶來許多複雜的問題。
字節跳動微服務前端解決方案，經過幾年發展已經成功支持了幾十個對內和對外的系統，在此過程中，他們收穫了哪些果實？遇到了哪些難點？具體如何應對？帶着這些問題，InfoQ 採訪了字節跳動前端工程師艾石光，希望能給即將或正在走上微前端之路的你帶來一些可參考經驗。
微前端初探
InfoQ：什麼是微前端？
艾石光：微前端的理念就是用微服務的模型去重構前端工程。微服務是一種設計模式，已經作爲在軟件工程行業近年發展最快的趨勢和特徵，被充分驗證過和實踐過了。也深入影響了從語言到環境的方方面面。但是在前端工程裏，瀏覽器是一個很獨特的運行時環境，和部署在操作系統上的服務端應用有不小的區別。前端目前有種種隔離技術在快速發展、有一些方便模擬操作系統性質的實踐，但還沒有對應的底層機制，也沒有可以達成標準級別的整體進展。微前端是在享用和微服務相同的工程理論的成果的同時用適應前端特徵的方式去做微服務化。
InfoQ：微前端的實現方式是？有哪些技術棧？
艾石光：作爲微服務模式的一個特殊發展，前端微服務可以有很多不同的導向。例如有些側重優雅耦合有些重視運行時隔離。從具體的組成部分來說，很多環節都有多種方案可以取捨。
對前端運行時架構來說，有幾種不同的沙盒組織方式，例如變量守護、IIFE、利用 prototype 鏈條包裝 global 等。對 CSS 隔離與複用架構來說，還可以用 shadow DOM、CSS Module 等。
對服務發現和託管部署服務，可以用流量層打通和額外 list 接口等。
對應到開發環境和調試服務，同樣有很多的調試測試解決方案、工具集，具體可以在演講中討論。
InfoQ：近兩年，組件化開發非常火，有些團隊會藉助 Web Components 通過一種標準化的非侵入的方式封裝一個組件，來構建跨框架的前端應用。您怎麼看待 Web Components ？
艾石光：Web Component 作爲前端 DOM 層的一種拆分和隔離機制，其實是一個很有效的技術方案。我們的設計裏也在儘可能的吸收這方面的理念和技術。進而把“前端”作爲整個工程來說時，獨立和隔離只是衆多議題中的一步，還涉及到通信、複用、多態等諸多環境。同樣重要的還有框架同構和異構、環境一致、服務發現和治理等等。這些需要更精細更成體系的工程模型來協調處理。
微前端在字節跳動的落地
InfoQ：字節跳動爲什麼要採用微前端？
字節跳動的一些業務例如頭條號，很久之前就發展到一個代碼倉庫龐大到發佈時間超過半個小時、新人加入非常難上手的程度了，也一直在摸索各種解決方案、組織方法。在 2 年前剛好遇到業務發展產生了一個新的時機：這個項目開始需要跨大團隊的組織協同，多個團隊一起建設。這些合作的開發者來自不同結構、不同流程、甚至不同地區的組織。這時再一起來合作同一個前端項目，如何高效的拆分、優雅的複用等等工程問題成了解決效率敞口最重要的手段。
InfoQ：微前端最適合的落地場景是？
艾石光：前端微服務最明顯最適合落地的場景是各種中後臺項目，尤其是那些傳統的 iframe 工程。實際試用過 frames 開發架構的同學會知道真的使用時，如何打造實用可理解的 deeplink 就已經很麻煩了。況且還有很多技術細節。比如那些底層複用、父子通信、session 打通、服務發現等。實際上已經默默承受了很多在微服務裏解決得很好且最終效果可以好得多的問題。
前端微服務需要解決的難題涵蓋了從集成開發環境到服務轉移到部署和流量識別和承載的後端架構，具體涉及到的面很廣，細節還是很多的。
我們團隊把前端微服務抽象成了服務發現、運行隔離和環境一致三個方面，分別對應了了從開發到發佈到線上運行的全部環節。
InfoQ：落地微前端的過程中，你們收穫了哪些好處？
艾石光：最大的好處肯定是開發效率上的，很多多餘的認知成本、協作成本都被消除了。
其次是上下線的效率提高了非常多。之前的統一發布模式需要耗費 30 分鐘上線、10 分鐘回滾，這很難適應一些業務變化。例如頭條號平臺從 19 年到今天各模塊共有 4292 次創建版本，這些版本還會組合出無窮種 A/B 測試的可能。這些都是傳統的發佈管理機制很難勝任的。
在工程質量上，通過微服務化有很多底層/中臺能力都可以由 masterpage 內置，有一些數據採集和回收可以在服務發現平臺上佈置，例如 sourceMap 的權限管理、console log 的回收都可以統一由 masterpage 安排、業務方無感知。這都是一些收穫。
InfoQ：採用微前端有哪些風險與挑戰？
艾石光：前端微服務整體上的安全性和可控性還是比較不錯的。但是如前面所述目前還沒有標準和底層深入支持，所以也新產生了很多獨特挑戰需要去應對。我覺得最值得提的新引入風險還是來自開發調試過程。
我們認爲 docker 等技術是服務端微服務的一個重要優勢，容器技術的成熟使微服務在線上線下有非常一致的環境表現。而前端更接近非容器的、類似於各種 BaaS 的模式。像 firebase、GAE 等不借助容器的微服務體系都有整套的調試解決方案和運行監控數據回收方案，可以保證部署前有條件充分調試，也有可靠的測試，能先測試再部署。而微前端的本地開發的環境與調試用的代碼和最終上線運行會有不小的區別。不僅如此，線上合併後的環境變化極快，其他平行的模塊加起來更新頻率非常高。所以這時發現和復現問題都是一個重要的環節。
我們也提供了很深入的解決方案，投入了很大的研發精力去應對這個挑戰。我們建設了完整的開發鏈工具，比如配置代碼的修復和消毒，還有融合雲打包的腳本植入、自動化驗證等。調試方面有整套的代理服務植入到開發環境的瀏覽器內，有獨立的調試命令也有充分與 webpack-dev-server 結合的方式。這些一起實現了讓使用者開發時，雖然寫的代碼僅僅是寄生在 masterpage 內的代碼片段，但是開發體驗幾乎和傳統的頁面開發完全一致、開發環境看到的運行表現也幾乎完全模擬線上。
其次是服務發現過程的模塊上下線，是一個需要小心對待的需要極高可用性的中心繫統。對此我們做了從 ETCD、Redis 到前端 localstorage 的多層容災。爲了更好地支撐流量，我們還在進一步嘗試更多的部署架構。
另外我們也做了更詳細的線上錯誤回收，並且打通到了用戶反饋系統。在我們微服務框架裏的 console log 都會被收集和整理，並且一起儲存時會自動裝載上 call stack。
我們真的需要微前端嗎？
InfoQ：微前端不一定適合每一個人，我們必須根據自身的情況仔細權衡。您認爲什麼樣的團隊或項目可以嘗試使用微前端呢？
艾石光：從技術角度上說如果你開始觀察到工程的組織需要費心去設計才能繼續保證直觀和優雅，尤其是對非主要作者的開發者來說，如果必須要額外的交流介紹、探討、商量、協調，才能解釋清楚一個項目的設計思路和構造，就應該開始考慮用不同級別的拆分模型來處理你的項目了。
如果你的團隊有技術異構的訴求，例如不同的編譯機制、不同的邏輯層實現、不同的展示層框架，又不希望降低項目的複用度和運行時的流暢，也可以考慮以解耦的角度去嘗試微服務。
最後一個更普遍的情況是，如果你的項目上線非常頻繁，變化很多，大量的時間消耗在反覆的編譯、部署裏，對應的一定有更多的時間消耗在單測和驗收過程。這時也建議從微服務角度去重新考慮。
採訪嘉賓：艾石光，字節跳動前端工程師，加入字節跳動以來一直致力於發展和建設前端基礎工程，包括基礎設施建設、業務工程與過程的改進和打磨。與團隊一起，在爲公司業務提供中臺產品的同時，也在努力提升公司前端團隊的研發效率與工程質量。至今，已經成功打造了微服務技術體系、富媒體中臺框架、服務遷移工具等產品。艾石光一直活躍在前端開發領域，在加入字節跳動之前，曾經在阿里巴巴和 CRIC 等企業參與前端開發，有豐富的工程化產品、技術中臺和研發框架的打造經驗。他將在 QCon上海2019 作題爲《前端微服務在字節跳動的打磨與應用》的演講，帶你瞭解微服務在成熟產品上的實踐、發展歷程和逐年打磨沉澱的技術細節，點擊瞭解詳情。