Благодаря процессу разработки Serverless и проблемам, которые он ставит перед нами, мы можем изменить свое мышление, упростить сложность, найти преимущества и избежать недостатков, а также лучше использовать его преимущества для повышения эффективности предприятия и предоставления бесконечных возможностей для творчество.

Обзор сервера

В последние годы серверные вычисления не производятся с собственными облачными вычислениями в контексте Интернета, который, как следует из названия, относится к базовым ресурсам, когда разработчики создают и запускают приложения без необходимости управлять серверами и другими объектами, приложение отделено как функция. детального развертывания функций и работы базового блока. Пользователи платят только за фактически использованные ресурсы. Эти коды полностью запускаются событиями (событие-триггер), параллельная платформа автоматически настраивается в соответствии с ресурсами службы запроса, с практически неограниченными возможностями расширения, без ресурсов в режиме ожидания. Код без сохранения состояния работает, он может легко добиться быстрой итерации, скорости развертывания.

1.1 Бессерверный фон

• История развития облачных вычислений

В быстро развивающуюся эпоху Интернета, от первых физических серверов до виртуальных машин, использующих такие технологии виртуализации, как XEN и KVM, до автоматического управления этими виртуализированными ресурсами с помощью облачных вычислений и появления технологии контейнеров, приложения были изолированы от , Теперь у нас снова есть Serverless, так что пользователям не нужно заботиться о среде запуска программы, ресурсах и количестве, пока они сосредоточены на технологии бизнес-логики.

Развитие облачных вычислений от IaaS, PaaS, SaaS до новейших BaaS, FasS, в этом тренде Serverless (де-сервер).

• Состав бессерверных

Для полного приложения, если мы хотим использовать бессерверные решения, нам необходимо рассмотреть внешний интерфейс, сетку API, которая является серверной службой, и базу данных хранилища объектов.С технической точки зрения, бессерверные решения — это комбинация FaaS. и Баас.

FaaS (функция как услуга) — это платформа для запуска функций, таких как функциональные вычисления Alibaba Cloud, Lambda AWS и т. д.

BaaS (Backend as a Service) — это некоторые серверные облачные сервисы, такие как облачные базы данных, хранилище объектов, очереди сообщений и т. д. Использование BaaS может значительно упростить разработку нашего приложения.

Бессерверные можно понимать как функции, работающие в FaaS и использующие BaaS.

1.2 Особенности бессерверного доступа

• Без сохранения состояния: но это также определяет характеристики без сохранения состояния без сервера, поскольку выполнение каждой функции может использовать другой контейнер, а совместное использование памяти или данных невозможно. Если вы хотите обмениваться данными, вы можете использовать только сторонние сервисы, такие как Redis, COS и т. д.
• Нет O&M: с Serverless нам не нужно заботиться о серверах и O&M. Это также является ядром идеи Serverless. Развитие эксплуатации и обслуживания включает в себя эксплуатацию и обслуживание вручную, автоматическую эксплуатацию и обслуживание, DevOps, AiOps и т. д., а бессерверные технологии привносят новый режим эксплуатации и обслуживания. В этом режиме пользователи могут рассматривать только код как NoOps.
• Программирование, управляемое событиями: Serverless рассчитывается только при запуске, что означает, что оно управляется событиями.
• Низкая стоимость: Эксплуатационные расходы, Serverless доверяет пользовательский сервер, базу данных и промежуточное ПО BaaS/FaaS, и пользователь больше не будет участвовать в обслуживании инфраструктуры и программного обеспечения, особенно в крупномасштабных кластерных операциях, стоимость значительно снижается. По сравнению с сервером или операционной системой платформы IaaS или PaaS, в бессерверной архитектуре пользователи работают с сервис-ориентированными компонентами, такими как службы хранения, службы авторизации и т. д., что может сократить цикл разработки и снизить сложность разработки.
• Выставление счетов по требованию: Serverless/FaaS отличается от IaaS/PaaS, которые предварительно распределяют вычислительные ресурсы.Метод выставления счетов обычно основан на количестве запросов и времени работы.С одной стороны, он может максимально использовать ресурсы, а с другой стороны, это действительно по требованию.Выставление счетов может снизить затраты ресурсов пользователей. Согласно статистике, типичные серверы в коммерческих и корпоративных центрах обработки данных обеспечивают производительность только от 5% до 15% от средней максимальной вычислительной мощности, что, по сути, является пустой тратой социальных ресурсов. В рамках бессерверной архитектуры поставщики будут предоставлять более подробные вычислительные возможности для максимального удовлетворения потребностей в реальном времени, а использование ресурсов будет значительно улучшено.Можно считать, что по сравнению с IaaS и PaaS Serverless/FaaS является своего рода «зеленым " вычисление.
• Эластичное масштабирование: очевидным преимуществом бессерверной архитектуры является то, что «горизонтальное масштабирование является полностью автоматическим, эластичным и управляется поставщиком услуг».

