Files
digital-garden/dev/architecture/Enriching Data in Distributed Systems.md
Struchkov Mark 8afe9c630e
All checks were successful
continuous-integration/drone/push Build is passing
Enriching Data in Distributed Systems.md
2025-02-26 17:44:26 +03:00

74 lines
7.1 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
aliases:
- Обогащение данных в распределённых системах
tags:
- maturity/🌱
date: 2025-02-26
---
В системе с [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисной архитектурой]] часто возникает ситуация, когда один сервис хранит информацию о сущностях (например, пользователях, клиентах, товарах), а другой сервис содержит связанные данные, но без детальной информации (например, только [[../Идентификатор сущности|идентификатор]] сущности). В таком случае возникает необходимость обогащения данных во втором сервисе, чтобы выполнять фильтрацию, агрегацию или другие операции. Рассмотрим возможные подходы к решению этой задачи, их плюсы и минусы.
## Синхронный вызов
При получении запроса во втором сервисе выполняется HTTP или [[../gRPC|gRPC]]-запрос в сервис, содержащий основную информацию, для получения необходимых атрибутов по идентификатору. Далее производится фильтрация или другая обработка данных.
**Плюсы**
- **Актуальность данных** — используется самая свежая информация.
- **Отсутствие дублирования** — вся информация централизована в одном сервисе.
**Минусы**
- Высокая [[Latency|задержка]] — каждый запрос требует дополнительных сетевых вызовов.
- **Жёсткая зависимость** — проблемы с доступностью основного сервиса могут привести к сбоям.
- Ограниченная [[Масштабирование информационной системы|масштабируемость]] — нагрузка на основной сервис увеличивается при росте количества запросов.
## Репликация данных во втором сервисе
Необходимые атрибуты сущностей дублируются во втором сервисе. Синхронизация изменений производится через события ([[../../../../_inbox/00 Kafka|Kafka]], [[../../../../_inbox/00 RabbitMQ|RabbitMQ]]) или периодические обновления.
**Плюсы**
- **Быстрая фильтрация** — запросы обрабатываются локально без обращений к другим сервисам.
- **Независимость сервисов** — отказ основного сервиса не влияет на работу второго сервиса.
**Минусы**
- **Риск рассогласования данных** — необходимо поддерживать актуальность реплицированных данных.
- **Дополнительные механизмы синхронизации** — требуется реализация подписки на изменения и обновления данных.
## Агрегация через API Gateway или BFF
Создается промежуточный сервис (агрегатор), который объединяет данные из нескольких сервисов. Клиент запрашивает данные через него, а агрегатор выполняет необходимые вызовы.
**Плюсы**
- **Разделение ответственности** — сервисы остаются независимыми, а объединение данных выполняется на уровне [[API Gateway]]/BFF.
- **Гибкость** — можно адаптировать запросы под различные потребности клиентов.
**Минусы**
- **Дополнительная инфраструктура** — требуется разрабатывать и поддерживать агрегатор.
- [[Latency|Задержки]] при обработке — выполнение нескольких запросов может увеличить [[Latency|время отклика]].
## Использование поискового движка
Данные индексируются в поисковой системе ## (Elasticsearch, OpenSearch), которая позволяет эффективно фильтровать информацию, включая поиск по атрибутам.
Плюсы
- **Высокая производительность поиска** — поисковые движки оптимизированы для сложных запросов.
- Хорошая [[Масштабирование информационной системы|масштабируемость]] — эффективны при больших объемах данных.
**Минусы**
- **Сложность поддержки** — необходима дополнительная инфраструктура для индексации данных.
- **Потенциальное рассогласование** — данные в индексе могут отставать от актуального состояния.
## Использование GraphQL с федерацией
[[../GraphQL|GraphQL]] позволяет создавать единый API, который объединяет данные из разных сервисов с помощью резолверов, запрашивающих необходимые данные.
**Плюсы**
- **Гибкость запросов** — клиент выбирает, какие данные получать.
- **Единая точка доступа** — упрощает взаимодействие между сервисами.
**Минусы**
- **Сложность реализации** — требуется настройка федерации и резолверов.
- **Дополнительные накладные расходы** — выполнение сложных запросов может увеличить нагрузку.
***
## Мета информация
**Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
**Родитель**::
**Источник**::
**Создана**:: [[2025-02-26]]
**Автор**::
### Дополнительные материалы
-
### Дочерние заметки
<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->