У меня есть микро-сервисная архитектура, которая работает с Spring Zuul Gateway, как показано на рисунке ниже. 
Моя служба аутентификации возвращает x-auth-token, сгенерированную средством весенней аутентификации, а мой репозиторий токенов - redis. Таким образом, пользователи должны использовать этот сервис для аутентификации, а затем использовать другие сервисы.
Все мои другие сервисы подключаются к одному и тому же экземпляру redis, поэтому, когда они получают x-auth-token, они могут получить информацию о сеансе пользователя. Обычно я делаю авторизацию, используя аннотацию @PreAuthorize и затем определяя роли, которые могут иметь доступ к контроллеру или методу.
До сих пор все работало нормально. Затем меня попросили добавить функциональность ограничения скорости в эту архитектуру. Так, например, один пользователь не должен иметь возможность сделать более 1 POST запроса на указание c api в сервисе books. Кроме того, если бы было два экземпляра книжного сервиса, я бы хотел, чтобы оба считались единым сервисом, когда речь идет об ограничении скорости.
Я нашел тонны документов, которые ссылались на этот проект , называемый весна-облако Zuul-1022 * ограничения частоты *. Глядя на документ, я понял, что он поддерживает redis как хранилище (хорошо для меня, потому что у меня там уже есть redis), а также поддерживает обработку ограничений скорости для пользователей.
Проблема в том, что мой шлюз zuul ничего не знает о пользователи! У него нет доступа к хранилищу Redis. Если я дам ему доступ к redis, проблема может быть решена, но возникнет еще одна проблема: мне нужно будет дважды авторизовать пользователя, что займет больше времени и больше redis traffi c! один раз в шлюзе, один раз в каждой службе (для проверки ролей и деталей сеанса).
Я ищу решения, наиболее близкие к этому списку потребностей:
- не изменять мой метод аутентификации (я не могу просто переключиться на JWT или OAuth)
- Не дублирует авторизацию или повторные запросы
- Балансирование запросов между моими службами не должно влиять на ограничение скорости. Если каждый экземпляр службы X запрашивается один раз для одного пользователя, то пользователь отправил два запроса.
- Надеемся, что для ответа есть хорошая пружинная поддержка.
- Я бы предпочел иметь возможность динамически изменять пределы.