VI
попробовать реконнектнуться
автоматически нужно. ну ок, видимо, решений общепринятых тут нет, запилим сами)
Size: a a a
2019 December 24
C
автоматически нужно. ну ок, видимо, решений общепринятых тут нет, запилим сами)
так можно автоматически реконнектнуться
ЕО
есть несколько мелких приложений, к ним на этапе инциализации бекенда подключается бекенд. в какой-то момент времени некий сервис падает, коннект разрывается. шо вы делаете тогда?
Ну у меня перед всеми сервисами L3 балансировщик
ЕО
Если критичный сервис разваливается, то просто часть запросов 500'ит
VI
Если критичный сервис разваливается, то просто часть запросов 500'ит
500-то 500, но хорошо бы переподнимать сервисы и снова их юзать
VI
Если критичный сервис разваливается, то просто часть запросов 500'ит
у вас некий gateway, типа неважно где упал сервис и где новый поднялся, точка входа всегда одна для остальных?
VI
вот это мне нравится
ЕО
500-то 500, но хорошо бы переподнимать сервисы и снова их юзать
VI
девопса лишнего не найдется? 😅
DP
господа, а как вы решаете проблему переподключения многочисленных сервисов друг к другу? допустим, у меня логгер - это отдельный сервис. мне нужно перед каждым событием логирования проверять пингом доступность? или лучше смотреть статус самого соединения и, если что, переподключаться? или есть уже что-то готовое?
grpc следит за своими соединениями сам
DP
но именно логгер я вообще по udp делаю всегда
VI
grpc следит за своими соединениями сам
У grpc либы есть эксперииентальная функция проверки соединения. А как ещё он сам следит? Переподключается? 🙄
DP
переподключается
VI
переподключается
😳
J
У grpc либы есть эксперииентальная функция проверки соединения. А как ещё он сам следит? Переподключается? 🙄
да, и много настроек есть к этому https://grpc.github.io/grpc/core/group__grpc__arg__keys.html#ga40e635cf00ea7a10c71ed71c03d97f23
IT
Столкнулся с архитектурной проблемой применения параметров конфигурации.
Само применение параметров это viper+cobra.
Ранее требовалось прокидывать в приложение ~8 специфичных параметров настройки для определенного типа "работы". Недавно получил требование что это должены быть массивы параметров.
Не нравится что всё станет не читабельно. Запускаться с конфигом на 50-100 строк - плохо. А потом количество может ещё вырасти.. Уж молчу про ключи, которыми можно задавать работу всё этого безобразия.
Настройки специфичные, для дёргания внешних утилит (скажем так), не какие-нибудь порты/адреса и прочие пути к бд)
Делать отдельный конфиг-файл/мини-базу под массив специфичных настроек? Или есть ещё какие-нибудь пути?
Само применение параметров это viper+cobra.
Ранее требовалось прокидывать в приложение ~8 специфичных параметров настройки для определенного типа "работы". Недавно получил требование что это должены быть массивы параметров.
Не нравится что всё станет не читабельно. Запускаться с конфигом на 50-100 строк - плохо. А потом количество может ещё вырасти.. Уж молчу про ключи, которыми можно задавать работу всё этого безобразия.
Настройки специфичные, для дёргания внешних утилит (скажем так), не какие-нибудь порты/адреса и прочие пути к бд)
Делать отдельный конфиг-файл/мини-базу под массив специфичных настроек? Или есть ещё какие-нибудь пути?