@pro-dev

Как правильно разделить проект на микросервисы или сервисы?

Привет! Есть проект-монолит. Пока что она состоит из логических, разделенных блоков: CRM и User. В качестве опыта хочу попробовать разделить этот проект на сервисы с использованием Docker. Код разделен по папкам, так что перенести его в отдельное приложение (сервис) не составляет особого труда. Однако я не знаю как правильно это сделать по архитектуре и по доменам.

Пользуясь тостером, уже давно заметил что он имеет единый центр авторизации на несколько сервисов, которые недавно стали едины, разделенные доменами. Это примерно то, что я хочу.

Весь Backend у меня на Symfony 4.4. Для Frontend использую Vue.

Реализацию задуманного вижу так:
1. Создается главный UI site.ru, где размещается вся информация и с помощью этого UI попадаем в сервисы. (отдельное приложение на VUE)
2. UI интерфейс для единого центра авторизации, управление профилем и пользователями. Помещается на поддомен account.site.ru (отдельное приложение на VUE)
3. API для единого центра авторизации, управление профилем и пользователями. Помещается на поддомен api.account.site.ru (отдельное приложение на Symfony) в API папку public помещаем документацию которая будет доступна по адресу api.account.site.ru/docs
4. UI интерфейс для работы в CRM. Помещается на поддомен crm.site.ru (отдельное приложение на VUE)
5. API для работы в CRM. Помещается на поддомен api.crm.site.ru (отдельное приложение на VUE) в API папку public помещаем документацию которая будет доступна по адресу api.crm.site.ru/docs

Скажите, на сколько правильная такая архитектура? Нужно ли для API отдельные домены? Либо разделить всё немного по другому: crm.site.ru, crm.site.ru/api/docs, crm.site.ru/api? Если есть полезные ссылки - буду очень благодарен. Ну а если найдется готовый пример на Github - просто супер! Спасибо за помощь)

PS: Разделение на сервисы делаю для опыта на действующем проекте. Поэтому про нагрузки и целесообразность прощу не спрашивать. Про Микросервисы в целом читал статьи на ХАБРе и других источниках. Плюсы и минусы такой архитектуры представляю. Цель — научится.
  • Вопрос задан
  • 306 просмотров
Решения вопроса 2
OnYourLips
@OnYourLips
Задача - потренироваться на тестовом приложении? С такой задачей сложно будет, вы вслепую все делаете, не зная реальных кейсов, которые бывают в реальных приложениях.

Но вы в любом случае разделение на микросервисы не делали - у вас как бекенд как был монолитом, так и остался (пункт 3).
Ответ написан
Robur
@Robur
Знаю больше чем это необходимо
Это у вас не микро сервисы а два обычных сервиса с общим сервисом авторизации. про микросервисы можете почитать microservices.io.
Структура нормальная.
На какие именно домены разделить и класть ли апи в разные домен или в один или разделять по путям - в целом мало разницы.

Самый большой вопрос у вас будет с авторизацией - над ней подумайте получше.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы