一拍即合

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

　　那么我在公司實(shí)施微服務(wù)的時(shí)候，也不是一拍腦袋想上就上的。剛?cè)肼毠镜臅r(shí)候才3、4個(gè)人，產(chǎn)品給到我的規(guī)劃只有一個(gè)很簡(jiǎn)單的系統(tǒng)，包含權(quán)限、客服IM、內(nèi)容管理三個(gè)模塊，我當(dāng)時(shí)想著優(yōu)先證明我們的開發(fā)能力和效率，于是使用簡(jiǎn)單的單體架構(gòu)不到三個(gè)星期項(xiàng)目就完成了。產(chǎn)品在我們開發(fā)的期間把整個(gè)項(xiàng)目的規(guī)劃和平臺(tái)系統(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ù)儲(chǔ)備，他有很好的運(yùn)維支撐，就這樣咱兩達(dá)成了共識(shí)。于是我著手翻出了收藏已久的微服務(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ù)儲(chǔ)備、業(yè)務(wù)架構(gòu)，在條件允許的情況下滿足您的小小要求，微服務(wù)雖不是銀彈，但我們也需要成長。

架構(gòu)思維

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

　　劃分的目的是為了定責(zé)與拆分，定責(zé)不是交通事故的定責(zé)而是劃定職責(zé)，明確模塊的使用場(chǎng)景，應(yīng)該被什么依賴？應(yīng)該依賴什么？拆分其實(shí)就是分而治之的思想，把一個(gè)復(fù)雜的大問題拆分成一個(gè)個(gè)簡(jiǎn)單而小的問題，化繁為簡(jiǎn)逐個(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í)我們還會(huì)考慮一個(gè)比較核心點(diǎn)，究竟如何微？粒度究竟到什么程度？怎么明確依賴關(guān)系？大家或多或少都會(huì)聽說身邊同行有實(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ū)動(dòng)設(shè)計(jì)》一書的，此后一直是雷聲大雨點(diǎn)小，在2014年軟件教父馬丁花給微服務(wù)一個(gè)全面描述，讓它走向一個(gè)高潮后，DDD終于贏來了他的春天。為什么說DDD適合微服務(wù)呢？DDD是一種通過劃分業(yè)務(wù)邊界，將復(fù)雜的業(yè)務(wù)領(lǐng)域簡(jiǎn)單化的設(shè)計(jì)思想，也就是化繁為簡(jiǎn)。為什么在上文重點(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í)體、值對(duì)象、領(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ì)思想：分而治之、化繁為簡(jiǎn)，那么戰(zhàn)略設(shè)計(jì)的思想完全可以作為微服務(wù)架構(gòu)設(shè)計(jì)的指導(dǎo)思想，此時(shí)此刻此場(chǎng)景不謀而合。

分層&切割

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

橫向拆分（橫向分層）

　　首先我按照分層架構(gòu)的思想以縱向維度拆分，通俗點(diǎn)就是按照自定向下的按照各層職責(zé)進(jìn)行分解，主要共分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對(duì)應(yīng)，主要負(fù)責(zé)可見即可得的工作：數(shù)據(jù)展示、交互動(dòng)畫等。

　　入站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)用。

　　注冊(cè)服務(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ù)依賴則通過注冊(cè)發(fā)現(xiàn)，可直連數(shù)據(jù)庫。

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

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

 縱向拆分（縱向切割）

　　接下來,我們可以通過DDD進(jìn)行服務(wù)的切割,通俗點(diǎn)描述就是將同一個(gè)較大的服務(wù)拆解成為多個(gè)較小的服務(wù)。

　　那么究竟要根據(jù)什么樣的信息和過程進(jìn)行拆解呢?有一個(gè)工作坊叫作"事件風(fēng)暴"，事件風(fēng)暴是一個(gè)從拆解到整合的過程，過程中需要領(lǐng)域?qū)＜遥ㄐ枨筇岢稣撸?/strong>和技術(shù)實(shí)踐者協(xié)作完成領(lǐng)域建模。