我们很高兴地宣布推出 Apigee Extension Processor 的正式版 (GA)（版本 1.0）！这一强大的新功能大幅提高了 Apigee 的覆盖范围和灵活性，使管理和保护更广泛的后端服务及现代应用架构变得前所未有的轻松。
由于 Extension Processor 可以与 Cloud Run 无缝集成，因而采用现代部署模型的开发者可以将 Apigee 策略应用至可扩展的容器化应用。
Extension Processor 还提供强大的新通信模式。现在，您可以轻松利用 gRPC 双向流式传输管理高级实时交互，从而开发具有高度交互和低延迟的应用。此外，对于事件驱动型架构，Extension Processor 提供了管理和保护服务器发送事件 (SSE) 的途径，从而提高向客户端传输数据流的效率。
但好处远不止应用部署和通信协议。Apigee Extension Processor 与 Google 令牌注入策略相结合可以大大简化对 Google Cloud 基础设施的安全访问。您可以无缝连接和控制对 Bigtable 等强大数据服务的访问，利用 Vertex AI 的智能功能来处理机器学习工作负载，同时保持 Apigee 安全框架的一致性。
最后，通过与 Google Cloud Load Balancing 的智能流量管理功能集成，Extension Processor 在路由和管理各种流量流方面具有前所未有的灵活性。这种强大的组合为管理最复杂的 API 环境开辟了无限的可能性。
这篇博客概述了一种强大的解决方案，可应对当今高性能和实时应用领域的关键挑战：在 Apigee 中管理 gRPC 流式传输。虽然 gRPC 是高效微服务的基石，但其流式传输特性给利用 Google Cloud 的 Apigee 作为内联代理（传统模式）的组织带来了挑战。我们将探讨在 gRPC 流式传输流量流经应用负载均衡器 (ALB) 时，Apigee Extension Processor 如何使 Apigee 的数据平面能够对其实施策略。这是通过服务扩展（流量扩展）实现的，因而无需 gRPC 流直接遍历 Apigee 网关即可实现有效的管理和路由。
请继续阅读，我们将深入探讨此解决方案的核心元素，重点介绍其优势，并简要概述涉及 Cloud Run 后端的实际用例。
Apigee Extension Processor 是一款强大的流量扩展（一种服务扩展）工具，可让您利用 Cloud Load Balancing 将标注发送至 Apigee 作为其 API 管理的一部分。如此一来，在 ALB 将 API 管理策略转发给用户管理的后端服务之前，Apigee 便可以将这些策略运用至请求，从而有效地将 Apigee 的强大 API 管理功能延伸至由 Cloud Load Balancing 处理的工作负载。
该图概述了 Apigee Extension Processor 配置所需的组件：
Apigee Extension Processor 配置涉及几个关键组件，包括 ALB、已启用 Extension Processor 的 Apigee 实例、服务扩展。有关这些组件的详细说明，请参阅 Apigee Extension Processor 概述。
以下带编号的步骤对应于流程图中带编号的箭头，表示事件的顺序：
1：客户端向 ALB 发送请求
2：充当策略执行点 (PEP) 的 ALB 会处理流量。在处理过程中，ALB 会通过配置的服务扩展（流量扩展）调用 Apigee。
3：充当策略决策点 (PDP) 的 Apigee Extension Processor 会接收标注，将相关的 API 管理策略应用至请求，并将已处理的请求返回给 ALB (PEP)。
4：ALB 完成处理并将请求转发给后端服务。
后端服务会发起响应以供 ALB 接收。ALB 可以通过服务扩展再次调用 Apigee，在对响应执行策略之后再将其转发给客户端。
许多现代应用需要并使用流式 gRPC 的强大功能，但 Apigee（用作内联代理）目前不支持进行流式传输。这正是 Apigee Extension Processor 体现出巨大价值的方面，允许 ALB 处理流式 gRPC 流量并充当 PEP（策略执行点），同时允许 Apigee 运行时充当 PDP（策略决策点）。
为了通过 Apigee Extension Processor 启用 gRPC 流式传输功能，您需要使用以下关键元素。有关详细的配置说明，请参阅开始使用 Apigee Extension Processor。
假设这样一个场景，客户利用 gRPC 流式传输功能（例如提供事实应用日志）来开发高性能的后端服务。为了实现可扩展性和易管理性，客户将此后端应用部署在其主要 Google Cloud 项目的 Google Cloud Run 上。现在，客户希望通过管理良好且安全的 API 网关向客户展示此 gRPC 流式传输服务。为此，他们选择使用 Apigee，以利用其强大的 API 管理功能，如身份验证、授权、速率限制和其他策略。
如前所述，在内联代理模式下，Apigee 原生不支持 gRPC 流式传输。通过标准 Apigee 配置直接提供 Cloud Run gRPC 服务这种方法不支持任何流式传输用例：客户端、服务器或双向流式传输。
Apigee Extension Processor 起着必要的衔接作用，适用于管理流向后端应用（部署在同一 Google Cloud 项目的 Cloud Run 上）的 gRPC 流式传输流量。
以下是简版流程：
注意： 此场景中，Apigee 代理是未配置目标端点的无目标代理，依靠 ALB 进行最终路由。
响应处理须遵循与请求流类似的模式。后端发起响应，然后由 ALB 处理。ALB 可以在将响应转发给客户端之前，通过服务扩展（流量扩展）调用 Apigee 以执行策略。
这个经过简化处理的用例演示了如何使用 Apigee Extension Processor 将 API 管理策略应用至流向后端应用（部署在同一 Google Cloud 项目的 Cloud Run 上）的 gRPC 流式传输流量。ALB 主要根据其 NEG 配置处理路由到 Cloud Run 服务的流量。
利用 Apigee Extension Processor 在后端管理 gRPC 流式传输服务有几个关键优势，可将 Apigee 的核心优势扩展到这一新的平台应用：
此方法成功地将 Apigee 强大的 API 管理功能扩展到 gRPC 流式传输，这是 Apigee 平台的核心代理原生不支持的流通信模式。
对于已经将 Apigee 用于其 RESTful API 的组织，此解决方案使其能够在 Apigee 中管理其 gRPC 流式传输服务。在要求使用 Extension Processor 的同时，它利用了熟悉的 API 管理概念，并减少了对单独工具的需求。
Apigee 为定义和实施 API 管理策略提供了一个集中的平台。通过 Extension Processor 集成 gRPC 流式传输功能，您可以在所有 API 端点上保持一致的治理和安全水平。
如果您将 gRPC 流式传输服务作为产品公开，则可以利用 Apigee 的变现功能。在您为您在 Apigee 中创建的自定义 API 产品设置价目表后，每当有人使用 gRPC 流式传输 API，您都能有获得收益。
虽然在传输场景中，详细的 gRPC 协议级分析可能会受到限制，但 Apigee 仍然可以提供有关流向流式传输服务的流量的宝贵见解，包括连接尝试、错误率和整体使用模式。这种可观测性对于监控和问题排查至关重要。
Apigee 的分布式跟踪系统可帮助您跟踪分布式系统中涉及 gRPC 流式传输服务的请求，并提供跨多个应用、服务和数据库的端到端可见性。
Apigee API Analytics 收集流经负载均衡器的大量信息，并在界面中提供数据可视化或下载数据进行离线分析的功能。这些数据对于了解使用模式、识别性能瓶颈和做出明智的业务决策非常宝贵。
考虑到这些好处，很明显，Apigee Extension Processor 是一种有价值且实用的解决方案，可以为 Google Cloud 上的 gRPC 流式传输服务带来必要的 API 管理功能。
Apigee Extension Processor 代表了我们在扩展 Apigee 功能方面向前迈出的重要一步。我们的设想是，在未来，任何地方的任何网关都可以利用 Apigee 的策略执行功能。这将涉及利用 ext-proc 协议并与各种基于 Envoy 的负载均衡器和网关集成，使其能够充当策略执行点 (PEP)，以及使 Apigee 运行时充当策略决策点 (PDP)。这种演变将进一步使组织能够在日益分散和异构的环境中，以一致的方式管理和保护其数字资产。
