支援效能效率的雲端設計模式
設計工作負載架構時，您應該使用可解決常見挑戰的產業模式。 模式可協助您在工作負載內進行刻意取捨，並針對您想要的結果進行優化。 它們也可以協助降低源自特定問題的風險，這可能會影響可靠性、安全性、成本和作業。 如果未降低，風險最終會導致效能效率不佳。 這些模式是由真實世界的體驗所支援、專為雲端規模和作業模型所設計，而且原本就與廠商無關。 使用已知的模式作為將工作負載設計標準化的方式，是營運卓越元件的一部分。
許多設計模式都直接支援一或多個架構要素。 支援效能效率要素的設計模式可解決延展性、效能調整、工作優先順序，以及移除瓶頸。
適用於效能效率的設計模式
下表摘要說明支援效能效率目標的雲端設計模式。
| 模式 | 摘要 |
|---|---|
| 非同步要求-回覆 | 藉由分離不需要立即解答之進程的互動要求和回復階段，改善系統的回應性和延展性。 藉由使用非同步模式，您可以在伺服器端最大化並行。 您可以使用此模式來排程要完成的工作，因為容量允許。 |
| 前端的後端 | 藉由建立專屬於特定前端介面的個別服務，將工作負載的服務層個別化。 此區隔可讓您以可能無法使用共用服務層的方式進行優化。 當您以不同的方式處理個別用戶端時，您可以針對特定用戶端的條件約束和功能優化效能。 |
| 隔艙 | 引進元件之間的分割，以隔離故障的彈射半徑。 此設計可讓每個大量分頁個別調整，以符合封裝在 Bulkhead 中的工作需求。 |
| 另行快取 | 藉由引進隨選填入的快取，將經常讀取資料的存取優化。 然後，快取會用於相同資料的後續要求。 此模式特別適用于不常變更且可容許特定過期數量的大量讀取資料。 此實作的目標是藉由將這種類型的資料卸載至快取，而不是從其資料存放區來源，在整體系統中提供更佳的效能。 |
| 設計 | 使用分散式事件驅動通訊，協調工作負載中自發分散式元件的行為。 當集中式協調流程拓撲發生效能瓶頸時，此模式可以提供替代方式。 |
| 斷路器 | 防止持續要求發生問題或無法使用的相依性。 重試錯誤方法可能會導致在相依性復原期間過度使用資源，也可以在嘗試復原的相依性上多載效能。 |
| 提領票證 | 將資料與傳訊流程分開，提供一種方式來個別擷取與訊息相關的資料。 當系統處理大型資料承載時，此模式可改善訊息發行者、訂閱者和訊息匯流排本身的效率與效能。 其運作方式是減少訊息大小，並確保取用者只在需要時擷取承載資料，並視需要和時間擷取承載資料。 |
| 競爭取用者 | 套用分散式和並行處理，以有效率地處理佇列中的專案。 此模型支援將負載分散到所有取用者節點，以及以佇列深度為基礎的動態調整。 |
| 計算資源彙總 | 藉由增加密度來優化和合併計算資源。 此模式結合了共用基礎結構上工作負載的多個應用程式或元件。 此匯總會使用備用節點容量來降低過度布建，將運算資源的使用率最大化。 容器協調器是常見的範例。 大型 (垂直調整) 計算實例通常用於這些基礎結構的資源集區中。 |
| 命令與查詢責任隔離 (CQRS) | 分隔應用程式資料模型的讀取和寫入作業。 此區隔可針對每個作業的特定用途，啟用目標效能和調整優化。 此設計在具有高讀寫比例的應用程式中最有説明。 |
| 部署戳記 | 根據假設會同時部署相同或不同版本的假設，提供發行特定版本的應用程式及其基礎結構作為受控制部署單位的方法。 此模式通常與您的工作負載中定義的縮放單位一致：因為除了單一縮放單位所提供的容量之外，還需要額外的容量，因此會部署額外的部署戳記來相應放大。 |
| 事件來源 | 將狀態變更視為一系列事件，並將其擷取在不可變的僅限附加記錄檔中。 根據您的工作負載，此模式通常會結合 CQRS、適當的定義域設計和策略性快照集，以改善效能。 效能改善是因為不可部分完成的附加作業，以及避免資料庫鎖定的寫入和讀取。 |
| 同盟身分識別 | 將信任委派給工作負載外部的識別提供者，以便管理使用者並提供應用程式的驗證。 當您卸載使用者管理和驗證時，可以將應用程式資源套用至其他優先順序。 |
| 閘道管理員 | 卸載在將要求轉送至後端節點之前和之後，特別針對安全性和存取控制強制執行的要求處理。 此模式通常用於在閘道層級實作節流，而不是在節點層級實作速率檢查。 協調所有節點之間的速率狀態原本就不是高效能。 |
| 閘道彙總 | 藉由在單一要求中匯總對多個後端服務的呼叫，簡化與工作負載的用戶端互動。 此設計可能會比用戶端建立多個連線的設計產生較少的延遲。 快取在匯總實作中也很常見，因為它會將後端系統的呼叫降到最低。 |
| 閘道卸載 | 在將要求轉送至後端節點之前和之後，將要求處理卸載至閘道裝置。 將卸載閘道新增至要求程式可讓您使用較少的每個節點資源，因為功能會集中于閘道上。 您可以獨立于應用程式程式碼，將卸載功能的實作優化。 卸載的平臺提供功能可能已經是高效能。 |
| 閘道路由 | 根據要求意圖、商務邏輯和後端可用性，將連入網路要求路由傳送至各種後端系統。 閘道路由可讓您將流量分散到系統中的節點，以平衡負載。 |
| Geode | 部署跨多個地理位置在主動-主動可用性模式中運作的系統。 此模式會使用資料複寫來支援任何用戶端可以連線到任何地理實例的理想。 您可以使用它，從最接近分散式使用者基底的區域提供您的應用程式。 這麼做可藉由消除長距離流量來減少延遲，因為您只會在目前使用相同的地理柵欄的使用者之間共用基礎結構。 |
| 健康情況端點監視 | 藉由公開專為該用途設計的端點，提供監視系統健康情況或狀態的方法。 您可以使用這些端點，將流量路由傳送至驗證為狀況良好的節點，以改善負載平衡。 透過額外的設定，您也可以取得可用節點容量的計量。 |
| 索引資料表 | 藉由讓用戶端查閱中繼資料來優化分散式資料存放區中的資料擷取，以便直接擷取資料，避免需要執行完整資料存放區掃描。 用戶端會指向其分區、資料分割或端點，以啟用動態資料分割以達到效能優化。 |
| 具體化檢視模式 | 使用預先計算的資料檢視來優化資料擷取。 具體化檢視會儲存複雜計算或查詢的結果，而不需要資料庫引擎或用戶端重新計算每個要求。 此設計可減少整體資源耗用量。 |
| 優先順序佇列 | 確保優先順序較高的專案會在優先順序較低的專案之前處理和完成。 根據商務優先順序分隔專案可讓您將效能工作焦點放在最耗時的工作上。 |
| 發行者/訂閱者 | 藉由使用中繼訊息代理程式或事件匯流排的通訊取代直接用戶端對服務或用戶端對服務通訊，來分離架構的元件。 將發行者與取用者分離可讓您針對特定訊息執行的工作，將計算和程式碼優化。 |
| 佇列型負載調節 | 藉由在佇列中緩衝傳入要求或工作，並讓佇列處理器以受控制的步調來處理傳入要求或工作層級。 這種方法可針對輸送量效能進行刻意設計，因為要求的進入不需要與其處理速率相互關聯。 |
| 排程器代理程式監督員 | 根據系統中可觀察的因素，有效率地分散和轉散發整個系統的工作。 此模式會使用效能和容量計量來偵測目前的使用率，並將工作路由傳送至具有容量的代理程式。 您也可以使用它來優先執行較高優先順序的工作，而非優先順序較低的工作。 |
| 分區化 | 將負載導向至特定的邏輯目的地，以處理特定要求，以啟用共置以進行優化。 當您在調整策略中使用分區化時，資料或處理會隔離至分區，因此只會與導向至該分區的其他要求競爭資源。 您也可以使用分區化，根據地理位置進行優化。 |
| 側車 | 將非主要或跨領域工作封裝在與主要應用程式一起存在的隨附程式中，以擴充應用程式的功能。 您可以將跨領域工作移至單一進程，以跨主要進程的多個實例進行調整，這可減少為應用程式的每個實例部署重複功能的需求。 |
| 靜態內容裝載 | 使用專為該用途設計的裝載平臺，將靜態內容傳遞至工作負載用戶端優化。 卸載外部化主機的責任有助於減輕壅塞，並可讓您只使用應用程式平臺來傳遞商務邏輯。 |
| 節流 | 對資源或元件傳入要求的速率或輸送量施加限制。 當系統需求偏高時，此模式有助於減輕壅塞，這可能會導致效能瓶頸。 您也可以使用它來主動避免雜訊鄰近案例。 |
| Valet 金鑰 | 授與安全性限制的資源存取權，而不使用中繼資源來 Proxy 存取權。 這麼做會將處理卸載為用戶端與資源之間的獨佔關聯性，而不需要以高效能的方式處理所有用戶端要求的大使元件。 當 Proxy 不會將值新增至交易時，使用此模式的優點最重要。 |
下一步
檢閱支援其他 Azure Well-Architected Framework 要素的雲端設計模式：