#ruby-on-rails #ruby #elasticsearch #microservices
#ruby-on-rails #ruby #elasticsearch #микросервисы
Вопрос:
Я хочу реализовать эластичный поиск как микросервис. У нас будет 2 приложения, где основное приложение будет подключено к реляционной базе данных, а другое приложение будет иметь всю логику для эластичного поиска. Теперь в основном приложении любое изменение будет выдавать уникальное событие с полезной нагрузкой, содержащей всю соответствующую информацию об этом изменении.
После установки эластичного поиска основное приложение отправит это событие в службу эластичного поиска для обработки. Я планирую иметь сервисы для индексации каждой индексной таблицы в эластичном поиске. Эта служба обработает событие и произведет добавление / обновление / удаление на основе события в этом индексе.
Одно событие также может обрабатываться несколькими службами, если индекс, связанный с этой службой, включает изменение данных, связанное с этим событием.
Я просто беспокоюсь, будет ли это правильным подходом. Я вижу, что один сервис (класс) станет огромным из-за слишком большого количества событий, обрабатываемых для индексации.
Я бы закодировал это на ruby, и есть драгоценный камень под названием elasticsearch-model, который используется большинством людей и упоминается в каждом другом блоге. Но я не хочу этим ограничиваться, а также было бы невозможно использовать его в настройке микросервиса.
Заранее спасибо.
Ответ №1:
Я использовал elasticsearch-model gem в своем текущем веб-приложении. вы можете переопределить его методы CRUD в свой код ruby, используя их в качестве архитектуры REST API
или
Если вы не хотите использовать этот драгоценный камень, вы также можете создать REST api для своего elasticsearch и реализовать желаемые функции.
Комментарии:
1. Мой вопрос больше склонен к структурированию кода для индексации различных вещей, происходящих вокруг приложения. Когда мы используем gem, он располагается поверх модели и фиксирует изменения и индексирует для эластичного поиска. Я хочу знать, существует ли альтернативный подход к отказу от использования gem для индексации. Тот, который я предлагаю в вопросе, использует различные сервисы / классы, каждый из которых представляет один индекс и обрабатывает события там для того, какие изменения нужно внести в индекс на основе события). Я смущен его масштабированием.