API-интерфейс прокси с автоматическим выключателем на AWS lambda

Я создаю API, который будет действовать как прокси для n базовых API, которые делают одно и то же. Он будет использовать шаблон прерыватель цепи, чтобы определить, когда один из базовых API недоступен, поэтому прокси-API будет иметь гос. Одним из решений является запуск API на AWS lambda и сохранение состояния прерывателя цепи в AWS ElastiCache.

Есть ли другое более экономичное решение, которое не требовало бы от меня постоянного запуска службы, такой как ElasticCache?


circuit-breaker amazon-web-services aws-lambda amazon-elasticache
person Myles McDonnell    schedule 20.07.2017    source источник
comment
n API, которые делают одно и то же, звучит так, как будто вы пытаетесь заново изобрести балансировщик нагрузки... так что вы можете уточнить, чего вы пытаетесь достичь в целом. Чьи это n API? Они взаимозаменяемы? Каковы ваши действия при срабатывании выключателя? Потенциально вы можете привнести некоторую иронию ненадежности в свою платформу, отслеживая состояние в среде без сохранения состояния.   -  person Michael - sqlbot    schedule 20.07.2017
comment
API делают то же самое (отправляю электронную почту), но имеют разные контракты, поэтому балансировщик нагрузки не подходит. Да, в идеале я бы оставил решение без сохранения состояния, но мне нужно поведение, которое обеспечивает прерыватель цепи, чтобы я мог определять, когда службы работают вверх и вниз, и соответствующим образом маршрутизировать трафик.   -  person Myles McDonnell    schedule 20.07.2017
comment
Хорошо, отправка электронной почты на самом деле является довольно хорошим (относительно редким) примером разрозненных, но взаимозаменяемых API от разных поставщиков. Тем не менее, этот вопрос требует некоторого размышления, поскольку (среди прочего) вам также необходимо передать вызывающей стороне уникальный идентификатор транзакции, чтобы идентифицировать каждое взаимодействие для последующего отслеживания и устранения неполадок того, какая цель обработала сообщение. Похоже, что с почтой лучше всего обращаться с промежуточным хранением, а не с прямой передачей.   -  person Michael - sqlbot    schedule 20.07.2017
comment
Я начинаю изучать аналогичный шаблон/архитектуру для AWS (не обязательно только прокси), и мне было интересно, удалось ли/как вам реализовать шаблон прерывателя цепи в управлении API AWS. Вы наконец использовали лямбду? Поддерживается DynamoDB? Или что-то другое?   -  person Eric B.    schedule 25.02.2018
comment
Не уверен, что понимаю всю проблему, но если вы просто ищете хранилище, которое не «всегда включено», то как насчет использования хранилища параметров AWS Systems Manager (docs.aws.amazon.com/systems-manager/latest/userguide/ ) и используя его из лямбда.   -  person Ankit Gupta    schedule 06.07.2019

Ответы (1)


arrow_upward
0
arrow_downward

Вероятно, я бы сохранил часть состояния в лямбде с временным кодом, который, как я полагаю, будет довольно коротким. Очевидно, что наличие этих данных не гарантируется (лямбда-выражения и резервное копирование будут пустыми), поэтому, если их нет или они превышают некоторое значение времени, с которым подходит ваше решение, возьмите их из DynamoDB. DynamoDB — это экономичное решение, которое быстро выполняет поиск с помощью PK. Но вы всегда будете хотеть писать какие-либо обновления в DynamoDB.

Я только что увидел, что этому 3 года, так что ˜\__(ツ)_/˜

person Jim    schedule 07.08.2020