grpc教程grpc入门

Posted 2021-06-18 b站lishinho杂货铺

这一阶段想做一个系统的教程，grpc一直是我最想讨论的话题之一。

随着微服务架构的出现，其实商用的现代软件的应用程序很少有孤立运行的，我们希望计算机网络连接每个应用，通过互相传递信息的方式进行通信和协调。grpc就是一个可扩展，松耦合，高性能，类型安全的解决方案：

grpc可以用在golang，c++，java等等不同语言的业务服务上；

grpc通过protobuffer实现序列化反序列化，效率大大高于json的效果；

grpc有效解决了REST架构风格应用程序间缺少强类型接口的弱点。

当然以上只是概括，具体因果我会尝试在这次和以后的教程中一一讲清楚。

01

—

grpc的定义

grpc是一种进程间通信技术，可以用来连接，调用，操作和调试分布式异构应用程序，就像是调用本地函数一样，使整个过程操作起来很简单。

了解grpc定义其实夹杂着很多概念，比如进程，进程间通信，分布式异构应用程序等。

简单来说，我的服务器运行一个服务，你的服务器也运行一个服务。现在我的服务想要获取你服务的数据，就需要用一种方法在不同服务器进程之间传播或交换信息。

其实这种进程间通信的方式有很多，我们使用的手机，各种客户端，各种工具，凡是能从服务器获取数据的都用到了进程间通信。

而grpc具体解决的就是有效构建了组织内部的服务间通信。

熟悉Java的同学一定不陌生序列化和反序列化的概念，

序列化：是把对象转换为字节序列，永久存到磁盘中。在网络中传输对象也要进行序列化。（对象->字节序列）

反序列化：是从磁盘中读取字节序列将它们反序列化成对象读出来。（字节序列->对象）

grpc使用protobuffers作为IDL来定义服务接口，实现序列化机制，将http/2作为网络间的通信协议。

02

—

基于grpc的微服务

基于grpc微服务的架构图

如果作为grpc的使用者，其实实现一个接口的流程是很清晰明了的。定义好一份proto文件，使用protobuffers的protoc生成客户端grpc stub的代码和服务器grpc server的代码，通过服务发现暴露在网络中

protoc是proto文件的编译器，目前已经可以支持多种编程语言，即使一些冷门不常用的语言，也可以利用插件的形式，相当于c套了一层其他语言的壳子来实现。

03

—

进程间通信技术

传统的RPC

其实只要上网搜下就能看到有人总结的很多早期rpc的痛点。从实现协议交互的角度来说，早期rpc实现比如CORBA(通过对象请求代理体系架构)和Java的RMI(远程方法调用)有着以下缺点：

1.实现复杂

2.构建在tcp这样的通信协议之上，而这会妨碍互操作性，

3.大量的规范限制也会使代码不够灵活。

SOAP

为了避免传统RPC实现的局限，基于http post请求的进程间通信的SOAP（简单对象访问协议）诞生。可是即使做了简化，面对越来越复杂的信息交互，操作消息格式的复杂和各种规范的限制也迫使SOAP逐步进化。

REST

REST（描述性状态迁移）架构风格应运而生，REST通用实现是http，应用于资源的状态变更操作会采用http动词（GET，POST，PUT，DELETE等）形式，资源状态会以文本的格式表述，比如json，xml，yaml等

REST架构风格已经成为构建微服务的标准方式，但是这种风格依然有痛点：

1.基于文本的低效消息协议

传输时是通过json等人类可读的文本，其实只需要传送机器可读二进制内容就行了。

2.缺乏强类型接口

在开发restful服务时，应用程序间不需要共享服务定义和类型定义的信息。接口并不是强类型的，这可能导致出现很多不兼容，运行时错误等问题。

3.REST架构风格难以实施

像GET，DELET不能加body，POST请求不带参数这些规约不会被强制执行，这就导致服务器和客户端可能存在的信息丢失。详情可以见阮一峰的RESTful API设计指南

grpc

grpc提供高效的进程间通信，在http/2上使用基于protobuffers的二进制协议来通信；

强类型，支持多语言，支持双工流；

具有简单且定义良好的服务接口和模式；

grpc不同于SOAP web的WSDL，先定义服务接口再实现细节，实现了契约优先

当然grpc不太适合对外的服务，因为和REST相比，契约驱动的形式降低了灵活性，消费者的控制权会削弱很多。

现在，b站内部系统的链路已经逐步使用grpc替代http的json进行交互。国内外的一些大厂也开始陆续通过grpc方案实现服务交互，grpc也越来越成为面试中的常见加分项。