用心做电影的网站,关键词都有哪些,网站公司怎么做的好,网站建站网站看看了解 gRPC 通信模式中的消息流
gRPC 支持四种通信模式#xff0c;分别是简单 RPC、服务端流式 RPC、客户端流式 RPC 和双向流式 RPC。
简单 RPC
在gRPC中#xff0c;一个简单的RPC调用遵循请求-响应模型#xff0c;通常涉及以下几个关键步骤和组件#xff1a;
请求头分别是简单 RPC、服务端流式 RPC、客户端流式 RPC 和双向流式 RPC。
简单 RPC
在gRPC中一个简单的RPC调用遵循请求-响应模型通常涉及以下几个关键步骤和组件
请求头Request Header: 客户端Client发起请求时首先发送一个请求头其中包含元数据如目标服务、方法等。长度前缀消息Length-Prefixed Message:在请求头后面客户端发送实际的RPC消息。这个消息一般会有一个长度前缀以便服务端Server可以准确地解析它。数据帧Data Frames: 一个消息可能会分成多个数据帧进行传输这取决于消息的大小和底层传输协议的限制。流结束标志EOS, End Of Stream:客户端在发送完所有数据帧后会设置一个EOS标志。这标志着客户端对该请求的“半关闭”状态意味着客户端将不再发送更多数据但仍然可以接收来自服务端的响应。响应头Response Header: 服务端在收到并解析完整的请求消息后首先发送一个响应头。响应消息Response Message: 随后服务端发送实际的响应消息该消息也是一个长度前缀的格式。Trailers: 最后服务端通过发送一个带有状态详细信息的Trailers头来结束通信。
服务端流式 RPC
从 client 端的角度来看简单 RPC 和服务端流式 RPC 具有相同的请求消息流。在这两种情况下我们都会发送一条请求消息。主要区别在于 server 端。server 端会发送多条消息而不是向 client 端发送一条响应消息。server 端一直等待直到收到完整的请求消息之后发送响应头和多个带长度前缀的消息。一旦 server 端发送带有状态详细信息的 Trailers 标头通信就会结束。 客户端流式 RPC
在客户端流式 RPC 中client 端向 server 端发送多条消息server 端发送一条响应消息作为回复。client 端首先通过发送请求头帧建立与 server 端的连接。建立连接后client 端会向 server 端发送多个长度前缀消息作为数据帧。最后client 端通过在最后一个数据帧中发送一个 EOS 标志来半关闭连接。同时server 端读取从 client 端接收到的消息。一旦接收到所有消息server 端就会发送响应消息以及 Trailers 标头并关闭连接。
双向流式 RPC
在此模式中client 端通过发送请求头帧来建立连接。一旦建立连接client 端和 server 端都可以直接发送多个长度前缀消息而无需等待对方完成。双方都可以自主结束连接这意味着他们不能再发送任何消息。
gRPC 实现架构
如下图所示gRPC 采用分层架构实现。 在gRPC的架构中核心组件分为以下几层
gRPC Core 层: 这是gRPC架构中的底层负责网络操作的所有底层细节。它提供了一组核心API和功能如流控制、安全认证、以及其他低级网络操作。语言绑定Language Bindings: gRPC原生支持C/C、Go和Java但也提供了多种流行编程语言的语言绑定包括PythonRuby、PHP等。这些绑定通常是对gRPC Core层的C API的高级包装使得在特定语言中使用gRPC更加方便。应用层Application Layer: 这一层位于语言绑定之上处理应用逻辑和数据编码逻辑。开发人员通常使用IDL接口定义语言编译器如Protocol Buffers编译器为特定的数据结构生成源代码。这些生成的代码会被集成到应用层逻辑中用于序列化和反序列化消息。
通过这种层次结构gRPC实现了从底层网络操作到高级应用逻辑的完全抽象允许开发人员集中精力在RPC逻辑的实现上而无需担心底层的网络细节。这种架构不仅使得代码更易于管理和扩展还支持跨语言和跨平台的通信大大提高了开发效率。 QA
gRPC Metadata 是通过什么传输 在gRPC中Metadata是通过HTTP/2 headers和trailers来传输的。Metadata是键值对的集合用于传递与请求或响应相关的附加信息。这些信息可能包括诸如认证令牌、自定义消息头、请求ID等。
请求头Request Headers: 在一个gRPC调用开始时客户端会发送HTTP/2 headers其中可以包括初始化该调用所需的Metadata。例如这里可能包含身份验证相关的令牌。响应头Response Headers: 与之类似服务端在响应开始时也会发送HTTP/2 headers这些也可以携带Metadata。这通常用于传递关于请求状态或其他重要信息的指示。Trailers: 在请求或响应完成时可以通过HTTP/2 trailers发送额外的Metadata。这常用于携带状态信息例如gRPC的状态码和错误消息。
在一个典型的gRPC调用中客户端会首先发送包含Metadata的HTTP/2 headers然后发送编码后的RPC message。服务端在接收到这些信息后会解析Metadata和RPC message并根据这些执行相应的操作然后返回响应和响应的Metadata。
调用 grpc.Dial 会真正的去连接服务端吗
会但是是异步连接的连接状态为正在连接。但如果你设置了 grpc.WithBlock 选项就会阻塞等待等待握手成功。另外你需要注意当未设置 grpc.WithBlock 时ctx 超时控制对其无任何效果。
调用 ClientConn 不 Close 会导致泄露吗
会除非你的客户端不是常驻进程那么在应用结束时会被动地回收资源。但如果是常驻进程你又真的忘记执行 Close 语句会造成的泄露。如下图
不控制超时调用的话会出现什么问题
短时间内不会出现问题但是会不断积蓄泄露积蓄到最后当然就是服务无法提供响应了。如下图
为什么默认的拦截器不可以传多个
func chainUnaryClientInterceptors(cc *ClientConn) {interceptors : cc.dopts.chainUnaryIntsif cc.dopts.unaryInt ! nil {interceptors append([]UnaryClientInterceptor{cc.dopts.unaryInt}, interceptors...)}var chainedInt UnaryClientInterceptorif len(interceptors) 0 {chainedInt nil} else if len(interceptors) 1 {chainedInt interceptors[0]} else {chainedInt func(ctx context.Context, method string, req, reply interface{}, cc *ClientConn, invoker UnaryInvoker, opts ...CallOption) error {return interceptors[0](ctx, method, req, reply, cc, getChainUnaryInvoker(interceptors, 0, invoker), opts...)}}cc.dopts.unaryInt chainedInt
}当存在多个拦截器时取的就是第一个拦截器。因此结论是允许传多个但并没有用。
真的需要用到多个拦截器的话怎么办
可以使用 go-grpc-middleware 提供的 grpc.UnaryInterceptor 和 grpc.StreamInterceptor 链式方法方便快捷省心。
频繁创建 ClientConn 有什么问题
这个问题我们可以反向验证一下假设不共用 ClientConn 看看会怎么样如下:
func BenchmarkSearch(b *testing.B) {for i : 0; i b.N; i {conn, err : GetClientConn()if err ! nil {b.Errorf(GetClientConn err: %v, err)}_, err Search(context.Background(), conn)if err ! nil {b.Errorf(Search err: %v, err)}}
}输出结果 ... connection error: desc transport: Error while dialing dial tcp :10001: socket: too many open files... connection error: desc transport: Error while dialing dial tcp :10001: socket: too many open files... connection error: desc transport: Error while dialing dial tcp :10001: socket: too many open files... connection error: desc transport: Error while dialing dial tcp :10001: socket: too many open files
FAIL
exit status 1当你的应用场景是存在高频次同时生成/调用 ClientConn 时可能会导致系统的文件句柄占用过多。这种情况下你可以变更应用程序生成/调用 ClientConn 的模式又或是池化它这块可以参考 grpc-go-pool 项目。
客户端请求失败后会默认重试吗
会不断地进行重试直到上下文取消。而重试时间方面采用 backoff 算法作为的重连机制默认的最大重试时间间隔是 120s。
为什么要用 HTTP/2 作为传输协议
许多客户端要通过 HTTP 代理来访问网络gRPC 全部用 HTTP/2 实现等到代理开始支持 HTTP/2 就能透明转发 gRPC 的数据。不光如此负责负载均衡、访问控制等等的反向代理都能无缝兼容 gRPC比起自己设计 wire protocol 的 Thrift这样做科学不少。 总结
gRPC 是一个高性能的远程过程调用RPC框架它主要依赖于两个关键技术Protocol Buffers和HTTP/2。
Protocol Buffers:这是一个高效的数据序列化协议用于编码和解码消息。由于其二进制格式和强类型定义它通常比传统的JSON或XML更高效具有更小的数据尺寸和更快的序列化/反序列化速度。这种优化的数据表达方式在网络传输中起到了至关重要的作用尤其是在需要低延迟和高吞吐量的场景中。HTTP/2: 相较于其前身HTTP/1.xHTTP/2提供了多路复用Multiplexing功能使得多个请求和响应可以在单一的TCP连接上并行传输。这减少了网络延迟并允许更高效的资源利用。此外HTTP/2还支持其他高级特性如头部压缩、优先级设置等进一步优化了网络性能。
结合这两个高效的协议gRPC能够提供低延迟、高吞吐量和高可扩展性使其成为一个理想的选择用于构建分布式系统和微服务架构。同时多路复用和高效的数据序列化也使得gRPC非常适用于移动应用、IoT设备以及其他网络受限的场景。 参考
https://segmentfault.com/a/1190000019608421
https://learnku.com/articles/72847
