Как 1С научить говорить на языке Google и Apache: AVRO и Protobuf внутри

15.01.26

Интеграция - Перенос данных 1C

Внешняя компонента Simple Kafka Connector получила поддержку бинарных форматов AVRO и Protocol Buffers (Protobuf), открывая для 1С-разработчиков возможность полноценной интеграции с современными микросервисными архитектурами. Теперь 1С может обмениваться данными в форматах, которые используют Google, LinkedIn, Uber и другие технологические гиганты, получая прирост производительности до 10 раз и сокращение трафика на 70% по сравнению с JSON.

Вступление: когда JSON перестал справляться

Представьте, что вы отправляете посылку курьерской службой. JSON — это как если бы вы упаковали каждый предмет в отдельную коробку с подробным описанием на каждой стороне: "Это кружка. Цвет: белый. Материал: керамика. Объем: 300мл." Удобно для понимания, но занимает много места.

AVRO и Protobuf — это как компактный штрих-код на минималистичной упаковке. Вся информация там есть, но места занимает в разы меньше, а читается мгновенно специальным сканером.

В мире 1С мы долгое время жили в парадигме "текст решает всё": XML для обмена, JSON для API, CSV для выгрузок. Это работало, пока объемы данных были скромными, а интеграции — не слишком частыми. Но современная архитектура требует другого подхода.

Simple Kafka Connector — это не просто конвертер форматов. Это полноценный клиент Apache Kafka, который включает в себя всю функциональность профессиональной работы с распределённой шиной сообщений: транзакции с гарантией Exactly-Once, управление consumer groups, пакетную отправку, Admin API для управления топиками и кластером. Поддержка AVRO и Protobuf — это мощная надстройка над уже зрелым и проверенным в production решением, которое успешно используется в высоконагруженных системах.

 

Актуальность в контексте микросервисной архитектуры

Проблемы текстовых форматов в enterprise-окружении

В классической архитектуре "1С + несколько внешних систем" JSON справлялся отлично. Но когда ваша инфраструктура вырастает до десятков микросервисов, обменивающихся миллионами сообщений в день через Apache Kafka, начинаются проблемы:

1. Размер имеет значение

Типичное JSON-сообщение с информацией о заказе:

{
  "order_id": "ORD-2026-00001234",
  "customer_id": "CUST-567890",
  "amount": 15420.50,
  "currency": "RUB",
  "status": "pending",
  "created_at": "2026-01-11T10:30:00Z"
}

Размер: ~180 байт

То же сообщение в Protobuf: ~45 байт (экономия 75%)

Когда через Kafka проходит 10 миллионов таких сообщений в день, разница между 1.8 ГБ и 450 МБ трафика становится критичной для стоимости инфраструктуры и скорости обработки.

2. Скорость сериализации

JSON требует парсинга текста, проверки синтаксиса, преобразования типов. Бинарные форматы читаются напрямую в память с минимальными преобразованиями. На практике это даёт разницу в 5-10 раз в скорости обработки.

3. Строгая типизация и эволюция схем

В JSON-мире мы часто сталкиваемся с проблемами:

  • "Почему в одном сообщении amount — строка, а в другом — число?"
  • "Мы добавили новое поле, и старая версия сервиса упала!"
  • "Как понять, какая структура данных ожидается на входе?"

AVRO и Protobuf решают это через схемы — формальные описания структуры данных, которые:

  • Гарантируют типобезопасность
  • Обеспечивают обратную и прямую совместимость при изменениях
  • Служат документацией для разработчиков

 

Место 1С в микросервисной экосистеме

Современная enterprise-система выглядит так:

  •  — система учета и управления (ERP-ядро)
  • Apache Kafka — шина обмена сообщениями
  • Микросервисы — специализированные сервисы (аналитика, ML, интеграции, нотификации)

До появления поддержки AVRO и Protobuf в Simple Kafka Connector разработчики сталкивались с дилеммой:

  • Либо использовать JSON и терять в производительности
  • Либо создавать промежуточные сервисы-конвертеры (что увеличивает задержки и усложняет архитектуру)

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

 

AVRO vs Protobuf: выбираем правильный инструмент

Оба формата решают схожие задачи, но имеют разную философию. Выбор между ними — это не вопрос "что лучше", а вопрос "что подходит для вашего случая".

 

