本文說明多雲端資料庫管理的部署架構、用途和最佳做法。適用於在多個雲端環境中設計及導入有狀態應用程式的架構師和工程師。
存取資料庫的多雲端應用程式架構取決於應用情境。沒有單一有狀態應用程式架構可以支援所有多雲用途。舉例來說，雲端爆量用途的最佳資料庫解決方案，與在多個雲端環境中並行執行的應用程式最佳資料庫解決方案不同。
以 Google Cloud等公有雲為例，有各種資料庫技術適用於特定的多雲用途。如要在單一公有雲內的多個區域部署應用程式，其中一個方法是使用公有雲供應商代管的多區域資料庫，例如 Spanner。如要部署可跨公有雲移植的應用程式，平台獨立的資料庫或許是更好的選擇，例如 AlloyDB Omni 或 PostgreSQL。
本文將先介紹有狀態資料庫應用程式的定義，然後分析多雲資料庫的用途。然後根據用途，詳細介紹多雲部署架構的資料庫系統分類。
本文也介紹了資料庫選取決策樹狀圖，其中列出選取合適資料庫技術的關鍵決策點。最後，我們將討論多雲資料庫管理的最佳做法。
重要字詞和定義
本節提供術語，並定義本文件中使用的通用有狀態資料庫應用程式。
術語
- 公有雲。公有雲提供多租戶基礎架構 (通常是全球性) 和服務，供客戶執行生產環境工作負載。 Google Cloud 是公有雲，提供許多代管服務，包括 GKE、GKE Enterprise 和代管資料庫。
- 混合雲。混合雲是公有雲與一或多個地端部署資料中心的組合。混合雲客戶可將地端服務與公有雲提供的其他服務結合。
- 多雲端。多雲是多個公有雲和地端部署資料中心的組合。混合雲是多雲的子集。
- 部署位置。基礎架構位置是可部署及執行工作負載 (包括應用程式和資料庫) 的實體位置。舉例來說，在 Google Cloud中，部署位置是區域和地區。從抽象層面來看，公有雲區域或可用區和地端部署資料中心都是部署位置。
有狀態資料庫應用程式
如要定義多雲用例，本文會使用一般有狀態資料庫應用程式架構，如下圖所示。
下圖顯示下列元件：
- 資料庫。資料庫可以是單一執行個體、多個執行個體或分散式資料庫，部署在運算節點上，或以雲端代管服務的形式提供。
- 應用程式服務。這些服務會合併為實作業務邏輯的應用程式。應用程式服務可以是下列任一項：
- Kubernetes 上的微服務。
- 在一或多個虛擬機器上執行的粗略程序。
- 單一大型虛擬機器上的單體式應用程式。
- Cloud Run functions 或 Cloud Run 中的無伺服器程式碼。部分應用程式服務可以存取資料庫。您可以多次部署每個應用程式服務。應用程式服務的每次部署作業，都是該應用程式服務的執行個體。
- 應用程式用戶端。應用程式用戶端會存取應用程式服務提供的功能。應用程式用戶端可以是下列其中一種：
- 已部署的用戶端，程式碼會在電腦、筆電或手機上執行。
- 未部署的用戶端，用戶端程式碼會在瀏覽器中執行。 應用程式用戶端執行個體一律會存取一或多個應用程式服務執行個體。
在多雲端資料庫的討論中，有狀態應用程式的架構抽象化包含資料庫、應用程式服務和應用程式用戶端。在應用程式的實作中，作業系統的使用或所用的程式設計語言等因素可能會有所不同。不過，這些詳細資料不會影響多雲資料庫管理。
佇列和檔案做為資料儲存服務
應用程式服務可使用許多持續性資源來保存資料。這些資源包括資料庫、佇列和檔案。每個持續性資源都會提供專為這些模型設計的儲存資料模型和存取模式。雖然應用程式會使用佇列、訊息系統和檔案系統，但以下章節將著重於資料庫。
雖然適用於多雲端資料庫的佇列和檔案，與部署位置、狀態共用、同步和非同步複寫等因素的考量相同，但這項討論超出本文範圍。
網路
在一般有狀態應用程式的架構中 (如下圖所示)，元件之間的每個箭頭都代表透過網路連線的通訊關係，例如存取應用程式服務的應用程式用戶端。
連線可位於單一可用區內，也可跨可用區、區域或雲端。連線可存在於任何部署位置組合之間。在多雲環境中，跨雲端網路是重要的考量因素，您可以採用多種做法。如要進一步瞭解跨雲端網路，請參閱「適用於分散式應用程式的 Cross-Cloud Network」和「連線至 Google Cloud：網路選項說明」。
本文的應用實例假設以下情況：
- 雲端之間有安全的網路連線。
- 資料庫及其元件可以相互通訊。
從非功能性角度來看，網路大小 (即總處理量和延遲時間) 可能會影響資料庫延遲時間和總處理量。從功能角度來看，網路通常不會受到影響。
多雲端資料庫應用實例
本節將介紹多雲端資料庫管理最常見的用途。在這些用途中，我們假設雲端和資料庫節點之間有安全的網路連線。
遷移應用程式
就多雲資料庫管理而言，應用程式遷移是指將應用程式、所有應用程式服務和資料庫從目前的雲端遷移至目標雲端。企業決定遷移應用程式的原因有很多，例如避免與雲端服務供應商競爭、更新技術，或是降低總持有成本 (TCO)。
在應用程式遷移作業中，目的是停止目前雲端中的生產作業，並在遷移完成後，繼續在目標雲端中生產。應用程式服務必須在目標雲端中執行。如要實作服務，可以採用「升級與轉移」方法。採用這種做法時，系統會在目標雲端部署相同程式碼。如要重新實作服務，可以使用目標雲端提供的現代化雲端技術。
就資料庫而言，應用程式遷移作業可考慮下列替代方案：
- 資料庫 lift-and-shift：如果目標雲端提供相同的資料庫引擎，即可 lift-and-shift 資料庫，在目標雲端中建立相同的部署作業。
- 資料庫升級並遷移至代管的同等項目：如果目標雲端提供代管版本，即可將自行管理的資料庫遷移至相同資料庫引擎的代管版本。
- 資料庫現代化：不同雲端提供不同的資料庫技術。由雲端供應商管理的資料庫可能具有優勢，例如更嚴格的服務水準協議 (SLA)、可擴充性，以及自動災難復原。
無論採用哪種部署策略，資料庫遷移都需要時間，因為必須將資料從目前的雲端移至目標雲端。雖然可以採用會導致停機的匯出和匯入方法，但最好還是選擇停機時間極短或零停機的遷移作業。這種做法可盡量減少應用程式停機時間，對企業及其客戶的影響也最小。不過，這通常需要更複雜的遷移設定，因為涉及初始載入、持續複製、監控、細微驗證，以及切換時的同步處理。如要支援回溯情境，您必須實作反向複製機制，在切換至目標資料庫後，將變更同步回來源資料庫。
災難復原
災難復原是指應用程式在區域服務中斷期間，仍能繼續為應用程式用戶端提供服務。為確保災難復原，應用程式必須部署至至少兩個區域，並隨時準備好執行。在正式環境中，應用程式會在主要區域執行。不過，如果發生服務中斷，次要區域就會成為主要區域。以下是災難復原的各種準備狀態模型：
- 熱待命：應用程式部署至兩個或多個區域 (主要和次要)，且應用程式在每個區域都能正常運作。如果主要區域發生故障，次要區域中的應用程式可以立即接管應用程式用戶端流量。
- 冷待命。應用程式在主要區域中執行，但已準備好在次要區域啟動 (但未執行)。如果主要區域發生故障，應用程式會在次要區域啟動。應用程式無法執行，且無法向應用程式用戶端提供所有應用程式服務時，就會發生應用程式中斷情形。
- 不得待機。在這個模型中，應用程式程式碼已準備好部署，但尚未部署在次要區域 (因此未使用的任何已部署資源)。如果主要區域發生中斷，應用程式的首次部署作業必須在次要區域進行。這項部署作業會將應用程式置於與冷備援相同的狀態，也就是必須啟動。與冷備援案例相比，這種做法的應用程式中斷時間較長，因為必須先部署應用程式 (包括建立雲端資源)。
從資料庫的角度來看，前述清單中討論的準備程度模型對應於下列資料庫方法：
- 交易同步資料庫。這個資料庫對應於熱待命模型。主要區域中的每筆交易都會在次要區域中以同步協調方式提交。如果服務中斷，次要區域會成為主要區域，資料庫也會保持一致，並立即提供服務。在此模型中，復原點目標 (RPO) 和復原時間目標 (RTO) 皆為零。
- 非同步複製的資料庫。這個資料庫也對應熱待命模型。由於從主要區域到次要區域的資料庫複製作業是非同步，因此如果主要區域發生故障，部分交易可能會複製到次要區域。雖然次要區域的資料庫已準備好處理生產負載，但可能沒有最新資料。因此，應用程式可能會遺失無法復原的交易。 由於存在這項風險，這種做法的 RTO 為零，但 RPO 大於零。
- 閒置資料庫。這個資料庫對應於冷備援模型。資料庫建立完成，但沒有任何資料。主要區域發生故障時，資料必須載入至閒置資料庫。如要啟用這項動作，必須先在主要區域進行一般備份，然後轉移至次要區域。備份可以是完整備份或增量備份，視資料庫引擎支援的備份類型而定。無論是哪種情況，資料庫都會還原為最後一次備份的狀態，而且從應用程式的角度來看，與主要區域相比，可能會遺失許多交易。雖然這種做法可能具有成本效益，但由於資料庫狀態並非最新狀態，因此自上次可用備份以來的所有交易都可能遺失，這會降低價值。
- 沒有資料庫。這個模型等同於「無待機」情況。次要區域未安裝資料庫，如果主要區域發生故障，就必須建立資料庫。建立資料庫後，必須先載入資料，應用程式才能使用，這與閒置資料庫的情況相同。
如果使用主要和次要雲端，而非主要和次要區域，本文討論的災難復原方法也適用。主要差異在於，由於雲端之間的網路異質性，雲端之間的延遲時間可能會增加，相較之下，雲端內區域之間的網路距離則不會有太大變化。其他差異可能來自不同雲端服務供應商受管理資料庫的不同功能和預設設定。
整個雲端發生故障的可能性，低於區域發生故障的可能性。 不過，企業可能仍會需要將應用程式部署到兩個雲端。這種做法有助於保護企業免於失敗，或協助企業遵守業務或產業法規。
另一個災難復原方法是設定主要和次要區域，以及主要和次要雲端。企業可藉此選擇最合適的災難復原程序，以解決故障狀況。如要讓應用程式繼續運作，可以視中斷嚴重程度，使用次要區域或次要雲端。
雲端爆發
雲端爆量是指一種設定，可讓應用程式用戶端流量在不同部署位置之間擴增。當容量需求增加，且備用位置提供額外容量時，應用程式就會爆量。主要位置可支援一般流量，而備援位置則可在應用程式用戶端流量超出主要位置支援範圍時，提供額外容量。主要和待命位置都已部署應用程式服務執行個體。
雲端爆量功能會跨雲端實作，其中一個雲端是主要雲端，第二個雲端則是備用雲端。在混合雲環境中，可使用這項服務，透過公有雲中的彈性雲端運算資源，擴充地端資料中心有限的運算資源。
如需資料庫支援服務，請使用下列選項：
- 主要位置部署。在這個部署作業中，資料庫只會部署在主要位置，不會部署在待命位置。應用程式爆量時，待命位置的應用程式會存取主要位置的資料庫。
- 主要和待命位置部署。這項部署作業同時支援主要和待命位置。資料庫執行個體會部署在兩個位置，並由該位置的應用程式服務執行個體存取，特別是在爆量的情況下。如「雲端內和跨雲端災難復原」一文所述，這兩個資料庫可以交易式同步，也可以非同步同步。非同步同步作業可能會延遲。 如果更新是在待命位置進行，則這些更新必須傳播回主要位置。如果兩個位置都可能同時更新，就必須實作衝突解決機制。
雲端爆發是混合雲的常見用途，可增加地端部署資料中心的容量。如果資料必須保留在特定國家/地區，也可以在公有雲中採用這種做法。如果某個國家/地區只有一個公有雲區域，則可爆量到同一個國家/地區的其他公有雲區域。這種做法可確保資料留在國內，同時解決公有雲區域的資源限制。
使用同級最佳的雲端服務
部分應用程式需要專屬雲端服務和產品，但這些服務和產品無法在單一雲端中使用。舉例來說，應用程式可能會在一個雲端中執行業務資料的業務邏輯處理作業，並在另一個雲端中分析業務資料。在這個應用實例中，應用程式的商業邏輯處理部分和分析部分會部署到不同的雲端。
從資料管理角度來看，用途如下：
- 分區資料。應用程式的每個部分都有自己的資料庫 (獨立分區)，且資料庫之間不會直接連線。管理資料的應用程式會將需要在兩個資料庫 (分區) 中提供的資料寫入兩次。
- 非同步複製的資料庫。如果需要讓一個雲端的資料在另一個雲端中可用，非同步複寫關係可能就適合。舉例來說，如果數據分析應用程式需要與商務應用程式相同的資料集或資料集子集，則後者可以在雲端之間複製。
- 交易同步資料庫。這類資料庫可讓您將資料提供給應用程式的這兩個部分。每個應用程式的每次更新都會保持交易一致性，並立即提供給兩個資料庫 (分割區)。交易同步資料庫可有效做為單一分散式資料庫。
分散式服務
分散式服務會部署及執行於兩個以上的部署位置。您可以將所有服務執行個體部署到所有部署位置。或者，您也可以根據硬體可用性或預期負載有限等因素，在所有位置部署部分服務，並僅在其中一個位置部署部分服務。
交易同步資料庫中的資料在所有位置都一致。因此，這類資料庫是將服務執行個體部署至所有部署位置的最佳選擇。
使用非同步複製資料庫時，可能會在兩個部署位置同時修改相同的資料項目。如要判斷兩個衝突變更中哪一個是最終一致狀態，必須實作衝突解決策略。雖然可以實作衝突解決策略，但並非總是簡單明瞭，有時還需要手動介入，才能將資料還原至一致狀態。
分散式服務重新定位和容錯移轉
如果整個雲端區域發生故障，系統會啟動災難復原程序。如果有狀態資料庫應用程式中的單一服務發生故障 (不是區域或整個應用程式)，就必須復原並重新啟動該服務。
災難復原的初步做法是在原始部署位置重新啟動失敗的服務 (就地重新啟動)。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 和執行資料庫執行個體的磁碟，原封不動地複製到目標環境。複製完成後，系統會啟動這些 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 外部執行的原因有很多，例如既有程序、企業內部的產品知識，或是無法使用。雲端供應商和雲端合作夥伴管理的資料庫都屬於這類。
在 Compute Engine 上執行資料庫同樣可行且可行。選取資料庫系統時，建議您進行完整的資料庫評估，確保符合應用程式的所有需求。
就應用程式設計而言，連線集區是重要的設計考量。存取資料庫的應用程式服務可能會在內部使用連線集區。使用連線集區有助於提升效率及縮短延遲時間。系統會直接從集區中提取要求，不必啟動要求，也不必等待建立連線。如果應用程式透過新增應用程式服務執行個體來擴充，每個執行個體都會建立連線集區。如果遵循最佳做法，每個集區都會預先建立最少一組連線。每次為應用程式擴充建立其他應用程式服務執行個體時，都會將連線新增至資料庫。從設計角度來看，由於資料庫無法支援無限連線，因此必須管理連線的加入作業，避免過載。
最佳資料庫系統與資料庫系統可攜性
選擇資料庫系統時，企業通常會選取最適合應用程式需求的資料庫系統。在多雲環境中，您可以選取各個雲端中最合適的資料庫，並根據用途將這些資料庫彼此連結。如果這些系統不同，任何單向或雙向的複製作業都需要投入大量心力。如果使用最佳系統的好處大於實作所需的工作量，這種做法或許就值得採用。
不過，建議您同時考慮並評估資料庫系統的方法，確保所有必要雲端都提供該系統。雖然這類資料庫可能不如最佳選項理想，但實作、運作及維護這類系統可能容易許多。
並行資料庫系統評估可顯示兩種資料庫系統的優缺點，為選取作業提供穩固的基礎。
內建與外部資料庫系統複製
如果使用案例需要在所有部署位置 (區域、地區或雲端) 都有資料庫系統，複製功能就非常重要。複製作業可以是異步、雙向，或完全同步的主動/主動複製作業。並非所有資料庫系統都支援所有這些形式的複寫。
如果系統實作的系統不支援複製功能，則可使用 Striim 等系統來輔助架構 (如「資料庫遷移」一文所述)。
最佳做法是評估替代資料庫管理系統，判斷內建複製功能的系統或需要複製技術的系統，各自的優點和缺點。
此外，還有第三類技術也在此案例中發揮作用。這個類別會為現有資料庫系統提供外掛程式，以提供複製功能。例如 MariaDB Galera Cluster。如果評估程序允許，建議您評估這些系統。
多模型資料庫
多模型資料庫可在雲端和即時應用程式中，提供彈性且可擴充的資料管理功能。多模型資料庫支援多種資料模型，例如文件、圖形、鍵/值、資料欄系列和關聯式，並提供統一的查詢介面和儲存引擎。這些功能具備下列優點：
- 簡化管理作業：開發人員可在單一資料庫系統中管理各種資料類型，有助於降低作業複雜度和管理負擔。
- 加快開發速度：多模型資料庫可彈性運用最適合不同需求的資料模型。這項彈性可加快開發速度，並協助您更快因應不斷變化的需求。
- 整合更輕鬆：統一的查詢介面和儲存引擎可減少連線及同步處理不同資料庫的複雜度。
- 強化查詢功能：開發人員可以查詢及合併不同模型中的資料，進而取得更豐富的洞察資料，並開發更精密的應用程式功能。
- 節省成本：資料庫系統減少，授權、硬體和營運費用也隨之降低。
- 提升效能：為特定工作選擇最合適的資料模型，有助於提升應用程式效能。
舉例來說，Spanner 提供多模型功能，並支援 PostgreSQL 方言。這項功能可讓您使用關聯式和 NoSQL 資料建構智慧型 AI 輔助應用程式，透過 Spanner Graph 查詢複雜關係，並使用向量搜尋進行語意搜尋。
後續步驟
- 瞭解混合式雲端和多雲端架構模式。
- 請參閱連接其他雲端服務供應商與 Google Cloud 的模式。
- 瞭解混合式雲端與多雲端部署項目的監控和記錄架構 Google Cloud。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：Alex Cârciu | 解決方案架構師