什么是gRPC
1.什么是gRPC
gRPC是rpc框架中的一种，是rpc中的大哥
是一个高性能，开源和通用的RPC框架，基于Protobuf序列化协议开发，且支持众多开发语言。
面向服务端和协议端，基于http/2设计，带来诸如双向流，流控，头部压缩，单TCP连接上的多路复用哀求等特性。这些特性使得其在移动设备上表现的更好，更省电和节省空间。
在gPRC里客户端可以向调用本地对象一样直接调用另一台不同机器上服务端应用的方法，使得您能够更轻易地创建分布式应用和服务。
与许多RPC系统类似，gRPC也是基于以下理念：定义一个服务，指定其能够被遥程调用的方法（包含参数和返归类型）。在服务端实现这个接口。并运行一个gRPC服务器来处理客户端调用。在客户端拥有一个存根能够向服务端一样的方法。
补充一个知识点（HTTP/2 与HTTP1.X的区别）
用于数据传输的二入制分帧
HTTP/2采用二入制格式传输协议，而非HTTP/1.x的文本格式。
多路复用
HTTP/2支持通过同一个连接发送多个并发的哀求。
而HTTP/1.x虽然通过pipeline也能并发哀求，但多个哀求之间的响应依然会被阻塞。
服务端推送
服务端推送是一种在客户端哀求之前发送数据的机制。在HTTP/2中，服务器可以对客户端的一个哀求发送多个响应。而不像HTTP/1.X一样，只能通过客户端发起request,服务端才产生对应的response。
减少网络流量的头部压缩。
HTTP/2对消息头入行了压缩传输，能够节省消息头占用的网络流量。至于如何压缩的，可以查观这篇：HPACK: Header Compression for HTTP/2[1]
2.gRPC大致哀求流程
1.客户端(gRPC Stub)调用A方法，发起RPC调用
2.对哀求信息使用Protobuf入行对象序列化压缩（IDL）
3.服务端（gPRC Server)接收到哀求后，解码哀求体，入行业务逻辑处理并返归。
4.对响应结果使用Protobuf入行对象序列化压缩（IDL）
5.客户端接受到服务端响应，解码哀求体。归调被调用的A方法，唤醒正在等待响应（阻塞）的客户端调用并返归响应结果
3.gRPC的优势
性能
gRPC消息使用一种有效的二入制消息格式protobuf继承宁序列化。Protobuf在服务器和客户机上的序列化非常快。Protobuf序列化之后的消息体积很小，能够有效负载，在移动应用程序等有限宽带场景中显得很重要。与采用文本格式的json相比，采用二入制格式的protobuf在速度上可以达到前者的5倍
代码生成
所有gRPC框架都为代码生成提供了一流的支持。gRPC的开发核心是*.proto文件，它定义了gRPC服务和消息的约定。根据这个文件，gRP框架将生成服务基类，消息和完整的客户端代码。
通过在服务器和客户端之间共享*.proto文件，可以从端到端生成消息和客户端代码。客户端的代码生成消除了客户端和服务器上的重复消息，并为您创建了一个强类型的客户端。无需编写客户端代码，可在具有许多服务和应用程序中节省大量开发时间。
严格的规范
不存在具有JSON的HTTP API的正事规范。开发人员不需要讨论URL，HTTP动词和响应代码的最佳格式。（不需要考虑用post还是get，get还是put)
该gRPC规范是规定有关gPRC服务必须遵循的格式。gRPC消除了争论并节省了开发人员的时间，因为gRPC在各个平台上和实现之间是一致的
流
gRPC服务支持所有流组合：
- 一元（没有媒体流）：最简朴的rpc调用，一个哀求对象对应一个返归对象。客户端发起一次哀求客户端相应一个数据，即标准的RPC通信。
- 服务器到客户端流：客户端流式rpc客户端传进多个哀求对象。服务端返归一个响应结果。应用场景：物联网终端向服务器报送数据。
- 客户端到服务器流：服务端流式rpc一个哀求对象，服务端可以传归多个结果对象。服务端流PRC下，客户端发出一个哀求，但不会立即得到一个响应，而是在服务器与客户端之间建立一个单向的流，不断获取响应直到流关闭。应用场景举例：典型的例子是客户端向服务端发送一个股票代码，服务端就把该股票的实时数据源源不断的返归客户端
- 双向流媒体：双向流式RPC结合客户端流式RPC和服务端流式RPC，可以传进多个对象，返归多个响应对象。应用场景：聊天应用
截至时间/超时和取消
gRPC答应客户端指定他们愿意等待RPC完成时间。该期限被发送到服务端，服务端可以决定在超出了期限时采取什么行动，例如，服务器可能会在超时时取消正在入行的gPRC/HTTP/数据库哀求
通过子gRPC调用截至时间和取消操作有助于实施资源使用限制
4.gRPC的劣势
浏览器支持有限
当下，不能从浏览器调用gRPC服务 ,
gRPC Web是gRPC团队的一项附加技术，它在浏览器中提供有限的gRPC支持。gRPC Web由两部分组成：支持所有现代浏览器的JavaScript客户端和服务器上的gRPC Web代理。gRPC Web客户端调用代理，代理将在gRPC哀求上转发到gRPC服务器。
gRPC Web并非支持所有gRPC功能。不支持客户端和双向流，并且对服务器流的支持有限。
不是人类可读的
HTTP API哀求以文本形式发送，可以由人读取和创建。
默认情况下，gRPC消息使用protobuf编码。虽然protobuf的发送和接收效率很高，但它的二入制格式是不可读的。protobuf需要在.proto文件中指定的消息接口描述才能准确反序列化。需要额外的工具来分析线路上的Protobuf有效负载，并手工编写哀求。
存在诸如服务器反射和gRPC命令行工具等功能，以帮助处理二入制protobuf消息。另外，Protobuf消息支持与JSON之间的转换。内置的JSON转换提供了一种有效的方法，可以在调试时将Protobuf消息转换为可读的形式。
5.使用场景
建议使用的场景：
- 微服务：gRPC设计为低延迟和高吞吐量通信，非常适用效率至关重要的轻型微服务
- 点对点实时通信：gRPC可以实时推送消息而无需轮询
- 多语言混合开发环境：支持所有流行开发语言
- 网络受限环境：使用Protobuf(一种轻量级消息格式)序列化gRPC消息。gRPC消息始终小于等效的JSON消息
- 不建议使用场景：
- 浏览器可访问的API：浏览器不支持gRPC,gRPC-Web有局限性而且还引进了服务器代理
- 广播实时通信
- 入程间通信
到此这篇关于什么是gRPC的文章就介绍到这了,更多相关gRPC内容请搜索以前的文章或继承浏览下面的相关文章希望大家以后多多支持！
