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

本文最后通過(guò)保險(xiǎn)訂單銷售模式設(shè)計(jì)案例來(lái)說(shuō)明如何進(jìn)行前端設(shè)計(jì)。

微前端概述

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

從單體前端到微前端

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

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

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

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

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

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

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

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

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

保險(xiǎn)訂單銷售模式的必要性

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

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

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

單體前端集成模式

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

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

單體前端集成模式

微前端集成模式

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

微前端集成模式

保險(xiǎn)訂單銷售模式方案

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

保險(xiǎn)產(chǎn)品通道

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

保險(xiǎn)訂單銷售模式方案

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

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

前端集成主頁(yè)面

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

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

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

實(shí)施微前端的主要價(jià)值和意義

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