广告

gPRC-Web迈向GA

  • 浏览(35)
  • 评论(0)
  • 译者:k8s

作者:Luc Perkins

我代表云原生计算基金会,很高兴地宣布gRPC-Web的GA版本,这是一个JavaScript客户端库,使Web应用程序能够直接与后端gRPC服务通信,而不需要HTTP服务器充当中介。这意味着您现在可以通过使用 .proto 文件定义客户端 和服务器端数据类型和服务接口,轻松构建真正的端到端gRPC应用程序体系结构 。因此,gRPC-Web为整个REST开发Web范例提供了一个引人注目的新选择。

一 基础

gRPC-Web使您能够在客户端Web应用程序和后端gRPC服务器之间定义服务“契约”,使用 .proto 定义和自动生成客户端JavaScript (您可以在 Closure 编译器JavaScript或更广泛使用的 CommonJS 之间进行选择)。您可以放弃这些开发过程:创建自定义JSON序列化和反序列化逻辑,处理HTTP状态代码(可能因REST API而异),内容类型协商等。

从更广泛的架构角度来看,gRPC-Web使端到端gRPC成为可能。下图说明了这一点:

gRPC-Web迈向GA

在左侧的gRPC-Web世界中,客户端应用程序发送Protocol Buffers到gRPC后端服务器,该服务器发送Protocol Buffers到其他gRPC后端服务。在右侧的REST世界中,Web应用程序将HTTP发送到后端REST API服务器,然后该服务器将发送Protocol Buffers到其他后端服务。

需要明确的是,REST应用程序本身没有任何问题。使用REST API服务器构建了大量非常成功的应用程序,这些服务器使用非HTTP协议与后端服务进行通信。但是想象一下,这些应用程序的开发过程围绕一个协议和一组 .proto 接口(以及一组服务合同)联合起来,您几乎可以感受到无数小时的节省和头痛的避免。gRPC-Web的好处不仅仅是“技术”;也是组织的。明亮的橙色线不仅仅是一个不同的协议 – 它是一个独立的工作和认知负荷来源,你现在可以很容易地变成亮绿色。

二 使用gRPC-Web的优点

随着时间的推移,gRPC-Web将提供更广泛的功能集。但我可以看到它从一开始就提供了一些巨大的便利:

  • 端到端gRPC – 如上所述,使用gRPC-Web,您可以正式从堆栈中删除REST组件并将其替换为纯gRPC,从而使您能够使用Protocol Buffers创建 整个RPC管道。想象一下客户端请求转到HTTP服务器的情况,然后HTTP服务器与5个后端gRPC服务进行交互。您花费在构建HTTP交互层的时间可能跟构建整个管道的其余部分一样多。
  • 前端和后端团队之间更紧密的合作 – 回想上面的图表。使用Protocol Buffers定义整个RPC管道,您不再需要将“微服务团队”与“客户团队”并肩。客户端与后端交互只是一个gRPC层。老实说,我还没有完全掌握端到端测试,服务网格集成,持续集成/交付等方面的含义。
  • 轻松生成客户端库 – 使用gRPC-Web,与“外部”世界交互的服务器,即将后端堆栈连接到互联网的隔膜,现在是gRPC服务器而不是HTTP服务器,这意味着您的所有服务都是客户端库可以是gRPC库。 需要Ruby,Python,Java和其他4种语言的客户端库吗?您不再需要为所有这些客户端编写HTTP客户端。

三 一个gRPC-Web示例

上一节介绍了gRPC-Web在大规模应用中的一些高级优势。 现在让我们通过一个例子来展示:一个简单的TODO应用程序。在gRPC-Web中,您可以从一个简单的 todos.proto 定义开始,如下所示:

syntax = “proto3”;
package todos;
message Todo {
 string content = 1;
 bool finished = 2;
}
message GetTodoRequest {
 int32 id = 1;
}
service TodoService {
 rpc GetTodoById (GetTodoRequest) returns (Todo);
}

您可以使用该 .proto 定义使用 protoc 命令行工具生成CommonJS客户端代码 :

protoc echo.proto 
 --js_out=import_style=commonjs:./output 
 --grpc-web_out=import_style=commonjs:./output

现在从后端gRPC服务器获取TODO列表可以这么简单:

const {GetTodoRequest} = require(‘./todos_pb.js’);
const {TodoServiceClient} = require(‘./todos_grpc_web_pb.js’);
const todoService = new proto.todos.TodoServiceClient(‘http://localhost:8080’);
const todoId = 1234;
var getTodoRequest = new proto.todos.GetTodoRequest();
getTodoRequest.setId(todoId);
var metadata = {};
var getTodo = todoService.getTodoById(getTodoRequest, metadata, (err, response) => {
 if (err) {
 console.log(err);
 } else {
 const todo = response.todo();
 if (todo == null) {
 console.log(`A TODO with the ID ${todoId} wasn’t found`);
 } else {
 console.log(`Fetched TODO with ID ${todoId}: ${todo.content()}`);
 }
 }
});

同样,没有HTTP代码或方法,没有JSON解析,没有头协商。您声明了数据类型和服务接口,并且gRPC-Web摘录了所有“硬接线”样板,为您提供了一个干净且人性化的API(基本上与当前用于gRPC API的Node.js相同的API ,只是转移到客户端)。

在后端,gRPC服务器可以用任何支持gRPC的语言编写,包括Go,Java,C ++,Ruby,Node.js等等(请参阅官方gRPC文档中的语言特定文档 )。最后一块拼图是服务代理。从一开始,gRPC-Web将支持 Envoy 作为默认服务代理,它具有内置的 envoy.grpc_web 过滤器,只需几行复制和可配置配置即可应用。 我很快就会在 Envoy博客 上详细说明这一点 。

四 下一步

迈向GA意味着核心构建块已牢固到位,可以在生产Web应用程序中使用。但是gRPC-Web还有很多其他的东西要来。查看官方路线图,了解核心团队在不久的将来所设想的内容。

如果您有兴趣为gRPC-Web做出贡献,那么核心团队会喜欢社区帮助的一些事项:

  • 前端框架集成 – 常用的前端框架(如 React,Angular 和 Vue)尚未提供对gRPC-Web的官方支持。但我们希望看到这些框架能够支持它,因为每个框架都会从gRPC中受益匪浅。
  • 特定于语言的代理支持 – 从GA版本开始,Envoy 是gRPC-Web的默认代理,通过特殊模块提供支持。但我们也很乐意看到特定语言的进程内代理的开发。进程内代理消除了对特殊代理的需求 – 例如Envoy和nginx – 并且使得使用gRPC-Web变得更加容易。

我们也很乐意收到社区的功能请求。目前,提出功能请求的最佳方法是填写 gRPC-Web路线图功能调查。只需列出您想要查看的功能,并告诉我们您是否愿意为这些功能的开发做出贡献 。gRPC-Web工程师一定会在项目开发过程中牢记这些信息。

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头