你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Azure API 管理迁移 Web 应用

Azure API 管理
Azure Monitor
Azure 应用程序服务

在此方案中，旅游行业的电子商务公司使用 Azure API 管理迁移旧版 Web 应用。 该公司将新的 UI 作为平台即服务（PaaS）应用托管在 Azure 上。 新 UI 依赖于现有和新的 HTTP API。 这些 API 使用更高效的设计接口进行部署，这些接口可提高性能、简化集成并允许将来的扩展性。

Architecture

此图显示了使用 API 管理迁移 Web 应用的步骤。

下载此体系结构的 Visio 文件。

Workflow

以下工作流与上图相对应：

  1. 现有的本地 Web 应用继续直接使用现有的本地 Web 服务。

  2. 现有的 Web 应用对现有 HTTP 服务的调用保持不变。 这些调用在企业网络内部执行。

  3. API 管理从 Azure 调用现有内部服务。

  4. 新 API 具有以下特征：

  5. 基于浏览器的新 Web 应用依赖于现有 HTTP API 和新 API 的 API 管理实例。

  6. 旅游电子商务公司可以将某些用户定向到新的 UI 进行预览或测试，同时保留旧 UI 和现有功能。

设置 API 管理实例，将旧版 HTTP 服务映射到新的 API 协定。 在此配置中，新的 Web UI 不知道与一组旧服务或 API 和新 API 的集成。

将来，项目团队可以逐渐将功能移动到新的 API，并停用原始服务。 团队在 API 管理配置中处理这些更改，使前端 UI 不受影响并避免重新开发工作。

Components

  • API 管理 是跨所有环境的 API 的管理平台和网关。 在此体系结构中，它充当旧 API 与新 API 的门面。 新的客户端应用使用单个一致的界面，团队可以在该外观后面以增量方式实现旧后端的现代化，对前端开发的影响最小。

  • 应用服务 是一种用于 Web 托管的交钥匙 PaaS 解决方案，提供现成的功能，例如安全性、负载均衡、自动缩放和自动化管理。 在此体系结构中，应用服务提供灵活的交钥匙托管，以便 DevOps 团队可以专注于功能交付。

Alternatives

  • 如果组织计划将其基础结构（包括托管旧应用的虚拟机（VM））完全迁移到 Azure，API 管理可以充当任何可寻址 HTTP 终结点的门面。

  • 如果组织将现有终结点保留为专用终结点，并且不会公开这些终结点，则组织的 API 管理实例可以链接到 Azure 虚拟网络。

  • 组织可以通过在内部模式下部署 API 管理实例来使其保持私有状态。 然后，组织可以将部署与 Azure 应用程序网关 配合使用，以允许某些 API 的公共访问，而另一些 API 则保持内部状态。 有关详细信息，请参阅 使用应用程序网关在内部虚拟网络中集成 API 管理。

  • 组织可能决定在本地托管其 API。 此更改的一个原因是组织无法将此项目范围内的下游数据库依赖项移到云中。 在此方案中，组织可以使用 自承载网关在本地利用 API 管理。

    自行托管网关是在容器中部署的 API 管理网关，通过出站套接字连接到 Azure。 若要使用自承载网关，必须满足以下先决条件：

    • 必须使用 Azure 中的父资源部署自承载网关，从而增加额外的成本。

    • 必须使用 API 管理的高级层。

方案详细信息

旅游行业的电子商务公司希望现代化其传统的基于浏览器的软件堆栈。 现有堆栈主要是整体堆栈，但一些 基于简单对象访问协议（SOAP）的 HTTP 服务 存在于最近的项目中。 该公司考虑创建额外的收入流，以盈利其一些内部知识产权。

该项目的目标包括解决技术负债、持续改进维护、加速功能开发以及减少回归缺陷。 项目使用迭代过程来避免风险，并并行执行以下步骤：

  • 开发团队将应用后端现代化，该后端由 VM 上托管的关系数据库组成。

  • 内部开发团队编写新的业务功能，并通过新的 HTTP API 公开它。

  • 合同开发团队构建了 Azure 托管的新基于浏览器的 UI。

该公司分阶段提供新的应用功能。 这些功能逐渐取代了本地托管的现有基于浏览器的客户端和服务器 UI 功能，这些功能为公司的电子商务业务提供支持。

管理团队成员不希望进行不必要的现代化。 此外，他们希望能够保持控制项目范围和成本。 为了实现这些目标，他们决定保留其现有的 SOAP HTTP 服务。 他们还希望能够尽量减少对现有 UI 做出的更改。 他们可以使用 API 管理 来解决项目的许多要求和约束。

可能的用例

此方案重点介绍了如何实现旧版基于浏览器的软件堆栈的现代化。

可以将此方案用于以下任务：

  • 了解你的企业能够如何通过利用 Azure 生态系统获益。
  • 计划服务迁移到 Azure。
  • 了解迁移到 Azure 如何影响现有 API。

Considerations

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

Reliability

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性设计评审清单。

  • 部署 API 管理实例时激活 可用性区域 。 将 API 管理部署到可用性区域的选项仅在高级服务层中可用。

  • 使用具有 部署到不同区域的额外网关实例的可用性区域。 如果一个区域脱机，则此组合可提高服务可用性。 多区域部署仅在高级服务层中可用。

  • 与 Application Insights 集成，它通过 Azure Monitor 显示用于监视的指标。 例如，可以使用容量指标来确定 API 管理资源的总体负载，以及是否需要 更多横向扩展单元。 跟踪资源容量和运行状况以提高可靠性。

  • 确保下游依赖项（例如托管 API 管理涵盖的 API 的后端服务）也具有复原能力。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

API 管理有八个层：

  • 消耗
  • 开发人员
  • 基本和基本 v2
  • 标准和标准 v2
  • Premium 和 Premium v2

有关这些层的差异的详细信息，请参阅 API 管理定价。

可以通过添加和删除单元来缩放 API 管理。 每个单元的容量取决于其所在的层。

Note

可以使用开发人员层评估 API 管理功能。 请勿将其用于生产。

若要查看部署需求的预计成本，可以修改 Azure 定价计算器中的缩放单元数和应用服务实例数。

Contributors

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

其他参与者：

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