如何降低前端集成的復(fù)雜度？做到后端解耦，前端聚合？這是一個很有意思的話題。
本文主要借鑒微前端設(shè)計思想，參考微服務(wù)單一職責和共享原則將前端進行拆分和組合。從功能垂直的角度，將微前端與中臺微服務(wù)進行集成和組合，形成從前端到后端可獨立開發(fā)、測試、部署和運維的，領(lǐng)域功能自包含的業(yè)務(wù)單元。
前端頁面通過微前端加載器，利用頁面路由和動態(tài)加載等技術(shù)，實現(xiàn)前端集成主頁面與微前端的“拼圖式”開發(fā)。前端集成項目團隊只需關(guān)注前端整體風格、微前端之間的數(shù)據(jù)交互和頁面路由等內(nèi)容，不涉及前端與中臺之間以及中臺與中臺之間的 API 集成，從而降低集成過程中的技術(shù)敏感度、團隊溝通成本和集成復(fù)雜度，提高交付效率和用戶體驗。

本文最后通過保險訂單銷售模式設(shè)計案例來說明如何進行前端設(shè)計。

微前端概述

微前端概念是 ThoughtWorks 在 2016 年提出來的，它將微服務(wù)理念擴展到前端開發(fā)，解決中臺微服務(wù)化后，前端由于仍為單體而存在的邏輯繁雜和臃腫的問題。微前端是按照前端設(shè)計方法在前端同時構(gòu)建多個可以獨立部署、完全自治、松耦合的頁面組合，其中每個組合只負責特定的 UI 元素和功能。
微前端與微服務(wù)都是希望將單體應(yīng)用，按照一定的規(guī)則拆分為多個可以獨立運行、獨立開發(fā)、獨立部署、獨立運維的微服務(wù)或者頁面聚合，從而滿足業(yè)務(wù)快速變化及分布式多團隊并行開發(fā)的需求。
微前端除了可以實現(xiàn)前端頁面的解耦外，還可實現(xiàn)前端頁面的復(fù)用，做到“一次開發(fā)，多端復(fù)用”，這也與中臺服務(wù)共享理念是一脈相承。

從單體前端到微前端

傳統(tǒng)的軟件項目往往采用單體式架構(gòu)，前端往往由一個團隊創(chuàng)建并維護一個 Web 應(yīng)用程序，通過 API 網(wǎng)關(guān)從微服務(wù)調(diào)用服務(wù)。隨著時間的推移，前端往往會越來越臃腫，越來越難維護。
隨著 5G 技術(shù)的應(yīng)用，企業(yè)活動將進一步移動化和線上化，過去企業(yè)的通常做法是為不同的應(yīng)用開發(fā)出很多獨立的 APP。但是用戶來并不想裝那么多 APP！

為了提高用戶體驗，實現(xiàn)統(tǒng)一運營，很多企業(yè)開始縮減 APP 的數(shù)量，通過一個 APP 集成所有應(yīng)用功能。試想如果將企業(yè)內(nèi)所有前端頁面、流程設(shè)計以及前端與后端集成的工作都交給前端項目，將原來獨立和分散的應(yīng)用，展示在一個巴掌大的手機屏幕上。前端項目將會面對無數(shù)的中臺項目和成千上萬不太熟悉的 API 接口，這絕對會是一場災(zāi)難。
相對互聯(lián)網(wǎng)企業(yè)而言，傳統(tǒng)企業(yè)的渠道應(yīng)用更多樣化，有面向內(nèi)部人員的柜臺類應(yīng)用、面向外部客戶的互聯(lián)網(wǎng)電商及移動 APP 類應(yīng)用，還有面向商業(yè)生態(tài)圈的第三方 API 集成。由于渠道的差異，傳統(tǒng)企業(yè)前端設(shè)計將會更多樣化和復(fù)雜化。
傳統(tǒng)企業(yè)在實施中臺戰(zhàn)略時，為滿足前端和中臺多渠道共享和復(fù)用，部分場景還應(yīng)有別于阿里巴巴的中臺戰(zhàn)略。傳統(tǒng)企業(yè)除了要像阿里巴巴一樣進行通用共享服務(wù)（主要提供共享 API）的中臺化建設(shè)外，還需要對核心專屬業(yè)務(wù)（除 API 外，還存在大量面向用戶的頁面）進行中臺化建設(shè)，以滿足不同渠道的業(yè)務(wù)復(fù)用的需求。

