如何將 Redis 用於微服務通訊的事件存儲

時間 2019-11-10

標籤如何 redis 用於微服通訊事件存儲欄目 Redis 简体版

原文原文鏈接

來源：Redislabs
做者：Martin Forstnerhtml

翻譯：Kevin (公衆號：中間件小哥）python

以個人經驗，將某些應用拆分紅更小的、鬆耦合的、可協同工做的獨立邏輯業務服務會更易於構建和維護。這些服務（也被稱爲微服務）各自管理本身的技術棧，所以很容易獨立於其餘服務進行開發和部署。前人已經總結了不少關於使用這種架構設計的好處，在此我就再也不贅述了。關於這種設計，有一個方面我一直在重點關注，由於若是沒有它，將會致使一些有趣的挑戰。雖然構建鬆耦合的微服務是一個很是輕量級和快速的開發過程，可是這些服務之間共享狀態、事件以及數據的通訊模型卻不那麼簡單。我使用過的最簡單的通訊模型就是服務間直接通訊，可是這種模型被 Fernando Dogio 明確地證實一旦服務規模擴大就會失效，會致使服務崩潰、重載邏輯以及負載增長等問題，從而可能引發的巨大麻煩，所以應該儘可能避免使用這種模型。還有一些其餘通訊模型，好比通用的發佈/訂閱模型、複雜的 kafka 事件流模型等，可是最近我在使用 Redis 構建微服務間的通訊模型。git

拯救者 Redis！github

微服務經過網絡邊界發佈狀態，爲了跟蹤這種狀態，事件一般須要被保存在事件存儲中。因爲事件一般是一種異步寫入操做的不可變流的記錄（又被稱爲事務日誌），所以適用於如下場景：docker

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

2. 丟失一個事件會致使錯誤狀態緩存

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

4. 寫操做簡單且快捷數據結構

5. 讀操做須要更多的時間，以致於須要緩存架構

6. 須要高可擴展性，服務之間都是解耦的，沒有關聯

使用 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-...

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

3. 安裝 Python3：

https://python-docs.readthedo...

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 能夠做爲企業級應用的選擇。

更多優質中間件技術資訊/原創/翻譯文章/資料/乾貨，請關注「中間件小哥」公衆號！