Введение: Иллюзия простоты
В Enterprise-сегменте (ритейл, финтех, промышленность) часто возникает типичная задача: есть тяжелое, неповоротливое ядро (SAP, Oracle, IBM Tririga или монолитная 1С) и есть необходимость дать доступ к части его данных внешним контрагентам.
Бизнес просит: «Давайте сделаем легкий B2B-портал для подрядчиков, чтобы они сами обновляли свои лимиты/квоты/статусы».
На первый взгляд задача кажется тривиальной: подняли Frontend на React/Vue, сделали пару REST API эндпоинтов и пишем напрямую в базу ядра. Но именно здесь начинаются архитектурные катастрофы, которые стоят корпорациям миллионы рублей из-за потерянных данных и логических конфликтов.
В этой статье я разберу паттерн отказоустойчивой двусторонней интеграции через шину данных (ESB) и покажу, как мы стандартизируем описание таких узлов с помощью протокола АОК (Архитектурно-Ориентированное Знание).
Проблема: Гонка состояний и «Хрупкая связь»
Представим процесс:
- Подрядчик заходит на Портал КА (Контрагента) и меняет свою производственную квоту (например, может взять 50 объектов вместо 10).
- В это же время внутренний менеджер (Бизнес-администратор) в интерфейсе Enterprise-ядра тоже меняет квоту этого подрядчика (например, снижает до 5 из-за штрафа).
Если портал интегрирован с ядром синхронно (точка-точка):
- Race Condition: Чей запрос пришел последним, тот и перетер данные.
- Отказ в обслуживании: Если ядро ушло на бэкап или обновление, внешний портал «падает» или выдает 500-е ошибки. Пользователи в ярости.
- Угроза безопасности: Выставлять API ядра наружу, даже через балансировщик — плохая практика.
Решение: Асинхронная двусторонняя интеграция через ESB
Чтобы избежать этого, мы применяем паттерн с использованием промежуточной интеграционной шины (ESB) и событийно-ориентированной модели (Event-Driven).
Вот как выглядит правильный Data Flow (Sequence Diagram):
Разбор архитектуры:
- Изоляция: Портал ничего не знает о структуре базы ядра. Он отправляет стандартизированный JSON в ESB. ESB берет на себя трансформацию payload'а в тяжелый SOAP/XML (или специфичный REST), который «понимает» ядро.
- Асинхронность и Буферизация: Если ядро недоступно, ESB сохраняет сообщение в очередь (например, RabbitMQ или Kafka). Портал мгновенно отвечает пользователю "Данные приняты в обработку", а шина доставит их, как только ядро «оживет».
- Master-система: Ядро всегда является источником правды (Single Source of Truth). Если бизнес-администратор меняет данные внутри, срабатывает внутренний триггер (OnSave/Workflow), ядро пушит webhook в шину, а шина обновляет данные на Портале КА.
Документирование как код: Протокол АОК (Архитектурно-Ориентированное Знание)
Даже идеальная архитектура превращается в Legacy («легаси»), если её не задокументировать. В Enterprise-разработке документация в Confluence часто устаревает еще до релиза.
В нашей практике мы используем Стандарт АОК. Это паспорт инженерного решения, который встраивается прямо в заголовок ключевых контроллеров или конфигурационных файлов ESB. Разработчик, открывая код, сразу видит бизнес-контекст.
Пример паспорта для модуля синхронизации:
/**
* ===================================================================
* | AOK PASSPORT: CAPACITY SYNCHRONIZATION MODULE |
* ===================================================================
* @PURPOSE
* >> Обеспечение двусторонней синхронизации параметров "Квот"
* между Личным Кабинетом контрагента и карточкой в Core-системе.
*
* @ARCHITECTURE
* >> 1. Принимает JSON payload от Портала КА.
* >> 2. Валидирует значения (min/max) согласно настроечной таблице.
* >> 3. Инициирует обновление записи в таблице (Business Object).
* >> 4. При изменении данных со стороны Бизнес-Администратора запускает
* Background-процесс для передачи данных обратно через Webhook.
*
* @INTEGRATION
* >> Endpoint: /api/v1/sync_capacity
* >> Механизм защиты: JWT-токен валидация, SSL/TLS шифрование.
* >> Обработка ошибок: В случае недоступности шины активируется
* Retry-политика (3 попытки с интервалом 5 мин), после логирование в Kibana.
*
* @SOLID_COMPLIANCE
* >> Single Responsibility: Модуль отвечает только за синхронизацию данных,
* логика расчета рейтингов изолирована в отдельном микросервисе.
* ===================================================================
*/
Такой подход ликвидирует «амнезию» у команды. Даже если сменится подрядчик или уволится Lead-инженер, новый разработчик за 2 минуты поймет зачем написан этот код и с чем он интегрирован.
Итог
Прямая интеграция внешних порталов с Enterprise-ядром — это бомба замедленного действия. Использование ESB, асинхронных очередей и четкого документирования архитектуры (АОК) позволяет создавать отказоустойчивые системы, которые выдерживают любые нагрузки и смены команд.
Стройте системы, а не костыли.
Автор: Владимир Евполов, Системный Архитектор ITWWS.