本指南提供最佳做法，說明如何在以應用程式為中心的 Google Cloud 中，使用 App Hub 和 Application Design Center 設計、定義及管理 App Hub 應用程式。遵循這些做法是建立可運作、可管理且有效率的應用程式的關鍵，有助於達成業務目標。
應用程式管理的核心原則
遵循下列核心原則，有助於以應用程式為中心管理基礎架構，進而盡量提高價值： Google Cloud
定義明確的界線：以符合作業、監控、管理和疑難排解邏輯的方式，設定應用程式管理界線。此外，您用做應用程式元件的此邊界內資源，最好能共用作業生命週期或業務價值，以簡化管理作業並降低風險。
為達到運作目的，請務必瞭解應用程式管理邊界和可觀測範圍之間的差異。
- 應用程式管理邊界定義了專案集合，其中包含可用於設計、建立及管理應用程式的 Google Cloud 資源，如「重要概念」一文所述。
- Google Cloud Observability 的可觀測範圍可讓您同時查看多個專案的遙測資料。
記錄、指標和追蹤範圍應包含應用程式管理邊界內相同專案的資料。如要進一步瞭解觀測範圍，請參閱「設定觀測範圍」。
反映業務能力：根據業務功能或端對端工作流程定義應用程式，而不僅是技術層面。應用程式應代表貴商家的不同價值串流。
建立明確的擁有權和中繼資料：為每個應用程式指派明確的屬性，讓團隊在應用程式中心有效尋找、瞭解及管理應用程式。這些屬性可協助探索及管理資料。 可探索性是指開發人員和營運人員等相關團隊可以找到應用程式。治理機制會明確定義每個應用程式的擁有者和負責人。
在 App Hub 中，您可以定義下列重要屬性：
- 環境：應用程式生命週期中的階段，例如正式環境、預備環境、測試環境或開發環境。這個屬性可協助團隊根據部署階段篩選及管理元件。
- 重要性：應用程式及其元件對業務的重要性，例如是否對業務至關重要。這項屬性可做為監控和事件回應優先順序的依據。
- 擁有者：負責應用程式的不同團隊的聯絡資訊，有助於落實問責制、簡化通訊，以及釐清責任。
應用程式設計中心支援這些屬性，也包含應用程式元件的位置和設定詳細資料。持續套用這些屬性和詳細資料，對於探索、管理和報表作業至關重要。
為演進而設計：您可以透過 Application Design Center 建立應用程式的範本，以便重複使用，為演進而設計。更新基礎範本後，您可以重新部署應用程式來套用這些變更，以滿足需求、推出新功能或進行架構變更，因應未來的成長和不斷變化的基礎架構需求。
反覆運算及調整應用程式模型：定期檢查及調整應用程式定義，以反映貴機構的結構、業務優先事項和技術架構變化。Cloud Hub 提供集中式檢視畫面，方便您查看從 Application Design Center 範本部署的應用程式可用更新，並根據不斷變化的需求，檢查及調整應用程式定義。
資料模型建議
瞭解如何將實際系統模擬為 App Hub 架構中的應用程式、服務和工作負載，有助於在 Google Cloud環境中有效運用應用程式管理功能。
定義應用程式時，請務必套用應用程式管理的核心原則，例如使用屬性建立明確的擁有權和中繼資料。
如要根據這個架構建立應用程式元件模型，請參考下列建議用途範例。
範例：以微服務為基礎的應用程式
以微服務為基礎的應用程式範例包括電子商務系統，例如線上商店的 OpenTelemetry 示範中描述的系統。建議您將這類系統建模為單一應用程式。這種做法可提供從產品探索到結帳的整個業務功能統一檢視畫面。舉例來說，請參考下列現有資源的模型，這些資源在 Google Cloud中執行：
應用程式：在 App Hub 中建立或定義單一應用程式，例如命名為
my-ecommerce-site。這個應用程式代表整個線上商店，可做為單一可管理的單元。將下列資源註冊至應用程式，建立元件的邏輯分組，共同提供線上商店的業務功能：- 微服務做為工作負載：註冊構成電子商務系統的個別微服務，例如「廣告」、「購物車」和「結帳」，做為應用程式中的工作負載。這些是具有二進位碼的運算資源，可執行業務邏輯的離散部分，以 Google Kubernetes Engine (GKE) 部署的形式執行。
- 網路端點即服務：將這些微服務的網路端點 (例如負載平衡器) 註冊為應用程式的服務。這些會向用戶公開網路商店功能。
請避免將每個微服務註冊為個別應用程式。這種做法會導致業務背景資訊不完整，難以全面掌握網路商店的健康狀態和成效。
將所有微服務歸入單一應用程式，可享有下列優點：
- 全面掌握：您可以在單一整合式檢視畫面中，監控整個電子商務使用者歷程的健康狀態和成效，包括廣告功能和結帳功能。
- 明確的業務背景：應用程式會根據所服務的業務功能 (即網路商店) 調整基礎架構。這種做法有助於瞭解應用程式的健康狀態和費用。
- 簡化疑難排解：發生問題時，您可以查看應用程式中不同微服務之間的依附元件，加快根本原因分析速度。
範例：三層式網頁應用程式
三層式網頁應用程式是一種架構模式，可將應用程式劃分為前端層、後端層和資料庫層。這個用途是示範如何將完整的業務功能建模為單一應用程式，而不是將每個層視為獨立元件。
下圖模型將技術層對應至三層式網頁應用程式：
應用程式：建立單一應用程式 (例如
my-web-app)，做為構成網路應用程式的所有元件的邏輯容器。服務：將向其他層級或使用者公開功能的網路介面註冊為服務，例如：
- 接收使用者流量的前端負載平衡器。
- 管理前後端之間流量的內部負載平衡器。
- Cloud SQL 或 Spanner 資料庫執行個體，可將資料服務公開給後端邏輯層。
工作負載：將執行應用程式程式碼的運算資源註冊為工作負載，例如：
- 代管執行個體群組 (MIG) 或 Google Kubernetes Engine 部署作業，用於提供前端使用者介面。
- 執行後端業務邏輯的 MIG 或 Google Kubernetes Engine 部署作業。
將這三個層級全部分組到單一應用程式中，可享有下列好處：
- 統一觀測：您可以在應用程式監控的單一資訊主頁中，監控整個應用程式的健康狀態和效能，不必再從三個不同的應用程式中拼湊資料。
- 明確的擁有權：您可以為
my-web-app應用程式指派商家、開發人員和營運人員擁有者，釐清整個業務職能的責任。 - 簡化管理：您可以在
my-web-app層級套用政策和存取權控管，在所有層級維持一致的管理方式。
應用程式設計和管理策略
請採用下列策略，確保 App Hub 和應用程式設計中心設定可擴充、可管理，且符合您的作業實務。
選擇全域或區域應用程式
為應用程式選擇位置 (全域或區域) 是基本決策，會影響資料處理、延遲和法規遵循：
- 優先處理區域應用程式：盡可能將應用程式定義為區域應用程式。這項做法可帶來多項優點，例如縮短延遲時間、節省成本，以及符合資料落地規定。如果所有應用程式元件都位於單一 Google Cloud 區域內，建議使用區域應用程式，因為這類應用程式與區域專屬 Google Cloud 功能和故障網域具有固有的相容性。如需建構高可用性系統的指引，請參閱透過資源備援機制建構可用性高的系統。
- 策略性地使用全域應用程式：只有在系統元件必須分布在多個區域，或涉及全域 Google Cloud 資源 (例如全域外部應用程式負載平衡器) 時，才選擇全域應用程式。
- 分解多區域系統：如果多個區域中的資源並未形成單一連貫的全球功能，請考慮為每個區域中的元件定義個別的區域應用程式。這個做法可讓每個部署作業充分發揮區域化優勢。
如要詳細比較 App Hub 中不同的部署地理位置，請參閱「全球和區域應用程式」。
將環境分成不同的應用程式
為支援安全性、權限和作業風險的隔離，請將不同的部署環境 (例如開發、測試和實際工作環境) 視為不同的應用程式。舉例來說，您可以將應用程式架構為 my-app-dev、my-app-staging 和 my-app-prod。
將環境劃分為不同的應用程式，可精確限制存取控管、政策執行和監控作業。此外，在應用程式元件中持續使用屬性、設定詳細資料和位置，可提高曝光度並強制執行治理。這些屬性提供豐富的中繼資料，可用於篩選、產生報表及套用政策。舉例來說，Environment 屬性可針對不同的部署環境政策，提供精細的詳細資料和資源專屬控制項。如要進一步瞭解這項屬性和其他屬性，請參閱「屬性和屬性」。
根據團隊結構調整應用程式管理界線
在應用程式管理邊界內，代表您的組織架構，特別是負責應用程式開發和營運的團隊。
這種做法可簡化擁有權和通訊，因為應用程式模型會反映貴商家用來定義工作劃分、分組和協調方式的架構，以達成其功能。
遵循應用程式生命週期
整合 App Hub 與 Application Design Center，打造順暢的應用程式生命週期體驗：
- 您有要註冊到應用程式的現有資源：使用 App Hub 將現有 Google Cloud 資源註冊為應用程式中的服務或工作負載。這項做法可讓您快速掌握現有基礎架構的統一檢視畫面和作業控制權。您也可以在 Application Design Center 中，從執行中的應用程式建立範本，以便為日後的部署作業統一架構。
- 您沒有要註冊到應用程式的現有資源：使用 Application Design Center，透過受控的可重複使用範本設計及部署新應用程式。從 Application Design Center 範本部署應用程式時，系統會自動在 App Hub 註冊元件，確保應用程式模型能準確反映預期設計。您也可以透過應用程式設計中心，根據範本修訂版本管理一致的應用程式更新。更新範本後，您可以重新部署應用程式來傳播變更，確保一致性和治理。
資源階層結構注意事項
Google Cloud中的資源階層結構是實用應用程式管理功能的基礎。您可以在該階層的頂端導入應用程式管理層，方法是設定管理專案，定義應用程式管理邊界。如要概略瞭解不同產品如何共同運作，成為以應用程式為中心的 Google Cloud 解決方案，請參閱以應用程式為中心的 Google Cloud。
仔細規劃應用程式管理資源階層，是建立邏輯群組的必要條件。 Google Cloud 您選擇單一專案、資料夾或一組專案來定義應用程式管理邊界，從根本上決定了控管、政策執行和資源探索。此外，以應用程式為中心的 Google Cloud 產品支援服務，會因您定義的應用程式管理界線而異。
如要根據資源階層和業務需求定義最合適的應用程式管理邊界，並瞭解不同資源結構模式的產品支援，請參閱「選擇應用程式設定模型」。
持續改善
應用程式設計並非靜態，通常會隨著時間演進。定期檢查及調整應用程式，確保應用程式持續符合業務功能、團隊結構和不斷變化的架構。
建議您使用 Cloud Hub 和 Gemini Cloud Assist 的洞察資料，找出最佳化機會並相應調整應用程式。使用 Application Design Center 建立架構變更模型及部署變更，並透過範本管理應用程式的生命週期。