简介
gRPC 是一个高性能、开源的通用 RPC 框架，它使用 HTTP/2 作为传输协议，Protocol Buffers 作为序列化工具，并支持流处理和多路复用。由于其速度和效率，它在微服务和云原生架构中获得了广泛的关注。
随着越来越多的组织采用 gRPC 进行服务间通信，API 网关必须不断演进以有效处理 gRPC 请求。本文将探讨现代 API 网关如何处理、路由和管理 gRPC 流量，它们面临哪些挑战，以及开发人员应遵循哪些最佳实践。
理解 gRPC 基础
在深入探讨 API 网关如何支持 gRPC 之前，让我们简要回顾一下 gRPC 的独特之处：
- 协议：gRPC 使用 HTTP/2，允许在单个连接上进行多路复用流。
- 消息格式：gRPC 不使用 JSON，而是使用 Protocol Buffers（protobuf），这是一种紧凑且高效的二进制格式。
- 流处理：gRPC 支持客户端、服务端以及双向流处理。
- 强类型：Protobuf 强制采用模式驱动的方法，从而实现严格的契约。
这些特征与 REST API 有很大不同，并对 API 网关提出了新的要求。
为什么 API 网关需要支持 gRPC
传统上，API 网关主要关注 HTTP/1.1 和 RESTful 流量。然而，随着 gRPC 采用率的提高，API 网关必须支持 gRPC 的原因有以下几点：
- 统一流量管理：整合 REST 和 gRPC 的可观测性、限流和身份验证。
- 安全策略：应用 TLS 终止、JWT 验证和基于角色的访问控制。
- 路由逻辑：支持基于服务名、方法名或请求头进行路由。
- 协议转换：在某些情况下，在 REST 和 gRPC 之间进行转换以支持传统的客户端。
API 网关支持 gRPC 所需的核心功能
1. HTTP/2 支持
- 由于 gRPC 运行在 HTTP/2 之上，网关必须支持全双工流和连接多路复用。
- 像 Envoy、APISIX 和 Kong 这样的网关原生支持 HTTP/2 和 gRPC 透传。
2. gRPC 路由与负载均衡
- 基于 gRPC 服务/方法名路由请求。
- 基于方法粒度、后端健康状况和元数据进行负载均衡。
3. gRPC 转换
- 使用协议转换将 gRPC 转换为 REST，反之亦然。
- 对于将 gRPC 服务暴露给前端客户端或传统系统非常有用。
4. gRPC 可观测性
- 提取 gRPC 元数据（方法名、持续时间、状态码）用于日志、指标和链路追踪。
- 与 OpenTelemetry 或 Prometheus 集成。
5. 身份验证与授权
- 应用 OAuth2、JWT 和 mTLS 来保护 gRPC 流量。
- 确保访问策略在必要时可以解析 protobuf 负载。
API 网关中的原生 gRPC 请求处理
1sequenceDiagram
2 participant Client
3 participant API Gateway
4 participant gRPC Service
5 Client->>API Gateway: HTTP/2 gRPC 请求
6 API Gateway->>gRPC Service: 转发请求（不解码）
7 gRPC Service-->>API Gateway: gRPC 响应
8 API Gateway-->>Client: 转发 gRPC 响应通过 API 网关进行 gRPC-JSON 转换
1sequenceDiagram
2 participant HTTP Client
3 participant API Gateway
4 participant gRPC Service
5 HTTP Client->>API Gateway: HTTP/1.1 REST 请求 (JSON)
6 API Gateway->>gRPC Service: 转换的 gRPC 请求 (protobuf)
7 gRPC Service-->>API Gateway: gRPC 响应 (protobuf)
8 API Gateway-->>HTTP Client: 转换的 JSON 响应真实世界示例
Envoy
- 原生 gRPC 代理，支持 HTTP/2 和 gRPC-Web。
- 支持使用
:method、:authority和:path请求头的 RouteConfiguration。 - 支持通过
proto_descriptor进行 gRPC-JSON 转换。
Apache APISIX
- 通过 gRPC 代理插件支持 gRPC。
- TLS 终止、mTLS 身份验证以及使用 URI 和 host 进行路由。
- 与 Prometheus 和 SkyWalking 集成，实现 gRPC 可观测性。
Kong
- HTTP/2 和 gRPC 代理。
- 身份验证插件（如 JWT）支持带有
content-type: application/grpc的 gRPC。 - OpenTelemetry 插件支持 gRPC span。
在网关使用 gRPC 的最佳实践
- 在网关中使用原生 HTTP/2 支持，以避免兼容性问题。
- 监控 gRPC 特定的指标，例如流持续时间和方法延迟。
- 在使用 gRPC 转换时，保持 proto 描述符处于最新状态。
- 使用 mTLS 保护传输安全，特别是对于内部微服务流量。
- 考虑使用 gRPC-Web 解决浏览器兼容性问题。
挑战与注意事项
- 浏览器对 gRPC 的支持有限；gRPC-Web 缓解了这个问题。
- 由于采用二进制协议（protobuf），调试较为复杂。
- 必须针对流式工作负载调整请求头大小限制和连接复用。
- 与 REST 相比，工具和可观测性不够成熟。
结论
随着 gRPC 继续塑造微服务通信的格局，API 网关必须为该协议提供一流的支持。从处理 HTTP/2 和流，到支持协议转换和执行安全策略，现代网关在使 gRPC 实现大规模管理方面发挥着关键作用。
在为 gRPC 选择或配置 API 网关时，了解该协议的功能和网关的功能集至关重要。通过正确的设置，开发人员可以利用 gRPC 的性能优势，同时在整个服务中保持控制、安全性和可观测性。
常见问题解答
1. 什么是 gRPC，它与 REST 有何不同？
gRPC 是一个使用 HTTP/2 和 protobuf 的高性能 RPC 框架。它支持二进制消息传递、双向流和强类型，这与依赖 HTTP/1.1 和 JSON 的 REST 不同。
2. API 网关能将 REST 转换为 gRPC 吗？
是的。像 Envoy 和 APISIX 这样的网关支持 gRPC-JSON 转换，将 RESTful HTTP 请求转换为 gRPC 调用。
3. gRPC 安全吗？
gRPC 支持使用 TLS 和双向 TLS (mTLS) 进行加密和身份验证。API 网关可以实施额外的安全策略。
4. 所有的 API 网关都支持 gRPC 吗？
不是。支持情况各不相同。Envoy、Kong 和 APISIX 提供了强大的 gRPC 支持。NGINX 需要额外的配置或第三方模块。
5. 浏览器对 gRPC 的支持情况如何？
浏览器本身不支持 gRPC 所需的 HTTP/2 帧。可以使用 gRPC-Web 来弥合这一差距。