支援可靠性的雲端設計模式
設計工作負載架構時，您應該使用可解決常見挑戰的產業模式。 模式可協助您在工作負載內進行刻意取捨，並針對您想要的結果進行優化。 它們也可以協助降低源自特定問題的風險，這可能會影響安全性、效能、成本和作業。 如果未減輕，這些風險最終會導致可靠性問題。 這些模式是由真實世界的體驗所支援、專為雲端規模和作業模型所設計，而且原本就與廠商無關。 使用已知的模式作為將工作負載設計標準化的方式，是營運卓越元件的一部分。
許多設計模式都直接支援一或多個架構要素。 支援可靠性要素的設計模式會優先處理工作負載可用性、自我保留、復原、資料和處理完整性，以及故障的內含專案。
可靠性的設計模式
下表摘要說明支援可靠性目標的雲端設計模式。
| 模式 | 摘要 |
|---|---|
| 外交官 (Ambassador) | 卸載與網路通訊相關的跨領域工作，以封裝和管理網路通訊。 產生的協助程式服務會代表用戶端起始通訊。 此中繼點提供將可靠性模式新增至網路通訊的機會，例如重試或緩衝。 |
| 前端的後端 | 藉由建立專屬於特定前端介面的個別服務，將工作負載的服務層個別化。 由於此區隔，支援一個用戶端的服務層發生問題，可能會影響另一個用戶端存取的可用性。 當您以不同的方式處理各種用戶端時，您可以根據預期的用戶端存取模式來排定可靠性工作的優先順序。 |
| 隔艙 | 引進元件之間的刻意和完整分割，以隔離故障的彈射半徑。 此失敗隔離策略會嘗試只包含發生問題的外頭錯誤，並防止對其他大塊造成影響。 |
| 另行快取 | 藉由引進隨選填入的快取，將經常讀取資料的存取優化。 然後，快取會用於相同資料的後續要求。 快取會建立資料複寫，而且在來源資料存放區暫時無法使用時，可以使用有限的方式來保留經常存取資料的可用性。 此外，如果快取發生問題，工作負載可能會回復到來源資料存放區。 |
| 斷路器 | 防止持續要求發生問題或無法使用的相依性。 如此一來，此模式會防止多載錯誤的相依性。 您也可以使用此模式來觸發工作負載中的正常降低。 斷路器通常會與自動復原結合，以提供自我保留和自我修復。 |
| 提領票證 | 將資料與傳訊流程分開，提供一種方式來個別擷取與訊息相關的資料。 訊息匯流排不會提供經常出現在專用資料存放區中的相同可靠性和災害復原，因此將資料與訊息分開，可為基礎資料提供更高的可靠性。 此分隔也允許在災害之後使用訊息佇列復原方法。 |
| 補償交易 | 藉由反轉先前套用動作的效果，提供從失敗中復原的機制。 此模式會使用補償動作來解決重要工作負載路徑中的問題，這可能牽涉到直接回復資料變更、中斷交易鎖定，或甚至執行原生系統行為來反轉效果等程式。 |
| 競爭取用者 | 套用分散式和並行處理，以有效率地處理佇列中的專案。 此模型會將取用者視為複本來建置佇列處理中的備援，因此實例失敗不會防止其他取用者處理佇列訊息。 |
| 事件來源 | 將狀態變更視為一系列事件，並將其擷取在不可變的僅限附加記錄檔中。 當變更的可靠歷程記錄在複雜的商務程式中很重要時，您可以使用此模式。 如果您需要復原狀態存放區，它也有助於狀態重建。 |
| 同盟身分識別 | 將信任委派給工作負載外部的識別提供者，以便管理使用者並提供應用程式的驗證。 卸載使用者管理和驗證會將這些元件的可靠性轉移至識別提供者，這通常是高 SLA。 此外，在工作負載災害復原期間，驗證元件可能不需要作為工作負載復原計畫的一部分來處理。 |
| 閘道彙總 | 藉由在單一要求中匯總對多個後端服務的呼叫，簡化與工作負載的用戶端互動。 此拓撲可讓您將暫時性錯誤處理從跨用戶端的分散式實作轉移到集中式實作。 |
| 閘道卸載 | 在將要求轉送至後端節點之前和之後，將要求處理卸載至閘道裝置。 將此責任卸載至閘道可減少後端節點上應用程式程式碼的複雜度。 在某些情況下，卸載會以可靠的平臺提供功能來完全取代功能。 |
| 閘道路由 | 根據要求意圖、商務邏輯和後端可用性，將連入網路要求路由傳送至各種後端系統。 閘道路由可讓您只將流量路由傳送至系統中狀況良好的節點。 |
| Geode | 部署跨多個地理位置在主動-主動可用性模式中運作的系統。 此模式會使用資料複寫來支援任何用戶端可以連線到任何地理實例的理想。 它可協助您的工作負載承受一或多個區域性中斷。 |
| 健康情況端點監視 | 藉由公開專為該用途設計的端點，提供監視系統健康情況或狀態的方法。 您可以使用此端點來管理工作負載的健康情況，以及警示和儀表板。 您也可以使用它作為自我修復補救的訊號。 |
| 索引資料表 | 藉由讓用戶端查閱中繼資料來優化分散式資料存放區中的資料擷取，以便直接擷取資料，避免需要執行完整資料存放區掃描。 由於用戶端會透過查閱程式指向其分區、分割區或端點，因此您可以使用此模式來加速資料存取的容錯移轉方法。 |
| 選出領導者 | 建立分散式應用程式的實例 領導者 。 領導者會協調與達成目標相關的責任。 此模式可藉由可靠地重新導向工作來減輕節點故障的影響。 當領導者故障時，它也會透過共識演算法實作容錯移轉。 |
| 管道與篩選器 | 將複雜的資料處理細分成一系列的獨立階段，以達成特定結果。 每個階段的單一責任可讓焦點注意，並避免干擾干擾所認可的資料處理。 |
| 優先順序佇列 | 確保優先順序較高的專案會在優先順序較低的專案之前處理和完成。 根據商務優先順序分隔專案，可讓您將可靠性工作焦點放在最重要的工作上。 |
| 發行者/訂閱者 | 藉由透過中繼訊息代理程式或事件匯流排的通訊取代直接用戶端對服務或用戶端對服務通訊，來分離架構的元件。 |
| 佇列型負載調節 | 藉由在佇列中緩衝傳入要求或工作，並讓佇列處理器以受控制步調處理它們，來控制傳入要求或工作的層級。 這種方法可將工作的抵達與處理分離，藉此針對突然的需求暴增提供復原能力。 它也可以隔離佇列處理中的故障，使其不會影響進入。 |
| 速率限制 | 控制用戶端要求的速率，以減少節流錯誤，並避免未系結的重試錯誤案例。 當服務設計為避免達到指定的限制時，這項策略可保護用戶端，方法是確認與服務通訊的限制和成本。 其運作方式是控制在特定時段內傳送至服務的作業數目和/或大小。 |
| 重試 | 解決可能暫時性或間歇性失敗，方法是以受控制的方式重試特定作業。 降低分散式系統中的暫時性錯誤是改善工作負載復原能力的關鍵技術。 |
| Saga 分散式交易 | 藉由將工作分解成較小的獨立交易序列，協調長時間執行且可能複雜的交易。 每個交易也必須有補償動作，才能在執行中反向失敗並維護完整性。 由於跨多個分散式系統的整合型交易通常不可能，因此此模式會藉由實作不可部分完成性和補償來提供一致性和可靠性。 |
| 排程器代理程式監督員 | 根據系統中可觀察的因素，有效率地分散和重新散發整個系統的工作。 此模式會使用健康情況計量來偵測失敗，並將工作重新路由傳送至狀況良好的代理程式，以減輕故障的影響。 |
| 循序群組 | 維護並行傳訊輸入，同時支援以定義的連續處理。 此模式可以消除難以疑難排解的競爭條件、爭用的訊息處理或其他因應措施，以解決可能導致故障的錯誤排序訊息。 |
| 分區化 | 將負載導向至特定邏輯目的地以處理特定要求，以啟用共置以進行優化。 因為資料或處理會隔離到分區，所以一個分區中的故障仍會與該分區隔離。 |
| 扼制圖 | 提供一種方法，讓您以新的元件來有系統地取代執行中系統的元件，通常是在系統移轉或現代化期間。 此模式的累加方法有助於在轉換期間降低風險。 |
| 節流 | 對資源或元件的連入要求速率或輸送量施加限制。 您可以設計限制來協助防止資源耗盡，這可能會導致故障。 您也可以使用此模式作為正常降級計畫中的控制機制。 |
下一步
檢閱支援其他 Azure Well-Architected Framework 要素的雲端設計模式：