Redis 如何簡化實現(xiàn)微服務的設計模式？

作者：jdon |?來源：jdon.com/55144
本文討論Redis如何簡化微服務中設計模式的實現(xiàn)：例如有界上下文，異步消息傳遞，基于編排的sagas，事件源，CQRS，遙測等。
微服務架構繼續(xù)變得越來越流行，但是卻被廣泛誤解。盡管大多數(shù)概念上都同意微服務應該是細粒度的且面向業(yè)務的，但通常對于架構的權衡和復雜性缺乏認識。例如，對于DevOps架構師來說，將微服務與Kubernetes相關聯(lián)是很常見的事情，而對于應用程序開發(fā)人員來說，將實現(xiàn)歸結為使用Spring Boot的情況很常見。盡管這些技術是相關的，但是容器和開發(fā)框架都無法獨自克服微服務架構的陷阱，尤其是在數(shù)據(jù)層。
Martin Fowler，Chris Richardson以及其他思想領袖早已解決與微服務架構和定義的相關特性的權衡，成功指導實施。包括的原則又：隔離、自主團隊授權、擁抱最終一致性以及基礎設施的自動化。雖然遵循這些原則可以避免早期采用者和DIY者所遭受的痛苦，但將它們合并到體系結構中的復雜性擴大了對最佳實踐和設計模式的需求，尤其是隨著實現(xiàn)擴展到數(shù)百個微服務時。
隨著Redis迅速成為微服務體系結構的主要組成部分，值得討論如何簡化設計模式的實現(xiàn)-例如有限上下文，異步消息傳遞，基于編排的sagas，事件源，CQRS，遙測等。
設計模式：受限上下文/有界上下文/界限上下->域驅動設計
我們的第一個挑戰(zhàn)是從邏輯上將業(yè)務劃分為多個微子域，以便每個人都可以由一個授權的小型自治團隊提供支持。每個子域的范圍應受其團隊管理其支持的微服務生命周期的能力的約束-從開始到后期制作。這種從臨時項目到自主域所有權的轉變激發(fā)了對微服務設計各個方面的責任感，并賦予了敏捷的決策能力-從而縮短了產(chǎn)品上市時間。
考慮一下前綴“微”，這暗示了在有限的業(yè)務子域中支持微服務的整個生命周期所需的團隊規(guī)模。搜索公眾號互聯(lián)網(wǎng)架構師復“2T”，送你一份驚喜禮包。
在我們的模型體系結構的上下文中，讓我們從付款處理域開始，開始組織設計過程，該域包括欺詐檢測，付款，結算等。由于這個范圍對于一個小型團隊來說可能太復雜了，因此，我們選擇將其所有權范圍縮小到欺詐檢測子域。
欺詐檢測由工作流的前三個微服務組成-包括數(shù)字身份，統(tǒng)計分析和基于AI的交易風險評分。由于他們的范圍可能仍然太小而無法管理，因此讓我們將欺詐檢測進一步分為兩個子域-最終看起來更易于管理。
在非常高的層次上，我們剛剛遵循的過程稱為域驅動設計（DDD），該過程受推薦的模式支持，該模式將每個微服務的范圍和所有權聲明綁定到一個稱為bounded context的業(yè)務子域。但是請稍等-Redis適合放置在哪里？
注意，每個微服務都有其自己的專用數(shù)據(jù)庫以進行隔離。擁有藍色邊界上下文的授權自治團隊選擇RediSearch支持其“ Authenticate Digital Identity”微服務，并選擇RedisBloom支持其“概率欺詐檢測檢查點”微服務。同時，擁有紫色邊界上下文的另一個團隊選擇RedisAI實時支持“交易風險評分”。
盡管每個微服務都需要自己的最佳數(shù)據(jù)模型來處理其獨特的數(shù)據(jù)訪問模式和SLA，但使用Redis就不必需要評估、內置、管理三個不同的數(shù)據(jù)庫。實際上，使用Redis Enterprise，他們可以在單個多租戶群集中部署所有三個Redis數(shù)據(jù)庫，而無需考慮其發(fā)布周期。?
設計模式：異步消息傳遞->服務間通信
既然我們已經(jīng)為每個微服務確定了一個有限的上下文和最佳數(shù)據(jù)模型，那么下一個挑戰(zhàn)就是在不破壞對隔離的合規(guī)性的情況下實現(xiàn)它們之間的通信。這可以通過擁抱最終的一致性來解決，后者假定服務間通信的接收端上的微服務在出站傳輸期間將不可用，但是，一旦恢復可用性，便可以使用該消息。
服務間通信的推薦模式是使用發(fā)布-訂閱消息代理作為其事件分發(fā)中心的異步消息傳遞。在這種模式下，生產(chǎn)者可以發(fā)布事件，而不必了解是否有任何消費者在收聽，并且（以相同的方式）該事件的消費者可以在方便時對其做出反應或完全忽略它。這通常是事件驅動架構的基礎。搜索公眾號互聯(lián)網(wǎng)架構師復“2T”，送你一份驚喜禮包。
由于我們已經(jīng)選擇Redis作為多個微服務的主要數(shù)據(jù)庫，因此我們可以通過使用Redis Streams來實現(xiàn)此模式，從而簡化架構。Redis Streams是不可變的按時間排序的日志數(shù)據(jù)結構，它允許生產(chǎn)者將異步消息發(fā)布到多個訂閱的使用者。這確保了發(fā)布事件的微服務將與使用它們的微服務保持脫鉤狀態(tài)，因此不會對可用性和發(fā)布周期產(chǎn)生交叉依賴。此外，Redis Streams可以配置為處理不同的交付保證，支持消費者群體以及本質上類似于Kafka的其他細微差別-也是跨微服務架構的主要內容。
設計模式：基于編排的Saga->分布式事務
現(xiàn)在，我們已經(jīng)啟用了服務間通信，接下來的挑戰(zhàn)是處理跨越多個有界上下文的事務，而又不會破壞對隔離的合規(guī)性。在過去，這是很簡單的實現(xiàn)，因為事務范圍內的所有操作都是針對單個RDBMS執(zhí)行的，該RDBMS提供行鎖定，死鎖檢測和回滾功能。一旦數(shù)據(jù)跨多個數(shù)據(jù)庫分布，兩階段提交協(xié)議（2PC）就成為分布式事務的標準。但是，盡管這兩種方法都可行，但在設計時并沒有考慮到最終的一致性。
如果我們假設在分布式事務期間將不存在依賴項，那么我們還應該假設頻繁的回滾將導致整個系統(tǒng)的零星不可用性—這既不是云本機，也不是縮短產(chǎn)品上市時間。
這可以通過放寬對ACID保證的嚴格要求來解決，ACID保證已經(jīng)支持了大多數(shù)傳統(tǒng)體系結構數(shù)十年來的關系數(shù)據(jù)庫。盡管關系數(shù)據(jù)庫在微服務體系結構中占有一席之地，但它們的相關性卻變得越來越重要。例如，如果不要求引用完整性，那么為什么沒有授權的自治團隊會選擇使用NoSQL數(shù)據(jù)庫優(yōu)化其微服務，該數(shù)據(jù)庫專門用于處理其特定的數(shù)據(jù)訪問模式和SLA。
回想一下，我們的付款處理工作流程由多個微服務組成，這些微服務組織到單獨的有界上下文中，并由Redis（NoSQL數(shù)據(jù)庫）支持。在這種情況下，推薦的處理分布式事務的模式是基于編排的Saga，它執(zhí)行一系列隔離的本地事務，并發(fā)布事件，從而促進工作流階段之間的過渡。
參與Saga的每個微服務都將僅偵聽其自己的與工作流相關的事件，該事件將通知它執(zhí)行本地數(shù)據(jù)庫事務，然后將其自己的事件發(fā)布給消息代理。這種事件驅動的編排可以包括補償用于回滾的微服務和用于復雜業(yè)務流程的決策服務。
值得注意的是，在基于編排的Saga中，沒有中央?yún)f(xié)調器，這避免了將參與的微服務的發(fā)布周期耦合在一起。但是，它并不總是正確的解決方案。在某些情況下，強一致性是絕對必要的，例如帳戶轉帳。在這種情況下，基于編排的Saga可能會更適合，或者在同一有限上下文中依靠微服務之間的2PC。
設計模式：事務發(fā)件箱和消息中繼->一致性
既然我們已經(jīng)設計了跨越多個有界上下文的事務，那么我們的下一個挑戰(zhàn)是減輕微服務的數(shù)據(jù)庫和消息代理之間的不一致風險，即使兩者都使用Redis?；叵胍幌?，在前兩種設計模式中，每個微服務都在本地提交到其數(shù)據(jù)庫，然后發(fā)布了一個事件。如果使用雙寫模式的某些變體來實現(xiàn)此目的，則通信可能會丟失并且分布式事務可能會變得孤立（尤其是在云環(huán)境中）。
可以將代碼復雜性添加到每個微服務中，以處理各種失敗和不一致的情況，但是請考慮將這種工作累加到數(shù)百個團隊中，并考慮不正確實施的風險-所有這些都不會增加業(yè)務價值。
為了避免各種應用程序級別實現(xiàn)的風險和成本，建議的模式是事務發(fā)件箱和消息重播。Redis通過使用Redis Streams作為事務發(fā)件箱，并使用RedisGears作為消息中繼，簡化并支持這兩種模式的組合實現(xiàn)，稱為后寫。在Redis中，輔助線程可以偵聽更改的數(shù)據(jù)事件，按時間順序持久地存儲它們，并在可用時將其發(fā)布到消息代理。可以通過基礎架構自動化在每個Redis數(shù)據(jù)庫上統(tǒng)一啟用或升級此功能。?
設計模式：遙測->可觀察性
現(xiàn)在，我們已經(jīng)減輕了主數(shù)據(jù)庫和輔助數(shù)據(jù)平臺之間不一致的風險，我們的下一個挑戰(zhàn)是衡量整個體系結構及其支持的業(yè)務交易中微服務的運行狀況，即可觀察性。
觀測是充滿了數(shù)以百計的分布式系統(tǒng)中的一個必須具備的孤立和最終一致的部件。
搜索公眾號互聯(lián)網(wǎng)架構師后臺回復“2T”，獲取一份驚喜禮包。
可觀察性建立在三大支柱上：指標，日志記錄和可追溯性。我們將首先關注指標，這些指標通常存儲在時間序列數(shù)據(jù)模型中，該數(shù)據(jù)模型可以處理大量按時間順序排列的事件和時間點查詢。最佳地，可以實時跟蹤指標，以便可以檢測到SLA / SLO異常，并在發(fā)生異常時可以緩解這些異常。
為了觀察分布式系統(tǒng)的運行狀況，我們首先需要它的數(shù)據(jù)。推薦的模式是遙測，它是從遠程源自動收集和傳輸數(shù)據(jù)以進行監(jiān)視。Redis通過其后寫功能將數(shù)據(jù)無縫推入另一個Redis數(shù)據(jù)模型RedisTimeSeries中，從而簡化了該模式的實現(xiàn)。注意，使用Redis，我們只需要一個平臺即可實現(xiàn)此模式。
現(xiàn)在，RedisTimeSeries中提供了指標，我們可以跨多個維度實時查詢它們-業(yè)務KPI，應用程序SLA / SLO，基礎架構利用率等。使用RedisInsight可視化基礎架構級別的指標。以及使用用于Grafana的Redis數(shù)據(jù)源可視化業(yè)務級別指標。
設計模式：事件源->審核和重播
既然我們已經(jīng)對度量標準數(shù)據(jù)實施了遙測，那么我們的下一個挑戰(zhàn)是啟用可觀察性的其余支柱-日志記錄和可追溯性。與指標不同，時間序列數(shù)據(jù)模型將無法使日志的固有屬性受益，因為它們無法匯總或縮減采樣。相反，它們需要一個不可變且按時間排序的數(shù)據(jù)結構，該結構可用于按事件發(fā)生的順序審核，恢復或重放事件鏈。
由于微服務需要隔離，因此它們不能依賴共享的RDBMS來維護捕獲整體中所有事件的事務日志。因此，推薦的模式是事件源，它在微服務數(shù)據(jù)庫級別的不可變且按時間排序的日志中記錄每個更改的數(shù)據(jù)事件。這種模式在大多數(shù)事件驅動的體系結構中很常見。
通常使用消息代理和事件存儲來實現(xiàn)事件源?；叵胍幌?，我們已經(jīng)實現(xiàn)了使用RedisGears捕獲更改數(shù)據(jù)事件并將其存儲在Redis Streams中的模式，Redis Streams是一個不可變的按時間順序排列的日志數(shù)據(jù)結構。因此，Redis可用作數(shù)據(jù)庫，消息代理和事件存儲。
Redis Streams還可以通過允許外部進程作為隔離的消費者組訂閱其事件流，從而超出單個微服務的范圍來簡化事件源。這允許在業(yè)務流程，域甚至架構級別進行觀察。例如，工作流仲裁器或系統(tǒng)范圍的分析平臺。
現(xiàn)在，我們已經(jīng)在Redis Streams中捕獲了更改數(shù)據(jù)事件，我們可以使用可觀察性的不同過濾器（微服務ID，事務關聯(lián)ID等）以本地方式可視化它們。
設計模式：命令查詢責任隔離（CQRS）->性能
請注意，當我們定義與欺詐相關的有界上下文時，我們省去了付款處理工作流程的最后階段。這是因為其授權的自治團隊選擇了非Redis數(shù)據(jù)庫來支持其微服務。
因此，現(xiàn)在讓我們假設“批準|?基于磁盤的數(shù)據(jù)庫支持“拒絕付款”微服務，該數(shù)據(jù)庫并未針對查詢性能進行優(yōu)化。由于它大概具有強大的耐用性保證，因此它是記錄保存的合理選擇-但是，如果其有限上下文還包含需要此數(shù)據(jù)進行查詢的微服務，該怎么辦。這意味著我們的下一個挑戰(zhàn)是在Redis不是記錄系統(tǒng)時優(yōu)化查詢性能。
推薦的模式是CQRS，它將數(shù)據(jù)集的寫（命令）和讀（查詢）責任分開。通過使用單獨的數(shù)據(jù)庫來實現(xiàn)CQRS，可以優(yōu)化數(shù)據(jù)結構或數(shù)據(jù)模型，以適應隔離區(qū)兩側的數(shù)據(jù)訪問模式及其各自的SLA。由于我們的目標是優(yōu)化性能，因此數(shù)據(jù)復制的方向通常會從基于磁盤的數(shù)據(jù)庫（例如MongoDB，Cassandra，RDBMS等）導入Redis。
這就是要抓到的地方–要實現(xiàn)這種模式，我們將需要解決近實時連續(xù)數(shù)據(jù)復制問題，保持異構數(shù)據(jù)庫之間最終的一致性，并轉換數(shù)據(jù)以避免Command和Query數(shù)據(jù)結構之間的阻抗不匹配。這聽起來應該很熟悉，因為我們是在Redis是源數(shù)據(jù)庫時執(zhí)行此操作的-回憶事務發(fā)件箱和消息中繼模式。但是，由于在這種情況下，Redis是目標，而其他大多數(shù)數(shù)據(jù)庫都不支持后寫操作，因此我們需要外部實現(xiàn)來復制更改后的數(shù)據(jù)事件。
在這種情況下，我們可以通過使用可以與Command和Query數(shù)據(jù)庫集成的Change Data Capture（CDC）框架來簡化CQRS的實現(xiàn)。CDC框架通常使用事務日志拖尾或輪詢發(fā)布者模式來掃描Command數(shù)據(jù)庫上的更改數(shù)據(jù)事件，并將它們作為轉換后的有效負載復制到Query數(shù)據(jù)庫。請注意，這與在緩存旁模式中使用Redis有何不同，因為它不會在微服務級別耦合數(shù)據(jù)庫—保持隔離。
設計模式：共享數(shù)據(jù)->可重用性
既然我們已經(jīng)解決了在Redis不在記錄系統(tǒng)中時優(yōu)化性能的問題，那么我們的下一個挑戰(zhàn)是處理微服務之間的共享數(shù)據(jù)，這些服務由不同的受限上下文或微服務體系結構之外的數(shù)據(jù)庫分隔。
后者的一個真實示例是一個扼殺程序從單片架構遷移到微服務架構。在這種情況下，作為混合云部署的一部分，微服務的數(shù)據(jù)庫可能依賴于外部記錄系統(tǒng)多年，甚至無限期依賴。當我們引入CQRS模式時，我們實際上已經(jīng)解決了這個問題，但是讓我們擴展問題說明，使其包含共享相同數(shù)據(jù)和數(shù)據(jù)訪問模式的微服務。
在這種情況下，以下是一些適用的模式，其中Redis簡化了實現(xiàn)：
只讀副本—將源數(shù)據(jù)復制到多個目標
共享數(shù)據(jù)庫-允許在單獨的有界上下文之間進行交叉依賴
域驅動設計-包括所有在單個有限上下文中共享數(shù)據(jù)的微服務
相關閱讀：2T架構師學習資料干貨分享
這是要抓住的地方-盡管這些模式解決了一些有限上下文之間的共享數(shù)據(jù)，但它們都無法在全球范圍內擴展。搜索公眾號互聯(lián)網(wǎng)架構師復“2T”，送你一份驚喜禮包。
對于全局數(shù)據(jù)，建議的模式是API網(wǎng)關的隔離數(shù)據(jù)庫。由于該數(shù)據(jù)庫可能會被流過體系結構的每個事務訪問，因此我們必須將業(yè)務連續(xù)性，可伸縮性和性能視為選擇該數(shù)據(jù)庫的關鍵成功標準。幸運的是，這是Redis Enterprise在數(shù)千個生產(chǎn)部署中大放異彩的地方。
Redis Enterprise是關鍵任務會話數(shù)據(jù)，身份驗證令牌和臨時數(shù)據(jù)存儲的事實上的標準，具有亞毫秒級的規(guī)模性能，并具有Active-Active跨集群復制和多可用性區(qū)域部署的99.999％SLA。

全棧架構社區(qū)交流群