Azure 上電信業者等級工作負載的設計原則
電信業者等級工作負載必須根據 Well-Architected 架構品質要素的指導方針來設計:
本文說明可產生和擴充 任務關鍵性設計原則的電信業者等級設計原則。 這些共同原則可作為跨重要設計領域的後續設計決策的藍圖。 強烈建議您瞭解這些原則,以進一步瞭解其效果,以及與不符合規範相關聯的取捨。
在工作負載需求的內容中,有明顯的 成本取捨 與引進更高的可靠性相關,這應該仔細考慮。
重要
本文是 Azure Well-Architected 電信業者等級工作負載 系列的一部分。 如果您不熟悉此系列,建議您從 什麼是電信業者等級工作負載開始?
考慮這些點時,請記住這個高階架構模型。
假設失敗
從假設一切可以開始,而且將會失敗。 應用程式設計必須允許容錯失敗,讓應用程式可以繼續在某些層級運作。
將單一失敗點降至最低,並實作 同盟方法。
跨多個區域部署應用程式,並跨這些區域進行適當的資料管理,以允許 CAP 定理的影響。
在幾秒內自動偵測問題並回應。 如需詳細資訊,請參閱 健康情況監視。
測試完整的解決方案,包括應用程式實作、平臺整合和部署。 這項測試應該包括生產系統上 的混亂測試 ,以避免測試偏差。
不共用任何內容
共用不 一般且直接的方法,可達到高可用性。 當應用程式可由可交換的多個不同元素提供服務時,請使用此方法。 個別元素必須有清楚瞭解的可用性計量,但不需要很高。 不過,元素必須結合在一起,才能保持獨立,且沒有共用基礎結構或相依性。
不常無法共用任何內容。 若要從任何 應該 共用的位置開始,而且只加入最小可能共用相依性集合中,應該會產生最佳解決方案。
範例
假設單一系統每年有六小時的停機時間, (大約 3.5*9s) ,結合四個系統,其中停機時間不相關期間每年會經歷不到 30 秒的停機時間。 一旦這四個系統依賴泛型服務,例如全域 DNS,其停機時間就不再不相關。 產生的停機時間會更高。
後續步驟
檢閱電信業者等級工作負載的容錯設計區域。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應