Envoy和gRPC-Web:REST的鲜新替代方案
Posted CNCF
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Envoy和gRPC-Web:REST的鲜新替代方案相关的知识,希望对你有一定的参考价值。
gRPC-Web是一个javascript客户机库,它允许web应用程序使用来与后端服务交互,而不是使用自定义HTTP服务器作为中介。上周,经过近两年的积极开发,gRPC团队在上宣布了gRPC-Web的GA发布。
就我个人而言,自从我第一次在 Improbable engineering的博客上看到gRPC-Web之后,我就对它产生了浓厚的兴趣。我一直很喜欢gRPC的性能、可伸缩性和服务交互的IDL驱动方法,并且渴望一种尽可能从服务路径中消除REST的方法。我很高兴地看到gRPC-Web已经准备就绪,因为我认为它为web开发打开了一些极具前景的领域。
在我看来,gRPC- Web的美妙之处在于,它使你能够从web客户机一直到下创建完整的端到端gRPC服务体系结构。以前,如果你希望将一个gRPC驱动的后端与web客户端结合使用,那么你需要编写REST API逻辑来将HTTP调用转换到gRPC上或从gRPC上进行转换——如果可能的话,我们大多数人都很乐意避免这种工作。gRPC-Web允许你使用Protocol Buffers封装所有数据接口,从而使你不必编写另一个HTTP服务器(是在令人难以置信的Envoy帮助下,我将进一步解释)。
gRPC- web的美妙之处在于,它使你能够从web客户机一直创建完整的端到端gRPC服务体系结构。这使你无需编写另一个HTTP服务器,因为它允许你使用Protocol Buffers封装所有的数据接口(在Envoy的关键帮助下)。
REST的方式
下图展示了两种构建基于gRPC的服务体系结构的web应用程序的方法。在左侧面板中,你将看到基于REST的“传统”方式,而在右侧面板中,你将看到gRPC-Web方式。
REST API与gRPC-Web中的客户机-后端交互
在左侧面板中,你将注意到REST API服务器充当web应用程序和后端之间的联系人。在很多情况下,REST服务器只是将HTTP从客户端调用转换为gRPC到后端服务的调用。
让我们来看一个示例:客户端希望通过将JSON发送到HTTP服务器的/auth端点来使用gRPC后端服务器进行身份验证。HTTP服务器将POST请求转换为AuthRequest的Protobuf消息,将该消息发送到后端gRPC auth服务器,最后将auth服务器的AuthResponse消息转换为web客户机的JSON负载。正如我在为CNCF博客写的博文中所述,这种方法本身并没有什么问题。这是一个很好的模式,很多开发人员都很成功地使用了这种模式;如果它对你有用,就留着吧。
但让我们面对现实吧:如果web客户端能够删除HTTP中介并直接将请求发送到后端(想象一下JavaScript auth客户端发送AuthRequest消息并返回AuthResponse消息),那么将节省大量工作。这意味着不需要HTTP状态码,不需要JSON SerDe,也不需要HTTP服务器本身的部署和管理负担。
在右边的面板中,你可以看到新的gRPC-Web替代方案。你将注意到:拼图的碎片更少了,一个协议(绿色的行!),没有HTTP逻辑,所有数据接口都使用.proto文件定义。客户端向gRPC后端发送一个Protobuf消息,返回一个Protobuf消息。
为了得到这个好处,还有一件事你需要做好…
Envoy的角色
坦白说:我撒了点小谎。前面我说过,使用gRPC- Web客户端可以“直接”对后端服务进行gRPC调用。这并不完全正确。对于gRPC-Web,客户端调用仍然需要转换为对gRPC友好的调用,但是这个角色现在由Envoy来填补,Envoy具有对gRPC-Web的内置支持,并作为其默认的服务网关。
下图给出了特使适用于gRPC-Web图片的基本图片。在这里,web应用程序与后端gRPC服务交互,后端gRPC服务依赖于另外两个gRPC服务。Envoy将客户端产生的HTTP/1.1调用转换为可以由这些服务处理的HTTP/2调用(gRPC使用HTTP/2进行传输)。HTTP仍然在幕后运行,但是客户机和服务器都不需要考虑HTTP术语。
Envoy在gRPC-Web应用程序中的角色
gRPC-Web是一个巨大的胜利,因为你不需要创建那个翻译层——你只需要为Envoy提供一些基本的配置。
对于gRPC-Web,客户端调用仍然需要转换为对gRPC友好的调用,但是这个角色现在由Envoy来填补,Envoy具有对gRPC-Web的内置支持,并作为其默认的服务网关。
Envoy配置例子
下面是一个用于Envoy代理的YAML配置示例,该代理侦听端口8080上的HTTP客户机连接,然后将这些请求代理给后端gRPC服务。
1static_resources:
2 listeners:
3 - name: listener_0
4 address:
5 socket_address: { address: 0.0.0.0, port_value: 8080 }
6 filter_chains:
7 - filters:
8 - name: envoy.http_connection_manager
9 config:
10 codec_type: auto
11 stat_prefix: ingress_http
12 route_config:
13 name: local_route
14 virtual_hosts:
15 - name: local_service
16 domains: ["*"]
17 routes:
18 - match:
19 prefix: "/”
20 route:
21 cluster: auth_service
22 cors:
23 allow_origin:
24 - "*"
25 allow_methods: GET, PUT, DELETE, POST, OPTIONS
26 allow_headers: keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web
27 max_age: "1728000"
28 expose_headers: grpc-status,grpc-message
29 enabled: true
30 http_filters:
31 - name: envoy.grpc_web
32 - name: envoy.cors
33 - name: envoy.router
34 clusters:
35 - name: auth_service
36 connect_timeout: 0.25s
37 type: logical_dns
38 http2_protocol_options: {}
39 lb_policy: round_robin
40 hosts:
41socket_address:
42 address: auth-server
43 port_value: 9090
一般来说,这是特使使用的非常标准的HTTP配置。只有几个小小的区别:
处理gRPC-Web客户机请求(JavaScript库自动处理这些头)需要一些非典型的头文件——x-grpc-web、grpc-status和grpc-message。
内置的envoy.grpc_web HTTP过滤器执行gRPC-Web代理的“繁重工作”
http2_protocol_options:{}指定auth_service接受HTTP/2(在本例中是gRPC)连接。
你只是将自己从围绕开发HTTP服务器的所有常见的繁琐程序中拯救出来,所需要的只是一个小YAML。不需要将HTTP谓词映射到API操作,不需要询问StackOverflow哪个HTTP状态代码对应哪个服务器状态,不需要将JSON转换为Protobuf消息。
一条新的道路
gRPC- Web和Envoy提供了一种非常引人注目的web开发新方法,它提供了Protocol Buffers和gRPC的类型安全性,并规避了HTTP和REST的许多缺陷,这些缺陷我们都非常熟悉。我鼓励——不乞求——你在下一个项目中尝试一下。
点击文末<<阅读原文>>进入网页了解更多。
CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux Foundation,是非营利性组织。
云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。请长按以下二维码进行关注。
以上是关于Envoy和gRPC-Web:REST的鲜新替代方案的主要内容,如果未能解决你的问题,请参考以下文章