理解 gRPC——以及REST和RPC架构的区别

本文的目标是让读者对gRPC有一个高层次的认识。它还将解释gRPC与现有web应用程序通信的协议以及架构之间的异同。

gRPC是什么？

gRPC是一个开源的远程过程调用框架，用于服务之间的高性能通信。服务之间的通信可以使用各种语言，通过可插拔的负载均衡、追踪、健康检查和身份验证，这让它被认为是一种非常高效的方法。在默认情况下，gRPC使用协议缓冲（Protocol Buffer）来序列化结构化数据。通常，在微服务架构中，gRPC被认为是REST更好的替代方案。gRPC中的“g”取名于最初开发该技术的Google。

在更深入了解gRPC的细节之前，让我们先来看看微服务架构。

微服务与单体应用对比

单体架构作为最传统的应用设计方案，它包含一个个独立的代码库：服务于客户端的用户界面、服务器端的应用程序和数据库。所有的开发人员都需要把代码贡献到同一个代码库。我比较喜欢的一个类比就是，可以把它想象成一个单间公寓。每个单间按需划分成不同的空间。

单体架构的优点是，由于只有一个单元，所以日志记录、性能监视和缓存等操作可以很容易地完成。而且，开发、测试、调试和部署都很简单。

但是随着应用程序的增长，它就会变得难以维护、扩展，甚至难以理解。而且，它可能变得非常复杂，代码中的一个小更改就可能影响整个应用程序。

单体架构的另一个重要的缺点是它对单一技术的严格遵守。采用新的框架或语言可能需要重新编写整个系统。

进入微服务架构！

如果单体架构是一个单间公寓，那么微服务架构可以被理解为是一个有很多房间的大房子。这意味着整个应用程序将被细分为多个更小的应用程序或服务。

这使开发团队能够灵活地选择最适合他们的技术，并让他们独立地扩展他们的服务。微服务应用中的任何错误只影响特定的服务，而不会影响整个应用程序。

开发团队可以独立地开发、维护和部署这些服务，这些服务通过定义好的API（Application Programming Interfaces）相互通信。

通过HTTP实现微服务之间的通信有多种方式。目前最广泛的是遵循REST协议，gRPC是另一种实现这种通信的方式，它的出现就是为了克服REST在微服务通信中的限制从而构建的。

REST架构

REST是一个使用HTTP协议的web架构，它被广泛用于web应用程序的开发。简单地说，REST是一种CS（客户端-服务器）结构，其中后端数据通过简单的表述性语言(如JSON/XML)提供给客户端。正如Roy Fielding所描述的，REST的意思是表述性状态传递（REpresentational State Transfer）。REST作为一种协议，在低级架构实施中，它不强制要求任何规则；在高级架构，它提供了实施指南。

为了使任何应用程序真正RESTful，必须遵循以下6个架构约束：

1．统一接口：意味着API接口必须呈现给web应用程序中的各种资源，从而呈现于消费者的API中。

2．客户端—服务器：客户端和服务器必须相互独立，客户端应该只知道与资源相对应的URI。

3．无状态：服务器不能存储任何与客户端请求相关的内容。客户端负责维护应用程序的状态。

4．可缓存：资源必须是可缓存的。

5．分层系统：架构必须分层，这意味着整个架构中的组件可以分布在多个服务器中。

6．按需编码：客户端必须把能够获得可执行代码作为一种响应。这是一个可选的约束。

基于REST的Web服务称为RESTful Web服务。在这些应用程序中，每个组件都是一个资源，可以通过使用HTTP标准的通用接口访问这些资源。以下四种HTTP方法通常用于基于REST的架构中：

• GET—对资源的只读访问。

• POST—创建新资源。

• DELETE—删除资源。

• PUT—更新现有资源或创建新资源。

RPC架构

RPC的意思是远程过程调用（Remote Procedure Call）。顾名思义，我们可以在远程服务器上调用函数或方法。RPC协议允许以相同的格式获取问题的结果，而不管在哪里执行。它可以从本地执行，也可以从拥有更好性能的远端服务器上执行。

RPC是一种比REST老得多的协议。自20世纪70年代ARPANET建立以来，它一直用于执行网络操作。RPC这个术语是由Bruce Jay Nelson在1981年首次提出的。但是，正如我们将要看到的，RPC仍然在基于API的现代应用程序中以不同的方式用于实施部署。

原理都是一样的。API是通过定义公共方法来构建的，然后采用参数调用的方法。RPC只是一堆函数，但是在HTTP API上下文中，它需要将方法放到URL中，并将参数放到查询字符串或主体中。

RPC API使用类似于POST /deleteResource的方法，它的主体是 {“id”：1} ，而不是REST方法，后者是DELETE /resource/1。

RPC在物联网设备和其他需要自定义契约通信的低功耗设备解决方案中非常流行，因为许多计算操作可以转移到另一个设备上。传统上，RPC可以基于RPC-XML和RPC-JSON来实现。

gRPC是在RPC协议上创建的最新框架。它利用自身的优势，试图解决传统RPC存在的问题。

gRPC又是什么？

到目前位置，无论我们都读到了什么，我们现在都可以重新认识一下gRPC。它是对传统RPC框架的一种进化。那么，它与现有的RPC框架有什么不同呢？

最重要的区别是gRPC使用protocol buffer作为序列化和通信的接口定义语言，而不是JSON/XML。Protocol buffer可以描述数据的结构，并且可以根据该描述生成代码，以生成或解析表示结构化数据的字节流。这就是为什么gRPC更适合使用polyglot(使用不同的技术部署)的web应用程序。二进制数据格式使得通信更加轻量，gRPC也可以与其他数据格式一起使用，但首选的格式仍然是protocol buffer。

此外，gRPC构建在HTTP/2之上，它支持双向通信以及传统的请求/响应。gRPC允许服务器和客户端之间的松散耦合。在实践中，客户端发起一个与gRPC服务器的长连接，并为每个RPC调用打开一个新的HTTP/2流。

REST与gRPC对比

与通常使用JSON的REST不同，gRPC使用protocol buffer，这是一种更好的数据编码方式。由于JSON是一种基于文本的格式，因此它比protobuf格式的压缩数据要重得多。

与传统REST相比，gRPC的另一个重大改进是它使用HTTP 2作为其传输协议。REST主要使用HTTP 1.1，基本上是一个请求—响应模型。（REST也可以用HTTP2来实现）gRPC利用了HTTP2的双向通信特性和传统的响应—请求结构。在HTTP 1.1中，当有多个请求来自多个客户端时，需要一个接一个提供服务，这很可能会使系统变慢。但，HTTP 2允许多路复用，因此可以同时处理多个请求和响应。

我们可以得出结论，在这种应用场景下：惯用API或大规模微服务通信的多语言通信时，gRPC是一个非常好的选择。

原文链接： https://medium.com/better-prog ... 3e79e