多雲端資料庫管理：架構、用途和最佳做法

本文件說明多雲端資料庫管理的部署架構、用途和最佳做法。本課程適用於在單一或多個雲端中設計及實作有狀態應用程式的架構師和工程師。

存取資料庫的多雲應用程式架構會依賴用途。單一具狀態的應用程式架構無法支援所有多雲用途。舉例來說，雲端爆發用途的最佳資料庫解決方案，與在多個雲端環境中同時執行的應用程式所需的最佳資料庫解決方案不同。

針對 Google Cloud等公用雲，有各種資料庫技術可用於特定的多雲用途。如要在單一公用雲端內的多個區域中部署應用程式，可以使用由供應商管理的多區域資料庫 (例如 Spanner) 等公用雲端。如要部署可在各公有雲端間移植的應用程式，不妨考慮採用不依附平台的資料庫，例如 AlloyDB Omni 或 PostgreSQL。

本文件將介紹有狀態資料庫應用程式的定義，接著分析多雲資料庫用途。接著，我們會根據用途，針對多雲部署架構提供詳細的資料庫系統分類。

這份文件也介紹了用於選擇資料庫的決策樹，其中概述了選擇適當資料庫技術的關鍵決策點。最後，我們將討論多雲資料庫管理的最佳做法。

重要詞彙和定義

本節提供術語，並定義本文件中使用的一般有狀態資料庫應用程式。

術語

• 公用雲端：公有雲提供多租戶基礎架構 (通常是全球) 和服務，客戶可用於執行正式版工作負載。 Google Cloud 是公有雲，提供許多代管服務，包括 GKE、GKE Enterprise 和代管資料庫。
• 混合式雲端。混合雲是公有雲與一或多個地端部署資料中心的組合。混合雲客戶可以將其內部部署服務與公有雲提供的其他服務結合。
• 多雲端。多雲端是指多個公有雲和內部部署資料中心的組合。混合雲是多雲的子集。
• 部署位置。基礎架構位置是指可部署及執行工作負載 (包括應用程式和資料庫) 的實體位置。舉例來說，在 Google Cloud中，部署位置是區域和區域。在抽象層級，公有雲區域或可用區和內部部署資料中心都是部署位置。

有狀態資料庫應用程式

為定義多雲用途，本文件使用了一般有狀態資料庫應用程式架構，如下圖所示。

下圖顯示以下元件：

• 資料庫：資料庫可以是單一執行個體、多執行個體或分散式資料庫，部署在運算節點上，或以雲端代管服務的形式提供。
• 應用程式服務。這些服務會組合成應用程式，用於實作商業邏輯。應用程式服務可以是下列任一項：
  • Kubernetes 上的微服務。
  • 粗粒度程序，在一或多部虛擬機器上執行。
  • 單體式應用程式位於單一大型虛擬機器上。
  • Cloud Run 函式或 Cloud Run 中的無伺服器程式碼。部分應用程式服務可存取資料庫。您可以多次部署各個應用程式服務。每個應用程式服務的部署作業都是該應用程式服務的例項。
• 應用程式用戶端。應用程式用戶端會存取應用程式服務提供的功能。應用程式用戶端可以是下列任一項：
  • 已部署的用戶端，在機器、筆電或手機上執行程式碼。
  • 未部署的用戶端，其中用戶端程式會在瀏覽器中執行。應用程式用戶端執行個體一律會存取一或多個應用程式服務執行個體。

在多雲資料庫討論的背景下，有狀態應用程式的架構抽象化包含資料庫、應用程式服務和應用程式用戶端。在應用程式實作中，使用作業系統或程式設計語言等因素可能會有所不同。不過，這些詳細資料不會影響多雲端資料庫管理。

佇列和檔案做為資料儲存服務

應用程式服務可使用許多持久性資源來儲存資料。這些資源包括資料庫、佇列和檔案。每個持久性資源都會提供專屬於這些模型的儲存資料模型和存取模式。雖然應用程式會使用佇列、訊息系統和檔案系統，但在下一個章節中，我們會特別著重於資料庫。

雖然佇列和檔案也適用於多雲端資料庫的部署位置、狀態共用、同步和非同步複寫等因素，但這項討論不在本文的範圍內。

網路

在一般有狀態應用程式的架構中 (如下圖所示)，元件之間的每個箭頭都代表透過網路連線的通訊關係，例如應用程式用戶端存取應用程式服務。

連線可在單一可用區內，或跨可用區、區域或雲端。您可以將任何部署位置組合連結在一起。在多雲環境中，跨雲端的網路連線是一項重要考量因素，您可以使用多種選項。如要進一步瞭解跨雲端網路，請參閱「分散式應用程式的跨雲端網路」和「連線至 Google Cloud：網路選項說明」。

在本文的應用實例中，假設以下情況：

• 雲端之間有安全的網路連線。
• 資料庫及其元件可以相互通訊。

從非功能性角度來看，網路的大小 (也就是處理量和延遲時間) 可能會影響資料庫的延遲時間和處理量。從功能角度來看，網路通常不會有任何影響。

多雲端資料庫用途

本節將介紹多雲端資料庫管理的幾種常見用途。針對這些用途，我們假設雲端和資料庫節點之間有安全的網路連線。

遷移應用程式

在多雲資料庫管理的情況下，應用程式遷移是指將應用程式、所有應用程式服務和資料庫從目前的雲端遷移至目標雲端。企業決定遷移應用程式的原因有很多，例如避免與雲端服務供應商競爭、翻新技術，或降低總持有成本 (TCO)。

在應用程式遷移作業中，我們的目標是停止在目前雲端的正式發布作業，並在遷移作業完成後，在目標雲端繼續進行正式發布作業。應用程式服務必須在目標雲端中執行。如要實作服務，可以使用升級與轉移方法。在這種做法中，相同的程式碼會部署至目標雲端。如要重新實作服務，您可以使用目標雲端提供的現代雲端技術。

從資料庫的角度來看，請考慮下列應用程式遷移替代方案：