從單體前端到微前端
如何實現(xiàn)前端復(fù)用，降低前端集成的復(fù)雜度？
在前端設(shè)計時，我們可以參考微服務(wù)設(shè)計方法，遵循單一職責和共享原則，按照領(lǐng)域模型和微服務(wù)邊界，將前端頁面進行拆分和組合形成微前端，與中臺微服務(wù)組合成業(yè)務(wù)單元。
業(yè)務(wù)單元定義：在前后端分離架構(gòu)模式下，微前端頁面與中臺微服務(wù)共同組成一個業(yè)務(wù)單元。在同一個業(yè)務(wù)單元內(nèi)，從前端頁面、中臺微服務(wù)到后端數(shù)據(jù)可以獨立開發(fā)、測試、部署和運維，在業(yè)務(wù)單元內(nèi)自包含完成中臺領(lǐng)域內(nèi)的部分或全部業(yè)務(wù)功能。
項目職責和系統(tǒng)邊界
1、從前端項目主要負責前端頁面的集成、頁面風格設(shè)計和流程控制，以及與微前端集成相關(guān)的微前端加載、微前端注冊、頁面路由以及數(shù)據(jù)共享。
2、后端中臺項目負責業(yè)務(wù)單元內(nèi)中臺微服務(wù)以及微服務(wù)對應(yīng)微前端開發(fā)和集成。
通用和專屬中臺項目既面向第三方生態(tài)圈提供 API 服務(wù)，也面向前端集成主頁面提供微前端頁面復(fù)用。微前端和中臺微服務(wù)組合成業(yè)務(wù)單元為多渠道業(yè)務(wù)提供從前端到后臺的頁面和業(yè)務(wù)邏輯復(fù)用。在面向多渠道業(yè)務(wù)頁面復(fù)用時，微前端需要做好頁面風格適配，以滿足不同渠道界面風格的要求。
通過職責分工和應(yīng)用邊界的清晰劃分，前端項目專注于微前端集成，后端項目專職做好本業(yè)務(wù)領(lǐng)域內(nèi)中臺微服務(wù)開發(fā)和微前端集成，確保領(lǐng)域內(nèi)前端頁面和后端業(yè)務(wù)邏輯作為一個業(yè)務(wù)單元整體高可用。
由于微前端和微服務(wù)之間的 API 集成已由中臺項目完成，前端項目可基于微前端實現(xiàn)拼圖式開發(fā)，在實現(xiàn)前后端復(fù)用的同時，大大降低前端集成復(fù)雜度。

微前端與微服務(wù)組合的幾種形態(tài)

微前端與微服務(wù)可以有多種組合方式，以實現(xiàn)不同的業(yè)務(wù)目標。
一個虛框內(nèi)微前端、中臺微服務(wù)共同組成一個業(yè)務(wù)單元（如下圖）。虛框內(nèi)組件可以按照業(yè)務(wù)單元分前端和后端進行獨立部署。
微前端頁面包括業(yè)務(wù)操作必需的頁面要素，不含頁面導(dǎo)航等要素，頁面導(dǎo)航功能位于前端集成主頁面內(nèi)。
微前端頁面稍加改造就可以完成簡單的單一場景業(yè)務(wù)，也可根據(jù)頁面路由動態(tài)加載到前端集成主頁面完成復(fù)雜組合場景業(yè)務(wù)。

微前端的幾種形態(tài)

微前端與微服務(wù)的組合主要有以下幾類形式。
1、單一類微前端：一個微前端和一個中臺微服務(wù)組成一個業(yè)務(wù)單元。微前端完成業(yè)務(wù)單元內(nèi)頁面流程和前端操作，中臺微服務(wù)完成后端業(yè)務(wù)邏輯，業(yè)務(wù)單元功能獨立且自包含。微前端可按照頁面路由動態(tài)加載至前端集成主頁面。
2、組合類微前端：一個微前端與多個中臺微服務(wù)組成業(yè)務(wù)單元。微前端通過對多個中臺微服務(wù)進行服務(wù)編排和組合，完成業(yè)務(wù)單元內(nèi)較復(fù)雜的頁面流程和前端操作。業(yè)務(wù)邏輯由后端多個微服務(wù)組合完成，如：可由專屬業(yè)務(wù)中臺與通用中臺微服務(wù)組合，也可由同一領(lǐng)域內(nèi)多個微服務(wù)組合。在微前端設(shè)計時，微前端對應(yīng)的組合微服務(wù)的數(shù)量要均衡考慮，否則很容易將微前端開發(fā)成單體前端。同時業(yè)務(wù)單元的領(lǐng)域邊界要清晰，避免由于功能交叉而導(dǎo)致單元與單元之間的耦合，影響項目團隊職責邊界，進而影響到部署、測試以及運維等。
3、通用共享類微前端：一個微前端與一個或多個通用中臺微服務(wù)組成共享類業(yè)務(wù)單元。通用共享類微前端一般通過前端集成主頁面，以共享頁面的模式與其他微前端頁面組合，共同完成業(yè)務(wù)流程。該類微前端通常對應(yīng)通用中臺共享類微服務(wù)。

