3.6日报

今天进行3.0信号整理工作

做官网后台技术文档

了解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有局限性而且还引入了服务器代理

广播实时通信

进程间通信