什么是gRPC？
gRPC是GoogleRemoteProcedureCall的简写，是基于RCP架构的变体。该技术遵循一个使用HTTP2.0协议的RPCAPI实现，但HTTP不会呈现给API开发人员或服务器。因此，开发人员无需担心RPC概念如何映射到HTTP，从而降低了复杂性。
总的来说，gRPC旨在加快微服务之间的数据传输。它的基础方法是确定一个服务，建立方法和相应的参数来实现远程调用和返回类型。
此外，它以一个IDL（接口描述语言）表示RPCAPI模型，这为确定远程过程提供了更直接的方法。默认情况下，IDL使用ProtocolBuffers（但也可以使用其他替代方案）来描述服务接口以及负载消息的结构。
gRPC与REST：对比
现在，我们对gRPC和REST有了一个初步认识，下面我们来看看它们的主要区别。
HTTP1.1vsHTTP2
RESTAPI遵循一个通常基于HTTP1.1构建的请求-响应通信模型。不幸的是，这意味着如果一个微服务收到来自多个客户端的多个请求，该模型必须每次只处理一个请求，拖慢了整个系统的速度。RESTAPI也可以构建在HTTP2上，但通信的请求-响应模型保持不变，这使得RESTAPI无法充分利用HTTP2的优势，例如流式通信和双向支持。
gRPC没有面临类似的障碍。它建立在HTTP2之上，且遵循客户端-响应通信模型。这让它支持双向通信和流式通信，因为gRPC能接收来自多个客户端的多个请求，并通过不断地流式传输信息来同时处理这些请求。此外，gRPC还可以处理“一元”交互，例如构建在HTTP1.1上的交互。
总之，gRPC能处理一元交互和多种类型的流：
一元：客户端发出单个请求并接收单个响应。
服务器流：服务器对客户端的请求响应一个消息流。当全部数据发送完毕后，服务器会再发送一条状态消息来完成流程。
客户端流：客户端向服务器发送一个消息流，并接收单个响应消息。
双向流：客户端和服务器的两个流互相独立，也就是说它们都能以任何顺序传输消息。客户端负责发起并结束双向流。
流类型
浏览器支持
这可能是REST相对于gRPC的主要优势之一。一方面，所有浏览器都完全支持REST。另一方面，gRPC获得的浏览器支持仍然非常有限。
不幸的是，它需要gRPC-web和一个代理层来执行HTTP1.1和HTTP2之间的转换。因此，gRPC主要用于内部/私有系统（特定组织的后端数据和应用程序功能中的API程序）。
负载数据结构
如前所述，gRPC默认使用ProtocolBuffers来序列化负载数据。这个方案更轻便，因为它支持高度压缩的格式并减少了消息的大小。此外，Protobuf（或ProtocolBuffer）是二进制的；它对结构化数据进行序列化和反序列化，以便通信和传输。换句话说，强类型消息可以自动从Protobuf转换为客户端和服务器的编程语言。
相比之下，REST主要依靠JSON或XML格式来发送和接收数据。事实上，即使它不强制要求任何结构，JSON也是最流行的格式，因为它具有灵活性和发送动态数据的能力，而不必遵循严格的结构。使用JSON的另一显著优势是其人类可读水平，这方面Protobuf尚无法与之竞争。
尽管如此，JSON在数据传输方面并不够轻量或快速。其原因在于，在使用REST时，必须将JSON（或其他格式）序列化并转换为客户端和服务器端使用的编程语言。这在传输数据的过程中增加了一个额外步骤，从而可能会损害性能并增加出现错误的可能性。
代码生成功能
与gRPC不同，RESTAPI不提供内置代码生成功能，这意味着开发人员必须使用Swagger或Postman等第三方工具为API请求生成代码。
相比之下，gRPC由于其protoc编译器而具有原生代码生成功能，该编译器与多种编程语言兼容。这对于集成了以不同语言和平台开发的各种服务的微服务系统来说尤其方便。此外，内置的代码生成器还有助于创建SDK（软件开发工具包）。