在此场景中，一家从事旅游业的电子商务公司通过使用 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 应用程序将依赖于 Azure API 管理实例来使用现有的 HTTP API 和新的 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 架构良好的框架的支柱原则，即一套可改进工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。
- 请考虑在已启用可用性区域的情况下部署 Azure API 管理实例。 将 API 管理部署到可用性区域的选项仅在高级服务层级中可用。
- 可用性区域可以与部署到不同区域的其他网关实例一起使用。 如果一个区域脱机，这将提高服务可用性。 多区域部署也仅在高级服务层级中可用。
- 考虑与 Azure Application Insights 集成，这样还可以通过 Azure Monitor 公开指标用于监视。 例如，容量指标可用于确定 API 管理资源的总体负载，以及是否需要额外横向扩展单位。 跟踪资源容量和运行状况可提高可靠性。
- 确保下游依赖项（例如，托管 API 管理外观的 API 的后端服务）也具有复原能力。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。
以下四个层中提供了 API 管理：开发人员、基本、标准和高级。 在 Azure API 管理定价指导中，可以找到有关这些层的差异的详细指导。
可以通过添加和删除单元来缩放 API 管理。 每个单元的容量取决于其所在的层。
注意
可以使用开发人员层来评估 API 管理功能。 请勿将其用于生产环境。
若要查看预计成本并根据部署需求进行自定义，可在 Azure 定价计算器中修改缩放单元和应用程序服务实例的数目。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Ben Gimblett | 高级客户工程师
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。
后续步骤
产品文档：
Learn 模块：