RPC，RPC和REST对比，IPC，Socket，gRPC，Protobuf，一个rpc请求是如何执行的

RPC

RPC简介

RPC是远程过程调用的简称，是分布式系统中不同节点间流行的通信方式。在互联网时代，RPC已经和IPC一样成为一个不可或缺的基础构件。因此Go语言的标准库也提供了一个简单的RPC实现，我们将以此为入口学习RPC的各种用法。

RPC是远程过程调用的缩写（Remote Procedure Call），通俗地说就是调用远处的一个函数。远处到底有多远呢？可能是同一个文件内的不同函数，也可能是同一个机器的另一个进程的函数，还可能是远在火星好奇号上面的某个秘密方法。因为RPC涉及的函数可能非常之远，远到它们之间说着完全不同的语言，语言就成了两边的沟通障碍。而Protobuf因为支持多种不同的语言（甚至不支持的语言也可以扩展支持），其本身特性也非常方便描述服务的接口（也就是方法列表），因此非常适合作为RPC世界的接口交流语言。本章将讨论RPC的基本用法，如何针对不同场景设计自己的RPC服务，以及围绕Protobuf构造的更为庞大的RPC生态。

RPC和REST对比

IPC

IPC(Inter-Process Communication)进程间通信，两个进程的数据之间产生交互，提供了各种进程间通信的方法。在Linux C编程中有几种方法

(1) 半双工Unix管道

(2) FIFOs(命名管道)

(3) 消息队列

(4) 信号量

(5) 共享内存

(6) 网络Socket

Socket

链接：https://www.jianshu.com/p/33f643c86d86

在TCP/IP协议中，“~~IP地址+TCP或UDP端口号~~”唯一标识网络通讯中的一个进程，“IP地址+端口号”就称为socket。

Socket是为了方便开发者直接使用更底层协议（一般是TCP或UDP）而存在的一个抽象层。Socket实际上是对TCP/IP协议的封装，本身并不是协议，而是一个调用接口（API）。

Socket的出现只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了我们知道的一些最基本的函数接口，比如create、listen、connect、accept、send、read和write。

主机A的应用程序要能和主机B的应用程序通信，必须通过Socket建立连接，而建立Socket连接必须需要底层TCP/IP协议来建立TCP连接。建立TCP连接需要底层IP协议来寻找网络中的主机。我们知道网络层使用IP协议可以帮助我们根据IP地址来找到目标主机，但是一台主机上可能运行着多个应用程序，如何才能与指定的应用程序通信就要通过TCP或UDP的地址也就是端口号来指定。这样就可以通过一个Socket实例唯一代表一个主机上的一个应用程序的通信链路了。

gRPC

https://www.cnblogs.com/FireworksEasyCool/p/12782137.html

gRPC概述

gRPC 是一个高性能、通用的开源 RPC 框架，其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计，基于 ProtoBuf(Protocol Buffers) 序列化协议开发，且支持众多开发语言。

与许多 RPC 系统类似，gRPC 也是基于以下理念：定义一个服务，指定其能够被远程调用的方法（包含参数和返回类型）。在服务端实现这个接口，并运行一个 gRPC 服务器来处理客户端调用。在客户端拥有一个存根能够像服务端一样的方法。

gRPC 默认使用 protocol buffers，这是 Google 开源的一套成熟的结构数据序列化机制（当然也可以使用其他数据格式如 JSON）。

gRPC是Google公司基于Protobuf开发的跨语言的开源RPC框架。gRPC基于HTTP/2协议设计，可以基于一个HTTP/2链接提供多个服务，对于移动设备更加友好。

最底层为TCP或Unix Socket协议，在此之上是HTTP/2协议的实现，然后在HTTP/2协议之上又构建了针对Go语言的gRPC核心库。应用程序通过gRPC插件生产的Stub代码和gRPC核心库通信，也可以直接和gRPC核心库通信。

上图中列出了 gRPC 基础概念及其关系图。其中包括：Service(定义)、RPC、API、Client、Stub、Channel、Server、Service(实现)、ServiceBuilder 等。

使用 gRPC 的 3个步骤:

需要使用 protobuf 定义接口，即编写 .proto 文件;
然后使用 protoc 工具配合编译插件编译生成特定语言或模块的执行代码，比如 Go、Java、C/C++、Python 等。
分别编写 server 端和 client 端代码，写入自己的业务逻辑。

Protobuf

Protocol buffers 是一种语言无关、平台无关的可扩展机制或者说是数据交换格式，用于序列化结构化数据。与 XML、JSON 相比，Protocol buffers 序列化后的码流更小、速度更快、操作更简单。ProtoBuf是二进制的，更快更高效。

编译过程

可以把 protoc 的编译过程分成简单的两个步骤：

解析 .proto 文件，编译成 protobuf 的原生数据结构保存在内存中；
把 protobuf 相关的数据结构传递给相应语言的编译插件，由插件负责将接收到的 protobuf 原生结构渲染输出为特定语言的模板。

具体过程如图所示：

protoc 中原生包含了部分语言（java、php、python、ruby等等）的编译插件，但是没有 Go 语言的，所以需要额外安装一个插件。

同样的，后续讲到的 gRPC Plugins、gRPC-Gateway 也是一个个的 protoc 编译插件，将 .proto 文件编译成对应模块需要的源文件。

安全认证

gRPC 内置了以下 encryption 机制：

1）SSL / TLS：通过证书进行数据加密；
2）ALTS：Google开发的一种双向身份验证和传输加密系统。
- 只有运行在 Google Cloud Platform 才可用，一般不用考虑。

gRPC 中的连接类型一共有以下3种：

1）insecure connection：不使用TLS加密
2）server-side TLS：仅服务端TLS加密
3）mutual TLS：客户端、服务端都使用TLS加密

gRPC Token认证

客户端发请求时，添加Token到上下文context.Context中，服务器接收到请求，先从上下文中获取Token验证，验证通过才进行下一步处理。

gRPC转换HTTP

我们通常把RPC用作内部通信，而使用Restful Api进行外部通信。为了避免写两套应用，我们使用grpc-gateway把gRPC转成HTTP。服务接收到HTTP请求后，grpc-gateway把它转成gRPC进行处理，然后以JSON形式返回数据。最终转成的Restful Api支持bearer token验证、数据验证，并添加swagger文档。