環境混合模式

採用環境混合架構模式時,您可以將工作負載的實際工作環境保留在現有資料中心,然後將公有雲用於開發和測試環境,或其他環境。這個模式仰賴多個運算環境間的相同應用程式備援部署。部署目標是協助提高容量、靈活度和韌性。

評估要遷移哪些工作負載時,您可能會發現在公有雲端執行特定應用程式的情況存有困難:

  • 管轄區或法規限制可能會要求您將資料保存在特定國家。
  • 第三方授權條款可能會禁止您在雲端環境中執行某些軟體。
  • 應用程式可能會要求只能在本機使用的硬體裝置存取權。

在這種情況下,請同時考量實際工作環境與應用程式生命週期內涉及的所有環境,包括開發、測試及暫存系統。這些限制通常適用於實際工作環境及其資料。這些規則可能不適用於未使用實際資料的其他環境。請洽詢貴機構的法規遵循部門或同等團隊。

下圖顯示典型的環境混合架構模式:

資料從 Google Cloud 中託管的開發環境,流向地端或另一個雲端環境中的正式環境。

在不同於實際工作環境系統的環境中執行開發與測試系統似乎是冒險的做法,而且可能與現有的最佳做法或嘗試盡可能縮小環境差異的做法背道而馳。雖然這類考量是合理的,但如果您區隔開發與測試程序的各個階段,則不適用。

雖然每個應用程式的開發、測試和部署程序互不相同,通常包含下列階段的變化:

  • 開發:建立候選版本。
  • 功能測試或使用者接受度測試:確認候選版本符合功能性需求。
  • 效能與可靠性測試:確認候選版本符合非功能性需求。也稱為負載測試。
  • 暫存或部署測試:確認部署程序是否有效。
  • 正式環境:發布新應用程式或更新應用程式。

在單一環境中同時執行上述多個階段幾乎是不切實際的,因此每個階段通常需要一或多個專屬環境。

測試環境的主要用途在於執行功能測試。暫存環境的主要用途是測試應用程式部署程序是否如預期般運作。等到版本到達暫存環境時,功能性測試應該已經完成。這是將軟體部署到正式版部署環境前的最後一個步驟。

為了確保測試結果有意義且可套用到實際工作環境部署,您在整個應用程式的生命週期內使用的環境組合必須盡可能符合下列規則:

  • 所有環境都具有「功能相等性」。也就是說,架構、API 以及作業系統版本和程式庫都是相等的,而且環境間的系統都有相同的運作方式。這樣的相等性可避免發生應用程式可在某個環境運作但卻在其他環境失敗的情況,或無法重現瑕疵的情況。
  • 用於效能與可靠性測試、暫存及實際工作的環境具有非功能相等性。也就是說,其效能、規模及設定,以及運作和維護方式都是相同的,或只在某些細微的方面有所不同。否則,效能與暫存測試就會變得沒有意義。

一般來說,用於開發和功能測試的環境可以與其他環境有非功能性的差異。

如下圖所示,測試和開發環境是建構在 Google Cloud上。代管資料庫 (例如 Cloud SQL) 可做為 Google Cloud的開發和測試選項。開發和測試作業可以在地端環境中使用相同的資料庫引擎和版本、功能相同的引擎和版本,或是在測試階段後推出至實際工作環境的新版本。不過,由於這兩個環境的基礎架構並不相同,因此這種效能負載測試方法無效。

開發和 QA 團隊透過 Google Cloud 測試和 QA 執行個體,將資料傳送至無效的內部部署正式環境系統。

下列情況很適合環境混合模式:

  • 在適用且可行的情況下,仰賴 Kubernetes 做為通用執行階段層,讓所有環境具備功能相等性。Google Kubernetes Engine (GKE) Enterprise 版是這項做法的關鍵技術。
    • 確保工作負載可攜性,並抽取出運算環境之間的差異。透過零信任服務網格,您可以控管及維持不同環境之間所需的通訊隔離。
  • 在公用雲端中執行開發和功能測試環境。這些環境與其餘環境具有功能相等性,但可能在效能等非功能層面有所不同。如上圖所示。
  • 在私人運算環境中,執行用於正式作業、中繼測試作業及效能 (負載測試) 與可靠性測試的環境,確保功能面和非功能面的相等性。