• 資料庫升遷：如果目標雲端可使用相同的資料庫引擎，您可以將資料庫升遷至目標雲端，以便在目標雲端中建立相同的部署。
• 資料庫升級並遷移至同等的代管資料庫：如果目標雲端提供相同資料庫引擎的代管版本，您可以將自行管理的資料庫遷移至該版本。
• 資料庫現代化：不同雲端提供不同的資料庫技術。雲端服務供應商代管的資料庫可能具有優點，例如更嚴格的服務水準協議 (SLA)、可擴充性和自動災難復原功能。

無論採用何種部署策略，資料庫遷移作業都需要時間，因為需要將資料從目前的雲端移至目標雲端。雖然可以採用會造成停機的匯出和匯入方法，但建議採用停機時間最短或不停機的遷移方式。這種做法可盡量減少應用程式停機時間，並盡可能降低對企業及其客戶的影響。不過，由於這項方法涉及初始載入、持續複製、監控、精細驗證，以及切換時的同步處理，因此通常需要更複雜的遷移設定。如要支援備用方案，您必須實作反向複製機制，以便在切換至目標資料庫後，將變更同步回來源資料庫。

災難復原

災難復原是指應用程式在區域停機期間，繼續為應用程式用戶端提供服務的能力。為確保災難復原功能，應用程式必須部署至至少兩個區域，並隨時準備執行。在正式版中，應用程式會在主要區域執行。不過，如果發生服務中斷，次要區域就會成為主要區域。以下是災難復原的不同就緒模式：

• 熱待命。應用程式已部署至兩個以上的區域 (主要和次要)，且在每個區域中都能正常運作。如果主要區域發生故障，次要區域中的應用程式可以立即接收應用程式用戶端流量。
• 冷待命。應用程式在主要區域中執行，但已準備好在次要區域中啟動 (但未執行)。如果主要區域發生故障，應用程式會在次要區域中啟動。應用程式無法運作，直到應用程式能夠運作並為應用程式用戶端提供所有應用程式服務為止。
• 無待機模式。在這個模型中，應用程式程式碼已可部署，但尚未部署至次要區域 (因此不會使用任何已部署的資源)。如果主要區域發生中斷，應用程式的第一次部署必須在次要區域中進行。這項部署作業會讓應用程式處於與冷待命相同的狀態，也就是必須啟動。在這種做法中，應用程式停機時間會比冷備用情況長，因為必須先進行應用程式部署作業，包括建立雲端資源。

從資料庫的角度來看，上述清單中討論的準備就緒模型對應下列資料庫方法：

• 以交易為基礎同步處理的資料庫。這個資料庫對應於熱待命模式。主要區域中的每筆交易都會在次要區域中同步協調。當次要區域在服務中斷期間成為主要區域時，資料庫會保持一致，並立即可供使用。在此模型中，復原點目標 (RPO) 和復原時間目標 (RTO) 皆為 0。
• 非同步複製的資料庫。這個資料庫也對應到熱待命模式。由於從主要區域複製到次要區域的資料庫是異步的，如果主要區域發生故障，部分交易可能會複製到次要區域。雖然次要區域中的資料庫已準備好負荷實際工作負載，但可能不會含有最新的資料。因此，應用程式可能會導致無法復原的交易損失。由於存在這項風險，因此此方法的 RTO 為零，但 RPO 大於零。
• 閒置資料庫。這個資料庫對應於冷備援模式。資料庫會在沒有任何資料的情況下建立。主要區域發生故障時，資料必須載入至空轉資料庫。如要啟用這項動作，您必須在主要區域執行定期備份，並將備份資料轉移至次要區域。備份作業可以是完整備份或增量備份，這取決於資料庫引擎支援的備份類型。無論是哪種情況，資料庫都會設回上次備份，從應用程式角度來看，與主要區域相比，可能會遺失許多交易。雖然這種做法可能具有成本效益，但由於資料庫狀態未更新，因此自上次可用備份以來的所有交易都可能會遺失，因此這項做法的價值會受到影響。
• 沒有資料庫。這個模型等同於「無待機」情況。次要區域沒有安裝資料庫，如果主要區域發生故障，就必須建立資料庫。建立資料庫後，就像閒置資料庫的情況一樣，必須先載入資料，應用程式才能使用該資料庫。

即使使用的是主要和次要雲端 (而非主要和次要區域)，本文所述的災難復原方法也適用。主要差異在於，由於雲端之間的網路異質性，雲端之間的延遲時間可能會比雲端內區域之間的網路距離還要長。其他差異可能來自不同雲端服務供應商的受管理資料庫，這些資料庫的功能和預設設定各不相同。

整個雲端服務發生故障的可能性，低於某個區域發生故障的可能性。不過，企業還是可以將應用程式部署在兩個雲端中。這種做法有助於保護企業免於發生故障，或協助企業遵守業務或產業法規。

另一種災難復原方法是使用主要和次要區域，以及主要和次要雲端。這種方法可讓企業選擇最佳的災難復原程序，以因應失敗情況。如要讓應用程式執行，您可以視停機嚴重程度使用次要區域或次要雲端。

雲端爆發

Cloud Bursting 是指可在不同部署位置擴大應用程式用戶端流量的設定。當容量需求增加，而待命位置提供額外容量時，應用程式就會爆增。主要位置可支援一般流量，而備用位置則可在應用程式用戶端流量增加超過主要位置可支援的程度時，提供額外容量。主要和待命位置都已部署應用程式服務執行個體。

雲端爆發會在多個雲端中實作，其中一個雲端是主要雲端，另一個雲端是備用雲端。在混合雲環境中使用，可透過公有雲中的彈性雲端運算資源，擴充地端資料中心中有限的運算資源。

如需資料庫支援，可使用下列選項：

• 主要位置部署。在這個部署作業中，資料庫只會部署在主要位置，而不會部署在待命位置。當應用程式爆量時，位於待命位置的應用程式會存取主要位置的資料庫。
• 主要和待命位置部署。這項部署作業支援主要和待命位置。資料庫執行個體會部署在兩個位置，並由該位置的應用程式服務執行個體存取，特別是在爆發的情況下。如同跨雲端和雲端內的災難復原，這兩個資料庫可以透過交易同步處理，也可以非同步同步處理。在非同步同步處理中，可能會出現延遲。如果更新是在待命位置進行，則這些更新必須傳回至主要位置。如果兩個位置都可能同時更新，則必須實作衝突解決機制。

