支援成本優化的雲端設計模式
設計工作負載架構時，您應該使用可解決常見挑戰的產業模式。 模式可協助您在工作負載內進行刻意取捨，並針對您想要的結果優化。 它們也可以協助降低源自特定問題的風險，進而影響可靠性、安全性、效能和作業。 如果未減輕，風險最終會增加成本。 這些模式受到真實世界體驗的支援，專為雲端規模和作業模型所設計，本質上是廠商無關。 使用已知的模式作為標準化工作負載設計的方式，是卓越營運的一部分。
許多設計模式直接支援一或多個架構要素。 支援成本優化支柱的設計模式，可配合實作有利的計費模型、減少過度布建、變更縮放維度，以及在移轉期間將價值最大化。
成本優化的設計模式
下表摘要說明支援成本優化目標的雲端設計模式。
| 模式 | 摘要 |
|---|---|
| 宣告檢查 | 將數據與傳訊流程分開，提供一種方式來個別擷取與訊息相關的數據。 訊息系統通常會限制訊息大小，而增加的大小限制通常是進階功能。 減少訊息主體的大小，可能會讓您使用更便宜的傳訊解決方案。 |
| 競爭取用者 | 套用分散式和並行處理，以有效率地處理佇列中的專案。 此模式可協助您優化成本，方法是啟用以佇列深度為基礎的調整，在佇列是空的時減少為零。 它也可以藉由讓您限制並行取用者實例數目上限來優化成本。 |
| 計算資源匯總 | 藉由增加密度來優化和合併計算資源。 此模式會結合共用基礎結構上工作負載的多個應用程式或元件。 如此一來，透過集區基礎結構上的元件匯總，甚至是整個工作負載的匯總，避免未使用的布建容量，將計算資源的使用率最大化。 容器協調器是常見的範例。 |
| 閘道卸除 | 將要求在將要求轉送至後端節點之前和之後，將要求卸除至閘道裝置。 將卸除閘道新增至要求程式可讓您將成本從每個節點花費的資源重新導向至閘道實作。 集中式處理模型中的成本經常低於分散式模型的成本。 |
| 傳訊網橋 | 提供媒介，以啟用通訊協定或格式不相容之傳訊系統之間的通訊。 此媒介可以增加您現有系統的壽命，同時仍允許與使用不同傳訊或事件技術之系統的互操作性。 |
| Publisher/Subscriber | 使用中繼訊息代理程式或事件總線，將架構的直接客戶端對服務或客戶端對服務通訊取代為通訊，以分離架構的元件。 此設計可以在您的架構中啟用事件驅動方法，這與以耗用量為基礎的計費搭配使用，以避免過度布建。 |
| 佇列型負載撫平 | 藉由在佇列中緩衝傳入要求或工作，讓佇列處理器以受控制的速度處理它們，來控制傳入要求或工作的層級。 由於負載處理與要求或工作接收分離，因此您可以使用此方法來減少過度布建資源以處理尖峰負載的需求。 |
| 分區化 | 將載入導向至特定邏輯目的地以處理特定要求，以啟用共置以進行優化。 實作分區的系統通常受益於使用成本較低的計算或記憶體資源的多個實例，而不是單一成本更高的資源。 在許多情況下，此設定可以節省您的成本。 |
| 靜態內容裝載 | 使用專為該用途設計的裝載平臺，將靜態內容傳遞至工作負載客戶端優化。 動態應用程式託管通常比靜態託管更昂貴，因為動態託管可以執行您的編碼商務規則。 使用應用程式平台傳遞靜態內容並不符合成本效益。 |
| Strangler Fig | 提供一種方法，以新的元件來系統地取代執行中系統的元件，通常是在系統移轉或現代化期間。 這種方法的目標是在以累加方式現代化的同時，最大化目前執行中系統現有投資的使用。 它可讓您在低 ROI 取代之前執行高 ROI 取代。 |
| 節流 | 對資源或元件傳入要求的速率或輸送量施加限制。 這些限制可以通知成本模型化，甚至可以直接系結至應用程式的商務模型。 它們也會對使用率加上明確的上限，這可納入資源大小調整。 |
| 代客金鑰 | 授與安全性限制的資源存取權，而不需使用中繼資源來 Proxy 存取權。 此設計會將處理卸除為用戶端與資源之間的獨佔關聯性，而不需要新增元件即可直接處理所有用戶端要求。 當用戶端要求頻繁或夠大而需要大量 Proxy 資源，或 Proxy 不會在要求中新增值時，此優點最為顯著。 |
下一步
檢閱支援其他 Azure 良好架構架構要素的雲端設計模式：