grpc Q&A问答

妖狐艹你老母 2022-12-09 05:22 18阅读 0赞

## gRPC Metadata 是通过什么传输？ ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center]

## 调用 grpc.Dial 会真正的去连接服务端吗？ ##

会，但是是异步连接的，连接状态为正在连接。但如果你设置了 grpc.WithBlock 选项，就会阻塞等待（等待握手成功）。另外你需要注意，当未设置 grpc.WithBlock 时，ctx 超时控制对其无任何效果。

## 调用 ClientConn 不 Close 会导致泄露吗？ ##

会，除非你的客户端不是常驻进程，那么在应用结束时会被动地回收资源。但如果是常驻进程，你又真的忘记执行 Close语句，会造成的泄露。如下图：

1.  client  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center 1]
2.  server  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center 2]
3.  tcp  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center 3]

## 不控制超时调用的话，会出现什么问题？ ##

短时间内不会出现问题，但是会不断积蓄泄露，积蓄到最后当然就是服务无法提供响应了。如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center 4]

## 为什么默认的拦截器不可以传多个？ ##

func chainUnaryClientInterceptors(cc *ClientConn) {
        
    	interceptors := cc.dopts.chainUnaryInts
    	if cc.dopts.unaryInt != nil {
        
    		interceptors = append([]UnaryClientInterceptor{
        cc.dopts.unaryInt}, interceptors...)
    	}
    	var chainedInt UnaryClientInterceptor
    	if 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 链式方法，方便快捷省心。

单单会用还不行，我们再深剖一下，看看它是怎么实现的。核心代码如下：

func ChainUnaryClient(interceptors ...grpc.UnaryClientInterceptor) grpc.UnaryClientInterceptor {
        
    	n := len(interceptors)
    	if n > 1 {
        
    		lastI := n - 1
    		return func(ctx context.Context, method string, req, reply interface{
        }, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
        
    			var (
    				chainHandler grpc.UnaryInvoker
    				curI         int
    			)
    
    			chainHandler = func(currentCtx context.Context, currentMethod string, currentReq, currentRepl interface{
        }, currentConn *grpc.ClientConn, currentOpts ...grpc.CallOption) error {
        
    				if curI == lastI {
        
    					return invoker(currentCtx, currentMethod, currentReq, currentRepl, currentConn, currentOpts...)
    				}
    				curI++
    				err := interceptors[curI](currentCtx, currentMethod, currentReq, currentRepl, currentConn, chainHandler, currentOpts...)
    				curI--
    				return err
    			}
    
    			return interceptors[0](ctx, method, req, reply, cc, chainHandler, opts...)
    		}
    	}
        ...
    }

当拦截器数量大于 1 时，从 interceptors\[1\] 开始递归，每一个递归的拦截器 interceptors\[i\] 会不断地执行，最后才真正的去执行 handler 方法。同时也经常有人会问拦截器的执行顺序是什么，通过这段代码你得出结论了吗？

## 频繁创建 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，这样做科学不少。

## 在 Kubernetes 中 gRPC 负载均衡有问题？ ##

gRPC 的 RPC 协议是基于 HTTP/2 标准实现的，HTTP/2 的一大特性就是不需要像 HTTP/1.1 一样，每次发出请求都要重新建立一个新连接，而是会复用原有的连接。

所以这将导致 kube-proxy 只有在连接建立时才会做负载均衡，而在这之后的每一次 RPC 请求都会利用原本的连接，那么实际上后续的每一次的 RPC 请求都跑到了同一个地方。

注：使用 k8s service 做负载均衡的情况下

# 总结 #

1.  gRPC 基于 HTTP/2 + Protobuf。
2.  gRPC 有四种调用方式，分别是一元、服务端/客户端流式、双向流式。
3.  gRPC 的附加信息都会体现在 HEADERS 帧，数据在 DATA 帧上。
4.  Client 请求若使用 grpc.Dial 默认是异步建立连接，当时状态为 Connecting。
5.  Client 请求若需要同步则调用 WithBlock()，完成状态为 Ready。
6.  Server 监听是循环等待连接，若没有则休眠，最大休眠时间 1s；若接收到新请求则起一个新的 goroutine 去处理。
7.  grpc.ClientConn 不关闭连接，会导致 goroutine 和 Memory 等泄露。
8.  任何内/外调用如果不加超时控制，会出现泄漏和客户端不断重试。
9.  特定场景下，如果不对 grpc.ClientConn 加以调控，会影响调用。
10. 拦截器如果不用 go-grpc-middleware 链式处理，会覆盖。
11. 在选择 gRPC 的负载均衡模式时，需要谨慎。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/197281f717f64c968bb950851ed59666.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/46f7ddcab02545c683d10744a1268190.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/155fff8a78d34a06a73c71ca1d58d5e6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/1ff79803a7ba4bcebdf7d0c4851b6455.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMyNDY4OTg_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221123/c026bac5a9f1433bb7aafa84fd3d5d39.png