В настоящее время у нас есть 2 микросервиса с собственной базой данных. Эти микросервисы представляют собой сервисы уровня 2, которые заполняют свою базу данных асинхронным c способом при некоторых триггерах CRON. Наше текущее требование - создать независимый развертываемый сервисный блок уровня 1, который сможет предоставлять эти данные важным клиентам через API с высокой скоростью вращения, доступностью и приемлемой задержкой.
Эта служба требуется для агрегирования данных из обеих этих двух баз данных в один объект для обслуживания простых агрегатов, таких как SUM, по некоторым полям.
Например: DB-1 => cars (принадлежит службе, S1) И DB-2 => buses (принадлежит S2)
Объект для обслуживания: DTO(List<Car> cars, List<Bus> buses), DTO(long carCount, long busCount) et c.
Мы не хотим создавать агрегатор API, поскольку мы не хотим поддерживать работоспособность сервисов уровня 2 только для обслуживания данных, которыми они владеют, а также из-за проблем с задержкой. Мы думаем о создании общей архитектуры БД, в которой служба Aggregator подключается к DB-1 и DB-2 и обслуживает их напрямую. Это идет вразрез с микросервисной архитектурой, которая вызывает беспокойство. Кроме того, это будет означать, что службе Aggregator также необходимо создать классы Entity для соответствующих таблиц.
Для фона: на самом деле в настоящее время это монолит Java, и это 3 модуля, которые мы исследуем, чтобы разбиться на независимые микросервисы. Данные S1's после записи БД будут также потребляться другими службами через Kafka (Kafka Pu sh после записи БД с последующей обработкой другими службами для других задач)
Количество подключенных баз данных не будет Grow и Aggregator коррелируют с двумя данными с точки зрения понимания бизнеса
Как обычно обрабатывается обслуживание данных через API с высокой пропускной способностью в таких случаях, когда сервис должен обслуживать данные нескольких ответственных сервисов с незначительными агрегатами, в основном данные из БД, которыми он не владеет? Мы будем очень признательны за любые идеи.