中臺微服務了，那前端呢？

前段時間作者寫了《當中臺遇到DDD，我們該如何設計微服務？》這篇文章，文章中詳細描述了基於DDD設計思想的中臺微服務設計方法以及分散式架構實施過程中的關注點等內容。中臺建設完成後，通過微服務實現了後端應用的解耦，提高了中臺應用的彈性伸縮能力。但由於微服務拆分，也會導致專案團隊和服務的碎片化，給前端專案整合帶來一定的複雜度。

微服務架構通常採用前後端分離方式，中臺服務通過API閘道器對外發布，單體應用拆分後一個前端專案可能會面對多箇中臺微服務專案。前端開發人員猶如維修電工一樣，將面對成千上萬中臺團隊開發出來的API接頭，如何正確的連線和拼裝，並且保證不出錯，不是一件很容易的事情。而當中臺API出現變更時，又如何通知所有受影響的前端專案團隊同步調整和版本協同釋出，需要的溝通成本相信也不小。

如何降低前端整合的複雜度？做到後端解耦，前端聚合？這是一個很有意思的話題。

本文主要借鑑微前端設計思想，參考微服務單一職責和共享原則將前端進行拆分和組合。從功能垂直的角度，將微前端與中臺微服務進行整合和組合，形成從前端到後端可獨立開發、測試、部署和運維的，領域功能自包含的業務單元。

前端頁面通過微前端載入器，利用頁面路由和動態載入等技術，實現前端整合主頁面與微前端的“拼圖式”開發。前端整合專案團隊只需關注前端整體風格、微前端之間的資料互動和頁面路由等內容，不涉及前端與中臺之間以及中臺與中臺之間的API整合，從而降低整合過程中的技術敏感度、團隊溝通成本和整合複雜度，提高交付效率和使用者體驗。

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

微前端概述

微前端概念是ThoughtWorks在2016年提出來的，它將微服務理念擴充套件到前端開發，解決中臺微服務化後，前端由於仍為單體而存在的邏輯繁雜和臃腫的問題。微前端是按照前端設計方法在前端同時構建多個可以獨立部署、完全自治、鬆耦合的頁面組合，其中每個組合只負責特定的 UI 元素和功能。

微前端與微服務都是希望將單體應用，按照一定的規則拆分為多個可以獨立執行、獨立開發、獨立部署、獨立運維的微服務或者頁面聚合，從而滿足業務快速變化及分散式多團隊並行開發的需求。

微前端除了可以實現前端頁面的解耦外，還可實現前端頁面的複用，做到“一次開發，多端複用”，這也與中臺服務共享理念是一脈相承。

從單體前端到微前端

傳統的軟體專案往往採用單體式架構，前端往往由一個團隊建立並維護一個 Web 應用程式，通過API閘道器從微服務呼叫服務。隨著時間的推移，前端往往會越來越臃腫，越來越難維護。

隨著5G技術的應用，企業活動將進一步移動化和線上化，過去企業的通常做法是為不同的應用開發出很多獨立的APP。但是使用者來並不想裝那麼多APP！

為了提高使用者體驗，實現統一運營，很多企業開始縮減APP的數量，通過一個APP整合所有應用功能。試想如果將企業內所有前端頁面、流程設計以及前端與後端整合的工作都交給前端專案，將原來獨立和分散的應用，展示在一個巴掌大的手機螢幕上。前端專案將會面對無數的中臺專案和成千上萬不太熟悉的API介面，這絕對會是一場災難。

相對網際網路企業而言，傳統企業的渠道應用更多樣化，有面向內部人員的櫃檯類應用、面向外部客戶的網際網路電商及移動APP類應用，還有面向商業生態圈的第三方API整合。由於渠道的差異，傳統企業前端設計將會更多樣化和複雜化。

傳統企業在實施中臺戰略時，為滿足前端和中臺多渠道共享和複用，部分場景還應有別於阿里巴巴的中臺戰略。傳統企業除了要像阿里巴巴一樣進行通用共享服務（主要提供共享API）的中臺化建設外，還需要對核心專屬業務（除API外，還存在大量面向使用者的頁面）進行中臺化建設，以滿足不同渠道的業務複用的需求。

