【RPC】

A high performance, open source universal RPC framework

https://grpc.io/

https://www.51cto.com/article/701423.html  -- 待提取思维导图

 

gRPC 是由Google开发的一个语言中立、高性能、通用的开源RPC框架，基于ProtoBuf(Protocol Buffers) 序列化协议开发，且支持众多开发语言。面向服务端和移动端，基于 HTTP/2 设计。

gRPC 构建在两个快速、高效的协议之上，也就是 protocol buffers 和HTTP/2。

• protocol buffers 是一个语言中立、平台无关的数据序列化协议，并且提供了可扩展的机制来实现结构化数据的序列化。当序列化完成之后，该协议会生成二进制载荷，这种载荷会比常见的 JSON 载荷更小，并且是强类型的。序列化之后的二进制载荷会通过名为 HTTP/2 的二进制传输协议进行发送。
• HTTP/2 是互联网协议 HTTP 的第 2 个主版本。HTTP/2 是完全多路复用的，这意味着 HTTP/2 可以在 TCP 连接上并行发送多个数据请求。这样一来，使用 HTTP/2 编写的应用程序更快、更简洁、更稳健。

跟语言平台绑定的开源 RPC 框架主要有下面几种。

• Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅支持 Java 语言。
• Motan：微博内部使用的 RPC 框架，于 2016 年对外开源，仅支持 Java 语言。
• Tars：腾讯内部使用的 RPC 框架，于 2017 年对外开源，仅支持 C++ 语言。
• Spring Cloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，仅支持 Java 语言

跨语言平台的开源 RPC 框架主要有以下几种。

• gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，支持多种语言。
• Thrift：最初是由 Facebook 开发的内部系统跨语言的 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一，支持多种语言。

---

 

gRPC

　　序列化：Protocol Buffer：定义数据结构、定义服务接口，通过序列化和反序列化方式提升传输效率。

　　gRPC 使用 Protocol Buffer 作为 IDL 来定义服务接口。

　　生成服务器端代码，也就是服务器端骨架(skeleton) ，它通过提供低层级的通信抽象简化了服务器端的逻辑。

　　生成客户端代码，也就是客户端存根(stub)，它使用抽象简化了客户端的通信，为不同的编程语言隐藏了低层级的通信。就像调用本地函数那样，客户端能够远程调用我们在服务接口定义中所指定的　　　　方法。

　　底层的 gRPC 框架处理所有的复杂工作，通常包括确保严格的服务契约、数据序列化、网络通信、认证、访问控制、可观察性等。

 Protobuf文件的后缀是.proto

 

1、gRpc vs Rest： 

　　参考：https://www.baeldung.com/rest-vs-grpc

　　REST is handy in integrating microservices and third-party applications with the core systems.

　　gRPC can find its application in various systems like IoT systems that require light-weight message transmission, mobile applications with no browser support, and applications that need multiplexed streams.

       多个方面：Rules（.proto）、Underlying HTTP Protocol(HTTP/2)、Data Exchange Format（protobuf）、Serialization、Latency、Browser Support、Code Generation Features

4.1. Guidelines vs. Rules
REST is a set of guidelines for designing web APIs without enforcing anything. On the other hand, gRPC enforces rules by defining a .proto file that must be adhered to by both client and server for data exchange.

4.2. Underlying HTTP Protocol
REST provides a request-response communication model built on the HTTP 1.1 protocol. Therefore, when multiple requests reach the server, it is bound to handle each of them, one at a time.

However, gRPC follows a client-response model of communication for designing web APIs that rely on HTTP/2. Hence, gRPC allows streaming communication and serves multiple requests simultaneously. In addition to that, gRPC also supports unary communication similar to REST.

4.3. Data Exchange Format
REST typically uses JSON and XML formats for data transfer. However, gRPC relies on Protobuf for an exchange of data over the HTTP/2 protocol.

4.4. Serialization vs. Strong Typing
REST, in most cases, uses JSON or XML that requires serialization and conversion into the target programming language for both client and server, thereby increasing response time and the possibility of errors while parsing the request/response.

However, gRPC provides strongly typed messages automatically converted using the Protobuf exchange format to the chosen programming language.

4.5. Latency
REST utilizing HTTP 1.1 requires a TCP handshake for each request. Hence, REST APIs with HTTP 1.1 can suffer from latency issues.

On the other hand, gRPC relies on HTTP/2 protocol, which uses multiplexed streams. Therefore, several clients can send multiple requests simultaneously without establishing a new TCP connection for each one. Also, the server can send push notifications to clients via the established connection.

4.6. Browser Support
REST APIs on HTTP 1.1 have universal browser support.

However, gRPC has limited browser support because numerous browsers (usually the older versions) have no mature support for HTTP/2. So, it may require gRPC-web and a proxy layer to perform conversions between HTTP 1.1 and HTTP/2. Therefore, at the moment, gRPC is primarily used for internal services.

4.7. Code Generation Features
REST provides no built-in code generation features. However, we can use third-party tools like Swagger or Postman to produce code for API requests.

On the other hand, gRPC, using its protoc compiler, comes with native code generation features, compatible with several programming languages.

 

2、demo：

　　http://www.hushowly.com/articles/1759

3、gRPC中Header传值与错误拦截处理：通过实现和注入拦截器实现

　　https://cloud.tencent.com/developer/article/1618969

 

四种服务类型

• 简单
• 客户端流式
• 服务端流式
• 双向流式rpc

　　编码样例：https://www.cnblogs.com/resentment/p/6792029.html