Нам от gRPC балансировки в первую очередь нужно, чтобы клиент выбирал живой хост из списка. В таком виде она работает между loadbalancer-controller и loadbalancer-node. Последняя подписывается на изменения состава балансеров, и там как раз мы и используем gRPC балансировку. Пакет memberlist (используется в consul реализует в себе логику service discovery: в ней есть встроенные механизмы healthcheck'ов и распространение их результатов по gossip протоколу. Мы у себя их подружили в таком виде, что memberlist сообщает об изменении списка живых хостов, и мы меняем список хостов в группе gRPC балансировки.
Memberlist мы немного дописывали и возвращали код в open source, но пока пользуемся своим форком. Фактически, проблема только одна в указанном PR: мы наблюдали высокое потребление памяти, но в остальном всё работает хорошо.
В других местах мы просто используем memberlist, потому что дальше у нас возникает шардирование. Цели healthcheck'ов (rip'ы) шардированы по healthcheck-controller'ам, так, что за одну цель отвечает один контроллер (он агрегирует результаты проверок, которые сообщают healthcheck-node). Поэтому loadbalancer-controller'ы подписываются на результаты проверок целей, подключаясь к конкретному healthcheck-controller'у, ответственному за эту цель, так что тут нам gRPC балансировка мешает. При изменении состава healthcheck controller'ов memberlist сообщает нам об этом и мы перераспределяем цели по новому списку healthcheck-controller'ов. Кстати, тут мы также пользуемся консистентным хэшированием примерно по тем же соображениям: легче масштабироваться горизонтально, так как не требуется синхронизация состояний между loadbalancer-controller'ами, и перемещению подвергается небольшая часть целей.
Между healthcheck-controller'ами и healthcheck-node примерно такая же история. Каждая проверка выполняется минимум тремя healthcheck-node'ами, но проверки шардированы между всем множеством нод (условно, если у нас шесть healthcheck-node, то проверка П будет выполняться на трёх из них). Шардирование так же выполняется консистентным хэшированием, и healthcheck-node знают, куда именно нужно отправлять результат, так что тут gRPC балансировка тоже не нужна.
Выше описана клиентская балансировка (у нас round-robin, но, опять же, нас скорее интересует исключение мёртвых хостов, чем непосредственно балансировка, так как в большинстве случаев мы работаем с gRPC stream'ами). Для серверной баланировки gRPC я бы рекомендовал попробовать envoy (например, вот статья с историей успеха), там реализовано несколько алгоритмов балансировки, в том числе и динамические.
Нам от gRPC балансировки в первую очередь нужно, чтобы клиент выбирал живой хост из списка. В таком виде она работает между loadbalancer-controller и loadbalancer-node. Последняя подписывается на изменения состава балансеров, и там как раз мы и используем gRPC балансировку. Пакет memberlist (используется в consul реализует в себе логику service discovery: в ней есть встроенные механизмы healthcheck'ов и распространение их результатов по gossip протоколу. Мы у себя их подружили в таком виде, что memberlist сообщает об изменении списка живых хостов, и мы меняем список хостов в группе gRPC балансировки.
Memberlist мы немного дописывали и возвращали код в open source, но пока пользуемся своим форком. Фактически, проблема только одна в указанном PR: мы наблюдали высокое потребление памяти, но в остальном всё работает хорошо.
В других местах мы просто используем memberlist, потому что дальше у нас возникает шардирование. Цели healthcheck'ов (rip'ы) шардированы по healthcheck-controller'ам, так, что за одну цель отвечает один контроллер (он агрегирует результаты проверок, которые сообщают healthcheck-node). Поэтому loadbalancer-controller'ы подписываются на результаты проверок целей, подключаясь к конкретному healthcheck-controller'у, ответственному за эту цель, так что тут нам gRPC балансировка мешает. При изменении состава healthcheck controller'ов memberlist сообщает нам об этом и мы перераспределяем цели по новому списку healthcheck-controller'ов. Кстати, тут мы также пользуемся консистентным хэшированием примерно по тем же соображениям: легче масштабироваться горизонтально, так как не требуется синхронизация состояний между loadbalancer-controller'ами, и перемещению подвергается небольшая часть целей.
Между healthcheck-controller'ами и healthcheck-node примерно такая же история. Каждая проверка выполняется минимум тремя healthcheck-node'ами, но проверки шардированы между всем множеством нод (условно, если у нас шесть healthcheck-node, то проверка П будет выполняться на трёх из них). Шардирование так же выполняется консистентным хэшированием, и healthcheck-node знают, куда именно нужно отправлять результат, так что тут gRPC балансировка тоже не нужна.
Выше описана клиентская балансировка (у нас round-robin, но, опять же, нас скорее интересует исключение мёртвых хостов, чем непосредственно балансировка, так как в большинстве случаев мы работаем с gRPC stream'ами). Для серверной баланировки gRPC я бы рекомендовал попробовать envoy (например, вот статья с историей успеха), там реализовано несколько алгоритмов балансировки, в том числе и динамические.