Ответ от Вадима: Всё верно, задача FLST трансформировать запрос, к примеру, вида "Внуково - Адлер для двух пассажиров на такое-то число" в многопоточный параллельный процесс поиска всех возможных вариантов в разных источниках. Формирование из этих потоков оптимальных результатов - задача для других наших сервисов, которыми занимается отдельная команда. Я думаю, если есть интерес, они могли бы оформить это тоже в отдельную статью.
Ответ от Вадима: Масштабирование сделано везде на основании CPU/MEM, и только на Search workers - через KEDA (https://keda.sh/) на основании количества поисковых горутин. Это количество на 1 под было выведено скорее экспериментальным путём, скейлинг включается чтобы не допустить более N поисковых горутин на 1 под. Остальные сервисы не такие прожорливые на ресурсы, и отлично себя показали со скейлингом чисто по CPU/MEM.
Из интересных плюшек наверное только то, что стало сильно проще распараллеливать процессы, масштабировать отдельные компоненты, а так же иметь на выходе скомпилированный бинарник который можно положить в docker image сильно меньшего размера.
MariaDb у нас стандарт в компании, эту часть не хотелось трогать. А KeyDb заменил Redis поскольку мультипоточна и производительнее Редиса.
На тот момент Weave Flux использовался минимально. Но согласны: пожалуй,нам стоило бы сказать, что для улучшения процессов нужно было форсировать переход на GitOps.
«Мы смогли успешно изолировать кровь неандертальцев и шерстистых мамонтов» — т.е. с ними шансов на воспроизводство больше, т.к. и более-менее подходящие «яйца» найти тоже проще, чем динозавровые? :)
«а выбраковывались ли аллергики, диабетики, которым мама сладкое запрещает по объективным причинам и те, кто тупо не любит сладкое или мармеладки»
— покажите мне хоть одного трёхлетнего ребёнка, который _не любит_ сладкое… оч вряд ли такой найдётся
Да, пожалуй, Мамкин Айтишник уже ойвсё, это я ещё люблю слушать старьё )))
Удивилась, что нет Радио Т, Запуск Завтра, Мамкин Айтишник...
Ответ от Вадима:
Всё верно, задача FLST трансформировать запрос, к примеру, вида "Внуково - Адлер для двух пассажиров на такое-то число" в многопоточный параллельный процесс поиска всех возможных вариантов в разных источниках. Формирование из этих потоков оптимальных результатов - задача для других наших сервисов, которыми занимается отдельная команда. Я думаю, если есть интерес, они могли бы оформить это тоже в отдельную статью.
Ответ от Вадима:
Масштабирование сделано везде на основании CPU/MEM, и только на Search workers - через KEDA (https://keda.sh/) на основании количества поисковых горутин. Это количество на 1 под было выведено скорее экспериментальным путём, скейлинг включается чтобы не допустить более N поисковых горутин на 1 под. Остальные сервисы не такие прожорливые на ресурсы, и отлично себя показали со скейлингом чисто по CPU/MEM.
Из интересных плюшек наверное только то, что стало сильно проще распараллеливать процессы, масштабировать отдельные компоненты, а так же иметь на выходе скомпилированный бинарник который можно положить в docker image сильно меньшего размера.
MariaDb у нас стандарт в компании, эту часть не хотелось трогать. А KeyDb заменил Redis поскольку мультипоточна и производительнее Редиса.
На тот момент Weave Flux использовался минимально. Но согласны: пожалуй, нам стоило бы сказать, что для улучшения процессов нужно было форсировать переход на GitOps.
— покажите мне хоть одного трёхлетнего ребёнка, который _не любит_ сладкое… оч вряд ли такой найдётся