雲端爆發是混合雲的常見用途，可用於增加地端部署資料中心的容量。當資料必須留在某個國家/地區時，也可以在各公有雲端中使用這項方法。如果某個公用雲端服務在某個國家/地區只有一個區域，則可能會在同一個國家/地區的不同公用雲端服務區域中發生爆量。這種做法可確保資料留在該國家境內，同時解決公有雲區域中的資源限制。

使用同級最佳的雲端服務

有些應用程式需要專屬的雲端服務和產品，而這些服務和產品無法在單一雲端中使用。舉例來說，應用程式可能會在一個雲端服務中執行業務邏輯處理的業務資料，並在另一個雲端服務中分析業務資料。在這個用途中，應用程式的商業邏輯處理部分和分析部分會部署至不同的雲端。

從資料管理的角度來看，這些用途如下：

• 分區資料。應用程式的每個部分都有自己的資料庫 (獨立的分區)，且各個資料庫都不會直接連結。管理資料的應用程式會將任何需要在兩個資料庫 (分區) 中提供的資料寫入兩次。
• 非同步複製的資料庫。如果需要在另一個雲端中提供來自一個雲端的資料，不對稱的複製關係可能會很適合。舉例來說，如果數據分析應用程式需要相同的資料集或業務應用程式的資料集子集，則可以將後者複製到雲端之間。
• 以交易為基礎同步處理的資料庫。這類資料庫可讓您將資料提供給應用程式的兩個部分。每個應用程式的每項更新都會在交易中保持一致，並可立即提供給兩個資料庫 (區隔)。交易同步資料庫可有效地充當單一分散式資料庫。

分散式服務

分散式服務會在兩個以上的部署位置部署及執行。您可以將所有服務執行個體部署至所有部署位置。或者，您也可以根據硬體可用性或預期的負載限制等因素，在所有位置部署部分服務，並在其中一個位置部署其他服務。

在交易同步資料庫中，資料在所有位置都保持一致。因此，將這類資料庫部署至所有部署位置，是最佳做法。

使用非同步複製資料庫時，可能會同時在兩個部署位置修改相同的資料項目。如要判斷兩個衝突變更中哪一個是最終一致狀態，必須實作衝突解決策略。雖然可以實作衝突解決策略，但這項作業不一定簡單，有時需要手動介入，才能將資料還原為一致狀態。

分散式服務重新安置和容錯移轉

如果整個雲端區域發生故障，系統會啟動災難復原。如果有狀態資料庫應用程式中的單一服務發生錯誤 (而非區域或整個應用程式)，則必須復原並重新啟動該服務。

災難復原的初始方法是在原始部署位置重新啟動失敗的服務 (重新啟動原地方法)。Kubernetes 等技術會根據服務的設定自動重新啟動服務。

不過，如果這種原地重新啟動方法無法成功，則可改為在次要位置重新啟動服務。服務從主要位置移轉至次要位置時發生錯誤。如果應用程式是以一組分散式服務部署，則單一服務的復原作業可動態進行。

從資料庫的角度來看，在原始部署位置重新啟動服務不需要特定的資料庫部署作業。當服務移至其他部署位置，且該服務存取資料庫時，就會套用與前文「分散式服務」一節所述相同的準備就緒模式。

如果服務暫時遷移，且企業可接受遷移期間較高的延遲時間，服務就能跨部署位置存取資料庫。雖然服務已重新配置，但仍會以原始部署位置相同的方式存取資料庫。

依據情境而異的部署

一般來說，單一應用程式部署作業會提供所有應用程式用戶端，並包含所有應用程式服務和資料庫。不過，也有例外情況。單一應用程式部署作業只能服務特定條件下的部分用戶端，也就是說需要多個應用程式部署作業。每個部署作業都會為不同的用戶端子集提供服務，而所有部署作業會共同為所有用戶端提供服務。

以下是依據情境而異的部署作業的使用案例：

• 部署多租用戶應用程式時，系統會為所有小型租用戶部署一個應用程式，每 10 個中型租用戶部署另一個應用程式，以及為每個高級租用戶部署一個應用程式。
• 需要區隔客戶，例如企業客戶和政府機關客戶。
• 需要區隔開發、測試環境和實際工作環境。

從資料庫的角度來看，您可以在一對一部署策略中，為每個應用程式部署一個資料庫。如下圖所示，這項策略是一種簡單的方法，因為每個部署都有自己的資料集，因此會建立分區資料。

上圖顯示以下內容：

• 設定包含三個應用程式部署。
• 每個資料集都有各自的資料庫。
• 部署作業之間不會共用任何資料。

在許多情況下，一對一部署是最合適的策略，但也有其他替代方案。

在多用戶群的情況下，租戶可能會重新安置。小型租用戶可能會變成中型租用戶，並且必須遷移至其他應用程式。在這種情況下，個別資料庫部署作業需要進行資料庫遷移。如果部署分散式資料庫，且所有部署都同時使用該資料庫，則所有租用戶資料都會位於單一資料庫系統中。因此，在資料庫之間移動租用戶不需要進行資料庫遷移作業。下圖為這類資料庫的範例：

上圖顯示以下內容：

• 應用程式的三個部署作業。
• 這些部署都會共用單一分散式資料庫。
• 應用程式可存取每個部署作業中的所有資料。
• 未實作資料分割。

如果企業經常在生命週期作業中重新安置租用戶，資料庫複製功能可能會是實用的替代方案。在這種方法中，租用戶資料會在租用戶遷移前，在資料庫之間複製。在這種情況下，系統會使用獨立資料庫部署不同的應用程式，並在租用戶遷移前後立即設定複製作業。下圖顯示在租用戶遷移期間，兩個應用程式部署之間的臨時複製作業。

上圖顯示應用程式的三個部署作業，其中有三個獨立的資料庫，分別儲存與各個部署作業相關聯的資料。如要將資料從一個資料庫遷移到另一個資料庫，可以設定臨時資料庫遷移作業。

應用程式可攜性

應用程式可攜性可確保應用程式可部署至不同的部署位置，尤其是不同的雲端。這種可攜性可確保應用程式隨時都能遷移，而不需要進行遷移專屬的重新設計，或額外開發應用程式來準備應用程式遷移作業。

為確保應用程式的可移植性，您可以使用下列其中一種方法，這會在本節稍後介紹：

• 系統型可攜性
• API 相容性
• 功能導向可攜性

系統式移植性會使用所有可能部署作業中使用的相同技術元件。為確保系統可攜性，每項技術都必須可在所有可能的部署位置使用。舉例來說，如果 PostgreSQL 等資料庫是候選項目，就必須在預期時間內驗證其在所有潛在部署位置的可用性。所有其他技術 (例如程式設計語言和基礎架構技術) 也是如此。如下圖所示，這種方法會根據技術，在所有部署位置建立一組常見功能。

上圖顯示可攜式應用程式部署作業，其中應用程式會預期在每個部署位置使用相同的資料庫系統。由於每個位置都使用相同的資料庫系統，因此應用程式可移植。應用程式可預期在整個部署作業中使用完全相同的資料庫系統。因此，可以假設完全相同的資料庫系統介面和行為。

在資料庫的 API 相容性系統中，用戶端會使用特定資料庫存取程式庫 (例如 MySQL 用戶端程式庫)，確保能連線至雲端環境中可能提供的任何相容實作項目。下圖說明 API 相容性。

上圖顯示應用程式可攜性，以資料庫系統 API 而非資料庫系統為依據。雖然各個位置的資料庫系統可能不同，但 API 都是相同的，且會提供相同的功能。應用程式可移植，因為即使基礎資料庫系統是不同的資料庫技術，應用程式仍可在各個位置使用相同的 API。

在以功能為基礎的可攜性方面，不同雲端中的不同技術可能會用於提供相同的功能。舉例來說，您可以將資料庫的使用範圍限制在關聯模型內。由於任何關聯式資料庫系統都能支援應用程式，因此不同版本的不同資料庫系統可在不同雲端中使用，而不會影響應用程式的可攜性。功能式移植性有一個缺點，就是只能使用所有關聯資料庫系統支援的資料庫模型部分。您必須使用資料庫模型，而非與所有雲端相容的資料庫系統。下圖為功能性可攜性架構範例。

如上圖所示，資料庫系統 API 和資料庫系統可能會因位置而異。為確保可攜性，應用程式必須只使用各個資料庫系統和各個 API 在各個位置可用的部分。由於每個位置通常只提供部分資料庫系統，因此應用程式必須將使用範圍限制在該子集。

為確保本節中所有選項的移植性，完整架構必須持續部署至所有目標位置。所有單元和系統測試案例都必須針對這些部署作業執行。這些是基礎架構和技術變更必須具備的必要條件，以便及早偵測並解決問題。

避免供應商依附元件

供應商依附性 (鎖定) 防範機制有助於降低依附特定技術和供應商的風險。這與應用程式可攜性表面上相似。供應商依附元件防範機制適用於所有使用的技術，而非僅限於雲端服務。舉例來說，如果 MySQL 用於資料庫系統，並安裝在雲端虛擬機器上，從雲端的角度來看，就沒有任何依附元件，但會依附 MySQL。可在不同雲端間移植的應用程式，可能仍會依賴雲端以外的不同廠商提供的技術。

為避免供應商依附性，所有技術都必須可替換。因此，您需要對所有應用程式功能進行完整且有條理的抽象化，以便將每個應用程式服務重新實作至不同的技術基礎，而不影響應用程式的實作方式。從資料庫的角度來看，您可以將資料庫模型的使用方式與特定資料庫管理系統分開，藉此實現這項抽象。

現有的正式版資料庫管理系統

雖然許多多雲端應用程式都是以資料庫系統為設計基礎，但許多企業在進行應用程式現代化時，也會開發多雲端應用程式。這些應用程式在開發時，假設新設計並導入的應用程式會存取現有的資料庫。

不將現有資料庫納入現代化計畫的原因有很多。您可能會使用其他資料庫系統不具備的特定功能。企業可能會採用資料庫，並採用複雜且完善的管理程序，因此轉移至其他系統可能不切實際或不經濟。或者，企業可能會選擇在第一階段將應用程式改為現代化，然後在第二階段將資料庫改為現代化。

當企業使用現有的資料庫系統時，多雲應用程式的設計人員必須決定是否要使用該資料庫，或是需要為不同的部署位置新增其他資料庫系統。舉例來說，如果資料庫是在內部部署，且應用程式也需要在 Google Cloud中執行，則需要考量在 Google Cloud 上部署的應用程式服務是否會存取內部資料庫。或者，如果您想在Google Cloud 和本機執行的應用程式服務中部署第二個資料庫，也可以使用這項功能。

如果在 Google Cloud中部署第二個資料庫，應用情境可能與「雲端爆發」或「分散式服務」一文中討論的應用情境相同。無論是哪種情況，都適用於這些章節中的資料庫討論。不過，這項功能僅限於現有本機資料庫可支援的跨位置功能，例如同步處理和複製。

部署模式

本文件討論的用例從資料庫的角度提出了一個常見問題：如果資料庫位於多個部署位置，它們之間的關係為何？

主要關係類型 (部署模式) 如下所述：

• 不含跨資料庫依附元件的分區
• 非同步單向複製
• 雙向複製作業，並解決衝突
• 完全主動式同步分散式系統

您可以將本文件中的每個用途對應至一或多個四種部署模式。

在以下討論中，我們假設用戶端會直接存取應用程式服務。視用途而定，您可能需要使用負載平衡器，才能動態引導用戶端存取應用程式，如下圖所示。

在上圖中，雲端負載平衡器會將用戶端呼叫導向至其中一個可用的地點。負載平衡器會確保負載平衡政策已生效，並將用戶端導向應用程式及其資料庫的正確位置。

不含跨資料庫依附元件的分區

這個部署模式是本文件討論的所有模式中最簡單的一種：每個位置或雲端都有資料庫，而資料庫包含彼此不相依的區隔資料集。資料項目只會儲存在一個資料庫中。每個資料區塊都位於專屬的資料庫中。這類模式的例子是多租戶應用程式，其中資料集位於一個或多個資料庫中。下圖顯示兩個完全分割的應用程式。

如上圖所示，應用程式會部署在兩個位置，每個位置負責整個資料集的一個分區。每個資料項目只會位於其中一個位置，確保分割的資料集不會在兩者之間複製。

分割資料庫的另一種部署模式是，資料集完全分割，但仍儲存在同一資料庫中。只有一個資料庫包含所有資料集。雖然資料集儲存在相同的資料庫中，但資料集是完全獨立的 (已劃分)，因此對其中一個資料集所做的變更不會影響其他資料集。下圖顯示共用單一資料庫的兩個應用程式。

上圖顯示以下內容：

• 兩個應用程式部署都共用一個位於第一個位置的資料庫。
• 由於資料集未經過分割，因此每個應用程式都能存取部署中的所有資料。

非同步單向複製

這個部署模式包含一個主要資料庫，會複製到一或多個次要資料庫。次要資料庫可用於讀取存取，但應用程式必須考量潛在的複製延遲時間。這類模式的例子包括將最適合特定用途的資料庫用作主要資料庫，而次要資料庫則用於分析。下圖顯示兩個應用程式存取單向複製的資料庫。

如上圖所示，這兩個資料庫中，其中一個是另一個資料庫的複本。圖表中的箭頭表示複製方向：位置 1 的資料庫系統資料會複製到位置 2 的資料庫系統。

雙向複製作業，並解決衝突

這個部署模式有兩個主要資料庫，彼此以非同步方式複製。如果同一個資料同時寫入每個資料庫 (例如相同的主鍵)，可能會導致寫入-寫入衝突。由於存在這種風險，因此必須有衝突解決機制，以便判斷哪個狀態是複製期間的最後狀態。這個模式可用於寫入-寫入衝突發生機率極低的情況。下圖顯示兩個應用程式存取雙向複製的資料庫。

如上圖所示，每個資料庫都會複製到其他資料庫。兩個複本彼此獨立，如圖表中兩個分開的藍色箭頭所示。由於這兩項複製作業是獨立的，如果各個應用程式同時變更相同的資料項目並進行複製，就可能發生衝突。在這種情況下，必須進行衝突解決。

完全主動式同步分散式系統

這個部署模式包含單一資料庫，該資料庫採用雙主動 (也稱為主要-主要) 設定。在主動-主動設定中，任何主要資料庫中的資料更新作業都會保持交易一致性，並同步複製。此模式的使用案例範例是分散式運算。下圖顯示兩個應用程式存取完全同步的「主要-主要」資料庫。

如上圖所示，這種安排可確保每個應用程式一律存取最後一致的狀態，不會有延遲或發生衝突的風險。在一個資料庫中所做的變更會立即在另一個資料庫中顯示。變更交易時，任何變更都會反映在兩個資料庫中。

資料庫系統分類

並非所有資料庫管理系統都能適用於本文件討論的部署模式。視用途而定，您可能只能實作一種部署模式，或是將部署模式與資料庫系統的子集結合。

在下一個章節中，我們將分類不同資料庫系統，並對應至四種部署模式。

您可以依據不同的維度 (例如資料模型、內部架構、部署模型和交易類型) 將資料庫分類。在下一個章節中，我們會使用兩個維度來管理多雲資料庫：

• 部署架構。資料庫管理系統如何部署至雲端資源 (例如運算引擎或雲端管理) 的架構。
• 發布模式。資料庫系統支援的分發模式 (例如單一執行個體或完全分散式)。

這兩個維度在多雲用途的情況下最為相關，可支援多雲資料庫用途衍生的四種部署模式。常見的分類方式是根據資料庫管理系統支援的資料模型。有些系統只支援一種模型 (例如圖形模型)。其他系統則同時支援多個資料模型 (例如關聯和文件模型)。不過，在多雲端資料庫管理的情況下，這項分類就無關緊要，因為多雲端應用程式可為其多雲端部署作業使用任何資料模型。

依部署架構劃分資料庫系統

多雲資料庫管理包含下列四個主要類別的資料庫管理系統部署架構：

• 內建雲端資料庫。內建雲端資料庫的設計、建構和最佳化方式，都是為了與雲端技術搭配使用。舉例來說，某些資料庫系統會將 Kubernetes 做為實作平台，並使用 Kubernetes 功能。CockroachDB 和 YugaByte 就是這類資料庫的例子。這些叢集可部署至任何支援 Kubernetes 的雲端。
• 雲端供應商管理的資料庫。雲端供應商代管的資料庫是採用雲端供應商專屬技術建構，並由特定雲端供應商管理的資料庫服務。Spanner、Bigtable、Firestore 和 AlloyDB for PostgreSQL 都是這類資料庫的例子。雲端服務供應商管理的資料庫只能在雲端服務供應商的雲端中使用，無法在其他地方安裝及執行。不過，PostgreSQL 適用的 AlloyDB 與 PostgreSQL 完全相容。
• 雲端前資料庫。雲端前資料庫是在雲端技術開發前 (有時是經過很長一段時間) 就存在，通常會在裸機硬體和虛擬機器 (VM) 上執行。PostgreSQL、MySQL 和 SQL Server 就是這類資料庫的例子。這些系統可在任何支援所需 VM 或裸機硬體的雲端上執行。
• 雲端合作夥伴管理的資料庫。部分公有雲有資料庫合作夥伴，可在公有雲中安裝及管理客戶的資料庫。因此，客戶不必自行管理這些資料庫。MongoDB Atlas、MariaDB 和 ScyllaDB 都是這類資料庫的例子。

這些主要類別有幾種變化版本。舉例來說，如果資料庫供應商實作專為雲端建構的資料庫，可能也會在供應商提供的雲端中，為客戶提供專為雲端建構的技術安裝作業和代管服務。這個做法等同於供應商提供公有雲，但只支援自家資料庫做為單一服務。

雲端前資料庫也可能位於容器中，且可部署至 Kubernetes 叢集。不過，這些資料庫不會使用 Kubernetes 專屬功能，例如擴充、多服務或多 Pod 部署。

資料庫供應商可能會同時與多個公有雲服務供應商合作，在多個公有雲中提供由雲端合作夥伴管理的資料庫。

依分發模式劃分的資料庫系統

不同的資料庫管理系統會根據資料庫架構中的分發模式實作。資料庫的模型如下：