基于微前端的保險訂單銷售方案設(shè)計

本節(jié)主要介紹如何通過微前端與中臺微服務(wù)組合設(shè)計，滿足保險產(chǎn)品訂單銷售業(yè)務(wù)模式要求。由于篇幅有限，本文主要描述技術(shù)和設(shè)計思路。如對詳細設(shè)計感興趣，可關(guān)注作者簡書號：歐創(chuàng)新，在《中臺戰(zhàn)略下的保險訂單銷售模式設(shè)計》文中有詳細介紹。

保險訂單銷售模式的必要性

對于保險集團而言，為充分利用銷售資源，實現(xiàn)集團一體化的綜拓銷售和所有子公司保險產(chǎn)品的一體化交叉銷售，需對所有產(chǎn)品實現(xiàn)無差異的一體化運營和銷售。傳統(tǒng)的保險核心業(yè)務(wù)系統(tǒng)基本都是分險種建設(shè)的，前端沒有統(tǒng)一的操作界面，客戶在購買多個保險產(chǎn)品時很難享受到流暢的服務(wù)。
以產(chǎn)險為例，承保核心系統(tǒng)基本是以車險和非車險產(chǎn)品為邊界建設(shè)。由于前端頁面分離，沒有統(tǒng)一的銷售界面，用戶只能在一個系統(tǒng)內(nèi)進行豎井式操作，一次只能完成一類產(chǎn)品承保。如產(chǎn)品涉及車和非車險，則需要分別操作車險和非車險兩個系統(tǒng)才能完成承保。
同一公司內(nèi)跨車和非車險產(chǎn)品銷售存在體驗的問題，如果把產(chǎn)、壽、健和養(yǎng)老所有子公司保險產(chǎn)品放在一起統(tǒng)一運營和銷售，面臨的問題就更復(fù)雜了。
為了解決所有保險產(chǎn)品無差異一體化銷售的問題，可以借鑒電商訂單化的銷售模式，在保險產(chǎn)品之上增加一個實體，這個實體就是訂單。
在前端，利用前端集成主頁面通過商品、錄單、購物車、訂單、保單管理等業(yè)務(wù)功能，建立所有產(chǎn)品的客戶接觸和體驗的一體化銷售界面。
保險訂單銷售模式可以滿足跨多個保險產(chǎn)品復(fù)雜場景的產(chǎn)品無差異的一體化銷售目標，給客戶提供一致的體驗，滿足集團化或者保險商城等多產(chǎn)品組合銷售場景要求。同時還可以通過事件驅(qū)動的異步化的模式，徹底解耦后端應(yīng)用，降低實時處理壓力。

承保業(yè)務(wù)中臺的建設(shè)

保險公司有很多類保險產(chǎn)品，但由于不同保險產(chǎn)品面向不同的場景，解決的問題不同，在錄單要素、業(yè)務(wù)規(guī)則以及流程等方面存在差異，因此其前端頁面和領(lǐng)域模型也會存在不同。為了避免不同類產(chǎn)品之間的相互影響和干擾，在進行承保業(yè)務(wù)中臺設(shè)計時，可以以同類相似場景的保險產(chǎn)品作為聚合進行承保專屬業(yè)務(wù)中臺的建設(shè)。
按照上述思路，集團內(nèi) N 類產(chǎn)品將會有 N 個承保專屬業(yè)務(wù)中臺，每個承保業(yè)務(wù)中臺至少包含：投保和保單管理兩個微服務(wù)。為了簡單起見，以下圖中六邊形微服務(wù)圖例為保險產(chǎn)品的承保業(yè)務(wù)中臺，如：車險所在圖例為車險承保業(yè)務(wù)中臺，車險承保業(yè)務(wù)中臺中至少包含了投保和保單管理兩個微服務(wù)。
投保微服務(wù)主要存儲客戶接觸過程中的投保數(shù)據(jù)和處理投保業(yè)務(wù)邏輯。配合核保中心完成核保操作，訂單支付完成后，訂單中心通過事件機制觸發(fā)投保微服務(wù)將投保單轉(zhuǎn)成保單，并異步將數(shù)據(jù)傳送到保單管理微服務(wù)和客戶統(tǒng)一視圖。
保單管理微服務(wù)異步接收從投保微服務(wù)將投保單轉(zhuǎn)保單后的保單數(shù)據(jù)。異步傳送后續(xù)流程需要的數(shù)據(jù)，如：傭金、收付費、再保以及客戶統(tǒng)一視圖庫和業(yè)務(wù)統(tǒng)一視圖數(shù)據(jù)。
中臺項目在建設(shè)投保和保單管理微服務(wù)時，需同步建設(shè)和集成錄單和保單管理微前端，微前端分別完成錄單和批改、退保的頁面邏輯。

