Поиск по данным по нескольким микросервисам


13

У меня есть данные для определенного домена, распределенные между микросервисом и устаревшей базой данных. У меня есть поиск, который охватывает поля как в устаревшей, так и в микросервисной базе данных. Ранее (до разделения микросервиса) это было сделано с 1 sql запросом. Теперь мне нужен вызов REST и запрос к устаревшей базе данных для обслуживания этой функции поиска. Мы говорим о нескольких миллионах строк здесь. Как я могу моделировать это лучше всего? Из-за большого объема данных вызов REST также обычно возвращает нумерацию страниц. Наивный подход к запуску вызова SQL и объединению и объединению результатов с ответом REST слишком медленный и не очень практичный.

Ответы:


21

Функция поиска может быть смоделирована как отдельный сервис с отдельной ответственностью от двух упомянутых вами сервисов. Таким образом, подход здесь может заключаться в создании нового сервиса («поиск») и в нем хранить копии данных обоих сервисов в форме, которую легко индексировать и искать, возможно, также денормализованной для быстрого получения результатов в желаемый формат.

Так, например, у вас может быть устаревшая база данных SQL, использующая, например, mySql, другой микросервис, использующий, например, MongoDB, и новый поисковый сервис, использующий эластичный поиск с данными из обоих уже вставленных вместе (денормализованных) для более удобного доступа. Конечно, детали будут зависеть от того, какие поиски вам нужно выполнить.

Данные из этих двух служб лучше всего передавать асинхронно в индекс поиска через шину событий, такую ​​как Kafka или Hermes, чтобы увеличить пропускную способность и уменьшить связь между службами. Изменение в любом из двух сервисов отправило бы событие, информирующее сервис поиска, чтобы также обновить свои данные.

Конечно, существует дополнительная задержка между изменениями в службах и в службе поиска, но поскольку микросервисы обычно используются в системах, которые распределены, некоторые задержки и временные несоответствия неизбежны в любом случае. Наличие дополнительной услуги и использование дополнительного хранилища для копии данных, которая уже есть в двух других службах, также является типичной стоимостью высокораспределенной и масштабируемой системы, использующей микросервисы.


Я уже думал о создании отдельного сервиса. Единственное, что доставляет мне некоторый дискомфорт - создание еще одной базы данных только для поиска (подача ее в эластичный вариант была бы другим вариантом, но у нас есть некоторые узкие места в инфраструктуре)
senseiwu

7
@zencv К сожалению, микросервисы имеют такую ​​стоимость. Возможность горизонтального масштабирования означает, что связь должна быть слабой, а это означает, что часто будет дублирование данных. Вы также получаете намного больше сетевого трафика. Масштабируемость часто означает падение производительности на каждое аппаратное устройство, и выбор одной архитектуры над другой (например, микросервисы против монолита) должен учитывать этот компромисс.
Михал
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.