使用gRPC, NATS, CockroachDB構建EventSourcing/CQRS的微服務

使用gRPC, NATS Streaming和CockroachDB等技術構建微服務

示例的程式碼可以在此處獲得:https://github.com/shijuvar/go-distributed-sys。為了方便理解，我簡化了概念並提供了一個示例，展示如何使用gRPC，NATS等技術構建分散式系統。

NATS Streaming用於訊息傳遞

在EventSourcing架構中，當您從一個微服務中釋出一個事件時，其他微服務可以對這些事件做出反應，併在執行自己的本地事務後釋出另一組事件。基於微服務的系統中的單個事務可以跨越多個微服務，其中我們可以透過一系列的事件來執行事務。每個聚合狀態的更改都可以視為一系列的事件，這是關於系統的不可變事實。為了釋出事件以讓其他微服務知道系統中發生了某些事情，我們需要使用訊息傳遞系統。在此示例中，我們使用NATS Steraming Server作為事件流系統來構建事件驅動的微服務。事件驅動的反應式架構是構建大規模可擴充套件微服務的架構方法的絕佳選擇。如果您對NATS和NATS Streaming不熟悉，請檢視我關於基本NATS的文章這裡和NATS Streaming 在這裡[1]。我認為NATS是構建分散式系統的神經系統，我一直致力於Go生態系統。

gRPC用於構建APIs

在示例中，事件儲存提供了一個API去執行命令，這是一個基於gRPC的API。gRPC是一個高效能、開源的遠端過程呼叫框架，可以在任何地方執行。它使Client和Server能夠透明地進行通訊，並使構建連線系統更加容易。gRPC被廣泛稱為微服務中的通訊協議。如果您透過API在微服務之間進行通訊，那麼gRPC是很好地選擇，如果您不瞭解gRPC，可以檢視我的文章[2]。

示例演示

下圖是示例程式碼的結構：

這是程式碼的架構圖：

這是示例中的基本工作流程：

1. 客戶端應用程式將訂單釋出到HTTP API。

2. 一個HTTP API(OrderService)接收的命令，然後使用gRPC API建立一個事件，透過一個命令將事件儲存到Event Store，儲存的是事件的不可變的日誌。

3. Event Store透過API執行命令，然後向NATS Streaming伺服器釋出order-created事件，以便讓其他服務知道建立了一個事件。

4. 付款服務（PaymentService）訂閱事件order-created，然後進行付款，然後透過Event Store API建立另一個事件order-payment-debited。

5. 查詢服務（orderquery-store1和orderquery-store2作為佇列訂閱者）也訂閱了order-created事件，該事件同步資料模型以提供查詢檢視的聚合狀態。

6. Event Store API在事件儲存上執行命令以建立事件order-payment-debited，並向NATS Streaming伺服器釋出事件，以便讓其他服務知道付款已被記入借方。

7. 餐廳服務（RestaurantService）最終批准訂單。

8. Distributed Saga管理分散式事務併在失敗時進行無效事務回滾（暫未實現）

EventSourcing的事件儲存

這是訊息Event的結構體定義。示例中的每個狀態更改都被視為事件，併在Event Store中執行命令。

清單1. 訊息的結構協議緩衝區中的事件:

Event Store提供了一個gRPC API用於儲存事件。這是Event Store實現中的基本程式碼塊：

清單2. gRPC伺服器中的基本實現:

每當新事件透過其gRPC API作為不可變日誌持久化儲存到Event Store中時，它就會透過NATS Streaming伺服器釋出事件，讓其他微伺服器知道新事件已經釋出，因此所有使用者微服務都可以對這些事件做出反應。在此示例中，事件從Event Store API本身釋出到訊息傳遞系統(NATS Streaming)中。在實際場景中，它可能來自單個微服務，也可能來自協調單個業務事務跨越多個微服務的Distributed Saga。

訂閱用於構建反應式微服務的事件

當您將事件持久儲存到Event Store中時，它透過NATS Streaming釋出新事件，如果您的微服務對這些事件感興趣，則微服務可以對這些事件進行訂閱。在這裡，我們使用NATS Streaming訂閱事件。在此示例中，當建立order-created 事件時，PaymentService訂閱該事件，並建立另一個名為order-payment-debited的事件。

清單3. 對order-created事件做出反應的NATS Streaming訂戶客戶端:

訂閱事件以構建聚合檢視的查詢模型

在CQRS中，它將應用程式分為兩部分：命令和查詢。這裡的命令是使用EventSourcing實現的，EventSourcing使用不可變事件日誌的Event Store來構建應用程式狀態。為了建立查詢模型，我們還可以在執行命令操作時訂閱事件。在這個例子中，服務orderquery-store 1和orderquery-store2透過QueueGroup訂閱，透過NATS Streaming訂閱事件order-created。NATS中的QueueGroup訂閱服務允許您在不進行任何配置的情況下實現負載均衡。

清單4. 用於同步查詢模型的NATS Streaming QueueGroup訂戶客戶端:

這裡，每當釋出order-created事件時，訂閱者根據事件執行一些邏輯併進行資料同步，透過將資料儲存到資料儲存中來建立聚合的非規範化檢視，它用於CQRS架構中的查詢模型。

使用CockroachDB持久儲存

使用CQRS的一個主要好處是，您可以為寫入操作和查詢操作使用不同的資料模型，因此您還可以使用不同的資料庫技術。在此示例演示中，我們使用CockroachDB執行命令和查詢模型。CockroachDB是一個分散式資料庫，用於構建可在災難中恢復的全球可擴充套件雲服務。在Go應用程式中，您可以使用類似於PostgreSQL的驅動程式（如github.com/lib/pq）來處理SQL 。如果您正在使用package database/sql進行事務，請使用CockroachDB的官方庫github.com/cockroachdb/cockroach-go/crdb。在示例演示中，使用CockroachDB的永續性邏輯在程式碼的store包中實現。g官方包crdb的方法ExecuteTx可以幫助您將事務執行到CockroachDB中。

清單5. 使用包crdb在CockroachDB中的事務實現:

這是Event Store的不可變日誌，用於建立最終的訂單:

Event Store的事件表有一個名為eventdata的欄位，我們將整個事件資料作為JSON檔案儲存到該欄位，它對構建應用程式狀態以及構建查詢檢視很有用。