雲端設計模式
架構設計人員藉由結合平臺服務、功能和程式代碼來設計工作負載，以滿足工作負載中的功能和非功能需求。 設計工作負載需要了解這些工作負載需求，然後選擇拓撲和方法，以解決工作負載條件約束所呈現的挑戰。 解決許多常見挑戰的雲端設計模式。
系統設計中廣泛運用了設計模式。 基礎結構、程式代碼和分散式系統全都是圍繞設計模式的組合所設計。 這些設計模式適用於在雲端中建置可靠、安全、成本優化、運作健全且高效能的應用程式。
這些設計模式並不專屬於任何技術，而且與任何分散式系統相關，無論是裝載於 Azure、其他雲端平臺，有些甚至可以延伸到內部部署或混合式工作負載。
雲端設計模式可協助設計過程
雲端工作負載容易發生 分散式運算的弱點。 雲端設計弱點的一些範例包括：
- 網路可靠
- 延遲為零
- 帶寬是無限的
- 網路是安全的
- 拓撲不會變更
- 有一個系統管理員
- 元件版本設定很簡單
- 可檢視性實作可能會延遲
設計模式不會消除這類概念，但有助於帶來意識、補償和風險降低。 每個雲端模式都有自己的取捨。 您需要更注意為何要選擇特定模式，而不是如何實作它。
架構完善的工作負載會考慮如何將這些全產業的設計模式作為工作負載設計的核心建置組塊。 每個 Azure Well-Architected 支柱都會在這些設計模式中表示，通常設計模式會在不同支柱的目標之間引入權衡取捨。
模式目錄
此目錄中的每個模式都會描述模式所解決的問題、套用模式的考慮，以及以 azure Microsoft為基礎的範例。 某些模式包含示範如何在 Azure 上實作模式的程式代碼範例或代碼段。
| 模式 | 摘要 | Azure Well-Architected Framework 支柱 |
|---|---|---|
| 大使 | 建立協助程式服務，代表取用者服務或應用程式傳送網路要求。 |
|
| 反損毀層 | 實作新式應用程式與舊版系統之間的外觀或配接器層。 |
|
| 異步要求-回復 | 將後端處理與前端主機分離，其中後端處理必須是異步的，但前端仍然需要明確的回應。 |
|
| 前端的後端 | 建立個別的後端服務，供特定前端應用程式或介面使用。 |
|
| 艙壁 | 將應用程式的元素隔離到集區中，讓其中一個元素失敗時，其他專案會繼續運作。 |
|
| Cache-Aside | 視需要將資料從資料庫載入至快取中。 |
|
| 編舞 | 讓每個服務決定商務作業的處理時機和方式，而不是視中央協調器而定。 |
|
| 斷路器 | 處理在連線到遠端服務或資源時，可能需要一段時間才能修正的錯誤。 |
|
| 宣告檢查 | 將大型訊息分割成宣告檢查和承載，以避免壓倒訊息總線。 |
|
| 補償交易 | 復原一系列步驟所執行的工作，一起定義最終一致的作業。 |
|
| 競爭取用者 | 讓多個並行取用者處理相同傳訊通道上收到的訊息。 |
|
| 計算資源匯總 | 將多個工作或作業合併成單一計算單位。 |
|
| CQRS | 使用個別介面來隔離從更新數據的作業讀取數據的作業。 |
|
| 部署戳記 | 部署多個獨立應用程式元件複本，包括數據存放區。 |
|
| Edge 工作負載組態 | 集中設定以解決在店面設定多個系統和裝置的挑戰。 | |
| 事件來源 | 使用僅限附加存放區來記錄描述定義域中數據所採取的動作的完整系列事件。 |
|
| 外部組態存放區 | 將組態資訊從應用程式部署套件移至集中式位置。 |
|
| 同盟身分識別 | 將驗證委派給外部識別提供者。 |
|
| 把關 | 使用專用主機實例來保護應用程式和服務，以作為用戶端與應用程式或服務之間的訊息代理程式、驗證和清理要求，並在它們之間傳遞要求和數據。 |
|
| 閘道匯總 | 使用閘道將多個個別要求匯總成單一要求。 |
|
| 閘道卸除 | 將共用或特製化服務功能卸除至閘道 Proxy。 |
|
| 網關路由 | 使用單一端點將要求路由傳送至多個服務。 |
|
| Geode | 將後端服務部署到一組地理節點，每個節點都可以在任何區域中服務任何用戶端要求。 |
|
| 健全狀況端點監視 | 在應用程式中實作功能檢查，外部工具可以定期透過公開的端點存取。 |
|
| 索引表 | 在查詢經常參考的數據存放區中建立索引。 |
|
| 領袖選舉 | 藉由選擇一個實例做為負責管理其他實例的領導者，協調分散式應用程式中共同作業工作實例集合所執行的動作。 |
|
| 具體化檢視 | 當數據不適合針對必要的查詢作業格式化時，針對一或多個數據存放區中的數據產生預先填入的檢視。 |
|
| 傳訊網橋 | 建立一個中介，來促進使用不同協定或格式的傳訊系統之間的溝通。 |
|
| 管道和篩選 | 將執行複雜處理的工作分解成一系列可重複使用的個別元素。 |
|
| 優先順序佇列 | 設定傳送至服務的要求優先順序，以便接收和處理優先順序高於優先順序較低的要求。 |
|
| Publisher/Subscriber | 讓應用程式以異步方式向多個感興趣的取用者宣告事件，而不需要將傳送者與接收者結合。 |
|
| 隔離 | 在授權在工作負載中取用外部資產之前，請確定外部資產符合小組同意的質量等級。 |
|
| 佇列型負載撫平 | 使用佇列，做為工作與它叫用的服務之間的緩衝區，以便順暢間歇性繁重的負載。 |
|
| 速率限制模式 | 限制模式可協助您避免或最小化與這些節流限制相關的節流錯誤，並協助您更準確地預測輸送量。 |
|
| 重試 | 讓應用程式在嘗試連線到服務或網路資源時，藉由明確地重試先前失敗的作業，來處理預期的暫時失敗。 |
|
| 傳奇 | 在分散式交易案例中管理微服務之間的數據一致性。 Saga 是一連串的交易，會更新每項服務並發佈訊息或事件，觸發下一個交易步驟。 |
|
| 排程器代理程式監督員 | 跨分散式服務和其他遠端資源協調一組動作。 |
|
| 循序車隊 | 以定義的順序處理一組相關的訊息，而不會封鎖處理其他訊息群組。 |
|
| 分區化 | 將數據存放區分割成一組水平數據分割或分區。 |
|
| Sidecar | 將應用程式的元件部署到個別的進程或容器，以提供隔離和封裝。 |
|
| 靜態內容裝載 | 將靜態內容部署至雲端式儲存體服務，以將其直接傳遞至用戶端。 |
|
| Strangler Fig | 透過逐漸將特定功能片段取代為新的應用程式和服務，以累加方式移轉舊版系統。 |
|
| 節流 | 控制應用程式實例、個別租用戶或整個服務所使用的資源耗用量。 |
|
| 代客金鑰 | 使用令牌或金鑰，提供用戶端對特定資源或服務的受限直接存取。 |
|
下一步
從 Azure Well-Architected 支柱的觀點來檢視旨在優化的設計模式。