从 gRPC 到 RESTful API：向世界其他地方公开你的 gRPC 服务

在设计现代微服务架构时，性能显然是关键。即使在高频交易和近实时系统之外，服务间通信中的额外几毫秒对整体用户体验也至关重要。在这种环境下，gRPC已成为一种高性能通信协议，并因其低延迟、高效序列化和强类型消息而被广泛采用。

另一方面，我们需要承认，大多数跨系统边界的服务间通信仍然严重依赖 HTTP API。这是因为 API 在很大程度上充当了 API 生产者和消费者之间的解耦实体之间的契约，而将它们更改为 gRPC 会带来很多摩擦。此外，并非所有开发人员都具备使用 gRPC 服务的能力或经验。因此，如果 API 提供商仅限于公开 gRPC 服务，他们可能会失去潜在的受众。

在本篇博文中，我们将演示如何轻松弥合高性能 gRPC 服务与广泛采用的 RESTful HTTP API 生态系统之间的差距。我们提出了一种解决方案，利用自动生成的 gRPC 网关，该网关可以与现有 gRPC 服务一起部署，以处理将提供 HTTP 接口的协议转换。最后，我们引入了Apigee作为企业 API 管理平台，以安全和自助的方式公开干净的 RESTful API 外观。

gRPC 到 HTTP 网关

假设一家运营电子商务网站的虚构公司在运营过程中意识到，部分组件可以自行提供价值，并纳入其战略性API 经济工作。我们的示例基于一个示例微服务架构，该架构由一系列用不同编程语言编写的子组件组成。他们想要探索加入其 API 平台的第一个服务是货币服务。它提供了两种 gRPC 方法，可让客户端列出支持的货币并执行从一种货币到另一种货币的货币转换。

如介绍中所述，gRPC 服务是内部或所谓的“东西向” 服务到服务通信的热门选择。虽然 gRPC 表现出卓越的性能特征，但目前大量 API 使用 HTTP 作为其主要通信协议。将这些 API 迁移到 gRPC 需要大量资源投入，尤其是考虑到并非所有开发人员都熟悉 gRPC 框架。

为了克服这一挑战，我们希望提供一个适配器层，为服务提供更传统的基于 JSON HTTP 的 API。我们决定使用开源gRPC 网关项目自动为我们的用例生成适配器，而不是自己手动编写协议转换。网关基于指定服务和消息的.proto 文件。它是服务生产者和消费者之间的唯一真实来源（或契约）。为了简化网关的生成，我们创建了一个便利包装器，允许我们通过向其提供对 .proto 文件的引用来生成网关。./generate-gateway.sh –proto-path ./examples/currency.proto

上述命令解析提供的 .proto 文件并生成 go 模块，用于将传入的 HTTP REST 请求转换为 gRPC 并将其发送到指定的端点。最后，它将网关包装在可以独立部署的 go 模块中。

对于最终的架构，我们需要构建一个容器映像并部署到目标运行时（例如Cloud Run）。要了解网关的工作原理，我们还可以在本地运行它：(cd generated/gateway && docker build . -t gateway:latest)docker run -p 8080:8080 -e GRPC_SERVER_ENDPOINT=localhost:9090 gateway:latest

此处的环境变量GRPC_SERVER_ENDPOINT 指向网关应向其发送流量的 gRPC 端点。在本例中，我们已经在端口 9090 上本地运行了 gRPC货币服务。网关启动后，您现在可以向网关的端点发送常规 JSON HTTP 请求：curl -X POST localhost:8080/hipstershop.CurrencyService/Convert -d ‘{“from”: {“units”: 3, “currency_code”: “USD”, “nanos”: 0}, “to_code”: “CHF”}’

如我们所见，我们已将 gRPC 货币服务作为 JSON HTTP API 提供，以便在更广泛的 API 生态系统中更轻松地使用。但是，当我们考虑这个新 API 如何与公司完善的 API 策略保持一致时，仍有改进空间：

• 该 API 不遵循被广泛接受的 RESTful API 设计原则，并且仍然很大程度上反映了原始 .proto 规范的结构。
• 该 API 不支持 API 管理功能，例如身份验证、集中日志记录和监控、错误处理或货币化。
• 开发人员无法使用自助服务选项来发现新的 API 并将自己作为 API 消费者加入。

通过 API 管理降低进入门槛

为了实现其中一些功能并最终推动 API 的采用，我们可以利用 Apigee API 代理外观形式的 API 管理层。虽然 Apigee 可以在直通模式下本机公开 gRPC 服务，但在这里我们在之前转换的协议上进行操作，该协议允许我们应用一系列有用的策略和配置：

• 方法、路径和有效负载转换使我们能够提供适当的 RESTful 外观并抽象​​ gRPC 的底层消息格式
• 收集指标和丰富的分析数据来衡量 API 程序的运行性能和成功
• 一致的 API 安全性、错误处理和流量管理控制，以保护其他系统并对客户端施加配额

为了在我们的 gRPC 网关之上进行构建，我们首先需要 API 代理来安全地访问我们的 gRPC 网关，该网关可以部署到 Cloud Run，在那里可以使用 Cloud IAM 强制执行身份验证。使用此安全机制，我们的 API 代理必须配置为使用 Google Cloud 身份验证本身，或转发从 API 客户端收到的凭据。

Apigee使用 API 代理管理路由的灵活而全面的方法使我们能够向 API 使用者公开 RESTful 路径，并在运行时将路径重写为我们的 gRPC 网关所期望的路径。curl -X POST “https://$APIGEE_HOSTNAME/currency/v1/convert” -d ‘{“from”: {“units”: 3, “currency_code”: “USD”, “nanos”: 0}, “to_code”: “CHF”}’

通过 Apigee API 代理代理我们的货币服务可以自动收集 API指标和分析数据，从而为我们提供有关 API 运行状况和成功的丰富见解。我们还可以通过附加额外的流量管理、安全、中介甚至代码扩展策略来构建我们的 API 代理。

为了向新受众介绍和推广此 API，我们可以利用Apigee 的开发者门户发布API 产品，供开发者发现、探索和试验 API，从而开辟新的机会。在此基础上，我们可以选择通过各种不同的策略（例如基于使用量的定价或订阅计划）将 API 产品货币化，以解锁更多收入来源。

结论和后续步骤

总之，我们展示了如何将 gRPC 服务作为 HTTP API 轻松展示给新受众，同时还能利用 Apigee 等综合 API 管理平台的优势。通过将 gRPC 的性能与 REST API 的熟悉度和工具相结合，我们可以为我们的服务和数据解锁新的可能性，从而覆盖更广泛的开发人员和应用程序。通过采用这种混合方法，我们可以在构建 API 生态系统时弥合 gRPC 和 REST 之间的差距，这样您就可以充分利用两全其美的优势。

文章来源：From gRPC to RESTful APIs: Expose your gRPC services to the REST of the world