Предложение о системной архитектуре

Question

У меня есть вопрос по системной архитектуре.Я строю систему продажи билетов.По сути, это создание билетов поддержки.

Я пытаюсь выяснить, правильно ли я использовал компоненты.

В первом случае senario:

Клиентский запрос на создание нового билета, шлюз перенаправляет запрос в службу продажи билетов,Билетная служба хочет проверить, является ли токен действительным, поэтому выдает публикацию через nats с токеном, если токен является действительным токеном регистрационной службы аутентификации и информация с парой ключ-значение для Redis в течение некоторого времени, скажем, 30 минут.и опубликовать результат нац.Натс перенаправляет его на тикет сервис.Если все в порядке, служба продажи билетов создает запись в базе данных.

Второй случай senorio:

Пользователь делаетвсе вышеописанные шаги, однако, сторона аутентификации вместо того, чтобы запрашивать службу аутентификации, получает информацию от Redis, если она существует, и делает те же самые шаги еще раз.

Вот мои вопросы,

Делаете ли выдумаете Redis используется для правильной цели?Или я должен просто удалить его и спрашивать снова и снова, когда приходит запрос на аутентификацию?

Как вы думаете, я должен сделать все аутентификации на Gateway?

, поэтому выглядело бы это так, как описано выше.

При первоначальном входе в систему и запросе.(первый сценарий)

После входа в систему (второй сценарий)

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

Заранее спасибо.

Answer 1

Более правильный способ - выполнить аутентификацию через шлюз API, т.е.Аутентификация шлюза API с помощью службы аутентификации, как указано во втором варианте для двух предложенных решений.

Шлюз API должен оказаться «шлюзом» всех ваших запросов и фильтровать любые запросы, которые не аутентифицированы или не авторизованы для доступа к вашим услугам.Аутентификация и авторизация могут быть их собственными службами, в этом случае шлюз API будет использовать для определения, может ли запрос получить доступ к какой-либо другой нисходящей службе.Помимо этого факта это также устраняет сложность, удаляя NATS.Один меньше компонента для работы и управления - это всегда выигрыш.

Одна небольшая модификация, которую я хотел бы сделать, состоит в том, что на втором шаге, вместо шлюза API, идущего непосредственно к Redis, я бы сделал проверку службы проверки подлинности Redis.Другими словами, служба аутентификации сначала перейдет в Redis, а затем перейдет в базу данных.Таким образом, есть больше разъединения.

Шлюзу API не нужно знать, как служба аутентификации хранит ключ для токена в Redis.Поэтому, если вы решите изменить то, каким должен быть ключ в службе аутентификации, вам не придется эффективно развертывать новое изменение способа чтения ключа из Redis в шлюзе API.