從單體前端到微前端

如何實現前端複用，降低前端整合的複雜度？

在前端設計時，我們可以參考微服務設計方法，遵循單一職責和共享原則，按照領域模型和微服務邊界，將前端頁面進行拆分和組合形成微前端，與中臺微服務組合成業務單元。

業務單元定義：在前後端分離架構模式下，微前端頁面與中臺微服務共同組成一個業務單元。在同一個業務單元內，從前端頁面、中臺微服務到後端資料可以獨立開發、測試、部署和運維，在業務單元內自包含完成中臺領域內的部分或全部業務功能。

專案職責和系統邊界

1. 從前端專案主要負責前端頁面的整合、頁面風格設計和流程控制，以及與微前端整合相關的微前端載入、微前端註冊、頁面路由以及資料共享。

2. 後端中臺專案負責業務單元內中臺微服務以及微服務對應微前端開發和整合。

通用和專屬中臺專案既面向第三方生態圈提供API服務，也面向前端整合主頁面提供微前端頁面複用。微前端和中臺微服務組合成業務單元為多渠道業務提供從前端到後臺的頁面和業務邏輯複用。在面向多渠道業務頁面複用時，微前端需要做好頁面風格適配，以滿足不同渠道介面風格的要求。

通過職責分工和應用邊界的清晰劃分，前端專案專注於微前端整合，後端專案專職做好本業務領域內中臺微服務開發和微前端整合，確保領域內前端頁面和後端業務邏輯作為一個業務單元整體高可用。

由於微前端和微服務之間的API整合已由中臺專案完成，前端專案可基於微前端實現拼圖式開發，在實現前後端複用的同時，大大降低前端整合複雜度。

微前端與微服務組合的幾種形態

微前端與微服務可以有多種組合方式，以實現不同的業務目標。

一個虛框內微前端、中臺微服務共同組成一個業務單元（如下圖）。虛框內元件可以按照業務單元分前端和後端進行獨立部署。

微前端頁面包括業務操作必需的頁面要素，不含頁面導航等要素，頁面導航功能位於前端整合主頁面內。

微前端頁面稍加改造就可以完成簡單的單一場景業務，也可根據頁面路由動態載入到前端整合主頁面完成複雜組合場景業務。

微前端的幾種形態

微前端與微服務的組合主要有以下幾類形式。

• 單一類微前端：一個微前端和一箇中臺微服務組成一個業務單元。微前端完成業務單元內頁面流程和前端操作，中臺微服務完成後端業務邏輯，業務單元功能獨立且自包含。微前端可按照頁面路由動態載入至前端整合主頁面。

• 組合類微前端：一個微前端與多箇中臺微服務組成業務單元。微前端通過對多箇中臺微服務進行服務編排和組合，完成業務單元內較複雜的頁面流程和前端操作。業務邏輯由後端多個微服務組合完成，如：可由專屬業務中臺與通用中臺微服務組合，也可由同一領域內多個微服務組合。在微前端設計時，微前端對應的組合微服務的數量要均衡考慮，否則很容易將微前端開發成單體前端。同時業務單元的領域邊界要清晰，避免由於功能交叉而導致單元與單元之間的耦合，影響專案團隊職責邊界，進而影響到部署、測試以及運維等。

• 通用共享類微前端：一個微前端與一個或多個通用中臺微服務組成共享類業務單元。通用共享類微前端一般通過前端整合主頁面，以共享頁面的模式與其他微前端頁面組合，共同完成業務流程。該類微前端通常對應通用中臺共享類微服務。

基於微前端的保險訂單銷售方案設計

本節主要介紹如何通過微前端與中臺微服務組合設計，滿足保險產品訂單銷售業務模式要求。由於篇幅有限，本文主要描述技術和設計思路。如對詳細設計感興趣，可關注作者簡書號：歐創新，在《中臺戰略下的保險訂單銷售模式設計》文中有詳細介紹。

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

