Б Бёрнс - Распределенные системы. Паттерны проектирования

136Часть II. Паттерны проектирования обслуживающих систем Преимущества FaaS

Преимущества подхода FaaS в первую очередь касаются раз-работчиков. Он существенно сокращает расстояние между ис-ходным текстом и запущенным сервисом. Поскольку, за ис-ключением исходных текстов, нет необходимости создавать и разворачивать другие артефакты, FaaS упрощает переход от исходных текстов, открытых в текстовом редакторе на ноутбуке или в браузере, к запущенному в облаке приложению. Масштабирование и управление развернутым кодом проис-ходит автоматически. По мере возрастания трафика для его обработки создаются новые экземпляры функции. При отказе функции в результате отказа приложения или аппаратного обе-спечения она автоматически перезапускается на другой машине. Наконец, подобно контейнеру, функция — еще более мелкая составная часть распределенной системы. Функции не хранят состояние, и поэтому любая система, построенная на основе функций, по определению будет модульной и слабосвязанной, чем такая же система, собранная в один исполняемый файл. Но в этом свойстве также кроется сложность разработки рас-пределенных систем на основе подхода FaaS. Слабая связность системы — одновременно ее преимущество и недостаток. В сле-дующем разделе рассматриваются сложности и проблемы, со-путствующие разработке систем на основе подхода FaaS. Проблемы разработки FaaS-систем Как было сказано в предыдущем разделе, разработка систем с использованием подхода FaaS вынуждает делать компонен-ты системы слабосвязанными. Каждая функция независима по определению. Все взаимодействие осуществляется по сети. Экземпляры функций не имеют собственной памяти, следова-тельно, они требуют наличия общего хранилища для хранения Глава 8. Функции и событийно-ориентированная обработка 137состояния. Принудительное ослабление связности элементов системы может повысить гибкость и скорость разработки сер-висов, но в то же время может существенно осложнить ее под-держку.

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

ружить. Рассмотрим в качестве примера следующие функции: ‰ ‰ functionA() вызывает functionB() ;

‰ ‰ functionB() вызывает functionC() ;

‰ ‰ functionC() вызывает functionA() .

Теперь рассмотрим, что происходит, когда в одну из этих функ-ций поступает некоторый запрос. Начинается бесконечный цикл, который завершается только тогда, когда истекает время ожидания запроса (а может, и позже) или когда у вас заканчива-

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

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

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