本引用体系结构使用 Azure Integration Services 来协调对企业后端系统的调用。 后端系统可包括服务型软件 (SaaS) 系统、Azure 服务以及企业中现有的 Web 服务。
体系结构
下载此体系结构的 Visio 文件。
工作流
后端系统。 上图的右侧显示企业部署的或依赖的各种后端系统。 这些系统可能包括 SaaS 系统、其他 Azure 服务或公开 REST 或 SOAP 终结点的 Web 服务。
Azure 逻辑应用。 在本体系结构中，逻辑应用由 HTTP 请求触发。 也可嵌套工作流，以便实现更复杂的业务流程。 逻辑应用使用连接器与常用的服务集成。 逻辑应用提供数百个连接器，但你可以创建自定义连接器。
Azure API 管理。 API 管理包含两个相关的组件：
API 网关。 API 网关接受 HTTP 调用并将其路由到后端。
开发人员门户。 Azure API 管理的每个实例都可以访问开发人员门户。 开发人员可以通过此门户访问有关 API 调用的文档和代码示例。 还可以在开发人员门户中测试 API。
Azure DNS。 Azure DNS 使用 Azure 基础结构提供名称解析。 通过在 Azure 中托管域，可以使用与其他 Azure 服务相同的凭据、API、工具和计费来管理 DNS 记录。 若要使用自定义域名（例如 contoso.com），请创建可将自定义域名映射到 IP 地址的 DNS 记录。 有关详细信息，请参阅在 API 管理中配置自定义域名。
Microsoft Entra ID。 使用 Microsoft Entra ID 对调用 API 网关的客户端进行身份验证。 Microsoft Entra ID 支持 OpenID Connect (OIDC) 协议。 客户端从 Microsoft Entra ID 获取访问令牌，API 网关在验证令牌后对请求授权。 如果使用 API 管理的标准层或高级层，Microsoft Entra ID 也可协助保护开发人员门户的访问安全性。
组件
- Integration Services 是一组服务，可用于集成应用、数据和进程。
- 逻辑应用是一种用于生成企业工作流的无服务器平台，企业工作流可集成应用程序、数据和服务。
- API 管理是用于发布 HTTP API 目录的托管服务。 可以使用它来提升 API 的可重用性和可发现性，并部署 API 网关来代理 API 请求。
- Azure DNS 是 DNS 域的托管服务。
- Microsoft Entra ID 是 Microsoft 推出的基于云的标识和访问管理服务。 企业员工可以使用 Microsoft Entra ID 访问外部和内部资源。
方案详细信息
Integration Services 是一组服务，可以使用这些服务为企业集成应用、数据和进程。 本体系结构使用这其中的两种服务：用于协调工作流的逻辑应用，以及用于创建 API 目录的 API 管理。
在本体系结构中，可以通过导入逻辑应用作为 API 来生成复合 API。 也可导入现有的 Web 服务，方法是导入 OpenAPI (Swagger) 规范或从 WSDL 规范导入 SOAP API。
API 网关用于将前端客户端与后端分离。 例如，它可以重新编写 URL 或在请求抵达后端之前转换请求。 它还处理许多跨领域问题，例如身份验证、跨域资源共享 (CORS) 支持以及响应缓存。
可能的用例
此体系结构对于基本集成方案已足够，其中工作流由对后端服务的同步调用触发。 使用队列和事件的更复杂体系结构基于这个基本的体系结构而构建。
建议
你的具体要求可能与此处显示的通用体系结构不同。 请使用本部分中的建议作为入手点。
API 管理
使用 API 管理基本层、标准层或高级层。 这些层提供生产服务级别协议 (SLA)，并支持 Azure 区域中的横向扩展。 API 管理的吞吐量容量以单位来度量。 每个定价层都有一个最大横向扩展。高级层还支持跨多个 Azure 区域横向扩展。 请根据功能集和所需的吞吐量级别选择层。 有关详细信息，请参阅 API 管理定价和 Azure API 管理实例的容量。
每个 Azure API 管理实例都有一个默认的域名，它是 azure-api.net 的子域，例如 contoso.azure-api.net。 考虑为组织配置自定义域。
逻辑应用
如果不需要保证较低的延迟进行响应，则非常适合使用逻辑应用，例如执行异步操作，或者运行时间适中的 API 调用。 如果需要保证低延迟（例如，在调用会导致用户界面停滞的情况下），请使用其他技术。 例如，使用 Azure Functions 或部署到 Azure 应用服务的 Web API。 对于 API 使用者，请优先 API 管理而不是 API。
Region
若要尽量降低网络延迟，可将 API 管理和逻辑应用置于同一区域。 一般情况下，请选择离用户最近（或离后端服务最近）的区域。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
查看每个服务的 SLA：
如果在使用高级层时跨至少两个区域来部署 API 管理，则有资格获得更高的 SLA。 请参阅 API 管理定价。
备份
定期备份 API 管理配置。 将备份文件存储在不同于服务部署区域的某个位置或 Azure 区域。 根据 RTO 选择灾难恢复策略：
在灾难恢复事件中，预配新的 API 管理实例，将备份还原到新实例，并重新指向 DNS 记录。
在另一 Azure 区域中保留 API 管理服务的被动实例。 定期将备份还原到该实例，使之与主动服务同步。 若要在发生灾难恢复事件期间还原服务，只需重新指向 DNS 记录。 此方法会产生额外的成本，因为需为被动实例付费，但它会减少恢复时间。
对于逻辑应用，建议使用配置即代码方法进行备份和还原。 由于逻辑应用无服务器，因此可以通过 Azure 资源管理器模板快速地重新创建它们。 请将模板保存在源代码管理中，并将模板与持续集成/持续部署 (CI/CD) 过程相集成。 在灾难恢复事件中，请将模板部署到新区域。
如果将逻辑应用部署到另一区域，请在 API 管理中更新配置。 可以使用一个基本的 PowerShell 脚本来更新 API 的后端属性。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
下面是一些针对本体系结构的安全注意事项，虽然此列表并未完整描述所有的安全最佳做法：
Azure API 管理服务具有固定的公共 IP 地址。 只有 API 管理的 IP 地址能调用逻辑应用终结点。 有关详细信息，请参阅限制入站 IP 地址。
为了确保用户拥有适当的访问级别，请使用 Azure 基于角色的访问控制 (Azure RBAC)。
使用 OAuth 或 OpenID Connect 保护 API 管理中的公共 API 终结点。 若要保护公共 API 终结点，请配置标识提供者并添加 JSON Web 令牌 (JWT) 验证策略。 有关详细信息，请参阅结合 Microsoft Entra ID 和 API 管理使用 OAuth 2.0 保护 API。
使用相互身份验证证书从 API 管理连接到后端服务。
在 API 管理 API 上强制实施 HTTPS。
存储机密
切勿将密码、访问密钥或连接字符串签入源代码管理。 如果需要这些值，请使用适当的技术保护和部署这些值。
如果逻辑应用所需的任何敏感值不能在连接器中创建，请将这些值存储在 Azure Key Vault 中，并从资源管理器模板引用它们。 请为每个环境使用部署模板参数和参数文件。 有关详细信息，请参阅保护工作流中的参数和输入。
API 管理使用称作“命名值”或“属性”的对象管理机密。 这些对象安全地存储可通过 API 管理策略访问的值。 有关详细信息，请参阅如何在 Azure API 管理策略中使用命名值。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅卓越运营支柱概述。
DevOps
为生产、开发和测试环境创建单独的资源组。 使用单独的资源组可以更方便地管理部署、删除测试部署，以及分配访问权限。
将资源分配到资源组时，请考虑以下因素：
生命周期。 一般情况下，应将具有相同生命周期的资源放入同一个资源组。
访问。 若要对组中的资源应用访问策略，可使用 Azure 基于角色的访问控制 (Azure RBAC)。
计费。 可以查看资源组的累计成本。
API 管理的定价层。 对开发和测试环境使用开发人员层。 为了尽量降低预生产期间的成本，请部署生产环境的副本、运行测试，然后关闭。
部署
使用 Azure 资源管理器模板部署 Azure 资源，按照基础结构即代码 (IaC) 流程进行操作。 通过模板，可更轻松地使用 Azure DevOps Services 或其他 CI/CD 解决方案自动执行部署。
过渡
请考虑为工作负载划分阶段，这意味着需要向各个阶段进行部署，并且需要在每个阶段运行验证，然后才能进入下一阶段。 如果使用此方法，就能以高度受控的方式将更新推送到生产环境，并最大程度地减少意外的部署问题。 建议使用蓝绿部署和 Canary 版本部署策略来更新实时生产环境。 还要考虑在部署失败时采用良好的回滚策略。 例如，可以自动重新部署部署历史记录中先前成功的部署。 Azure CLI 中 的 --rollback-on-error flag 参数就是很好的例子。
工作负荷隔离
将 API 管理和任何单个逻辑应用放在其自身独立的资源管理器模板中。 使用独立的模板可将资源存储在源代码管理系统中。 可以在 CI/CD 过程中统一或者逐个部署这些模板。
版本
每当更改逻辑应用的配置或者通过资源管理器模板部署更新时，Azure 都会保留该版本的副本，并保留具有运行历史记录的所有版本。 可以使用这些版本来跟踪历史更改，或者将某个版本提升为逻辑应用的当前配置。 例如，可以将逻辑应用回退到以前的版本。
API 管理支持两个不同但互补的版本控制概念：
版本：API 使用者可以根据需要选择 API 版本（例如 v1、v2、beta 或 production）。
修订版允许 API 管理员在 API 中进行非重大更改，并部署这些更改，同时提供更改日志以通知 API 使用者有关更改的信息。
可在开发环境中创建修订版，并使用资源管理器模板在其他环境中部署此项更改。 有关详细信息，请参阅发布 API 的多个版本
也可在将某个 API 指定为“当前”版本并提供给用户访问之前，使用修订版来测试该 API。 但是，建议不要使用此方法进行负载测试或集成测试。 请改用独立的测试环境或预生产环境。
诊断和监控
在 API 管理和逻辑应用中使用 Azure Monitor 进行操作监视。 Azure Monitor 根据为每个服务配置的指标提供信息，默认已启用。 有关详细信息，请参阅：
每个服务还提供以下选项：
若要进行更深入的分析和仪表板显示，请将逻辑应用日志发送到 Azure Log Analytics。
若要进行 DevOps 监视，请为 API 管理配置 Azure Application Insights。
API 管理支持使用 Power BI 解决方案模板进行自定义 API 分析。 可以使用此解决方案模板来创建自己的分析解决方案。 业务用户可在 Power BI 中查看报表。
性能效率
性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率要素概述。
为了提高 API 管理的可伸缩性，请添加缓存策略（如果适用）。 缓存还有助于减少后端服务的负载。
若要提高容量，可在 Azure 区域中横向扩展 Azure API 管理基本层、标准层和高级层。 要分析服务的使用情况，请在“指标”菜单上选择“容量指标”，然后根据需要扩展或缩减。 升级或缩放过程可能需要 15 到 45 分钟才能完成。
有关缩放 API 管理服务的建议：
缩放时请考虑流量模式。 采用较高易失性流量模式的客户需要更多的容量。
如果容量一贯超过 66%，则可能表示需要纵向扩展。
如果容量一贯低于 20%，则可能表示能够缩减。
在生产环境中启用负载之前，请始终使用有代表性的负载对 API 管理服务进行负载测试。
使用高级层时，可以跨多个 Azure 区域缩放 API 管理实例。 这样可以让 API 管理有资格获得更高的 SLA，并让你可以在多个区域靠近用户的位置预配服务。
逻辑应用的无服务器模型意味着管理员无需规划服务可伸缩性。 服务会根据需求自动缩放。
成本优化
通常，使用 Azure 定价计算器来估算成本。 下面是一些其他注意事项。
API 管理
需要对所有运行的 API 管理实例付费。 如果已纵向扩展，但始终不需要该性能级别，请手动进行纵向缩减，或者配置自动缩放。
逻辑应用
逻辑应用使用无服务器模型。 根据操作和连接器执行计算费用。 有关详细信息，请参阅逻辑应用定价。
有关详细信息，请参阅 Microsoft Azure 架构良好的框架中的“成本”部分。
后续步骤
相关资源
若要提高可靠性和可伸缩性，请使用消息队列和事件将后端系统分离。 此体系结构将在本系列的下一篇文章中进行介绍：
可能还对 Azure 体系结构中心的这些文章感兴趣：