• 單一執行個體。單一資料庫執行個體會在一個 VM 或一個容器上執行，並充當集中式系統。這個系統會管理所有資料庫存取權。由於單一執行個體無法連線至任何其他執行個體，因此資料庫系統不支援複寫。
• 多執行個體主動-被動。在這個常見架構中，多個資料庫執行個體會連結在一起。最常見的連結是主動-被動關係，其中一個例項是主動資料庫例項，可支援兩個例項，並進行讀寫。一或多個被動系統為唯讀，並以同步或非同步方式接收來自主要系統的所有資料庫變更。被動系統可提供讀取權限。主被動式也稱為主-次要或來源-副本。
• 多執行個體主動-主動。在這種相對不常見的架構中，每個執行個體都是有效的執行個體。在這種情況下，每個執行個體都能執行讀取和寫入交易，並提供資料一致性。因此，為避免資料不一致，系統會一律同步處理所有執行個體。
• 多個執行個體的雙主動架構，並提供衝突解決機制。這也是相對較少見的系統。每個執行個體都提供讀取和寫入存取權，但資料庫會以非同步模式同步。允許同時更新相同的資料項目，這會導致狀態不一致。衝突解決政策必須決定哪個狀態是最後一致的狀態。
• 多實體分割。資料分割是根據資料的(不連續)分區進行管理。每個分區都由獨立的資料庫執行個體管理。這種分發方式可隨時間動態新增更多分片，因此具有可擴充性。不過，由於並非所有系統都支援這項功能，因此跨區塊查詢可能無法執行。

本節所述的所有發布模型都能支援分割，且可成為分割系統。不過，並非所有系統都提供分割選項。資料分割是一種可擴充性概念，通常與多雲環境中的架構資料庫選取無關。

雲端和合作夥伴管理的資料庫的發布模型不同。由於這些資料庫與雲端供應商的架構相關聯，因此這些系統會根據下列部署位置實作架構：

• 區域系統。區域管理的資料庫系統會與區域綁定。當區域可用時，資料庫系統也會可用。不過，如果區域無法使用，就無法存取資料庫。
• 區域系統。地區代管資料庫會與特定區域綁定，只要至少有一個可存取的區域，即可存取資料庫。任何區域組合都可能無法存取。
• 跨區域系統。跨區域系統會連結至兩個或更多區域，並在至少一個區域可用時正常運作。

如果資料庫可安裝在企業要使用的所有雲端中，跨區域系統也能支援跨雲端系統。

除了本節所述的受管理資料庫架構，還有其他可能的替代方案。地區系統可能會在兩個區域之間共用磁碟。如果這兩個區域中任一區域無法使用，資料庫系統可在剩餘的區域中繼續運作。不過，如果中斷情形影響到兩個可用區，即使其他可用區仍可完全上線，資料庫系統仍會無法使用。

將資料庫系統對應至部署模式

下表說明本文所述的部署模式和部署架構之間的關係。這些欄位會根據部署模式和部署架構，說明組合所需的條件。

部署架構	部署模式
	不含跨資料庫依附元件的分區	非同步單向複製	雙向複製作業，並解決衝突	完全主動式同步分散式系統
內建雲端資料庫	所有提供資料庫系統所用內建雲端技術的雲端皆可使用。 如果無法使用相同的資料庫，可以使用不同的資料庫系統。	提供複製功能的雲端資料庫。	提供雙向複寫功能的雲端資料庫。	提供主-主同步處理功能的雲端資料庫。
雲端供應商管理的資料庫	不同雲端的資料庫系統可能不同。	備援資源不必是雲端供應商管理的資料庫 (請參閱「資料庫遷移技術在部署模式中的角色」)。	如果資料庫提供雙向複製功能，則僅限於在雲端內，而非跨雲端。	如果資料庫提供主-主同步處理，則僅限於在雲端內，而非跨雲端。
雲端前資料庫	資料庫系統可以在不同的雲端服務中使用相同或不同的系統。	您可以跨多個雲端服務進行複製。	資料庫系統提供雙向複製和衝突解決功能。	資料庫系統提供主要-主要同步處理。
雲端合作夥伴管理的資料庫	不同雲端的資料庫系統可能不同。 如果合作夥伴在所有必要雲端中提供受管理的資料庫系統，則可使用相同的資料庫。	備份資料庫不一定要是雲端供應商管理的資料庫。 如果合作夥伴在所有必要雲端中提供受管理的資料庫系統，則可使用相同的資料庫。	資料庫系統提供雙向複製和衝突解決功能。	資料庫系統提供主要-主要同步處理。

如果資料庫系統未提供內建複製作業，您可以改用資料庫複製作業技術。詳情請參閱「資料庫遷移技術在部署模式中的作用」。

下表將部署模式與發布模式做連結。這些欄位會指出，在特定部署模式和發布模式下，哪些組合是可能的。

發布模型	部署模式
	不含跨資料庫依附元件的分區	非同步單向複製	雙向複製作業，並解決衝突	完全主動式同步分散式系統
單一例項	在涉及的雲端中，可以使用相同或不同的資料庫系統。	不適用	不適用	不適用
多實體主動/被動	在相關雲端中，可使用相同或不同的資料庫系統。	複製作業可跨雲端執行。	複製作業可跨雲端執行。	不適用
多執行個體主動/主動	在相關雲端中，可使用相同或不同的資料庫系統。	不適用	不適用	可跨雲端進行同步。
多執行個體雙主動與衝突解決機制	在相關雲端中，可使用相同或不同的資料庫系統。	不適用	不適用	如果可在不同雲端之間進行雙向複寫，則適用此選項。

有些分發模式實作會根據基礎資料庫技術新增額外抽象，但並未內建這類分發模式，例如 Postgres-BDR 這類主動/主動系統。這些系統已納入上表中的相應類別。從多雲端的角度來看，導入的發布模型如何實作並不重要。

資料庫遷移和複寫

視用途而定，企業可能需要將資料庫從一個部署位置遷移至另一個部署位置。或者，如果是下游處理作業，可能需要將資料庫的資料複製到其他位置。在下一個章節中，我們會進一步討論資料庫遷移和資料庫複寫。

資料庫遷移

資料庫遷移功能可用於將資料庫從一個部署位置移至另一個部署位置。舉例來說，在內部部署資料中心執行的資料庫會改為在雲端執行。遷移完成後，資料庫會在內部部署的資料中心關閉。

