[[347101]]

許多現(xiàn)代應(yīng)用都需要在企業(yè)級規(guī)模上進(jìn)行構(gòu)建，有時甚至需要在互聯(lián)網(wǎng)規(guī)模上進(jìn)行構(gòu)建。這些應(yīng)用都需要滿足可擴(kuò)展性、可用性、安全性、可靠性和彈性需求。

在本文中，我將談?wù)撘恍┰O(shè)計模式，這些模式可以幫助你輕松實現(xiàn)上述能力。我將討論每個模式，他們?nèi)绾卧谠圃h(huán)境中使用，以及何時使用和何時不使用。

有些模式也并不是什么新發(fā)明，但它們在當(dāng)前互聯(lián)網(wǎng)規(guī)模的云世界中非常有用。

以下是我將在本文中討論的模式列表。

1. 熔斷器
2. 命令和查詢責(zé)任分離(CQRS)
3. 事件溯源(Event Sourcing)
4. Sidecar
5. 后端對前端
6. Strangler

下面進(jìn)入正文。

熔斷器

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

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

熔斷器

上圖展示了熔斷器模式的實現(xiàn)，當(dāng)服務(wù)1了解到在調(diào)用服務(wù)2時有連續(xù)的故障/超時時，服務(wù)1不再重試，而是跳過調(diào)用服務(wù)2，并立即返回響應(yīng)。

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

如果你使用的是 API 網(wǎng)關(guān)或像 Envoy 這樣的 sidecar 代理，那么可以在代理級別本身實現(xiàn)。

注意：非常重要的一點(diǎn)是，當(dāng)熔斷器打開時，要有足夠的日志記錄和警報，以便跟蹤這段時間內(nèi)收到的請求，并讓運(yùn)維團(tuán)隊了解到這些信息。

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

何時使用此模式

• 當(dāng)一個服務(wù)依賴另一個遠(yuǎn)程服務(wù)，并且在某些情況下很可能失敗時;
• 當(dāng)一個服務(wù)有很強(qiáng)依賴性時(例如：主數(shù)據(jù)服務(wù))。

何時不使用此模式

• 當(dāng)你在處理本地依賴關(guān)系時，熔斷器可能會產(chǎn)生開銷。

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

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

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

當(dāng)使用單個數(shù)據(jù)存儲同時執(zhí)行讀和寫操作，并且訪問量很大時，那么可能會開始遭遇性能問題。

在這種情況下，CQRS 模式可能很有用。CQRS 模式建議使用單獨(dú)的數(shù)據(jù)存儲來進(jìn)行讀和寫操作。

CQRS

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

如果你處理的是私有數(shù)據(jù)庫，很多企業(yè)數(shù)據(jù)庫也提供了這個功能。

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

什么時候使用這種模式

• 當(dāng)你正在考慮擴(kuò)展一個期望有大量讀和寫的應(yīng)用程序時。
• 當(dāng)你想分別調(diào)整讀和寫操作的性能時
• 當(dāng)你的讀操作可以接受接近實時或最終一致性時

何時不使用此模式

• 當(dāng)你正在構(gòu)建一個常規(guī)的 CRUD 應(yīng)用程序，并不是每次都有大量的讀和寫的時候

事件溯源(Event Sourcing)

事件溯源是一種有意思的設(shè)計模式，在這種模式下，域事件的序列被存儲為日志，日志的聚合視圖給出了應(yīng)用程序的當(dāng)前狀態(tài)。

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

事件溯源

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

注：大多數(shù)云服務(wù)提供商都支持消息服務(wù)，如 Google Pub/Sub、Azure Service Bus、AWS SQS 等。這些服務(wù)與強(qiáng)大的一致數(shù)據(jù)存儲相結(jié)合，可以用來實現(xiàn)這個模式。

何時使用此模式

• 常規(guī)的 CRUD 操作不能很好的滿足需求時。
• 通常適用于座位預(yù)定系統(tǒng)，如公交車、火車、會議、電影院等，或由購物車操作、支付等事件組成的電商系統(tǒng)。
• 當(dāng)需要強(qiáng)大的審計和事件回放來創(chuàng)建應(yīng)用的當(dāng)前和過去的狀態(tài)時。

何時不使用此模式

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

(待續(xù))

原文鏈接：

https://medium.com/better-programming/modern-day-architecture-design-patterns-for-software-professionals-9056ee1ed977

本文轉(zhuǎn)載自微信公眾號「高可用架構(gòu)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系高可用架構(gòu)公眾號。