當您設計工作負載架構時，您應該使用解決常見挑戰的產業模式。 模式可協助您進行有意的權衡，並針對預期的結果進行最佳化。 它們還可以幫助您降低可能影響可靠性、安全性、效能和成本的風險。 由於營運跨越所有這些領域，因此未管理的風險最終會以營運辛勤或事件的形式出現。 這些模式已在真實的雲端環境中得到驗證，可根據現代操作模型進行擴展，並且本質上與供應商無關。 在眾所周知的模式上進行標準化本身就是一種卓越營運的實踐。
許多模式會強化一或多個 Azure Well-Architected 支柱。 特別是針對卓越營運，模式通常會提供拓撲，以啟用安全的部署方法、漸進式演進、受控移轉和可觀測性。
下表摘要說明支援卓越營運目標的架構設計模式。
| 樣式 | 總結 |
|---|---|
| 反腐敗層 | 透過新增中介層來代理舊元件與新元件之間的互動，以保護新系統元件免受舊版系統的行為或實作選擇的影響。 此模式有助於確保新的元件設計不會受到舊版實作的影響，當您與這些舊版系統整合時，這些實作可能會有不同的資料模型或商業規則。 此模式在漸進式系統移轉中特別有用。 它減少了新元件的技術債務，同時仍支援現有元件。 |
| 編舞 | 使用分散式事件驅動通訊來協調工作負載中自主分散式元件的行為。 當您預期在工作負載的生命週期期間經常更新或取代服務時，此模式會很有用。 因為分散式元件是自主的，所以您可以修改工作量，而對系統的整體變更較少。 |
| 運算資源整合 | 透過增加密度來最佳化和整合運算資源。 此型樣會結合共用基礎結構上工作負載的多個應用程式或元件。 整合可產生更同質的運算平台，可簡化管理和可觀察性、減少操作任務的不同方法，並減少所需的工具數量。 |
| 部署戳記 | 提供一種方法，可將應用程式的特定版本及其基礎結構發行為受控的部署單位，假設會同時部署相同或不同的版本。 此模式符合不可變的基礎設施目標，支援進階部署模型，並可以促進安全部署實踐。 |
| 外部組態存放區 | 將組態擷取至外部化至應用程式的服務，以支援組態值的動態更新，而不需要變更程式碼或重新部署應用程式。 應用程式組態與應用程式程式碼的這種分離支援環境特定的組態，並將版本控制套用至組態值。 外部組態存放區也是管理功能旗標的常見位置，以啟用安全的部署做法。 |
| 閘道聚合 | 透過在單一請求中彙總對多個後端服務的呼叫，簡化用戶端與工作負載的互動。 此拓撲可讓後端邏輯獨立於用戶端發展，可讓您變更鏈結服務實作，甚至資料來源，而不需要變更用戶端接觸點。 |
| 閘道卸載 | 在將要求轉送至後端節點之前和之後，將要求處理卸載至閘道裝置。 將卸載閘道新增至要求程序可讓您從單點管理卸載功能的組態和維護，而不是從多個節點管理卸載功能。 |
| 閘道路由 | 根據請求意圖、業務邏輯和後端可用性，將傳入的網路請求路由到各種後端系統。 閘道路由可讓您將請求與後端分離，進而讓您的後端支援進階部署模型、平台轉換，以及網域名稱解析和傳輸中加密的單一管理點。 |
| 健康情況端點監控 | 提供一種方法，藉由公開專為該目的設計的端點來監視系統的健康情況或狀態。 標準化要公開的健康情況端點，以及整個工作負載中結果中的分析層級，可協助您分級問題。 |
| 傳訊橋接器 | 提供中介，以啟用傳訊系統之間的通訊，否則這些系統因通訊協定或格式而不相容。 當您在工作負載內轉換傳訊和事件技術時，或當您有來自外部相依關係的異質需求時，此解耦可提供彈性。 |
| 出版商/訂閱者 | 透過透過中繼訊息代理程式或事件匯流排將直接用戶端對服務或用戶端對服務通訊取代為直接用戶端對服務或用戶端對服務通訊，以分離架構的元件。 此間接層可讓您安全地變更發行者或訂閱者端的實作，而不需要協調這兩個元件的變更。 |
| 隔離 | 確保外部資產符合團隊同意的品質層級，然後再被授權在工作負載中使用它們。 這些檢查的自動化和一致性是工作負載軟體開發生命週期和安全部署實務 （SDP） 的一部分。 |
| 邊車 | 藉由將非主要或橫切工作封裝在與主要應用程式並存的隨附程式中，以擴充應用程式的功能。 此模式提供一種在工具整合中實作彈性的方法，可增強應用程式的可觀察性，而不需要應用程式採用直接實作相依性。 它可讓 Sidecar 功能獨立發展，並獨立於應用程式的生命週期進行維護。 |
| 絞殺者無花果 | 提供一種方法，以系統地將執行中的系統元件替換為新元件，通常是在系統的移轉或現代化期間。 這種模式提供了一種持續改進的方法，其中首選隨著時間的推移進行小變化的增量替換，而不是實施風險更大的大型系統性變化。 此模式也支持安全停用：在替換流程達到可靠性和可觀測性的目標後，才能針對舊版端點進行測量、清空和移除操作。 |
後續步驟
檢閱支援其他 Azure Well-Architected Framework 支柱的架構設計模式：