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

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

本系列文章從“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 

微服務實戰視訊請關注微信公眾號：