Ответ по умолчанию AWS API Gateway и триггер AWS Lambda

Я экспериментировал с AWS API Gateway и AWS Lambda, чтобы опробовать бессерверную архитектуру. Просматривали блоги и документацию AWS. Пробовали образец GET / POST. Но у меня есть следующее требование к отслеживанию пользовательских событий из моего пользовательского приложения.

  • Events are posted from my application to API end point
    • I wanted the API to respond back with a custom response (Say {'fine'}) (acknowledging that the request has been received)
  • После отправки ответа передайте полезные данные события функции AWS Lambda.

В соответствии с документацией, я понимаю: а) Я могу публиковать события в конечной точке API. Б) При запуске GET / POST функции AWS Lambda - ответьте из функции AWS Lambda на запрос API.

Я хотел изменить приведенное выше и изменить его на а) Отправлять события в конечную точку API а.0) Ответить обратно, подтверждая, что запрос получен [Say {'fine'}] б) Запускать функцию AWS Lambda для обработки полезной нагрузки события

Пожалуйста, поделитесь предложениями о том, как достичь того же.


amazon-web-services aws-lambda serverless-framework aws-api-gateway
person user1652054    schedule 18.05.2016    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Еще одна асинхронная модель, которую использовали многие клиенты:

  1. Настройте API, настроенный для отправки запросы к Amazon Kinesis. Этот API может подтвердить запрос.
  2. Настройте AWS Lambda для использования вашего потока Kinesis.

Эта настройка имеет некоторые преимущества для API-интерфейсов с высокой рабочей нагрузкой, поскольку выборки из потока Kinesis могут быть пакетными и не требуют масштабирования 1: 1 как для ограничений шлюза API, так и для ограничений Lambda.

Обновить

Чтобы ответить на ваши вопросы о масштабируемости:

Кинезис

Kinesis масштабируется, добавляя в поток то, что он называет «осколками». Каждый осколок обрабатывает часть вашего трафика на основе ключа раздела. Каждый сегмент масштабируется до 1000 об / с или 1 Мбит / с (см. лимиты). Даже с меньшими по умолчанию 25 осколками это будет поддерживать до 25 000 об / с или 25 Мбит / с с равномерно распределенным ключом раздела.

API-шлюз

API Gateway имеет ограничение уровня учетной записи по умолчанию в 500 оборотов в секунду, но его можно легко расширить, запросив увеличение лимита. У нас есть заказчики на производстве, которые используют услугу в пределах, превышающих ваш текущий предлагаемый масштаб.

person Bob Kinney    schedule 18.05.2016
comment
Конечно. Попробую это. - person user1652054; 19.05.2016
comment
Онлайн-чтение предполагает, что Kinesis может плохо масштабироваться для очень высокой пропускной способности, как Kafka. Скажем, если я увеличу это до 6000-8000 запросов в секунду, смогут ли API Gateway и Kinesis справиться с этим? Скажи мой средн. размер полезной нагрузки составляет около 25-30 КБ? - person user1652054; 19.05.2016
comment
@ user1652054 Я добавил в свой ответ некоторую информацию о масштабировании. Надеюсь, это ответит на ваш вопрос. - person Bob Kinney; 19.05.2016
comment
Конечно. Спасибо, это было полезно. Я начну опробовать несколько сценариев - person user1652054; 20.05.2016

arrow_upward
0
arrow_downward

Если вы хотите получить быстрый ответ от API и не ждать обработки данных, вы можете:

  • публиковать событие в конечной точке шлюза API
  • запускать AWS Lambda-функцию A
  • асинхронно вызывать лямбда-функцию B с помощью AWS SDK в лямбда-функции A
  • Вызов context.succeed() или context.done() или функцию обратного вызова в лямбда-функции A, чтобы она ответила на шлюз API.
  • лямбда-функция B может обрабатывать данные, пока API Gateway уже получил ответ
person Alexis N-o    schedule 18.05.2016
comment
Спасибо. Однако это может означать двойной биллинг. Мне было интересно, есть ли способ позволить шлюзу API закрыть цикл ответа (например, как это возможно в конечных точках приложения Nodejs express), а затем продолжить обработку. - person user1652054; 19.05.2016
comment
Конечно, с вас будет взиматься плата за это дополнительное выполнение лямбда-выражения, но при 128 МБ памяти и выполнении, вероятно, ниже 100 мс, дополнительные затраты должны быть очень ограничены. Вам придется сравнивать ее с ценой на другие решения, такие как Kinesis, в зависимости от ожидаемого объема запросов. - person Alexis N-o; 19.05.2016

arrow_upward
0
arrow_downward

Сначала вам следует запустить несколько тестов, чтобы увидеть, какое время отклика в реальном мире вы получаете от того, что ваша лямбда-функция завершает всю логику. Если время превышает допустимое для вашего варианта использования, вот еще одно асинхронное решение, с использованием темы SNS для запуска вторичная лямбда-функция.

  1. Клиентский запрос к API-шлюзу -> Вызов лямбда-функции A
  2. Лямбда A проверяет полезную нагрузку, а затем публикует в SNS Topic X
  3. Лямбда A возвращает {fine} сообщение об успешном завершении -> Шлюз API -> клиент
  4. SNS Topic X запускает лямбда-функцию B
  5. Лямбда-функция B реализует заданную логику
person Mikelax    schedule 21.05.2016