建置商務需求

  • 發行項

每個設計決策必須對應某個業務需求。 設計 Azure 應用程式時，此設計原則看起來可能很明顯，但請務必牢記在心。

您的應用程式必須支援數百萬個使用者，還是數千個使用者？ 是否有大型流量高載或穩定工作負載？ 可接受的應用程式中斷層級為何？ 最後，商務需求會推動這些設計考慮。

下列建議可協助您設計和建置符合商務需求的解決方案：

  • 定義商務目標 ，例如復原時間目標 (RTO) 、復原點目標 (RPO) ，以及 MTO) 的最大可容忍 (中斷。 決策人員應該了解架構相關的這些數字。

    例如，假設您的企業需要非常低的 RTO 和非常低的 RPO。 您可以選擇使用區域備援架構來符合這些需求。 如果您的企業可以容忍較高的 RTO 和 RPO，新增備援可能會為沒有業務權益的額外成本。

  • 請考慮您需要減輕的失敗風險。 請遵循 設計自我修復指引 ，設計解決方案以復原許多常見失敗模式類型。 請考慮您是否需要考慮較不可能發生的情況，例如發生重大自然災害的地理區域，可能會影響該區域中的所有可用性區域。 降低這些不常見的風險通常較昂貴，而且牽涉到重大取捨，因此清楚瞭解企業對風險的承受度。

  • 檔服務等級協定 (SLA) 和服務等級目標， (SLA) ，包括可用性和效能計量。 例如，建議的解決方案可能會提供 99.95% 的可用性。 該 SLO 是否符合 SLA 是否為商務決策。

  • 為您的商務領域建立模型應用程式。 分析商務需求，並使用這些需求來建立解決方案的模型。 請考慮使用領域驅動設計 (DDD) 方法來建立領域模型，以反映您的商務程式和使用案例。

  • 定義功能和非功能需求。 功能需求會決定應用程式是否執行其工作。 非功能需求會決定應用程式的執行效能。 請確定您瞭解非功能性需求，例如延展性、可用性和延遲。 這些需求會影響設計決策和技術選擇。

  • 分解工作負載。 此內容中的工作負載表示可邏輯上與其他工作分開的離散功能或計算工作。 不同的工作負載可能有不同的可用性、延展性、資料一致性和災害復原的需求。

  • 規劃成長。 解決方案可能支援使用者數目、事務量和資料儲存體的目前需求，但也需要處理成長，而不需要進行重大架構變更。 也請考慮您的商務模型和商務需求可能會隨著時間而變更。 如果應用程式的服務模型和資料模型太嚴格，則很難為新的使用案例和案例發展解決方案。

  • 管理成本。 在傳統的內部部署應用程式中，您會預付硬體作為資本支出。 在雲端應用程式中，您會支付所取用的資源費用。 請確定您瞭解服務的定價模式。 總成本可能包括網路頻寬使用量、儲存體、IP 位址和服務耗用量。

    也請考慮作業成本。 在雲端中，您不需要管理硬體或基礎結構，但仍需要管理應用程式 DevOps、事件回應和災害復原。

下一步