單體前端集成模式

在承保業(yè)務(wù)中臺完成建設(shè)后，如果前端項目仍然采用單體前端集成模式。前端項目將面臨 N 類產(chǎn)品的中臺項目和微服務(wù)暴露出來的成千上萬的 API。
以錄單為例，如果前端用一個錄單頁面完成所有產(chǎn)品的錄入，將會面臨由于不同類產(chǎn)品錄單要素不一樣而導(dǎo)致頁面眾口難調(diào)的問題，最終影響用戶體驗。而且在集成過程中還需要處理不同產(chǎn)品中臺 API 路由的問題。
而如果前端項目為每類產(chǎn)品單獨開發(fā)一個錄單頁面，暫且不提需要開發(fā) N 類產(chǎn)品前端錄單頁面的工作量。在與中臺集成的過程中，前端項目團隊需要詳細了解所有 N 類產(chǎn)品的中臺 API，并需要為每類產(chǎn)品完成前后端的集成。而且有可能由于業(yè)務(wù)中臺屬于不同子公司，而導(dǎo)致集成開發(fā)需要跨公司，而公司之間或許還存在技術(shù)異構(gòu)，這將會給前端集成帶來非常巨大的工作量。而一旦中臺 API 出現(xiàn)變更，前端版本的調(diào)整和多個應(yīng)用版本的協(xié)同發(fā)布，也會影響到業(yè)務(wù)的正常運行。
單體前端的集成模式給前端項目提出了很高的要求。

而如果采用微前端的集成模式呢？或許情況會發(fā)生很大的變化。

單體前端集成模式

微前端集成模式

如采用微前端集成模式，中臺項目和前端項目將會有清晰的職責和應(yīng)用邊界。前端項目可通過前端集成主頁面按需加載微前端，實現(xiàn)拼圖式開發(fā)。
1、前端項目主要負責前端主頁面的集成、頁面風格設(shè)計和流程控制，以及與微前端集成相關(guān)的微前端加載、微前端注冊、頁面路由以及前端集成主頁面的數(shù)據(jù)共享。
2、后端中臺項目負責業(yè)務(wù)單元內(nèi)中臺微服務(wù)以及對應(yīng)的微前端建設(shè)，完成中臺微服務(wù)與微前端的集成。
中臺項目為投保微服務(wù)和保單管理微服務(wù)分別開發(fā)錄單微前端和保單管理微前端。錄單微前端與投保微服務(wù)組成投保業(yè)務(wù)單元（如下圖虛框內(nèi)組件組合為一個業(yè)務(wù)單元）。由于微前端與中臺微服務(wù)的開發(fā)、測試和集成都是在中臺項目內(nèi)完成，集成起來的難度和出問題的可能性會比單體前端集成模式要小的多。
前端項目只需要關(guān)注集成主頁面中的微前端加載、注冊和頁面路由規(guī)則的設(shè)置，不需關(guān)心中臺微服務(wù) API 的集成和中臺業(yè)務(wù)邏輯的技術(shù)實現(xiàn)，從而屏蔽底層技術(shù)復(fù)雜度，降低前端項目技術(shù)能力要求、溝通和測試成本。

微前端集成模式

保險訂單銷售模式方案

為了后續(xù)描述方便在本節(jié)定義一個新名詞“保險產(chǎn)品通道”。

保險產(chǎn)品通道

保險產(chǎn)品通道包括微前端、承保專屬業(yè)務(wù)中臺以及專屬業(yè)務(wù)中臺后端對應(yīng)的收付費、傭金、再保等通用中臺和客戶統(tǒng)一視圖和業(yè)務(wù)統(tǒng)一視圖等數(shù)據(jù)中臺。同類產(chǎn)品在這個通道內(nèi)完成錄單、投保、保單生成、退保、批改以及向后端送數(shù)等操作。
保險產(chǎn)品通道主要隔離點在微前端和承保專屬業(yè)務(wù)中臺。同類產(chǎn)品使用同一個產(chǎn)品通道，不同類產(chǎn)品使用不同的產(chǎn)品通道，所有流程無交叉，代碼、部署和功能隔離。保險產(chǎn)品通道包括領(lǐng)域內(nèi)若干微前端和微服務(wù)組合成的若干個業(yè)務(wù)單元，這些業(yè)務(wù)單元能力組合成全部的領(lǐng)域能力，如車險中臺所在的投保業(yè)務(wù)單元和保單管理業(yè)務(wù)單元，共同組成車險承保領(lǐng)域能力。

保險訂單銷售模式方案

產(chǎn)品通道設(shè)計要點
承保流程中不同保險產(chǎn)品通道之間無交叉和交互。
同類產(chǎn)品承保業(yè)務(wù)流程在自己專屬產(chǎn)品通道內(nèi)完成。

產(chǎn)品通道的意義
1、業(yè)務(wù)專一性：領(lǐng)域模型更聚焦，功能更單一，前后端項目團隊規(guī)模更小，集中辦公，更專注于本領(lǐng)域內(nèi)的業(yè)務(wù)邏輯和微前端。產(chǎn)品通道業(yè)務(wù)高度內(nèi)斂，同類產(chǎn)品錄單、流程和規(guī)則基本相似，產(chǎn)品之間干擾小，用戶體驗會更好。
2、職責專一性：產(chǎn)品通道完成了產(chǎn)品從前端到后端全部承保流程。中臺項目專職于產(chǎn)品承保業(yè)務(wù)中臺業(yè)務(wù)邏輯和微前端頁面的實現(xiàn)，因此誰負責產(chǎn)品，誰就負責微前端和專屬業(yè)務(wù)中臺建設(shè)，并保證全通道內(nèi)業(yè)務(wù)的高可用。前端項目只需完成前端主頁面與微前端的集成，集成過程甚至不涉及到 API，可以減輕前端集成壓力和界面開發(fā)的復(fù)雜度。尤其對于集團級跨子公司（主要問題是系統(tǒng)和業(yè)務(wù)相互不熟悉，接口和集成復(fù)雜，溝通成本高）的系統(tǒng)集成會帶來極大的好處，降低溝通成本和集成的復(fù)雜度。
3、復(fù)用性：微前端和承保業(yè)務(wù)中臺都有高度的復(fù)用性。微前端可快速加入前端集成主頁面，或?qū)⑽⑶岸酥苯影l(fā)布成 APP，實現(xiàn)快速響應(yīng)和發(fā)布。某些場景甚至一個微前端就是一個 APP 應(yīng)用，完成單一場景產(chǎn)品的銷售。
4、隔離性：同類產(chǎn)品的問題修復(fù)和代碼修改在一個產(chǎn)品通道內(nèi)，不會影響其他產(chǎn)品通道的業(yè)務(wù)。不同產(chǎn)品通道在物理和邏輯上隔離，業(yè)務(wù)單元的版本發(fā)布和新產(chǎn)品上線相互之間不受影響。
5、響應(yīng)能力：新產(chǎn)品通道可以獨立開發(fā)、測試、集成和部署，完成部署后只需在集成主頁面完成微前端注冊和增加頁面路由即可上線銷售。
6、測試和溝通成本低：一個產(chǎn)品通道由一個中臺項目團隊負責。產(chǎn)品通道功能自包含，在一個通道內(nèi)可以完成從前端到后端所有業(yè)務(wù)流程集成和測試，降低溝通和測試成本。
7、技術(shù)敏感度低：微前端只要符合規(guī)范即可快速動態(tài)加載到前端集成主頁面，前端項目在前端集成過程中不需要關(guān)注中臺的技術(shù)實現(xiàn)和 API 集成，降低技術(shù)敏感度。

前端集成主頁面

