В предыдущей статье мы исследовали работу Serverless под капотом. По сути, Serverless использует многоуровневое планирование и быстрый холодный старт, что позволяет масштабироваться до нуля, когда не обрабатываются никакие события. Это похоже на светильник с голосовым управлением, который загорается, когда кто-то присутствует, и автоматически выключается, когда комната пуста.
Уяснив основы, вы, возможно, заинтересуетесь практическим применением этой впечатляющей технологии. Сегодня мы углубимся в варианты использования Serverless. Однако предварительным условием для понимания его применения является понимание его процессной модели — концепции, столь же важной, как холодный старт.
Процессная модель Serverless
Давайте вернёмся к процессу холодного старта Serverless из прошлого занятия. Напомним, что облачный провайдер управляет этапами подготовки контейнера и среды выполнения, оставляя нам возможность сосредоточиться только на выполнении функций. В мире Serverless выполнение функций обрабатывается «сервисом функций». Когда триггер функции сигнализирует о прибытии «события», сервис функций создаёт экземпляры функций по мере необходимости и выполняет соответствующие функции. После завершения выполнения функции связанный с ней экземпляр завершает работу, позволяя Serverless-приложению масштабироваться до нуля и перейти в энергосберегающий режим.
Теперь вы можете задаться вопросом: можно ли оставить экземпляр активным после выполнения функции вместо его завершения, чтобы он ожидал следующего вызова функции? Это устранило бы накладные расходы на холодный старт каждый раз, что привело бы к более быстрому времени отклика.
Действительно, Serverless предусматривает такие сценарии. Следовательно, с точки зрения процесса, выполняющего экземпляр функции, существуют две модели:
- Run-to-Completion (Выполнить до завершения): В этой модели экземпляр функции, после готовности, выполняет функцию и немедленно завершается. Это представляет собой наиболее чистую форму использования Serverless.
- Persistent Process (Постоянный процесс): Здесь экземпляр функции после своей подготовки не прекращает работу после завершения функции. Вместо этого он возвращается и терпеливо ожидает следующего вызова функции. Обратите внимание, что даже в этой модели облачный провайдер в конечном итоге уничтожает экземпляр функции, если в течение заданного периода времени никакое событие его не активирует.
Оркестрация данных
Большинство инженеров знакомы с шаблоном MVC (Model-View-Controller) — весьма успешной парадигмой проектирования. Однако рост фронтенд-фреймворков MVVM выдвинул уровень View вперёд, что привело к появлению SPA (Single Page Applications). И наоборот, уровни Control и Model на бэкенде опустились, что привело к появлению сервис-ориентированных бэкенд-приложений.
Этот сдвиг привёл к более тщательному разделению фронтенда и бэкенда. Разработка фронтенда может вестись самостоятельно, опираясь на имитированные интерфейсы данных, в то время как команды бэкенда могут сосредоточиться на разработке интерфейсов данных. Однако это разделение вводит уровень шлюза данных с высокой сетевой вводом-выводом.
Node.js с его асинхронной, неблокирующей природой и близостью JavaScript к фронтенд-инженерам естественным образом взял на себя роль уровня шлюза данных. Это привело к появлению слоя BFF (Backend For Frontend) на Node.js, который оркестрирует бэкенд-данные и интерфейсы, адаптируя их в структуры данных, подходящие для потребления фронтендом.
Уровень BFF действует как посредник, соединяя фронтенд и бэкенд. Необработанные данные, часто называемые сырыми данными или метаданными, практически нечитаемы для конечных пользователей. Поэтому нам нужно комбинировать и обрабатывать соответствующие данные, добавляя ценность и делая их осмысленными. Этот процесс комбинирования и обработки называется оркестрацией данных.
Традиционно управление приложениями Node.js для уровня BFF было ресурсоёмким, требуя виртуальных машин или платформ PaaS. Однако, поскольку уровень BFF в основном выполняет оркестрацию данных без сохранения состояния, мы можем без проблем заменить приложение Node.js на Serverless с использованием модели Run-to-Completion. В этом суть всё более популярного термина SFF (Serverless For Frontend).
Теперь, когда мы поняли эволюцию от BFF к SFF, давайте проследим новый поток запросов. Когда фронтенд инициирует запрос данных, триггер функции активирует наш сервис функций. Наша функция запускается, вызывает интерфейс метаданных бэкенда, обрабатывает возвращённые метаданные в формат, требуемый фронтендом, и, наконец, наша Serverless-функция может заслуженно отдохнуть.
Оркестрация сервисов
Оркестрация сервисов имеет сходство с оркестрацией данных, ключевое отличие состоит в том, что она фокусируется на комбинировании и обработке различных сервисов, предлагаемых облачным провайдером. Хотя эта концепция существовала и до Serverless, её традиционная реализация была ограничена версиями языков SDK, поддерживаемых сервисами. Обычно мы прибегали к YAML-файлам или интерфейсам командной строки для оркестрации сервисов. Для использования этих сервисов или API приходилось находить соответствующие SDK на предпочитаемом языке программирования, загружать их в код и использовать секретные ключи для вызова методов SDK для оркестрации. Как и в случае с оркестрацией данных, затраты на бэкенд-операции и развёртывание были существенными, а отсутствие SDK требовало ручной реализации на основе интерфейсов или протоколов платформы.
Serverless расширяет границы использования SDK. Например, представьте веб-сервис, которому нужно отправлять проверочные коды по электронной почте. Мы можем добиться этого с помощью Serverless-функции типа Run-to-Completion, которая использует SDK облачного провайдера для отправки писем. Одновременно постоянная Serverless-функция может генерировать случайные строки проверочных кодов, сохранять их и запускать Serverless-функцию отправки электронной почты для доставки кодов в почтовые ящики пользователей. Во время проверки мы можем снова вызвать постоянную Serverless-функцию для проверки кодов.
Примечательное преимущество Serverless — его языковая независимость. Это освобождает команды разработчиков от привязки к одному языку, позволяя им использовать сильные стороны Java, PHP, Python, Node.js и других для совместного создания сложных приложений.
Открытость оркестрации сервисов на Serverless привлекла значительное внимание облачных провайдеров. Она позволяет создавать разнообразные и сложные сценарии оркестрации сервисов, оставаясь при этом независимой от языка, что значительно расширяет варианты использования различных облачных сервисов. Однако это также требует от разработчиков ознакомления с набором сервисов, предлагаемых выбранным облачным провайдером.
Заключение
- Существует два типа процессных моделей для Serverless: резидентный тип и тип «использовал и уничтожил». Резидентный тип предназначен для адаптации к традиционной архитектуре MVC и выглядит неестественно; если вы начинаете использовать Serverless только сейчас, я бы определённо рекомендовал модель «использовал и уничтожил», которая позволяет максимально реализовать преимущества Serverless.
- Прослеживая историю, я выделил BFF, разработанный через разделение фронтенда и бэкенда, который затем может быть заменён на SFF. Будь то оркестрация внутренних интерфейсов или оркестрация внешних данных, Serverless может сыграть огромную роль.
- Отходя от оркестрации данных, мы можем использовать возможности Serverless и облачных сервис-провайдеров для реализации оркестрации сервисов, создавать более мощные сценарии композитных сервисов и повышать эффективность нашей разработки.
Novita AI — это универсальная облачная платформа, которая расширяет ваши AI-амбиции. Интегрированные API, Serverless, GPU Instance — экономически эффективные инструменты, необходимые вам. Устраните инфраструктуру, начните бесплатно и воплотите своё AI-видение в реальность.
Рекомендуемое чтение
