微服務實戰(九)：落地微服務架構到直銷系統(回顧總結)

這個系列咱們大概寫了八篇文章，將微服務的最重要的內容過了一遍。固然其中有些內容尚未涉及到，好比Docker（不是微服務架構風格中必須的）等，關於Docker咱們本身能夠在網上找找其餘文章。

這篇文章就來回顧下微服務架構風格是如何落地的，若是你對如下回顧的內容都很清楚並已經有一些實踐的經驗，那麼恭喜你，你已經進入了微服務的大門。

 

1、什麼是微服務

由於客戶對現代化的產品和系統的須要，對軟件開發自己提出了更高的要求，這些要求包括：

1.服務獨立性，互不影響：包括各小組能獨立開發；服務能獨立部署與運行；不一樣上下文中能夠有不一樣的技術選型。

2.高性能大併發：接口可以快速響應請求；隊列處理業務可以支持大併發；查詢的性能要好。

3.事件溯源與最終一致性：可以跟蹤對象歷史變化狀態；可以回溯對象到任意的狀態。

4.服務高可用性：數據儘可能可以訪問；服務儘可能可以調用；服務最好能集中管理。

 

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

 

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

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

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

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

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

 

2、實現微服務

1.實現微服務的最關鍵內容就是實現一個事件總線，事件總線既用於微服務之間的通訊鬆耦合、也對大併發高性能的要求提供底層支持。

 

實現的事件總線的大概步驟是：

a.定義事件消息接口。

b.定義事件消息處理器接口。

c.定義事件消息與事件消息處理器接口的關聯關係。

d.定義消息發佈、消息訂閱、消息總線相關的接口。

e.實現事件消息基類與事件消息總線基類。

f.實現事件消息與處理器的關聯。

 

2.實現微服務的第二個關鍵內容就是要支持CQRS架構，這樣在對抗大併發時會有很好的支持。

 

 

實現CQRS架構大併發的大概方法與原理是：

a.命令與查詢走不一樣的WebApi服務，將更改系統狀態的行爲與查詢的行爲作很好的隔離，並能夠部署微服務到不一樣的服務器上，固然還能夠經過NLB作進一步的擴展。

b.命令端的WebApi並不直接處理調用用例完成，而是接收到用戶命令時，將命令消息發佈到消息總線，而後馬上返回一個操做信息給用戶，這樣用戶體驗很好，不須要等待業務邏輯完成與持久化完成。

c.命令處理器WebApi從消息隊列偵聽到消息，而後進行處理，處理的主要內容是完成領域邏輯調用，直接添加事件數據到事件存儲中。這裏須要注意的是，並非持久化到業務數據庫中。首先完成領域邏輯調用，能夠獲得用例最終正確的領域對象，而後存儲事件時，存儲此次領域對象的狀態，而且是直接添加。這樣作的好處有：一是加快持久化，二是可以保存領域對象每次變化的信息，將來能夠用於歷史追蹤、事件溯源與最終一致性。

事件存儲是個重要的基礎，它主要的實現步驟是：構建事件存儲表、重構事件類支持事件存儲、實現存儲的事件對象、實現事件對象的存儲功能。

d.命令處理器將領域對象發送到消息總線中，事件處理器會偵聽隊列，並最終將消息信息涉及到的領域對象持久化到業務數據庫中。

e.在查詢WebApi中，能夠直接查詢業務庫，若是業務庫並不適合多表鏈接查詢時，能夠再單獨作個拉平的爲查詢提供服務的查詢庫。查詢庫的內容能夠經過業務庫更新成功後，發佈消息到另外一個隊列中，而後經過處理器來處理這些數據到查詢庫中。

 

另外須要特別注意的是，在實際的高性能系統中，查詢可能並不會走業務庫（寫庫），而是單獨作一個查詢庫（讀庫）並實現相關的查詢WebApi，查詢庫的結構是按照前端查詢方面的原型來作設計。這樣就很好的作到了讀寫分離，關於讀寫分離的最佳實踐，你們能夠參考微信公衆號文章。

 

3.實現微服務的第三個關鍵內容是服務的高可用性。

a.保證微服務負載可用：這裏的負載要實現數據庫層面、微服務WebApi層面、重試策略、斷路器模式。

b.保證微服務地址可用：主要經過API網關與服務中心實現。

 

至此，咱們就基本上實現了微服務架構風格的系統。必定要注意的是，當咱們須要應對市場對系統提到的要求，而這種要求只有微服務架構風格才能很好支持時，才使用；不要盲目的使用，也不要所有使用，好比CQRS就根據產品的特色能夠選擇性的使用，必定要讓你的架構是可演進的，而不是照搬。

 

3、總體架構圖

根據整個系列的文章，實際上咱們就實現了這兩個總體架構圖：

 

 

QQ討論羣：309287205 

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