Какие именно есть варианты grpc service discovery с минимальным откликом?

Ссылка скопирована
Java soa Облачные вычисления
1 ответ

Ищу ServiceDiscovery с возможностью коннекта по grПК.

Сейчас ситуация такая: основная проблема - общее время обработки запроса. Сейчас custom ServiceDiscovery by grПК обеспечивает get serviceInstance в пределах 2-3ms на Desktop. Проверял Eureca, ZooKeeper, Consul. Это слишком медленно.

Сейчас ситуация такая: есть-ли public решения, которые обеспечивают производительность на уровне 300+ запрос/сек для обнаружения
Сервиса?

Нужно решить такую задачу?

Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.

Заказать помощь
Лучший ответ
1
Стас DB Ответ

Для gRPC service discovery с минимальным откликом лучше выбирать не «самый модный» вариант, а тот, который ближе к вашей инфраструктуре. Сам gRPC умеет работать с name resolver и load balancing policy, но discovery обычно дает внешняя система: Kubernetes DNS, Consul, etcd, Eureka, xDS/Envoy или облачный service registry.

Если сервисы живут в Kubernetes, самый простой и быстрый вариант — обычный Kubernetes Service плюс DNS. Для большинства внутренних API этого достаточно. Если нужны advanced retries, traffic splitting, mTLS и наблюдаемость, добавляют Envoy/xDS или service mesh.

  • Kubernetes DNS: просто, дешево, достаточно для большинства сервисов;
  • Consul: хорошо для VM/bare metal и смешанной инфраструктуры;
  • etcd: низкоуровневый вариант, требует своей логики клиента;
  • Envoy/xDS: мощно для балансировки, retries, circuit breaking;
  • Eureka: чаще встречается в Java/Spring-экосистеме.

Для минимального отклика важен не только discovery, но и то, как клиент переиспользует соединения. gRPC держит HTTP/2 connection, поэтому постоянное пересоздание channel убивает latency. Channel должен быть долгоживущим, а discovery должен обновлять список endpoints без пересоздания всего клиента.

Практическая схема:
client -> grpc channel -> resolver -> список endpoints
client-side LB: round_robin / pick_first
health checks: обязательны
timeouts: короткие и явные
retries: только для idempotent методов

Практическая схема: client -> grpc channel -> resolver -> список endpoints client-side LB: round_robin / pick_first health checks: обязательны timeouts: короткие и явные retries: только для idempotent методов

Если у вас Java, посмотрите в сторону grpc-java name resolver или интеграции через Spring Cloud, но без лишней магии. Для Kubernetes часто достаточно адреса вида service.namespace.svc.cluster.local. Для VM-парка я бы выбрал Consul. Для высоконагруженной платформы с тонким управлением трафиком — Envoy/xDS. Начните с простого DNS/discovery и измерьте p95/p99, потому что усложнение инфраструктуры не всегда уменьшает задержку.

Другие ответы (0)

Пока нет других ответов. Будьте первым, кто поможет автору.

Ответить на вопрос

комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Вам также может быть интересно

VPN Как правильно настроить vless для Android TV? 1 ответ Pyrogram Как правильно зарегистрировать юзер бота в Telegram? 1 ответ печатные-платы Как заставить запускаться программу M3.exe от компании Hanxing AOI в инспекционной машине на Windows 7 Pro? 1 ответ Аккумуляторные батареи Почему при зарядке автостарта слышен писк, где искать причину? 1 ответ