将迁移的 MongoDB 工作负载部署到 Oracle Autonomous Transaction Processing Serverless@Google 云
使用文档和文档数据库来发展数据方案和应用程序的工作负载和应用程序非常受欢迎，因为它们为开发人员提供了灵活性。模式灵活性、快速开发和可扩展性使应用程序功能能够快速原型化、更轻松地进行应用程序演化，并保证构建迭代更小的应用程序和功能，开发人员可以扩展这些应用程序和功能来满足大型用户群的需求。然而，这些类型的工作负载面临着挑战，包括事务性保证较弱、数据查询的多功能性，以及无法支持文档（例如分析或机器学习）上的其他工作负载。
如果这些工作负载能够从传统文档数据库的优势中获益并利用关系数据库的优势，结果会怎样？例如，具有更强大的事务处理保证，并添加了分析和机器学习等功能，而无需将数据复制到其他数据库或系统。
自治事务处理 (Autonomous Transaction Processing，ATP) 无服务器是一项经过优化的全自动化数据库服务，可并行运行事务、分析和批处理工作负载。为了提高性能，该服务针对行格式、索引和数据缓存进行了预配置，同时提供可扩展性、可用性、透明的安全性和实时运营分析。应用开发人员和 DBA 可以在不牺牲功能或原子性、一致性、隔离性和持久性 (ACID) 属性的情况下快速、经济高效地开发和部署应用。
功能架构
此体系结构假定，具有应用程序和 MongoDB 数据库的工作负载（内部部署或云部署）存在，并将迁移到 Google Cloud 和 Oracle Database@Google Cloud 。它描述了未来的状态架构、其优势、如何部署以及可用于增强现有工作负载的其他功能。
此架构中使用的关键特性之一是 Oracle Database API for MongoDB，它支持应用使用 MongoDB 驱动程序、工具和 SDK 与 Oracle Database 中的 JSON 文档集合进行交互。现有应用代码可以处理存储在 Autonomous Transaction Processing Serverless 中的数据，而无需重构代码。
下图描述了由数据库、后端和前端层组成的典型应用程序。
mongodb-atp-s-google-logical-arch-migration.zip
MEAN 堆栈是用于实现此模式的常用堆栈：
- MongoDB ：文档数据库
- Express：后端框架
- Angular：前端框架
Node.js：后台服务器
本文档使用 MEAN 堆栈作为将迁移到 Google Cloud 和 ATP Serverless 的现有部署的示例。
将此工作负载迁移到 Google Cloud 和 ATP Serverless 非常简单，主要包括以下步骤：
- 部署 ATP 无服务器实例，在创建时启用 Oracle Database MongoDB API。
- 将元数据和数据从 MongoDB 迁移到 ATP Serverless。
- 使用 Google Cloud Run、VM、容器或 Kubernetes 将应用服务器部署到与 ATP Serverless 相同的区域和可用性域，以运行
Node.js和 Express。 - 将后端应用程序代码部署到应用服务器。
- 使用当前应用程序上使用的相同 MongoDB 工具和驱动程序将后端应用程序连接到 ATP Serverless。
- 将用户连接到新的应用程序 URI。
请注意，此参考体系结构侧重于迁移的工作负载的部署，而不是迁移过程本身。有关迁移过程的更多详细信息，请参阅了解更多信息部分。
将工作负载迁移到 ATP Serverless 后，可以使用多个功能来增强现有功能，无论是 1) 支持额外的非功能要求，例如轻松提高可扩展性、弹性还是高可用性，还是 2) 具有其他功能特性，例如运营报告、分析和机器学习，而无需将数据从数据库中复制出来。
要提高可扩展性和高可用性，请使用 Autonomous Transaction Processing Serverless 自动缩放功能。通过一次单击或 API 调用，工作负载最多可使用基线容量的 3 倍，而无需停机。请注意，Autonomous Transaction Processing Serverless 使用 Oracle Real Application Clusters (Oracle RAC) 技术实现高可用性。对于后端层，请使用具有自动缩放设置的 VM 缩放集，或者使用具有自动缩放设置的 PaaS 服务（如应用程序服务）来启用应用程序的高可用性和可扩展性。
由于 ATP Serverless 是基于多模型、多工作负载数据库技术构建的，因此您可以添加依赖于与现有应用程序一起工作的关系型、空间型、图形型或向量型数据类型的功能。
物理体系结构
物理架构包括使用两个 Google Cloud 区域中的委派子网部署的 Autonomous Transaction Processing Serverless，以支持高可用性。OCI 服务支持自动备份到 Oracle Cloud Infrastructure Object Storage 。
该体系结构支持以下各项：
- 前端层
- 应用程序用户可以从 Internet 进行连接。
- 用户连接通过全局云负载平衡器路由到运行应用的活动区域。
- 使用 Cloud Armor 保护用户连接。
- 与应用的用户连接使用外部全局应用负载平衡器进行负载平衡。
- 后端层
- 使用 Cloud Run 以高可用性方式部署应用程序。
- Cloud Run 自动缩放用于实现水平可扩展性。
- Database Tier
- ATP 无服务器提供高可用性，例如 Oracle Real Application Clusters (Oracle RAC) 和多个数据库节点是服务实例的基础。因此，默认情况下，数据库层具有高可用性和弹性。
- 在 ATP Serverless 中启用的 Oracle Database API for MongoDB 允许您无需更改即可使用现有应用程序代码。
- Oracle Database API for MongoDB 具有高度的弹性，ATP Serverless 可在内部保证弹性。
- ATP 无服务器可以使用自动缩放，在系统负载增加和减少时进行调整。
- ATP 无服务器业务连续性通过跨区域 Autonomous Data Guard 实现。
- 灾难恢复
- 第二个区域部署了类似的拓扑，以减少总体恢复时间目标。
- 使用热 DR 策略降低总体 RTO。在热 DR 策略中，后端层云资源已与 ATP 无服务器备用数据库一起预配。
- 或者，您可以在发生故障时预配后端层资源，从而降低运行 DR 资源的成本，同时提高整体 RTO。
- 网络
- 云负载平衡器将路由来自内部部署和互联网的所有应用传入流量。
- ATP 无服务器部署有专用端点，以提高安全状况。
- Cloud Run 使用放置在 VPC 的应用程序子网中的无服务器 VPC 访问连接器进行部署，以访问 ATP 无服务器实例。
- 无服务器 VPC 访问连接器允许与 ATP 无服务器实例建立专用连接。
- 安全
- 所有数据在传输中和静态都是安全的。
为了简单起见，不在此部署中描述以下潜在的设计改进：
- 使用云监视警报、发布/订阅和云功能自动执行应用灾难恢复。
- 利用集线器和辐条式拓扑来强制实施集中式网络安全。
- 利用部署在集线器 VPC 中的网络防火墙，通过检查所有流量和执行策略来改善整体安全状况。
mongodb-atp-s-google-physical-arch.zip
该架构包含以下 Google 组件：
- Google Cloud 区域
Google Cloud 区域是一个地理区域，其中包含用于托管资源的数据中心和基础设施。区域由区域组成，这些区域在该区域内彼此隔离。
- Google Cloud 区域
Google Cloud 中的区域是区域内资源的部署区域。区域在一个区域内彼此隔离，并被视为一个故障域。
- Google Cloud 项目
使用 Google Workspace API 和构建 Google Workspace 附加组件或应用程序需要 Google Cloud Project。Cloud Project 构成了创建、启用和使用所有 Google Cloud 服务的基础，包括管理 API、启用计费、添加和删除协作者以及管理权限。
- Google 虚拟私有云
Google Virtual Private Cloud (VPC) 为 Compute Engine 虚拟机 (VM) 实例、Google Kubernetes Engine (GKE) 容器、数据库服务和无服务器工作负载提供网络功能。VPC 可为您的基于云的服务提供灵活、可扩展的网络。
- Google 子网
每个 Google Virtual Private Cloud (VPC) 网络都包含一个或多个称为子网的 IP 地址范围。子网是具有与之关联的 IP 地址范围的区域资源。
- Google 负载平衡器
Google 负载平衡器提供从单个入口点到后端多个服务器的自动流量分配。
- Google Cloud Armor
Google Cloud Armor 是一项网络安全服务，通过将始终启用的 DDoS 防御、Web 应用防火墙 (WAF) 和预配置的可定制规则以及基于机器学习的自适应应用威胁检测相结合，为分布式拒绝服务 (DDoS) 攻击和 Web 应用威胁（例如跨站点脚本 (XSS) 和 SQL 注入）提供企业级保护。
- Google Cloud 运行
Google Cloud Run 是一个完全托管的无服务器计算平台，可让您直接在 Google 可扩展的基础设施上运行容器化应用、API 和批处理作业，并实现自动扩展和集成的安全性，而无需管理服务器或集群。
该体系结构包含以下 Oracle 组件：
- OCI 地区
OCI 区域是一个本地化的地理区域，其中包含一个或多个托管可用性域的数据中心。区域独立于其他区域，并且很远的距离可以将它们分开（跨越国家甚至大洲）。
- Oracle Autonomous Database
Oracle Autonomous Database 是一个完全托管的预配置数据库环境，可用于事务处理和数据仓库工作负载。您不需要配置或管理任何硬件，也不需安装任何软件。OCI 可处理数据库创建、备份、打补丁、升级和调优。
- Oracle Autonomous Data Guard
Oracle Autonomous Data Guard 支持备用（对等）数据库为您的 Autonomous Database 实例提供数据保护和灾难恢复。它提供了一组全面的服务，可创建、维护、管理和监视一个或多个备用数据库，使生产 Oracle 数据库在不中断的情况下保持可用。Oracle Data Guard 将这些备用数据库作为生产数据库的副本进行维护。然后，如果生产数据库由于计划内或计划外停机而变得不可用，您可以将任何备用数据库切换到生产角色，从而最大限度地减少与停机关联的停机时间。
- OCI 对象存储
OCI Object Storage 可访问任意内容类型的大量结构化和非结构化数据，包括数据库备份、分析数据以及图像和视频等丰富内容。您可以安全地直接从应用或云平台内存储数据。您可以扩展存储，而不会出现性能或服务可靠性下降的情况。
将标准存储用于您需要快速、立即和频繁访问的“热”存储。将归档存储用于长期保留且很少或很少访问的“冷”存储。
体系结构变量
建议的物理体系结构的这种变体使用在每个应用服务器中运行的由客户管理的 Oracle REST Data Services 部署。但是，ATP Serverless 提供的完全托管的 MongoDB API 是大多数工作负载的最佳解决方案，因为它更易于管理。
如果需要手动控制 Oracle REST Data Services 的配置和管理，则可以选择使用客户管理的 Oracle REST Data Services。例如，允许应用程序使用更大的连接池。
注意：
如果有特定的工作负荷要求，请使用此体系结构变量。只有高级用户才应部署此体系结构变体。本节仅介绍了与之前描述的物理体系结构相比的差异，因此除非另有说明，否则所有物理体系结构设计原则都是有效的。
下面的体系结构图描述了变体的部署方式。为简单起见，只会描述部署在 JSON 工作负载 VCN 中的云资源，因为部署的其余部分与前面描述的物理架构相同。
mongodb-atp-s-google-arch-variant.zip
- 传入用户请求由 Cloud Load Balancer 分发，Cloud Load Balancer 使用 Cloud Run 无服务器网络端点组 (NEG) 作为其后端。此设置可实现水平扩展并消除任何单点故障。
- 后端应用程序部署为 Cloud Run 容器。
- Cloud Run 根据现有容器负载水平扩展容器。
- 使用应用程序和 Oracle REST Data Services 创建、安装和配置容器，这使两个容器都可以在同一容器中运行。
- 每个 Worker 都在同一运行时环境中运行容器映像，以共存应用和 Oracle REST Data Services。
- 客户管理的 Oracle REST Data Services Worker 配置为启用 MongoDB API，以便应用可以使用 MongoDB 工具和驱动程序连接到数据库。
- 客户管理的 Oracle REST Data Services 配置为可根据工作负载非功能要求进行调整，例如配置较大的连接池或使用其他数据库服务。
- 后端代码和客户管理的 Oracle REST Data Services 都预先安装并预配置在 Worker 上使用的容器映像中。当 Cloud Run 横向扩展时，新员工能够运行后端应用，并在预配后连接到数据库。
推荐
- 应用程序部署
- 如果您需要 Cloud Run 中可能不可用的高级编排、网络和安全功能，请考虑使用基于容器的 Google Kubernetes 引擎 (GKE) 部署。
- 安全
- 请考虑使用 Oracle Data Safe 来进一步提高工作负载安全状况并执行数据库审计。
- 观测
- 考虑使用 Google Cloud Monitoring 来监视 ATP Serverless 指标以及所有其他 Google Cloud 服务监视数据。
- 灾难恢复
- 考虑使用 Google 合作伙伴解决方案或定制脚本自动执行和编排堆栈所有层的灾难和恢复，以检测故障并启动故障转移流程。
- 运营效率
- 如果 ATP 无服务器工作负载属于更广泛的数据库组，请考虑使用弹性池来提高成本效率。
- 考虑启用 OCI 服务 Oracle Cloud Infrastructure Database Management，该服务提供一组全面的数据库性能监视和管理功能，以简化 ATP 无服务器实例的管理。
- 应用程序演变
- 考虑使用 SQL 和前端（例如 Oracle APEX 或 Looker）在 ATP Serverless 中部署运营分析和实时报告，而无需将数据移出数据库，以进行可信和实时数据分析。
- 考虑使用 Oracle Machine Learning (OML) 将 ATP Serverless 用于机器学习，使用 JSON 数据构建和训练模型，而无需任何数据移动，并部署模型和现有工作负载以实现高效推断。
- 对于应用核心之外的其他用例，请考虑使用 ATP 无服务器选择 AI 和数据库视图来查询 JSON 并保存元数据，以便用户可以使用自然语言查询 JSON 数据。
- 考虑使用 ATP Serverless 存储其他数据类型（关系型、向量型、空间型或图形型），以提高工作负载的功能和灵活性。