Распределение нагрузки на стороне клиента GRPC: один из узлов выходит из строя - PullRequest
Новая
       39

Распределение нагрузки на стороне клиента GRPC: один из узлов выходит из строя

0 голосов
/ 24 января 2019

Для службы Grpc используется балансировка нагрузки на стороне клиента.

Создание канала 

ManageChannelBuilder.forTarget("host1:port,host2:port,host3:port").nameResolverFactory(new CustomNameResolverProvider()).loadBalancerFactory(RoundRobinBalancerFactory.getInstance()).usePlaintText(true).build();

Используйте этот канал для создания заглушки.

Проблема

Если один из сервисов [host1] выйдет из строя, будет ли заглушка обрабатывать этот сценарий и не отправлять дальнейшие запросы на сервис [host1]?

Согласно документациив https://grpc.io/blog/loadbalancing

Толстый клиентский подход означает, что в клиенте реализованы интеллектуальные функции балансировки нагрузки.Клиент отвечает за отслеживание доступных серверов, их рабочей нагрузки и алгоритмов, используемых для выбора серверов.Клиент обычно объединяет библиотеки, которые взаимодействуют с другими инфраструктурами, такими как обнаружение служб, разрешение имен, управление квотами и т. Д.вести список активного списка серверов и каждый раз создавать экземпляр ManagedChannel со списком активных серверов?

Результат теста

Согласно тесту, если один из сервисов выходит из строяне влияет на балансировку нагрузки и все запросы обрабатываются корректно.

Итак, можно ли предположить, что заглушка или класс ManagedChannel обрабатывают список активных серверов?

Ответ с документацией будет высоко оценен.

1 Ответ

0 голосов
/ 24 января 2019

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

Pick First (по умолчанию), перебирает адреса, пока не сработает. Круглый Робин только круглые робины над рабочими соединениями. То, что вы описываете, должно работать нормально.

Отмечу, что у вашего подхода есть один недостаток: вы не можете менять серверы во время работы процесса. Удаление сломанных бэкэндов - это одно, а добавление новых рабочих бекендов - другое. Если ваша нагрузка слишком высока, вы не сможете решить проблему, добавив больше работников, потому что даже если вы добавите больше работников, ваши клиенты не будут к ним подключаться.

...