Комментарии 6
Хотелось бы побольше конкретики, тема масштабируемых сервисов, написанных на Go и развернуты в Kubernetes не раскрыта :(
Например, у вас 20 подов, и потом при нагрузке они увеличиваются - как? Автоскейлинг, либо еще что-то?
Можно раскрыть было какие-то интересные плюшки при переходе с PHP на Go - что изменили в бизнес-логике, т.п. У вас 3 сервиса, которые тоже можно было раскрыть как-то в статье.
Обосновать применение MariaDB, KeyDB по сравнению с другими базами данных.
Я бы ещё добавил к вашему вопросу как выбирался размер самих подов по CPU/RAM.
Ответ от Вадима:
Масштабирование сделано везде на основании CPU/MEM, и только на Search workers - через KEDA (https://keda.sh/) на основании количества поисковых горутин. Это количество на 1 под было выведено скорее экспериментальным путём, скейлинг включается чтобы не допустить более N поисковых горутин на 1 под. Остальные сервисы не такие прожорливые на ресурсы, и отлично себя показали со скейлингом чисто по CPU/MEM.
Из интересных плюшек наверное только то, что стало сильно проще распараллеливать процессы, масштабировать отдельные компоненты, а так же иметь на выходе скомпилированный бинарник который можно положить в docker image сильно меньшего размера.
MariaDb у нас стандарт в компании, эту часть не хотелось трогать. А KeyDb заменил Redis поскольку мультипоточна и производительнее Редиса.
GDS возвращает на каждый запрос разное количество предложений (вариантов полетов), обычно не более 300 (хотя не редко и более 1000).
Мне казалось, что GDS (Amadeus и т.п.) выдаёт только отдельные перелёты, загруженные авиакомпаниями, оптимальные комбинации ищут агрегаторы (используя, скажем QPX от ITA, и там как раз самое интересное - по крайней мере с алгоритмической точки зрения - из происходящего под капотом). Сейчас можно получить разные варианты (в том числе склейку рейсов разных авиакомпаний из разных альянсов) от GDS?
Ответ от Вадима:
Всё верно, задача FLST трансформировать запрос, к примеру, вида "Внуково - Адлер для двух пассажиров на такое-то число" в многопоточный параллельный процесс поиска всех возможных вариантов в разных источниках. Формирование из этих потоков оптимальных результатов - задача для других наших сервисов, которыми занимается отдельная команда. Я думаю, если есть интерес, они могли бы оформить это тоже в отдельную статью.
Под капотом: как работает мгновенный поиск перелетов