[IT-инфраструктура, Amazon Web Services, DevOps, Serverless] Реализуем бессерверный API с AWS Gateway и Lambda (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Без API не обходится ни одно веб-приложение. Для их разработки используются разные методы. Сейчас, например, набирает популярность бессерверный подход — он экономичный, масштабируемый и относительно простой. Как ведущий провайдер бессерверных вычислений Amazon Web Services (AWS) вносит огромный вклад в бессерверную разработку. Здесь мы обсудим общие концепции реализации API с помощью AWS Lambda и других сервисов AWS.
Почему именно AWS Lambda?
AWS Lambda — это сервис AWS, который отвечает за выполнение определенных функций в ответ на триггеры, то есть события в приложении. Это могут быть HTTP-вызовы, события в других сервисах AWS, например S3, Kinesis или SNS, или повторяющиеся запланированные события. Функции выполняются в эфемерных контейнерах, подготовкой и масштабированием которых занимается AWS, так что разработчики избавлены от хлопот, связанных с инфраструктурой.
Еще одно привлекательное преимущество — оплата по мере использования. Вы платите только за общее время выполнения функций и не тратитесь в периоды простоя. Конечно, у Lambda, как и у любого другого сервиса, есть свои ограничения. Он не подходит для некоторых задач вроде очень длительных заданий, интенсивных вычислений или процессов, где мы должны контролировать среду выполнения. Но для реализации API сервис AWS Lambda обычно подходит идеально.
Роль API Gateway
AWS API Gateway — это сервис, с помощью которого разработчики создают конечные точки (HTTP endpoints), управляют ими и сопоставляют их с определенными ресурсами AWS, а также настраивают кастомные домены, механизмы авторизации, кэширование и другие фичи. API Gateway — это основная часть бессерверного API, потому что отвечает за связь между определенным API и функцией, обрабатывающей запросы к этому API.
HTTP API
API Gateway включает множество функций и интеграций. В какой-то момент в Amazon поняли, что разработчикам, которые используют бессерверные вычисления, обычно не нужно столько всего. Скорее, они предпочли бы в целом упростить процесс реализации. Наверное, поэтому в конце 2019 года AWS объявили о новых HTTP API, облегченной версии API Gateway, которая существенно упрощает разработку, повышает производительность и снижает расходы для бессерверных API. Несмотря на свою простоту, HTTP API поддерживают такие важные фичи, как настройка CORS для всех конечных точек, интеграция JWT, кастомные домены и соединения с VPC.
Принципы бессерверных API
Чтобы разобраться с главными принципами реализации бессерверных API, рассмотрим лаконичный пример простого приложения виртуальной доски, состоящий из двух конечных точек: POST для записи сообщений и GET для извлечения трех последних сообщений. Рассмотрим и другие возможные функции (параметры пути, CORS и авторизаторы), но постараемся не усложнять финальную реализацию.
AWS DynamoDB
Наш проект будет полностью бессерверным, поэтому используем AWS DynamoDB для хранения сообщений. Эта база данных отвечает принципам бессерверной архитектуры — простота использования и оплата только за запросы. DynamoDB — это база данных NoSQL «ключ-значение» от AWS, где данные хранятся на серверах AWS и полностью управляются Amazon.
AWS Serverless Application Model
Для реализации вам понадобится аккаунт AWS, а также установленный и настроенный фреймворк AWS Serverless Application Model (SAM). SAM — это инструмент для создания, обновления и администрирования бессерверных приложений и всех ресурсов, которые нужны ему для работы. С AWS SAM мы не создаем каждый сервис вручную на веб-консоли — мы просто описываем все, что нам нужно, в специальном файле шаблона.
После установки CLI переходим в нужный каталог и выполняем команду:
$ sam init -r nodejs12.x -n whiteboard
Инициализация нового проекта
Выбираем первую опцию и нажимаем Quick Start from Scratch (Быстрый запуск с нуля). Создается каталог нашей доски с минимумом установочных файлов.
Определяем необходимые ресурсы
Сначала открываем файл template.yml и удаляем все, что находится под разделом Resources. Прежде чем перейти к самому API, создаем дополнительные ресурсы. Определяем таблицу DynamoDB, где будут храниться сообщения:
Resources:
BoardMessagesTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: board-messages-table
AttributeDefinitions:
- AttributeName: partKey
AttributeType: S
- AttributeName: createdAt
AttributeType: N
KeySchema:
- AttributeName: partKey
KeyType: HASH
- AttributeName: createdAt
KeyType: RANGE
ProvisionedThroughput:
ReadCapacityUnits: 5
WriteCapacityUnits: 5
Объявление таблицы DynamoDB
AWS создает таблицу DynamoDB, где атрибутом partKey будет ключ партиции, одинаковый для всех записей, а атрибутом createdAt будет ключ диапазона для сортировки по метке времени. Можно добавить в записи другие ключи и значения, но определять их необязательно.
Теперь в том же файле, сразу под предыдущим определением, объявим HTTP API, с которым будут связаны все будущие конечные точки и функции.
BoardHttpApi:
Type: AWS::Serverless::HttpApi
Properties:
StageName: Test
CorsConfiguration: True
Объявление HTTP API
Это очень короткое и простое определение — название этапа и конфигурация CORS, которые, впрочем, необязательны. Видите, каким простым и лаконичным может быть создание API? При необходимости, конечно, можно добавить самые разные свойства, например ссылку на функцию авторизации, определение домена, параметры логирования и другие.
Определяем функции обработчиков API
Наконец, определив все API, давайте объявим две функции, связанные с конкретными конечными точками.
PostMessageFunction:
Type: AWS::Serverless::Function
Properties:
Handler: src/handlers/postMessage.handler
Runtime: nodejs12.x
MemorySize: 128
Timeout: 5
Events:
PostMessage:
Type: HttpApi
Properties:
ApiId: !Ref BoardHttpApi
Method: POST
Path: /messages
Policies:
- AmazonDynamoDBFullAccess
GetMessagesFunction:
Type: AWS::Serverless::Function
Properties:
Handler: src/handlers/getMessages.handler
Runtime: nodejs12.x
MemorySize: 128
Timeout: 5
Events:
GetMessages:
Type: HttpApi
Properties:
ApiId: !Ref BoardHttpApi
Method: GET
Path: /messages
Policies:
- AmazonDynamoDBFullAccess
Объявление обработчиков для запросов POST и GET
Тут все понятно: две функции, одна из которых будет вызываться при запросе POST к пути /messages, а другая — при запросе GET к тому же пути. У обеих функций есть ограничения на 128 МБ оперативки и пятисекундный таймаут. Код функций находится в файлах postMessage.js и getMessage.js в каталоге /src/handlers/. Создадим их прямо сейчас. (Мы предоставили полный доступ к DynamoDB в разделе Policies каждой функции, чтобы упросить код. В реальном проекте доступ нужно будет настроить более тонко).
Написание функций
Идем в каталог /src/handlers и создаем файлы со следующим содержимым:
postMessage.js
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB();
exports.handler = async (event) => {
const { body } = event;
try {
const { author, text } = JSON.parse(body);
if (!author || !text) {
return {
statusCode: 403,
body: 'author and text are required!'
}
}
await dynamodb.putItem({
TableName: 'board-messages-table',
Item: {
msgId: { S: 'board' },
author: { S: author },
text: { S: text },
createdAt: { N: String(Date.now()) } // still expects string!
}
}).promise();
return {
statusCode: 200,
body: 'Message posted on board!',
}
} catch (err) {
return {
statusCode: 500,
body: 'Something went wrong :(',
}
}
};
Код обработчика запросов POST
Эта функция будет выполняться в ответ на запросы POST. Она вычленяет из тела запроса автора и текст и сохраняет эти данные в базе данных. Еще она заполняет атрибут partKey одинаковым значением для всех записей. Обычно это не лучший метод, но для нашего примера подходит, потому что позволяет выполнять сортировку по ключам диапазона среди всех элементов с одинаковым ключом партиции. Кстати, DynamoDB всегда ожидает строку, даже если тип атрибута — число.
getMessages.js
const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB();
exports.handler = async () => {
try {
const result = await dynamodb.query({
TableName: 'board-messages-table',
KeyConditionExpression: 'partKey = :partKey',
ScanIndexForward: false,
Limit: 3,
ExpressionAttributeValues: {':partKey': { S: 'board'}}
}).promise();
return {
statusCode: 200,
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify(result.Items),
}
} catch (err) {
console.log(err);
return {
statusCode: 500,
body: 'Something went wrong :(',
}
}
};
Код обработчика запросов GET
В этой функции мы сначала получаем записи, у которых partKey равен board, потом задаем для ScanIndexForward значение false, чтобы последние сообщения отображались сверху, и наконец с помощью свойства Limit указываем, что хотим увидеть только три сообщения.
Развёртывание
Деплоить с AWS SAM легко — достаточно одной команды с несколькими введенными значениями. Переходим в root-каталог проекта и выполняем команду:
$ sam deploy --guided
Команда развертывания
Нас попросят ввести имя приложения и выбрать регион AWS, а еще подтвердить несколько действий:
Указание и подтверждение параметров
После подтверждения параметров запускается развертывание и создаются ресурсы. На это уйдет не больше минуты.
Список создаваемых ресурсов их статусы
Когда процесс завершится, открываем веб-консоль AWS в браузере, переходим к сервису API, находим только что созданный API и копируем URL к корневому эндпоинту нашего API.
URL для конечной точки root API
Тестируем API
Давайте напишем на доске несколько сообщений используя, как и большинство из нас, утилиту curl. В следующей команде замените плейсхолдеры своими данными.
curl -d '{"author":"name", "text":"Message text"}' -H "Content-Type: application/json" -X POST https://your-api-id.execute-api.your-region.amazonaws.com/test/messages
Выполнение запроса POST в curl
Отправляем несколько запросов с разными сообщениями. Если все нормально, в консоли отобразится Message posted on board! (Сообщение опубликовано на доске) без ошибок.
Чтобы извлечь последнее сообщение, выполним простую команду, даже короче предыдущей:
curl https://your-api-id.execute-api.your-region.amazonaws.com/test/messages
Выполнение запроса GET в curl
Вот и все. Мы создали простой HTTP API с AWS Lambda и AWS SAM. Конечно, в реальном проекте нужно будет больше функций и конфигураций, но принцип будет тот же: определяем ресурсы, определяем конфигурации, пишем код и запускаем деплой.
Подключение мониторинга Thundra
Будет разумно организовать мониторинг — особенно для бессерверных приложений, где легко запутаться с дебагом и трейсингом.
Можно подключить мониторинг Thundra к только что созданным функциям Lambda (см. краткое руководство). После подключения Thundra вам нужно будет инструментировать функции Lambda postMessage и getMessages, чтобы просмотреть подробную информацию о каждом вызове и получить общую картину приложения.
Выбираем функции в списке, нажимаем сначала кнопку Instrument, а затем OK.
Подтверждение инструментирования функции Lambda
Пробуем сделать несколько запросов к API, возвращаемся на дашборд Thundra, нажимаем на имя функции и выбираем вызовы из списка. Здесь мы видим время, производительность, входные и выходные данные функции и т. д. Это очень полезно при отладке API в реальных проектах.
Сведения об одном вызове
Если вы используете бессерверные вычисления в сложных проектах с разными сервисами AWS или других вендоров, вам определенно пригодится функция Unique Tracing, которая существенно упрощает устранение неполадок и отладку приложения.
Стоит ли использовать HTTP API?
С помощью HTTP API с AWS Lambda можно создавать высокопроизводительные и экономичные API. Хоть это и облегченная версия API Gateway REST API, она обладает всем необходимым функционалом и покрывает 90% нужд разработчиков. HTTP API не поддерживают некоторые полезные функции, вроде кэширования, валидации схем и трансформации ответов.
Кэширование вам, скорее всего, не пригодится, потому что HTTP API работают гораздо быстрее старых REST API, а валидацию и трансформацию можно выполнять на уровне кода функции.
Если у ваших разработчиков нет других причин отказаться от HTTP API, можете с уверенностью их использовать. Обычно бессерверная транзакция начинается с вызова API, а отслеживать асинхронный поток событий не так-то просто. В таких ситуациях используйте комплексную функцию распределенного трейсинга в Thundra. Thundra предоставляет 250 тысяч запросов в месяц бесплатно — вполне достаточно для маленьких проектов или стартапов.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Serkan Özal
===========Похожие новости:
- [Информационная безопасность, DevOps] Валидные сертификаты и DNS для сервисов в локальных сетях без удостоверяющего центра
- [DevOps] Приглашаем на DINS DEVOPS EVENING: переезд на Sentry и 4 Golden signals
- [Высокая производительность, Системное администрирование, IT-инфраструктура, Apache] Продвинутый курс по Apache Kafka: 11 апреля старт группы с куратором
- [JavaScript, Git, Управление разработкой, Управление продуктом, DevOps] Введение в непрерывную поставку (CD) при помощи GitLab (перевод)
- [Информационная безопасность, Спортивное программирование, IT-инфраструктура] Открыт набор атакующих и защитников для участия в кибербитве The Standoff на Positive Hack Days
- [IT-инфраструктура, Сетевое оборудование, IT-компании] Возможно ли сделать ЦОД эффективнее и экономичнее одновременно?
- [Администрирование баз данных, Карьера в IT-индустрии, DevOps] Неотправленное письмо боссу в кровавом Enterprise
- [IT-инфраструктура, Гаджеты, IT-компании] Apple распространила программу независимого ремонта почти на весь мир
- [Конференции, DevOps] Повышение цен на конференции и подарки для подписчиков
- [Виртуализация, DevOps, Облачные сервисы] По-прежнему ли актуальны контейнеры? (перевод)
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_amazon_web_services, #_devops, #_serverless, #_aws, #_aws_lambda, #_amazon_web_services, #_api_gateway, #_serverless, #_blog_kompanii_southbridge (
Блог компании Southbridge
), #_itinfrastruktura (
IT-инфраструктура
), #_amazon_web_services, #_devops, #_serverless
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:54
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Без API не обходится ни одно веб-приложение. Для их разработки используются разные методы. Сейчас, например, набирает популярность бессерверный подход — он экономичный, масштабируемый и относительно простой. Как ведущий провайдер бессерверных вычислений Amazon Web Services (AWS) вносит огромный вклад в бессерверную разработку. Здесь мы обсудим общие концепции реализации API с помощью AWS Lambda и других сервисов AWS. Почему именно AWS Lambda? AWS Lambda — это сервис AWS, который отвечает за выполнение определенных функций в ответ на триггеры, то есть события в приложении. Это могут быть HTTP-вызовы, события в других сервисах AWS, например S3, Kinesis или SNS, или повторяющиеся запланированные события. Функции выполняются в эфемерных контейнерах, подготовкой и масштабированием которых занимается AWS, так что разработчики избавлены от хлопот, связанных с инфраструктурой. Еще одно привлекательное преимущество — оплата по мере использования. Вы платите только за общее время выполнения функций и не тратитесь в периоды простоя. Конечно, у Lambda, как и у любого другого сервиса, есть свои ограничения. Он не подходит для некоторых задач вроде очень длительных заданий, интенсивных вычислений или процессов, где мы должны контролировать среду выполнения. Но для реализации API сервис AWS Lambda обычно подходит идеально. Роль API Gateway AWS API Gateway — это сервис, с помощью которого разработчики создают конечные точки (HTTP endpoints), управляют ими и сопоставляют их с определенными ресурсами AWS, а также настраивают кастомные домены, механизмы авторизации, кэширование и другие фичи. API Gateway — это основная часть бессерверного API, потому что отвечает за связь между определенным API и функцией, обрабатывающей запросы к этому API. HTTP API API Gateway включает множество функций и интеграций. В какой-то момент в Amazon поняли, что разработчикам, которые используют бессерверные вычисления, обычно не нужно столько всего. Скорее, они предпочли бы в целом упростить процесс реализации. Наверное, поэтому в конце 2019 года AWS объявили о новых HTTP API, облегченной версии API Gateway, которая существенно упрощает разработку, повышает производительность и снижает расходы для бессерверных API. Несмотря на свою простоту, HTTP API поддерживают такие важные фичи, как настройка CORS для всех конечных точек, интеграция JWT, кастомные домены и соединения с VPC. Принципы бессерверных API Чтобы разобраться с главными принципами реализации бессерверных API, рассмотрим лаконичный пример простого приложения виртуальной доски, состоящий из двух конечных точек: POST для записи сообщений и GET для извлечения трех последних сообщений. Рассмотрим и другие возможные функции (параметры пути, CORS и авторизаторы), но постараемся не усложнять финальную реализацию. AWS DynamoDB Наш проект будет полностью бессерверным, поэтому используем AWS DynamoDB для хранения сообщений. Эта база данных отвечает принципам бессерверной архитектуры — простота использования и оплата только за запросы. DynamoDB — это база данных NoSQL «ключ-значение» от AWS, где данные хранятся на серверах AWS и полностью управляются Amazon. AWS Serverless Application Model Для реализации вам понадобится аккаунт AWS, а также установленный и настроенный фреймворк AWS Serverless Application Model (SAM). SAM — это инструмент для создания, обновления и администрирования бессерверных приложений и всех ресурсов, которые нужны ему для работы. С AWS SAM мы не создаем каждый сервис вручную на веб-консоли — мы просто описываем все, что нам нужно, в специальном файле шаблона. После установки CLI переходим в нужный каталог и выполняем команду: $ sam init -r nodejs12.x -n whiteboard Инициализация нового проекта Выбираем первую опцию и нажимаем Quick Start from Scratch (Быстрый запуск с нуля). Создается каталог нашей доски с минимумом установочных файлов. Определяем необходимые ресурсы Сначала открываем файл template.yml и удаляем все, что находится под разделом Resources. Прежде чем перейти к самому API, создаем дополнительные ресурсы. Определяем таблицу DynamoDB, где будут храниться сообщения: Resources:
BoardMessagesTable: Type: AWS::DynamoDB::Table Properties: TableName: board-messages-table AttributeDefinitions: - AttributeName: partKey AttributeType: S - AttributeName: createdAt AttributeType: N KeySchema: - AttributeName: partKey KeyType: HASH - AttributeName: createdAt KeyType: RANGE ProvisionedThroughput: ReadCapacityUnits: 5 WriteCapacityUnits: 5 Объявление таблицы DynamoDB AWS создает таблицу DynamoDB, где атрибутом partKey будет ключ партиции, одинаковый для всех записей, а атрибутом createdAt будет ключ диапазона для сортировки по метке времени. Можно добавить в записи другие ключи и значения, но определять их необязательно. Теперь в том же файле, сразу под предыдущим определением, объявим HTTP API, с которым будут связаны все будущие конечные точки и функции. BoardHttpApi:
Type: AWS::Serverless::HttpApi Properties: StageName: Test CorsConfiguration: True Объявление HTTP API Это очень короткое и простое определение — название этапа и конфигурация CORS, которые, впрочем, необязательны. Видите, каким простым и лаконичным может быть создание API? При необходимости, конечно, можно добавить самые разные свойства, например ссылку на функцию авторизации, определение домена, параметры логирования и другие. Определяем функции обработчиков API Наконец, определив все API, давайте объявим две функции, связанные с конкретными конечными точками. PostMessageFunction:
Type: AWS::Serverless::Function Properties: Handler: src/handlers/postMessage.handler Runtime: nodejs12.x MemorySize: 128 Timeout: 5 Events: PostMessage: Type: HttpApi Properties: ApiId: !Ref BoardHttpApi Method: POST Path: /messages Policies: - AmazonDynamoDBFullAccess GetMessagesFunction: Type: AWS::Serverless::Function Properties: Handler: src/handlers/getMessages.handler Runtime: nodejs12.x MemorySize: 128 Timeout: 5 Events: GetMessages: Type: HttpApi Properties: ApiId: !Ref BoardHttpApi Method: GET Path: /messages Policies: - AmazonDynamoDBFullAccess Объявление обработчиков для запросов POST и GET Тут все понятно: две функции, одна из которых будет вызываться при запросе POST к пути /messages, а другая — при запросе GET к тому же пути. У обеих функций есть ограничения на 128 МБ оперативки и пятисекундный таймаут. Код функций находится в файлах postMessage.js и getMessage.js в каталоге /src/handlers/. Создадим их прямо сейчас. (Мы предоставили полный доступ к DynamoDB в разделе Policies каждой функции, чтобы упросить код. В реальном проекте доступ нужно будет настроить более тонко). Написание функций Идем в каталог /src/handlers и создаем файлы со следующим содержимым: postMessage.js const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB(); exports.handler = async (event) => { const { body } = event; try { const { author, text } = JSON.parse(body); if (!author || !text) { return { statusCode: 403, body: 'author and text are required!' } } await dynamodb.putItem({ TableName: 'board-messages-table', Item: { msgId: { S: 'board' }, author: { S: author }, text: { S: text }, createdAt: { N: String(Date.now()) } // still expects string! } }).promise(); return { statusCode: 200, body: 'Message posted on board!', } } catch (err) { return { statusCode: 500, body: 'Something went wrong :(', } } }; Код обработчика запросов POST Эта функция будет выполняться в ответ на запросы POST. Она вычленяет из тела запроса автора и текст и сохраняет эти данные в базе данных. Еще она заполняет атрибут partKey одинаковым значением для всех записей. Обычно это не лучший метод, но для нашего примера подходит, потому что позволяет выполнять сортировку по ключам диапазона среди всех элементов с одинаковым ключом партиции. Кстати, DynamoDB всегда ожидает строку, даже если тип атрибута — число. getMessages.js const AWS = require('aws-sdk');
const dynamodb = new AWS.DynamoDB(); exports.handler = async () => { try { const result = await dynamodb.query({ TableName: 'board-messages-table', KeyConditionExpression: 'partKey = :partKey', ScanIndexForward: false, Limit: 3, ExpressionAttributeValues: {':partKey': { S: 'board'}} }).promise(); return { statusCode: 200, headers: { 'Content-Type': 'application/json', }, body: JSON.stringify(result.Items), } } catch (err) { console.log(err); return { statusCode: 500, body: 'Something went wrong :(', } } }; Код обработчика запросов GET В этой функции мы сначала получаем записи, у которых partKey равен board, потом задаем для ScanIndexForward значение false, чтобы последние сообщения отображались сверху, и наконец с помощью свойства Limit указываем, что хотим увидеть только три сообщения. Развёртывание Деплоить с AWS SAM легко — достаточно одной команды с несколькими введенными значениями. Переходим в root-каталог проекта и выполняем команду: $ sam deploy --guided
Команда развертывания Нас попросят ввести имя приложения и выбрать регион AWS, а еще подтвердить несколько действий: Указание и подтверждение параметров После подтверждения параметров запускается развертывание и создаются ресурсы. На это уйдет не больше минуты. Список создаваемых ресурсов их статусы Когда процесс завершится, открываем веб-консоль AWS в браузере, переходим к сервису API, находим только что созданный API и копируем URL к корневому эндпоинту нашего API. URL для конечной точки root API Тестируем API Давайте напишем на доске несколько сообщений используя, как и большинство из нас, утилиту curl. В следующей команде замените плейсхолдеры своими данными. curl -d '{"author":"name", "text":"Message text"}' -H "Content-Type: application/json" -X POST https://your-api-id.execute-api.your-region.amazonaws.com/test/messages
Выполнение запроса POST в curl Отправляем несколько запросов с разными сообщениями. Если все нормально, в консоли отобразится Message posted on board! (Сообщение опубликовано на доске) без ошибок. Чтобы извлечь последнее сообщение, выполним простую команду, даже короче предыдущей: curl https://your-api-id.execute-api.your-region.amazonaws.com/test/messages
Выполнение запроса GET в curl Вот и все. Мы создали простой HTTP API с AWS Lambda и AWS SAM. Конечно, в реальном проекте нужно будет больше функций и конфигураций, но принцип будет тот же: определяем ресурсы, определяем конфигурации, пишем код и запускаем деплой. Подключение мониторинга Thundra Будет разумно организовать мониторинг — особенно для бессерверных приложений, где легко запутаться с дебагом и трейсингом. Можно подключить мониторинг Thundra к только что созданным функциям Lambda (см. краткое руководство). После подключения Thundra вам нужно будет инструментировать функции Lambda postMessage и getMessages, чтобы просмотреть подробную информацию о каждом вызове и получить общую картину приложения. Выбираем функции в списке, нажимаем сначала кнопку Instrument, а затем OK. Подтверждение инструментирования функции Lambda Пробуем сделать несколько запросов к API, возвращаемся на дашборд Thundra, нажимаем на имя функции и выбираем вызовы из списка. Здесь мы видим время, производительность, входные и выходные данные функции и т. д. Это очень полезно при отладке API в реальных проектах. Сведения об одном вызове Если вы используете бессерверные вычисления в сложных проектах с разными сервисами AWS или других вендоров, вам определенно пригодится функция Unique Tracing, которая существенно упрощает устранение неполадок и отладку приложения. Стоит ли использовать HTTP API? С помощью HTTP API с AWS Lambda можно создавать высокопроизводительные и экономичные API. Хоть это и облегченная версия API Gateway REST API, она обладает всем необходимым функционалом и покрывает 90% нужд разработчиков. HTTP API не поддерживают некоторые полезные функции, вроде кэширования, валидации схем и трансформации ответов. Кэширование вам, скорее всего, не пригодится, потому что HTTP API работают гораздо быстрее старых REST API, а валидацию и трансформацию можно выполнять на уровне кода функции. Если у ваших разработчиков нет других причин отказаться от HTTP API, можете с уверенностью их использовать. Обычно бессерверная транзакция начинается с вызова API, а отслеживать асинхронный поток событий не так-то просто. В таких ситуациях используйте комплексную функцию распределенного трейсинга в Thundra. Thundra предоставляет 250 тысяч запросов в месяц бесплатно — вполне достаточно для маленьких проектов или стартапов. =========== Источник: habr.com =========== =========== Автор оригинала: Serkan Özal ===========Похожие новости:
Блог компании Southbridge ), #_itinfrastruktura ( IT-инфраструктура ), #_amazon_web_services, #_devops, #_serverless |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:54
Часовой пояс: UTC + 5