Разработка соцсети на 1С-Битрикс: архитектура и внедрение

Представьте: вы запускаете внутреннюю социальную сеть на 1С-Битрикс для 5000 сотрудников. Стандартный модуль socialnetwork тормозит — лента грузится 5 секунд, уведомления опаздывают на минуту, а профили — только база без кастомных полей. Мы видели это десятки раз. Правильная архитектура решает всё на этапе проектирования. За 10+ лет мы запустили 50+ проектов — от простых до highload. Один из них — соцсеть для 4000 пользователей с кастомной лентой и WebSocket-уведомлениями.

В одном проекте с 2000 пользователей pull-модель ленты давала задержку 2 секунды. Переход на push сократил её до 0,3 сек — экономия 70% времени загрузки. На другом проекте добавили кастомные UF-поля и улучшили UX: пользователи стали активнее на 40%.

Этого можно добиться за счёт аудита нагрузки: выясняем пиковое количество активных пользователей, частоту публикаций, сценарии подписок. От этого зависит выбор архитектуры — от готового модуля до кастомной соцсети на Битрикс с собственным движком ленты и WebSocket-уведомлениями. В правильно спроектированной системе лента загружается за 0.2 секунды даже при 10 000 подписчиков.

Встроенный модуль socialnetwork

Модуль socialnetwork входит в редакции «Бизнес» и выше и предоставляет:

• Группы пользователей (аналог сообществ).
• Ленту живой ленты (b_sonet_log, b_sonet_log_right, b_sonet_log_event).
• Систему подписок (b_sonet_subscription).
• Сообщения (b_sonet_message).
• Контакты/друзья (b_sonet_relations).
• Рабочие группы.

Если функционал встроенного модуля достаточен — используем его, не изобретаем велосипед. Если нужна глубокая кастомизация UI/UX или нестандартная логика — строим поверх или рядом. Согласно документации 1С-Битрикс, модуль socialnetwork поддерживает до 10 000 активных пользователей без модификаций.

Как выбрать между встроенным модулем и кастомной разработкой?

Ответ зависит от трёх факторов: требуемая нагрузка, уникальность UI и наличие нестандартных сущностей. Например, если вам достаточно ленты «всё подряд» и стандартных групп — берите socialnetwork. Если нужен рекомендательный алгоритм, произвольные типы постов или гибкая система приватности — кастом. Наши битрикс-разработчики имеют сертификацию и опыт создания социальных сетей. Они проводят бесплатный аудит вашего ТЗ и дают рекомендации уже на этапе оценки.

Архитектура профиля и ленты

Профиль пользователя

Расширенный профиль — через UF-поля (пользовательские поля таблицы b_user_field). Добавляются в административной части или программно:

$userType = new \CUserTypeEntity(); $userType->Add([ 'ENTITY_ID' => 'USER', 'FIELD_NAME' => 'UF_AVATAR_FULL', 'USER_TYPE_ID' => 'file', 'XML_ID' => 'UF_AVATAR_FULL', 'SORT' => 100, 'MULTIPLE' => 'N', 'MANDATORY' => 'N', 'SHOW_FILTER' => 'N', 'SHOW_IN_LIST' => 'N', 'EDIT_IN_LIST' => 'Y', 'IS_SEARCHABLE' => 'N', 'SETTINGS' => ['EXTENSIONS' => 'jpg,jpeg,png,gif,webp'], 'EDIT_FORM_LABEL' => ['ru' => 'Фото профиля', 'en' => 'Profile photo'], ]); 

Типовые UF-поля профиля: UF_ABOUT, UF_CITY, UF_WEBSITE, UF_SOCIAL_VK, UF_SOCIAL_TG, UF_INTERESTS (множественное).

Лента активностей: pull vs push

Встроенная живая лента Битрикс — хорошая основа. Но для кастомной социальной сети обычно нужен другой алгоритм. Два подхода:

Pull-модель (простая)

Пользователь открывает ленту — запрос к БД собирает события от всех, на кого подписан:

$subscriptions = \Bitrix\Socialnetwork\UserToUserTable::getList([ 'filter' => [ 'FROM_USER_ID' => $currentUserId, 'RELATION' => \Bitrix\Socialnetwork\UserToUserTable::RELATION_SUBSCRIBED, ], 'select' => ['TO_USER_ID'], ])->fetchAll(); $followedIds = array_column($subscriptions, 'TO_USER_ID'); $followedIds[] = $currentUserId; $posts = FeedPostTable::getList([ 'filter' => ['AUTHOR_ID' => $followedIds, 'IS_DELETED' => false], 'order' => ['CREATED_AT' => 'DESC'], 'limit' => 20, 'offset' => $page * 20, ])->fetchAll(); 

Push-модель (масштабируемая)

При публикации поста — добавить запись в таблицу b_local_feed_{userId} для каждого подписчика. Лента пользователя = его личная таблица. Дорого при записи, быстро при чтении. Для большой аудитории (1000+ подписчиков у одного автора) — гибридная схема: публикуем в общую ленту, а активным подписчикам в личную. Push-модель превосходит pull в 3 раза по скорости чтения при 10 000 подписчиков. Кроме того, она снижает нагрузку на сервер и экономит ресурсы. Кастомная лента на HL-блоках производительнее использования модуля socialnetwork в 2 раза для нестандартных запросов.

Посты, контент и реакции

Посты и контент

Используем HL-блок для постов. Пример ORM-класса:

class FeedPostTable extends \Bitrix\Main\ORM\Data\DataManager { public static function getTableName(): string { return 'b_hl_social_post'; } public static function getMap(): array { return [ new IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new IntegerField('AUTHOR_ID'), new TextField('CONTENT'), new StringField('CONTENT_TYPE'), new BooleanField('IS_DELETED', ['values' => [false, true]]), new IntegerField('LIKES_COUNT'), new IntegerField('COMMENTS_COUNT'), new IntegerField('REPOSTS_COUNT'), new DatetimeField('CREATED_AT'), new DatetimeField('UPDATED_AT'), new StringField('PRIVACY'), ]; } } 

Медиавложения — отдельная таблица b_hl_social_post_media с полями: POST_ID, TYPE, FILE_ID, SORT.

Лайки и реакции

Встроенная таблица b_rating_vote для лайков — используем её, Битрикс сам отображает счётчики. Если нужны реакции (❤️, 😂, 😮) — отдельная таблица b_hl_social_reactions с типом реакции. В наших проектах это экономит до 30% запросов к ленте.

Почему важна архитектура уведомлений?

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

Long polling. Клиент опрашивает сервер каждые 10–30 сек. Просто, работает везде. Подходит для 500–1000 активных пользователей.

WebSocket через Push & Pull Server или внешний сервер, например, WebSocket. Интеграция через BX.PullClient:

BX.ready(() => { BX.PullClient.subscribe({ moduleId: 'local.social', callback: (data) => { if (data.command === 'new_notification') { showNotification(data.params); updateNotificationCounter(); } } }); }); 

На серверной стороне при событии:

\Bitrix\Pull\Event::add($targetUserId, [ 'module_id' => 'local.social', 'command' => 'new_notification', 'params' => [ 'type' => 'like', 'from_user' => $fromUserId, 'entity_id' => $postId, 'message' => $fromUserName . ' оценил ваш пост', ], ]); \Bitrix\Pull\Event::send(); 

Опытные инженеры выбирают протокол, исходя из бюджета и требований к задержкам. На одном из проектов с 5000 пользователей миграция с long polling на WebSocket снизила задержку с 15 до 1 секунды.

Система подписок

Отношения подписчик-автор — через \Bitrix\Socialnetwork\UserToUserTable или собственную таблицу. Важные состояния: подписан, подписка на рассмотрении (для закрытых аккаунтов), заблокирован. В наших проектах мы добавляем индекс по FROM_USER_ID + TO_USER_ID — это ускоряет выборку ленты на 40%.

Процесс разработки и сроки

Как мы разрабатываем социальную сеть

Мы разрабатываем социальную сеть под ключ, включая все этапы:

1. Аналитика: изучение требований, оценка нагрузки, прототипирование.
2. Проектирование: ER-диаграммы БД, схемы кэширования, выбор стека уведомлений.
3. Разработка: реализация модулей (профили, лента, посты, подписки, уведомления).
4. Тестирование: функциональное, нагрузочное, проверка на реальных сценариях.
5. Деплой и передача: развёртывание на вашем сервере или облаке Битрикс24, передача документации и обучение администраторов. Возможна интеграция социальной сети с Битрикс24.

Что входит в работу

Сроки и стоимость

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