如何使用常用的架構設計模式之熔斷器模式

本篇內容主要講解“如何使用常用的架構設計模式之熔斷器模式”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何使用常用的架構設計模式之熔斷器模式”吧!

熔斷器

分布式系統在設計時應考慮到故障問題。目前微服務已經得到了廣泛應用，這些服務大多依賴于其他遠程服務。遠程服務可能會因為網絡、應用負載等各種原因而不能及時響應。在大多數情況下，通過重試應該可以解決這些問題。

但也有極端情況，比如服務降級或服務本身完全失效。在這種情況下，繼續重試是沒有意義的。因此熔斷器模式就可以派上用場了。

熔斷器

上圖展示了熔斷器模式的實現，當服務1了解到在調用服務2時有連續的故障/超時時，服務1不再重試，而是跳過調用服務2，并立即返回響應。

有一些流行的開源庫，比如 Netflix 的 Hystrix，可以用來非常容易地實現這種模式。

如果你使用的是 API 網關或像 Envoy 這樣的 sidecar 代理，那么可以在代理級別本身實現。

注意：非常重要的一點是，當熔斷器打開時，要有足夠的日志記錄和警報，以便跟蹤這段時間內收到的請求，并讓運維團隊了解到這些信息。

你也可以在半開的情況下實現熔斷器，以繼續為能容忍服務降級的客戶提供服務。

何時使用此模式

• 當一個服務依賴另一個遠程服務，并且在某些情況下很可能失敗時;

• 當一個服務有很強依賴性時(例如：主數據服務)。

何時不使用此模式

• 當你在處理本地依賴關系時，熔斷器可能會產生開銷。

命令和查詢責任隔離(CQRS)

CQRS 對于現代使用數據存儲的應用來說是一個非常有用的模式。它的原理是將數據存儲中的讀(查詢)和寫/更新(命令)操作分開。

假設你正在構建一個應用程序，需要將數據存儲在 MySQL/PostgreSQL  數據庫中。大家都知道，當向數據存儲中寫入數據時，一個操作需要經過幾個步驟，比如驗證、模型和持久化，因此典型的寫/更新操作比簡單的讀操作需要更長的時間。

當使用單個數據存儲同時執行讀和寫操作，并且訪問量很大時，那么可能會開始遭遇性能問題。

在這種情況下，CQRS 模式可能很有用。CQRS 模式建議使用單獨的數據存儲來進行讀和寫操作。

CQRS

注：現在大多數 PaaS 數據庫都提供了創建數據存儲的讀復制(Google Cloud SQL、Azure SQL DB、Amazon  RDS等)的能力，這有助于更容易實現CQRS。

如果你處理的是私有數據庫，很多企業數據庫也提供了這個功能。

注：如今有些人也喜歡為讀復制使用速度快、性能好的 NoSQL 數據庫，比如 MongoDB 和 Elasticsearch。

什么時候使用這種模式

• 當你正在考慮擴展一個期望有大量讀和寫的應用程序時。

• 當你想分別調整讀和寫操作的性能時

• 當你的讀操作可以接受接近實時或最終一致性時

何時不使用此模式

• 當你正在構建一個常規的 CRUD 應用程序，并不是每次都有大量的讀和寫的時候

事件溯源(Event Sourcing)

事件溯源是一種有意思的設計模式，在這種模式下，域事件的序列被存儲為日志，日志的聚合視圖給出了應用程序的當前狀態。

這種模式通常用于那些無法承受數據存儲鎖的系統，并且需要維護事件的審計和歷史記錄，例如，酒店/會議/座位預訂等應用。

事件溯源

比如一個酒店客房預訂系統，其中用戶需要預訂或取消預訂。在這里，你需要將預訂和取消預訂存儲為一系列事件。在每次預訂之前，通過查看事件日志，聚合視圖顯示可用房間。

注：大多數云服務提供商都支持消息服務，如 Google Pub/Sub、Azure Service Bus、AWS SQS  等。這些服務與強大的一致數據存儲相結合，可以用來實現這個模式。

何時使用此模式

• 常規的 CRUD 操作不能很好的滿足需求時。

• 通常適用于座位預定系統，如公交車、火車、會議、電影院等，或由購物車操作、支付等事件組成的電商系統。

• 當需要強大的審計和事件回放來創建應用的當前和過去的狀態時。

何時不使用此模式

• 常規的 CRUD 操作足以滿足用戶需求時。

到此，相信大家對“如何使用常用的架構設計模式之熔斷器模式”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！