在此场景中，一家从事旅游业的电子商务公司通过使用 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。
- 托管在已启用安全传输（HTTPS 或 SSL）的 Azure Web 应用中。
- 已启用授权，该授权由 Azure 应用服务使用 Microsoft Entra ID 和 OAuth2 提供。
- 基于浏览器的新 Web 应用程序将依赖于 Azure API 管理实例来使用现有的 HTTP API 和新的 API。
API 管理实例配置为将旧式 HTTP 服务映射到新的 API 合同。 通过这种配置，新 Web UI 将不知道与一组旧式服务/API 和新 API 进行了集成。
将来，项目团队会逐渐将功能移植到新 API，并淘汰原始服务。 团队将在API 管理配置中处理这些更改，使前端 UI 不受影响，并避免重新开发工作。
组件
备选方法
如果组织计划将整个基础结构（包括托管旧式应用程序的 VM）转移到 Azure，则 API 管理仍是一个极佳的选项，因为它可以充当任何可寻址 HTTP 终结点的结构。
如果组织决定保持现有终结点的私密性，而不想将其公开，可将其 API 管理实例链接到 Azure 虚拟网络 (VNet)：
- 在链接到已部署的 Azure 虚拟网络的 Azure 直接迁移方案中，组织可以通过专用 IP 地址直接寻址后端服务。
- 在本地方案中，API 管理实例可以通过 Azure VPN 网关和站点到站点 IPSec VPN 连接或 Azure ExpressRoute，以私密方式反向连接到内部服务。 然后，此方案将成为 Azure 和本地的混合方案。
组织可以通过在内部模式下部署 API 管理实例来使其保持私有状态。 然后，组织可以结合 Azure 应用程序网关使用该部署，让某些 API 进行公开访问，同时让其他一些 API 进行内部访问。 有关详细信息，请参阅将内部虚拟网络中的 API 管理与应用程序网关集成。
组织可能决定在本地托管其 API。 做出这种改变的可能原因之一是，组织无法将此项目范围内的下游数据库依赖项转移到云中。 如果是这样，组织仍然可以使用自承载网关在本地利用 API 管理。
自承载网关是 API 管理网关的容器化部署，它通过出站套接字连接回到 Azure。 第一个先决条件是，如果 Azure 中没有父资源，则无法部署自承载网关，这会产生额外的费用。 其次，需要高级层 API 管理。
注意
有关将 API 管理连接到虚拟网络的一般信息，请参阅此文。
方案详细信息
一家旅游行业的电子商务公司正在现代化其旧式基于浏览器的软件堆栈。 尽管其现有堆栈基本上是整体化的，但最近某个项目中采用了一些基于 SOAP 的 HTTP 服务。 该公司正在考虑建立更多的收入流，以便将一些已开发的内部知识产权转化为收益。
项目目标包括解决技术债务、改进日常维护，以及加速功能开发并减少回归缺陷。 该项目将使用迭代过程来避免风险，同时并行执行某些步骤：
- 开发团队将现代化应用程序后端，该后端由 VM 上托管的关系数据库组成。
- 内部开发团队将编写要通过新 HTTP API 公开的新业务功能。
- 合同开发团队将生成一个要托管在 Azure 中的基于浏览器的新 UI。
新应用程序功能分阶段交付。 这些功能将逐渐替代现有的、目前为该公司电子商务业务提供动力的基于浏览器的客户端-服务器 UI 功能（托管在本地）。
管理团队成员不希望进行不必要的现代化。 此外，他们希望能够保持控制项目范围和成本。 为此，他们决定保留现有的 SOAP HTTP 服务。 他们还希望能够尽量减少对现有 UI 做出的更改。 他们可以使用 Azure API 管理，解决该项目的许多要求和约束。
可能的用例
此场景重点介绍如何让旧式基于浏览器的软件堆栈实现现代化。
你可以通过此场景来实现以下目的：
- 了解你的企业能够如何通过利用 Azure 生态系统获益。
- 计划如何将服务迁移到 Azure。
- 了解迁移到 Azure 会对现有 API 产生怎样的影响。
注意事项
这些注意事项实现 Azure 架构良好的框架的支柱原则，即一套可改进工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可用性和可伸缩性
- 可以通过选择定价层，然后添加单元，来横向扩展 Azure API 管理。
- 也可以使用自动缩放来实现缩放。
- 跨多个区域部署可以实现故障转移，在高级层中可以执行此操作。
- 考虑与 Azure Application Insights 集成，这样还可以通过 Azure Monitor 公开指标用于监视。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
以下四个层中提供了 API 管理：开发人员、基本、标准和高级。 在 Azure API 管理定价指导中，可以找到有关这些层的差异的详细指导。
可以通过添加和删除单元来缩放 API 管理。 每个单元的容量取决于其所在的层。
注意
可以使用开发人员层来评估 API 管理功能。 请勿将其用于生产环境。
若要查看预计成本并根据部署需求进行自定义，可在 Azure 定价计算器中修改缩放单元和应用服务实例的数目。
部署此方案
若要开始，请在门户中创建一个 Azure API 管理实例。
或者，可以从符合具体用例的现有 Azure 资源管理器快速入门模板中进行选择。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Ben Gimblett | 高级客户工程师
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
产品文档：
Learn 模块：