Привет! Есть проект-монолит. Пока что она состоит из логических, разделенных блоков: 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: Разделение на сервисы делаю для опыта на действующем проекте. Поэтому про нагрузки и целесообразность прощу не спрашивать. Про Сервисы и Микросервисы в целом читал статьи на ХАБРе и других источниках. Плюсы и минусы такой архитектуры представляю. Цель — научится.
Делать поддомены или нет, это не так важно. Отдельный домен, это удобнее, ведь и так может быть api.site.ru/v1/ Механизм можно назвать межсайтовой авторизацией и я где-то видел статью как хабр к этому шел. В целом нужно получить токен пользователя и проверить его валидность. Как это сделано на хабре, можно посмотреть отлавливая запросы к их апишке при авторизации с хабра или тостера, или что там у них еще есть... Т.е. заходит юзер, кликает на авторизацию, его перебрасывает на страницу авторизации, он логинится/авторизуется и его редиректит обратно с со свеженьким токеном, далее мы смотрим его токен и готово! Если пользователь зашел на наш другой сайт, мы смотрим наши куки в его браузере, валидируем у себя и готово! Докер очень удобно рулится через docker-compose или даже через вэб морду типа portainer, хотя он только 2 версию композа поддерживает, но есть и другие аналоги. Создаются стэки типа: service_1, service_2 ....