如何進(jìn)行微服務(wù)架構(gòu)中的模塊劃分和服務(wù)識別

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)如何進(jìn)行微服務(wù)架構(gòu)中的模塊劃分和服務(wù)識別，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

最近在進(jìn)行微服務(wù)架構(gòu)的交流和討論中，除了談到微服務(wù)技術(shù)架構(gòu)外，客戶往往更加掛你微服務(wù)模塊的劃分粒度，已經(jīng)具體的微服務(wù)API接口的識別和定義問題，因此這篇文章將重點(diǎn)談下微服務(wù)架構(gòu)實(shí)踐過程中的微服務(wù)模塊劃分和服務(wù)識別。

首先我們還是再總結(jié)在在跨系統(tǒng)間的接口集成中服務(wù)的識別和定義方法，可以總結(jié)為：

1. 基于流程架構(gòu)和業(yè)務(wù)架構(gòu)，從跨系統(tǒng)交互流程出發(fā)，分析業(yè)務(wù)交互接口點(diǎn)，識別關(guān)鍵的業(yè)務(wù)服務(wù)能力。

2. 基于數(shù)據(jù)架構(gòu)和主數(shù)據(jù)建模分析，識別關(guān)鍵的數(shù)據(jù)服務(wù)能力。

3. 基于技術(shù)架構(gòu)和共性平臺層技術(shù)組件的分析和定義，以能力開放原則識別關(guān)鍵技術(shù)服務(wù)能力。

因此對于跨系統(tǒng)間的集成，對于服務(wù)識別和定義思路是相對清晰的。那么在傳統(tǒng)方法中業(yè)務(wù)系統(tǒng)的劃分和定義粒度又是如何?在前面企業(yè)架構(gòu)分析中，我曾經(jīng)談到過，通過跨系統(tǒng)交互流程分析，識別出最細(xì)粒度的業(yè)務(wù)功能模塊和功能單元，然后再從底向上進(jìn)行聚合，以CRUD分析為主要方法，多次迭代出***的滿足高內(nèi)聚，松耦合條件的業(yè)務(wù)系統(tǒng)劃分。這里面沒有一個(gè)精確方法，但是卻有該大原則下的指導(dǎo)方法。

微服務(wù)模塊的劃分

微服務(wù)模塊的劃分不是什么新鮮事物，就是傳統(tǒng)的業(yè)務(wù)系統(tǒng)內(nèi)部的業(yè)務(wù)功能組件的劃分，但是我要注意到的關(guān)鍵一點(diǎn)還是業(yè)務(wù)組件本身的粒度和大小。原來沒有完全拆分為獨(dú)立的微服務(wù)模塊的時(shí)候，我們一個(gè)業(yè)務(wù)系統(tǒng)可以劃分20個(gè)以上的業(yè)務(wù)模塊，因?yàn)橛捎跀?shù)據(jù)庫本身沒有拆分，同時(shí)業(yè)務(wù)模塊間的調(diào)用本身又是內(nèi)部的API調(diào)用，因此感覺不到有什么問題。但是如果把這20個(gè)業(yè)務(wù)模塊完全拆分為獨(dú)立的微服務(wù)模塊，你才會(huì)發(fā)現(xiàn)模塊間的緊耦合或者說大量的交互集成接口，會(huì)導(dǎo)致整個(gè)系統(tǒng)集成和交互關(guān)系相對復(fù)雜，后期很難管理。

這也是我們原來經(jīng)常強(qiáng)調(diào)的，傳統(tǒng)的一個(gè)大業(yè)務(wù)系統(tǒng)劃分微服務(wù)模塊的時(shí)候，盡量是劃分到6到8個(gè)模塊比較合適，當(dāng)你本身的IT成熟度達(dá)到一定水平后你可以劃分的更加細(xì)點(diǎn)。同時(shí)在微服務(wù)模塊劃分的時(shí)候一定要考慮數(shù)據(jù)庫本身的劃分，即底層的數(shù)據(jù)庫也是劃分開的，類似我原來談私有云PaaS的時(shí)候談的數(shù)據(jù)庫的水平拆分。

究竟如何拆?實(shí)際上方法仍然是一樣的，還是要分析單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部的流程，然后分解到具體的業(yè)務(wù)組件或功能，再按照高內(nèi)聚的原則進(jìn)行聚合，盡量確保各個(gè)微服務(wù)模塊之間的交互最少。同時(shí)對于大家都要用到的基礎(chǔ)數(shù)據(jù)模塊，仍然采用共性下沉的策略和思路進(jìn)行。同時(shí)一個(gè)有價(jià)值的參考方法是，分析該業(yè)務(wù)系統(tǒng)承載的主體業(yè)務(wù)流程是什么?然后分析這個(gè)業(yè)務(wù)流程可以橫向劃分微哪幾個(gè)獨(dú)立的階段，然后先將這些獨(dú)立的階段劃分微不同的微服務(wù)模塊，在劃分好后再進(jìn)行CRUD分析進(jìn)行修正。

