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