使用 Azure API 管理迁移 Web 应用
在此场景中，一家从事旅游业的电子商务公司通过使用 Azure API 管理迁移旧的 web 应用程序。 新 UI 将作为平台即服务 (PaaS) 应用程序托管在 Azure 上，并依赖于现有和新的 HTTP API。 这些 API 附带了一组设计更合理的接口，可以提高性能、简化集成和实现将来的扩展。
体系结构
下载此体系结构的 Visio 文件。
工作流
- 现有的本地 Web 应用程序继续直接使用现有的本地 Web 服务。
- 仍然是从现有的 Web 应用调用现有的 HTTP 服务。 这些调用在企业网络内部执行。
- 入站调用是从 Azure 向现有内部服务发出的：
- 安全团队允许来自 API 管理实例的流量 使用安全传输（HTTPS 或 SSL）通过公司防火墙传递到现有的本地服务。
- 运营团队只允许从 API 管理实例向服务发出入站调用。 它通过将 API 管理实例的 IP 地址添加到 企业网络外围中的允许列表来满足此要求。
- 新模块配置为用于 HTTP 服务的本地请求管道（ 仅 处理来自外部的连接）。 管道验证 API 管理提供的证书。
- 新 API：
- 只通过提供 API 结构的 API 管理实例公开。 不会直接访问新 API。
- 开发并发布为 Azure PaaS Web API 应用。
- 配置为（通过 Azure 应用服务的 Web 应用功能设置）仅接受 API 管理虚拟 IP（VIP）。
- 托管在已启用安全传输（HTTPS 或 SSL）的 Azure Web 应用中。
- 已启用授权， Azure 应用服务 通过 Microsoft Entra ID 和 Open Authorization （OAuth） 2 提供。
- 基于浏览器的新 Web 应用程序依赖于现有 HTTP API 和新 API 的 Azure API 管理实例。
- 旅游电子商务公司现在可以将某些用户引导到新的 UI（预览版或测试），同时保留旧 UI 和现有功能并排。
API 管理实例配置为将旧式 HTTP 服务映射到新的 API 合同。 通过这种配置，新 Web UI 将不知道与一组旧式服务/API 和新 API 进行了集成。
将来，项目团队会逐渐将功能移植到新 API，并淘汰原始服务。 团队将在API 管理配置中处理这些更改，使前端 UI 不受影响，并避免重新开发工作。
组件
- Azure API 管理 抽象化后端 API，并为开发人员和应用程序添加交叉功能和发现。 在此方案中，通过使用 API 管理作为新客户端应用程序使用一致和使用新标准，可以重新组合现有旧式后端 API，并添加新的 API 功能。 由于 API 管理外观既有现有的 API，也有新的 API，因此开发人员有可能以迭代的方式对 API 管理外观后面的旧式后端进行现代化，并且对新前端开发的影响最小到零。
- Azure 应用服务 是用于 Web 托管的一项关键平台即服务（PaaS）服务，提供现成的功能，例如安全性、负载均衡、自动缩放和自动化管理。 Azure 应用程序服务是为该解决方案开发的新 API 的绝佳选择，因为它提供了灵活的现成托管，使 DevOps 团队能够专注于交付功能。
备选方法
如果组织计划将整个基础结构（包括托管旧式应用程序的 VM）转移到 Azure，则 API 管理仍是一个极佳的选项，因为它可以充当任何可寻址 HTTP 终结点的结构。
如果组织已决定将现有终结点保留为专用终结点，并且不公开这些终结点，则组织的 API 管理实例可以链接到 Azure 虚拟网络：
- 当 API 管理链接到 Azure 虚拟网络时，组织可以通过专用 IP 地址直接寻址后端服务。
- 在本地方案中，API 管理实例可以通过 Azure VPN 网关和站点到站点 Internet 协议安全性（IPsec）VPN 连接 或 Azure ExpressRoute 私下访问内部服务。 然后，此方案将成为 Azure 和本地的混合方案。
组织可以通过在内部模式下部署 API 管理实例来使其保持私有状态。 然后，组织可以将部署与 Azure 应用程序网关 配合使用，为某些 API 启用公共访问，而另一些 API 则保持内部状态。 有关详细信息，请参阅将 内部虚拟网络中的 API 管理与应用程序网关集成。
组织可能决定在本地托管其 API。 做出这种改变的可能原因之一是，组织无法将此项目范围内的下游数据库依赖项转移到云中。 如果是这种情况，组织仍可以使用 自承载网关在本地利用 API 管理。
自承载网关是 API 管理网关的容器化部署，它通过出站套接字连接回到 Azure。 第一个先决条件是，如果 Azure 中没有父资源，则无法部署自承载网关，这会产生额外的费用。 其次，需要高级层 API 管理。
方案详细信息
一家旅游行业的电子商务公司正在现代化其旧式基于浏览器的软件堆栈。 尽管现有堆栈大多是整体堆栈，但最近的项目中存在一些 基于简单对象访问协议（SOAP）的 HTTP 服务 。 该公司正在考虑建立更多的收入流，以便将一些已开发的内部知识产权转化为收益。
项目目标包括解决技术债务、改进日常维护，以及加速功能开发并减少回归缺陷。 该项目将使用迭代过程来避免风险，同时并行执行某些步骤：
- 开发团队将现代化应用程序后端，该后端由 VM 上托管的关系数据库组成。
- 内部开发团队将编写要通过新 HTTP API 公开的新业务功能。
- 合同开发团队将生成一个要托管在 Azure 中的基于浏览器的新 UI。
新应用程序功能分阶段交付。 这些功能将逐渐替代现有的、目前为该公司电子商务业务提供动力的基于浏览器的客户端-服务器 UI 功能（托管在本地）。
管理团队成员不希望进行不必要的现代化。 此外，他们希望能够保持控制项目范围和成本。 为此，他们决定保留现有的 SOAP HTTP 服务。 他们还希望能够尽量减少对现有 UI 做出的更改。 他们可以使用 Azure API 管理 来解决项目的许多要求和约束。
可能的用例
此场景重点介绍如何让旧式基于浏览器的软件堆栈实现现代化。
你可以通过此场景来实现以下目的：
- 了解你的企业能够如何通过利用 Azure 生态系统获益。
- 计划如何将服务迁移到 Azure。
- 了解迁移到 Azure 会对现有 API 产生怎样的影响。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。
可靠性
可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性设计评审清单。
- 请考虑部署 已启用可用性区域的 Azure API 管理实例。 将 API 管理部署到可用性区域的选项仅在高级服务层级中可用。
- 可用性区域可与 部署到不同区域的附加网关实例结合使用。 如果一个区域脱机，这将提高服务可用性。 多区域部署也仅在高级服务层级中可用。
- 请考虑 与 Azure Application Insights 集成，后者还通过 Azure Monitor 显示用于监视的指标。 例如，容量指标可用于确定 API 管理资源的总体负载，以及是否需要 额外的横向扩展单元。 跟踪资源容量和运行状况可提高可靠性。
- 确保下游依赖项（例如，托管 API 管理外观的 API 的后端服务）也具有复原能力。
成本优化
成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。
以下四个层中提供了 API 管理：开发人员、基本、标准和高级。 有关这些层差异的详细指南，请参阅 Azure API 管理定价指南。
可以通过添加和删除单元来缩放 API 管理。 每个单元的容量取决于其所在的层。
注意
可以使用开发人员层来评估 API 管理功能。 请勿将其用于生产环境。
若要查看预计的成本并根据部署需求进行自定义，可以修改 Azure 定价计算器中的缩放单元和应用服务实例数。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Ben Gimblett |高级客户工程师
若要查看非公共LinkedIn配置文件，请登录到LinkedIn。
后续步骤
产品文档：
Learn 模块：