Пошук по даних перетинає кілька мікросервісів


13

У мене є дані для певного домену, розподіленого між мікросервісом та застарілою базою даних. У мене є пошук, який охоплює поля як у застарілій, так і в базі даних мікросервісу. Раніше (до розбиття мікросервісу) це було зроблено за допомогою 1 sql запиту. Тепер мені потрібен виклик REST та запит до застарілої бази даних, щоб обслуговувати цю функцію пошуку. Ми говоримо про кілька мільйонів рядів тут. Як я можу це найкраще моделювати? Завдяки обсягу даних, виклик REST зазвичай також повертає болючі результати. Наївний підхід до запуску виклику SQL та комбінування та об'єднання результатів із відповіддю REST надто повільний і не дуже практичний.

Відповіді:


21

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

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

Дані двох служб найкраще передаватимуть асинхронно до індексу пошуку через шину подій, наприклад, Kafka або Hermes, щоб збільшити пропускну здатність і зменшити зв’язок між службами. Зміна будь-якої з двох служб призведе до події, яка інформує пошукову службу, щоб також оновити її дані.

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


Я вже хоча про створення окремої служби. Єдине, що доставляє мені певний дискомфорт - створення ще однієї бази даних лише для пошуку (подача її до еластичного було б ще одним варіантом, але у нас є деякі вузькі місця інфраструктури)
senseiwu

7
@zencv На жаль, мікросервіси мають такі витрати. Бути в змозі горизонтально масштабувати означає, що зв'язок повинен бути слабким, а це означає, що часто буде дублювання даних. Ви також отримуєте набагато більше мережевого трафіку. Масштабованість часто означає зниження продуктивності на одне апаратне забезпечення та вибір однієї архітектури над іншою (наприклад, мікросервіси проти моноліту) повинні враховувати цей компроміс.
Michał Kosmulski
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.