(Также опубликовано в моем блоге)
Бессерверная граница с работниками Cloudflare
Недавно я сделал проект, в котором использовал воркеров Cloudflare. В этой статье я расскажу, как они работают, и расскажу о некоторых вариантах использования.
Эта статья была написана на основе моего собственного опыта, мне не платили и Cloudflare не платили за написание этой статьи.
Что такое Cloudflare?
Cloudflare - это компания, которая продает различные сервисы, такие как DNS, CDN, защита от DDoS и многие другие сервисы, одна из их последних услуг называется «Cloudflare worker».
Чтобы воспользоваться преимуществами сотрудников Cloudflare, вам необходимо использовать их службу DNS, поскольку она дополняет их службу DNS. Используя также их CDN, вы сможете получить максимальную отдачу от работников Cloudflare.
Что такое воркер Cloudflare?
Рабочий Cloudflare - это бессерверная функция, написанная на JavaScript и работающая на периферии. Это короткое и сексуальное объяснение.
- Бессерверный означает, что вы пишете код, который не требует от вас подстраховки сервера и хоста, на котором будет выполняться код. Вы просто пишете свой код и развертываете его, тот, на котором размещается (в данном случае Cloudflare) Бессерверный код заботится о хостинге, начальной загрузке сервера, инфраструктуре и масштабировании. Известный аналогичный сервис - Lambda от AWS.
- Когда мы говорим о границе, мы имеем в виду ближайший географически расположенный центр обработки данных к посетителю вашего сайта, который пытается получить доступ к вашему сайту через Cloudflare DNS. Cloudflare имеет собственные центры обработки данных по всему миру, чтобы предоставлять свои услуги, такие как DNS и CDN, поэтому он может обслуживать посетителей с минимальной задержкой за счет стратегического распространения этих центров обработки данных по всему миру.
При использовании DNS Cloudflare важно знать, что запросы проходят через их центры обработки данных (если вы выберете это, но обязательно для использования Cloudflare Workers).
При использовании Cloudflare worker запрос будет идти по следующему пути:
Каждый запрос будет перехвачен ближайшим местоположением Cloudflare Edge, и это вызовет выполнение вашей бессерверной функции. В этой функции у вас есть полный контроль, если вы перенаправляете запрос на исходный сервер или выполняете свою собственную логику. Вы даже можете получить ресурсы с разных серверов, а затем объединить эти результаты в один ответ для клиента, другие примеры - позже.
Обратите внимание, что эта функция выполняется в ближайшем дата-центре рядом с клиентом. Когда вы развертываете воркер Cloudflare, код будет развернут во всех периферийных местоположениях Cloudflare.
Как выглядит код?
В простейшем виде рабочий код Cloudflare выглядит так:
Обычно в JavaScript мы начинаем с создания прослушивателя событий fetch в строке 1. Событие fetch эквивалентно событию входящего запроса к периферийному местоположению Cloudflare.
Для удобочитаемости кода мы создаем отдельную функцию handleRequest(), куда мы поместим нашу настраиваемую логику. Обратите внимание, что у нас есть аналогичный API и опыт кодирования, что и у Web Worker в браузере, где мы в основном также хотим перехватывать запросы, чтобы мы могли выполнять кеширование на стороне браузера.
Время выполнения
Рабочий код Cloudflare работает в среде выполнения barebone V8, на момент написания они использовали v8 v7.4 и регулярно обновляли его. Это означает, что вы можете использовать новейшие функции, такие как async/await, и последние улучшения V8, такие как сборщик мусора Orinoco.
Вместе со средой выполнения идут API кеширования и API извлечения, которые мы находим в современных браузерах. Таким образом, легко выполнять любые HTTP-запросы. Обратите внимание, что объект request, переданный в HandleRequest(), является экземпляром типа Request из Fetch API. Практически все API извлечения и кеширования такие же, как и в документации MDN, но есть несколько отличий.
А как насчет модулей Node?
Мы работаем в среде barebone V8, как и в браузере, поэтому модули узлов изначально не поддерживаются. Хотя вы можете использовать любой модуль узла и использовать Webpack для объединения всех ваших зависимостей и различных исходных файлов в один файл, который можно развернуть в Cloudflare. При запуске webpack необходимо указать в качестве цели webworker.
Обратной стороной использования веб-пакета является то, что вы получаете один урезанный объединенный файл, который помещает весь код в одну строку текста. Это означает, что ваши трассировки стека будут запутанными и нечитаемыми.
Обработка ошибок
Когда выполняется воркер Cloudflare, у вас нет доступа к stdout воркера. У вас есть это только в «тестовом» интерфейсе, который предоставляет Cloudflare, но при работе в производственной среде вам необходимо добавить код для регистрации ошибок на удаленном сервере или в службе. Как было сказано ранее, убедитесь, что у вас есть правильные описания ошибок, когда вы используете webpack для объединения всего вашего кода в один файл. Потому что в этом случае трассировку стека нельзя будет прочитать.
Кеширование
Это работает только в том случае, если вы также используете службу CDN Cloudflare, тогда вы можете использовать Cache API, который сопоставляется с локальным кешем локального пограничного местоположения, где выполняется рабочий. Это невероятно полезная функция, когда вы хотите реализовать собственную логику кэширования ресурсов.
Соответствие маршрута
Для вашего удобства, когда вы включаете Cloudflare worker, вы можете настроить несколько URL-адресов сопоставления маршрутов, поэтому вам не нужно реализовывать эту логику в коде вашего Cloudflare worker.
Случаи применения
У нас есть эта распределенно развернутая бессерверная функция, которая работает на периферийных локациях Cloudflare. Так зачем и когда нам нужно это использовать? Cloudflare действительно предоставляет список рецептов, возможности безграничны.
Проект, над которым я работал, заключался в оптимизации стратегии кэширования для конкретной веб-службы. Комбинация использования Cloudflare Workers, их службы DNS и CDN позволила мне оптимизировать стратегию кэширования, реализовав настраиваемую логику, сэкономив много денег на счете поставщика облачных услуг за счет уменьшения на 90% пропускной способности вывода данных из данного облака. услуга.
В другом проекте я использовал веб-воркера для распределения посетителей по группам отклонений A / B и использовал два разных источника для сбора файлов cookie и объединения их в ответ.
Прелесть в том, что вы можете запрограммировать свою собственную логику прокси-сервера, выполняемую на периферии, то есть рядом с клиентом с малым временем отклика. Вы можете написать любую логику без проблем с холодным запуском. Время выполнения и скорость запуска чрезвычайно низки, поэтому влияние на выполнение работника Cloudflare между вашими запросами невелико.
Вызовы
Следует иметь в виду несколько проблем.
- Ведение журнала необходимо вести на внешний сервер, поэтому вам нужно сделать HTTP-запрос для записи в журнал. Если этот запрос не удастся, у вас будет тихий сбой без какой-либо информации для продолжения.
- Вы можете развернуть только одного воркера Cloudflare на домен верхнего уровня. Поэтому, если ваша промежуточная среда размещена как субдомен (например, staging.yourbrand.com), вы не можете развернуть воркер для промежуточных целей. Вам понадобится еще один домен верхнего уровня, использующий Cloudflare DNS, где вы можете развернуть промежуточную версию своего рабочего Cloudflare.
Ресурсы
Если вам понравился этот пост, отметьте свою признательность или оставьте конструктивный отзыв в комментариях. Возможно, вам будут интересны некоторые из моих других статей:
