Консультирование по архитектуре решений 1С-Битрикс

Архитектура 1С-Битрикс: где ломается рост нагрузки

Архитектура 1С-Битрикс редко ломается сразу — она деградирует постепенно, и первый сигнал обычно выглядит как «стало медленнее после очередного наполнения каталога». Каталог в десятки тысяч позиций, обмен с учётной системой и растущая доля авторизованных посетителей складываются в узкое место: нагрузка на каталог растёт быстрее, чем мощности серверов.

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

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

Аудит архитектуры сайта начинается не с кода, а с карты точек отказа сайта: сколько узлов, где живёт база, кто и когда пишет в каталог, что происходит при недоступности учётной системы. Дальше — замеры: план выполнения тяжёлых запросов, доля страниц из кэша, время прогрева. Так видно, что решается настройкой, а что требует выноса обмена в очередь и разделения чтения и записи. Разбираем, как это закрывается.

Что даёт выверенная архитектура на 1С-Битрикс

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

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

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

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

Режимы работы: один узел, кластер, разделение ролей

Режим работы определяет, что именно придётся менять, когда нагрузка вырастет вдвое: усилить один сервер, разнести роли по машинам или добавить узлы за балансировщиком. Выбор зависит не от размера каталога, а от того, где система упирается сейчас — в диск, в базу или в обработку запросов. Ниже — реальные варианты, между которыми выбирают на старте и при переезде.

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

Этапы работ: от аудита схемы до передачи регламентов

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

1. Аудит инфраструктуры. Снимаем факты: версии ядра и модулей, конфигурация веб-сервера и базы данных, планировщик, очереди, внешние интеграции, фактические пики по логам посещаемости. На выходе — карта текущего состояния и список узких мест, а не общие выводы.
2. Схема архитектуры. Проектируем целевое разделение ролей: веб-слой, база, кэш, поиск, вынесенные фоновые задачи. Фиксируем точки отказа, поведение при перегрузке и порядок действий при откате.
3. Сборка тестового контура. Разворачиваем копию с обезличенными данными и теми же версиями компонентов, что в рабочем контуре. Иначе результаты проверок на нём ничего не доказывают.
4. Нагрузочная проверка. Профиль нагрузки строим по реальным логам, а не по средним значениям. Ступенчато поднимаем нагрузку и смотрим время ответа на ключевых сценариях, долю ошибок, потребление ресурсов и место, где система ломается первой.
5. Перенос без простоя. Переводим трафик на новую схему при минимальном окне работ: синхронизация данных, переключение, контрольные замеры. Откат выполняется по заранее описанной процедуре, а не по решению на месте.
6. Наблюдаемость. Настраиваем метрики и пороги оповещений по узлам, очередям и времени ответа — чтобы деградация выявлялась до жалоб пользователей.
7. Передача регламентов. Отдаём схему, правила обновления, инструкции по типовым инцидентам и разбор изменений команде заказчика.

Что остаётся в проекте после сдачи работ

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

• Схема инфраструктуры — окружения разработки, приёмки и продакшена, роли серверов, связи с 1С и внешними сервисами, точки входа трафика, кэш и очереди обработки; отдельно помечены узкие места и внешние зависимости.
• Документация по проекту — структура решения, кастомные компоненты и модули, изменённые файлы ядра, история архитектурных решений с обоснованием: почему сделано так и что отвергли.
• Конфигурации окружений — параметры кэширования и индексации, задания по расписанию и фоновые агенты, значения, меняющие поведение сайта, с пометкой, что можно править безопасно.
• Политики доступа — роли в административной панели по инфоблокам и разделам, права на сервер, порядок выдачи и отзыва доступов, ротация ключей и учётных записей.
• Регламент обслуживания — периодичность резервного копирования и проверка восстановления, порядок обновления платформы, окна работ, каналы оповещения и критерии эскалации.
• Инструкции сопровождения — типовые операции по шагам: публикация контента, выпуск и откат релиза, подключение новой интеграции, диагностика частых отказов кэша и обмена.
• Реестр интеграций и учётных данных — что с чем связано, где хранятся ключи, какая сторона отвечает за обмен и что делать при расхождении данных.

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

Кейс: как разнесли нагрузку и убрали падения каталога

Что было

Каталог на 1С-Битрикс работал на одном сервере: приложение, база и обмен с учётной системой делили одни ресурсы. Обмен запускался по расписанию и на время выгрузки цен и остатков забирал соединения к базе — карточки начинали отдаваться секундами, часть запросов срывалась по превышению времени ожидания. Пик приходился на утро, когда менеджеры открывали админку, а посетители — каталог.

Что изменили

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

Что стало

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

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

Чем отличается пересборка на живой системе от переноса?

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

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

Перенос дороже на подготовке: тестовый контур должен повторять боевой — та же ветка 1С-Битрикс, та же конфигурация веб-сервера, тот же поисковый движок и правила обмена с 1С. Зато переключение без простоя делают на уровне маршрутизации: держат оба контура, переносят накопленные изменения базы, переводят домен и закрывают запись в старый.

Правило выбора простое. Меняются структура инфоблоков, свойства, правила обмена с 1С или логика модулей — это перенос: цена ошибки выше стоимости второго контура. Косметика в шаблоне, настройки кеша, точечные правки компонентов допустимы на живом контуре — при снятой копии и плане отката.

Мы раскладываем задачу по этим двум сценариям ещё на этапе оценки и показываем, где точка невозврата, — до начала работ.

Частые технические сомнения перед началом работ

Сомнения на старте почти всегда инженерные, а не организационные: что будет с работающим сайтом, во что превратится код после обновления, реально ли вести проект своими силами. Ниже — вопросы, которые задают чаще всего, и ответы по существу.

Обновление ядра сломает наши доработки?

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

Не вырастет ли число ошибок после обновления?

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

Сможем ли дальше вести проект своими силами?

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

Обсудим задачу и вернёмся с оценкой и планом

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

• Текущий контур: редакция продукта, где размещён сайт, как выкладываются изменения и кто это делает.
• Интеграции: с чем идёт обмен (учётная система, склад, платежи, доставка, службы рассылок), по какому расписанию и что происходит при разрыве связи.
• Нагрузка: суточная посещаемость, пиковые всплески, объём каталога и число одновременных пользователей в часы максимума.
• Данные: объём каталога и заказов, откуда переносим, нужно ли сохранять историю и связи между сущностями.
• Ограничения: жёсткие даты, регламенты и требования к доступам, что нельзя менять в текущем контуре.
• Приоритеты: что критично в первой очереди, а что можно вынести на следующий этап.

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