.Net微服務實戰之技術架構分層篇

一拍即合

　　上一篇《.Net微服務實戰之技術選型篇》，從技術選型角度講解了微服務實施的中間件的選擇與協做，工欲善其事，必先利其器，中間件的選擇是做爲微服務的基礎與開始，也但願給一直想在.Net入門微服務的同行有一個很好的方向。在此篇從新整理了一下整個微服務項目的demo，但願對有須要的朋友起到必定的幫助：https://github.com/SkyChenSky/Sikiro 

　　那麼我在公司實施微服務的時候，也不是一拍腦殼想上就上的。剛入職公司的時候才三、4我的，產品給到個人規劃只有一個很簡單的系統，包含權限、客服IM、內容管理三個模塊，我當時想着優先證實咱們的開發能力和效率，因而使用簡單的單體架構不到三個星期項目就完成了。產品在咱們開發的期間把整個項目的規劃和平臺系統的劃分給梳理了一遍，終於讓我有一個很明確的技術實施方向，同時公司的人力成本預算也批了下來開始進行團隊擴招。

　　因而我與老領導商量了一下，在如今這個狀況，不管業務仍是團隊都具備使用微服務架構的可操做性，再採用部分DevOps的思想給與微服務實施的支持，能順利的實施落地微服務問題不大。咱們倆討論了一番，我有良好的微服務技術儲備，他有很好的運維支撐，就這樣咱兩達成了共識。因而我着手翻出了收藏已久的微服務中間件、架構分層、服務拆分的資料，今後開始了個人微服務實施之路。

PS:咱們討論實施微服務的時候除了以上堂而皇之的理由以外，其實還存有一點私心，就是如今企業招聘不少須要有實施微服務經驗的人才，可是80%的項目和同行又是沒有這樣的實施必要與經驗，這就是雞生蛋和蛋生雞的問題。我毫無隱瞞的說出咱們的私心並非慫恿你們冒着風險去實施，而是但願你們經過分析如今團隊的組織架構、技術儲備、業務架構，在條件容許的狀況下知足您的小小要求，微服務雖不是銀彈，但咱們也須要成長。

架構思惟

　　抽象是做爲架構思惟的核心，使咱們站在大局觀察，屏蔽細節；這系統劃分哪幾個模塊？模塊之間的如何協做的？抽象又能夠衍生出兩種思想劃分與協做。

　　劃分的目的是爲了定責與拆分，定責不是交通事故的定責而是劃定職責，明確模塊的使用場景，應該被什麼依賴？應該依賴什麼？拆分其實就是分而治之的思想，把一個複雜的大問題拆分紅一個個簡單而小的問題，化繁爲簡逐個擊破天然就迎刃而解。

　　協做的目的是整合劃分好的模塊，被拆分的模塊若是沒法整合到一塊兒，拆分則失去了他原有的意義。

不謀而合

 　　技術服務於架構，架構服務於業務，業務服務於商務。因此有明確的業務藍圖才能夠很好的規劃架構方向；選擇好合適的技術才能很好的支撐架構。此時咱們開始着手實施微服務，然而在實施時咱們還會考慮一個比較核心點，究竟如何微？粒度究竟到什麼程度？怎麼明確依賴關係？你們或多或少都會據說身邊同行有實施微服務的失敗案例：拆分粒度過細緻使系統複雜度太高；拆分粒度太粗又沒達到微服務該有的效果等。那麼是否在業界有一套科學的指導方法論？我認爲是有的，DDD戰略設計與分層架構。

　　埃裏克、埃文斯在2004年發表了《領域驅動設計》一書的，此後一直是雷聲大雨點小，在2014年軟件教父馬丁花給微服務一個全面描述，讓它走向一個高潮後，DDD終於贏來了他的春天。爲何說DDD適合微服務呢？DDD是一種經過劃分業務邊界，將複雜的業務領域簡單化的設計思想，也就是化繁爲簡。爲何在上文重點強調DDD戰略設計？DDD分爲戰略設計與戰術設計。

戰略設計

　　主要從業務視角出發，創建業務領域模型，劃分領域邊界，創建通用語言的界限上下文，界限上下文能夠做爲微服務設計的參考邊界。

戰術設計

　　主要從技術視角出發，側重於領域模型的技術實現，完成軟件開發和落地，例如咱們常討論的聚合根、實體、值對象、領域服務等代碼邏輯的設計與實現。