Apache AVRO: самодокументируемые данные

Философия: Схема всегда с данными

AVRO хранит схему прямо в файле/сообщении. Это как если бы к каждой посылке прилагалась инструкция по распаковке.

Когда использовать AVRO:

 Частые изменения схем Когда ваша модель данных активно развивается, и нужна максимальная гибкость. AVRO поддерживает прямую и обратную совместимость "из коробки".

 Аналитические системы и Data Lake Когда данные сохраняются надолго, и через год нужно будет прочитать, что именно было записано. Схема в файле — это самодокументирование.

 Динамические данные Когда структура данных может варьироваться, и нужна возможность работы со схемой в runtime.

 Интеграция с экосистемой Hadoop AVRO — стандарт де-факто для Hadoop, Spark, Hive.

Пример сценария:

Задача: Выгрузка документов из 1С в аналитическое хранилище
Частота: 1 раз в сутки
Объем: 1 млн документов
Особенность: Модель данных меняется раз в квартал (новые реквизиты)

Решение: AVRO
Причина: Схема сохраняется вместе с данными, старые выгрузки
остаются читаемыми, новые поля добавляются без проблем.

 

Protocol Buffers: максимальная производительность

Философия: Схема заранее известна всем участникам

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

Когда использовать Protobuf:

 Высоконагруженные системы Когда счет идёт на миллионы сообщений в минуту, и каждая миллисекунда важна.

 Устоявшиеся схемы Когда структура данных стабильна и меняется редко.

 Минимальный размер сообщений Protobuf на 20-30% компактнее AVRO. Критично для IoT, мобильных приложений, оплаты трафика.

 Интеграция с современными микросервисами Protobuf — стандарт для gRPC, используется в Google, Netflix, Square.

 

Пример сценария:

Задача: Синхронизация остатков в реальном времени
Частота: 1000 сообщений в секунду
Объем: Небольшие структуры (артикул, склад, остаток)
Особенность: Схема стабильна годами

Решение: Protobuf
Причина: Максимальная скорость обработки, минимальный размер,
схема меняется редко.

 

Сравнительная таблица

 Критерий  AVRO  Protobuf  JSON (для сравнения)
 Размер сообщения  Компактный (~50% от JSON)  Очень компактный (~30% от JSON)  Базовый (100%)
 Скорость обработки  Быстрая (в 5-7 раз быстрее JSON)  Очень быстрая (в 8-10 раз быстрее JSON)   Базовая
 Схема в данных  Да (самодокументирование)  Нет (нужно знать заранее)  Нет
 Эволюция схемы  Прямая и обратная совместимость    Обратная совместимость   Зависит от реализации 
 Читаемость без инструментов   Бинарный формат  Бинарный формат  Текстовый формат
 Экосистема  Hadoop, Spark, Kafka, Starrocks  gRPC, Microservices APIs, Cloud Native  Универсальная
 Сложность внедрения  Средняя  Средняя  Низкая
 Использование в 1С  Поддерживается  Поддерживается  Встроенная поддержка

 

Золотое правило выбора

Используйте AVRO, если:

  • Данные хранятся долго (архивы, аналитические хранилища)
  • Схема часто меняется
  • Важна самодокументируемость

Используйте Protobuf, если:

  • Нужна максимальная производительность
  • Схема стабильна
  • Интегрируетесь с gRPC-сервисами

Оставайтесь на JSON, если:

  • Объемы данных небольшие (< 100k сообщений/день)
  • Важна читаемость и отладка
  • Интегрируетесь с legacy-системами

 

Практика: примеры использования в 1С

Пример 1: Отправка данных в формате AVRO

Представим задачу: отправка информации о проведенных документах "Реализация товаров и услуг" в аналитическое хранилище через Kafka.

 
 Шаг 1: Определяем схему AVRO
 
 Шаг 2: Формируем и отправляем данные

Результат: Вместо отправки отдельного JSON-сообщения на каждый документ (180 байт × 1000 документов = 180 КБ), мы отправляем одно AVRO-сообщение размером ~45 КБ. Экономия трафика: 75%.

 

Пример 2: Получение данных в формате Protobuf

Представим обратную задачу: получение обновлений остатков из внешней системы через Kafka в формате Protobuf.

 
 Шаг 1: Определяем схему Protobuf
 
 Шаг 2: Подписка и обработка сообщений

Результат: Обработка остатков происходит в 8-10 раз быстрее, чем при использовании JSON, благодаря бинарному формату Protobuf.

 

Пример 3: Микросервисная интеграция — читаем AVRO, пишем Protobuf

Рассмотрим типичный сценарий микросервисной архитектуры:

  • Микросервис заказов (Order Service) отправляет новые заказы в формате AVRO в топик orders.new (AVRO обеспечивает самодокументируемость и гибкую эволюцию схемы)
  • 1С ERP читает заказы, проверяет остатки, резервирует товар, проводит бизнес-логику
  • 1С ERP отправляет статус обработки в формате Protobuf в топик orders.processing.status (Protobuf обеспечивает максимальную производительность для real-time обработки)
  • Микросервисы (нотификации, логистика, биллинг) читают статусы в Protobuf для дальнейшей обработки
  • Аналитическая система (Kafka Streams, Apache Spark) читает данные из обоих топиков для построения отчётов и дашбордов

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

 

Архитектура решения

 

 

 

Шаг 1: Схемы данных

 

 
 AVRO схема для входящих заказов (от Order Service)
 
 Protobuf схема для статуса обработки

 

Шаг 2: Обработка заказов с Exactly-Once гарантиями (Read-Process-Write)

 

Используем транзакционный подход для обеспечения Exactly-Once семантики. Это гарантирует:

  •  Каждый заказ обрабатывается ровно один раз (нет дубликатов, нет потерь)
  •  Атомарность: либо всё выполняется (чтение, обработка в 1С, запись статуса), либо ничего
  •  При сбоях и перезапусках обработка продолжается с правильной позиции
 
 Обработка заказов из Kafka (читаем AVRO, пишем Protobuf)

 

Результат работы примера с Exactly-Once:

  1. READ (AVRO) — получаем заказы от Order Service (AVRO обеспечивает самодокументируемость и гибкую эволюцию схемы)
  2. PROCESS (1С) — проверяем остатки, резервируем товары в транзакции БД 1С
  3. WRITE (Protobuf) — отправляем компактный статус обработки для микросервисов в транзакции Kafka
  4. COMMIT — фиксируем транзакцию Kafka вместе с offset — гарантия Exactly-Once!
  5. Аналитика читает — Analytics System читает данные из обоих топиков для построения отчётов и дашбордов

 

Ключевые механизмы Exactly-Once:

 

Преимущества такого подхода:

  •  Правильная архитектура — каждый формат используется по назначению: AVRO для событий с эволюцией схемы, Protobuf для высокопроизводительных статусов
  •  1С как центральный процессор — обрабатывает критичную бизнес-логику (остатки, резервирование) между разнородными микросервисами
  •  Производительность — обработка тысяч заказов в минуту благодаря бинарным форматам и эффективной сериализации
  •  Надёжность — транзакции в 1С + Kafka consumer groups гарантируют целостность данных и at-least-once доставку
  •  Масштабируемость — можно запустить несколько экземпляров 1С в одной consumer group для параллельной обработки

 

Пример 4: Гибридный подход для отладки

Один из умных приемов — использовать JSON для разработки и отладки, а AVRO/Protobuf для production:

Функция ОтправитьСообщениеУниверсально(Данные, Топик, ФорматСообщения = "JSON")

    Если ФорматСообщения = "AVRO" Тогда

        // Преобразуем в AVRO
        Компонента.ПреобразоватьВФорматAVRO(Данные, "sales_document");
        Результат = Компонента.ОтправитьСообщениеAVRO(Топик);

    ИначеЕсли ФорматСообщения = "PROTOBUF" Тогда

        // Преобразуем в Protobuf
        Компонента.ПреобразоватьВФорматProtobuf(Данные, "StockUpdate");
        Результат = Компонента.ОтправитьСообщениеProtobuf(Топик);

    Иначе

        // Отправляем как обычный JSON
        Результат = Компонента.ОтправитьСообщение(Данные, Топик);

    КонецЕсли;

    Возврат Результат;

КонецФункции

// Использование:
// Разработка: ОтправитьСообщениеУниверсально(Данные, "test.topic", "JSON");
// Production:  ОтправитьСообщениеУниверсально(Данные, "prod.topic", "PROTOBUF");

 

Заключение

