Миграция из монолита в микросервис

Question

Я смотрю на стратегию миграции «коричневого поля» (из курса множественного взгляда), где вы создаете 1 таблицу API / монолит. В настоящее время я работаю в команде, переходящей с монолитной архитектуры на микросервисную, которая будет работать на AWS.

Вот проблема / сомнение у меня:

У меня есть 2 таблицы (объединены) и хранимая процедура Oracle, которая создает объект с использованием этих 2 таблиц. Конечно, Oracle очень эффективен.

Однако, если я помещу каждую из этих двух таблиц в отдельные API REST, создание этого результирующего объекта будет включать: - выборка 1/3 данных из таблицы 1 - извлечение 1/2 данных из таблицы 2 - использование Java для построения результатов из этих двух наборов данных (миллионы записей).

Я слышал два ответа на этот вопрос: 1) не беспокойтесь об этом, у вас практически неограниченная вычислительная мощность в облаке, например / один экземпляр EC2 / микросервис. И если вашему API / Сервису приходится выполнять тяжелую работу (извлекать / обрабатывать миллионы записей), просто предоставьте своему экземпляру EC2 много энергии (процессор, память, хранилище и т. Д.)

и ...

2) переместить обе таблицы в один и тот же API.

Я не уверен насчет ответа 1, а что касается 2, иногда задействовано несколько таблиц, например, 10+! Также с решением 2 та же проблема проявится, когда вам может понадобиться получить несколько тысяч / 100000 записей +!

Любой совет приветствуется !! :)

Answer 1

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

С другой стороны, Oracle PL / SQL гораздо эффективнее, чем объединение их в коде Java. Если вы разместите их в двух или более разных сервисах, вам придется более внимательно относиться ко многим вещам в приложении, а также к производительности, поскольку в ваших таблицах миллионы записей.

Обновление:

О вашем первом решении, даже если вы собираетесь развернуть его на AWS, и практически AWS имеет неограниченную вычислительную мощность, что обойдется вам в целое состояние. Мощность обработки AWS не очень низкая. Особенно, если бы вы могли что-то сделать, чтобы снизить стоимость.

Answer 2

Я не знаю вашу точную архитектуру, но вы должны выполнять такую ​​операцию, как объединение таблиц непосредственно в Oracle, вместо того, чтобы разбивать каждую из таблиц по отдельности, а затем комбинировать / агрегировать из вашего кода Java.Использование такого подхода должно быть намного более эффективным, чем то, что вы делаете в настоящее время.Даже если таблицы находятся в отдельных экземплярах Oracle, возможно, было бы более эффективно выполнить кросс-запрос к базе данных, объединить / агрегировать, а затем вернуть единый результирующий набор в код Java.