　　從以上兩點的描述能夠看出，戰略設計從業務視角出發，而架構服務於業務，二者都須要從業務出發，DDD戰略設計與微服務都有一樣的設計思想：分而治之、化繁爲簡，那麼戰略設計的思想徹底能夠做爲微服務架構設計的指導思想，此時此刻此場景不謀而合。

分層架構

　　也能夠叫N層架構（N>=2），其實本質在於劃分職責、隔離關注點，保證各層之間的差別足夠清晰，邊界足夠明顯，其特色自頂向下依賴，逐層傳遞。

縱向拆分

　　首先我按照分層架構的思想以縱向維度拆分，主要共分5層，UI層、聚合API服務層、基礎業務API服務層、基礎設施層、數據庫層。

       調用鏈路自頂往下，用戶-->UI-->API網關-->聚合API服務-->Consul+Consul Template+Nginx-->業務API服務-->數據庫

　　UI層

　　依賴於聚合API服務層，操做與接口11對應，主要負責可見便可得的工做：數據展現、交互動畫等。

　　入站API網關

　　主要負責聚合API服務層內外網隔離、入站規則控制，防止外部大流量沖垮內部服務。

　　聚合API服務層

　　被UI層依賴，依賴於基礎業務API服務層，主要負責基礎業務API服務層的接口的邏輯組合，不直連數據庫，可經過API網關暴露給UI層調用。

　　註冊服務中心

　　記錄基礎業務API服務層的服務IP列表，內網使用，銜接聚合API服務層與基礎業務API服務層。

　　基礎業務API服務層，

　　被聚合API服務層依賴，依賴於數據庫層，可作具體的數據庫讀寫處理，內網使用，同層服務之間不互相依賴引用。

　　數據庫層

　　包括非關係型數據庫與關係型數據庫。

　　基礎設施服務層

　　可被全部層都依賴，若是被UI層依賴則經過API網關暴露，若是被內網服務依賴則經過註冊發現，可直連數據庫。

　　出站API網關

　　主要負責基礎設施服務層內外網隔離，轉發第三方開放API請求，出站規則控制，防止被沒法把控的第三方服務而拖垮內部服務。

 橫向拆分

　　接下來，咱們能夠經過DDD劃分領域的方式進行服務的橫向維度的拆分。舉個例子：

 　  咱們平臺擁有三種不一樣業務領域的系統：客戶中心、企業管理系統、內部管理系統。

　　那麼，聚合API服務層則擁有客戶系統API服務、企業管理系統API服務，內部管理系統API服務。

　　客戶中心的擁有客戶信息管理、支付、訂單管理等業務模塊。

　　企業管理系統擁有訂單管理、權限管理、支付、倉儲等業務模塊。

　　內部管理系統擁有權限管理、報表、帳戶管理等業務模塊。

　　全部系統涉及到自定義訂單號、消息推送等業務。

　　從以上得知，核心域包括倉儲、訂單業務、客戶信息。通用域包括權限管理、帳戶認證、支付模塊、消息推送等。支撐域包括自定義訂單號。

　　所以基礎業務API層能夠劃分：倉儲API服務、訂單API服務、客戶API服務、權限API服務、認證API服務，支付API服務。

　　基礎設施API層能夠劃分：ID發號API服務，消息推送API服務。

　　若是隨着業務繼續擴大，團隊人數增多，則能夠更加的細分，例如倉儲拆分紅快運、集運等。支付拆分紅微信支付、支付寶等。

 項目示例

　　上一篇《.Net微服務實戰之技術選型篇》我整理了咱們公司使用的框架開源到了github，此次我拿了部分業務項目做爲示例並上傳了。

　　https://github.com/SkyChenSky/Sikiro 

　　首先想說明幾點：

　　1.這個不是標準，只是針對咱們公司狀況取捨後的結果，每一個公司的業務有複雜有簡單你們視狀況完善本身的項目。

　　2.爲了保護公司原有的業務隱私，我作了部分邏輯的刪除，因此你們若是看到不完整的邏輯是正常現象。

　　3.但願你們把思惟放高，不要死摳細節，求同存異。

　　4.代碼在原有的基礎上修改了名稱和引用路徑會有變化，若是有問題隨時在評論和github反饋給我。