Какие проблемы возникают при управлении безсерверной средой или средой Lambda?

146
15

спросил(а) 2020-02-24T14:53:57+03:00 1 год, 9 месяцев назад
1
Лучший ответ
152

Некоторые из проблем лямбда и безсерверной среды:

По запросу Время запуска: лямбды отличаются от традиционного кода Java (веб-приложений и т. Д.), Которые запускаются один раз и остаются включенными до перезапуска пула приложений или JVM. Каждый запрос может породить новый экземпляр лямбды. (хотя в действительности существует отличное повторное использование лямбда-контейнера) Вы можете обойти его, запустив периодическую проверку пинга CloudWatch на лямбдах. Микро-функции вместо нано-функций Если вы пытаетесь внедрить микро-сервис, который имеет 8 веб-методов, вы можете получить 8 разных лямбд. (8 обработчиков) Это слишком большая фрагментация. Нано лямбды Лучше всего иметь один общий лямбда-обработчик (например, лямбда-прокси), а затем обрабатывать 8 маршрутов с ним. Micro-лямбда. Таким образом, микросервис может быть представлен одной лямбдой. Значения конфигурации В скомпилированном коде, таком как C # и Java, пакет развертывания представляет собой ZIP-файл. Это делает файлы свойств или файлы конфигурации как спорные для предоставления динамических значений конфигурации. Другие варианты включают хранение Config в DynamodB, S3, внешних источниках. Это имеет проблемы с производительностью при запуске и обновлениями. Переменные среды являются отличным вариантом. Путаница в разработке Многие разработчики путают понятие AWS-лямбды в структуре своих проектов и основах кода. Lambda - это действительно «время выполнения» или «развертывание». Не время разработки Подобно тому, как вы не будете беспокоиться о том, будет ли ваш код работать на tomcat, в веб-сфере, цент-системе или Linux, вам не нужно сильно беспокоиться о aws-лямбде. Это влияет только на ваш начальный уровень, который должен соответствовать сигнатуре лямбда-обработчика. Это делает ваш проект простой библиотекой Java. Ничего общего с лямбдой, aws и т. Д. Отсутствие поддержки многопоточности при выполнении экземпляра лямбды. Неявно, лямбда-экземпляр является единственным потоком выполнения запроса. Другой запрос обслуживается другим экземпляром лямбды. Это означает, что вы не можете надежно поставить в очередь другой блок многопоточного кода как часть вашего лямбда-выполнения. Например. Вы не можете сохранить запись в базе данных, а затем выполнить асинхронную запись в систему ведения журнала. Нет никакой гарантии, что заданный в очереди рабочий элемент получит поток, прежде чем лямбда будет снесена. Обходной путь должен вызвать другую лямбду асинхронно, который не является действительно легким вызовом. Отсутствие гибкости для расширенной настройки конфигурации Бессерверная служба баз данных или настройки фронта облака и т. Д. Предоставляют клиентам очень ограниченные настройки. Снаружи, если это, нет ничего, что вы можете контролировать. Например. До прошлой недели вы не могли сказать фронту облака: «Эй, мне нужно, чтобы вы поддержали tls v1. Только для версии 2 и выше. Аналогичным образом, существуют конфигурации sql-сервера, которые могут отсутствовать для настройки в сценариях rds. Обратите внимание, что это сложные сценарии. Блокировка поставщика Если сервер не используется, вы можете рассчитывать на то, что провайдер облачных вычислений будет поддерживать новые среды выполнения, платформы, серверы баз данных и т. Д. Если бы это были виртуальные машины или EC2, вы могли бы загрузить его с любой необходимой инфраструктурой и платформами. Сопротивление людей Это уникальная проблема со сменой парадигмы, которую приносит безсерверная архитектура. Внезапно это выводит множество групп (разработчиков, мониторинг, закупки серверов, уровни поддержки, группы вызова и т. Д.) Из своих зон комфорта. Внезапно появился новый способ развертывания, обслуживания, устранения неполадок, поддержки и выполнения SCM. Это тоже благо, поскольку именно так достигается прогресс.

Даже с учетом вышеизложенного, безсерверные или лямбда-окружения удивительны в устранении большого количества тяжелой работы.

Подготовка AMI, управление ELB, автоматическое масштабирование, регулирование, механизм повторных попыток, ведение журнала из коробки и т. Д. Это эволюция.

ответил(а) 2020-02-24T14:53:57+03:00 1 год, 9 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема