Подскажете по архитектуре «мультисервисного» приложения?

Question

[Wan-Derer]

Всем привет!
Думаю надо архитектурой приложения (Spring Boot, сборка на Maven).
Приложение будет предоставлять несколько WEB-сервисов, за каждый будет отвечать отдельный микросервис :) Но все они будут обращаться к одной базе данных.
Я хочу сделать микросервис (или модуль?), который абстрагирует БД. Т.е. он умеет читать (пока только читать, а в перспективе и писать, и кэшировать запросы) записи из БД и раздавать их другим частям приложения. Все остальные части ничего не знают про БД, а пользуются готовыми объектами.
Как это лучше сделать? Очевидный путь - микросервис и раздача по REST. Но допустим, у меня БД на 1000 таблиц (плюс ещё таблицы взаимосвязаны что порождает вложенные Java-объекты). Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....
М.б. есть менее обезьяний способ? :) Думать какие-то универсальные методы с подсовыванием нужных классов и Reflection? Сделать его как модуль (модули из Java-9)? Или как-то ещё?
Наверняка я не первый кто столкнулся с такой задачей. Как это вообще принято делать?

Comments

[Wan-Derer]

Dr. Bacon, Хорошо, назвал неправильно :) А как правильно делать подобные приложения?

[Jacen11]

Wan-Derer,

, у меня БД на 1000 таблиц (плюс ещё таблицы взаимосвязаны что порождает вложенные Java-объекты). Это значит, мне надо сделать 1000 репозиториев

почему 1000? может и 100, может и 2000. Тут нет никакой связи

раздача по REST

такого протокола нет. Это архитектура. По моему у вас проблемы с пониманием что есть что и зачем нужно.

Для начала начните с того что такое микросервисы и нахрена они нужны. Люблю этим вопросом топить людей. Почти никто не может отстоять микросервисы перед монолитом.

[Wan-Derer]

Jacen11, Не надо никого топить, это неконструктивно :) Я тут не для того чтобы отстаивать "неправильную позицию", я спрашиваю как сделать правильно.
Не нравится слово "микросервисы"? Хорошо, давайте назовём части приложения "маленькими монолитиками". Надо ли делить приложение на части? Надо - т.к. они несут весьма разные функции и есть смысл разнести их по разным портам и прикрутить к каждому по собственному фронтенду. При этом разрабатывать, разворачивать, модернизировать каждую часть можно и нужно по отдельности, не затрагивая остальных.
Надо ли пилить каждую часть на более мелкие части? Думаю - нет т.к. они действительно небольшие и функционально законченные.
НО! Они все пользуются одной и той же БД, из которой "черпают" данные "общего назначения": юзеры, ассеты, события и пр. Плюс есть данные, специфичные для каждой конкретной части, они их получают всякими способами: своя БД, очереди, пользовательский ввод и пр.
Вот я и хочу "общую часть" вынести куда-то отдельно. И спрашиваю как это принято делать: библиотека? модуль? сервис? Велосипед изобретать не хочу - поэтому и спрашиваю: как это делают обычно?

[d'Ivan]

Хороший монолит лучше, чем много плохих микросерсисов.

[Jacen11]

Wan-Derer, слой репозиторий. Слои разделяют везде по разному, нет одного супер правильного способа. В своем проекте хватает просто в отдельный пакет. Иногда в отдельный модуль выделяют. На больших проектах это отдельный микросервис

Answer 1

[d'Ivan]

НО! Они все пользуются одной и той же БД, из которой "черпают" данные "общего назначения": юзеры, ассеты, события и пр.

Вот я и хочу "общую часть" вынести куда-то отдельно. И спрашиваю как это принято делать: библиотека? модуль? сервис?

Можно сделать как подключаемую библиотеку (пакет Java), вынеся всё в ядро самое необходимое. Вокруг библиотеки ядра могут быть созданы какие-то библиотеки-обвески. Репозиториев библиотек может быть несколько, для простоты. Каждая библиотека может иметь свою версию и использоваться монолитом при сборке.

Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....

Ну зачем так? Нет смысла дробить даже на десятки, не говоря уже о тысячах.

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

Comments

[Wan-Derer]

Архитектуры как таковой нет, я собственно и пытаюсь её разработать. Сейчас есть работающее приложение, тот самый монолит, представляющий собой один из "модулей", о которых я говорил ранее.
Базу данных я не проектирую, она мне предоставляется в готовом виде. И сейчас готовится новая версия, в которой база разделяется на две части: в одной объекты "общего назначения" (юзеры и т.д.), а в другой - специфичные для моего приложения. Но данные мне нужны из обеих баз.
В принципе, я умею делать Spring-приложение с двумя (несколькими) базами, это не проблема. Но я пытаюсь думать немного вперёд. Допустим, у меня появится задача реализовать ещё одну часть предметной области. Будет то же деление: объекты "общего назначения" и специфичные для этой части. Добавлять функционал к текущему приложению не надо - это будет совсем другая логика, просто часть исходных данных будет общая, т.е. это в любом случае будет отдельное приложение. Тогда, в рамках монолитного подхода мне надо будет скопировать код, отвечающий за "общую" часть, а потом поддерживать его уже в двух приложениях. Я и хочу эту общую часть вынести и использовать как в текущем приложении, так и в последующих.
Вот я думаю как это лучше сделать. Если единственный нормальный вариант - библиотека, ну ok, будет библиотека. Но я хочу и другие варианты рассмотреть, какие - об этом и вопрос.

Answer 2

[mayton2019]

Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....

Зачем такой ужас. Делай только те репозитарии которые реально задействованы в бизнес-задачах.
Из личного опыта могу сказать что если приложение спроектировано по умному - то ему не нужно
выделять каждую таблицу в Entity.

Comments

[Wan-Derer]

Сейчас так и есть. Я забираю только те таблицы, которые нужны, более того, только те поля таблиц, которые нужны. Но если я вынесу работу с базой в отдельную часть, мне в конце концов придётся описать все таблицы с помощью объектов. Пусть их будет не 1000 т.к. есть какое-то число зависимых таблиц, которые будут представлены вложенными объектами. Пусть их будет 300-400, но это всё равно до фига :)

[mayton2019]

Wan-Derer, что-то я не понимаю твою проблему. Есть задача. Автоматизируй все что можешь. Сгенери Java код на основе таблиц. Для генератора будет безразлично 300 таблиц или 1000.

Что не автоматизируется -добей руками.

[Wan-Derer]

mayton2019, IDEA не любит Firebird и не хочет автоматически генерировать код :) Но это вопрос двадцатый. Я не собираюсь в один присест описывать всю базу, буду делать это по мере необходимости.
Вопрос в том как организовать раздачу объектов (варианты подробно описывал выше). Т.е. как это обычно делается в подобных случаях?

Answer 3

[Орхан Гасанлы]

Приложение будет предоставлять несколько WEB-сервисов, за каждый будет отвечать отдельный микросервис :) Но все они будут обращаться к одной базе данных.

Может быть вам нужны не микросервисы, а distributed monolith? Ну и реализовать паттерн shared database access

Я хочу сделать микросервис (или модуль?), который абстрагирует БД. Т.е. он умеет читать (пока только читать, а в перспективе и писать, и кэшировать запросы) записи из БД и раздавать их другим частям приложения. Все остальные части ничего не знают про БД, а пользуются готовыми объектами.

Тут можно и про SAGA задуматься.

Но допустим, у меня БД на 1000 таблиц (плюс ещё таблицы взаимосвязаны что порождает вложенные Java-объекты). Это значит, мне надо сделать 1000 репозиториев, в каждом Х методов (получение по ID, получение по значению поля, одного объекта, коллекции...). И ещё 1000*Х методов в контроллерах....

Честно, не уловил сути между количеством таблиц в БД и количеством репозиториев. Но если что можно же монорепо сделать.

Думаю, вам не нужны микросервисы. Вам понадобится monolith, ну или максимумdistributed monolith.
Много чего можно вынести в отдельные модули. Например, создать модуль persistence и вынести DAO туда

Comments

[Wan-Derer]

О, много новых слов :)
Спасибо, будем почитать :))

[Орхан Гасанлы]

Wan-Derer, рад помочь