設計注意事項

  • 業務需求:應用程式的每項部署和發布策略都有各自的優缺點。為確保所選方法符合特定需求,請根據業務需求和限制進行全面評估,然後再做出選擇。
  • 環境差異:這個模式的主要目標是使用雲端環境進行開發和測試。最終狀態是在私有內部部署環境 (實際工作環境) 中代管測試的應用程式。為避免開發及測試功能時,在雲端環境中運作正常,但在生產環境 (內部部署) 中失敗,技術團隊必須瞭解這兩個環境的架構和功能。這包括對其他應用程式和硬體基礎架構的依附元件,例如執行流量檢查的安全系統。
  • 控管:如要控管貴公司可在雲端開發的內容,以及可供測試的資料,請使用核准和控管程序。這個程序也能協助貴公司確保開發和測試環境中使用的雲端功能,與內部部署正式環境中的功能一致。
  • 成功條件:必須有明確、預先定義且可衡量的測試成功條件,並符合貴機構的軟體品質保證標準。請將這些標準套用至您開發及測試的任何應用程式。
  • 備援:雖然開發和測試環境可能不需要像正式環境一樣的可靠性,但仍需要備援功能,以及測試不同失敗情境的能力。失敗情境需求可能會促使設計在開發和測試環境中納入備援機制。

優點

在公用雲端中執行開發和功能測試工作負載可提供下列多項優點:

  • 您可以在需要的時候自動啟動及停止環境。舉例來說,您可以為每個修訂或提取要求佈建整個環境,允許執行測試,然後再次將它關閉。這種做法也有以下優點:
    • 您可以在虛擬機器 (VM) 閒置時停止執行個體,或僅於需要時佈建環境,藉此減少費用。
    • 您可以為每個提取要求啟動暫時性環境,加快開發和測試速度。這樣做也能減少維護負擔,並降低建構環境中的不一致性。
  • 在公有雲中執行這些環境,有助於熟悉雲端和相關工具,並建立信心,這可能也有助於遷移其他工作負載。如果您決定使用容器和 Kubernetes 探索工作負載可攜性,例如在各個環境中使用 GKE Enterprise,這個方法就特別實用。

最佳做法

如要成功實作環境混合式架構模式,請考慮採用下列建議:

  • 定義應用程式通訊需求,包括最佳網路和安全防護設計。然後使用鏡像網路模式,設計網路架構,避免不同環境的系統直接通訊。如果需要跨環境通訊,則必須以受控方式進行。
  • 您選擇的應用程式部署和測試策略應符合業務目標和需求。這可能包括在不中斷服務的情況下推出變更,或是在廣泛發布前,逐步向特定環境或使用者群組實作功能。

  • 為了讓工作負載可以移轉到他處,並去除不同環境之間的差異,您可能會使用容器和 Kubernetes。詳情請參閱 GKE Enterprise 混合式環境參考架構

  • 建立可在各個運算環境間使用的通用工具鍊,以部署、設定及管理工作負載。使用 Kubernetes 可為您帶來這樣的一致性。

  • 確保運算環境間採用一致的持續整合/持續推送軟體更新管道,並將同一組二進位檔、套件或容器部署至各種環境。

  • 使用 Kubernetes 時,請使用 Tekton 等持續整合系統來實作部署管道,部署至叢集並在各個環境間使用。詳情請參閱 Google Cloud上的開發運作解決方案。

  • 為協助您持續發布安全可靠的應用程式,請將安全性納入 DevOps 流程 (DevSecOps) 的重要環節。詳情請參閱「使用 Dev(Sec)Ops Toolkit 在不到一小時內交付及保護面向網際網路的應用程式」。

  • 將相同的工具用於 Google Cloud與現有雲端環境間的記錄和監控。請考慮使用開放原始碼監控系統。詳情請參閱「混合雲和多雲端的監控及記錄模式」。

  • 如果測試和實際工作環境的工作負載是由不同的團隊管理,使用不同的工具或許可以接受。不過,使用檢視權限不同的相同工具,有助於減少訓練工作和複雜度。

  • 為功能測試選擇資料庫、儲存空間及訊息傳遞服務時,請使用在 Google Cloud上具有代管對應項目的產品。仰賴代管服務可協助減少維護開發和測試環境的管理工作。

  • 為保護私密資訊,建議您將所有傳輸中的通訊內容加密。如果需要在連線層進行加密,您可以根據選取的混合式連線解決方案,選擇各種選項。這些選項包括 VPN 通道、採用 Cloud Interconnect 的高可用性 VPN,以及 Cloud Interconnect 的 MACsec。

下表顯示哪些 Google Cloud 產品與常見 OSS 產品相容。

OSS 產品 相容於 Google Cloud 產品
Apache HBase Bigtable
Apache Beam Dataflow
CDAP Cloud Data Fusion
Apache Hadoop Dataproc
MySQL、PostgreSQL Cloud SQL
Redis 叢集、Redis、Memcached Memorystore
網路檔案系統 (NFS) Filestore
JMS、Kafka Pub/Sub
Kubernetes GKE Enterprise