本節中的設計原則文章提供基礎，協助您建置雲端應用程式，以承受失敗、隨需求擴展，以及隨著業務需求而發展。 無論您是要設計新系統、現代化舊版應用程式，還是規劃生產工作負載，這些互連原則都可以幫助您就可靠性、效能和可維護性做出明智的決策。 它們共同構成了一種全面的雲端原生應用程式設計方法，平衡了卓越技術與商業價值。
若要讓您的應用程式更具可擴展性、彈性和可管理性，請遵循以下設計原則。
核心原則
自我修復設計。 設計您的應用程式以偵測失敗、正常回應並自動復原。 在分散式系統中，故障是不可避免的。 若要隔離失敗並維護系統可用性，請實作重試邏輯、健康端點監控、斷路器和艙壁模式。
讓所有的東西變得多餘。 在您的應用程式中建立備援以避免單點故障。 使用負載平衡器、多個執行個體、資料庫複本，以及多區域或多區域部署。 針對符合您的業務需求和風險承受能力的備援層級進行設計。
盡量減少協調。 將應用程式服務之間的協調降至最低，以達到延展性。 使用非同步通訊的解耦元件，在適當的情況下擁抱最終一致性，並套用網域事件來同步狀態，而無需緊密耦合。
設計為能夠橫向擴展。根據需求變化，設計您的應用程式以新增或移除執行個體。 避免工作階段黏性、識別瓶頸、透過擴展需求來分解工作負載，以及使用基於即時指標的自動擴展來有效處理可變負載。
圍繞限制進行分區。 使用數據分割來處理資料庫、網路和計算限制。 將資料水平、垂直或功能性地分區，並設計分區索引鍵以避免熱點。 請考慮在多個層級進行分割，包括資料庫、佇列和運算資源。
操作原則
為營運而設計。 設計您的應用程式，為營運團隊提供部署、監控和事件回應所需的工具。 實施全面的日誌記錄、分散式追蹤、標準化指標並自動化管理任務，以實現有效的營運監督。
使用受管服務。 使用平台即服務 （PaaS） ，而不是基礎結構即服務 （IaaS）。 受管服務可減少營運開銷、提供內建擴展功能、並讓團隊專注於應用程式邏輯，而不是基礎設施維護。
使用身分識別服務。 使用受控識別平台，例如 Microsoft Entra ID，而不是建置或操作您自己的身分識別系統。 受管解決方案提供憑證儲存、驗證功能、聯合功能，並符合業界標準。
戰略原則
為進化而設計。 為持續創新而設計，因為所有成功的應用程式都會隨著時間的推移而變化。 強制執行鬆散耦合、封裝領域知識、使用非同步傳訊，以及公開定義良好的 API，其中包括適當的版本控制，以實現獨立的服務演進。
為業務需求而構建。 根據業務需求做出設計決策。 定義明確的目標，例如復原時間目標 （RTO）、文件服務等級協定 （SLA） 和服務等級目標 （SLO）、圍繞業務領域建立應用程式模型，並在平衡功能和非功能需求的同時規劃成長。
執行服務的故障模式分析。 系統地識別系統中的潛在故障點並規劃復原策略。 若要從一開始就建立可靠性，請在架構和設計階段進行故障模式分析 （FMA）。 按風險和影響對每種故障模式進行評級，然後確定適當的響應和恢復機制。
應用這些原則
這些原則共同作用，以建立彈性、可擴展的應用程式：
從業務需求開始，瞭解您要建置的內容和原因。
透過實作自我修復功能和備援來設計以因應故障。
透過水平擴展、分割和最小協調來規劃擴展。
使用 Azure 服務 來降低作業複雜度，並專注於商務邏輯。
透過適當的監控、日誌記錄和自動化來支援營運。
針對變更而建置 ，以確保您的應用程式可以隨著業務需求而發展。