針對商務需求建置
每個設計決策都必須依商務需求來合理。 此設計原則看起來可能很明顯,但在設計 Azure 應用程式時,請務必記住這一點。
您的應用程式必須支持數百萬個使用者,還是幾千個使用者? 是否有大型流量高載或穩定的工作負載? 可接受的應用程式中斷層級為何? 最後,商務需求會推動這些設計考慮。
下列建議可協助您設計和建置符合商務需求的解決方案:
定義商務目標 ,例如復原時間目標 (RTO)、恢復點目標 (RPO),以及最大可容忍中斷 (MTO)。 這些數字應該會通知有關架構的決策。
例如,假設您的企業需要非常低的 RTO 和非常低的 RPO。 您可以選擇使用區域備援架構來符合這些需求。 如果您的企業可以容忍較高的 RTO 和 RPO,新增備援可能會增加額外的成本,而不需要獲得任何業務利益。
請考慮您需要減輕的失敗風險。 請遵循設計自我修復指引,設計解決方案以復原許多常見失敗模式類型。 請考慮您是否需要考慮較不可能發生的情況,例如發生重大自然災害的地理區域,可能會影響該區域中的所有可用性區域。 減輕這些罕見的風險通常更昂貴,而且涉及重大取捨,因此清楚了解企業對風險承受能力。
記錄服務等級協定 (SLA) 和服務等級目標 (SLA), 包括可用性和效能計量。 例如,建議的解決方案可能會提供99.95%的可用性。 SLO 是否符合 SLA 是否為商務決策。
為商務網域建立模型應用程式 。 分析商務需求,並使用這些需求來建立解決方案的模型。 請考慮使用網域驅動設計 (DDD) 方法來建立能反映商務程式和使用案例的領域模型。
定義功能和非功能需求。 功能需求會決定應用程式是否執行其工作。 非功能需求會決定應用程式執行程度。 請確定您瞭解非功能性需求,例如延展性、可用性和延遲。 這些需求會影響設計決策和技術選擇。
將工作負載分解為離散功能。 工作負載是應用程式資源、數據和支援基礎結構的集合,可同時運作,以達成已定義的商務成果。 工作負載是由元件和開發和作業程式所組成。 工作負載通常會分解成與使用者、數據或系統流程一致的離散功能,而這些流程可以是屬性值,而且具有非功能性需求。
不同的使用者、數據或系統流程通常有不同的可用性、延展性、數據一致性和災害復原需求。 設計良好的系統可讓您將每個流程的設計優化。 若要達成此目的,您必須將工作負載分解成可調整的元件。 一般策略牽涉到根據其值來分類元件。 例如,第 1 層元件很重要,而且應該不考慮費用而優化。 第 2 層元件相當重要,但可以暫時減少,但會產生最少的後果。 第 3 層元件是選擇性的;讓它們符合成本效益且易於管理。 建立對流程價值的共同瞭解,可協助每個人設計和演進工作負載,在成本與其他非功能性需求之間保持平衡。
規劃成長。 解決方案可能支援用戶數目、交易量和數據記憶體的目前需求,但也需要在不需要重大架構變更的情況下處理成長。 也請考慮您的商務模型和商務需求可能會隨著時間而變更。 如果應用程式的服務模型和數據模型過於殭化,則很難為新的使用案例和案例發展解決方案。
調整商業模式和成本。 系統的壽命會受到其成本如何與商業模式保持一致的影響。 身為架構設計人員,您必須考慮價值驅動因素,並使用該見解來引導您的決策。 您應該識別解決方案將提供價值(例如獲利率)的維度,然後確定架構遵循價值數據流。 如此一來,您的架構就能將投資的價值最大化,併產生符合業務期望的投資報酬率。。
管理成本。 在傳統的內部部署應用程式中,您需預付硬體作為資本支出。 在雲端應用程式中,您會為取用的資源付費。 請確定您瞭解服務的定價模式。 總成本可能包括網路頻寬使用量、記憶體、IP 位址和服務耗用量。
也請考慮作業成本。 在雲端中,您不需要管理硬體或基礎結構,但仍需要管理應用程式 DevOps、事件回應和災害復原。