Спасибо! Почитал, подумал, и решил не добавлять сервисную сетку в архитектуру системы. Может, в будущем будет добавлена, но не сейчас.
ДФ>ELK на больших объемах не очень удобен, лучше уж vector+Clickhouse+Lighthouse/Grafana ДФ>Zabbix — это уже совсем старое решение, для мониторинга лучше прометеус, а картинки — в той же графане ДФ>gRPC — это довольно странное решение для моноязыковых проектов, приходится все упихивать в protobuf, а он не самый удобный и хороший формат. Да и не поддерживается нормально заметной частью service mesh/балансировщиков. Для нескольких сервисов gRPC не даст заметного выигрыша.
Что за сложности с большими объемами у ELK? У нас ожидается, в среднем, от 500 Мб до 2 Гб логов в секунду. Про "в секунду" не опечатка. Может получится писать в логи меньше, но пока непонятно, зависит от запросов бизнеса на аналитику.
ДФ>Ого, а что за задачи, требущие такого объема работ?
b2b система, напрямую с пользователями не работает. Система проектируется на замену существующей работающей системы. Существующая система уперлась в целый ряд проблем, поэтому решили ее переписать с нуля. На данный момент, она занимает, почти целиком, крупный датацентр.
ДФ>Эээ, кубер предполагается свой или чужой? Если свой, то это очень дорого в поддержке, особенно при требовниях 24*7 (а бесшовный деплоймент, как мне кажется, предполагает 24*7). ДФ>Но кубер не дает никаких особых возможностей для деплоймента без остановки (как и истио). Все равно нужно писать свои скрипты управления балансировщиком...
Предполагается свой. Да, требование 24/7.
Почему свой кубер дорого? Вроде, взять двух девопсов на него, и норм? Ии что-то еще?
Про балансировщик — да, понятно. Плюс еще хочется мирроринг, а еще хочется тестирование прямо на проде, перед тем как выставлять новую версию микросервиса даже для части пользователей. Такое тестирование можно сделать на основе меток в метаинформации запроса. Видел такой метод в видео от Авито, выглядит очень полезным.
ДФ>Тут да, меш помогает (писать руками скрипты на nginx сложно), но платить за это istio+kubernetes — получается еще дороже, увы. ДФ>Тут стоит прикинуть все требования к инфраструктуре, а уже потом думать про service mesh.
A>>4. Circuit breaker, для подтормаживающих инстансов. ДФ>Хм, там мало circuit breaker, там еще много что нужно, по идее. И даже в istio всего нужного нет. ДФ>Вообще, удобнее это реализовывать через библиотеки на клиентах. Для rest их много, про gRPC не в курсе.
Да, библиотеки есть, Polly. Проверил в том числе для gRPC, работает, то что нужно.
