應用程式的架構元件可分為「前端」或「後端」。在某些情況下，這些元件可以託管在不同的運算環境中運作。在分層混合架構模式中，運算環境位於地端部署的私人運算環境和 Google Cloud。
前端應用程式元件會直接向使用者或裝置公開。因此，這些應用程式通常高度重視效能表現。為開發新功能及改良現有功能，軟體更新頻率可能會較高。由於前端應用程式通常仰賴後端應用程式來儲存及管理資料，以及處理商業邏輯和使用者輸入內容，因此通常為無狀態，或只管理有限的資料量。
如要確保前端應用程式易於存取和使用，您可以運用各種架構和技術建構應用程式。前端應用程式的成功關鍵因素包括應用程式效能、回應速度和瀏覽器相容性。
後端應用程式元件通常專注於儲存及管理資料。在某些架構中，商業邏輯可能會併入後端元件。後端應用程式推出新版本的速度通常不會像前端應用程式那麼頻繁。後端應用程式在管理方面面臨下列挑戰：
- 處理大量要求
- 處理大量資料
- 保護資料安全
- 在所有系統副本中維護最新資料
三層式網頁應用程式解決方案是建構商務網頁應用程式最常見的實作方式之一，例如包含不同應用程式元件的電子商務網站。這個架構包含下列層級。每個層級都是獨立運作，但彼此緊密相連，共同發揮作用。
- 網頁前端和展示層
- 應用程式層
- 資料存取或後端層
將這些層放入容器中，可區隔技術需求 (例如擴充需求)，並協助分階段遷移。此外，您還能將這些應用程式部署至與平台無關的雲端服務，以便在不同環境之間移植、使用自動化管理功能，以及透過雲端管理平台 (例如 Cloud Run 或 Google Kubernetes Engine (GKE) Enterprise 版) 進行擴充。此外，Google Cloud代管資料庫 (例如 Cloud SQL) 可做為資料庫層提供後端服務。
分級混合架構模式的重點是將現有的前端應用程式元件部署至公有雲。在這個模式中，您會將所有現有的後端應用程式元件保留在私人運算環境中。您可以根據應用程式的規模和特定設計，依個案情況遷移前端應用程式元件。詳情請參閱「遷移至 Google Cloud」。
如果您現有的應用程式在內部部署環境中託管後端和前端元件，請考量目前架構的限制。舉例來說，隨著應用程式擴展，對效能和穩定性的要求也會提高，這時您就應開始評估是否要重構應用程式的部分內容，或是移至更合適的架構。「分級混合」架構模式可讓您先將部分應用程式工作負載和元件移至雲端，再進行全面轉換。此外，也請務必考量這類遷移作業的成本、時間和風險。
下圖顯示典型的分層混合架構模式。
在上圖中，用戶端要求會傳送至 Google Cloud中託管的應用程式前端。接著，應用程式前端會將資料傳回應用程式後端所在的內部部署環境 (最好是透過 API 閘道)。
採用分層混合式架構模式時，您可以運用Google Cloud 基礎架構和全球服務，如下圖的範例架構所示。應用程式前端可透過 Google Cloud存取。此外，您也可以使用自動調整資源配置功能，動態且有效率地因應資源調度需求，不必過度佈建基礎架構，為前端增加彈性。您可以使用不同的架構，在 Google Cloud上建構及執行可擴充的網頁應用程式。每種架構各有優缺點，適合不同的需求。
如需更多資訊，請觀看 YouTube 上的「在 Google 上執行可擴充網路應用程式的三種方式 Google Cloud」。如要進一步瞭解在Google Cloud上翻新電子商務平台的各種方式，請參閱「如何在 Google Cloud上建構數位商務平台」。
在上圖中，應用程式前端託管於Google Cloud ，透過全域負載平衡、自動調度資源和 Google Cloud Armor 的 DDoS 防護功能，提供全球最佳化的多區域使用者體驗。
過了一段時間之後，您部署至公用雲端的應用程式數量可能會增加，直到您考慮將後端應用程式元件遷移至公用雲端。如果您預期會處理大量流量，選擇雲端代管服務或許有助於您管理自己的基礎架構，進而節省工程資源。除非限制或需求規定必須在本機代管後端應用程式元件，否則請考慮這個選項。舉例來說，如果您的後端資料受到法規限制，可能需要將該資料保留在內部部署環境。不過，在適用且符合規範的情況下，使用私密資料保護功能 (例如去識別化技術)，有助於在必要時移動這類資料。
在分層混合架構模式中，您也可以在某些情境中使用 Google Distributed Cloud。您可以透過 Distributed Cloud，在 Google 提供及維護的專屬硬體上執行 Google Kubernetes Engine 叢集，並與 Google Cloud 資料中心分開。為確保 Distributed Cloud 符合您目前和未來的需求，請瞭解 Distributed Cloud 與傳統雲端 GKE 區域相比的限制。
優點
先專注於前端應用程式有以下幾項優點：
- 前端元件會仰賴後端資源，偶爾也會仰賴其他前端元件。
- 後端元件不會仰賴前端元件。因此，區隔及遷移前端應用程式比較不會像遷移後端應用程式那麼複雜。
- 由於前端應用程式通常為無狀態，而且本身並不管理資料，因此遷移通常沒那麼困難。
- 遷移時可以最佳化前端元件，改用無狀態架構。詳情請觀看 YouTube 上的「如何將有狀態的網頁應用程式移植到 Cloud Run」。
將現有或新開發的前端應用程式部署至公用雲端可提供下列多項優點：
- 許多前端應用程式受限於頻繁的變更。在公有雲中執行這些應用程式，可簡化持續整合/持續部署 (CI/CD) 程序的設定作業。您可以使用 CI/CD，以有效率且自動化的方式傳送更新。詳情請參閱「 Google Cloud上的 CI/CD」。
- 如果前端重視效能，且流量負載量不一，那麼雲端部署提供的負載平衡、多區域部署、Cloud CDN 快取、無伺服器和自動調度資源功能，就能大幅提升效能 (最好採用無狀態架構)。
使用 GKE 等雲端管理平台，採用容器化微服務，即可使用微前端等現代架構，將微服務擴展至前端元件。
擴充微服務通常用於前端，涉及多個團隊在同一個應用程式上協作。這類團隊結構需要採取疊代式做法，並持續維護。使用微前端的優點包括：
- 可做為獨立的微服務模組，用於開發、測試及部署。
- 可讓個別開發團隊選擇偏好的技術和程式碼。
- 這樣一來，開發和部署週期就能快速進行，不會影響其他團隊可能管理的其餘前端元件。
無論是實作使用者介面或 API，或是處理物聯網 (IoT) 資料擷取，前端應用程式都可以受益於 Firebase、Pub/Sub、Apigee、Cloud CDN、App Engine 或 Cloud Run 等雲端服務提供的功能。
雲端管理的 API Proxy 有助於：
- 將應用程式導向的 API 與後端服務 (例如微服務) 分離。
- 防止應用程式受到後端程式碼變更的影響。
- 支援現有的 API 驅動前端架構，例如前端後端 (BFF)、微前端等。
- 在 Apigee 上實作 API Proxy，即可在 Google Cloud 或其他環境中公開 API。
您也可以反向套用分級混合模式，將後端部署在雲端，同時將前端保留在私人運算環境。雖然這種做法較不常見，但處理重量級單體式前端時，最適合運用這種方法。在這種情況下，反覆擷取後端功能並將這些新的後端部署在雲端，可能會比較簡單。
本系列文章的第三部分會討論可啟用這類架構的網路模式。Apigee Hybrid 可做為平台，在混合式部署模型中建構及管理 API Proxy。詳情請參閱鬆散耦合架構，包括分層單體式和微服務架構。
最佳做法
規劃分層混合式架構時，請參考本節資訊。
簡化複雜度的最佳做法
套用分層混合架構模式時，請考慮下列最佳做法，有助於降低整體部署和作業複雜度：
- 根據對所識別應用程式通訊模型的評估結果，為這些應用程式選取最有效率且有效的通訊解決方案。
由於大部分的使用者互動包含跨多個運算環境連結的系統，因此這些系統之間快速且低延遲的連結至關重要，為符合可用性和效能期望，您應設計高可用性、低延遲和適當的總處理量等級。從安全性的角度來看，通訊需要細部控制。理想情況下，您應該使用安全 API 公開應用程式元件。詳情請參閱閘道出口。
- 如要盡量減少環境之間的通訊延遲，請選取地理位置靠近私人運算環境的Google Cloud 區域，應用程式後端元件會託管在該環境中。詳情請參閱「選擇 Compute Engine 地區的最佳做法」。
- 盡可能減少在不同環境中執行的系統之間的高度依附元件，尤其是在同步處理通訊時。這些依附元件可能會降低效能、減少整體可用性，並產生額外的輸出資料傳輸費用。
- 採用分層混合架構模式時，從內部部署環境進入Google Cloud 的輸入流量，可能會大於離開 Google Cloud的輸出流量。不過，您應瞭解離開 Google Cloud的預期輸出資料移轉量。如果您打算長期使用此架構，且輸出資料量較高，建議使用 Cloud Interconnect。Cloud Interconnect 有助於提升連線效能，並可能降低符合特定條件的流量傳出資料費用。詳情請參閱 Cloud Interconnect 定價。
- 為保護私密資訊，建議您加密所有傳輸中的通訊內容。如需在連線層進行加密，可以使用 VPN 通道、採用 Cloud Interconnect 的高可用性 VPN，以及 Cloud Interconnect 的 MACsec。
為解決不同後端間通訊協定、API 和驗證機制不一致的問題，建議您視情況部署 API 閘道或 Proxy，做為統一的表面。這個閘道或 Proxy 會做為集中控制點，並執行下列措施：
- 導入額外的安全措施。
- 保護用戶端應用程式和其他服務，避免受到後端程式碼變更的影響。
- 方便稽核所有跨環境應用程式及其分離式元件之間的通訊。
- 做為舊版和現代化服務之間的中介通訊層。
- Apigee 和 Apigee Hybrid 可讓您在內部部署環境、邊緣、其他雲端和Google Cloud 環境中，代管及管理企業級和混合式閘道。
如要簡化混合式設定的建立程序，請搭配混合式連線使用 Cloud Load Balancing。 也就是說，您可以將雲端負載平衡的優點擴展至地端運算環境中託管的服務。這種做法可讓工作負載分階段遷移至 Google Cloud ，服務中斷情形降到最低或完全不會中斷，確保分散式服務順利轉換。詳情請參閱混合式連線網路端點群組總覽。
有時，同時使用 API Gateway、Proxy 和 Application Load Balancer，可提供更強大的解決方案，大規模管理、保護及分配 API 流量。搭配 API 閘道使用 Cloud Load Balancing 可讓您達成下列目標：
- 使用 Apigee 和 Cloud CDN 提供高效能 API，縮短延遲時間、在全球代管 API，並在流量尖峰季節提高可用性。詳情請觀看 YouTube 上的「透過 Apigee 和 Cloud CDN 提供高效能 API」影片。
- 實作進階流量管理。
- 使用 Cloud Armor 做為 DDoS 防護和網路安全服務，保護您的 API。
- 在多個區域中，有效管理閘道之間的負載平衡。如需更多資訊，請觀看 YouTube 上的「Securing APIs and Implementing multi-region failover with Private Service Connect and Apigee」。
使用 API 管理和服務網格，透過微服務架構保護及控管服務通訊和曝光。
- 使用 Cloud Service Mesh，在由分散式服務組成的系統中，促成服務之間的通訊，並維持服務品質，同時管理服務之間的驗證、授權和加密作業。
- 使用 Apigee 等 API 管理平台，將這些服務以 API 的形式公開，方便貴機構和外部實體使用。
在環境之間建立通用身分識別，讓系統能夠跨越環境界線以安全的方式進行驗證。
在公有雲中部署 CI/CD 和設定管理系統。詳情請參閱鏡像網路架構模式。
為提高作業效率，請在各個環境間使用一致的工具和 CI/CD 管道。
個別工作負載和應用程式架構的最佳做法
- 雖然這個模式的重點在於前端應用程式，但仍請注意對後端應用程式進行現代化的需求。如果後端應用程式的開發步調比前端應用程式慢相當多，這項差異可能會導致額外的複雜情況。
- 將 API 視為後端介面，可簡化整合、前端開發、服務互動，並隱藏後端系統的複雜性。為解決這些挑戰，Apigee 可協助您開發及管理混合式和多雲端部署作業的 API 閘道/Proxy。
- 根據內容 (靜態與動態)、搜尋引擎最佳化成效，以及網頁載入速度的期望，為前端網頁應用程式選擇轉譯方法。
- 為內容導向的網路應用程式選取架構時，有多種選項可供選擇，包括單體式、無伺服器、事件導向和微服務架構。如要選取最合適的架構，請根據目前和未來的應用程式需求，徹底評估這些選項。如要根據業務和技術目標做出架構決策，請參閱內容導向網頁應用程式後端的不同架構比較，以及網頁後端的重要考量事項。
採用微服務架構後，您可以使用容器化應用程式，並以 Kubernetes 做為通用執行階段層。使用分層混合式架構模式，您可以在下列任一情境中執行：
跨雲端和地端環境 (Google Cloud 和您的地端環境)。
- 在不同環境中使用容器和 Kubernetes 時，您可以彈性地將工作負載現代化，然後在不同時間遷移至 Google Cloud 。當工作負載大量取決於另一個工作負載且無法個別遷移時，這會非常有幫助，或者您也可以使用混合式工作負載可攜性，在每個環境中使用最佳資源。在所有情況下，GKE Enterprise 都是重要的啟用技術。詳情請參閱 GKE Enterprise 混合式環境。
在 Google Cloud 遷移及現代化應用程式元件的環境中。
- 如果您的舊版後端位於內部部署環境，且不支援容器化，或短期內需要大量時間和資源才能完成現代化，請使用這種方法。
如要進一步瞭解如何設計單體式應用程式，並重構為微服務架構，以實現網路應用程式架構現代化，請參閱微服務簡介。
您可以根據網路應用程式的需求，合併使用資料儲存技術。使用 Cloud SQL 儲存結構化資料，並使用 Cloud Storage 儲存媒體檔案，是滿足各種資料儲存需求的常見做法。不過，選擇哪種方式主要取決於您的用途。如要進一步瞭解內容導向應用程式後端的資料儲存空間選項和有效模式，請參閱「內容導向網頁應用程式的資料儲存空間選項」。另請參閱「資料庫選項說明」。 Google Cloud