Обновить
11
0
Евгений Соколов@heappro

Software Developer

Отправить сообщение
Этот подход будет хорошо работать, если невозможно быстро поднять новые инстансы сервиса. То есть, даже если вы в AWS, но запуск нового инстанса занимает много времени, то лучше сделать механизм уменьшения нагрузки.
Включать сервера при необходимости – плохой вариант.
От момента включения до момента, когда сервер сможет обрабатывать запросы, пройдет минимум пол часа. Надо время на включение, на закачку и распаковку индекса, на закачку и установку поисковика, на запуск.
Все это время сервису в целом будет очень плохо.
По какому протоколу общаются ваши сервисы? Это HTTP?

Да, HTTP. Есть планы перехода на gRPC.

Хватает ли возможностей HAProxy? Не возникала ли необходимость писать что-то свое?

Пока полностью хватает

Используете ли вы service discovery системы типа consul/zookeeper?

Zookeeper есть, но используется не для SD.
SD не используем, пока смотрим в его сторону.
Интересно, и что же происходит, если «падает» сниппетный сервер?

Если падает сниппетный, то поведение аналогично. Другие соседи по кластеру узнают о падении через запрос /status. И в свою очередь тоже перестают отвечать. Кластер закрывается.

А содержимое восьми шардов одинаковое во всех кластерах или возможны другие варианты?

В штатном режиме везде одинаковые. Но бывают другие ситуации:
1) Обновление идет пачками по несколько кластеров. То есть на период обновления могут отличаться.
2) Если сервер лежал, потом включился, там оказался старый шард. Но такой кластер не откроется пользователям.

В каком смысле «отойти от кластерной архитектуры»? А что будет взамен? Звучит как мегапрорыв :)

Иммется ввиду избавиться от сущности «кластер», в которой 8+1 сервер с жесткой связью.
Будет отдельный сервис со сниппетами, а поисковые серверы не будут связаны с другими поисковыми серверами.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Зарегистрирован
Активность