Стоит ли выдавать доступ к базе данных микросервису?

Question

[EgorSvinarev]

Добрый вечер!
Занимаюсь проектированием учебного приложения на основе микросервисной архитектуры и возникла следующая ситуация: я планирую реализовывать API Gateway, на котором будет осуществляться авторизация/аутентификация пользователя. Каждый запрос будет прокидываться через сервис Auth, в котором будет проходить аутентификация средствами JWT-токенов. Ниже представил диаграмму:

Но тут у меня возник вопрос: откуда брать данные в Auth сервисе? Стоит ли выдавать ему прямой доступ к БД сервиса Users? Или лучше настроить отдельной реплику этой БД для него? А может стоит вообще поместить логику авторизации/аутентификации в сервис Users? (последний вариант спорный, потому что по идее сервис Auth должен быть максимально отказоустойчив и легковесен, т.к. через него проходит весь трафик приложения)

Comments

[Василий Банников]

Стоит ли выдавать ему прямой доступ к БД сервиса Users?

А какие данные из Users вдруг понадобились для аутентификации?

[EgorSvinarev]

Василий Банников, условно email/логин, пароль. Я планировал их там хранить

[Василий Банников]

EgorSvinarev, а зачем пароли в Users хранить?

Answer 1

[Сергей Горностаев]

1. Заводите для сервиса auth базу, в которой хранится только информация связанная с аутентификацией и авторизацией - идентификатор пользователя, хэш пароля, набор ролей, дата последней попытки логина, дата последнего успешного логина, количество неудачный попыток входа и т.п.;
   
2. Из БД сервиса User эту информацию убираете, храните там остальные данные пользователя - логин, ФИО, адрес и т.п.;
   
3. Добавляете в систему брокер очередей;
   
4. При регистрации нового пользователя сервис User порождает событие, кладёт его в очередь, а сервис Auth подписывается на эти события и создаёт у себя в БД соответствующие записи.
   

Answer 2

[historydev]

Судя по твоей схеме, у тебя все запросы через этот api gateway идут. Почему сервис который работает с api, стучится в auth, он авторизовывается?

Но и в целом эта система говно с одной точкой для всех запросов.
- Если дудосеры дудосят шлюз - всё страдать будет:
client => gateway => auth | payment | other | ...❌

Твой шлюз это по сути фасад, так используй разные фасады для разных задач, чтобы твою единственную точку входа до смерти не долбили:
client => auth gateway => auth1 | auth2 | auth3 | ...✅
client => payments gateway => payment1 | payment2 | shipment | ...✅
payment1 | payment2 | shipment | other | ... => db gateway => dbservice1 | dbservice2 | dbservice3 | ...✅

Если ты собрался выдавать каждому встречному-поперечному сервису доступ к базе - то тебе не нужны микросервисы.
Если используешь их, то твой "dbservice" должен уметь множится.

В зависимости от нагрузки на каждый отдельный экземпляр "dbservice", "db gateway" - должен решить, куда направить запрос.

Comments

[Сергей Горностаев]

Почему сервис который работает с api, стучится в auth, он авторизовывается?

Классический подход, поставить api gateway, спрятать за ним микросервисы и доверить ему аутентификацию и авторизацию запросов например через Keycloak. Сбер, МТС, Озон и многие другие так работают.

Если дудосеры дудосят шлюз - всё страдать будет

Шлюзы обычно делаются с расчётом на лёгкое горизонтальное масштабирование, дудосить сотню инстансов шлюза ничуть не проще, чем по десять инстансов десяти микросервисов.

[historydev]

дудосить сотню инстансов шлюза ничуть не проще, чем по десять инстансов десяти микросервисов.

Я отталкивался от того, что шлюз один, как на схеме.

Шлюзы обычно делаются с расчётом на лёгкое горизонтальное масштабирование

То есть эта схема распространяется на одну машину?

[Сергей Горностаев]

historydev, схема концептуальная, а не сетевая, каждый кубик вполне может быть системой размазанной по десяткам узлов в трёх ЦОДах.

[historydev]

Сергей Горностаев, Мне кажется автор не концептуальную рисовал)

Но с таким кол-вом информации, проще на кофейной гуще гадать, чем предположения выдвигать.

Если шлюзы и всё вполне может быть отдельной тачкой, кто решает какой шлюз выбрать?

Клиент, днс или ещё кто?

[Василий]

historydev, так может не стоит сразу кидаться какашками, если информации не достаточно.

Answer 3

[Василий]

Общее правило 1 сервис 1 хранилище. Я бы предложил не усложнять систему. Пусть сервис Auth ходит в сервис User.

Answer 4

[Сергей Сахаров]

Конечно, я не разработчик, но
почему бы к БД не подключить AAA-сервис, например RADIUS?
https://ru.wikipedia.org/wiki/RADIUS