一拍即合

　　上一篇《.Net微服務(wù)實(shí)戰(zhàn)之技術(shù)選型篇》，從技術(shù)選型角度講解了微服務(wù)實(shí)施的中間件的選擇與協(xié)作，工欲善其事，必先利其器，中間件的選擇是作為微服務(wù)的基礎(chǔ)與開始，也希望給一直想在.Net入門微服務(wù)的同行有一個(gè)很好的方向。在此篇重新整理了一下整個(gè)微服務(wù)項(xiàng)目的demo，希望對有需要的朋友起到一定的幫助：https://github.com/SkyChenSky/Sikiro

　　那么我在公司實(shí)施微服務(wù)的時(shí)候，也不是一拍腦袋想上就上的。剛?cè)肼毠镜臅r(shí)候才3、4個(gè)人，產(chǎn)品給到我的規(guī)劃只有一個(gè)很簡單的系統(tǒng)，包含權(quán)限、客服IM、內(nèi)容管理三個(gè)模塊，我當(dāng)時(shí)想著優(yōu)先證明我們的開發(fā)能力和效率，于是使用簡單的單體架構(gòu)不到三個(gè)星期項(xiàng)目就完成了。產(chǎn)品在我們開發(fā)的期間把整個(gè)項(xiàng)目的規(guī)劃和平臺系統(tǒng)的劃分給梳理了一遍，終于讓我有一個(gè)很明確的技術(shù)實(shí)施方向，同時(shí)公司的人力成本預(yù)算也批了下來開始進(jìn)行團(tuán)隊(duì)擴(kuò)招。

　　于是我與老領(lǐng)導(dǎo)商量了一下，在現(xiàn)在這個(gè)情況，無論業(yè)務(wù)還是團(tuán)隊(duì)都具有使用微服務(wù)架構(gòu)的可操作性，再采用部分DevOps的思想給與微服務(wù)實(shí)施的支持，能順利的實(shí)施落地微服務(wù)問題不大。我們倆討論了一番，我有良好的微服務(wù)技術(shù)儲備，他有很好的運(yùn)維支撐，就這樣咱兩達(dá)成了共識。于是我著手翻出了收藏已久的微服務(wù)中間件、架構(gòu)分層、服務(wù)拆分的資料，從此開始了我的微服務(wù)實(shí)施之路。

PS:我們討論實(shí)施微服務(wù)的時(shí)候除了以上冠冕堂皇的理由之外，其實(shí)還存有一點(diǎn)私心，就是現(xiàn)在企業(yè)招聘很多需要有實(shí)施微服務(wù)經(jīng)驗(yàn)的人才，但是80%的項(xiàng)目和同行又是沒有這樣的實(shí)施必要與經(jīng)驗(yàn)，這就是雞生蛋和蛋生雞的問題。我毫無隱瞞的說出我們的私心并不是慫恿大家冒著風(fēng)險(xiǎn)去實(shí)施，而是希望大家通過分析現(xiàn)在團(tuán)隊(duì)的組織架構(gòu)、技術(shù)儲備、業(yè)務(wù)架構(gòu)，在條件允許的情況下滿足您的小小要求，微服務(wù)雖不是銀彈，但我們也需要成長。

架構(gòu)思維

　　抽象是作為架構(gòu)思維的核心，使我們站在大局觀察，屏蔽細(xì)節(jié)；這系統(tǒng)劃分哪幾個(gè)模塊？模塊之間的如何協(xié)作的？抽象又可以衍生出兩種思想劃分與協(xié)作。

　　劃分的目的是為了定責(zé)與拆分，定責(zé)不是交通事故的定責(zé)而是劃定職責(zé)，明確模塊的使用場景，應(yīng)該被什么依賴？應(yīng)該依賴什么？拆分其實(shí)就是分而治之的思想，把一個(gè)復(fù)雜的大問題拆分成一個(gè)個(gè)簡單而小的問題，化繁為簡逐個(gè)擊破自然就迎刃而解。

　　協(xié)作的目的是整合劃分好的模塊，被拆分的模塊如果無法整合到一起，拆分則失去了他原有的意義。

不謀而合

?　　技術(shù)服務(wù)于架構(gòu)，架構(gòu)服務(wù)于業(yè)務(wù)，業(yè)務(wù)服務(wù)于商務(wù)。所以有明確的業(yè)務(wù)藍(lán)圖才可以很好的規(guī)劃架構(gòu)方向；選擇好合適的技術(shù)才能很好的支撐架構(gòu)。此時(shí)我們開始著手實(shí)施微服務(wù)，然而在實(shí)施時(shí)我們還會考慮一個(gè)比較核心點(diǎn)，究竟如何微？粒度究竟到什么程度？怎么明確依賴關(guān)系？大家或多或少都會聽說身邊同行有實(shí)施微服務(wù)的失敗案例：拆分粒度過細(xì)導(dǎo)致系統(tǒng)復(fù)雜度過高；拆分粒度太粗又沒達(dá)到微服務(wù)該有的效果等。那么是否在業(yè)界有一套科學(xué)的指導(dǎo)方法論？我認(rèn)為是有的，DDD戰(zhàn)略設(shè)計(jì)與分層架構(gòu)。

　　埃里克、埃文斯在2004年發(fā)表了《領(lǐng)域驅(qū)動設(shè)計(jì)》一書的，此后一直是雷聲大雨點(diǎn)小，在2014年軟件教父馬丁花給微服務(wù)一個(gè)全面描述，讓它走向一個(gè)高潮后，DDD終于贏來了他的春天。為什么說DDD適合微服務(wù)呢？DDD是一種通過劃分業(yè)務(wù)邊界，將復(fù)雜的業(yè)務(wù)領(lǐng)域簡單化的設(shè)計(jì)思想，也就是化繁為簡。為什么在上文重點(diǎn)強(qiáng)調(diào)DDD戰(zhàn)略設(shè)計(jì)？DDD分為戰(zhàn)略設(shè)計(jì)與戰(zhàn)術(shù)設(shè)計(jì)。

戰(zhàn)略設(shè)計(jì)

　　主要從業(yè)務(wù)視角出發(fā)，建立業(yè)務(wù)領(lǐng)域模型，劃分領(lǐng)域邊界，建立通用語言的界限上下文，界限上下文可以作為微服務(wù)設(shè)計(jì)的參考邊界。

戰(zhàn)術(shù)設(shè)計(jì)

　　主要從技術(shù)視角出發(fā)，側(cè)重于領(lǐng)域模型的技術(shù)實(shí)現(xiàn)，完成軟件開發(fā)和落地，例如我們常討論的聚合根、實(shí)體、值對象、領(lǐng)域服務(wù)等代碼邏輯的設(shè)計(jì)與實(shí)現(xiàn)。

　　從以上兩點(diǎn)的描述可以看出，戰(zhàn)略設(shè)計(jì)從業(yè)務(wù)視角出發(fā)，而架構(gòu)服務(wù)于業(yè)務(wù)，兩者都需要從業(yè)務(wù)出發(fā)，DDD戰(zhàn)略設(shè)計(jì)與微服務(wù)都有同樣的設(shè)計(jì)思想：分而治之、化繁為簡，那么戰(zhàn)略設(shè)計(jì)的思想完全可以作為微服務(wù)架構(gòu)設(shè)計(jì)的指導(dǎo)思想，此時(shí)此刻此場景不謀而合。

分層架構(gòu)

　　也可以叫N層架構(gòu)（N>=2），其實(shí)本質(zhì)在于劃分職責(zé)、隔離關(guān)注點(diǎn)，保證各層之間的差異足夠清晰，邊界足夠明顯，其特點(diǎn)自頂向下依賴，逐層傳遞。

縱向拆分

　　首先我按照分層架構(gòu)的思想以縱向維度拆分，主要共分5層，UI層、聚合API服務(wù)層、基礎(chǔ)業(yè)務(wù)API服務(wù)層、基礎(chǔ)設(shè)施層、數(shù)據(jù)庫層。

? ? ? ?調(diào)用鏈路自頂往下，用戶-->UI-->API網(wǎng)關(guān)-->聚合API服務(wù)-->Consul+Consul Template+Nginx-->業(yè)務(wù)API服務(wù)-->數(shù)據(jù)庫

　　UI層

　　依賴于聚合API服務(wù)層，操作與接口11對應(yīng)，主要負(fù)責(zé)可見即可得的工作：數(shù)據(jù)展示、交互動畫等。

　　入站API網(wǎng)關(guān)

　　主要負(fù)責(zé)聚合API服務(wù)層內(nèi)外網(wǎng)隔離、入站規(guī)則控制，防止外部大流量沖垮內(nèi)部服務(wù)。

　　聚合API服務(wù)層

　　被UI層依賴，依賴于基礎(chǔ)業(yè)務(wù)API服務(wù)層，主要負(fù)責(zé)基礎(chǔ)業(yè)務(wù)API服務(wù)層的接口的邏輯組合，不直連數(shù)據(jù)庫，可通過API網(wǎng)關(guān)暴露給UI層調(diào)用。

　　注冊服務(wù)中心

　　記錄基礎(chǔ)業(yè)務(wù)API服務(wù)層的服務(wù)IP列表，內(nèi)網(wǎng)使用，銜接聚合API服務(wù)層與基礎(chǔ)業(yè)務(wù)API服務(wù)層。

　　基礎(chǔ)業(yè)務(wù)API服務(wù)層，

　　被聚合API服務(wù)層依賴，依賴于數(shù)據(jù)庫層，可做具體的數(shù)據(jù)庫讀寫處理，內(nèi)網(wǎng)使用，同層服務(wù)之間不互相依賴引用。

　　數(shù)據(jù)庫層

　　包括非關(guān)系型數(shù)據(jù)庫與關(guān)系型數(shù)據(jù)庫。

　　基礎(chǔ)設(shè)施服務(wù)層

　　可被所有層都依賴，如果被UI層依賴則通過API網(wǎng)關(guān)暴露，如果被內(nèi)網(wǎng)服務(wù)依賴則通過注冊發(fā)現(xiàn)，可直連數(shù)據(jù)庫。

　　出站API網(wǎng)關(guān)

　　主要負(fù)責(zé)基礎(chǔ)設(shè)施服務(wù)層內(nèi)外網(wǎng)隔離，轉(zhuǎn)發(fā)第三方開放API請求，出站規(guī)則控制，防止被無法把控的第三方服務(wù)而拖垮內(nèi)部服務(wù)。

?橫向拆分

　　接下來，我們可以通過DDD劃分領(lǐng)域的方式進(jìn)行服務(wù)的橫向維度的拆分。舉個(gè)例子：

?　? 我們平臺擁有三種不同業(yè)務(wù)領(lǐng)域的系統(tǒng)：客戶中心、企業(yè)管理系統(tǒng)、內(nèi)部管理系統(tǒng)。

　　那么，聚合API服務(wù)層則擁有客戶系統(tǒng)API服務(wù)、企業(yè)管理系統(tǒng)API服務(wù)，內(nèi)部管理系統(tǒng)API服務(wù)。

　　客戶中心的擁有客戶信息管理、支付、訂單管理等業(yè)務(wù)模塊。

　　企業(yè)管理系統(tǒng)擁有訂單管理、權(quán)限管理、支付、倉儲等業(yè)務(wù)模塊。

　　內(nèi)部管理系統(tǒng)擁有權(quán)限管理、報(bào)表、賬戶管理等業(yè)務(wù)模塊。

　　所有系統(tǒng)涉及到自定義訂單號、消息推送等業(yè)務(wù)。

　　從以上得知，核心域包括倉儲、訂單業(yè)務(wù)、客戶信息。通用域包括權(quán)限管理、賬戶認(rèn)證、支付模塊、消息推送等。支撐域包括自定義訂單號。

　　因此基礎(chǔ)業(yè)務(wù)API層可以劃分：倉儲API服務(wù)、訂單API服務(wù)、客戶API服務(wù)、權(quán)限API服務(wù)、認(rèn)證API服務(wù)，支付API服務(wù)。

　　基礎(chǔ)設(shè)施API層可以劃分：ID發(fā)號API服務(wù)，消息推送API服務(wù)。

　　如果隨著業(yè)務(wù)繼續(xù)擴(kuò)大，團(tuán)隊(duì)人數(shù)增多，則可以更加的細(xì)分，例如倉儲拆分成快運(yùn)、集運(yùn)等。支付拆分成微信支付、支付寶等。

?項(xiàng)目示例

　　上一篇《.Net微服務(wù)實(shí)戰(zhàn)之技術(shù)選型篇》我整理了我們公司使用的框架開源到了github，這次我拿了部分業(yè)務(wù)項(xiàng)目作為示例并上傳了。

　　https://github.com/SkyChenSky/Sikiro?

　　首先想說明幾點(diǎn)：

　　1.這個(gè)不是標(biāo)準(zhǔn)，只是針對我們公司情況取舍后的結(jié)果，每個(gè)公司的業(yè)務(wù)有復(fù)雜有簡單大家視情況完善自己的項(xiàng)目。

　　2.為了保護(hù)公司原有的業(yè)務(wù)隱私，我做了部分邏輯的刪除，所以大家如果看到不完整的邏輯是正常現(xiàn)象。

　　3.希望大家把思維放高，不要死摳細(xì)節(jié)，求同存異。

　　4.代碼在原有的基礎(chǔ)上修改了名稱和引用路徑會有變化，如果有問題隨時(shí)在評論和github反饋給我。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的.Net微服务实战之技术架构分层篇的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。