資料庫遷移的主要方法如下：

• 隨即轉移。執行資料庫執行個體的 VM 和磁碟會原封不動地複製到目標環境。複製完成後，系統會啟動這些資料庫，並完成遷移作業。
• 匯出、匯入、備份及還原。這兩種方法都會使用資料庫系統功能，將資料庫外部化，並在目標位置重新建立資料庫。匯出/匯入通常是採用 ASCII 格式，而備份和還原則是採用二進位格式。
• 零停機遷移。在這種方法中，應用程式系統會在存取來源系統時遷移資料庫。初始載入完成後，系統會使用變更資料擷取 (CDC) 技術，將變更從來源傳送至目標資料庫。應用程式會在遷移完成後，從在來源資料庫系統上停止運作到在目標資料庫系統上重新啟動之間，發生一段停機時間。

當資料庫從一個雲端服務移至另一個雲端服務，或是從一種資料庫引擎移至另一種資料庫引擎時，資料庫遷移就會成為多雲用途的相關作業。

資料庫遷移是一項多面向的程序，詳情請參閱「資料庫遷移：概念和原則 (第 1 部分) 」和「資料庫遷移：概念和原則 (第 2 部分)」。

內建資料庫技術可用於資料庫遷移作業，例如匯出和匯入、備份和還原，或內建複製通訊協定。如果來源和目標系統是不同的資料庫系統，遷移技術是資料庫遷移的最佳選擇。資料庫遷移服務、Striim 和 Debezium 是資料庫遷移技術的範例。

資料庫複製

資料庫複製與資料庫遷移類似。不過，在資料庫複製期間，來源資料庫系統會維持原狀，而每項變更都會傳送至目標資料庫。

資料庫複製作業是持續性的程序，會將變更從來源資料庫傳送至目標資料庫。如果這項程序為非同步，變更會在稍微延遲後傳送至目標資料庫。如果程序是同步的，則系統會同時對來源系統和目標系統進行相同的交易變更。

除了將來源複製到目標資料庫之外，常見做法是將資料從來源資料庫複製到目標分析系統。

與資料庫遷移作業一樣，如果有複製通訊協定，您可以使用內建資料庫技術進行資料庫複製。如果沒有內建的複製通訊協定，您可以使用 Datastream、Striim 或 Debezium 等複製技術。

資料庫遷移技術在部署模式中的角色

在部署模式中使用不同資料庫系統時，內建資料庫技術通常無法啟用複製功能，例如非同步 (異質) 複製。而是可以部署資料庫遷移技術來啟用這類複製功能。其中部分遷移系統也實作雙向複製功能。

如果資料庫遷移或複製技術適用於資料庫系統與部署模式的對應表 1 或表 2 中標示為「不適用」的組合所使用的資料庫系統，則可用於資料庫複製。下圖顯示使用遷移技術複製資料庫的方法。

在上圖中，位置 1 的資料庫會複製至位置 2 的資料庫。系統會部署遷移伺服器來實作複製作業，而非直接複製資料庫系統。這個方法適用於資料庫系統，因為這些系統的實作方式並未內建資料庫複製功能，且需要依賴與資料庫系統分開的系統來實作複製作業。

多雲端資料庫選項

多雲資料庫用途與資料庫系統分類結合後，可協助您決定哪些資料庫最適合特定用途。舉例來說，如要在應用程式可攜性中實作用途，有兩種做法。第一個選項是確保所有雲端都能使用相同的資料庫引擎。這種做法可確保系統可攜性。第二個選項是確保所有雲端都能使用相同的資料模型和查詢介面。雖然資料庫系統可能不同，但可移植性會在功能介面上提供。

以下各節的決策樹會顯示本文件中多雲資料庫用途的決策標準。決策樹會建議每個用途的最佳資料庫。

現有資料庫系統的最佳做法

如果資料庫系統已在實際工作環境中使用，您必須決定是否要保留或取代該系統。下圖顯示決策過程中應問的問題：

決策樹中的提問和答案如下：

• 資料庫系統是否已正式上線？
  • 如果沒有實際工作環境資料庫系統，請選取資料庫系統 (請略過「多雲端資料庫管理的決策」)。
  • 如果資料庫系統已在實際運作，請評估是否應保留該系統。
• 如果資料庫系統已在實際運作中，請評估是否應保留該系統。
  • 如果應保留資料庫系統，系統就會做出決定，並完成決策程序。
  • 如果需要變更資料庫系統，或仍在決定要使用哪個系統，請選取資料庫系統 (請略過「多雲資料庫管理的決策」)。

多雲資料庫管理的決策

以下決策樹適用於需要多地點資料庫 (包括多雲資料庫部署) 的用途。這項工具會以部署模式做為決策標準的依據。

決策樹中的提問和答案如下：

• 資料是否已在不同資料庫中進行分割，且沒有任何跨資料庫的依附性？
  • 如果是，則可為各個位置選取相同或不同的資料庫系統。
  • 如果沒有，請繼續回答下一個問題。
• 是否需要非同步單向複製？
  • 如果是，請評估是否可使用資料庫複製作業系統。
    • 如果是，請選取與複製系統相容的相同或不同資料庫系統。
    • 如果沒有，請選取可實作主動-被動式發布模式的資料庫系統。
    • 如果沒有，請繼續回答下一個問題。
• 選取具有同步執行個體的資料庫系統。
  • 是否可以接受衝突解決方案？
    • 如果是，請選取雙向複製資料庫系統或主動-主動資料庫系統。
    • 如果沒有，請選取主動/主動系統。

如果實作多個多雲用途，企業必須決定要使用一個資料庫系統來支援所有用途，還是要使用多個資料庫系統。

如果企業想使用單一資料庫系統來支援所有用途，最好選擇同步處理效果最佳的系統。舉例來說，如果您需要單向複寫和同步處理的執行個體，同步處理的執行個體就是最佳選擇。

同步品質的階層 (從無到最佳) 如下：分割、單向複製、雙向複製和完全同步複製。

部署最佳做法

本節將說明選擇資料庫以便遷移或開發多雲應用程式時，應遵循的最佳做法。

現有資料庫管理系統

建議您保留資料庫，並且除非特定用途需要，否則不要變更資料庫系統。如果企業已建立完善的資料庫管理系統，並且具備有效的開發、作業和維護程序，建議不要變更設定。

雲端爆量使用情形如果不需要在雲端中使用資料庫系統，可能就不需要變更資料庫。另一個用途是將資料異動以非同步方式複製到相同雲端中的不同部署位置，或複製到其他雲端。針對這些用途，建議您實作基準測試，並驗證跨地點通訊和延遲時間是否符合存取資料庫時的應用程式需求。

資料庫系統做為 Kubernetes 服務

如果企業考慮在 Kubernetes 中執行資料庫系統，並以 StatefulSets 做為服務，則必須考量下列因素：

• 資料庫是否提供應用程式所需的資料庫模型。
• 非功能性因素：決定如何在資料庫系統中以 Kubernetes 服務的形式實作營運化，例如如何進行擴充 (向上和向下)、如何管理備份和還原作業，以及系統如何提供監控功能。為了協助企業瞭解以 Kubernetes 為基礎的資料庫系統需求，企業應以自身的資料庫使用經驗做為比較基準。
• 高可用性和災難復原。為提供高可用性，系統需要在區域內的區域發生故障時繼續運作。資料庫必須能夠快速從一個區域移轉至另一個區域。在最佳情況下，資料庫會在每個區域中執行一個執行個體，且該執行個體已完全同步，因此 RTO 和 RPO 為零。
• 災難復原功能，可因應區域 (或雲端) 故障。在理想情況下，資料庫會繼續在第二個區域運作，RPO 和 RTO 為零。在較不理想的情況下，次要區域中的資料庫可能無法完全追上主要資料庫的所有交易。

如要決定在 Kubernetes 中執行資料庫的最佳方式，建議您進行完整的資料庫評估，尤其是當系統需要與 Kubernetes 外部實際工作環境中的系統相提並論時。

不依賴 Kubernetes 的資料庫系統

在 Kubernetes 中以服務形式實作的應用程式，不一定需要同時在 Kubernetes 中執行資料庫。資料庫系統需要在 Kubernetes 外執行的原因有很多，例如已建立的程序、企業內的產品知識，或是無法使用 Kubernetes。雲端供應商和雲端合作夥伴管理的資料庫都屬於這個類別。

在 Compute Engine 上執行資料庫也是可行的方法。選擇資料庫系統時，建議您進行完整的資料庫評估，確保符合應用程式的所有需求。

從應用程式設計的角度來看，連線集區是重要的設計考量。存取資料庫的應用程式服務可能會在內部使用連線集區。使用連線集區可提高效率並縮短延遲時間。系統會從集區中取用要求，而不需要啟動要求，也不需要等待建立連線。如果應用程式是透過新增應用程式服務執行個體來擴充，每個執行個體都會建立連線集區。如果遵循最佳做法，每個集區都會預先建立一組最少的連線。每次為應用程式擴充而建立其他應用程式服務執行個體時，系統都會將連線新增至資料庫。從設計角度來看，由於資料庫無法支援無限的連線，因此必須管理新增的連線，以免發生超載。

最佳資料庫系統與資料庫系統可攜性

企業在選擇資料庫系統時，通常會選取最適合應用程式需求的資料庫系統。在多雲環境中，您可以選取每個雲端的最佳資料庫，並根據用途相互連結。如果這些系統不同，則任何複製作業 (單向或雙向) 都需要大量的努力。如果使用最佳系統的好處大於實作所需的努力，這種做法或許是合理的。

不過，建議您同時考量並評估資料庫系統的做法，以便在所有必要的雲端中使用。雖然這類資料庫可能不是最佳選擇，但實作、操作和維護這類系統可能會比較容易。

並行資料庫系統評估可顯示兩個資料庫系統的優缺點，為選項提供穩固的基礎。

內建與外部資料庫系統複製

如果用途需要在所有部署位置 (區域、區域或雲端) 中使用資料庫系統，複製功能就非常重要。複製作業可以是非同步、雙向或完全同步的主動-主動複製作業。不過，並非所有資料庫系統都支援這些複製形式。

如果系統不支援系統實作複製作業的複製功能，則可使用 Striim 等系統來補足架構 (如「資料庫遷移」一文所述)。

最佳做法是評估其他資料庫管理系統，以判斷內建複製功能的系統或需要複製技術的系統的優缺點。

第三類技術在這裡也扮演了重要角色。這個類別會為現有資料庫系統提供外掛程式，以便提供複製功能。例如 MariaDB Galera Cluster。如果評估程序允許，建議您評估這些系統。

多模態資料庫

多模型資料庫可在雲端和即時應用程式中提供彈性、可擴充的資料管理功能。多模型資料庫在統一查詢介面和儲存引擎下，支援多種資料模型，例如文件、圖表、鍵/值、欄族和關聯式。這些功能具備下列優點：

• 簡化管理：開發人員可在單一資料庫系統中管理各種資料類型，有助於降低營運複雜度和額外負擔。
• 開發速度加快：多模型資料庫可彈性運用最佳資料模型，滿足各種需求。這種彈性可加快開發速度，並協助您更快因應變化的需求。
• 更容易整合：統一的查詢介面和儲存引擎可盡量簡化連結及同步處理不同資料庫的複雜度。
• 強化查詢功能：開發人員可以查詢及結合不同模型的資料，進而提供更豐富的洞察資料和更精密的應用程式功能。
• 節省成本：資料庫系統數量減少，可降低授權、硬體和營運費用。
• 最佳效能：選擇最適合特定工作的資料模型，有助於提升應用程式效能。

舉例來說，Spanner 提供多種模型功能，並支援 PostgreSQL 方言。這項功能可讓您使用關聯式和 NoSQL 資料建構智慧型 AI 應用程式，使用 Spanner 圖查詢複雜的關係，並使用向量搜尋進行語意搜尋。

後續步驟

• 瞭解混合式雲端和多雲端架構模式。
• 請參閱連接其他雲端服務供應商與 Google Cloud 的模式。
• 瞭解 Google Cloud上的混合式雲端和多雲端部署項目的監控和記錄架構。
• 如需更多參考架構、圖表和最佳做法，請瀏覽 雲端架構中心。

貢獻者

作者：Alex Cârciu | 解決方案架構師