微服務實戰(一)：落地微服務架構到直銷系統(什麼是微服務)

網上有不少關於微服務的文章，從不一樣的維度對微服務進行了相關的講述；有些高屋建瓴，有些涉及細節，有些側重理論，有些側重代碼，都是很是不錯的瞭解微服務的文章。

咱們這個系列的文章的維度主要是實戰落地，也就是咱們在日常工做以及產品開發過程當中，考慮爲何選擇微服務架構風格，以及如何將微服務的架構風格落地到咱們實際的一個大健康行業直銷電商系統的主要過程。本文涉及有少許理論的部分，主要是架構與實現的層面，讓你們真正對微服務能瞭解、能認識、能實現。

本系列文章從「DDD實戰進階第一波」系列繼續。若是你對咱們落地的系統的需求以及DDD不是特別瞭解的話，建議你先查看咱們DDD實戰進階第一波的文章，由於DDD是微服務架構風格的一個重要組成部分，並且本系列的需求和代碼會緊接着DDD實戰進階第一波。

微服務這幾年很火。其實一種概念或一種架構風格的興起，必定有它背後的緣由。咱們在這裏不講所謂高大上的理由，而是講我通過將近18年的軟件設計與開發工做，在有選擇性的成功使用了微服務架構風格的體會。

微服務架構風格的興起，主要是由於客戶對現代化的產品和系統的須要，對軟件開發自己提出了更高的要求。

1.服務獨立性：

一個系統一般在設計時，架構師(或項目經理)會根據對需求的理解劃分爲設計上的多個界限上下文，每一個界限上下文包含本界限上下文須要的領域模型。在實際

開發過程當中，會主要出現如下幾個問題：

a.多小組並行開發：在一個大型系統中，界限上下文會分給不一樣的開發小組進行開發。有些界限上下文之間在業務上有依賴關係，但咱們在技術上也作了依賴。好比訂單界限上下文依賴產品界限上下文或客戶界限上下文，這樣一般要先實現被依賴的對象或功能（至少要先定義出來），才作依賴它的功能，影響開發的效率。

b.部署與運行的問題：由於存在依賴關係，因此被依賴界限上下文的組件發生變化時，該組件還要更新到依賴它的界限上下文中，管理複雜。並且一旦被依賴的界限上下文出現問題，依賴它的界限上下文也會出現問題。服務獨立部署到不一樣的主機或Docker上由於存在引用，也會對管理和部署上帶來障礙。

c.技術選擇的問題：由於技術上存在依賴關係（一般是經過引用），因此多個小組採用的技術一般是相同的。但在某些狀況下，界限上下文應該選用最適合它的技術，並且界限上下文之間也不該該經過Restful風格的接口互相訪問。

2.高性能大併發：

現代的互聯網應用，須要支持大量用戶的併發訪問操做，傳統的經典開發方式，會主要出現如下幾個問題：

a.用例接口的直接暴露：一般咱們會將功能暴露成接口，而接口經過調用應用服務（應用服務協調倉儲和邏輯）完成用例功能，若是邏輯複雜，數據庫訪問負載大，特別該用例經過事務同時操做多個數據訪問上下文，速度會很慢，很長時間纔給前端返回結果，若是用戶多，該問題會被放大。

b.查詢的問題：一個界限上下文除了用例的功能，一般咱們會有不少查詢的功能提供給用戶。一般咱們會將一個界限上下文的全部功能都作到一個Api項目中，另外業務和查詢使用的模型是同一個，這樣也會影響性能。

3.事件溯源與最終一致性：

在大併發的系統中，咱們不能使用事務來保證強一致性，由於這樣會影響性能，咱們應該採用多界限上下文的最終一致性來保證數據的正確。

a.傳統的經典開發方式，沒法實現最終一致性的主要緣由是沒有記錄一個對象變化歷史的事件信息，因此當咱們在經過非事務同時更新多個界限上下文的數據時，當須要回滾先更新界限上下文的對象數據時，不知道該對象的歷史狀態，也就沒辦法還原。

b.業務單據的歷史修改信息：一般在業務系統中，咱們有需求須要知道一個對象（好比一張單據）的歷史修改記錄時，由於沒有記錄事件數據，因此沒法很好的跟蹤對象的歷史變化狀態。

4.服務的高可用行：

如今對服務的高可用要求愈來愈高，咱們應該儘可能保證應用提供的服務可用，不然會丟失用戶，形成業務損失。服務的高可用一般會因爲如下兩個方面緣由引發：

a.數據庫服務或數據庫down掉、數據訪問網絡鏈接中斷。

b.WebApi網絡地址不可用、WebApi訪問負載大、對用戶的請求響應異常。

 

爲了解決上述的開發過程、部署過程以及運行過程當中的問題，咱們須要一種新的架構風格來指導產品的開發、部署與運行。這種架構風格就是微服務。微服務架構風格提出如下幾個

要求來解決上述問題，並應對用戶與市場對咱們的產品與軟件提出的更高的要求。

1.經過構建EDA（事件驅動的架構）並結合消息總線，解決服務獨立性的問題。

2.經過構建CQRS（命令查詢職責分離的架構）並結合消息總線，解決大併發高性能的問題。

3.經過構建Event存儲與還原的機制，實現事件溯源，解決最終一致性的問題，也解決業務上有對象歷史狀態獲取需求。

4.經過數據庫產品自己高可用行，彈性訪問實現數據訪問高可用；經過實現WebApi負載平衡、重試與斷路器、Api網關與服務中心等方式，實現WebApi的高可用。

所以，我對微服務的定義是：微服務是一種架構風格，它旨在經過將一個大系統分解成多個小系統（DDD中的界限上下文），並經過一系列的架構建議，解決服務獨立性、性能、事件溯源與最終一致、高可用性的需求，最終使多個界限上下文可以相互協做，組合成一個爲用戶提供高質量的服務的大系統。

 

本系列文章涉及到的技術包括C#、Asp.net core、EF core、RabbitMq、Ocelot、Consul、Docker等。

 

本系列文章經過直銷系統的實際案例，最終將實現以下的兩個整體架構圖，並將直銷系統的業務鏈接到它們。

QQ討論羣：309287205 

微服務實戰視頻請關注微信公衆號：