許多現(xiàn)代應(yīng)用都需要在企業(yè)級規(guī)模上進行構(gòu)建，有時甚至需要在互聯(lián)網(wǎng)規(guī)模上進行構(gòu)建。這些應(yīng)用都需要滿足可擴展性、可用性、安全性、可靠性和彈性需求。
在本文中，我將談?wù)撘恍┰O(shè)計模式，這些模式可以幫助你輕松實現(xiàn)上述能力。我將討論每個模式，他們?nèi)绾卧谠圃h(huán)境中使用，以及何時使用和何時不使用。
有些模式也并不是什么新發(fā)明，但它們在當(dāng)前互聯(lián)網(wǎng)規(guī)模的云世界中非常有用。
以下是我將在本文中討論的模式列表。
熔斷器
命令和查詢責(zé)任分離（CQRS）
事件溯源（Event Sourcing）
Sidecar
后端對前端
Strangler
下面進入正文。
熔斷器
分布式系統(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)。
注意：非常重要的一點是，當(dāng)熔斷器打開時，要有足夠的日志記錄和警報，以便跟蹤這段時間內(nèi)收到的請求，并讓運維團隊了解到這些信息。
你也可以在半開的情況下實現(xiàn)熔斷器，以繼續(xù)為能容忍服務(wù)降級的客戶提供服務(wù)。
何時使用此模式
當(dāng)一個服務(wù)依賴另一個遠(yuǎn)程服務(wù)，并且在某些情況下很可能失敗時；
當(dāng)一個服務(wù)有很強依賴性時（例如：主數(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 模式建議使用單獨的數(shù)據(jù)存儲來進行讀和寫操作。
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)你正在考慮擴展一個期望有大量讀和寫的應(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)，并且需要維護事件的審計和歷史記錄，例如，酒店/會議/座位預(yù)訂等應(yīng)用。
事件溯源
比如一個酒店客房預(yù)訂系統(tǒng)，其中用戶需要預(yù)訂或取消預(yù)訂。在這里，你需要將預(yù)訂和取消預(yù)訂存儲為一系列事件。在每次預(yù)訂之前，通過查看事件日志，聚合視圖顯示可用房間。
注：大多數(shù)云服務(wù)提供商都支持消息服務(wù)，如 Google Pub/Sub、Azure Service Bus、AWS SQS 等。這些服務(wù)與強大的一致數(shù)據(jù)存儲相結(jié)合，可以用來實現(xiàn)這個模式。
何時使用此模式
常規(guī)的 CRUD 操作不能很好的滿足需求時。
通常適用于座位預(yù)定系統(tǒng)，如公交車、火車、會議、電影院等，或由購物車操作、支付等事件組成的電商系統(tǒng)。
當(dā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
本文由高可用架構(gòu)翻譯，技術(shù)原創(chuàng)及架構(gòu)實踐文章，歡迎通過公眾號菜單「聯(lián)系我們」進行投稿。
高可用架構(gòu)
改變互聯(lián)網(wǎng)的構(gòu)建方式
