Я строю систему на основе микросервисов. Это веб-приложение, подключенное к разным остальным APIS. Теперь я хочу реализовать систему авторизации (не аутентификацию), поэтому в основном я хочу иметь возможность определить, какие пользователи в системе могут выполнять какие действия.
Поэтому я думаю реализовать для этого систему ролей / разрешений.
Однако у меня возникла дилемма по поводу двух разных вариантов архитектуры, и я хотел бы узнать ваши мысли, советы, плюсы и минусы, чтобы двигаться вперед.
Будет специальный микросервис для обработки пользовательских разрешений и ролей, поэтому в основном этот микросервис будет иметь доступ к двум таблицам базы данных, устанавливающим связь между пользователем и ролями, а также ролями и разрешениями. Это общая часть двух решений, которые я рассмотрел.
Теперь оба варианта с плюсами и минусами на мой взгляд:
1) Сохранение для каждого микросервиса таблицы кеша с разрешениями пользователя, специфичными для этого микросервиса. Таким образом, каждый раз, когда пользователь хочет выполнить действие на этом микросервисе (скажем, удалить заказ на микросервисе заказа), микросервис будет проверять эту таблицу, предоставляя или не предоставляя пользователю доступ для выполнения действия.
Плюсы: каждый микросервис на самом деле является микросервисом, независимой службой, которая может работать полностью автономно с остальной частью системы. Если основной микросервис, обрабатывающий пользовательское разрешение, дает сбой и он недоступен, остальные микросервисы будут продолжать работать.
Минусы: если я обновляю пользовательские разрешения в микросервисе, который обрабатывает это, мне нужно отправить сообщение всем микросервисам, чтобы обновить их соответствующие таблицы разрешений.
2) Создание микросервиса шлюза API, который будет действовать в качестве промежуточного программного обеспечения между внешним интерфейсом и остальными микросервисами и использовать в нем graphql. Фронтенд больше не будет знать об остальных микросервисах, только узнает об этом.
Этот микросервис будет перехватывать все запросы от внешнего интерфейса, проверять в микросервисе разрешений пользователей, имеет ли пользователь разрешение на выполнение действия и, если да, вызывать соответствующий микросервис.
Плюсы: вся бизнес-логика, определяющая, имеет ли пользователь доступ или нет, находится в одном микросервисе, а не дублируется между микросервисами. Кроме того, аутентификация должна быть реализована только в микросервисе промежуточного программного обеспечения, нет необходимости перепроверять, прошла ли аутентификация пользователя на внутренних микросервисах, как если бы мы туда попали, потому что мы были успешно аутентифицированы ранее.
Нет необходимости обновлять таблицы кеша во внутренних микроуслугах, если обновляются роли или разрешения пользователя.
Минусы: это противоречит определению микросервисной архитектуры. Т.е. в случае сбоя микросервиса промежуточного программного обеспечения вся система выйдет из строя.
Я бы хотел узнать ваши мысли !!
Спасибо!