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