前端集成主頁面類似門戶，集成所有微前端頁面，實現(xiàn)所有微前端的聚合。按照正確的邏輯（如根據(jù)客戶選擇產(chǎn)品，選擇加載產(chǎn)品對應(yīng)的錄單微前端，完成錄單和投保）加載微前端頁面，協(xié)同配合完成完整的業(yè)務(wù)流程，給用戶提供一致的體驗。
前端集成主頁面和所有微前端須有統(tǒng)一的頁面風格，且符合前端的集成技術(shù)規(guī)范。
前端集成主頁面加載并組合各微前端，作為一個整體為客戶提供所有保險產(chǎn)品銷售的接觸和體驗界面，包括商品展示、錄單、購物車、訂單管理、支付管理以及退保和批改等保單管理操作。

以投保和保單管理為例，說明一下前端集成主頁面的工作原理。

1、在錄單過程中，客戶選擇保險產(chǎn)品，前端集成主頁面根據(jù)客戶選擇的保險產(chǎn)品，獲取產(chǎn)品對應(yīng)的錄單微前端路由，也就是錄單微前端 URL 地址，在主頁面指定區(qū)域加載錄單微前端頁面。錄單微前端負責錄單界面，投保微服務(wù)負責投保單生成等后端邏輯，兩者配合在產(chǎn)品通道內(nèi)完成投保單的錄入和投保單生成。
2、在保單管理過程中，前端集成主頁面根據(jù)客戶選擇的保險產(chǎn)品加載產(chǎn)品對應(yīng)的保單管理微前端，兩者配合在產(chǎn)品通道內(nèi)完成保單退?；蚺?。

實施微前端的主要價值和意義

現(xiàn)在越來越多的公司都在進行微前端的落地和應(yīng)用，微前端主要技術(shù)方向有 Mooa、Single-SPA、Web Components、Vue 等開源前端框架，在此不做贅述。
微前端是前端建設(shè)的一個非常重要的方向和關(guān)注點，通過微前端的集成模式可以減輕系統(tǒng)開發(fā)的復(fù)雜度，降低前端集成的難度。它的主要價值和意義如下：
1、前端集成簡單：前端項目只需關(guān)注前端集成主頁面與微前端的集成，不涉及到 API 集成和中臺技術(shù)實現(xiàn)細節(jié)，可真正實現(xiàn)模塊化集成，實現(xiàn)拼圖式的開發(fā)，降低前端集成的復(fù)雜度和成本。
2、項目職責專一：中臺項目從數(shù)據(jù)庫、中臺到微前端界面端到端地完成領(lǐng)域邏輯功能開發(fā)，確保領(lǐng)域業(yè)務(wù)單元內(nèi)從前端到后端可用。由于團隊職責專一，項目成員都熟悉團隊內(nèi)的業(yè)務(wù)和技術(shù)，從而降低開發(fā)過程因為溝通和集成出問題的風險。
3、隔離和依賴性：每個團隊都有自己的關(guān)注點，各關(guān)注點邊界清晰，相互隔離，風暴都在茶壺內(nèi)。業(yè)務(wù)單元在代碼、邏輯和物理邊界都是隔離的，降低應(yīng)用之間的依賴性。在出現(xiàn)問題時可實現(xiàn)快速問題定位和修復(fù)，并可將風險控制在一個業(yè)務(wù)單元內(nèi)，不會影響其他業(yè)務(wù)單元的正常運行。版本發(fā)布過程中不會影響其它業(yè)務(wù)單元的正常運行。
4、降低溝通和測試成本：一個中臺項目團隊從前端頁面到后端中臺業(yè)務(wù)邏輯，實現(xiàn)從開發(fā)、測試、集成和部署的全流程和全生命周期管理，降低前后端集成的測試和溝通成本。
5、更敏捷的發(fā)布：由于應(yīng)用之間的隔離和依賴性降低，每一個小的變化都控制在業(yè)務(wù)單元內(nèi)，項目團隊可以獨立按照自己的步調(diào)進行迭代開發(fā)，實現(xiàn)更快的發(fā)布周期。
6、降低技術(shù)敏感性：由于前端項目主要關(guān)注微前端的集成和前端技術(shù)，屏蔽了前端對中臺技術(shù)的要求，從而降低了前端項目技術(shù)的敏感性。在降低前端集成復(fù)雜度的同時，中臺項目可以更便捷的選擇和嘗試更多更合適的技術(shù)和架構(gòu)，實現(xiàn)架構(gòu)的演進。
7、高度復(fù)用性：微前端和業(yè)務(wù)中臺都有高度的復(fù)用性。微前端可快速按需加載到前端集成主頁面，或?qū)⑽⑶岸酥苯影l(fā)布成 APP，實現(xiàn)快速發(fā)布。某些場景一個微前端就是一個 APP 應(yīng)用。