得物效率前端微應用推進過程與思考
一、背景
效率工程
隨著業務的發展，組織規模的擴大，越來越多的企業開始意識到協作效率對于企業團隊的重要性，甚至是決定其在某個行業競爭中突圍的關鍵，是企業長久生存的根本。
得物效率工程運用產品、技術、數據等手段，全面提升公司的效率。在管理效率、協同效率、跨團隊溝通效率、產研協作效率、辦公效率等各方面持續探索，高效驅動公司發展。
效率工程的業務場景
上面提到，效率工程為提升企業協作效率而生，因此會面臨大量中后臺應用場景。
這些中后臺應用體現為「PC 站點、H5 站點、飛書應用、特定機器環境」等，面向所有內部員工和部分外部用戶。
在面向多類型用戶和使用場景等條件下，效率工程技術產品在穩定性、體驗、擴展性等方面面臨的挑戰非常多。
效率工程面臨的問題
效率工程主要的業務形態是「PC 站點的大型中后臺應用」，此類應用的布局大多數是這樣的：
圖片
針對這類場景，有此類產品研發經驗的同學，對其面對的問題也會比較熟悉：
- 依賴管理方面。非 monorepo 類倉庫下，對于只有一個 package.json 對依賴管理，底層依賴如 antd 等版本升級困難，因為回歸成本很高。
a.個別底層依賴的升級是難以避免的，尤其是涉及穩定性、可維護性、用戶體驗方面，在某個節點會爆發問題影響線上
- 代碼耦合度方面。微前端下，如果沒有做好抽象，基座和子應用的代碼耦合度容易偏高。
- 基座通常包括：Layout、權限控制等通用模塊難免的，在基座中可能包括對特定頁面的處理邏輯，這里不再舉例
- 業務投放成本方面。有些業務的內容區非常適合投放到多個平臺，但通常情況下中后臺應用代碼的布局和內容部分是強耦合的。單獨將內容區域投放到外部平臺，要一個個處理，成本很高。
- 比如某個重報表類平臺，其報表展示能力能否應用在更多平臺上，其投放能力是最重要的影響因素
經過調研后，我們引入微應用來解決目前遇到的問題：
微應用
一個基于“monorepo & 微前端 & 基座與業務分離”的、包括“文檔 & 工具”的一套體系化降低研發成本和提升用戶體驗的技術產品。
這是面向得物效率工程業務場景下，我們對微應用的定義。
系統案例：得物學習平臺
得物效率工程的學習平臺，是面向得物員工、勞務人員、鑒別師、客服等人群的大型中后臺應用，產品形態是 PC / H5 / 飛書應用等。是非常典型的適用于「微應用」推進的項目。
圖片
依賴管理方面
學習平臺原來是非 monorepo 結構，只用一個 package.json 做依賴管理，底層依賴 antd 等的版本極難更新，很難享受到最新版本的快樂。
代碼耦合度方面
學習平臺 Layout 和各個頁面內容部分代碼是強耦合的，Layout 中也有部分頁面的業務邏輯。
業務投放成本方面
學習平臺的多個頁面對外投放是整體性投放，需要對 Layout 做特殊處理、權限特殊處理等方式處理后，才能開始投放，投放成本高，而且投放方案不通用。
二、問題分析
Why：為什么做？為什么這樣做？
- 中后臺應用越來越臃腫已成為共識
- 中后臺需要在功能越來越多的情況下，輕量化地迭代
- monorepo 配合微前端，是中后臺應用輕量化迭代的有效方案
Who: 用戶是誰？
- 業務前端：能夠快速理解遷移方案、低成本使用配套工具完成遷移、有充分的 Q/A 文檔介紹
- Leader：能夠通過看板等產品、結合指標，快速判斷遷移后的工程質量，在長期維護狀態下保證工程質量不快速下降
What：做什么？
- 最佳實踐文檔：面向業務前端，要求通俗易懂，業務前端可以在 0.5D 內快速理解整個方案
- 遷移工具：提供一個工具，幫助開發者快速完成遷移
- 巡檢看板：查看各類指標，如依賴版本是否過期、公共模塊位置是否合理等
When：什么時候做？
- 一個中后臺項目子應用超過 X 個，感官越來越臃腫的情況下，可以考慮做微應用化了
- 想在中后臺項目前期打好基礎，便于后續迭代提效，可以考慮使用微應用了
Where：在哪里做？
- 解釋：很顯然這不是在說物理位置，在研發流程中，這個工具該處于什么位置
- 遷移中：在業務開發者本機執行遷移動作、飛書文檔完成背景介紹
- 遷移后：有在線的巡檢平臺可以：執行巡檢、查看巡檢報告
How：如何做？
- 要同時進行 monorepo 化和微前端化，工作量大、操作復雜、穩定性保障難度大
- 第 1 步：以 1 個項目試點，跑通流程、輸出“最佳實踐（初版）”、輸出“遷移工具（初版）”
- 第 2 步：以 1 個項目驗證全套方案，輸出“最佳實踐（修正版）”、輸出“遷移工具（修正版）”
- 第 3 步：以 1 個項目完成全套方案，輸出“最佳實踐（完整版）”、輸出“遷移工具（完整版）”
- 第 4 步：更多項目接入
三、明確目標
根據 SMART 原則，我們制定了如下目標（時間限制在 3 個月內）：
1. 降低微應用化遷移成本，中大型應用的微應用化遷移耗時降低 30%
耗時降低計算公式：1 - (有 SOP 時微應用化遷移估時 / 無 SOP 時微應用化遷移估時)
2. 降低學習平臺維護成本，管理端和學員端公共依賴升級時的測試耗時降低 50%
耗時降低計算公式：1 - (微應用化后的測試估時 / 微應用化前的測試估時)
四、推進方案
經過以上分析，我們的推進方案在「輸出、里程碑、技術架構、測試方案、效果預估」等方面進行了確認。
輸出
1. 面向業務開發者
a.《效率前端微應用最佳實踐》文檔：幫助業務開發者可以在 0.5D 理解遷移所需的各類背景
b.「微應用遷移技術產品 monopower」：幫助業務開發者完成應用 monorepo 化過程 90% 的工作量
2. 面向 Leader
a.「在線巡檢能力和報告」：幫助 Leader 查看項目完成微應用遷移后，工程質量是如何的，這里包括了一系列的指標
里程碑
圖片
如上圖，里程碑整體分為 2 個階段：
第一階段，通過業務的少量落地完成方案驗證，側重在驗證
第 1 步：以 1 個項目試點，跑通流程、輸出“最佳實踐（初版）”、輸出“遷移工具（初版）”，落地 1 ~ 2 個頁面
第 2 步：以 1 個項目驗證全套方案，輸出“最佳實踐（修正版）”、輸出“遷移工具（修正版）”，落地 3 ~ 10 個頁面
第二階段，業務全量遷移，側重在業務落地
以 1 個項目完成全套方案，輸出“最佳實踐（完整版）”、輸出“遷移工具（完整版）”，落地該應用全部頁面
技術架構
1. 迪米特法則
即最小知識原則，在 SOLID 設計原則中符合 「Single，單一職責；Open-Close：開閉原則」的思想。
我們在考慮微應用技術架構所具備的特征時，更注重簡單、可靠、閉環，也就是迪米特法則。
簡單：輸出的技術產品和文檔，需要面向真正用戶，易于理解，使用門檻低
可靠性：業內微前端產品（qiankun / wujie / micro-app / ...）對比，各自的優缺點，是否滿足業務需求
閉環：當項目進行微應用化后，定時巡檢和告警會觸發運行，定期掃描工程質量并通知到相關方
2. 整體架構
圖中綠色區域是需要開發的產品或文檔。
圖片
整體架構包括以下核心模塊：
a.新增微應用倉庫
不在老倉庫進行微應用化改造，保證穩定性。
b.monopower cli/server
i.一鍵改造非 monorepo 項目為 monorepo 項目
圖片
ii.掃描項目質量，并輸出報告和告警
圖片
c.微應用遷移最佳實踐文檔
3. 一鍵 monorepo 化
轉換過程
- 對原工程做「基于 AST 或正則」的依賴分析
- 調整目錄結構為 monorepo
- 對新工程中代碼做「基于 AST 或正則」的引用路徑修正
比如，原工程中有 import utils from '@/utils'，新工程可能需要變為 import utils from '@monorepo/utils'
圖片
技術實現
a.對原工程做依賴解析后，會生成包含依賴樹的 json 文件存儲在本地
b.基于 json 文件 和 monorepo 結構規范，生成新的 monorepo 化的工程結構
c.基于 json 文件和 monorepo 結構規范，對新的 monorepo 化的工程中的引用路徑做修正
圖片
多次 monorepo 化
由于學習平臺的微應用化持續近 3 個月，期間會經歷多次迭代。
比如 A/B/C 3 個頁面是待微應用化的頁面，用 3 個迭代分別對 A/B/C 3 個頁面進行微應用化。
那么，A 頁面上線后，假如第二個迭代，原倉庫依然需要對 A 頁面修改，就意味著，第二個迭代要同時上線 A/B 頁面。
為了減少回歸測試成本，我們用 monopower transfer 做了一個轉換后的 diff 展示，如果 A 頁面在兩次迭代被進行了兩次 transfer，且 diff 沒有變化，就不需要回歸測試。
測試方案
1. 兩個方案
a. 以單個路由為粒度，每次全量切換該路由的流量到微應用版本 b. 以整個工程為粒度，按照人群/流量分布為維度，定向灰度到微應用版本
2. 選定方案
最終我們用第一個測試方案。原因如下：
a. 學習平臺是微應用推進的第一個驗證型項目，短時間內全量完成改造的難度太大
b. 以單個路由為粒度，能夠逐步修復問題，驗證整體方案的可行性
3. 應用效果
使用第一個方案，在整個微應用落地過程中是比較順利的，平穩地將近 40 個頁面逐批次切換到微應用模式。
這里也頻繁用到了「推進方案 -- 技術架構 -- 一鍵 monorepo 化」中提到的“多次 monorepo 化”，利用 monopower transfer 的 diff 結果，來減少回歸測試成本。
效果評估
1. 學習平臺改造前后的工程結構對比
改造前：
圖片
改造后：
圖片
2. 遷移前
系統自檢：
圖片
3. 遷移中
遷移步驟：
i.安裝命令行 monopower
ii.在當前項目執行 monopower transfer，執行 monorepo 化
iii.逐個頁面測試
圖片
正向依賴分析：
比如入口文件 index.tsx，可以基于該入口文件做依賴樹的可視化分析
圖片
反向依賴分析：
用于分析某個文件被哪些文件引用，用于分析該文件的重要性等
圖片
4. 遷移后
定期巡檢，輸出巡檢報告，包括且不限于「工程化配置、代碼質量、公共依賴引用、依賴收斂、穩定性、性能、用戶體驗」等分析結果。
巡檢工具內部，可以結合靜態文件掃描和運行時模擬，對當前項目做全方位掃描，當然側重在微應用方面的健康度。
五、目標達成情況
上文中提到了「微應用」推進的目標，這里分開演示效果。
目標 1：降低微應用化遷移成本，中大型的微應用化遷移耗時降低 30%
耗時降低計算公式：1 - (有 SOP 時微應用化遷移估時 / 無 SOP 時微應用化遷移估時)
改造前
圖片
用 monopower transfer 對學習平臺進行 monorepo 化改造：
圖片
圖片
改造后
圖片
目標 2：降低學習平臺維護成本，管理端和學員端公共依賴升級時的測試耗時降低 50%
耗時降低計算公式：1 - (微應用化后的測試估時 / 微應用化前的測試估時)
很顯然，這是利用了 monorepo 類工程的天然優勢：依賴隔離。
圖片
學習平臺可以針對管理端和學員端做依賴隔離，從而可以單獨升級學員端、管理端業務的底層依賴。
六、推進的經驗教訓
變與不變
上述推進方案確認后，剩下的就是根據各個里程碑完成對應進度即可，因此在推進過程中，沒有遇到「進度」方面的問題。
當然在推進途中，隨時會面臨實際的技術問題、人員調整、業務壓力等，除了保持足夠的心理準備外，在“技術調研”階段，為關鍵鏈路做好多個方案對比和意外狀況的預案尤為重要。
比如，在微前端選型中，社區中有諸多方案可選（iframe / qiankun / wujie / micro-app 等），在初期擬定某個微前端方案后，如果中途遇到難以解決的問題，就需要及時復盤、調整到備選方案。
備選方案也要做足功課，這是我們在推進微應用落地過程中的重要經驗
Babel在實際應用中的劣勢
在上文介紹「推進方案 - 技術架構- 一鍵 monorepo 化」時，我們提到了: 在對原工程做 monorepo 化時，需要對原工程進行“依賴解析”和“代碼引用路徑修正”。其中專門強調了「基于 AST 或正則」。
圖片
圖片
最開始，我們是基于 Babel 的 AST 解析能力，對工程做「依賴解析和代碼轉換」的。
但實踐過程中發現了 2 個問題：
速度慢
對于效率工程的大型中后臺應用，代碼規模是龐大的，基于 Babel 做一次 AST 解析，尤其是再配合外部封裝的 DFS 類算法框架，進行一次全量解析的耗時有時會持續 10min 以上，這和我們原來的期待（30s 以內）是不相符的。
最初，我們只是對外部封裝的 DFS 類算法框架做了時間復雜度上的優化（如加緩存、轉為 BFS 可中斷的方式等），效果并不明顯，根源還是 Babel 的 AST 解析性能瓶頸。
不正確的新代碼
對源碼做 AST 插件中的節點修改后，生成的新代碼，會修改額外的代碼，比如 ts 類型聲明
比如，源碼中的：
const stringList: string[] = []const stringList：any[] = []原因也基本明確，Babel 的插件配置不夠合理，但調整成本還是很高的，我們對各類配置進行過嘗試，不是很理想。
最終，我們選擇了看起來最笨拙，卻是性能最好的辦法--“正則匹配字符串”來幫助進行依賴解析。
這是部分代碼截圖（正則是用 GPT 生成的，很棒，輔以人工檢查即可）。
圖片
團隊鍛煉
這部分其實是團隊管理和項目管理部分了，如果推進人是比較資深的同學是能很快地完成中大型項目的核心難點工作的，但也有不少同學有成長的意愿以及完成挑戰的能力。
那負責推進的同學，就要學會拆解、放手，讓有意愿有潛力的同學多多承擔重要工作，同時把控風險，保證項目的順利推進。
很榮幸，這個項目在推進的 3 個月內，涌現了多位成長明顯的同學，在整個項目高質量完成的結果上，貢獻了自己的力量，而且很多問題的發現、解決、通用化方案輸出是這些同學主動推動的。
推進能力模型
值得思考的是，以效率前端微應用推進為例，成功推進一個中大型項目，需要具備怎樣的能力和工作方式？
下圖能力模型是我比較喜歡參考的：
圖片
基于這個能力模型，衍生出的比如：主動性、技術儲備、任務分解等各類能力都是可以納入這個模型參考的。
以下是上述能力模型在具體事務上的工作技巧實踐：
- 閉環式推進
- 工作四象限
七、技術之外
本文介紹的技術方案，是效率前端微應用推進的初期設計的，推進 3 個月以來，中途經歷了各種各樣的困難，也有額外的技術小項被納入微應用推進方案，但整體的方向沒有大的變化。
除了技術方面，我有個心得：“推進的同學，需要有良好的心理素質，并能為自己尋找資源”。
良好的心理素質
「Everything is under control」，我想這是設計技術方案的同學需要慢慢具備的心理素質。
在推進過程中，你對遇到的困難是否有心理準備？比如技術方案被挑戰、研發體驗變化帶來的反彈、回滾難度是否都考慮過。“出現各類問題是很正常的”，是我在推進任何項目都有的心理準備。
為自己尋找資源
在各方對推進項目價值沒有太大異議的前提下，推進的同學需要假設任何人包括 Leader 對你需要的幫助是完全不了解的，此時，你需要作為需求方向各個具備資源或者能夠調動資源的人尋求合理的幫助。
八、后續：深水區之前端微服務化
本文從背景出發，詳細介紹了效率前端微應用推進初期設定的技術方案。在推進的 3 個月中，除了完成上述工作外，有多個很重要的技術小項、人員陸續加入。
在下一階段，得物效率前端微應用的推進將重點關注業務微服務化能力的建設。
微服務化在后端領域已經講了很久，在前端領域通常大家提到的是微前端，但本文中提到的「前端微服務化」更側重業務的多端投放能力。
比如，某個中后臺應用的報表能力很強，在其他平臺上，想接入這些報表的話，有幾個方式可以做：
- 該中后臺應用做對外投放能力改造，成本與該應用本身復雜度相關，投放后，方案不具備通用性
- 該中后臺應用采用微服務化能力提升，提升成本極低（比如引入一個微服務化增強腳本即可），子頁面中的報表即可獨立投放到其他平臺
后續要推進的即是第二個方案類似的方向，這是部分實現思路：
圖片
在業務場景中，如果能夠做到「布局 與 內容」的松耦合，對于業務本身的多場景接入大有益處，這也是「微應用」推進面臨的一個深水區，值得重度投入，后續有不錯進展的話，我們會及時分享。
