Прежде чем узнать о возможностях использования бессерверных технологий для создания микросервисов, рассмотрим создание простого веб-приложения с помощью бессерверного стека приложений AWS.
Бессерверные строительные блоки для веб-приложения
На приведенной выше диаграмме показана коллекция доступных в AWS бессерверных технологий для создания бессерверного full-stack веб-приложения. Рассмотрим каждый из них, чтобы разобраться в предоставляемых ими функциях.
AWS CloudFront. Этот сервис работает как прокси-сервер и CDN для запросов приложений. Установленные между браузером пользователя и CloudFront SSL-соединения, в которые будут пересылаться запросы бэкенду и фронтенду приложения, зависят от пути запроса. Например, если браузер запрашивает фронтенд-путь, такой как статическое содержимое (HTML, CSS, JS), CloudFront направляет его в Amazon S3 и обслуживает статическое содержимое. Если браузер запрашивает ресурс API (например, /API/), CloudFront перенаправляет его в бэкенд приложения.
AWS API Gateway работает как прослушиватель событий для запросов ресурсов API, полученных через сеть, и при необходимости запускает лямбда-функции. Эти запросы обычно передаются из CloudFront.
Amazon S3. S3 используется для хранения статических файлов, таких как изображения и другие фронтенд ассеты. Помимо этого варианта использования, S3 также может поддерживать фронтенд часть веб-приложения, если она состоит из статических файлов, таких как HTML, CSS и JS.
AWS Lambda содержит код приложения, который обрабатывает бэкенд функции API. Лямбда предоставляет базовую вычислительную платформу. Ее функционал также способен связываться с базой данных как для извлечения, так и для обновления данных.
AWS DynamoDB — это сервис базы данных NoSQL от AWS для хранения и извлечения данных.
AWS Cognito — полностью управляемое решение для идентификации, выполняющее аутентификацию и авторизацию пользователей с использованием OpenID Connect.
Можно ли использовать бессерверные технологии для микросервисов?
Предположим, что приложение выросло в течение нескольких лет и предлагает сервисы с различными возможностями для бизнеса. При использовании одного и того же стека технологий каждый из микросервисов можно реализовать с помощью APIGateway, Lambda и DynamoDB. Однако стек технологий может различаться в зависимости от конкретных бизнес-требований.
Но так ли просто внедрить микросервисы в растущее приложение, как показано на диаграммах? Ответ: НЕТ!
Диаграммы выглядят простыми из-за отсутствия базовой функциональности, которая заключается во взаимодействии между микросервисами.
В реальном мире эти микросервисы должны взаимодействовать друг с другом для обеспечения бизнес-функций. С другой стороны, эти распределенные системы создают дополнительные проблемы для приложения.
Микросервис прямых API-вызовов
Один из самых простых способов взаимодействия между микросервисами — вызов одного микросервиса другим через API второго. Однако в этом подходе часто происходят сбои, если в одной бизнес-функции задействовано более двух сервисов. Причина сбоев заключается в необходимости подготовки к частичным сбоям без нарушений согласованности данных на разных микросервисах.
Коммуникация микросервисов с использованием асинхронного обмена сообщениями с Pub-Sub с помощью AWS SNS
Самый простой подход для распространения изменений данных между различными микросервисами. Одним из его преимуществ является отсутствие необходимости в том, чтобы один микросервис знал о другом. Нужно лишь добавить прослушиватель для изменений данных в каждом микросервисе.
Для реализации этого подхода нужно найти публикатора и промежуточного подписчика в AWS. Самым простым и эффективным сервисом-кандидатом для этих целей является AWS SNS, который обеспечивает поддержку для объявления топиков, публикации и подписки на них с помощью AWS Lambda. Публикация уведомления в SNS гарантирует, что сообщение будет доставлено всем слушателям, поддерживающим повторную попытку.
Транзакции между микросервисами
Что делать, если изменения являются транзакционными? Для обеспечения этой функциональности нужна дополнительная поддержка промежуточного ПО. В этом случае необходима поддержка как для распространения транзакции между сервисами, так и для отмены в случае возникновения проблемы.
Наилучший вариант — это реализация шаблона SAGA для всех микросервисов, участвующих в транзакции. Проще говоря, выполнение локальных транзакций внутри микросервисов и использование событий для координации между микросервисами с помощью предварительно определенной машины состояний.
При использовании AWS можно смоделировать транзакции с помощью AWS Step Functions для реализации SAGA. Такой подход уменьшает сложность, предоставляя возможность определения машины состояний для обработки транзакции. AWS Step Functions способны координировать транзакцию, а также отменять ее в случае необходимости.
Заключение
Создание full-stack приложений с использованием бессерверных технологий уже становится реальностью. Бессерверные технологии также предоставляют набор промежуточного ПО для поддержки взаимодействий микросервисов, обладающих ключевым значением при реализации даже базовых шаблонов связи для микросервисов.
В этой статье мы рассмотрели лишь несколько вариантов использования из целого множества. Например, при работе с потоковыми данными можно использовать AWS Kinesis. При сохранении порядка обработки различных сообщений можно использовать AWS SQS.
Аналогичным образом экосистемы AWS предоставляют различные строительные блоки для поддержки микросервисов. Модель ценообразования AWS также облегчает выбор различных вариантов дизайна, при которых большая часть цены устанавливается в зависимости от фактического потребления сервиса. Лучшим примером будет использование AWS API Gateway в качестве микро-шлюза для всех микросервисов, что является важным архитектурным решением для других облачных провайдеров.
Читайте также:
- Полезные JavaScript-модули, на которые стоит обратить внимание
- Микросервисы. Руководство для начинающих
- Эффективное использование ESLint
Перевод статьи Ashan Fernando: Can We Use Serverless Functions to Build Microservices?
