一文帶你瞭解單體應用到微服務劃分的幾種方法

在進行企業中臺規劃或微服務架構設計時候,微服務模塊究竟應該如何劃分,已經劃分的粒度究竟如何才合適。這個估計是所有人在進行微服務轉型的時候都遇到的最典型的例子。

實際上對於微服務模塊劃分,微服務 API 接口識別是整個企業中臺規劃建設方法論中的一個關鍵內容,我在前面也談到過當前中臺 + 微服務架構思想實際上仍然可以參考原來的 SOA + 企業架構諮詢的方法進行架構規劃,但是對傳統方法論本身存在優化和改進。

對於該點後續準備通過中臺規劃建設方法論詳細展開來談,今天僅僅是從一些關鍵的點上來說明下微服務模塊劃分問題。

單體到微服務劃分大原則

注意這裏講的是大原則不是絕對原則。對於傳統的單體應用在轉到微服務的時候我們也是給出實際實踐總結的一些大的原則做爲參考。

原則 1:劃分爲 < 10 個微服務模塊

一個傳統的單體應用,在進行劃分的時候最好不要超過 10 個微服務模塊。注意這裏指的業務功能模塊不包括底層的系統管理,流程引擎等技術模塊。

大家可能也會看到傳統的單體應用一般也不會超過 10 個以上的一級功能菜單,因此在劃分微服務的時候也可以參考一級功能菜單進行劃分。

注:這個原則不絕對,比如一些類似 OA,IT 運維流程管理類系統,所有的業務功能流程之間基本沒有任何耦合性,這種業務系統可以將微服務劃分的更細也沒有大的影響。

原則 2:強數據關聯模塊不要拆分

簡單來說就是有些系統基本就是圍繞一個核心數據或業務對象展開的管理系統,比如我們說的資源管理系統,資產管理系統等。

對於這些系統的資源,資產等核心數據,建議都不要再進行微服務拆分,這些數據之間本身存在強數據關聯和一致性要求,如果進行微服務拆分後續很難保證事務一致性要求。

原則 3:以數據聚合驅動業務功能聚合

這個理解起來困難,簡單來說就是微服務劃分不僅僅是上層業務功能模塊劃分,而且包括了數據庫的拆分,因此在劃分微服務的時候首先要考慮數據域的拆分,基於數據和功能的 CRUD 分析來考慮數據的聚合關聯要求。先拆分好數據域,再來考慮數據域裏面有哪些業務功能。

原則 4:從縱向功能劃分思路到橫向分層思路轉變

在微服務劃分裏面,同樣需要結合 SOA 的橫向分層思想,即:

傳統的單體應用你會發現在進行微服務劃分的時候,本身微服務也體現出分層屬性,即有些屬於底層的業務對象,實體,數據提供類微服務;有些數據業務功能和規則類微服務;而還有些屬於上層的流程和服務功能組合類微服務。

因此在進行微服務劃分的時候應該從數據 -》功能規則 -》流程的分層模型維度綜合考慮。

原則 5:高內聚,松耦合的基礎原則

當然,在進行微服務拆分的時候高內聚,松耦合的原則不變。而如何確保拆分的數據庫,拆分的業務功能模塊滿足高內聚松耦合的原則。

在前面做企業架構規劃分析的時候就經常談到,在進行業務流程分析,業務架構和數據架構規劃的時候,核心會產生業務流程,業務功能,業務數據對象等關鍵的信息,而我們要做的就是對這些關鍵進行交互矩陣分析來識別業務模塊,業務數據之間的內聚特徵。其中包括:

業務組件交互矩陣:橫向和豎向都是業務組件,內容單元格里是具體的業務交互接口點,通過此矩陣可以看出業務組件的劃分是否會導致大量的業務接口存在,分析每個業務接口產生的原因,以進行組件的合併、業務功能轉移等。

業務對象和業務交互矩陣:橫向是業務組件和業務功能,縱向是具體的業務對象,內容單元格是具體的 CRUD 信息(即傳統的 CRUD 矩陣分析)。對於同一個業務對象,CUD 操作儘量減少分離,而讀操作則可以共享,以減少業務對象的多頭管理和維護,將業務表單和數據的維護儘量控制在同一個業務大組件中完成,減少數據間的交互和傳遞。

流程交互分析矩陣:橫向是具體的流程信息,縱向是具體的流程活動信息,在這個矩陣圖上可以看到同一個流程活動或流程片段往往存在於多個不同的流程。該分析的重要作用是對流程建模中可複用的流程片段或流程活動進行抽象和分析。

功能業務組件分析矩陣:橫向是具體的業務組件,縱向是業務功能,在該交互分析上重點是分析具體的可複用的業務功能,以對可複用的業務功能進一步進行抽取,形成可複用的服務。

微服務劃分的指導思想

對於微服務模塊劃分,簡單來說你完全可以借鑑傳統單體應用業務功能模塊劃分的思路進行,只是在這個基礎上會增加了上面原則裏面談到的數據驅動,SOA 分層思路等。

微服務劃分切忌不要劃分的太細,粒度劃分的越細,後面微服務集成和管理的難度就越大。

再次糾正一個觀點,即我們這裏指的微服務模塊是從數據庫到業務邏輯到前臺都可以獨立自治和部署的模塊。即使在一個微服務模塊內部,你還可以拆分不同的組件,比如拆分爲多個 JAR 包,但是這個不是我們獨立管理的單位。

在 IT 應用架構規劃大中臺的概念下,實際上中臺包括了技術中臺和業務中臺,對於技術中臺重點是各個技術組件和技術服務能力的實現,而對於業務中臺則主要包括了數據能力和業務規則處理能力的提供。

對於業務中臺本身也是分層,包括了最基本的數據類中心和業務處理類中心。

數據類中心本身又包括了基礎主數據類和核心共享業務單據類,比如我們看到的產品中心,用戶中心,屬於基礎主數據類。而對於訂單中心,庫存中心則屬於業務共享數據類。

業務處理類則主要是進行核心業務功能和邏輯的處理,類似的包括了交易中心,結算中心,計費中心等,都可以看做是業務處理類的中臺模塊。當然,業務處理類中臺也包括關鍵的領域服務提供組件,即這類組件需要調用底層更多基礎原子模塊的核心接口能力,經常組合後再提供出整合的組合能力。

技術中臺模塊的劃分 - 完全垂直徹底解耦

技術中臺主要負責提供各類的技術服務能力,其中包括了消息,緩存,存儲 (內存,結構化和非結構化),文件,日誌,通知,規則引擎,流程等各種通用的和業務無關的技術能力。可以看到對於各種技術服務之間,本身沒有任何的耦合性,完全是垂直獨立,因此對於技術中臺中的微服務模塊劃分粒度,完全可以一個技術服務一個微服務模塊,完全獨立管理和部署,相互之間沒有任何影響。

技術中臺屬於我們傳統的 PaaS 技術平臺必須要管控和治理的一部分內容,對於技術服務的接入,消費和調用,日誌等都需要在 PaaS 管控治理平臺能夠查詢和監控。

業務中臺模塊的劃分 - 圍繞數據仍然是核心

注意這裏的業務中臺模塊,就是一個獨立的微服務模塊,一個獨立的有數據庫,邏輯層到前端界面展現的小應用。只是這個業務中臺本身還將自己的關鍵能力以 API 接口服務的方式開放給前臺應用調用。

業務中臺模塊劃分粒度相當重要,粒度太細後期集成和管控都相當複雜,同時由於模塊劃分太細也容易引入更多前臺應用開發帶來的分佈式事務處理場景。而粒度太粗的話本身又無法起到獨立自治,後期易於變更運維,本身靈活敏捷的作用。

如果說做互聯網電商,由於有類似阿里等的成功實踐,可能大家閉着眼都知道應該包括類似產品中心,庫存中心,用戶中心,訂單中心,結算中心等各類的中臺模塊。但是如果是全新的業務類型,或者說針對企業內部的管理信息化,究竟應該如何去劃分中臺。

  1. 基礎主數據類模塊劃分

如果一個基礎主數據就一個微服務模塊,那麼會導致我們的微服務模塊的量極大,比如用戶中心,組織中心,人員中心,客戶中心,物料中心,供應商中心等。那麼這種劃分方法在企業內信息化上並不太合理。

如果是按標準的主數據管理系統的業務模塊劃分,實際上它不是按照數據維度進行劃分,一般我們說主數據系統會包括了元數據和數據對象管理,數據集成和調度,數據清理,流程引擎,數據內容管理等各個模塊。而無法真正體現出以數據爲中心的思想。

因此對於基礎主數據類微服務模塊,最好的方式是按數據域進行拆分,比如對於用戶,組織,崗位,人員等劃分到一個人力域數據中心,對於供應鏈,物料編碼,採購類別等劃分到採購或供應鏈域微服務模塊。這樣劃分的好處就是既實現了一定程度上的模塊拆分和松耦合,同時按域劃分後,同一個域的基礎主數據本身在一個數據庫中進行管理,這些基礎主數據本身可能存在一定的耦合關係,那麼這些耦合關係的處理將不再需要提升到分佈式事務層面去處理。

  1. 業務功能類模塊劃分

談業務功能類模塊的劃分,實際上又回到我們在傳統進行單個業務系統架構設計的時候如何進行組件劃分這個話題。如何劃分組件,簡單來說就是要高內聚和松耦合,確保每個組件儘可能的獨立自治,組件和組件之間的干擾最小。

當時我們在做單系統的時候,往往對於組件劃分考慮的並不徹底,就是說在代碼層面確實劃分了組件,組件也可以進行獨立打包,但是對於各個組件仍然對應一個數據庫。那麼我們就經常犯一個錯誤,即雖然在業務和邏輯層兩個組件看似松耦合了,但是很多耦合性轉變到了數據庫層了。舉個簡單的例子,數據庫的一個關聯查詢很容易就實現了,但是涉及到關聯的兩個表,其核心 Owner 卻是不同的兩個組件模塊。

所以對於上層的業務組件劃分,本身原來我們也談兩個方法,這裏拿採購管理系統舉例。

不論是哪種方法,我們看到在進行微服務模塊劃分的時候,關鍵還是要把基礎和共享數據找出來,然後纔是去處理上層的業務。再來考慮業務流程,業務規則處理等還需要單獨設置哪些微服務模塊。即使是用方法一,我們也看到每個模塊都一定有自己關鍵的主屬 Owner 數據。

劃分微服務模塊,實際上相對關鍵的一個步驟就是拆分數據庫的過程。要把原來我們一個數據庫的內容,拆分並對應到各個微服務模塊上。主屬 Owner,對該數據具備了完全的 CRUD 能力。而其它模塊更多的是單純的數據導入或數據查詢。

大中臺更多的是體現其核心數據集中和共享能力,而不是業務流程和規則處理能力,因此更多的業務流程處理都應該歸結到前臺更加合適。

一個大中臺的訂單中心,可以和各種各樣的前臺微服務模塊對接,不管是網頁還是 APP 應用,不管是渠道,政企還是電商,但是最終都是將正式流程處理完成後生效的訂單數據導入到訂單中心。然後訂單中心再提供完整的訂單能力開放。

下面我將對上面講到的一些核心指導思想展開進行描述。

流程分析識別大階段

當我們在分析一個業務或業務系統的時候,經常會用到端到端的業務流程分析,而業務流程分析完成後一個完整的流程階段也就清晰了。

一個大流程的各個階段往往就是我們劃分微服務時候重要參考。

比如上圖我們在進行一個供應鏈端到端流程分析的時候,在流程梳理清楚後我們可以很清楚的看到採購需求,採購請購,採購合同,採購訂單,物流管理等大的流程執行階段。而這些階段就是我們劃分微服務的一個重要參考。

其次,在同一個階段裏面涉及到不同的職能部門單元的時候,我們看到耦合性本身也較弱,那麼就還可以進一步進行拆分。比如對於採購需求階段可以進一步拆分爲採購需求和採購計劃,而對於採購溯源階段,可以進一步拆分爲採購請購和招投標兩個獨立的微服務。

即你在進行微服務拆分的時候,除了基於流程分析,企業當前的業務部門和崗位角色設置情況也可以作爲一個重要參考。

比如上圖的業務部門設置也可以清晰的看到對於採購計劃,採購合同可以獨立爲微服務。而我們流程分析裏面沒有識別到的類似採購績效管理,採購執行監控也是獨立的微服務模塊。

從已有業務系統模塊劃分入手

對於已有的單體業務系統,當然還可以從已有的業務系統入手進行微服務模塊劃分。要知道對於傳統的單體應用業務模塊劃分的時候本身也是考慮了高內聚,松耦合的道理。

但是傳統的單體應用構建的問題在哪裏呢?

我們常說的單體應用本身的構建更多的是從縱向業務功能的角度出發,是偏縱向垂直方式構建業務功能的,而對於微服務架構思想下,我們引入了 SOA 架構思路,即會去思考當前的業務功能和流程,如何從數據 -》功能 -》流程的橫向分層思路來構建。

這也是我們在參考傳統的業務系統架構的時候需要調整的地方。

圖片來自網絡

上圖是我們常見的一個採購管理系統的功能架構圖。

從這個圖裏面可以看到如果進行微服務拆分,對於採購計劃,採購尋源,採購合同管理,採購訂單管理,採購基礎數據,供應商協同,供應商管理就是可以進行拆分的微服務。

當然在這個過程中,你會發現有些地方還可以拆分。

比如上圖裏面的訂單執行,對於訂單執行你再按業務流程分析就會發現本身還可以按流程階段,業務職能域劃分爲採購訂單管理,物流管理,發票和結算管理等幾個獨立的業務域。而這些就是我們可以做爲獨立的微服務模塊。

其次,一直在談的分層思路,結合上圖我們進一步解釋。

因此即使參考已有的業務系統模塊劃分,也要考慮核心共性基礎數據下沉爲獨立的微服務,而流程類業務功能上升到前臺類應用也作爲獨立的微服務。

圖片來源網絡

當然在這個過程中可以多參考些業務系統的功能架構圖,多對比分析,然後再結合企業實際的業務需求和業務流程情況進行整合。

以數據架構分析入手劃分微服務

數據驅動入手,簡單來說就是一開始要弱化進行全面的業務流程分析,就是你不需要進行全面的流程分析就能夠快速的構建識別和定義業務中臺。

對於業務對象,我們可以初步分爲兩個類型

在我們看常見的中臺架構圖的時候,我們都會注意到中臺的各個模板一般都會以中心來命名,比如說用戶中心,產品中心,訂單中心,商品中心等。而這裏面出現的就是各個核心共享業務對象或數據對象。而我們要做的就是把這些關鍵的數據對象或業務對象識別出來。

如何識別?

我們可以調研企業各個業務部門有哪些常見的業務表單或電子表單,然後對這些表單數據進行定義。

即你關注的不是流程,而是最終的結果數據。比如我們說人力資源部門,你會看到存在請假單,用章申請單,工資條,培訓需求表,培訓考勤表等,這些就是最終的業務表單或數據對象。

我們可能不會去詳細的分析培訓組織流程,但是我們會關心培訓會產生哪些業務對象數據。當然,很多時候你必須仍然要了解業務才能夠識別出業務對象,只是不需要對業務流程做詳細流程分析。

數據域劃分 - 基礎主數據 -》共享數據 -》附屬數據

數據架構裏面有一個重點就是數據域劃分,而數據域的劃分往往是我們參考進行拆庫的一個重點,因此如何劃分數據域成爲一個關鍵點。當然最基本的仍然是數據之間的高內聚和低耦合性。

首先是識別和定義主數據

對於數據域的劃分,我們首先還是考慮先識別和定義主數據,先將主數據識別出來,然後對主數據再進行一次數據域劃分,具體仍然可以參考供應鏈,財務,人力資源等核心業務域進一步細劃分數據域。在這裏注意不一定按照互聯網的做法每個關鍵對象就劃分爲一箇中臺模塊,比如用戶中心,商品中心等,而是可以按業務域劃分爲不同的中臺模塊,核心原因還是考慮數據的耦合性。

其次,我們要尋找核心動態數據,其中核心動態數據我們理解爲兩個關鍵特點

對於第二點,最終態數據即爲你可能走了很多業務流程,最終形成的正式生效的數據,類似合同,訂單,庫存信息等,這些都是最終態數據。當然並不是說類似採購申請單,入庫單,出庫單這些數據不重要,而是我們首先要找到最終態數據。

我們可以看到大部分的業務流程,不論是業務流還是人工審批流最終的目標剛好就是形成正式生效的終態數據對象。而這些數據對象在內容形成後又將能力暴露出來給外部其他業務流程或業務功能使用。

按這個概念來說,對於我們做報賬系統的差旅報銷申請單,借款申請單也不屬於最終態數據,因爲這些申請單走完流程後最終的目標是形成各類憑證信息。

因此我們找尋到終態數據,基於這些來構建中臺模塊,類似訂單中心,合同中心,庫存中心就屬於這類情況。

最後一個,即附屬數據,也可以理解爲流程中的申請單據數據,這些數據是否放到中臺需要根據我們實際情況來看,具體的原則主要包括兩點。

我們構建的中臺模塊可以有多種呈現方式,有一種中臺就是完全是邏輯層 + 服務提供沒有任何業務功能(只保留系統管理員維護數據功能)。還有一種中臺就是既提供服務能力,也提供業務功能。

那麼如果要徹底按分層思路構建中臺,這個時候附屬數據不用劃到中臺中心裏面,反之則可以劃入。這個時候的中臺既提供業務功能也提供能力服務。

比如對於訂單中心,我們可以將採購訂單申請,審批流程也劃入到訂單中心裏面,這樣訂單中心既提供訂單能力服務,也提供訂單業務功能。你也可以訂單中心只提供訂單能力服務(包括訂單導入,查詢,變更等),而將其他業務功能全部劃分到前臺去。

可以看到,對於互聯網中臺構建往往是後者,而對於企業中臺構建建議採用前者兼顧兩個方面。

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/IpW-11ZzTHa_MGOdIEuLww