Какую архитектуру для высокой доступности REST API вы бы порекомендовали?

Question

[dmitrytut]

Добрый день!

Опишу ситуацию. Наверное, она довольно обыденная, но все же.
Есть rest api и бэкенд на физически разных серверах. Аутентификация и авторизация происходят на бэкенде. Есть высокая вероятность того, что бэкенд может периодически отключаться на непродолжительное время. Поэтому нужно чтобы в эти периоды недоступности бэка api слой не терял запросы, а когда бэк включится, обработал бы их. Еще одну задачу, которую хотелось бы решить, это хотя бы немного сгладить нагрузку на api, так как бывают пики. На ум приходит очередь. Но из-за аутентификации, насколько я понимаю, необходимо складывать в очередь сообщения еще до проверки аутентификации.
Какую бы вы порекомендовали архитектуру в данной ситуации?

Вышеописанное реализовано на стеке: IIS, .Net WebApi, WCF

Спасибо!

Answer 1

[jacob1237]

Не указали какого типа у Вас авторизация и аутентификация и какую роль играет "бэкенд" в этом процессе по отношению к API.

Предположу что авторизация session-based и бэкенд хранит именно сессионные данные, тогда Вам необходимо использовать токены для авторизации, например JWT.
Таким образом слой API не будет иметь никакой связи с бэкендом при авторизации запросов (именно авторизации), т.к. все необходимые данные будут "зашиты" в токене.

Если же у Вас слой API служит только для того, чтобы отображать (проксировать в каком-то смысле) RESTful запросы на внутренний API или протокол (я так понял что WCF у вас в стэке именно об этом) и Вы хотите просто сохранять запросы на сервер (которые должны, видимо, быть больше на запись чем на чтение), воспользуйтесь промежуточным ПО, которое даст возможность складывать в очередь эти задачи.

Примеры ПО: Redis, Beanstalkd.
В первом воспользуйтесь структурой данных LIST, а второй как раз только под это и заточен (не забудьте настроить persistance чтобы не терять данные).

Но т.к. у Вас Windows, то наверное больше подойдет что-то типа hangfire.io
Однако у вышеперечисленного софта есть форки и скомпиленные под Windows бинарники.

По поводу пиков - на то они и пики. Судя по всему, таков характер активности Ваших пользователей.
Я бы в таком случае просто проанализировал характер и время возникновения пиков и подумал бы как можно решить эту задачу предусмотрев просто дополнительные мощности для этого и масштабировал бы воркеров on-demand, т.е. по мере возникновения активности наращиваем мощности, по мере снижения - уменьшаем. Но это больше инфраструктурный вопрос.

Возможно даже что его получится решить через Rate Limiting. Либо своими силами, либо при помощи сервисов типа Apigee: docs.apigee.com/api-services/content/rate-limiting.

К сожалению именно по стэку .NET не подскажу, т.к. сам работаю в другом стэке. Но принципы тут общие.

Comments

[dmitrytut]

Спасибо большое за исчерпывающий ответ!
Есть несколько вариантов в работе, как только закончу - напишу что выбрал и почему.