這個系列我們大概寫了八篇文章，將微服務的最重要的內容過了一遍。當然其中有些內容還沒有涉及到，比如Docker（不是微服務架構風格中必須的）等，關於Docker我們自己可以在網上找找其他文章。
這篇文章就來回顧下微服務架構風格是如何落地的，如果你對以下回顧的內容都很清楚並已經有一些實踐的經驗，那麼恭喜你，你已經進入了微服務的大門。
一、什麼是微服務
因為客戶對現代化的產品和系統的需要，對軟體開發本身提出了更高的要求，這些要求包括：
1.服務獨立性，互不影響：包括各小組能獨立開發；服務能獨立部署與執行；不同上下文中可以有不同的技術選型。
2.高效能大併發：介面能夠快速響應請求；佇列處理業務能夠支援大併發；查詢的效能要好。
3.事件溯源與最終一致性：能夠跟蹤物件歷史變化狀態；能夠回溯物件到任意的狀態。
4.服務高可用性：資料儘量能夠訪問；服務儘量能夠呼叫；服務最好能集中管理。
為了解決上述的開發過程、部署過程以及執行過程中的問題，需要一種新的架構風格來指導產品的開發、部署與執行，這種架構風格就是微服務。
微服務架構風格提出以下幾個要求來解決上述問題，並應對使用者與市場對我們的產品與軟體提出的更高要求。
1.通過構建EDA（事件驅動的架構）並結合訊息匯流排，解決服務獨立性的問題。
2.通過構建CQRS（命令查詢職責分離的架構）並結合訊息匯流排，解決大併發高效能的問題。
3.通過構建Event儲存與還原的機制，實現事件溯源，解決最終一致性的問題，也解決業務上有物件歷史狀態獲取的需求。
4.通過資料庫產品本身高可用行，彈性訪問實現資料訪問高可用；通過實現WebApi負載平衡、重試與斷路器、Api閘道器與服務中心等方式，實現WebApi的高可用。
所以，微服務是一種架構風格，它旨在通過將一個大系統分解成多個小系統（DDD中的界限上下文），並通過一系列的架構建議，解決服務獨立性、效能、事件溯源與最終一致、高可用性的需求，最終使多個界限上下文能夠相互協作，組合成一個為使用者提供高質量的服務的大系統。
二、實現微服務
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就根據產品的特點可以選擇性的使用，一定要讓你的架構是可演進的，而不是照搬。
三、整體架構圖
根據整個系列的文章，實際上我們就實現了這兩個整體架構圖：
