gRPCクライアントはサーバーを呼び出すために接続プールを必要としますか？

問題が発見されました

マイクロサービスの開発では、gRPCの適用が絶対に必要です。一般に、内部マイクロサービスの相互作用は、通常、通信にRPCを使用します。外部通信の場合は、httpsインターフェイスのドキュメントが提供されます。

gRPCの基本的な使用法については、gRPCの概要の記事を参照してください。

gRPCの場合、次の基本的な知識ポイントを知る必要があります。

• gRPCの基本的な4つのモードのアプリケーションシナリオ

  • 要求/応答モード
  • クライアントストリーミングモード
  • サーバーデータフローモード
  • 双方向フローモード

• Protoファイルの定義と使用

• gRPCインターセプターのアプリケーション、基本的にこのgRPCインターセプターをチェックすることができます

  • 実際、クライアント側のインターセプターとサーバー側のインターセプターがあり、自分で詳細を学ぶことができます

• gRPCの設計原理の詳細

• ゴーキットの使用

もちろん、今日はgRPCのアプリケーションや原理について話すのではなく、開発プロセスで簡単に遭遇する問題について話すことです。

• gRPCクライアント接続が多重化されていないため、パフォーマンスに影響します

各サービスコードの最近のレビューでは、部門全体がgRPCクライアントを使用してサーバーインターフェイスを要求すると、新しい接続が作成され、サーバーインターフェイスが呼び出され、使用後に閉じられることがわかりました。たとえば、

これで何が問題になる可能性がありますか？

通常の簡単な使用では問題ありませんが、同時実行性が高いとパフォーマンスの問題が発生しやすくなります。たとえば、パフォーマンステストを行っていると、しばらくパフォーマンステストを行った後、クライアントがサービスを要求すると、最後にエラーが報告されます。

rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp xxx:xxx: connect: connection refused

実際に問題を確認したところ、gRPC接続の数がいっぱいで、多くの接続が完全に解放されていなかったことがわかりました。

現時点では、考えてみれば、クライアントがサーバーインターフェイスを要求するたびに新しい接続を確立し、呼び出しが完了した直後に接続を閉じる必要はありません。

我们知道，gRPC 的通信本质上也是 TCP 的连接，那么一次连接就需要三次握手，和四次挥手，每一次建立连接和释放连接的时候，都需要走这么一个过程，如果我们频繁的建立和释放连接，这对于资源和性能其实都是一个大大的浪费

我们还知道 gRPC 是一个高性能、开源和拥有统一规定的 RPC框架，面向对象的 http/2 通信协议，能够能节省空间和 IO 密集度的开销 ，但是我们并没有很好的将他运用起来，gRPC 服务端的连接管理不用我们操心，但是我们对于 gRPC 客户端的连续非常有必要关心，咱们要想办法复用客户端的连接

gRPC 连接池

复用连接，我们可以使用连接池的方式

对于这种复用资源，我们其实也接触了不少，例如复用线程 worker 的线程池，go 中的协程池 ..

简单来说，连接池 ，就是提前创建好一定数量的 tcp 连接句柄放在池子中，咱们需要和外部通信的时候，就去池子中取一个连接来用，用完了之后，咱们就放回去

连接池解决了什么问题

很明显，连接池解决了上述咱们频繁创建连接和释放连接带来的资源和性能上的损耗，咱们节省了这部分开销后，自然就提高了咱们的性能

可是我们再次思考一下，如果这个连接池子就是只能存放固定的连接，那么我们业务扩张的时候，岂不是光等待池子里面有空闲连接就会耗费大量的时间呢？

或者是池子过大，咱们需要的连接数较少，那么开辟那么多连接岂不是一种浪费？

那么我们在设计或者是应用连接池的时候，就需要考虑如下几个方面了：

• 连接池是否支持扩缩容

• 空闲的连接是否支持超时自行关闭，是否支持保活

• 池子满的时候，处理的策略是什么样的

其实关于连接池的设计和库网上都很多，我们可以找一个案例来看看如何来使用连接池，以及它是如何来进行上述几个方面的编码落地的

如何去使用连接池

先来看看客户端如何使用连接池

客户端使用 pool

client/main.go

package main

import (
        "context"
        "flag"
        "fmt"
        "log"
        "time"

        "mypoolclient/pool"
        "mypoolclient/pb"
)

var addr = flag.String("addr", "127.0.0.1:8888", "the address to connect to")