對於保險集團而言，為充分利用銷售資源，實現集團一體化的綜拓銷售和所有子公司保險產品的一體化交叉銷售，需對所有產品實現無差異的一體化運營和銷售。傳統的保險核心業務系統基本都是分險種建設的，前端沒有統一的操作介面，客戶在購買多個保險產品時很難享受到流暢的服務。

以產險為例，承保核心系統基本是以車險和非車險產品為邊界建設。由於前端頁面分離，沒有統一的銷售介面，使用者只能在一個系統內進行豎井式操作，一次只能完成一類產品承保。如產品涉及車和非車險，則需要分別操作車險和非車險兩個系統才能完成承保。

同一公司內跨車和非車險產品銷售存在體驗的問題，如果把產、壽、健和養老所有子公司保險產品放在一起統一運營和銷售，面臨的問題就更復雜了。

為了解決所有保險產品無差異一體化銷售的問題，可以借鑑電商訂單化的銷售模式，在保險產品之上增加一個實體，這個實體就是訂單。

在前端，利用前端整合主頁面通過商品、錄單、購物車、訂單、保單管理等業務功能，建立所有產品的客戶接觸和體驗的一體化銷售介面。

保險訂單銷售模式可以滿足跨多個保險產品複雜場景的產品無差異的一體化銷售目標，給客戶提供一致的體驗，滿足集團化或者保險商城等多產品組合銷售場景要求。同時還可以通過事件驅動的非同步化的模式，徹底解耦後端應用，降低實時處理壓力。

承保業務中臺的建設

保險公司有很多類保險產品，但由於不同保險產品面向不同的場景，解決的問題不同，在錄單要素、業務規則以及流程等方面存在差異，因此其前端頁面和領域模型也會存在不同。為了避免不同類產品之間的相互影響和干擾，在進行承保業務中臺設計時，可以以同類相似場景的保險產品作為聚合進行承保專屬業務中臺的建設。

按照上述思路，集團內N類產品將會有N個承保專屬業務中臺，每個承保業務中臺至少包含：投保和保單管理兩個微服務。為了簡單起見，以下圖中六邊形微服務圖例為保險產品的承保業務中臺，如：車險所在圖例為車險承保業務中臺，車險承保業務中臺中至少包含了投保和保單管理兩個微服務。

投保微服務主要儲存客戶接觸過程中的投保資料和處理投保業務邏輯。配合核保中心完成核保操作，訂單支付完成後，訂單中心通過事件機制觸發投保微服務將投保單轉成保單，並非同步將資料傳送到保單管理微服務和客戶統一檢視。

保單管理微服務非同步接收從投保微服務將投保單轉保單後的保單資料。非同步傳送後續流程需要的資料，如：佣金、收付費、再保以及客戶統一檢視庫和業務統一檢視資料。

中臺專案在建設投保和保單管理微服務時，需同步建設和整合錄單和保單管理微前端，微前端分別完成錄單和批改、退保的頁面邏輯。

單體前端整合模式

在承保業務中臺完成建設後，如果前端專案仍然採用單體前端整合模式。前端專案將面臨N類產品的中臺專案和微服務暴露出來的成千上萬的API。

以錄單為例，如果前端用一個錄單頁面完成所有產品的錄入，將會面臨由於不同類產品錄單要素不一樣而導致頁面眾口難調的問題，最終影響使用者體驗。而且在整合過程中還需要處理不同產品中臺API路由的問題。

而如果前端專案為每類產品單獨開發一個錄單頁面，暫且不提需要開發N類產品前端錄單頁面的工作量。在與中臺整合的過程中，前端專案團隊需要詳細瞭解所有N類產品的中臺API，並需要為每類產品完成前後端的整合。而且有可能由於業務中臺屬於不同子公司，而導致整合開發需要跨公司，而公司之間或許還存在技術異構，這將會給前端整合帶來非常巨大的工作量。而一旦中臺API出現變更，前端版本的調整和多個應用版本的協同釋出，也會影響到業務的正常執行。

單體前端的整合模式給前端專案提出了很高的要求。

