Как использовать общий код приложений в микросервисах?

Question

[Михаил]

Есть проект реализующий логику работы с БД (репозиторий).
Есть желание разделить проект на микросервисы (предположим, на 20 отдельных сервисов).

Как должно работать по феншую, только один проект с БД или каждый может работать в БД?
Если каждый может, то цеплять весь репозиторий к каждому микросервису? Или у каждого микросервиса должен быть свой мини репозиторий? Если у каждого свой, и есть повторяющиеся запросы, они так и должны повторяться или как-то тоже это выносится?

Answer 1

[Павел Волынцев]

Если коротко, то архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными используя легковесные механизмы, как правило HTTP. Эти сервисы построены вокруг бизнес-потребностей и развертываются независимо с использованием полностью автоматизированной среды. Существует абсолютный минимум централизованного управления этими сервисами. Сами по себе эти сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных.

https://habrahabr.ru/post/249183/



В общем случае у них разные базы данных. Потому что там не-смежные данные. Если данные нужно хранить в одном месте из-за отношений - объединяй микросервисы. Если данные нужны для сложных запросов - делай промежуточный сервис агрегации (data aggregation), хранилище данных (data warehouse) или сервис консолидированных отчётов (reporting service) - в общем место, куда сливается инфа из микробаз и соединяется (https://www.quora.com/How-is-reporting-implemented...

Реализовать можно и одним приложением (один репозиторий) с 20 точками входа и 20 приложений (20 репозиториев). От архитектора зависит. Как ему удобнее. Как команде удобнее.

Comments

[Павел Волынцев]

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