func main() {
        flag.Parse()

        p, err := pool.New(*addr, pool.DefaultOptions)
        if err != nil {
                log.Fatalf("failed to new pool: %v", err)
        }
        defer p.Close()

        conn, err := p.Get()
        if err != nil {
                log.Fatalf("failed to get conn: %v", err)
        }
        defer conn.Close()

        client := pb.NewTestsvrClient(conn.Value())
        ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
        defer cancel()

        res, err := client.Say(ctx, &pb.TestReq{Message: []byte("hi")})
        if err != nil {
                log.Fatalf("unexpected error from Say: %v", err)
        }
        fmt.Println("rpc response:", res)
}

此处的客户端，我们很明显可以看出来，以前咱们使用客户端去调用服务端接口的时候，总会不自觉的 Dial 一下建立连接

咱们使用连接池的话，就可以直接从池子里面拿一个连接出来直接使用即可

服务端

server/client.go

package main

import (
        "context"
        "flag"
        "fmt"
        "log"
        "net"

        "google.golang.org/grpc"

        "mypoolserver/pb"
)

var port = flag.Int("port", 8888, "port number")

// server implements EchoServer.
type server struct{}

func (s *server) Say(context.Context, *pb.TestReq) (*pb.TestRsp, error) {
        fmt.Println("call  Say ... ")
        return &pb.TestRsp{Message: []byte("hello world")}, nil
}

func main() {
        flag.Parse()

        listen, err := net.Listen("tcp", fmt.Sprintf("127.0.0.1:%v", *port))
        if err != nil {
                log.Fatalf("failed to listen: %v", err)
        }

        s := grpc.NewServer()
        pb.RegisterTestsvrServer(s, &server{})
        fmt.Println("start server ...")

        if err := s.Serve(listen); err != nil {
                log.Fatalf("failed to serve: %v", err)
        }


        fmt.Println("over server ...")
}

连接池的具体实现方式

连接池的具体实现方式，参考了 github https://github.com/shimingyah/pool

具体的实现，都放在上述目录的 pool 下面了 ， 也可以访问地址 ： https://github.com/qingconglaixueit/mypoolapp

pool 包中包含了 3 个文件，作用如下：

.

├── conn.go

-- 关于 grpc 连接的结构定义和方法实现

├── options.go

-- 拦截器的常量定义，以及 Dial 建立连接的简单封装， 这个文件可要可不要，看自己的需求

└── pool.go

-- 具体 pool 的接口定义和实现

直接来看 pool.go 中的接口定义

type Pool interface {
   Get() (Conn, error)

   Close() error

   Status() string
}

• Get()

获取一个新的连接 ， 当关闭连接的时候，会将该连接放入到池子中

• Close()

关闭连接池，自然连接池子中的连接也不再可用

关于 pool 结构的定义 ，conn 结构的定义建议，将上述 github 地址上的源码下载下来进行阅读，下面主要是分享关于

• 连接池子的创建，扩缩容，释放

• 具体 TCP 连接的创建和释放

创建连接池

func New(address string, option Options) (Pool, error) {
   if address == "" {
      return nil, errors.New("invalid address settings")
   }
   if option.Dial == nil {
      return nil, errors.New("invalid dial settings")
   }
   if option.MaxIdle <= 0 || option.MaxActive <= 0 || option.MaxIdle > option.MaxActive {
      return nil, errors.New("invalid maximum settings")
   }
   if option.MaxConcurrentStreams <= 0 {
      return nil, errors.New("invalid maximun settings")
   }

   p := &pool{
      index:   0,
      current: int32(option.MaxIdle),
      ref:     0,
      opt:     option,
      conns:   make([]*conn, option.MaxActive),
      address: address,
      closed:  0,
   }

   for i := 0; i < p.opt.MaxIdle; i++ {
      c, err := p.opt.Dial(address)
      if err != nil {
         p.Close()
         return nil, fmt.Errorf("dial is not able to fill the pool: %s", err)
      }
      p.conns[i] = p.wrapConn(c, false)
   }
   log.Printf("new pool success: %v\n", p.Status())

   return p, nil
}

关于 pool 的接口，可以看成是这样的

对于创建连接池，除了校验基本的参数以外，我们知道池子其实是一个 TCP 连接的切片，长度为 option.MaxActive 即最大的活跃连接数

p.conns[i] = p.wrapConn(c, false) 表示咱们初始化一个连接，并放到连接池中，且初始化的 once 参数置为 false，表示该连接默认保存在池子中，不被销毁

换句话说，当我们需要真实销毁连接池中的连接的时候，就将该链接的 once 参数置为 false 即可，实际上也无需我们使用这去做这一步

实际上 关于每一个连接的建立也是在 New 里面完成的，只要有 1 个连接未建立成功，那么咱们的连接池就算是建立失败，咱们会调用 p.Close() 将之前建立好的连接全部释放掉

// 关闭连接池
func (p *pool) Close() error {
   atomic.StoreInt32(&p.closed, 1)
   atomic.StoreUint32(&p.index, 0)
   atomic.StoreInt32(&p.current, 0)
   atomic.StoreInt32(&p.ref, 0)
   p.deleteFrom(0)
   log.Printf("close pool success: %v\n", p.Status())
   return nil
}

// 清除从 指定位置开始到 MaxActive 之间的连接
func (p *pool) deleteFrom(begin int) {
   for i := begin; i < p.opt.MaxActive; i++ {
      p.reset(i)
   }
}

// 清除具体的连接
func (p *pool) reset(index int) {
   conn := p.conns[index]
   if conn == nil {
      return
   }
   conn.reset()
   p.conns[index] = nil
}

这里我们可以看到，当需要从池子中清除具体的连接的时候，最终从连接池子中取出对应位置上的连接 ，conn := p.conns[index]， conn.reset() ，实际上是给当前这个连接进行参数赋值

func (c *conn) reset() error {
   cc := c.cc
   c.cc = nil
   c.once = false
   if cc != nil {
      return cc.Close()
   }
   return nil
}

func (c *conn) Close() error {
   c.pool.decrRef()
   if c.once {
      return c.reset()
   }
   return nil
}

最终调用 Close() 将指定的连接清除掉，这些动作都是连接池自动给我们做了，无需我们使用者去担心

我们使用连接池通过 pool.Get() 拿到具体的连接句柄 conn 之后，我们使用 conn.Close() 关闭连接，实际上也是会走到上述的 Close() 实现的位置，但是我们并未指定当然也没有权限显示的指定将 once 置位为 false ，因此对于调用者来说，是关闭了连接，对于连接池来说，实际上是将连接归还到连接池中

关于连接池子的缩容和扩容是在 pool.Get() 中实现的

func (p *pool) Get() (Conn, error) {
   // the first selected from the created connections
   nextRef := p.incrRef()
   p.RLock()
   current := atomic.LoadInt32(&p.current)
   p.RUnlock()
   if current == 0 {
      return nil, ErrClosed
   }
   if nextRef <= current*int32(p.opt.MaxConcurrentStreams) {
      next := atomic.AddUint32(&p.index, 1) % uint32(current)
      return p.conns[next], nil
   }

   // the number connection of pool is reach to max active
   if current == int32(p.opt.MaxActive) {
      // the second if reuse is true, select from pool's connections
      if p.opt.Reuse {
         next := atomic.AddUint32(&p.index, 1) % uint32(current)
         return p.conns[next], nil
      }
      // the third create one-time connection
      c, err := p.opt.Dial(p.address)
      return p.wrapConn(c, true), err
   }

   // the fourth create new connections given back to pool
   p.Lock()
   current = atomic.LoadInt32(&p.current)
   if current < int32(p.opt.MaxActive) && nextRef > current*int32(p.opt.MaxConcurrentStreams) {
      // 2 times the incremental or the remain incremental
      increment := current
      if current+increment > int32(p.opt.MaxActive) {
         increment = int32(p.opt.MaxActive) - current
      }
      var i int32
      var err error
      for i = 0; i < increment; i++ {
         c, er := p.opt.Dial(p.address)
         if er != nil {
            err = er
            break
         }
         p.reset(int(current + i))
         p.conns[current+i] = p.wrapConn(c, false)
      }
      current += i
      log.Printf("grow pool: %d ---> %d, increment: %d, maxActive: %d\n",
         p.current, current, increment, p.opt.MaxActive)
      atomic.StoreInt32(&p.current, current)
      if err != nil {
         p.Unlock()
         return nil, err
      }
   }
   p.Unlock()
   next := atomic.AddUint32(&p.index, 1) % uint32(current)
   return p.conns[next], nil
}

从 Get 的实现中，我们可以知道 Get 的逻辑如下

• 先增加连接的引用计数，如果在设定 current*int32(p.opt.MaxConcurrentStreams) 范围内，那么直接取连接进行使用即可

• 現在の接続数がアクティブな接続の最大数に達した場合、新しいプールを作成するときに渡されたオプションの再利用パラメーターがtrueであるかどうかによって異なります。再利用、新しい接続を作成します

• それ以外の場合は、接続プールを2倍または1倍に拡張する必要があります。

実際、これが本当に必要な場合、上記のライブラリはスケーリングアルゴリズムを提供しません

Get実装を縮小することも可能です。具体的な縮小戦略は、実際の状況に応じて決定できます。たとえば、参照カウントnextRefが現在のアクティブな接続数の20％にすぎない場合（これは単なる例です）、収縮を考慮することができます。スパン

読んでくれてありがとう、交換へようこそ、いいねをして、波をたどって行きます

ナゲッツテクノロジーコミュニティのクリエイター署名プログラムの募集に参加しています。リンクをクリックして登録し、送信してください。