2 проблемы, связанные с бессерверной обработкой

2.1 Преобразование услуг

• Ограниченные сценарии использования: Serverless подходит не для всех сценариев.В текущей ситуации разработки Serverless подходит для управляемого событиями асинхронного рабочего процесса.Если само приложение не подходит для сценария, его очень сложно трансформировать, и трудно для достижения результата на более позднем этапе.
• Разработка и развертывание: В настоящее время бессерверная экосистема находится в стадии быстрого развития. В настоящее время крупные производители публичных облаков имеют свои собственные бессерверные продукты. Чтобы облегчить быструю разработку разработчиками, производители написали различные подключаемые модули IDE для своих продукты, которые могут быть автоматически дополнены Обнаружение кода и могут быть автоматически развернуты в облаке одним щелчком мыши, но покрытия некоторых традиционных приложений недостаточно, и есть еще много областей, которые нуждаются в постоянной оптимизации и улучшении.
• Запуск теста: для функционального тестирования основные общедоступные облака также предоставляют запуск тестов, но нет хорошей функциональной поддержки для передачи нескольких параметров интерфейса.

2.2 Инфраструктурные проблемы

• Создание и обслуживание базовой инфраструктуры: в настоящее время для бессерверных решений с открытым исходным кодом, таких как Knative/Openfass/Kubeless или OpenWhisk, их создание и развертывание поддерживаются на более позднем этапе, что создает огромные проблемы для предприятий. мигрировали вверх, появится инфраструктурный слой, проблема требует устранения в короткие сроки, что предъявляет очень высокие требования к эксплуатационному и обслуживающему персоналу.
• Обслуживание API: для миграции бизнеса на Serverless, для обслуживания большого количества серверных API в более поздний период отсутствует единая платформа управления и контроля, или средства обслуживания чрезвычайно сложны для управления этим. обслуживание API, это не только из единого склада, еще более необходимо распространить управление на платформу.
• Сопутствующее экологическое обслуживание: Serverless - это не только отдельная функция бэкэнда, но также включает продукты, связанные с Baas.Если предприятие само выбирает инструменты с открытым исходным кодом, ему необходимо поддерживать шлюз API, хранилище объектов, журналы, мониторинг и т. д., все это должно быть реализовано самими пользователями.Этот вход в Serverless подобен морю, не только не снижает затраты пользователей, но вместо этого создает большие технические проблемы.

Обзор трех AWS Lambda

В ответ на вышеперечисленные проблемы, с которыми сталкивается бессерверная система, нам необходимо четко понимать, подходит ли известный нам бизнес для бессерверных сценариев, разделить бизнес и можно ли перенести определенные интерфейсы и определенные модульные функции на бессерверные для оптимизации архитектуры.

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

3.1 Обзор AWS Lambda

• Что такое AWS Lambda

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

• Бессерверная экология

AWS Lambda — это FaaS, а для Serverless также требуются сервисы, связанные с Baas.Общедоступное облако предоставляет нам полный набор решений, таких как реагирование на инциденты, изменение данных в корзинах Amazon S3 или таблицах Amazon DynamoDB и запуск с использованием кода Amazon API Gateway. в ответ на HTTP-запросы или вызывать свой код с помощью вызовов API, сделанных через AWS SDK. Благодаря этим функциям вы можете использовать Lambda для простого создания триггеров обработки данных для таких сервисов AWS, как Amazon S3 и Amazon DynamoDB, для обработки потоковых данных, хранящихся в Kinesis, или для создания собственного серверного модуля, работающего с масштабом, производительностью и безопасностью AWS.

Для DevOPS можно использовать CodePipeline и AWS CodeBuild для автоматического развертывания этих приложений.

3.2 Сценарии применения

Serverless имеет определенные сценарии применения, анализирует архитектуру собственного бизнеса, то есть сценарий, и комбинирует характеристики Serverless для разборки или миграции адаптирующегося к сценарию бизнеса на Serverless.

• Когда владелец интернет-магазина с индивидуальным изображением поддерживает изображение продукта, необходимо динамически обрезать изображение до разных размеров или наносить на изображение разные водяные знаки в соответствии с положением отображения продукта. Когда магазин загружает изображение в хранилище объектов OSS, он инициирует расчет функции с помощью триггера, настроенного для расчета функции. В соответствии с правилами расчета генерируются изображения разных размеров для удовлетворения потребностей отображения товаров в Интернете Весь процесс не требует создания дополнительных серверов и не требует вмешательства художников веб-сайта.
• Низкочастотные запросы в IoT В отрасли IoT устройства IoT передают небольшой объем данных, а передача данных часто выполняется через фиксированные промежутки времени, поэтому часто задействованы сценарии низкочастотных запросов. Например: приложения IoT запускаются только один раз в минуту в течение 50 мс каждый раз, что означает, что загрузка ЦП составляет всего 0,1% в час, или 1000 идентичных приложений могут совместно использовать вычислительные ресурсы. В рамках бессерверной архитектуры пользователи могут приобретать ресурсы со скоростью 100 мс в минуту для удовлетворения вычислительных потребностей, что может эффективно решить проблемы эффективности и снизить затраты на использование.
• Настраиваемые события Пользователи могут отправлять электронные письма для проверки своих адресов электронной почты при регистрации, а также могут инициировать последующие процессы регистрации с помощью настраиваемых событий без необходимости настраивать дополнительные бессерверные приложения для обработки последующих запросов.
• События триггера с фиксированным временем запускают триггеры с фиксированным временем, такие как обработка данных транзакций в часы пик в ночное время или во время простоя службы, или запуск пакетных данных для создания отчетов о данных.Благодаря бессерверному методу нет необходимости приобретать дополнительные ресурсы обработки которые мало используются..

Четыре практики AWS Lambda

Вы создадите функцию Lambda с помощью консоли AWS Lambda. Далее вы вручную вызовете функцию Lambda с примерами данных события. AWS Lambda выполнит функцию Lambda и вернет результат. Затем вы проверите результаты выполнения, в том числе журналы, созданные вашей функцией Lambda, и различные метрики CloudWatch. Из-за ограниченного места здесь я буду практиковать самое базовое использование Lambda. Позже части высокого уровня можно найти на официальный веб-сайт склада, чтобы насладиться универсальным обслуживанием.

4.1 Создание функций

Откройте консоль AWS Lambda и выберите «Создать функцию». В поле Имя функции введите имя функции и выберите Создать функцию.

4.2 Расчетная функция

дизайнерОтображает обзор вашей функции и ее вышестоящих и нижестоящих ресурсов. Вы можете использовать его для настройки триггеров, слоев и целей.

• создать функцию

Здесь мы создаем функцию для среды выполнения интерпретатора Python 3.6.

После завершения создания мы видим, что код шаблона функции такой:

import json

def lambda_handler(event, context):
    # TODO implement
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

После этого мы можем увидеть функцию, которую мы написали.

4.3 Запуск теста

Нажмите Тест, чтобы создать тестовое событие, выберите здесь простой шаблон теста hello world, настройте имя, а затем протестируйте.

После создания тестового события запустите тест, чтобы увидеть структуру выполнения.

