雲端原生解決方案可藉由建置新的工作負載（應用程式）或將新功能新增至現有的工作負載，來建立新的商業價值。 無論您是開發全新的應用程式或將新功能新增至現有的系統，雲端原生開發都是規劃、建置、部署和優化工作負載的旅程。 此架構提供端對端指引，以確保您的雲端原生應用程式符合商務目標、架構良好，並以最低風險提供。
必要條件：Azure 著陸區
定義雲端原生解決方案的商務目標
從明確的業務目標開始。 定義雲端原生解決方案應實現的特定結果，例如啟用新的數位產品、進入新市場、改善客戶體驗，或降低營運成本。 使用可測量的指標，例如營收增長、縮短上市時間，或支援票證數量來量化成功。 針對新功能，請定義目標，例如改善客戶體驗、降低營運成本或增加系統延展性。
識別條件約束和成功準則。 記錄任何商務限制，例如預算、合規性或傳遞時程表。 定義每個目標成功的標準。 例如，「透過 Q4 啟動新的客戶入口網站」或「將結帳延遲減少 40%」。這些準則會引導優先順序，並協助評估規劃期間的取捨。
驗證項目關係人的一致性。 確認所有相關人士（商務和技術人員）都同意目標、限制和成功的定義。 此對齊方式可能牽涉到工作坊或正式簽署。 早期對齊可防止稍後的溝通錯誤，並避免成本高昂的重新作業，確保每個人都從一開始就具有相同的期望。
定義雲端原生解決方案的需求
記錄功能需求。 記錄系統必須提供的功能和功能，以符合使用者需求。 每個需求都應該系結至商務目標，確保開發工作直接支援所需的結果。 使用項目關係人面試和商務策略檔來識別高價值的結果。 根據商務價值和技術可行性來設定功能優先順序。 將每個需求追蹤至可測量的商業目標，以證明其包含合理性。
建立非功能性需求。 非功能需求會定義符合功能需求和治理的技術需求。 建立支持這些功能所需的品質屬性和技術目標。 針對運行時間、恢復點目標（RPO）和復原時間目標（RTO）定義目標 可靠性計量 ，例如服務等級目標（SLO）。 建立 安全性基準。 建立 成本模型。 設定 效能目標。
控制雲端原生解決方案的範疇。 清楚定義初始版本的範圍與範圍外的內容。 包含更多"附加功能"是很有吸引力的，但範圍擴張可能會影響計劃進度和預算。 記錄解決方案的界限，並針對任何新的要求實作變更控制程式。 僅核准對已定義目標有直接支援並且能在不破壞排程或預算的情況下實施的變更。 將優先順序較低的想法延遲到未來的待辦專案。 嚴格管理範圍可讓小組專注於在限制內先提供最有價值的功能。
規劃雲端原生架構
規劃良好的架構對於滿足您的目標和需求至關重要。 每個主要架構決策都牽涉到延展性、複雜度、成本和靈活度方面的取捨。 下列步驟和決策點可協助您製作符合最佳做法的雲端原生設計：
探索已驗證的雲端原生架構
檢閱架構基本概念和最佳做法。 從頭開始發明架構之前，請先檢閱 Azure 架構中心的已驗證參考架構和基本概念。 熟悉的架構樣式包括探索常見工作負載的已驗證參考架構。 這些架構有助於加速設計決策並降低風險。
選取適當的架構樣式。 根據工作負載的特性和小組功能選擇 架構樣式 。 架構樣式包括多層式（整合型）、微服務、事件驅動（訊息型）、web-queue-worker。 例如，如果您需要針對相對簡單的應用程式進行快速開發，則結構良好的多層式整合型可能已足夠。 對於具有不同網域的大型或快速進化應用程式，微服務或事件驅動方法可提供彈性（複雜度成本）。 實際上，許多系統最終都會有混合式樣式。 例如，架構的核心可能包含微服務，並具有某些共用服務或事件驅動的子系統。 關鍵是瞭解每個樣式的取捨，並選取最符合延展性、復原性和靈活度需求的方法。
套用設計最佳做法。 無論您挑選哪種樣式，都必須遵守雲端 架構基本概念 和 最佳做法。 Azure 架構中心提供 雲端設計模式 目錄（重試、斷路器、CQRS），可解決分散式工作負載中的常見挑戰。 將這些模式整合到您的設計中，可以改善可靠性和效能。
將五個要素整合到設計決策中。 使用 Well-Architected Framework 來指導可靠性、安全性、效能效率、成本最佳化和卓越營運方面的決策。 這五個要素應指導所有設計決策。 例如，選擇資料庫時，請考慮可靠性（備援、備份）、效能和成本，以達到正確的平衡。 文件說明您在支柱之間的取捨，例如為了更高的效能而增加成本。 這些附註對於未來的治理和檢閱很有價值。
規劃與現有系統的整合
清查所有相依系統和服務。 除非您是初創公司，否則雲端原生的新解決方案很少會獨立運作。 請考慮新的工作負載或功能如何融入環境。 繪製數據流，並確保與標準相容。 建立您工作負載與其互動之所有系統的完整清單。 此清單包含內部 API、資料庫、識別提供者（Microsoft Entra ID）、監視工具、CI/CD 管線，以及透過 VPN 或 ExpressRoute 存取的內部部署系統。 使用架構圖表和相依性對應來可視化這些關聯性。
分類整合類型和通訊協定。 依類型分類每個整合點（驗證、數據交換、傳訊）和通訊協定（REST、gRPC、ODBC、SAML、OAuth2）。 此分類有助於識別相容性需求和潛在瓶頸。
驗證身分識別和存取整合。 請確定您的解決方案與組織的身分識別提供者整合。 例如，使用 Microsoft Entra ID 進行驗證和授權，而不是引進新的身分識別系統。 確認單一登錄 （SSO）、角色型訪問控制 （RBAC） 和條件式存取原則的支援。
評估網路連線和安全性。 檢查您的工作負載如何連接到其他系統。 驗證防火牆規則、DNS 解析和路由路徑。 針對混合式案例，請確認 ExpressRoute 或 VPN 設定已就緒並經過測試。 使用 Azure Network Watcher 來監控並解決連線問題。
確保數據流相容性與合規性。 規劃系統之間的數據流。 確認數據格式、架構和轉換需求。 確保符合數據駐留地、加密和數據保留政策的規範。
儘早且持續地測試整合點。 在早期開發階段執行整合測試。 針對無法使用的系統使用模擬物件和存根物件。 使用 Azure DevOps 或 GitHub Actions 等工具，在您的 CI/CD 管線中自動執行這些測試。 監視延遲、輸送量和錯誤率。 例如，您想要避免應用程式所依賴的 API 不支援必要的負載，或是網路防火牆封鎖您的服務。
檔整合合約和 SLA。 定義並記錄每個整合點的預期行為、可用性和效能。 包含重試邏輯、逾時設定和後援機制。 與相依系統的服務等級協定 （SLA） 一致。
選取適當的 Azure 服務和服務層級
使用決策指南來選取符合工作負載需求的服務。 Azure 提供多個選項來執行您的應用程式程式碼，每個都有優缺點。 檢閱 技術選擇概觀 ，以識別符合您功能和非功能需求的服務。 排定平臺即服務 （PaaS） 選項的優先順序，因為這些服務可藉由自動處理基礎結構管理、修補和調整來降低作業額外負荷。
定義使用模式和效能需求，以選取服務層級。 服務層級選取會影響成本和功能。 記錄預期的交易量、並行使用者載入、記憶體需求和效能目標，例如響應時間和輸送量。 使用這些計量來選取符合基準需求的初始服務層級 （SKU），而不需要大量過度布建。 規劃根據部署后的實際使用模式來調整階層。
驗證所選服務層級的功能相容性。 進階安全性功能、高可用性選項或整合 API 等重要功能會因服務層級而異。 建立將必要功能對應至可用 SKU 的功能矩陣。 請確定選取的層支援所有必要的功能，以避免稍後進行昂貴的移轉或架構變更。 參考 服務特定的檔 ，以確認功能可用性和限制。
選取要使用的區域數目
評估多區域部署的取捨。 單一區域架構更簡單且更便宜，但區域性中斷會降低您的應用程式。 多區域部署可以達到更高的可用性（一個區域可能會失敗，而使用者會從另一個區域提供服務），也可以藉由提供來自最接近區域的使用者來改善效能。 權衡會增加部署和資料同步的複雜性。 您必須跨區域處理數據復寫，並有潛在的一致性問題、全域流量路由，以及更高的成本。 讓您的可靠性需求推動此決策。
使用可靠性目標來引導區域策略。 定義服務等級目標 （SLO）、恢復點目標 （RPO） 和復原時間目標 （RTO），以判斷區域需求。
確認遵循數據駐留法規的合規性。 請與法律和合規性小組合作，確保區域選擇符合法規義務。
檔架構
建立詳細的架構圖表和設計檔。 文件支援實作、檢視和未來的維護。 包含選取的 Azure 服務、SKU、數據流和用戶互動。 請確定圖表提供架構的清楚視覺表示，以支持實作和檢閱。
記錄重要的設計決策和取捨。 記錄架構選擇背後的原理，包括可靠性、安全性和效能等非功能需求。 強調任何權衡取捨，以平衡競爭的優先順序。
規劃雲端原生部署策略
當您將雲端原生解決方案部署至生產環境時，請遵循規劃的策略，而不是臨機作推送。 穩固的部署計劃可將對用戶的影響降到最低，並提供在發生問題時復原的方法。
規劃開發和部署做法
開發與部署的實踐可確保跨環境的一致傳遞和運營準備。 這些做法可降低部署風險，並改善小組協調。
建立部署自動化的 DevOps 做法。 DevOps 做法會透過自動化、版本控制和 CI/CD 管線，讓開發和作業小組保持一致。 使用 Azure DevOps 或 GitHub Actions 之類的工具，將建置、測試和部署工作流程自動化。 此方法可減少手動錯誤、加速發行週期，以及跨環境提供一致的部署程式。
規劃 作業整備以支援 部署活動。 運行準備包括部署場景的監視、警示和事件響應程序。 記錄部署操作手冊和自動化腳本，這些內容涵蓋回退程序、健康檢查和故障排除步驟。 將這些資源儲存在 Azure DevOps Wiki 或 GitHub 等中央位置，以確保部署活動期間的輔助功能。
定義支援可靠部署 的開發做法 。 使用程式代碼撰寫標準、對等檢閱和自動化測試，以確保程式代碼品質和部署整備程度。 將這些做法整合到 CI/CD 管線中，以在部署之前設定品質檢查點。 包含部署特定測試，例如整合測試、煙霧測試和效能驗證，以驗證系統是否適合生產環境。
規劃新工作負載的部署
使用漸進式暴露來限制影響。 對於沒有現有使用者的新應用程式（綠地），您應該執行軟啟動。 部署到生產環境，但一開始只會向內部使用者或試驗群組公開。 這種方法是用於新工作負載的 Canary 部署。 如果確實是全新的且隔離的，就有可能將一次性部署到完整生產環境，但還是建議逐步釋出，以受控方式發現任何問題。 請勿在第一天對 100% 用戶釋放系統，而不需要先進行一些真實世界的驗證。 如需詳細資訊，請參閱 WAF - 採用漸進式曝光模型。
記錄作業流程和升級路徑。 建立清晰的文件，以重新啟動服務、存取日誌、處理常見問題，以及升級事件。 將此文件儲存在 SharePoint 或 GitHub 等共用存放庫中，以確保支援小組的可用性。
規劃新功能的部署
使用變更管理規劃新功能整合。 請遵循組織的變更管理程式來控制和記錄生產變更。 定義復原程式，例如還原應用程式版本或還原資料庫備份。 在部署之前獲得利害關係人的批准，以確保與業務目標保持一致。 如需詳細資訊，請參閱 CAF 中的 變更管理。
針對次要或回溯相容變更使用就地更新。 使用滾動更新或功能旗標，直接將更新部署至生產環境。 從一小部分的用戶或實例開始。 監視系統計量和記錄，以在完整推出之前驗證穩定性。
針對主要或高風險變更使用平行部署（藍色-綠色）。 在不同的環境中部署新版本。 將少部分的線上流量分配至新版本，以驗證其行為。 如果成功，請將所有流量移轉至新版本。 如果發生問題，請將流量還原為原始版本，以確保持續性。
規劃新工作負載的作業移交。 識別負責在部署後操作和支援解決方案的團隊。 定義支援模型（24/7 隨選或上班時間支援），並確保所有項目關係人都瞭解其角色。
定義擁有權和支持責任。 確認作業小組已準備好支援新功能。 更新檔和呈報路徑，以反映新的責任，並確保快速回應事件。
定義雲端原生解決方案的復原方案
復原計劃可讓小組在部署失敗或帶來風險時快速回復變更。 妥善定義的計劃可將停機時間降到最低、限制業務影響，以及維護系統可靠性。 在起始任何移轉或部署之前，請一律建立復原準則和程式。
定義失敗的部署。 與商務項目關係人、工作負載擁有者和作業小組共同作業，以決定哪些專案是失敗的部署。 範例包括失敗的健康情況檢查、效能不佳、安全性問題或未達到成功計量。 此定義可確保復原決策符合貴組織的風險承受能力。 在部署計劃中包含觸發復原的特定條件，例如 CPU 使用量限制、回應時間閾值或錯誤率。 此評估會在事件期間清楚且一致地做出復原決策。
自動化 CI/CD 管線中的回滾步驟。 使用 Azure Pipelines 或 GitHub Actions 之類的工具，將復原程序自動化。 例如，如果健康情況檢查失敗，請設定管道以重新部署先前版本。
建立工作負載特定的回復指示。 開發符合工作負載類型、環境和部署方法的復原步驟。 例如，基礎結構即程序代碼部署需要重新套用先前的範本。 應用程式復原牽涉到重新部署先前的容器映像。 將復原腳本、設定快照集和基礎結構即程式代碼範本附加至復原方案。 這些資產可快速執行，並減少對手動介入的依賴性。
測試回滾程序。 模擬生產階段前環境中的部署失敗，以驗證復原效率。 識別並解決自動化、許可權或相依性的差距。 確認回復會將系統還原到穩定且已知的良好狀態。
改善回滾策略 在每次部署或回滾事件之後，進行回顧以評估哪些有效，哪些無效。 根據經驗教訓、架構變更或新工具，更新回滾準則、程序和自動化。 維護文件，以確保回復策略保持最新且有效。