App Hub 適用於支援的地區，可協助您在 App Hub 應用程式中整理全球或區域 Google Cloud 基礎架構資源。位置支援功能可讓您根據應用程式元件的地理位置，以及與基礎架構其他部分的通訊方式，將這些元件分組，簡化管理作業。
建立應用程式時，請將位置定義為「全球」或「區域」。這項選擇是決定哪些服務和工作負載可納入應用程式的基礎。此外，這項選擇對資料處理、共置、費用和法規遵循都有重大影響。全球和區域應用程式的定義如下：
全域應用程式：從功能上將服務和工作負載分組，這些服務和工作負載會分散至全球各地或多個 Google Cloud 區域。舉例來說，您可以納入全域應用程式負載平衡器服務，以及分布在全球各地的後端工作負載。
區域應用程式：按照服務和工作負載分組，這些服務和工作負載完全位於單一 Google Cloud 區域內。舉例來說，您可以納入區域性應用程式負載平衡器服務及其後端工作負載，這些都位於
us-central1。
如要做出最符合需求的決策，請務必瞭解Google Cloud 區域和可用區，這兩者旨在提供容錯能力和高可用性。區域是獨立的地理區域，可用區則是區域內的部署區域，可做為單一故障網域。如要進一步瞭解全域和區域資源，請參閱「地理位置與地區」和「Cloud 服務據點」。
比較全域和區域性應用程式
下表重點列出全球和區域應用程式的主要差異和注意事項，協助您做出選擇：
| 全球應用程式 | 區域應用程式 | |
|---|---|---|
| 建議用途 | 最適合具有本質上屬於全球性或分布於多個區域的元件的應用程式。 | 如果所有應用程式元件都位於同一個 Google Cloud 區域內，即使這些元件跨越多個專案，也建議使用這項設定。 |
| 資源範圍 | 可包含任何區域的全球和區域 Google Cloud 資源。 | 只能包含與應用程式位於 Google Cloud 相同單一區域的資源。您無法在區域應用程式中註冊全域元件。 |
| 應用程式中繼資料 | 儲存在多個區域，可從任何區域存取。 Google Cloud 不支援資料落地。 |
儲存在特定區域，但可從任何其他 Google Cloud 區域存取。 不支援資料落地。 |
| 範例 | 管理全域負載平衡應用程式，後端元件位於不同區域，可集中檢視分散式系統。 | 管理應用程式，其中包含 us-central1 中的所有服務和工作負載。 |
為應用程式選取最佳位置
在選擇全域和區域位置時，請考量業務功能 (應用程式代表) 的架構和作業需求。以下比較結果是以地理區域考量為依據：
- 一般來說，區域應用程式比全域應用程式更具優勢。如要利用較低的元件延遲時間、符合資料地區性規定、節省潛在的網路費用，以及享有與區域專屬功能一致的特性，請選擇「區域」應用程式。 Google Cloud
- 如果應用程式元件必須分布在多個區域，或依賴全域 Google Cloud 資源，請選擇全域應用程式。
您可能有多個位於不同區域的 Google Cloud 資源，這些資源無法形成單一、連貫的全域函式。在這種情況下，最佳做法通常是為每個區域內的元件定義個別的區域應用程式。這種做法可為每個部署作業充分發揮區域化優勢。
Google Cloud 資源階層是定義資料夾和專案整理方式的基礎。如果階層結構規劃得當，與區域或全球應用程式管理邊界一致，就能簡化應用程式中服務和工作負載的分組和管理作業。詳情請參閱「選擇應用程式設定模型」。
區域應用程式的優點
全域應用程式可為分散式系統提供彈性。不過，為 App Hub 應用程式選擇區域位置可帶來顯著優勢：
支援資料落地和法規遵循：應用程式中樞中繼資料不提供資料落地功能。不過，區域應用程式可確保基礎Google Cloud 資源處理及儲存的實際資料，會留在您選取的地理區域限制內。這項優勢通常對於遵守資料地域性的法律、法規和組織要求至關重要。
縮短延遲時間：將應用程式元件放在同一區域內，通常可盡量縮短元件之間的網路延遲時間，進而提升應用程式效能和使用者體驗。
符合產品功能規定：某些 Google Cloud 產品或功能規定所有互動元件都必須位於同一區域。舉例來說，Compute Engine 執行個體只能連結位於同一區域的永久磁碟。區域性 App Hub 應用程式本質上符合這類架構限制。
降低成本：不同 Google Cloud 區域之間的資料移轉通常會產生網路費用，而同一區域內的網路流量通常價格較低。在區域中建立應用程式，有助於管理及減少跨區域網路費用。
與故障網域保持一致： Google Cloud 區域設計為獨立的故障網域。在單一區域內部署應用程式，並在該區域內使用多個區域來確保高可用性，可讓應用程式的容錯能力與 Google Cloud的基礎架構復原模型保持一致。