Область подключения клиента Go gRPC и объединение в пул

Рассмотрим пример из базы кода gRPC Go:

func main() {
    // Set up a connection to the server.
    conn, err := grpc.Dial(address, grpc.WithInsecure())
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }
    defer conn.Close()
    c := pb.NewGreeterClient(conn)

    // Contact the server and print out its response.
    name := defaultName
    if len(os.Args) > 1 {
        name = os.Args[1]
    }
    r, err := c.SayHello(context.Background(), &pb.HelloRequest{Name: name})
    if err != nil {
        log.Fatalf("could not greet: %v", err)
    }
    log.Printf("Greeting: %s", r.Message)
}

При использовании службы gRPC из другой службы, какой должна быть область подключения (conn)? Я предполагаю, что он должен иметь сходство с объемом обрабатываемого запроса в службе потребителей, но мне еще предстоит найти какую-либо документацию по этому поводу. Следует ли мне использовать здесь пул подключений?

E.G.

  1. Служба потребителей gRPC получает запрос
  2. установить соединение с сервисом gRPC (напрямую или через пул)
  3. сделать n запросов к службе gRPC
  4. закрыть соединение gRPC (или отпустить обратно в пул)

go grpc
person Myles McDonnell    schedule 25.01.2018    source источник
comment
Если вы планируете в ближайшее время отправлять больше запросов, вам следует оставить соединение открытым и использовать его повторно. В противном случае или если у вас очень мало ресурсов, вам следует немедленно закрыть его. Однако это действительно невозможно сказать с вашим текущим примером.   -  person Marc    schedule 25.01.2018
comment
Конечно, пример взят из репозитория grpc, чтобы было ясно, что я имею в виду под соединением. Где-то должна быть какая-то документация о том, как использовать соединение ... например, безопасно ли это для одновременного использования?   -  person Myles McDonnell    schedule 25.01.2018
comment
Они безопасны для одновременного использования. Однако у вас есть смысл, что можно использовать некоторую документацию. Кажется, вы не единственный, кто так думает.   -  person Marc    schedule 25.01.2018

Ответы (1)


arrow_upward
11
arrow_downward

По опыту, клиентские подключения gRPC следует повторно использовать в течение всего срока службы клиентского приложения, поскольку они безопасны для одновременного использования. Кроме того, одной из ключевых особенностей gRPC является быстрый ответ на удаленные процедурные вызовы, чего нельзя добиться, если вам придется повторно подключаться при каждом полученном запросе.

Тем не менее, вместе с этими постоянными соединениями настоятельно рекомендуется использовать какую-либо балансировку нагрузки gRPC. В противном случае большая нагрузка может оказаться на нескольких долгоживущих соединениях клиент-сервер grpc. Варианты балансировки нагрузки включают:

  1. Пул соединений gRPC на стороне клиента в сочетании с балансировщиком нагрузки TCP (уровень 4) на стороне сервера. Это сначала создаст пул клиентских подключений и повторно использует этот пул для последующих запросов gRPC. На мой взгляд, это самый простой способ реализовать. См. Объединение подключений gRPC для примера объединения подключений grpc на стороне клиента grpc, который использует < библиотеку href = "https://github.com/processout/grpc-go-pool" rel = "noreferrer"> grpc-go-pool.
  2. Балансировщик нагрузки HTTP / 2 (уровень 7) с поддержкой gRPC для запросов балансировки нагрузки. См. балансировку нагрузки gRPC, в которой представлен обзор различных вариантов балансировки нагрузки grpc. Недавно nginx добавил поддержку балансировки нагрузки gRPC.
person Agrim    schedule 20.03.2018