总监又来了，人狠话不多，这篇 gRPC，小弟佩服！

大家好，我是楼仔！,RPC、gRPC、Thrift、HTTP，大家知道它们之前的联系和区别么？这些都是面试常考的问题，今天我们带大家先搞懂 RPC 和 gRPC。,在讲述 gPRC 之前，我们需要先搞懂什么是 RPC。,不 BB，直接上文章目录：,,RPC（Remote Procedure Call Protocol）远程过程调用协议，目标就是让远程服务调用更加简单、透明。,RPC 框架负责屏蔽底层的传输方式（TCP 或者 UDP）、序列化方式（XML/Json/ 二进制）和通信细节，服务调用者可以像调用本地接口一样调用远程的服务提供者，而不需要关心底层通信细节和调用过程。,,当我们的业务越来越多、应用也越来越多时，自然的，我们会发现有些功能已经不能简单划分开来或者划分不出来。,此时可以将公共业务逻辑抽离出来，将之组成独立的服务 Service 应用，而原有的、新增的应用都可以与那些独立的 Service 应用 交互，以此来完成完整的业务功能。,所以我们急需一种高效的应用程序之间的通讯手段来完成这种需求，RPC 大显身手的时候来了！,要让网络通信细节对使用者透明，我们需要对通信细节进行封装，我们先看下一个 RPC 调用的流程涉及到哪些通信细节：,,RPC 的目标就是要 2~8 这些步骤都封装起来，让用户对这些细节透明，下面是网上的另外一幅图，感觉一目了然：,,gRPC 是一个高性能、通用的开源 RPC 框架，其由 Google 2015 年主要面向移动应用开发并基于 HTTP/2 协议标准而设计，基于 ProtoBuf 序列化协议开发，且支持众多开发语言。,由于是开源框架，通信的双方可以进行二次开发，所以客户端和服务器端之间的通信会更加专注于业务层面的内容，减少了对由 gRPC 框架实现的底层通信的关注。,如下图，DATA 部分即业务层面内容，下面所有的信息都由 gRPC 进行封装。,,,简单地说，gRPC 就是在客户端和服务器端开启 gRPC 功能后建立连接，将设备上配置的订阅数据推送给服务器端。,我们可以看到整个过程是需要用到 Protocol Buffers 将所需要处理数据的结构化数据在 proto 文件中进行定义。,你可以理解 ProtoBuf 是一种更加灵活、高效的数据格式，与 XML、JSON 类似，在一些高性能且对响应速度有要求的数据传输场景非常适用。,ProtoBuf 在 gRPC 的框架中主要有三个作用：定义数据结构、定义服务接口，通过序列化和反序列化方式提升传输效率。,为什么 ProtoBuf 会提高传输效率呢？,我们知道使用 XML、JSON 进行数据编译时，数据文本格式更容易阅读，但进行数据交换时，设备就需要耗费大量的 CPU 在 I/O 动作上，自然会影响整个传输速率。,Protocol Buffers 不像前者，它会将字符串进行序列化后再进行传输，即二进制数据。,,可以看到其实两者内容相差不大，并且内容非常直观，但是 Protocol Buffers 编码的内容只是提供给操作者阅读的，实际上传输的并不会以这种文本形式，而是序列化后的二进制数据，字节数会比 JSON、XML 的字节数少很多，速率更快。,gPRC 如何支撑跨平台，多语言呢 ？,Protocol Buffers 自带一个编译器也是一个优势点，前面提到的 proto 文件就是通过编译器进行编译的，proto 文件需要编译生成一个类似库文件，基于库文件才能真正开发数据应用。,具体用什么编程语言编译生成这个库文件呢？由于现网中负责网络设备和服务器设备的运维人员往往不是同一组人，运维人员可能会习惯使用不同的编程语言进行运维开发，那么 Protocol Buffers 其中一个优势就能发挥出来——跨语言。,从上面的介绍，我们得出在编码方面 Protocol Buffers 对比 JSON、XML 的优点：,Protobuf 适用场景：,除了 Protocol Buffers 之外，从交互图中和分层框架可以看到， gRPC 还有另外一个优势——它是基于 HTTP 2.0 协议的。,由于 gRPC 基于 HTTP 2.0 标准设计，带来了更多强大功能，如多路复用、二进制帧、头部压缩、推送机制。,这些功能给设备带来重大益处，如节省带宽、降低 TCP 连接次数、节省 CPU 使用等，gRPC 既能够在客户端应用，也能够在服务器端应用，从而以透明的方式实现两端的通信和简化通信系统的构建。,HTTP 1.X 定义了四种与服务器交互的方式，分别为 GET、POST、PUT、DELETE，这些在 HTTP 2.0 中均保留，我们看看 HTTP 2.0 的新特性：双向流、多路复用、二进制帧、头部压缩。,与采用文本格式的 JSON 相比，采用二进制格式的 protobuf 在速度上可以达到前者的 5 倍！,Auth0 网站所做的性能测试结果显示，protobuf 和 JSON 的优势差异在 Java、Python 等环境中尤为明显，下图是 Auth0 在两个 Spring Boot 应用程序间所做的对比测试结果。,,结果显示，protobuf 所需的请求时间最多只有 JSON 的 20% 左右，即速度是其 5 倍!,下面看一下性能和空间开销对比。,,,从上图可得出如下结论：,我们先看一下项目结构：,,文件 helloworld.proto：,这里提供了一个 SayHello() 方法，然后入参为 HelloRequest，返回值为 HelloReply，可以看到 proto 文件只定义了入参和返回值的格式，以及调用的接口，至于接口内部的实现，该文件完全不用关心。,文件 pom.xml：,这里面的 build 其实是为了安装 protobuf 插件，里面其实有 2 个插件我们需要用到，分别为 protobuf:compile 和 protobuf:compile-javanano，当我们直接执行时，会生成左侧文件，其中 GreeterGrpc 提供调用接口，Hello 开头的文件功能主要是对数据进行序列化，然后处理入参和返回值。,可能有同学会问，你把文件生成到 target 中，我想放到 main.src 中，你可以把这些文件 copy 出来，或者也可以通过工具生成：,,文件 HelloWorldClient.java：,这个太简单了，就是连接服务端口，调用 sayHello() 方法。,文件 HelloWorldServer.java：,主要是实现 sayHello() 方法，里面对数据进行了简单处理，入参为 “W  orld”，返回的是 “Hello World”。,先启动 Server，返回如下：,,再启动 Client，返回如下：,,同时 Server返回如下：,,Git 地址：https://github.com/lml200701158/rpc-study,这篇文章其实是我去年写的，这次是重新整理，文章详细讲解了 RPC 和 gRPC，以及 gRPC 的应用示例，非常全面，后面会再把 Thrift 整理出来。,这个 Demo 看起来很简单，我 TM 居然搞了大半天，一开始是因为不知道需要执行 2 个不同的插件来生成 protobuf，以为只需要点击 protobuf:compile 就可以，结果发现 protobuf:compile-javanano 也需要点一下。,还有就是我自己喜欢作，感觉通过插件生成 protobuf 不完美，我想通过自己下载的插件，手动生成 protobuf 文件，结果手动生成的没有搞定，自动生成的方式也不可用，搞了半天才发现是缓存的问题，最后直接执行 “Invalidate Caches / Restart” 才搞定。,应征了一句话“no zuo no die”，不过这个过程还是需要经历的。