基於DDD思想的微服務架構學習導向 架構學習前言 因為公司架構組決定在後續的項目系統開發中採用 “微服務架構+.netcore” 模式，這個模式直接用於實踐，對於我們公司這些沒有實踐經驗的人來說，開發難度是顯而易見的。正因為如此，公司架構師才數次為我們研發人員進行架構培訓，講關於這套架構所涉及的知識 ...
基於DDD思想的微服務架構學習導向
架構學習前言
因為公司架構組決定在後續的項目系統開發中採用 “微服務架構+.netcore” 模式，這個模式直接用於實踐，對於我們公司這些沒有實踐經驗的人來說，開發難度是顯而易見的。正因為如此，公司架構師才數次為我們研發人員進行架構培訓，講關於這套架構所涉及的知識，比如.net core，efcore，consul，cap等。
現在這套系統我們已經比較熟悉了，開發也逐漸走上了正軌，所以我想回過頭來總結一下公司目前所採用的這套框架，分析流程以及其中使用的知識點，開源項目等。
架構解析
前端
- npm + webpack 開發工作流
- react 為UI層，以及antd作為基礎控制項實現
- react route 路由實現
- 公共狀態用的是 redux
- redux-saga 編寫 redux 業務流
- postal 來實現事件驅動來解耦
目前我們前端框架所用到的就是上面這些，因為我這次主要是講後端框架的一些實現細節，所以前端後面有機會在細說
後端
後端框架總的來說還算比較好理解的，我首先來回顧一下架構總的流程設計思路。
首先從前端發出請求開始，首先會經過 Nginx 負載均衡到我們的Host層（我個人理解為 “api轉接，數據包裝” 層，這裡是不含任何業務邏輯的，以下稱為Host層），然後Host層經過Api網關伺服器分發到各個領域服務，這裡面的過程是用的是開源的 consul 分散式服務註冊和發現的工具，經過api網關分發到具體的領域服務之後，就到了我們的重點的 “業務層” 了，所有的業務都是在這裡編寫開發的，業務領域層與值持久化層交互，而我們的資料庫方面也是集群的，採用讀寫分離的原則（因為mysql在這方面配置使用起來簡單，比如主從庫同步等，這也是我們使用 mysql 的一個主要原因），用 efcore 對 dbwrite 寫數據，dapper 對 dbread 讀數據。除此之外，緩存，報表等需要對數據進行特定的加工也都是在這個數據存儲層。
接著我們回過頭來到領域服務層，這裡包含了所有的業務邏輯，自然也包含了領域事件，在架構中，事件分兩種：
- 領域事件（Domain Event）
- 集成事件（Integration Event）
領域事件我們是用的 MediatR 開源組件來解耦領域與領域之間的交互。
集成事件我們是用的 CAP + kafka 來實現進程級別的領域服務交互來保證最終一致性，這裡面的冪等提交，容錯，階段提交，重試措施，熔斷等就不說了，這方面是個大內容我也僅僅只是瞭解，不過是我日後學習的一個方面。
講到這裡整個微服務架構的流程就差不多了，但是這僅僅只是我們公司架構的運行過程，比較簡單，但是於我們來說又複雜，也不跟其他公司的架構做對比了
總結
現在來簡要概括一下後端的流程架構
- 前端開始請求
- 進過 Nginx 負載均衡來到Host層（實現高負載）
- Host層在由 Consul api網關伺服器 分配到各個領域層
- Domain layer 負責業務的編寫與 db 的交互
- Domain layer 中由 MediatR 和 CAP 實現同進程，垮進程間的領域交互
- 數據，緩存都在 持久化層
- 另外還有單獨的業務級別的任務調度（HangFire，Quartz等）
所涉及的知識點，也就是我後面要分析以及學習的知識
- MediatR 實現同進程間的領域交互
- FluentValidation 驗證組件（獨立驗證）來解耦業務
- CAP 實現跨進程的領域事件調度
- Autofac
- Dapper（NPoco）
- Polly 異常重試
