本指南提供最佳做法，協助您在 App Hub 中設計及定義應用程式。有效設計應用程式是充分運用以應用程式為中心的 Google Cloud 的關鍵，可提升可視性、控管能力和作業效率。
應用程式設計的核心原則
遵循下列核心原則，有助於建立穩健、易於維護且符合業務目標的應用程式，進而充分發揮 App Hub 的價值：
反映業務能力：根據業務功能或端對端工作流程定義 App Hub 應用程式，而不只是技術層或個別微服務。應用程式應代表企業的獨特價值流。
確認明確的擁有權：為每個應用程式指派明確的屬性和屬性，支援探索和管理。特別是新增應用程式擁有者可促進問責制，並簡化溝通流程。
考量應用程式界線：定義適合作業、監控和控管的界線。應用程式內的資源最好共用作業生命週期和影響範圍，以簡化管理作業並降低作業風險。
從作業角度考量應用程式的界線時，請務必瞭解 Google Cloud Observability 如何建構資料收集和顯示方式。App Hub 著重於應用程式界線，而 Google Cloud Observability 則使用範圍定義哪些遙測資料可跨專案顯示及分析。這些可觀測範圍的設定與主專案或管理專案有特定關係，決定您如何彙整及查看不同專案的遙測資料。如要進一步瞭解如何設定這些項目以取得統一檢視畫面，請參閱「設定可觀測性範圍」。
因應演變：設計應用程式時，請考量架構日後的變化和成長。
反覆修正：定期檢查及調整應用程式，以反映機構架構、團隊和業務優先事項的變更。
應用程式的定義
瞭解 App Hub 中的應用程式定義，是有效整合Google Cloud應用程式管理功能的基本前提。應用程式會將共同提供特定業務功能的服務和工作負載分組。如要進一步瞭解 App Hub 中應用程式、服務和工作負載的核心概念，請參閱概念和資料模型。
如要判斷 App Hub 應用程式的適當界線，請思考下列重要問題：
- 這組資源能為使用者或商家帶來哪些價值？
- 這些元件是否共用相同的作業生命週期？
- 這些資源是否都有明確的統一擁有權？
- 這個分組方式是否能有效監控及排解問題？
範例：OpenTelemetry 示範架構
OpenTelemetry 示範架構代表電子商務系統，包含「廣告」、「購物車」和「結帳」等微服務。如要在 App Hub 中妥善定義這個應用程式，請考慮下列建議：
將整個電子商務系統模擬為一個 App Hub 應用程式，例如
my-ecommerce-site：- 個別微服務的運算執行個體 (例如 Google Kubernetes Engine (GKE) 部署作業) 會對應至 App Hub 工作負載。
- 網路端點 (例如負載平衡的 gRPC/HTTP 介面) 會對應至 App Hub 服務。
請避免將每個微服務 (例如「廣告」、「購物車」和「結帳」) 註冊為各自的 App Hub 應用程式。這種做法會導致業務情境支離破碎。
如要進一步瞭解 App Hub 支援的基礎架構資源 (以服務和工作負載的形式)，請參閱「App Hub 支援的資源」。
設計策略
請採用下列設計策略，確保 App Hub 設定可擴充、可管理，且符合您的作業實務。
選擇全域或區域應用程式
設計 App Hub 應用程式時，最基本的決定是將應用程式定義為全域或區域。這項選擇會影響可納入的資源、資料處理方式、延遲時間、費用和法規遵循：
- 全域應用程式最適合本質上分散在多個 Google Cloud 區域的服務和工作負載，或依賴全域資源 (例如全域應用程式負載平衡器)。
- 如果所有應用程式元件都位於單一 Google Cloud 區域內，建議使用區域應用程式。如果架構允許，這通常是最佳做法。
下列最佳做法清單可協助您選擇全球或區域應用程式：
- 優先採用區域應用程式：請盡可能將應用程式設計為區域應用程式，以享有延遲時間縮短、跨區域網路流量的潛在成本節省、符合資料所在地規定，以及與區域專屬Google Cloud 功能和故障網域的內建相容性等優勢。
- 策略性地使用全域應用程式：只有在系統元件必須分散在各個區域，或涉及全域 Google Cloud 服務時，才選擇全域應用程式。
- 分解多區域系統：如果您在多個區域中擁有資源，但這些資源並未形成單一的全球功能，請考慮為每個區域中的資源定義個別的區域應用程式。這個做法可為每個部署作業帶來最大的區域化效益。
如需詳細比較，並深入瞭解這項選擇的影響，請參閱「全域和區域應用程式」。
將環境定義為個別應用程式
您可以將不同的部署環境表示為不同的 App Hub 應用程式。這種做法可有效隔離安全性、權限和作業風險，避免環境之間發生意外影響。
舉例來說，您可以將應用程式分別建構為 my-app-dev、my-app-staging 和 my-app-prod，用於開發、測試和正式環境。
您可以在單一應用程式中使用 Environment 屬性標記資源，但將環境劃分為不同的應用程式，可為存取權控管、政策強制執行和監控作業提供精確的界線。您仍須在這些環境專屬應用程式的資源上，持續使用 Environment 屬性，提供詳細資訊並進一步指定角色。如要進一步瞭解這項屬性和其他屬性，請參閱「使用屬性進行控管」。
配合團隊結構
建議您根據負責開發及運作應用程式的團隊，調整應用程式的界線。由於應用程式中心的應用程式模型會反映貴機構的結構，因此這種做法可簡化擁有權和通訊程序。
使用屬性進行管理
對所有應用程式資源套用屬性，以提升探索能力並落實控管。這些屬性提供豐富的中繼資料，可用於篩選、製作報表及套用政策：
- 嚴重程度：有助於排定監控和事件回應資源的優先順序。
- 環境：支援篩選功能和環境專屬政策。
- 擁有者：負責提供資訊和問責。
為使用這些屬性標記資源建立機構標準。 詳情請參閱「支援探索和管理功能」。
找出應用程式管理用途
整合 App Hub 與 App Design Center，從設計到營運，打造流暢的應用程式生命週期體驗：
- 您有要註冊為應用程式的現有資源：將 Google Cloud 設定模型中的現有資源註冊為 App Hub 中的應用程式，即可取得統一的檢視畫面和作業控制權。
- 您沒有可註冊為應用程式的現有資源：使用 Application Design Center 設計及部署新應用程式。Application Design Center 會自動在 App Hub 中註冊已部署的資源，因此模型會準確反映預期設計。您也可以透過 Application Design Center 管理應用程式更新。應用程式範本變更時，您可以更新以該範本為基礎的任何執行個體，確保應用程式更新作業一致。
資源階層
標準Google Cloud 資源階層結構包含機構、資料夾和專案資源。App Hub 透過應用程式啟用資料夾和主機專案的概念，在該階層結構之上導入應用程式管理層，具體做法取決於您的設定模型。
瞭解所選設定模型在現有資源階層結構中的適用情形，有助於有效管理、強制執行政策及探索資源。 Google Cloud選擇應用程式管理設定模型時，請查看建議的結構，並規劃資源階層。
持續改善
應用程式設計並非靜態，通常會隨著時間演進。定期檢查及調整應用程式，確保應用程式持續符合業務需求、團隊結構和不斷變化的架構。
建議您使用 Cloud Hub 和 Gemini Cloud Assist 的洞察資料，找出最佳化商機，並據此調整應用程式。此外，您可以使用 Application Design Center 管理應用程式的生命週期。Cloud Hub 的「Deployments」頁面會顯示可用的應用程式更新，這些更新來自應用程式所依據的 Application Design Center 範本，可簡化更新程序。