今天起,您可以在 gRPC API 端点前使用 ,我们全球内容交付网络 (CDN)。
是一种现代、有效且语言无关的API框架,用于构建 API。它使用 (protobuf) 作为
(IDL),使您能够以平台无关的方式定义服务和消息类型。通过轻量且高性能的远程过程调用 (RPC) 在 HTTP/2上实现服务之间的通信。这促进了各服务之间的高效、低延迟通信,适合微服务架构。
gRPC 提供了双向流、流量控制以及针对多种
的自动代码生成等特性。它非常适合需要高性能、高效通信和实时数据流的场景。如果您的应用需要处理大量数据或在客户端与服务器之间进行低延迟通信,gRPC是个不错的选择。然而,相较于 REST,学习 gRPC 可能更有挑战性。例如,gRPC 依赖 protobuf 序列化格式,这要求开发人员在
.proto 文件中定义数据结构和服务方法。
将 CloudFront 部署在 gRPC API 端点前的两个主要好处如下:
为演示如何使用 gRPC,我采用了 ,该示例来自 。为了方便部署,我将这个示例应用放在容器中(也可以使用其他部署选项)。
我使用以下 Dockerfile:
dockerfile FROM python:3.7 RUN pip install protobuf grpcio COPY ./grpc/examples/python/route_guide . CMD python route_guide_server.py EXPOSE50051
我还使用 将容器部署在 AmazonElastic Container Service (Amazon ECS)。Copilot命令会提示我收集构建和部署容器所需的信息。然后,它自动创建 、
和 ,同时也为我创建
TLS 证书和负载均衡器。我通过修改 ,将客户端应用中的负载均衡器监听端点替换为
DNS 名称。同时,我将客户端应用代码更改为使用 grpc.secure_channel 而不是
grpc.insecure_channel,因为负载均衡器提供了 HTTPS 端点。
当我确认 API 正确部署并正常工作后,将配置 CloudFront。
在 的 CloudFront 部分,我选择 创建分发 。
在原点部分,我将我的 gRPC 端点 DNS 名称输入为原点域名 ,并启用 仅 HTTPS 作为 协议 ,HTTPS 端口保持为 443。然后我为分发选择一个名称 。
在 查看器 部分,我选择 仅 HTTPS 作为 查看器协议策略 ,然后选择 GET、HEAD、OPTIONS、PUT、POST、PATCH、DELETE 作为 允许的 HTTP 方法 ,并选择 启用 以 允许通过 HTTP/2 的 gRPC 请求 。
接着,在 缓存键和原点请求 中,我选择 AllViewer 作为 原点请求策略 。
默认的缓存策略是 CacheOptimized ,但 gRPC 并不是可缓存的 API 流量。因此,我选择 CachingDisabled 作为 缓存策略 。
AWS WAF 有助于保护您免受可能影响可用性、危害安全性或消耗过多资源的常见网络攻击和机器人程序的影响。对于 gRPC 流量,AWS WAF可以检查请求的 并强制 。不过,它不会检查以protobuf格式传输的请求体。
在本示例中,我选择不使用 AWS WAF。在 Web 应用防火墙 (WAF) 中,我选择 不启用安全保护 。
我还保持其他选项的默认值。默认情况下已选中 HTTP/2 支持,不要禁用它,因为 gRPC 需要 它。
最后,我选择 创建分发 。
启用 gRPC 只需在常规设置上开一个开关。一旦启用,结合 HTTP/2 和 HTTP POST,CloudFront 可以检测到 gRPC客户端流量并将其转发到您的 gRPC 原点。
几分钟后,分发就绪。随后,我复制并粘贴 CloudFront 分发的端点 URL,并将客户端应用更改为指向 CloudFront,而非之前的负载均衡器。
在测试应用程序再次运行时,一切正常。
gRPC 原点可在 600 多个 CloudFront 边缘位置上使用,不会产生额外费用。普通的请求和数据传输费用仍然适用。
今天就去将 CloudFront 原点指向 gRPC 端点吧。
![Sébastien删除)
Seb 自从上世纪八十年代初第一次触碰 Commodore 64 以来就开始编写代码。他以热情、好奇和创造力来激励开发者释放 AWS云的价值。他的兴趣包括软件架构、开发者工具和移动计算。如果您想向他推销东西,确保它有 API。可以在 Twitter 上关注他 @sebsto。
Leave a Reply