Как поддерживать http-сессии в API, развернутом в Kubernetes?

Question

Я разрабатываю API, который будет принимать запросы от клиентов и взаимодействовать с облачным бэкэндом, таким как AWS, от имени клиента.Этот API должен быть масштабируемым, поэтому некоторые исследования привели меня к мысли, что я могу поместить API в контейнеры и позволить масштабировать его через Kubernetes.Я планирую использовать Flask для написания этого API.У меня три вопроса на этот счет:

1. Подходит ли для этого колба?Похоже, благодаря моим исследованиям.
2. Как API должен обрабатывать аутентификацию пользователя на сервере?Должен ли он просто получить имя пользователя / пароль от пользователя, установить соединение с бэкэндом на основе этих учетных данных и каким-либо образом поддерживать получающееся соединение в памяти / базе данных?Есть ли другой способ?
3. Если мы используем второй подход для аутентификации пользователя, то возникает вопрос: я не хочу, чтобы API устанавливал новое соединение с серверной частью при каждом запросе пользователя.Это означает, что мне нужно как-то постоянно поддерживать состояние соединения, чтобы убедиться, что API должен работать децентрализованно.Например, пользователь A ранее обслуживался экземпляром Docker 1 API, но теперь его запрос перенаправляется на экземпляр 2 Docker, в этом случае я хочу использовать то же соединение пользователя с серверной частью, которое было установлено экземпляром API Docker 1.,Итак, как мне поддерживать эту связь?Это противоречит принципам REST API, который не должен иметь состояния?Каков еще вариант для разработки системы, тогда?Спасибо.

Answer 1

1. С колбой должно быть все в порядке, как и во многих других подходах, вам решать, как вы все-таки напишите свой API

2. наилучшим путемна мой взгляд, это что-то вроде аутентификации токена на предъявителя, где вы предоставляете некоторый механизм (ы) аутентификации для службы выдачи токена, и когда у вас есть подписанный токен, ваш API (или прокси-сервер api gateway / auth) может проверить, действителен ли токен (либо самостоятельно, либо по вызову выделенного микросервиса)

3. Если по какой-либо причине вам требуется хранилище сеансов, вам следует внедрить отдельный сервис, который будет хранить эти данные сеансов.Например, вы можете использовать Redis в качестве центрального хранилища.Если вам также нужна HA для этой службы, вам потребуется реализовать хранилище сеансов с некоторой поддержкой кластеризации.