Я использую Quarkus RestClient и столкнулся с некоторыми проблемами. У меня есть URL-адрес, который внутренне разрешен до 4 разных IP-адресов (в этом примере данные и IP-адреса псевдонимизированы):
[user@server]$ dig service.example.com
;; ANSWER SECTION:
service.example.com. 740 IN CNAME service-example-com.some-internal-resolution.com.
service-example-com.some-internal-resolution.com. 290 IN A 300.300.351.76
service-example-com.some-internal-resolution.com. 290 IN A 300.300.350.1
service-example-com.some-internal-resolution.com. 290 IN A 300.300.349.76
service-example-com.some-internal-resolution.com. 290 IN A 300.300.348.1
Мне кажется, что Quarkus RestClient извлекает только первый IP-адрес, потому что проблема в том, что когда этот первый IP-адрес недоступен, я получаю тайм-аут соединения, хотя остальные доступны, поэтому я думаю, что это проблема с RestClient?
Есть ли способ обойти это поведение, чтобы RestClient пробовал и другие IP-адреса, если первый недоступен?
Это ожидаемое поведение. Чтобы делать то, что вы хотите, вам нужно использовать аист (фреймворк обнаружения сервисов Quarkus) — https://smallrye.io/smallrye-stork/1.3.1/service-discovery/dns/
А потом:
quarkus.stork.my-service.service-discovery.type=dns
и ваш клиент отдыха будет использовать URL-адрес stork://my-service
.
Кажется, эта структура не решает мою проблему. Кажется, не существует какого-то механизма для перенаправления запроса на другой IP-адрес типа A. Кажется, что он может получать информацию о доступных сервисах только с DNS-сервера (в случае настройки DNS), поэтому в итоге у меня все еще та же проблема, что и раньше. Поэтому мне нужно найти другое решение.
Stork разрешит список записей A, а затем осуществит циклический перебор среди них (или другую стратегию выбора, циклический перебор используется по умолчанию).
Думаю, теперь я нашел решение: см. github.com/smallrye/smallrye-stork/discussions/829
Выглядит многообещающе. Спасибо за подсказку, попробую.