Разработка интеграционной шины и ESB
Проектирование отказоустойчивых микросервисов для связки 1С, BPM-систем и внешних API. Решаем проблемы нагрузки, потери данных и рассинхрона там, где типовые коннекторы не справляются.
Когда типовая интеграция перестаёт работать
Признаки того, что вашей архитектуре нужна инженерная доработка.
Блокировки в пиковые часы
Регламентные задания 1С на обмен с маркетплейсами или ЭДО блокируют пользовательские сеансы. Склад останавливается, бухгалтеры не могут провести документы.
Рассинхрон остатков
Из-за отсутствия retry-логики и идемпотентности при сбоях API создаются дубли заказов или теряются обновления цен. Штрафы маркетплейсов растут ежемесячно.
Медленная выгрузка данных
OData и web-сервисы 1С не справляются с объёмом >10k SKU. Выгрузка занимает часы вместо минут, а бизнес-аналитика строится на вчерашних данных.
Технологический стек решения
Микросервисная архитектура
Независимые сервисы на Go и Symfony 7. Каждый домен (заказы, остатки, контрагенты) масштабируется точечно без переписывания монолита.
Очереди сообщений
RabbitMQ/Kafka для асинхронного обмена. Гарантированная доставка, exponential backoff и dead-letter очереди для обработки неустранимых ошибок.
Прямое чтение SQL-реплик
Подключение к read-only репликам PostgreSQL напрямую. Снижение нагрузки на продуктив ERP на 90% и ускорение выгрузки больших объёмов.
Процесс разработки интеграционной шины
Аудит и проектирование
Анализируем текущую архитектуру, нагрузку и боли. Проектируем схему интеграции, выбираем стек и определяем границы сервисов.
Разработка MVP
Реализуем ключевые потоки данных: чтение из 1С через реплику, обработка в очередях, отправка во внешние API. Покрываем тестами.
Нагрузочное тестирование
Имитируем пиковую нагрузку (x3 от текущей). Проверяем работу retry-логики, dead-letter очередей и мониторинга в стрессовых условиях.
Внедрение и передача
Разворачиваем в вашем контуре (On-Premise / Cloud). Настраиваем мониторинг Prometheus/Grafana. Передаём документацию и обучаем вашу команду.
Типовая схема интеграции
Пример архитектуры для e-commerce с нагрузкой >10k заказов/день.
Что вы получаете на выходе
Не просто код, а полноценную инженерную систему с документацией и мониторингом.
Параметры retry-логики для Ozon API
Настроены параметры экспоненциальной задержки с джиттером для предотвращения thundering herd при восстановлении API после сбоя. Dead-letter очередь настроена на хранение сообщений в течение 7 дней перед автоматической архивацией.
# messenger.yaml — конфигурация транспорта
framework:
messenger:
transports:
ozon_sync:
dsn: '%env(RABBITMQ_DSN)%'
options:
exchange: { name: ozon_integration, type: direct }
queues:
ozon_sync_queue:
binding_keys: [ozon_sync]
arguments:
x-dead-letter-exchange: 'dlx_exchange'
x-message-ttl: 604800000 # 7 дней TTL
routing:
'App\Message\SyncOzonStock': ozon_sync
Работаем с проектами от 500 млн ₽ оборота · NDA по запросу
Частые вопросы
Нужно ли менять конфигурацию 1С для подключения шины?
Нет. Интеграционная шина работает как внешний сервис и подключается к 1С через OData или прямое чтение SQL-реплик. Типовая конфигурация 1С не изменяется, что гарантирует безопасность при обновлениях платформы.
Какая инфраструктура требуется для запуска?
Минимально: 2 vCPU, 4 GB RAM под сервис + отдельный инстанс RabbitMQ/PostgreSQL. Для Highload-нагрузок (>50k транзакций/день) рекомендуем кластер из 3 нод с горизонтальным масштабированием consumer-процессов.
Можно ли интегрировать шину с нашей существующей BPM-системой?
Да. Шина спроектирована как независимый слой и поддерживает интеграцию с Elma365, SimpleOne, Bpmsoft и другими BPM-платформами через REST/gRPC API. Мы адаптируем протокол обмена под специфику вашей системы.
Кто будет поддерживать систему после внедрения?
Мы передаём полную документацию, настроенный мониторинг и обучаем вашу команду. При необходимости заключаем договор SLA-поддержки с гарантированным временем реакции на инциденты.