Поддержка AVRO и Protobuf в компоненте Simple Kafka Connector — это не просто добавление "еще двух форматов". Это качественный скачок в возможностях 1С как платформы интеграции.

Теперь 1С может:

  • Говорить на одном языке с современными микросервисами (без промежуточных конвертеров)
  • Обрабатывать большие объемы данных благодаря 10-кратному ускорению и 70% экономии трафика
  • Участвовать в событийно-ориентированных архитектурах наравне с сервисами на Go, Java, Python

Это открывает дорогу к новым архитектурным паттернам: Event SourcingCQRSReal-time analytics — вещам, которые раньше казались недостижимыми в мире 1С.

Практические преимущества

Для бизнеса:

  • Снижение стоимости инфраструктуры — меньше трафика = меньше расходы на облачные сервисы
  • Ускорение интеграций — данные обрабатываются в 5-10 раз быстрее
  • Масштабируемость — возможность обрабатывать миллионы событий в день

Для разработчиков:

  • Типобезопасность — схемы гарантируют корректность данных
  • Версионирование — безболезненная эволюция форматов данных
  • Совместимость — интеграция с любыми современными системами

С чего начать

  1. Изучите вашу архитектуру — определите узкие места в интеграциях
  2. Выберите формат — AVRO для аналитики и гибкости, Protobuf для производительности
  3. Начните с пилота — выберите один поток данных и внедрите бинарный формат
  4. Измеряйте результаты — сравните производительность до и после

Компонента доступна на GitHub с полной документацией и примерами. Начните с малого, и вы увидите, как 1С из "тяжеловесной системы учета" превращается в быстрый и гибкий компонент современной микросервисной архитектуры.


Полезные ссылки:

Документация компоненты:

Внешние ресурсы:

Вступайте в нашу телеграмм-группу Инфостарт

См. также

Перенос данных 1C Программист 1С:Предприятие 8 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

58000 руб.

04.08.2015    184587    429    298    

439

SALE! 15%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

22650 руб.

12.06.2017    158148    947    317    

477

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена | Можно выполнить переход с УПП на БП 3 или запускать выгрузку данных за выбранный период времени | Переносятся документы, начальные остатки и вся справочная информация | Есть фильтр по организации и множество других параметров выгрузки | Поддерживается несколько сценариев работы: как первичный полный перенос, так и перенос только новых документов | Перенос данных возможен в "1С: Бухгалтерия 3.0" версии ПРОФ, КОРП или базовую | Переход с "1С: УПП1.3" / "1С:КА 1.1" на "1С:БП3.0" с помощью правил конвертации будет максимально комфортным! | Можно бесплатно проверить перенос на вашем сервере!

50050 руб.

25.02.2015    186614    349    283    

411

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.264.x) и БП 3.0 (3.0.192.x). Правила подходят для версии ПРОФ и КОРП.

38000 34200 руб.

15.12.2021    32694    243    61    

183

SALE! 10%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Управление торговлей 10 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.88.x) и УТ 11.5 (11.5.25.x).

38000 34200 руб.

23.07.2020    66236    309    86    

248

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Программист 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)

Правила переноса кадровых и расчетных данных и справочной информации из "1С:УПП1.3" или "1С:КА 1.1" в "1С:ЗУП 3.1 | Разработан в формате КД 2 (правила конвертации данных) | При выгрузке есть фильтр по организациям | Обновляется при выходе новых релизов 1С | Развитие алгоритмов | Расчетные документы переносятся в документ "Перенос данных" | Создаются документы "Начальная штатная расстановка" и "Начальная задолженность по зарплате", переносятся кадровые документы

58000 руб.

29.10.2018    61468    77    128    

76

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием Россия Платные (руб)

Регулярный обмен, выгрузка, перенос из КА 1.1, УПП 1.3, УТ 10.3 для обмена с любыми конфигурациями, поддерживающими обмен в формате EnterpriseData (КД3) - БП 3.0, ERP, КА 2, УТ 11, Розница 3, УНФ 3 и другими. Правила для старых и доработанных конфигураций не требуют синхронного обновления и совместимы с новыми и будущими конфигурациями. Обмен по расписанию, через папку, FTP, почту.

16531 руб.

18.02.2016    199952    662    543    

559

Перенос данных 1C Программист Бухгалтер 1С:Предприятие 8 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет НДФЛ ФОМС, ЕФС Платные (руб)

Обработки для быстрого перехода с конфигураций «КАМИН:Расчет заработной платы 3.0», «КАМИН:Зарплата для бизнеса 4.0» и «КАМИН:Зарплата 5.0» на конфигурацию «Зарплата и управление персоналом» версии 3.1.

12200 руб.

25.09.2016    89667    409    257    

340
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Неопределено 111 16.01.26 03:37 Сейчас в теме
Пока всё стабильно работает, это выглядит интересно и весьма заманчиво. Но как разобрать проблемную ситуацию, когда вместо человекочитаемого пакета передаются двоичные данные?
2. Shmell 659 16.01.26 07:56 Сейчас в теме
(1) а отправляете в каком формате?
3. Неопределено 111 16.01.26 08:05 Сейчас в теме
(2) Сейчас JSON, но интересно разобрать AVRO.
4. Shmell 659 16.01.26 09:23 Сейчас в теме
(22)
(3) Получаете двоичные данные, преобразуете в человекочитаемый через
ДекодироватьСообщениеAVRO(ДанныеAVRO, ИмяСхемыJSON, ВозвращатьJSON)

пример avro

или
ДекодироватьСообщениеProtobuf(ДанныеProtobuf, ИмяСхемы, ВозвращатьJSON)

пример protobuf
5. Неопределено 111 16.01.26 09:35 Сейчас в теме
(4) А, ну понятно. Спасибо.
6. smit1c 107 16.01.26 11:40 Сейчас в теме
Хорошая статья!
Но пока не достигнем "миллионы сообщений в минуту" посидим на JSON.....
ixijixi; Трактор; Shmell; +3 Ответить
7. Shmell 659 16.01.26 11:44 Сейчас в теме
(6) Спасибо! Здесь же дело не только в объеме. В avro используются схемы, а это очень выгодно для версионирования данных и интеграций с различными внешними сервисами
8. smit1c 107 16.01.26 11:48 Сейчас в теме
(7)
В avro используются схемы, а это очень выгодно для версионирования данных и интеграций с различными внешними сервисами


Да, когда делаете с нуля и другая система уже поддерживает этот формат.
Но когда в организации куча действующих обменов идёт на JSON, то надо оценить затраты на переделку под другой формат. И стоимость перехода значительно превышает выгоды от использования нового формата.
9. Трактор 1272 16.01.26 12:35 Сейчас в теме
Как я понял из статьи 1С сначала формирует строку JSON, затем скармливает её компоненте, которая возвращает двоичные данные. Экономия возникает при передаче данных.
У меня основные накладные расходы возникают при сериализации данных в JSON. Собственно передача данных волнует мало. Вдобавок данные жмутся при передаче.

Выгода для 1С неочевидна. Ну или я чего-то недоперепонял.
11. Shmell 659 16.01.26 13:52 Сейчас в теме
(9) Если задача — просто передать данные из точки А в точку Б и сжатие уже есть, то выгода действительно минимальна. Avro/Protobuf раскрываются в экосистемных сценариях: много потребителей, Schema Registry, потоковая аналитика, долгосрочное хранение в data lake.

Если просуммировать информацию, которую я изложил в статье, то выгода возникает в следующих кейсах:
1. Контракты данных (Schema) — получатель гарантированно знает структуру, типы полей, обязательность. Не нужно договариваться "на словах".
2. Эволюция схемы — можно добавлять/удалять поля без поломки потребителей (backward/forward compatibility).
3. Schema Registry — централизованный реестр схем для всей компании. Kafka-потребители автоматически получают актуальную схему.
4. Интеграция — Spark, Flink, ksqlDB и другие системы нативно читают Avro/Protobuf без дополнительного парсинга.
Трактор; +1 Ответить
10. Segate 285 16.01.26 13:34 Сейчас в теме
(0) а как можно с вами связаться?
Напишите пожалуйста, https://t.me/segate

Очень хочется задать пару вопросов
12. TyurinArt 103 18.01.26 11:46 Сейчас в теме
(0) если для вас важен размер сообщения, тогда попробуйте сжимать с помощью snappy https://github.com/google/snappy

valve использует его для сжатия CSVCMsg_UpdateStringTable;
13. van_za 314 20.01.26 20:19 Сейчас в теме
Для отправки сообщения требуется регистрация/авторизация