而如果採用微前端的整合模式呢？或許情況會發生很大的變化。

單體前端整合模式

微前端整合模式

如採用微前端整合模式，中臺專案和前端專案將會有清晰的職責和應用邊界。前端專案可通過前端整合主頁面按需載入微前端，實現拼圖式開發。

1. 前端專案主要負責前端主頁面的整合、頁面風格設計和流程控制，以及與微前端整合相關的微前端載入、微前端註冊、頁面路由以及前端整合主頁面的資料共享。

2. 後端中臺專案負責業務單元內中臺微服務以及對應的微前端建設，完成中臺微服務與微前端的整合。

中臺專案為投保微服務和保單管理微服務分別開發錄單微前端和保單管理微前端。錄單微前端與投保微服務組成投保業務單元（如下圖虛框內元件組合為一個業務單元）。由於微前端與中臺微服務的開發、測試和整合都是在中臺專案內完成，整合起來的難度和出問題的可能性會比單體前端整合模式要小的多。

前端專案只需要關注整合主頁面中的微前端載入、註冊和頁面路由規則的設定，不需關心中臺微服務API的整合和中臺業務邏輯的技術實現，從而遮蔽底層技術複雜度，降低前端專案技術能力要求、溝通和測試成本。

微前端整合模式

保險訂單銷售模式方案

為了後續描述方便在本節定義一個新名詞“保險產品通道”。

保險產品通道

保險產品通道包括微前端、承保專屬業務中臺以及專屬業務中臺後端對應的收付費、佣金、再保等通用中臺和客戶統一檢視和業務統一檢視等資料中臺。同類產品在這個通道內完成錄單、投保、保單生成、退保、批改以及向後端送數等操作。

保險產品通道主要隔離點在微前端和承保專屬業務中臺。同類產品使用同一個產品通道，不同類產品使用不同的產品通道，所有流程無交叉，程式碼、部署和功能隔離。保險產品通道包括領域內若干微前端和微服務組合成的若干個業務單元，這些業務單元能力組合成全部的領域能力，如車險中臺所在的投保業務單元和保單管理業務單元，共同組成車險承保領域能力。

保險訂單銷售模式方案

產品通道設計要點

承保流程中不同保險產品通道之間無交叉和互動。

同類產品承保業務流程在自己專屬產品通道內完成。

產品通道的意義

1. 業務專一性：領域模型更聚焦，功能更單一，前後端專案團隊規模更小，集中辦公，更專注於本領域內的業務邏輯和微前端。產品通道業務高度內斂，同類產品錄單、流程和規則基本相似，產品之間干擾小，使用者體驗會更好。

2. 職責專一性：產品通道完成了產品從前端到後端全部承保流程。中臺專案專職於產品承保業務中臺業務邏輯和微前端頁面的實現，因此誰負責產品，誰就負責微前端和專屬業務中臺建設，並保證全通道內業務的高可用。前端專案只需完成前端主頁面與微前端的整合，整合過程甚至不涉及到API，可以減輕前端整合壓力和介面開發的複雜度。尤其對於集團級跨子公司（主要問題是系統和業務相互不熟悉，介面和整合複雜，溝通成本高）的系統整合會帶來極大的好處，降低溝通成本和整合的複雜度。

3. 複用性：微前端和承保業務中臺都有高度的複用性。微前端可快速加入前端整合主頁面，或將微前端直接釋出成APP，實現快速響應和釋出。某些場景甚至一個微前端就是一個APP應用，完成單一場景產品的銷售。

4. 隔離性：同類產品的問題修復和程式碼修改在一個產品通道內，不會影響其他產品通道的業務。不同產品通道在物理和邏輯上隔離，業務單元的版本釋出和新產品上線相互之間不受影響。

5. 響應能力：新產品通道可以獨立開發、測試、整合和部署，完成部署後只需在整合主頁面完成微前端註冊和增加頁面路由即可上線銷售。

6. 測試和溝通成本低：一個產品通道由一箇中臺專案團隊負責。產品通道功能自包含，在一個通道內可以完成從前端到後端所有業務流程整合和測試，降低溝通和測試成本。

7. 技術敏感度低：微前端只要符合規範即可快速動態載入到前端整合主頁面，前端專案在前端整合過程中不需要關注中臺的技術實現和API整合，降低技術敏感度。

前端整合主頁面

前端整合主頁面類似門戶，整合所有微前端頁面，實現所有微前端的聚合。按照正確的邏輯（如根據客戶選擇產品，選擇載入產品對應的錄單微前端，完成錄單和投保）載入微前端頁面，協同配合完成完整的業務流程，給使用者提供一致的體驗。

前端整合主頁面和所有微前端須有統一的頁面風格，且符合前端的整合技術規範。

前端整合主頁面載入並組合各微前端，作為一個整體為客戶提供所有保險產品銷售的接觸和體驗介面，包括商品展示、錄單、購物車、訂單管理、支付管理以及退保和批改等保單管理操作。

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

1. 在錄單過程中，客戶選擇保險產品，前端整合主頁面根據客戶選擇的保險產品，獲取產品對應的錄單微前端路由，也就是錄單微前端URL地址，在主頁面指定區域載入錄單微前端頁面。錄單微前端負責錄單介面，投保微服務負責投保單生成等後端邏輯，兩者配合在產品通道內完成投保單的錄入和投保單生成。

2. 在保單管理過程中，前端整合主頁面根據客戶選擇的保險產品載入產品對應的保單管理微前端，兩者配合在產品通道內完成保單退保或批改。

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

現在越來越多的公司都在進行微前端的落地和應用，微前端主要技術方向有Mooa、Single-SPA、Web Components、Vue等開源前端框架，在此不做贅述。

微前端是前端建設的一個非常重要的方向和關注點，通過微前端的整合模式可以減輕系統開發的複雜度，降低前端整合的難度。它的主要價值和意義如下：

1. 前端整合簡單：前端專案只需關注前端整合主頁面與微前端的整合，不涉及到API整合和中臺技術實現細節，可真正實現模組化整合，實現拼圖式的開發，降低前端整合的複雜度和成本。

2. 專案職責專一：中臺專案從資料庫、中臺到微前端介面端到端地完成領域邏輯功能開發，確保領域業務單元內從前端到後端可用。由於團隊職責專一，專案成員都熟悉團隊內的業務和技術，從而降低開發過程因為溝通和整合出問題的風險。

3. 隔離和依賴性：每個團隊都有自己的關注點，各關注點邊界清晰，相互隔離，風暴都在茶壺內。業務單元在程式碼、邏輯和物理邊界都是隔離的，降低應用之間的依賴性。在出現問題時可實現快速問題定位和修復，並可將風險控制在一個業務單元內，不會影響其他業務單元的正常執行。版本釋出過程中不會影響其它業務單元的正常執行。

4. 降低溝通和測試成本：一箇中臺專案團隊從前端頁面到後端中臺業務邏輯，實現從開發、測試、整合和部署的全流程和全生命週期管理，降低前後端整合的測試和溝通成本。

5. 更敏捷的釋出：由於應用之間的隔離和依賴性降低，每一個小的變化都控制在業務單元內，專案團隊可以獨立按照自己的步調進行迭代開發，實現更快的釋出週期。

6. 降低技術敏感性：由於前端專案主要關注微前端的整合和前端技術，遮蔽了前端對中臺技術的要求，從而降低了前端專案技術的敏感性。在降低前端整合複雜度的同時，中臺專案可以更便捷的選擇和嘗試更多更合適的技術和架構，實現架構的演進。

7. 高度複用性：微前端和業務中臺都有高度的複用性。微前端可快速按需載入到前端整合主頁面，或將微前端直接釋出成APP，實現快速釋出。某些場景一個微前端就是一個APP應用。

參考文章

• 「微前端」- 將微服務理念擴充套件到前端開發（理論篇），作者：ThoughtWorks中國。

• 「微前端」- 將微服務理念擴充套件到前端開發（實踐篇），作者：ThoughtWorks中國。