一拍即合

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

那麼我在公司實施微服務的時候，也不是一拍腦袋想上就上的。剛入職公司的時候才3、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反饋給我。