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