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的鲜新替代方案的主要内容,如果未能解决你的问题,请参考以下文章

gRPC-Web正式发布

第一个gRPC-web项目

第一个gRPC-web项目

第一个gRPC-web项目

gRPC-Web发布,REST又要被干掉了?

ASP.NET Core 搭载 Envoy 实现 gRPC 服务代理