Минусы и недостатки CMS «Битрикс» для крупных сайтов | Технологии Успеха
Меню
1-й российский научный центр «Технологии успеха»
Научный подход к проектированию и продвижению онлайн-площадок
Задать вопрос 8 800 775-17-11

Ошибки Битрикса на сложных проектах: чем он хуже других?

Автор: Максим Монахов — декан 1-го российского научного центра разработок онлайн-площадок «Технологии успеха»


Некоторое время назад мы уже писали статью о плюсах Битрикса: «Чем 1C-Битрикс лучше других систем управления сайтом». Теперь настало время разобраться в недостатках и слабых местах системы при работе со сложными проектами. Выявляем честные минусы вместе!

Недостаточно гибкая архитектура

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

За пример возьмем простой элемент «Документ», который обладает характеристиками:

  • тип;
  • дата формирования;
  • автор;
  • наличие подписи;
  • кем подписан.

Он хранится в разделе «Заявления», подраздел «Запросы на справку».

Поле «Кем подписан» связано с инфоблоком — справочником сотрудников. Предположим, что данные поступают из внешней базы данных. Стандартный механизм импорта данных не предусматривает возможности обновления — только стирание и запись заново.

При этом, пока мы не добавим элементы в один инфоблок, не сможем получить уникальные идентификаторы, чтобы установить связь. Это приводит к тому, что при обмене необходимо передавать избыточное количество данных об этих связях.

Для двух-трех инфоблоков — не страшно, но когда их десятки, то происходит следующее:

  1. Значительно увеличивается риск ошибки формирования связей. Их приходится задавать программисту вручную — чем больше связей, тем чаще путаница.
  2. Возрастает объем передаваемых данных, что приводит к существенному снижению скорости обмена, иногда на порядок.
  3. Связи, которые мы настраивали вручную, будут стерты при выгрузке.


Пример: bakalavriat.fa.ru

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

Чтобы обеспечить корректность отображения информации, приходится выстраивать сложную вложенную иерархию разделов, дублировать ее в характеристики программы. При этом используются связанные с ней дополнительные справочники преподавателей, предметов, цен. В результате обработка данных занимает порядка 30–40 минут для 300 элементов. При использовании фреймворка это занимает меньше минуты, так как есть возможность сделать структуру базы данных сайта в точном соответствии с БД источника.

Кроме того, нельзя что-то просто взять и исправить на сайте. Например, для того, чтобы убрать преподавателя в программе, надо вносить изменения в исходной системе. А если работой с сайтом и работой с БД приемной комиссии занимаются разные подразделения, то это приводит к еще более низкой оперативности.


Проблема обработки данных с нескольких источников

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

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

В Битриксе такой механизм не предусмотрен, что ведет за собой следующее:

  1. Если мы собираем данные сразу со всех источников, то сбой одного из них приводит к возникновению серверной ошибки — все данные не получены.
  2. Если мы собираем данные по очереди, то нам приходится их хранить сразу в Битриксе. Допустим, с какого-то источника мы не взяли информацию, и получается так, что часть данных — новая, часть — старая. Как итог — дезинформация посетителей и проблемы с «поломанными» разделами на сайте.

Пример: quest-battle.ru

Данные о стоимости, расписании и ценах собираются более чем с 30 источников. Сбой одного из них приводит к тому, что на сайте отображается неактуальная информация для бронирования.

Для решения проблемы был написан отдельный механизм сбора данных на фреймворке, который формирует пакет обновления данных в Битрикс.

Только вылилось это в дополнительные финансовые и временные затраты для владельцев сайта.


Проблемы интеграции с 1С

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

  • или большинство конфигураций 1С не умеет работать с модулем обмена изначально;
  • или была произведена масштабная доработка исходной конфигурации, и модуль обмена перестал работать.

В таком случае на стороне 1С нужно дорабатывать модуль обмена, либо поднимать SOAP/API шлюз. При одинаковых трудозатратах шлюз выглядит предпочтительнее, т. к. позволяет более гибко настроить обмен, создает меньшую нагрузку и может работать в режиме онлайн.

Битрикс также потребует доработок для работы с новым модулем обмена или шлюзом. Если выбран последний (а это логично в 99,9%), то наступают те же проблемы, что описаны в предыдущем разделе: обращения к шлюзу требуют построения очереди, а ее лучше обрабатывать брокером.

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

Кратко о других минусах

Разрастание объема хранимых данных

Если сайту на 1С-Битрикс требуется активная работа с загружаемыми файлами, то это приводит к быстрому росту места, занимаемого на дисках сервера. Дополнительное кеширование, нерациональное хранение данных приводит к тому, что сайты по 200–300 Гб — уже далеко не редкость! При этом поиск информации о файле в БД занимает длительное время, от чего возникают проблемы производительности сайта.

В случае фреймворков для файлов может быть использована документно-ориентированная система управления БД, например, MongoDB. Она позволяет создавать быстрые файловые хранилища.

Проблемы масштабирования

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

Тяжелая интеграция с современными средствами разработки публичной части сайта (верстки)

Современные решения: VueJS, Angular, React и т. п. позволяют ускорить и разработку сайта, и саму работу. Интеграция с 1С-Битрикс возможна, но она, наоборот, увеличивает время разработки.

На этом я, пожалуй, закончу! Вдруг вы подумаете, что я вас отговариваю от Битрикс! А на самом деле, если вы надумаете делать сайт — просто обратитесь к нам. Мы работаем в этой сфере ежедневно уже более 11 лет и с полной уверенностью подберем систему управления сайта под любые ваши задумки.

Оцените статью:

Обсудим Ваш проект?

наверх