Примечание. Каждый пользователь может создать до 10 тестовых событий для каждой функции. Эти тестовые события недоступны для других пользователей.

4.4 Подробная конфигурация

Мы можем сначала взглянуть на результат после запуска теста.

Распечатав результаты, мы можем сделать следующие выводы о конфигурации:

• lambda_handler: это функция, которую лямбда запускает каждый раз. Вся наша бизнес-логика написана внутри этой функции. Изменение имени функции при тестировании приводит к тому, что функция не работает нормально. Имя функции фиксировано.
• событие: для данных, которые нам нужно обработать, то есть входные параметры.
• Контекст: некоторая информация о запуске для функции, например: AWS_REQUEST_ID для вызова функции после отключения запроса INVELEID, FUNCTION_NAME Название функции.
• В конце мы можем использовать функцию для возврата результата и так далее.

4.5 Мониторинг журнала

4.5.1 Просмотр журнала

После запуска функционального теста мы можем просмотреть соответствующую информацию о работе функции, отслеживая журнал.

• Результат выполнения: в этом разделе отображается состояние выполнения как успешное, а также отображается результат выполнения функции, возвращенный оператором return.
• Сводка: в разделе отображается ключевая информация, сообщаемая в разделе «Вывод журнала» (строка «ОТЧЕТ» в журнале выполнения).
• Вывод журнала: раздел отображения журнала AWS Lambda, созданный для каждого выполнения. Они записываются функцией в журнал CloudWatch Lambda. Для удобства консоль AWS Lambda показывает эти журналы.

4.5.2 Просмотр мониторинга

Для мониторинга выполняемых функций мы можем просматривать их через CloudWatch, а затем выполнять статистический анализ, определять узкие места функций и параллелизм и настраивать их.

4.6 Очистка ресурсов

После использования функции очистите связанные ресурсы.При очистке ресурсов остаются логи и роли IAM, которые также необходимо очищать вместе.

• удалить лямбда-функцию

• удалить группу журнала

• удалить исполнительную роль

Это завершает очистку всей функции, роли и группы журналов.

4.7 Примечания

• Параллелизм: когда код функции выполняется, если есть другой запрос, вам необходимо настроить функцию и вернуться, предварительно настроить другой экземпляр, чтобы улучшить параллелизм функции. Параллелизм ограничен ограничениями на уровне региона
• Триггер: это ресурс или конфигурация, которая вызывает функцию Lambda. Сюда входят сервисы AWS, которые можно настроить для вызова функций, разрабатываемых вами приложений и карт источников событий. Карта источников событий — это ресурс в Lambda, который считывает элементы из потока или очереди и вызывает функцию.
• Виртуальное частное облако (VPC) — если вашей функции требуется сетевой доступ к ресурсам, недоступным в Интернете, ее необходимо настроить для подключения к VPC, чтобы правильно получить доступ к ресурсам в Интернете.
• Для конфиденциальных данных их можно внедрить в функцию через переменные среды, чтобы обеспечить безопасность функции.

Пять мыслей о бессерверных технологиях

При использовании AWS Lambda вы несете единоличную ответственность за свой собственный код. AWS Lambda управляет компьютерными кластерами, которые обеспечивают баланс памяти, ЦП, сети и других ресурсов. Хотя функциональные вычисления подходят для многих сценариев, они не являются панацеей для всех сценариев приложений.Если бессерверные облачные функции хотят развиваться быстрее на более позднем этапе, им необходимо тонко настроить бизнес-логику и вызвать каждую функцию, а во-вторых, они должны быть настроены производителями облачных сервисов, для сервисов уже нужно улучшать экосистему самостоятельно, и как минимум бессерверные облачные функции поддерживают различные продукты в собственном облаке. Несмотря на то, что в настоящее время бессерверные решения все еще имеют много ограничений, они развиваются и совершенствуются, и большинство разработчиков и поставщиков услуг ищут безграничные возможности безсерверных решений.

🏆 Технический спецвыпуск 7 | Все может быть бессерверным