一拍即合
上一篇《.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回報給我。