漫谈grpc 3：从实践到原理，带你参透 gRPC (7)

在该方法中会不断地去尝试创建连接，若成功则结束。否则不断地根据 Backoff 算法的重试机制去尝试创建连接，直到成功为止。从结论上来讲，单纯调用 DialContext 是异步建立连接的，也就是并不是马上生效，处于 Connecting 状态，而正式下要到达 Ready 状态才可用。

真的连了吗

​

在抓包工具上提示一个包都没有，那么这算真正连接了吗？我认为这是一个表述问题，我们应该尽可能的严谨。如果你真的想通过 DialContext 方法就打通与服务端的连接，则需要调用 WithBlock 方法，虽然会导致阻塞等待，但最终连接会到达 Ready 状态（握手成功）。如下图：

​

二、实例化 Service API type SearchServiceClient interface {  Search(ctx context.Context, in *SearchRequest, opts ...grpc.CallOption) (*SearchResponse, error) } type searchServiceClient struct {  cc *grpc.ClientConn } func NewSearchServiceClient(cc *grpc.ClientConn) SearchServiceClient {  return &searchServiceClient{cc} }

这块就是实例 Service API interface，比较简单。

三、调用 // search.pb.go func (c *searchServiceClient) Search(ctx context.Context, in *SearchRequest, opts ...grpc.CallOption) (*SearchResponse, error) {  out := new(SearchResponse)  err := c.cc.Invoke(ctx, "/proto.SearchService/Search", in, out, opts...)  if err != nil {   return nil, err  }  return out, nil }

proto 生成的 RPC 方法更像是一个包装盒，把需要的东西放进去，而实际上调用的还是 grpc.invoke 方法。如下：

func invoke(ctx context.Context, method string, req, reply interface{}, cc *ClientConn, opts ...CallOption) error {  cs, err := newClientStream(ctx, unaryStreamDesc, cc, method, opts...)  if err != nil {   return err  }  if err := cs.SendMsg(req); err != nil {   return err  }  return cs.RecvMsg(reply) }

通过概览，可以关注到三块调用。如下：

newClientStream：获取传输层 Trasport 并组合封装到 ClientStream 中返回，在这块会涉及负载均衡、超时控制、 Encoding、 Stream 的动作，与服务端基本一致的行为。

cs.SendMsg：发送 RPC 请求出去，但其并不承担等待响应的功能。

cs.RecvMsg：阻塞等待接受到的 RPC 方法响应结果。

连接

// clientconn.go func (cc *ClientConn) getTransport(ctx context.Context, failfast bool, method string) (transport.ClientTransport, func(balancer.DoneInfo), error) {  t, done, err := cc.blockingpicker.pick(ctx, failfast, balancer.PickOptions{   FullMethodName: method,  })  if err != nil {   return nil, nil, toRPCErr(err)  }  return t, done, nil }