本文档介绍多云数据库管理的部署架构、用例和最佳做法。它面向在云中和跨云端设计和实现有状态应用的架构师和工程师。
访问数据库的多云应用架构依赖于用例。单个有状态应用架构无法支持所有多云用例。例如，针对云爆发用例的最佳数据库解决方案与在多个云环境中并发运行的应用的最佳数据库解决方案不同。
对于 Google Cloud 等公有云，有众多数据库技术适用于特定的多云用例。如需在单个公有云内的多个区域部署应用，一种选择是使用公有云、提供商管理的多区域数据库，例如 Spanner。如需部署应用以便可跨公有云移植，最好使用与平台无关的数据库，例如 PostgreSQL。
本文档介绍了有状态数据库应用的定义，接着是多云数据库用例分析。然后，根据用例介绍了多云部署架构的详细数据库系统分类。
本文档还介绍了用于选择数据库的决策树，其中概述了关于选择适当数据库技术的关键决策点。最后，讨论了多云数据库管理的最佳做法。
关键术语和定义
本部分提供术语并定义本文档中使用的通用有状态数据库应用。
术语
- 公有云。公有云提供多租户基础架构（通常是全球性的），以及客户可用于运行其生产工作负载的服务。Google Cloud 是一种公有云，可提供许多代管式服务，包括 GKE、GKE 企业版和代管式数据库。
- 混合云。混合云是公有云与一个或多个本地数据中心的组合。混合云客户可以将本地服务与公有云提供的其他服务相结合。
- 多云。多云是多个公有云和本地数据中心的组合。混合云是多云的子集。
- 部署位置。基础架构位置是可以部署和运行工作负载（包括应用和数据库）的物理位置。例如，在 Google Cloud 中，部署位置为区域和地区。在抽象级层，公有云地区/区域和本地数据中心是部署位置。
有状态数据库应用
为了定义多云用例，本文档使用通用有状态数据库应用架构，如下图所示。
下图显示了以下组件：
- 数据库。数据库可以是单个实例、多实例或分布式数据库，部署在计算节点上或以云代管式服务的形式提供。
- 应用服务。这些服务合并为实现业务逻辑的应用。应用服务可以是以下任何一项：
- Kubernetes 上的微服务。
- 在一个或多个虚拟机上运行的粗粒度进程。
- 单个大型虚拟机上的单体式应用。
- Cloud Functions 或 Cloud Run 中的无服务器代码。某些应用服务可以访问数据库。您可以多次部署每个应用服务。应用服务的每个部署都是该应用服务的实例。
- 应用客户端。应用客户端可以使用应用服务提供的功能。应用客户端可以是以下任一项：
- 部署的客户端，其中代码在机器、笔记本电脑或手机上运行。
- 非部署客户端，这些客户端代码在浏览器中运行。应用客户端实例始终访问一个或多个应用服务实例。
在多云数据库讨论中，有状态应用的架构抽象包括数据库、应用服务和应用客户端。在应用的实现中，操作系统的使用或所使用的编程语言等因素可能会有所不同。但是，这些细节不会影响多云数据库管理。
将队列和文件用作数据存储服务
有许多持久性资源可供应用服务用于保留数据。这些资源包括数据库、队列和文件。每个持久性资源都提供专用于这些模型的存储数据模型和访问模式。虽然队列、消息传递系统和文件系统由应用使用，但在下一部分中，重点侧重于数据库。
虽然部署位置、状态共享、多云数据库的同步和异步复制等因素同样适用于队列和文件，但这不在本文档的讨论范围内。
网络
在通用有状态应用的架构中（如下图所示），组件之间的每个箭头都表示通过网络连接进行的通信关系，例如访问应用服务的应用客户端。
连接可以位于区域内，也可以跨区域、地区或云。连接可以位于部署位置的任意组合之间。在多云环境中，跨云网络连接是重要的考虑因素，您可以使用多种选项。如需详细了解跨云网络连接，请参阅连接到 Google Cloud：您的网络选项说明。
在本文档的用例中，假设条件如下：
- 云之间存在安全的网络连接。
- 数据库及其组件可以相互通信。
从非功能性角度来看，网络大小（即吞吐量和延迟时间）可能会影响数据库延迟时间和吞吐量。从功能角度来看，网络通常没有影响。
多云数据库用例
本部分介绍了多云数据库管理的一些最常见的用例。对于这些用例，假设云端和数据库节点之间存在安全网络连接。
应用迁移
在多云数据库管理的场景中，应用迁移是指应用、所有应用服务和数据库从当前云迁移到目标云。企业可能会出于多种原因决定迁移应用，例如为了避免与云服务商进行竞争、实现技术现代化或降低总拥有成本 (TCO)。
在应用迁移中，目的是停止当前云中的生产并在迁移完成后在目标云中继续生产。应用服务必须在目标云中运行。要实现这些服务，可以使用直接原样迁移方法。此方法在目标云中部署相同的代码。要重新实现该服务，可以使用目标云中可用的现代云技术。
从数据库的角度来看，请考虑应用迁移的以下替代方案：
- 数据库直接原样迁移：如果目标云中提供了相同的数据库引擎，则可直接原样迁移数据库以在目标云中创建相同的部署。
- 数据库直接原样迁移到代管式等效项：如果目标云提供，则自行管理的数据库可以迁移到同一数据库引擎的代管式版本。
- 数据库现代化改造：不同的云环境提供不同的数据库技术。云服务商管理的数据库可能具有诸多优势，例如更严格的服务等级协议 (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 的数据库系统。
支持冲突解决的双向复制
此部署模式有两个主数据库，这些主数据库异步复制。如果将同一数据同时写入每个数据库（例如同一主键），则可能会导致写入-写入冲突。由于存在这种风险，因此必须有冲突解决来确定复制期间哪个状态是最后的状态。如果出现写入-写入冲突（这种情况很少），可以使用此模式。下图展示了两个应用访问双向复制的数据库。
如上图所示，每个数据库都会复制到另一个数据库。这两个复制彼此独立，如上图所示，有两个单独的蓝色箭头。由于两个复制是独立的，因此如果每个应用更改同一个数据项，并且并发复制，则可能会出现冲突。在这种情况下，您必须解决冲突。
完全主动-主动同步分布式系统
此部署模式具有一个数据库，它具有主动-主动（也称为“主要-主要”）设置。在主动-主动设置中，任何主数据库中的数据更新在事务上都是一致的，并且同步复制。此模式的一个示例用例是分布式计算。下图显示了两个应用访问完全同步的主要-主要数据库。
如上图所示，这种安排可确保每个应用始终访问最后的一致状态，而不会出现延迟或冲突风险。一个数据库中的更改会立即在另一个数据库中生效。更改事务提交时，任何更改都会反映在两个数据库中。
数据库系统分类
对于本文档中讨论的部署模式，并非所有数据库管理系统都同样适合。根据用例，可能只能实现一种部署模式或者将部署模式仅与部分数据库系统组合。
在以下部分中，不同的数据库系统分类并映射到 4 种部署模式。
您可以按不同维度（例如数据模型、内部架构、部署模型和事务类型）对数据库进行分类。在以下部分，使用两个维度来进行多云数据库管理：
- 部署架构。显示如何将数据库管理系统部署到云端资源（例如计算引擎或云端管理）的架构。
- 分销模式。数据库系统支持的分布模型（例如单个实例或完全分布式）。
这两个维度在多云用例场景中最为相关，它们支持源自多云数据库用例的四种部署模式。常见的分类基于数据库管理系统支持的数据模型。某些系统仅支持一个模型（例如图表模型）。其他系统同时支持多个数据模型（例如关系型和文档模型）。但是，在多云数据库管理环境中，这种分类无关紧要，因为多云应用可以使用任何数据模型进行多云部署。
按部署架构划分的数据库系统
多云数据库管理包括下面四种主要类别的数据库管理系统部署架构：
- 内置云数据库。内置云数据库经过精心设计、构建和优化，可搭配云技术使用。例如，某些数据库系统使用 Kubernetes 作为其实现平台，并使用 Kubernetes 功能。CockroachDB 和 YugaByte 是此类数据库的示例。它们可以部署到任何支持 Kubernetes 的云中。
- 云服务商管理的数据库。云服务商管理的数据库基于云服务商专用技术构建，是由特定云服务商管理的一种数据库服务。Spanner、Bigtable 和 AlloyDB for PostgreSQL 是此类数据库的示例。云服务商管理的数据库仅在云服务商的云中提供，不能在其他位置安装和运行。 但是，AlloyDB for PostgreSQL 与 PostgreSQL 完全兼容。
- 云中预先存在的数据库。云中预先存在的数据库在云技术开发之前就存在（有时是很长时间），通常在裸机硬件和虚拟机 (VM) 上运行。PostgreSQL、MySQL 和 SQL Server 是此类数据库的示例。这些系统可以在支持所需虚拟机或裸机硬件的任何云上运行。
- 云合作伙伴管理的数据库。一些公有云具有在公有云中安装和管理客户数据库的数据库合作伙伴。因此，客户不必自行管理这些数据库。MongoDB Atlas 和 MariaDB 是此类数据库的示例。
这些主要类别有一些变体。例如，实现为云端构建的数据库的数据库供应商可能支持在为云端构建的技术上进行安装，并在供应商提供的云中向客户提供代管式服务。此方法等同于供应商提供公有云，该云仅支持将其数据库作为单个服务。
云中预先存在的数据库可能位于容器中，并且可能部署到 Kubernetes 集群中。但是，这些数据库不使用 Kubernetes 特有的功能，例如扩缩、多服务或多 pod 部署。
数据库供应商可能会同时与多家公有云服务商合作，从而在多个公有云中提供其数据库作为云合作伙伴管理的数据库。
按分布模型划分的数据库系统
不同的数据库管理系统是根据数据库架构中的分布模型实现的。数据库的模型如下所示：
- 单一实例。单个数据库实例在一个虚拟机或一个容器上运行，充当一个集中系统。此系统会管理所有数据库访问。由于单一实例无法连接任何其他实例，因此数据库系统不支持复制。
- 多实例主动-被动。在此通用架构中，多个数据库实例彼此关联。最常见的关联是“主动-被动”关系，其中一个实例是同时支持实例和读写的主动数据库实例。一个或多个被动系统是只读的，可同步或异步地从主数据库接收所有数据库更改。被动系统可以提供读取权限。主动-被动也称为主要-辅助或源-副本。
- 多实例主动-主动。该架构相对不常见，其中每个实例都是主动实例。在这种情况下，每个实例都可执行读写事务并提供数据一致性。因此，为了防止数据不一致，所有实例始终保持同步。
- 支持冲突解决的多实例主动-主动。该系统也相对不常见。每个实例都可供读写访问，但数据库会以异步模式同步。允许同时更新同一数据项，这会导致状态不一致。冲突解决政策必须确定哪一个状态是最后的一致状态。
- 多实例分片。分片基于对数据（不相交）分区的管理。每个分区使用单独的数据库实例来管理。这种分布具有可扩缩性，因为随着时间的推移，可以动态添加更多分片。但是，可能无法实现跨分片查询，因为并非所有系统都支持此功能。
本部分讨论的所有分布模型都可以支持分片，并且可以是分片系统。但是，并非所有系统都可以提供分片选项。分片是一个可伸缩性概念，通常与多云环境中的架构数据库选择无关。
对于云端和合作伙伴管理的数据库，分发模式有所不同。由于这些数据库与云服务商的架构关联，因此这些系统会根据以下部署位置实现架构：
- 区域系统。一个区域管理的数据库系统与一个区域关联。当该区域可用时，数据库系统也可用。但是，如果区域不可用，则无法访问数据库。
- 地区系统。一个地区管理的数据库与一个地区关联，并在至少一个区域可访问时可供访问。任何区域的组合都可能会变得无法访问。
- 跨地区系统。一个跨地区系统与两个或更多个地区关联，并在至少一个地区可用时正常运行。
如果数据库可以安装在企业计划使用的所有云中，则跨地区系统还可以支持跨云系统。
本部分讨论的代管式数据库架构还有其他可能的替代方案。地区系统可能会在两个区域之间共享一个磁盘。如果两个区域中的任何一个无法访问，则数据库系统可在其余区域中继续。但是，如果两个区域都发生服务中断，那么即使其他区域可能仍完全在线，数据库系统也不可用。
将数据库系统映射到部署模式
下表介绍了本文档中讨论的部署模式和部署架构如何彼此相关。这些字段根据部署模式和部署架构声明实现组合所需的条件。
| 部署架构 | 部署模式 | ||||
|---|---|---|---|---|---|
| 分区时不使用跨数据库依赖项 | 异步单向复制 | 支持冲突解决的双向复制 | 完全主动-主动同步分布式系统 | ||
| 内置云数据库 | 适用于所有提供数据库系统使用的内置云技术的云。
如果同一个数据库不可用，您可使用不同的数据库系统。 |
提供复制功能的云数据库。 | 提供双向复制功能的云数据库。 | 提供主要-主要同步功能的云数据库。 | |
| 云服务商管理的数据库 | 不同云中的数据库系统可以不同。 | 副本不必是云服务商管理的数据库（请参阅数据库迁移技术在部署模式中的作用）。 | 如果数据库提供双向复制，则只能在云内部（而非跨云）。 | 仅在云内部（而不是跨云）时（如果数据库提供主要-主要同步）。 | |
| 云中预先存在的数据库 | 不同云中的数据库系统可以相同，也可以不同。 | 可以跨多个云进行复制。 | 数据库系统提供双向复制和冲突解决功能。 | 数据库系统提供主要-主要同步。 | |
| 云合作伙伴管理的数据库 | 不同云中的数据库系统可以不同。
如果合作伙伴在所有必需的云中提供代管式数据库系统，则可以使用相同的数据库。 |
副本不必是云服务商管理的数据库。 如果合作伙伴在所有必需的云中提供代管式数据库系统，则可以使用相同的数据库。 |
数据库系统提供双向复制和冲突解决功能。 | 数据库系统提供主要-主要同步。 | |
如果数据库系统不提供内置复制功能，则可以改用数据库复制技术。如需了解详情，请参阅数据库迁移技术在部署模式中的作用。
下表介绍了部署模式与分布模型的关系。这些字段声明了在给定部署模式和分布模型下可使用组合的条件。
| 分销模式 | 部署模式 | ||||
|---|---|---|---|---|---|
| 分区时不使用跨数据库依赖项 | 异步单向复制 | 支持冲突解决的双向复制 | 完全主动-主动同步分布式系统 | ||
| 单一实例 | 有可能在所涉及的云中使用相同或不同的数据库系统。 | 不适用 | 不适用 | 不适用 | |
| 多实例主动-被动 | 有可能在所涉及的云中使用相同或不同的数据库系统。 | 可以跨云进行复制。 | 可以跨云进行复制。 | 不适用 | |
| 多实例主动-主动 | 有可能在所涉及的云中使用相同或不同的数据库系统。 | 不适用 | 不适用 | 可以跨云进行同步。 | |
| 支持冲突解决的多实例主动-主动 | 有可能在所涉及的云中使用相同或不同的数据库系统。 | 不适用 | 不适用 | 适用于可跨云双向复制的情况。 | |
基于底层数据库技术添加额外抽象的分布模型的某些实现没有内置此类分布模型，例如 Postgres-BDR 主动-主动系统。此类系统包含在上表中的相应类别中。从多云的角度来看，分布模型的实现方式无关紧要。
数据库迁移和复制
根据用例，企业可能需要将数据库从一个部署位置迁移到另一个部署位置。或者，对于下游处理，它可能需要将数据库的数据复制到其他位置。下一部分将详细讨论数据库迁移和数据库复制。
数据库迁移
当数据库从一个部署位置移动到另一个部署位置时，会使用数据库迁移。例如，迁移在本地数据中心运行的数据库，使其改为在云端运行。迁移完成后，数据库将在本地数据中心关停。
数据库迁移的主要方法如下所示：
- 直接原样迁移。运行数据库实例的虚拟机和磁盘会按原样复制到目标环境中。复制后，它们就会启动并完成迁移。
- 导出和导入以及备份和恢复。这些方法都使用数据库系统功能来将数据库外部化，并在目标位置重新创建数据库。导出/导入通常基于 ASCII 格式，而备份和恢复则基于二进制格式。
- 零停机迁移。在此方法中，数据库会在应用系统访问源系统时进行迁移。初始加载后，系统会使用变更数据捕获 (CDC) 技术将更改从源数据库传输到目标数据库。应用会导致停机，停机时间从在源数据库系统停止一直到迁移完成后在目标数据库系统上重启为止。
当数据库从一个云迁移到另一个云，或者从一种数据库引擎迁移到另一种数据库引擎时，数据库迁移会在多云用例中变得相关。
数据库迁移这一流程涉及到多个方面。如需了解详情，请参阅数据库迁移：概念和原则（第 1 部分）和数据库迁移：概念和原则（第 2 部分）。
内置数据库技术可用于执行数据库迁移，例如导出和导入、备份和恢复或内置复制协议。如果源系统和目标系统是不同的数据库系统，则迁移技术是数据库迁移的最佳选择。Database Migration Service、Striim 和 Debezium 是数据库迁移技术的示例。
数据库复制
数据库复制类似于数据库迁移。但是在数据库复制期间，源数据库系统会在每项更改传输到目标数据库时保持原位。
数据库复制是一个持续的过程，它会将更改从源数据库发送到目标数据库。如果此过程是异步的，则更改会在短暂延迟后到达目标数据库。如果过程是同步的，则对源系统所做的更改会同时作用于目标系统，并作用于相同事务。
除了将源数据库复制到目标数据库，常见的做法是将数据从源数据库复制到目标分析系统。
与数据库迁移一样，如果有复制协议可用，则内置数据库技术可用于数据库复制。如果没有内置复制协议，则可以使用 Striim 或 Debezium 等复制技术。
数据库迁移技术在部署模式中的作用
在部署模式中使用不同的数据库系统（例如异步（异构）复制）时，通常不提供用于复制的内置数据库技术。而是可以部署数据库迁移技术来启用此类复制。其中一些迁移系统还实现了双向复制。
如果数据库迁移或复制技术可用于将数据库系统映射到部署模式中的表 1 或表 2 中标记为“不适用”的组合中使用的数据库系统，那么可能能够将它用于数据库复制。下图展示了使用迁移技术进行数据库复制的方法。
在上图中，位置 1 的数据库被复制到位置 2 的数据库。部署迁移服务器来实现复制，而不是直接复制数据库系统。此方法用于这样的数据库系统，它们没有在实现中内置数据库复制功能，而且需要依赖与数据库系统分开的系统来实现复制。
多云数据库选择
多云数据库用例与数据库系统分类相结合，可帮助您确定哪些数据库最适合给定用例。例如，如需实现应用可移植性中的用例，有两种方法。第一种方法是确保同一数据库引擎在所有云中都可用。这种方法可确保系统的可移植性。第二种方法是确保为所有云提供相同的数据模型和查询接口。虽然数据库系统可能有所不同，但可移植性是在功能接口上提供的。
以下部分中的决策树显示了本文档中多云数据库用例的决策标准。决策树建议考虑对每个用例使用最佳数据库。
现有数据库系统的最佳做法
如果数据库系统在生产环境中，则必须决定是保留还是替换该系统。下图显示了您的决策过程中要考虑的问题：
决策树中的问题和解答如下：
- 数据库系统是否处于生产状态？
- 如果数据库系统都未处于生产状态，请选择一个数据库系统（跳转至关于多云数据库管理的决策）。
- 如果数据库系统处于生产状态，请评估是否应保留该系统。
- 如果数据库系统处于生产状态，请评估是否应保留该系统。
- 如果应保留数据库系统，则会做出决策并完成决策过程。
- 如果应更改数据库系统，或者仍在做决策，请选择一个数据库系统（跳转至关于多云数据库管理的决策）。
关于多云数据库管理的决策
以下决策树适用于具有多位置数据库要求（包括多云数据库部署）的用例。它使用部署模式作为决策标准的基础。
决策树中的问题和解答如下：
- 数据是否分区到不同的数据库中，没有任何跨数据库依赖项？
- 如果是，则可以为每个位置选择相同或不同的数据库系统。
- 如果不是，请继续回答下一个问题。
- 是否需要异步单向复制？
- 如果是，则评估数据库复制系统是否可接受。
- 如果是，请选择与复制系统兼容的相同或不同的数据库系统。
- 如果不是，请选择可以实现主动-被动分布模型的数据库系统。
- 如果不是，请继续回答下一个问题。
- 如果是，则评估数据库复制系统是否可接受。
- 选择具有同步实例的数据库系统。
- 冲突解决是否是可接受的？
- 如果是，请选择双向复制数据库系统或主动-主动数据库系统。
- 如果不是，请选择主动-主动系统。
- 冲突解决是否是可接受的？
如果实现了多个多云用例，则企业必须决定是使用一个数据库系统支持所有用例，还是使用多个数据库系统。
如果企业想要使用一个数据库系统来支持所有用例，则具有最佳同步的系统是最佳选择。例如，如果既需要单向复制，也需要同步实例，则最佳选择是同步实例。
同步质量的层次结构为（从无到最佳）：分区、单向复制、双向复制和完全同步的复制。
部署最佳做法
本部分重点介绍在选择数据库进行多云应用迁移或开发时要遵循的最佳做法。
现有数据库管理系统
一种好的做法是保留数据库，除非特定用例要求，否则不更改数据库系统。对于已建立数据库管理系统并且具有有效开发、运营和维护流程的企业，最好避免进行更改。
不需要云端数据库系统的云爆发用例可能不需要数据库更改。另一个用例是异步复制到同一云中的其他部署位置或复制到另一个云。对于这些用例，一种不错的方法是实现基准测试，同时验证跨位置通信，并验证在访问数据库时跨位置通信和延迟是否满足应用要求。
将数据库系统用作 Kubernetes 服务
如果企业考虑在 Kubernetes 中将数据库系统作为基于 StatefulSet 的服务来运行，则必须考虑以下因素：
- 数据库是否提供应用所需的数据库模型。
- 非功能因素，用于确定如何在数据库系统中以 Kubernetes 服务的形式实现操作 - 例如，如何扩缩（纵向扩容和纵向缩容）、如何管理备份和还原，以及系统如何提供监控。为帮助他们了解基于 Kubernetes 的数据库系统的要求，企业应将其在数据库方面的经验用作对照点。
- 高可用性和灾难恢复。为了提供高可用性，当区域内的可用区发生故障时，系统需要继续运行。数据库必须能够快速从一个可用区故障切换到另一个可用区。在理想情况下，数据库在每个可用区中都运行了一个完全同步的 RTO 和 RPO 为零的实例。
- 灾难恢复，用于应对地区（或云）的故障。在理想情况下，数据库继续在第二个地区运行，其中 RPO 和 RTO 为零。在不太理想的情况中，次要地区中的数据库可能无法完全跟上主要数据库中的所有事务。
若要确定如何在 Kubernetes 中以最佳方式运行数据库，完整数据库评估是一个不错的方法，尤其是当系统需要与 Kubernetes 之外的生产环境中的系统进行比较时。
独立于 Kubernetes 的数据库系统
对于在 Kubernetes 中以服务形式实现的应用，并不总是需要同时在 Kubernetes 中运行数据库。数据库系统需要在 Kubernetes 外部运行的原因有很多，例如已建立的流程、企业内的产品知识，或者不可用情况。云服务商和云合作伙伴管理的数据库都属于此类别。
同样可以在 Compute Engine 运行数据库。选择数据库系统时，最好进行完整数据库评估，以确保满足应用的所有要求。
从应用设计的角度来看，连接池是一项重要的设计考虑因素。访问数据库的应用服务可能会在内部使用连接池。使用连接池有助于提高效率并减少延迟时间。无需启动请求，也无需等待创建连接，而是从池中发出请求。如果通过添加应用服务实例对应用进行纵向扩容，则每个实例都会创建一个连接池。如果遵循最佳做法，则每个池会预先创建一组最小连接。每次为应用扩缩另外创建一个应用服务实例时，连接都会添加到数据库中。从设计角度来看，由于数据库不支持无限连接，因此必须管理添加的连接以避免过载。
最佳数据库系统与数据库系统可移植性
选择数据库系统时，企业通常会选择能够满足应用要求的最佳数据库系统。在多云环境中，您可选择每个云中的最佳数据库，并且它们可以根据用例彼此连接。如果这些系统不同，则任何复制（单向或双向）都需要花费大量精力。如果使用最佳系统的好处超过了实现它所需的工作量，那么这种方法可能是合理的。
不过，一种好的做法是考虑同时评估所有必需云中提供的数据库系统的方法。虽然此类数据库可能并不是理想的选择，但实现、操作和维护此类系统要容易得多。
并发数据库系统评估演示了这两种数据库系统的优缺点，为选择提供了坚实的基础。
内置数据库系统复制与外部数据库系统复制
对于需要在所有部署位置（区域、地区或云）中使用数据库系统的用例，复制是一项重要功能。复制可以是异步、双向或完全同步的主动-主动复制。数据库系统并不支持所有这些复制形式。
对于不支持将复制纳入其系统实现复制的系统，Striim 之类的系统可用于补充架构（如数据库迁移中所述）。
最佳做法是评估其他数据库管理系统，来确定具有内置复制功能的系统或需要复制技术的系统的优缺点。
第三类技术在本例中也发挥着作用。此类会为现有数据库系统提供插件，从而提供复制功能。一个示例是 MariaDB Galera 集群。如果评估过程允许，最好评估这些系统。
后续步骤
- 了解混合云和多云模式及做法。
- 了解将其他云服务提供商与 Google Cloud 连接的模式。
- 了解在 Google Cloud 上进行混合云和多云部署的监控和日志记录架构。
- 如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。
贡献者
作者：Alex Cârciu | 解决方案架构师