В настоящее время я разрабатываю сервис, который позволил бы моим клиентам создавать и развертывать свои API-интерфейсы, в отличие от шлюза AWS Api. Он будет использоваться в качестве точки входа API и направляться на несколько бэкэндов. Логика такого шлюза мне ясна, однако общая архитектура все еще не такова.
В соответствии с современными методами и правилами SaaS мне потребуется создать отказоустойчивое масштабируемое решение, которое обычно принимает некоторую формупараллелизм в запросах на обслуживание (по крайней мере, для API в целом).
Этот шлюз может создавать и развертывать клиентские API (набор конечных точек), которые внедряются в основное дерево маршрутизации приложения. Например, user1 создает API, у которого 3 конечные точки, я вставляю их в дерево как / user1 / stage / xx [1,2,3]. Тогда другой делает то же самое. Шлюз контролирует развертывание и обслуживание своих конечных точек и сохраняет все свои данные в памяти для быстрой маршрутизации.
Здесь наступает масштабируемость. Мне нужно построить шлюз таким образом, чтобы решение не дало сбой, поддерживало бы масштабирование вверх и вниз в соответствии с его потребностями, однако я не понимаю, как можно распределить логику одного приложения во многих случаях.
На ум приходят два подхода, и у них обоих есть свои слабые стороны:
Отдельные сервисы, основанные на количестве процессов, которые он обрабатывает. то есть instance1 обслуживает 100 API, поэтому пришло время создать новый. Для этого потребуется некоторая маршрутизация, чтобы главный балансировщик знал, куда отправлять удаленный запрос - какой экземпляр обрабатывает что. А отказ одного из экземпляров привел бы к падению 100 API
Отделение только экземпляров, имеющих отношение ко всей логике и данным, в одном месте. Создайте столько экземпляров, сколько необходимо, загрузите в них одни и те же данные и балансировщик задач для маршрутизации удаленных запросов в соответствии с логикой балансировки. Для этого потребуется, чтобы все экземпляры принесли ВСЕ API и какую-то контрольную точку для развертывания и отключили клиентские API во всех экземплярах, но это обеспечивает масштабируемость нагрузки. Однако, если будет много API, каждый экземпляр должен будет развернуть их все в своей памяти (обработчики, таблицы маршрутизации и т. Д.).
Я что-то упустил? Как бы вы пошли об этой проблеме? Каков наилучший способ создания масштабируемого и отказоустойчивого шлюза API, такого как этот?