微服務(wù)接口的識別和定義

不管是傳統(tǒng)的跨業(yè)務(wù)系統(tǒng)間交互的接口，還是微服務(wù)模塊間的交互API接口，我一直強(qiáng)調(diào)的一個(gè)關(guān)鍵就是接口一定要保證粗粒度特性，實(shí)現(xiàn)業(yè)務(wù)規(guī)則和邏輯的高度內(nèi)聚。接口面對的應(yīng)該是核心的業(yè)務(wù)對象，領(lǐng)域?qū)ο蠡驑I(yè)務(wù)規(guī)則能力暴露，而不是微服務(wù)模塊內(nèi)部的數(shù)據(jù)庫表的CRUD操作的暴露。如果將數(shù)據(jù)庫表CRUD操作暴露為Rest  API接口并在微服務(wù)模塊間相互調(diào)用。一個(gè)是耦合性增加，一個(gè)是完全沒有實(shí)現(xiàn)高內(nèi)聚的基本要求。

基于以上基礎(chǔ)原則，我們在進(jìn)行微服務(wù)接口識別和定義的時(shí)候，仍然需要從業(yè)務(wù)流程出發(fā)，梳理清楚完成一個(gè)完整的業(yè)務(wù)流程各個(gè)微服務(wù)模塊之間有哪些業(yè)務(wù)交互接口，然后將這些接口識別出來后，才進(jìn)行接口的拆分或合并，最終形成微服務(wù)API接口，只有這樣最終的微服務(wù)API接口才是可以復(fù)用的。

由于我們已經(jīng)將基礎(chǔ)數(shù)據(jù)管理獨(dú)立到一個(gè)基礎(chǔ)模塊，因此可以基于數(shù)據(jù)能力開放和暴露的原則將這些基礎(chǔ)數(shù)據(jù)的能力以查詢服務(wù)方式暴露為獨(dú)立的數(shù)據(jù)服務(wù)能力接口。要求仍然是領(lǐng)域?qū)ο蠹壎皇菙?shù)據(jù)庫表級別。

每一個(gè)微服務(wù)模塊在開發(fā)和實(shí)現(xiàn)的時(shí)候，如果都是基于領(lǐng)域驅(qū)動(dòng)架構(gòu)設(shè)計(jì)的思路進(jìn)行的，那么只有微服務(wù)模塊的領(lǐng)域?qū)ο蠖x完整，完全可以將領(lǐng)域?qū)ο蟮哪芰σ訟PI接口的方式暴露出去，這里既包括了查詢類接口，也包括了導(dǎo)入或數(shù)據(jù)插入類接口，其次對于核心的業(yè)務(wù)規(guī)則的實(shí)現(xiàn)可以獨(dú)立暴露為接口服務(wù)。

在前面微服務(wù)架構(gòu)咨詢里面我曾經(jīng)談到過，在多個(gè)微服務(wù)模塊之上，還可能有一個(gè)微服務(wù)能力組合層，實(shí)現(xiàn)類似流程服務(wù)和組合服務(wù)類的能力。如果存在這種情況，那么***也是獨(dú)立的微服務(wù)模塊來實(shí)現(xiàn)，這個(gè)微服務(wù)模塊本身可能并不對應(yīng)具體的數(shù)據(jù)庫，而是將底層的微服務(wù)模塊之間服務(wù)能力進(jìn)行組合，形成新的接口服務(wù)能力。

由于在微服務(wù)架構(gòu)設(shè)計(jì)中，我們更加強(qiáng)調(diào)數(shù)據(jù)不落地的方式進(jìn)行后續(xù)的開發(fā)和實(shí)現(xiàn)，由于數(shù)據(jù)不落地，我們就可以更好的以能力開放的思路來進(jìn)行接口的識別和暴露。簡單來說有哪些數(shù)據(jù)或業(yè)務(wù)對象在你這，有哪些業(yè)務(wù)規(guī)則屬于你管理?這些都在經(jīng)過粗粒度聚合后，都可以識別和定位為微服務(wù)API接口。

上述就是小編為大家分享的如何進(jìn)行微服務(wù)架構(gòu)中的模塊劃分和服務(wù)識別了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。