如何將 Redis 用于微服務通信的事件存儲

來源：Redislabs
作者：Martin Forstner

翻譯：Kev×××）

以我的經驗，將某些應用拆分成更小的、松耦合的、可協同工作的獨立邏輯業務服務會更易于構建和維護。這些服務（也被稱為微服務）各自管理自己的技術棧，因此很容易獨立于其他服務進行開發和部署。前人已經總結了很多關于使用這種架構設計的好處，在此我就不再贅述了。關于這種設計，有一個方面我一直在重×××沒有它，將會導致一些有趣的挑戰。雖然構建松耦合的微服務是一個非常輕量級和快速的開發過程，但是這些服務之間共享狀態、事件以及數據的通信模型卻不那么簡單。我使用過的最簡單的通信模型就是服務間直接通信，但是這種模型被 Fernando Dogio 明確地證明一旦服務規模擴大就會失效，會導致服務崩潰、重載邏輯以及負載增加等問題，從而可能引起的巨大的麻煩，因此應該盡量避免使用這種模型。還有一些其他通信模型，比如通用的發布/訂閱模型、復雜的 kafka 事件流模型等，但是最近我在使用 Redis 構建微服務間的通信模型。

?

拯救者 Redis！

微服務通過網絡邊界發布狀態，為了跟蹤這種狀態，事件通常需要被保存在事件存儲中。由于事件通常是一種異步寫入操作的不可變流的記錄（又被稱為事務日志），因此適用于以下場景：

1.?順序很重要（時間序列數據）

2.?丟失一個事件會導致錯誤狀態

3.?回放狀態在任何給定時間點都是已知的

4.?寫操作簡單且快捷

5.?讀操作需要更多的時間，以至于需要緩存

6.?需要高可擴展性，Service之間都是解耦的，沒有關聯

使用 Redis，我始終可以輕松實現發布-訂閱模式。但現在，Redis 5.0 提供了新的Streams 數據類型，我們可以以一種更加抽象的方式對日志數據結構進行建模-使之成為時間序列數據的理想用例（例如最多一次或最少一次傳遞語義的事務日志）。基于雙主功能，輕松簡單的部署以及內存中的超快速處理能力，Redis 流成為一種管理大規模微服務通信的必備工具。基本的模型被稱為命令查詢職責分離（CQRS）,它將命令和查詢分開執行，命令使用 HTTP 協議，而查詢采用 RESP(Redis 序列化協議)。讓我們使用一個例子來說明如何使用 Redis 作為事件存儲。

?

OrderShop簡單應用概述

我創建了一個簡單但是通用的電子商務應用作為例子。當創建/刪除客戶、庫存物品或訂單時，使用 RESP 將事件異步傳遞到 CRM 服務，以管理 OrderShop 與當前和潛在客戶的互動。像許多常見應用程序的需求一樣，CRM 服務可以在運行時啟動和停止，而不會影響其他微服務。這需要捕獲在其停機期間發送給它的所有消息以進行后續處理。
下圖展示了 9 個解耦的微服務的互連性，這些微服務使用由 Redis 流構建的事件存儲進行服務間通信。他們通過偵聽事件存儲（即 Redis 實例）中特定事件流上的任何新創建的事件來執行此操作。

圖1. OrderShop 架構?

?

我們的 OrderShop 應用程序的域模型由以下 5 個實體組成：

• 顧客

• 產品

• 庫存

• 訂單

• 賬單

通過偵聽域事件并保持實體緩存為最新狀態，事件存儲的聚合功能僅需調用一次或在響應時調用。

圖2. OrderShop 域模型

?

安裝并運行OrderShop

按照如下步驟安裝并運行 OrderShop 應用：

1. 從這里下載代碼倉庫：

https://github.com/Redislabs-Solution-Architects/ordershop

2.?確保已經安裝了 Docker Engine和Docker Compose

3.?安裝 Python3：

https://python-docs.readthedocs.io/en/latest/starting/install3/osx.html

4.?使用 docker-compose up啟動應用程序

5.?使用 pip3 install -r client / requirements.txt 安裝需求

6.?然后使用 python3 -m unittest client / client.py 執行客戶端

7.?使用 docker-compose stop crm-service 停止 CRM 服務

8.?重新執行客戶端，您會看到該應用程序正常運行，沒有任何錯誤

?

深入了解

以下是來自 client.py 的一些簡單測試用例，以及相應的 Redis 數據類型和鍵。

?

我選擇流數據類型來保存這些事件，因為它們背后的抽象數據類型是事務日志，非常適合我們連續事件流的用例。我選擇了不同的鍵來分配分區，并決定為每個流生成自己的條目 ID，ID 包含秒“-”微秒的時間戳（為了保持 ID 的唯一，并保留了鍵/分區之間事件的順序）。我選擇集合來存儲 ID（UUID），并選擇列表和哈希來對數據建模，因為它反映了它們的結構，并且實體緩存只是域模型的簡單投影。

?

結論

Redis 提供的各種數據結構-包括集合，有序集合，哈希，列表，字符串，位數組，HyperLogLogs，地理空間索引以及現在的流-可以輕松適應任何數據模型。流包含的元素不僅是單個字符串，而且是由字段和值組成的對象。范圍查詢速度很快，并且流中的每個條目都有一個 ID，這是一個邏輯偏移量。流提供了針對時間序列等應用的解決方案，并可為其他應用提供流消息，例如，替換需要更高可靠性的通用發布/ 訂閱應用程序，以及其他全新的應用。
您可以通過分片（聚集多個實例）來擴展 Redis 實例并提供容災恢復的持久性選項，所以 Redis 可以作為企業級應用的選擇。

更多優質中間件技術資訊/原創/翻譯文章/資料/干貨，×××