← Все продукты

Workers

Cloudflare Workers выполняет код клиентов в изолятах V8 в сети Cloudflare, используя привязки к хранилищу, базам данных, очередям и сервисам инференса. На этой странице описаны модель выполнения, модель привязок, ограничения платформы, влияющие на архитектуру решений, и опубликованные тарифы.

Управление документом

Дана
Технический писатель, Integrity Czech Republic s.r.o.

Обзор

Workers представляет собой serverless-платформу Cloudflare для выполнения кода. Код развёртывается в сети, а не в конкретном регионе, и каждый вызов обрабатывается в том дата-центре, который принял запрос. Здесь нет инстансов, размер которых нужно подбирать, и нет рантайма, который нужно патчить, но платформа задаёт явные ограничения по CPU, памяти, количеству подзапросов и размеру скрипта, которые определяют, что на ней можно построить. Эти ограничения описаны в разделе «Лимиты и ограничения», и их стоит прочитать до начала проектирования, а не после.

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

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

Архитектура

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

Запуск не всегда бесплатен. Время холодного старта зависит от размера скрипта, объема работы, выполняемой на уровне модуля, и от необходимости создания экземпляра модуля WebAssembly. Крупные бандлы и интенсивная инициализация вызывают измеримые задержки холодного старта.

Среда выполнения реализует веб-платформенные API: fetch, Request и Response, URL, Web Crypto, потоки, WebSocket и подмножество API Node.js, включаемое через nodejs_compat флаг совместимости. Поведение среды выполнения фиксируется датой совместимости и флагами совместимости, указанными в конфигурации Worker, именно так платформа вносит изменения в поведение, не нарушая уже развёрнутый код.

Привязки соединяют Worker с ресурсами платформы. Привязка объявляется в конфигурации и добавляется в объект окружения во время выполнения, поэтому пространство имён KV, бакет R2, база данных D1, очередь, пространство имён Durable Object, модель AI или другой Worker рассматривается как возможность, а не как строка подключения или встроенные учётные данные.

Развертывание через Wrangler CLI публикует новую версию. Gradual Deployments направляют заданный процент трафика на новую версию, что означает, что во время такого развертывания одновременно работают две версии. Поэтому в этом режиме развертывание не является атомарным, и код должен корректно работать при одновременной работе обеих версий с одними и теми же данными.

В конвейере обработки запросов Cloudflare этапы обеспечения безопасности выполняются до вызова Worker, поэтому запрос, заблокированный WAF или правилом защиты от DDoS, не доходит до кода Worker.

Возможности

Модель настройки

Worker определяется своим кодом и файлом конфигурации, wrangler.jsonc или wrangler.toml. Конфигурация задаёт следующее:

• Точка входа и настройки сборки. Точка входа модуля и любой этап сборки.
• Дата и флаги совместимости. Поведение среды выполнения, под которое был написан код. Изменение compatibility date является осознанным действием с заметными последствиями, и его следует рассматривать как изменение кода.
• Привязки. пространства имён KV, бакеты R2, базы данных D1, пространства имён Durable Object, очереди, service bindings к другим Workers, AI bindings и обычные переменные окружения.
• Секреты. Хранится вне файла конфигурации, задаётся через Wrangler или панель управления и становится доступным в объекте окружения во время выполнения.
• Триггеры. Routes и Custom Domains для вызова по HTTP, cron-выражения для вызова по расписанию и объявления потребителей очередей.
• Окружения. Именованные варианты конфигурации для тестового и боевого окружений, каждый со своими привязками и секретами.
• Лимиты. Там, где это поддерживается, явный лимит CPU для Worker.

Выбор хранилища представляет собой главное архитектурное решение и зависит от требуемой модели согласованности и характера доступа к данным. Используйте KV для частого чтения данных, допускающих согласованность в конечном счёте, D1 для реляционных запросов, R2 для объектов, Durable Objects, если требуется строгая согласованность или координация на уровне отдельной сущности, и Queues, если обработку нужно вынести за пределы запроса.

Храните конфигурацию в системе контроля версий вместе с кодом: привязки и настройки совместимости влияют на поведение во время выполнения не меньше, чем исходный код.

Лимиты и ограничения

Приведённые ниже значения взяты из документации Cloudflare по лимитам платформы, проверено 2026-08-31 (https://developers.cloudflare.com/workers/platform/limits/). Они могут изменяться без предупреждения, поэтому их следует перепроверять, прежде чем полагаться на них в решении.

Subrequest представляет собой любой запрос, который Worker выполняет через Fetch API или к сервису Cloudflare через привязку, поэтому вызовы fetch и вызовы через привязку расходуют один и тот же бюджет в рамках одного вызова Worker.

Ограничения сервиса хранения данных, данные получены 2026-08-28:

• Workers KV. Размер ключа 512 байт, размер значения 25 МиБ, а документированный лимит составляет примерно одну запись в секунду на один и тот же ключ. KV обеспечивает согласованность в конечном счёте: запись не гарантированно сразу видна при чтении из другого региона.
• R2. При превышении лимита размера объекта для одного запроса требуется многочастевая (multipart) загрузка, при этом действуют ограничения на размер части. Исходящий трафик в интернет не тарифицируется, операции тарифицируются по классу.
• D1. На максимальный размер базы данных и на отдельные запросы действуют ограничения. База данных D1 не заменяет горизонтально масштабируемый реляционный кластер, поэтому перед планированием объёма данных уточните текущее максимальное значение.
• Durable Objects. Объект однопоточный, поэтому пропускная способность на объект ограничена, а шаблоны обращения к «горячим» ключам необходимо исключать еще на этапе проектирования. Действуют лимиты хранения на объект, которые отличаются для бэкендов на основе «ключ-значение» и SQLite.

Дополнительные ограничения:

• Python Workers доступны в открытой бета-версии и требуют python_workers флаг совместимости. Планирование продакшен нагрузки на них означает готовность к бета статусу и возможным изменениям поведения.
• Время CPU измеряет время, потраченное на выполнение, а не астрономическое время. Ожидание подзапроса не расходует время CPU, но общая длительность запроса всё равно подчиняется тайм-аутам HTTP и поведению клиента.
• Холодный старт полностью не устраняется. Большие бандлы, объёмная инициализация на уровне модуля и создание экземпляров WebAssembly ощутимо увеличивают время запуска.
• При постепенном развёртывании одновременно работают две версии, поэтому на время развёртывания изменения схемы и формата данных должны сохранять обратную совместимость.
• Совместимость с Node.js является частичной и зависит от nodejs_compat флаг и дату совместимости. Библиотеки, которым требуются неподдерживаемые API Node.js, нативные модули или долгоживущие необработанные TCP-соединения, могут не работать.
• На уровне аккаунта действуют ограничения по параллелизму и частоте запросов. Если для рабочей нагрузки ожидаются экстремальные всплески параллелизма, это следует подтверждать по условиям контракта, а не принимать как данность.

Доступность по планам

Развёртывание

Предварительные требования.

• Определите подходящую нагрузку и классифицируйте её: edge-логика перед существующим origin-сервером, API, задача по расписанию или полноценное приложение.
• Сопоставьте рабочую нагрузку с примитивами платформы и зафиксируйте требования к согласованности для каждой части состояния, поскольку именно это определяет выбор хранилища.
• Перед написанием кода сверьте нагрузку с документированными лимитами: пиковое использование CPU на запрос, пиковое использование памяти, количество исходящих вызовов на запрос, размер бандла и любые зависимости, требующие неподдерживаемого Node.js API.
• Подтвердите выбранную среду выполнения. Если предлагается Python, зафиксируйте, что Python Workers находятся в открытой бета-версии, и получите решение о приемлемости этого статуса.
• Зафиксируйте, где сейчас хранятся секреты и как они будут передаваться в качестве секретов Worker.
• Зафиксируйте текущий путь трафика и маршрут отката к нему.

Поэтапная проверка. Реализуйте нагрузку в тестовом окружении с собственными привязками и собственными данными и проверьте её на репрезентативном трафике. Замерьте время CPU на вызов, использование памяти и число подзапросов относительно лимитов тарифного плана, а также поведение при холодном старте на боевом размере бандла, а не на урезанном. Убедитесь, что данные наблюдаемости доходят до нужного назначения, прежде чем направлять на сервис реальный трафик.

Настройка.

1. Явно объявляйте bindings и указывайте дату совместимости, не полагаясь на значение по умолчанию.
2. Перенесите все учетные данные в Worker secrets и убедитесь, что в репозитории или конфигурационном файле их не осталось.
3. Настройте отдельные стейджинг- и продакшен-окружения с разными ресурсами хранения, чтобы ошибка при развёртывании не могла привести к записи в продакшен-данные.
4. Настройте CI так, чтобы развёртывание выполнялось пайплайном с ограниченным по правам API-токеном, а не с рабочей станции разработчика.
5. Добавьте ограничение частоты запросов перед общедоступными маршрутами Worker, а также кеширование там, где это допускает ответ, чтобы ограничить объем запросов и, соответственно, расходы.
6. Оцените стоимость модели относительно ожидаемого трафика, используя страницы тарификации для каждого сервиса, включая классы операций хранения, и настройте оповещения о выставлении счетов.

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

Верификация.

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

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

Вопросы эксплуатации

Отслеживайте время CPU, частоту ошибок и количество подзапросов по каждому маршруту, а не только объём запросов. Сбои, связанные с лимитами, проявляются под нагрузкой и незаметны в тестовой среде с низким трафиком.

Периодически пересматривайте дату совместимости. Если оставить её неизменной надолго, Worker будет работать со всё более устаревшим поведением среды выполнения; если же изменить дату без тестирования, поведение изменится непредсказуемо. Относитесь к изменению даты как к отдельному изменению, которое требует собственной проверки.

Следите за количеством операций с хранилищем наряду с количеством запросов. Если архитектура выполняет несколько операций с KV или D1 на каждый запрос, стоимость определяется в основном этими операциями, и изменение кеширования может существенно изменить сумму счёта в любую сторону.

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

Проектируйте ключи Durable Object так, чтобы нагрузка распределялась между объектами. Если один объект обрабатывает непропорционально большую долю трафика, он становится потолком пропускной способности, который не устраняется никаким масштабированием платформы.

Отказы, которые стоит учитывать заранее: обновление зависимости, из-за которого размер бандла превышает лимит; фрагмент кода, который иногда превышает лимит CPU при больших входных данных; конкуренция за запись в KV по одному ключу; вышестоящий сервис, который работает настолько медленно, что удерживает подзапросы открытыми; и постепенное развёртывание, оставшееся частично выполненным.

Известные особенности

• Python Workers находятся в открытой бета-версии и требуют флага совместимости. Если упомянуть их рядом с общедоступными средами выполнения без этой оговорки, архитектор может заложить в план продакшена бета-версию среды выполнения.
• Платформа не свободна от ограничений производительности. Время CPU, память, размер бандла, количество подзапросов и квоты на уровне сервиса ограничивают возможности одного вызова.
• Холодный старт существует. Для компактных JavaScript-бандлов он незначителен, а для крупных бандлов и создания экземпляров WebAssembly увеличивается.
• Постепенное развёртывание намеренно не атомарно. Две версии обслуживают запросы одновременно, и это требование к совместимости данных, а не просто деталь реализации.
• KV обеспечивает согласованность в конечном счёте и имеет ограничение на частоту записи для каждого ключа. Использование KV в качестве основного хранилища для быстро изменяющегося состояния приводит к проблемам с корректностью данных, которые проявляются только при параллельном доступе.
• Durable Object является однопоточным. Пропускная способность на объект ограничена архитектурно, а не тарифным планом аккаунта.
• Совместимость с Node.js является частичной. Дерево зависимостей, которое успешно собирается локально, всё же может дать сбой во время выполнения из-за неподдерживаемого API.
• Переносимость частичная. Стандартные веб-API, совместимый с S3 API R2 и диалект SQLite в D1 сохраняют переносимость большей части логики приложения, тогда как перенос Durable Objects и других платформозависимых сервисов потребует изменения архитектуры. На этапе проектирования определите, к какой категории относится каждый компонент.

Совместимость

Workers выполняются после фаз безопасности конвейера обработки запросов Cloudflare, поэтому решения WAF, DDoS и Bot Management применяются раньше, чем запускается код Worker. Заблокированный запрос никогда не доходит до Worker.

Workers взаимодействуют с CDN через Cache API и через Cache Rules. Если и Cache Rule, и логика кеширования Worker применяются к одному и тому же запросу, приоритет определяется задокументированной последовательностью обработки трафика.

R2 может выступать источником для CDN и лежит в основе Cache Reserve, поэтому объектное хранилище, кеширование и вычисления работают вместе без обычного сервера-источника.

Service bindings позволяют одному Worker вызывать другой без обращения по сети, что даёт возможность разбивать приложение на отдельно развёртываемые модули и сохранять низкую задержку вызовов.

Валидацию Turnstile можно выполнять в Worker, что позволяет проводить проверку на edge, а не в бэкенде приложения.

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

Часто задаваемые вопросы

Требуется ли полная миграция приложения для перехода на Workers? Нет. Распространённый способ внедрения заключается в том, чтобы разместить Worker на маршруте перед существующим источником для обработки редиректов, логики кеширования, аутентификации или персонализации, при этом само приложение остаётся на месте. Перенос самого приложения является отдельным решением.

Что на самом деле измеряет ограничение CPU? Время, затраченное на выполнение кода, а не общая длительность запроса. Ожидание subrequest не расходует CPU-время, поэтому запрос может длиться дольше, чем лимит CPU, не превышая его.

Какой сервис хранения должен содержать состояние сессии или координации? Durable Objects, если требуется строгая согласованность или координация на уровне отдельных сущностей. KV обеспечивает согласованность в конечном счёте и ограничивает частоту запросов на ключ, поэтому не подходит для быстро изменяющегося состояния в рамках одного ключа.

Какие части приложения на Workers можно перенести на другую платформу? Код, написанный с использованием стандартных веб-API, данные в R2 через S3-совместимый API, а также схемы и запросы D1 на диалекте SQLite в основном переносимы. Durable Objects и другие платформенно-зависимые сервисы потребуют переработки архитектуры.

Источники

• https://developers.cloudflare.com/workers/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/platform/limits/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/platform/pricing/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/languages/python/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/configuration/compatibility-dates/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/workers/configuration/versions-and-deployments/gradual-deployments/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/kv/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/r2/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/d1/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/durable-objects/, дата обращения 2026-08-28.

Снимок контента: 2026-08-28.

История изменений