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