Пример печенья с предсказанием
Почему для простых запросов стоит арендовать целый сервер? Для большинства веб-сайтов обычные серверы часто простаивают 99% времени, пока кому-то не понадобится выполнить какое-либо обслуживание. Так почему бы не иметь возможность использовать сервер только при необходимости? Это одна из многих фундаментальных причин, по которым бессерверные архитектуры преследовались и популяризировались в последнее время в мире разработки.
- Обработка по запросу. Вы платите и используете ресурсы сервера только в течение времени, необходимого для обработки ваших запросов. Если ваш сервер используется только 500 миллисекунд в день, именно столько вы используете серверного времени, и именно столько вам выставили счет.
- Снижение накладных расходов на маршрутизацию: бессерверные провайдеры, такие как AWS, имеют веб-интерфейсы для детальной настройки бессерверных конечных точек. Это значительно снижает накладные расходы на маршрутизацию, которые вам обычно приходится выполнять для сервера, который вы настраиваете самостоятельно.
- Принудительная модульность. Бессерверные архитектуры - это наборы небольших модулей, которые можно вызывать. Это дает вам модульную архитектуру разработки, которая может хорошо масштабироваться.
Осознав преимущества, давайте рассмотрим пример печенья с предсказанием, который я написал с использованием бессерверной архитектуры. Я буду использовать AWS в качестве поставщика бессерверной архитектуры.
После того, как вы ознакомитесь с ситуацией, вы должны иметь твердое представление о том, как разрабатывать и связывать бессерверные архитектуры с вашими интерфейсными приложениями.
Этот пример использования предполагает некоторое знакомство с AWS. Я постараюсь изо всех сил объяснить все этапы настройки бессерверной архитектуры с AWS. Исходный код можно посмотреть по адресу http://github.com/ahmedsakr/fortune-cookie-serverless
Что такое лямбда?
Лямбды - это основа ваших бессерверных архитектур. Думайте о лямбдах как о независимых частях вашего сервера (реже). Это просто программы JavaScript, которые выполняются для выполнения четко определенной задачи. В нашем случае использования я определил 1 лямбда для моей бессерверной архитектуры, которая выплевывает разные состояния при каждом вызове!
Реализация лямбда requestFortune
очень тривиальна: она возвращает случайное состояние из заранее определенного набора состояний. Ваши лямбда-выражения могут быть очень сложными частями программ, которые выполняют сложные операции: загрузку / загрузку изображений, регистрацию / подписку пользователя, манипуляции с базой данных и многое другое.
Вся картина
Это приложение cookie с предсказаниями не просто показывает список строк, которые оно хранит на стороне клиента. Он вызывает лямбду AWS с перекрестным происхождением, прося дать ему целое состояние, ожидает ответа, а затем показывает ответ пользователю.
Давайте рассмотрим вариант использования на высоком уровне, прежде чем мы перейдем к специфике всех трех этапов:
- Пользователь нажимает «запросить состояние». Обработчик JavaScript вызывается для отправки HTTP-запроса GET в конечную точку AWS API Gateway.
- API Gateway вызывает
requestFortune
лямбда (функцию). Эту часть можно полностью настроить через веб-интерфейс AWS. - Lambda возвращает состояние обработчику JavaScript. Обработчик JavaScript получает состояние в теле ответа и отображает его на странице.
Каждый пункт играет важную роль в реализации бессерверной архитектуры. Давайте изучим, как я подключил каждый этап, чтобы завершить бессерверную архитектуру.
Отправка метода HTTP
Это должно быть вам знакомо, если вы написали интерфейсные приложения, которые взаимодействуют с экспресс-серверами, или использовали REST API. При переходе с серверной на бессерверную архитектуру ничего не меняется с точки зрения дизайна.
Вот обработчик, который вызывается при нажатии кнопки «Запросить удачу».
В конечную точку AWS API Gateway отправляется метод HTTP GET, который предоставляет requestFortune
лямбда, о которой мы говорили ранее. Получив ответ, он заменяет элемент fortune-text
данными, полученными в ответе!
Это завершает логику для клиента, отображающего состояние. Теперь нам нужно обсудить, как получить лямбда-выражение, загруженное в AWS и выполненное из шлюза API, который предоставляет конечную точку, подобную той, которая показана на fortune.js
выше.
Загрузка лямбды в AWS
Я использовал пакет serverless
npm для загрузки вашей лямбды в AWS. Вот файл yml, который я использовал для настройки лямбда-выражения cookie с предсказанием.
В этом YAML-файле указаны определенные конфигурации, которые инструктируют AWS о том, как построить мой стек CloudFormation. Если вы не знакомы с этим, не беспокойтесь, поскольку в этом нет необходимости разбираться в бессерверных архитектурах. Все, что вам нужно извлечь из этого, - это то, что лямбда-файл загружается в AWS, чтобы мы могли его вызвать.
Создание и настройка API Gateway
Теперь, когда наша лямбда доступна на AWS, мы хотим показать ее использование конечной точке шлюза API, аналогичной той, которая использовалась в fortune.js
выше.
Используя интерфейс API Gateway, я создал REST API, поддерживающий метод GET. Я связал свою недавно загруженную лямбду, которая будет вызываться, когда REST API получит запрос GET.
После этого я развернул свой API и получил следующую конечную точку, в которую можно отправить метод HTTP GET для вызова лямбда-выражения:
https://a9vymko126.execute-api.ca-central-1.amazonaws.com/test
Вот и все! мой проект теперь бессерверный!
Моя лямбда теперь развернута через шлюз API, и у меня есть URL-адрес REST API, на который я могу отправлять запросы GET, чтобы получить в качестве ответа целое состояние.
Теперь, когда все это настроено, я:
- Запуск сервера только тогда, когда кто-то вызывает лямбду для получения состояния
- Оплата только за время, которое лямбда занимает при выполнении.
Вот как выглядит вкладка сети после запроса нескольких состояний:
В среднем моему приложению требуется всего 30 миллисекунд, чтобы отправить запрос на получение состояния с помощью лямбды! Разве это не здорово?
А главное - AWS предоставляет 1 000 000 бесплатных лямбда-вызовов в месяц. Скорее всего, вам даже не придется ничего платить за приложение, использующее ресурсы сервера.