Это глава из написанного мной «Руководства по сборке с помощью Serverless AWS». Для получения дополнительной информации о целях и фокусах руководства, пожалуйста, прочтите главу «Введение».

Оглавление:

  1. "Введение"
  2. Бессерверное введение
  3. Введение в облако и AWS
  4. Инфраструктура как код
  5. "Я"
  6. ВПК
  7. Лямбда
  8. API-шлюз
  9. ДинамоДБ
  10. S3
  11. Облачные часы
  12. Облачный фронт
  13. Маршрут 53
  14. СНС (Вы здесь)
  15. СКС
  16. Кинезис
  17. Семейство инструментов разработчика
  18. Бессерверные контейнеры

Когда система становится все более и более сложной, время обработки может выйти из-под контроля. Независимо от того, сколько настроек или оптимизаций мы вносим в обработчики конечных точек API, иногда лучше просто убрать часть этой логики с критического пути. Конечная цель создания такого асинхронного рабочего процесса — ограничить задержку, с которой сталкивается пользователь при завершении обработки запроса в фоновом режиме. В традиционных системах это может означать создание службы очередей, отправку сообщений в очередь и использование этих сообщений в фоновом режиме. С AWS мы можем добиться всего этого с помощью Simple Notification Service (SNS).

Честно говоря, я не осознавал полезности SNS до тех пор, пока довольно поздно не начал свой путь к AWS. Уменьшить задержку может быть сложно. Я обнаружил, что перемещение логики из взаимодействия с пользователем в фоновый режим иногда проще и выгоднее, чем пытаться максимально оптимизировать код. SNS очень полезен при создании асинхронных рабочих процессов такого типа, особенно потому, что он легко интегрируется с Lambda. Я упомянул об архитектурах, управляемых событиями, в главе о Lambda, и SNS — это то, что управляет этими событиями в системе.

Есть несколько фундаментальных концепций, связанных с SNS, которые необходимо понять, прежде чем я перейду к своим вариантам использования. SNS — это просто генератор событий, и каждый «экземпляр» SNS называется «темой». Мы можем сделать вызов API, чтобы опубликовать событие в теме. Затем топик отправляет это событие всем своим «подпискам» на основе примененных к ним «политик фильтрации». Часто мы называем подобную систему распределенной системой обмена сообщениями с публикацией и подпиской (pub/sub), где Apache Kafka является действующим программным обеспечением.

Тема — это то, что считается экземпляром системы массового обслуживания. Поскольку SNS является бессерверной, мы можем создать столько тем, сколько захотим, но лично мне нравится создавать только одну для каждой рабочей нагрузки или API. Это сохраняет все центральное расположение и менее запутанным. Я отделяю свою логику обработки, используя политики фильтрации для своих подписок.

Подписка на тему SNS довольно проста. Мы можем подписаться на несколько типов конечных точек, включая HTTPS, электронную почту, SMS, SQS (подробнее об этом позже), Kinesis (опять же, подробнее об этом позже) и Lambda. Если подписчик внешний (HTTPS, электронная почта, SMS), то подписываемся на конечную точку, адрес электронной почты или номер телефона. Если подписчиком является другой сервис AWS, то мы можем подписаться на сервис напрямую, используя его ARN. После того, как подписка установлена, любые события, опубликованные в теме, будут переданы всем подпискам.

После создания темы и начала создания моих подписок мне нравится добавлять политики фильтрации в свои подписки, чтобы поддерживать более детальный контроль над тем, какие события обрабатываются моими подписками Lambdas. Политики фильтрации — это то, что позволяет мне использовать одну тему для нескольких типов событий. Единственный трюк с использованием политик фильтрации заключается в том, что те же ключи и значения, которые используются в политике фильтрации, должны быть включены в запрос API « Publish » в качестве «атрибутов сообщения». Это единственный способ, с помощью которого SNS будет знать, как точно доставлять эти события.

Сейчас мне нравится структурировать мои проекты для асинхронной обработки: стандартный шлюз API и лямбда на переднем плане, обслуживающие пользователя на критическом пути, тема SNS для лямбды шлюза API для публикации событий и лямбда с подпиской на это. тема, чтобы использовать эти события на бэкэнде. Обычно создание события на критическом пути занимает меньше времени, чем дополнительная обработка, особенно если дополнительная обработка включает вызовы API. Я также использую AWS SDK для создания полезной нагрузки Publish API в Lambda шлюза API. Помните, что в вызове API Publish мне нужно использовать те же пары ключей и значений атрибута сообщения, которые я использовал в политике фильтрации. Если события не доставляются должным образом, атрибуты сообщения могут не соответствовать политике фильтрации.

Помимо использования SNS для выгрузки логики из конечной точки API, мы уже несколько раз обсуждали полезную интеграцию — CloudWatch Alarms. Теперь, когда мы лучше понимаем, что такое SNS, интеграция с CloudWatch Alarms, надеюсь, стала немного понятнее. Триггер тревоги, который публикует событие в теме SNS, которая отправляет событие в свои подписки. Я лично использовал электронную почту и подписки Lambda с этой интеграцией и добился больших успехов.

Хотя конечной точке API, скорее всего, нужна собственная пользовательская логика, есть вероятность, что вся работа может выполняться асинхронно. Примером этого может быть обработка заказов. Вместо того, чтобы интегрировать API Gateway с Lambda, который будет публиковать только событие, мы можем пропустить Lambda и интегрировать API Gateway напрямую с SNS. Это также то, о чем я упоминал в разделе «Интеграция прокси-сервера шлюза API» в главе «Шлюз API». Хотя конкретные обстоятельства, при которых эффективно используется эта интеграция, могут быть редкими, она может сэкономить некоторую дополнительную задержку для наших пользователей, когда мы сможем ее реализовать.

Одной из интеграций подписки, о которой я упоминал ранее, была AWS SQS, что означает Simple Queue Service. Подождите, я думал, что SNS заменяет настройку традиционной службы очередей? Вроде. SNS и SQS при совместном использовании действительно стали бы альтернативой более традиционному программному обеспечению, такому как Kafka. SNS работает отлично, но SQS добавляет больше надежности. Однако я расскажу о своих мыслях и примерах использования SQS в следующей главе.

В целом, SNS предлагает огромные преимущества и простую интеграцию. С тех пор, как я заново открыл для себя, насколько это может быть важно, я использую SNS во множестве своих рабочих задач. Возможность публиковать события, которые будут обрабатываться в фоновом режиме, высвобождает ресурсы и время, чтобы обеспечить более плавный и быстрый пользовательский интерфейс для моих API. Цена также хорошо сочетается с бессерверными моделями, о которых я уже говорил. Мы платим за SNS по запросу или событию, поэтому наши расходы растут только по мере того, как мы больше используем эту услугу. Цель, как и во всех приложениях, состоит в том, чтобы наше использование увеличивалось вместе с платными пользователями.

Следующая глава: SQSПредыдущая глава: Маршрут 53Категории: Руководство по созданию бессерверных aws

Первоначально опубликовано на https://thomasstep.com 4 октября 2021 г.