国家住房城乡建设厅网站,福建国通星驿网络科技有限公司,开发app小程序,南通精诚建设集团有限公司网站今天进行3.0信号整理工作
做官网后台技术文档
了解grpc
gRPC是rpc框架中的一种#xff0c;是rpc中的大哥
是一个高性能#xff0c;开源和通用的RPC框架#xff0c;基于Protobuf序列化协议开发#xff0c;且支持众多开发语言。
面向服务端和协议端#xff0c;基于http…今天进行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的正事规范。开发人员不需要讨论URLHTTP动词和响应代码的最佳格式。不需要考虑用post还是getget还是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有局限性而且还引入了服务器代理
广播实时通信
进程间通信
