你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用网关可将多个单独请求聚合成一个请求。 当客户端必须对不同的后端系统进行多次调用才能执行操作时，此模式非常有用。
上下文和问题
若要执行单个任务，客户端可能需要对各种后端服务进行多次调用。 依赖多个服务来执行任务的应用程序必须为每个请求消耗资源。 将新功能或服务添加到应用程序时，需要额外的请求，从而进一步提高资源要求和网络调用。 客户端与后端之间的这种聊天可能会对应用程序的性能和规模产生不利影响。 微服务体系结构使得此问题更加常见，因为围绕许多较小的服务构建的应用程序具有更多的跨服务调用。
在下图中，客户端向每个服务发送请求（编号为 1、2 和 3）。 每个服务处理请求并返回对应用程序的响应（编号为 4、5 和 6）。 以这种方式通过具有高延迟的手机网络发送单个请求效率低下，并可能导致连接丢失或响应不完整。 每个请求可能并行运行。 但是，应用程序仍必须在单独的连接上发送、等待和处理每个请求的数据，这会增加失败的可能性。
解决方案
使用网关减少客户端与服务之间的频繁通信。 网关接收客户端请求，将请求调度到各种后端系统，并在结果发送回客户端之前聚合结果。
此模式可以减少应用程序对后端服务发出的请求数，并提高高延迟网络的应用程序性能。
在下图中，应用程序向网关发送一个请求 (1)。 请求包含一组额外的请求。 网关通过将其发送到相关服务（2）来分解这些请求并处理每个请求。 每个服务向网关返回响应 (3)。 网关组合来自每个服务的响应，并向应用程序发送响应 (4)。 应用程序发出单个请求，并仅接收来自网关的单个响应。
问题和注意事项
在决定如何实现此模式时，请考虑以下几点：
网关不应在后端服务中引入服务耦合。
网关应位于后端服务附近，以尽可能减少延迟。
网关服务可能引入单一故障点（SPoF）。 确保网关设计正确，以满足应用程序的可用性要求。
网关可能会带来瓶颈。 确保网关具有足够的性能来处理当前负载，并且可以进行缩放以满足预期增长。
对网关执行负载测试，以确保不会为服务引入级联故障。
如果一个或多个服务调用耗时过长，那么通过超时处理并仅返回部分数据可能是可以接受的。 请考虑应用程序处理这种情况的方式。
使用异步输入和输出（I/O）来确保后端的延迟不会在应用程序中导致性能问题。
通过使用关联 ID 跟踪每次单独调用来实现分布式跟踪。
监视请求指标和响应大小。
考虑返回缓存的数据（作为故障转移策略）来处理故障。
与其将聚合功能集成到网关中，不如考虑将聚合服务置于网关后端。 请求聚合可能具有与网关中的其他服务不同的资源要求，可能会影响网关的路由和卸载功能。
何时使用此模式
在以下情况下使用此模式：
客户端需要与多个后端服务通信才能执行操作。
客户端可能会使用具有显著延迟的网络，例如手机网络。
在以下情况下，此模式可能不适用：
在执行多个不同的操作时，希望减少客户端与单个服务之间的调用次数。 在这种情况下，向服务添加批处理操作可能更合适。
客户端或应用程序位于后端服务附近，延迟不是一个重要因素。
工作负载设计
评估如何在工作负荷的设计中使用网关聚合模式来解决Azure Well-Architected框架支柱中涵盖的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 可靠性 设计决策有助于工作负荷在发生故障后 复原 ，并确保它在发生故障后 恢复到 正常运行状态。 | 使用此拓扑，可以将暂时性故障处理从跨客户端的分布式实现转移到集中式实现。 - 处理暂时性故障的建议 |
| 安全设计决策有助于确保工作负荷数据和系统的机密性、完整性和可用性。 | 这种拓扑通常会减少客户端与系统之间的交互接触点数量，从而减少公开暴露面和身份验证点。 聚合后的后端可以保持与客户端完全网络隔离。 - SE:04 分段 - SE：08 强化资源 |
| 卓越运营有助于通过标准化流程和团队凝聚力来实现工作负荷质量。 | 此模式使后端逻辑能够独立于客户端发展。 这种分离使你可以灵活地更改链接的服务实现，甚至数据源，而无需更改客户端接触点。 - OE:04 工具和流程 |
| 通过缩放、数据和代码的优化，性能效率可帮助工作负荷高效地满足需求。 | 与客户端建立多个连接的设计相比，此设计造成的延迟更少。 聚合实现中的缓存可最大程度地减少对后端系统的调用。 - PE：03 选择服务 - PE:08 数据性能 |
如果此模式在某个支柱中引入权衡取舍，请将它们与其他支柱的目标进行对比。
Example
请考虑基于微服务的应用程序，它为客户提供订单摘要体验。 当用户打开订单页时，应用程序必须从多个后端服务（例如订单服务、发货服务和客户配置文件服务）检索数据。
在微服务体系结构中，这些服务是独立实现和部署的。 如果没有聚合，客户端必须直接调用每个服务，这会增加延迟和复杂性。
为了解决此问题，应用程序使用 Azure API 管理 作为网关聚合层。 客户端向充当订单信息的收集器的 API 管理操作发送单个请求。 然后，API 管理会调用支持的后端 API，并向客户端返回统一响应。
可以使用 API 管理发送请求策略从多个服务检索数据并构造组合响应来实现此轻型组合。 在此示例中，后端服务在 Azure 容器应用 环境中运行，并将每个后端服务部署为一个容器应用，该应用在直接客户端访问中保持隐藏状态。
下载此体系结构的 Visio 文件。
请求流遵循以下步骤：
客户端向通过 API 管理公开的订单摘要终结点发送请求。
API 管理应用从后端服务收集订单、发货和客户配置文件数据的策略。
API Management 将后端响应整合为单个订单摘要负载。
API 管理将聚合响应返回到客户端。
通过引入此聚合层，解决方案可减少客户端到服务的往返，并简化客户端交互。 此层负责妥善处理无响应的后端服务，并防止故障在聚合响应中级联扩散。 使用按请求超时、条件错误处理和 断路器强化 API 管理策略。
如果某个后端调用超时或返回错误，API 管理可以应用最适合操作的行为。 例如，当缺少数据可接受时，它可能会返回部分响应，或者当需要完整且一致的订单数据时，它可能会失败整个请求。 在策略设计中明确此决策，使客户端体验可预测的行为。
当网关执行轻量级组合、格式调整和响应组装时，这种方法效果很好。 如果聚合需要自定义域逻辑、复杂转换或运行时间较长的业务流程，请将该功能放在网关后面的专用自定义服务中。
若要监视，请跨完整请求路径收集遥测数据，以便可以将 API 管理行为与后端延迟相关联。 此可见性在网关聚合模式中非常重要，因为单个客户端操作依赖于多个后端调用，并且任何依赖项中的失败或响应速度缓慢都可能会影响最终聚合结果。 使用 Azure Monitor 作为中心可观测性平台。 为网关和策略执行路径收集 API 管理日志和指标，并启用 对容器应用的监视 ，以便从后端容器应用捕获应用程序日志和指标。 将 API 管理和后端遥测路由到 Log Analytics 工作区，以便进行统一的查询、警报和故障排除。 借助这些遥测数据，您可以检测超时模式，确定是哪个后端依赖项导致响应不完整或失败，并针对延迟或错误率升高创建警报。