15  /  96

Программная архитектура веб-систем на Битриксе

Просмотров: 2012 (Статистика ведётся с 06.02.2017)

Цитатник веб-разработчиков.

Александр Сербул: БУС это не "компоненты перетаскивать и галочки в админке тыкать", а это - хардкорная разработка модулей, доработка ядра, жесткий ORM, последние новинки PHP.

Для программиста не важно какой использовать framework. Framework - это просто основа, из которой бывает нередко целесообразнее собрать проект, чем писать с нуля. И Bitrix Framework здесь не исключение. Его надо понять, увидеть в целом, оценить его сложность и возможности. Но для ведущего разработчика, который выбирает модель реализации, знание системы важно, иначе трудно ожидать разумного и оправданного выбора архитектуры решения. Рассмотрим несколько вариантов архитектур, позволяющих решать определённые задачи.

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

Работая с Битрикс нужно в первую очередь понимать, что можно выжать из стандартных компонентов и шаблонов, а что придётся дописывать.

Простой сайт

Модель простого сайта и что должен предусмотреть проектировщик при реализации такого проекта.

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

Сайт с объёмным контентом

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

Для хранения большого объёма данных рекомендуется использовать Облачное хранилище и CDN. Весь большой контент рекомендуется хранить там.

Для организации поэтапной работы над контентом рекомендуется использовать Документооборот и Бизнес процессы

Много данных в инфоблоках

Под "много данных" понимается сотни тысяч и миллионы элементов.

Такой проект "тяжёл" для административной части. Рекомендуется не использовать опцию Совместный просмотр разделов и элементов в настройках модуля Информационные блоки (и настройках самого инфоблока) и обязательно разносить инфоблоки по типам.

Обязательно для таких проектов необходимо:

  • Спроектировать модель данных в инфоблоках. Необходимо понять где нужна денормализация, где - агрегация, где кеширование.
  • Описать и реализовать основные запросы к данным из публички (иногда админки). Нужно понять цепочки использования. Например, клиент планирует получать регулярно список новостей (или список элементов в каталоге), и редко (раз в месяц) строить выборки, например, по продажам. Следовательно нужно обеспечить быструю обработку частых запросов, в нашем случае: просмотр списков новостей (каталога), просмотр разделов каталога.
  • Реализовать соединение выборок из инфоблоков (joins). Нужно спроектировать модель соединения данных из инфоблоков. В крайних случаях использовать прямые запросы в БД. НО перед этим надо попытаться использовать все доступные средства API.
  • Пользовательские свойства. Скорее всего они будут не совпадающими у инфоблоков, так как контента много и он, скорее всего, разнотипный.
  • Кастомные страницы административной части к инфоблокам. При больших объёмах есть смысл в таком проектировании.
  • Управляемое и эффективное кеширование данных.
  • Экспорт/импорт - JSON, XML, REST, очереди, инкременты.

Много ролей

В этом случае на сайте работает много сотрудников и как следствие этого возникают повышенные запросы по безопасности, повышенные требования к разделению доступа.

На таком проекте практически всё делается штатными средствами, надо только понять систему уровней доступа к модулям, папкам, файлам:

Много кода

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

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

В таких проектах ответственность лежит полностью на разработчиках, за Bitrix Framework не спрячешься, надо внимательно рассматривать вопросы производительности, безопасности, аудита.

Интеграция с внешними системами

Задача потребует нетривиального программирования. Используется модуль Веб-сервисы. Если не хватает функционала, то используя REST, SOAP, JSON, XML-RPC API дорабатываем нужны функционал. Далее реализуете систему синхронизации.

Если данных очень много, то есть смысл создать свои таблицы в MySQL и хранить данные там.

В проектах такого уровня разработчики должны представлять себе администрирование систем. Так при работе с веб-сервисами нужно понимать XML, TCP-IP, FTP. Как пойдут пакеты, где что пропадает. И кроме этого в группу разработчиков надо подключать квалифицированного сисадмина как можно раньше.

Веб-кластер

Веб-кластер позволяет решать множество задач. При этом в коде вашего проекта ничего делать не нужно, это штатная функция Bitrix Framework.

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

Нужно подумать о логике восстановления на базе требований SLA. Надо понять как сделать так, что бы максимум 2 минуты система была недоступна. Последнее - резервное копирование. Нужен отдельный регламент.




3
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии