Инициативы по модернизации предприятий все чаще требуют интеграции многолетней инфраструктуры IBM MQ и TIBCO с Apache Kafka и AWS EventBridge без переписывания устаревших мейнфреймов COBOL. Финансовые услуги требуют семантики точно один раз для торговых команд, где дублирование выполнения создает материальный риск и нарушение нормативных требований.
Устаревшие шины сообщений не имеют собственных примитивов идемпотентности и полагаются на императивный порядок FIFO с разрушительными чтениями, в то время как облачные потоки предпочитают неизменяемые журналы с повторами на основе смещений. Несоответствие протоколов — фиксированные длины копий COBOL против самоописывающегося Avro — в сочетании с разнородными гарантиями поставки создает векторы потери или дублирования сообщений во время событий масштабирования адаптеров или временных сетевых разделений.
Развернуть статeless Программный адаптер в контейнерах с Apache Camel или Spring Cloud Stream внутри Kubernetes, чтобы проводить медиацию между системами. Реализовать шаблон Идемпотентный потребитель, используя Redis или Amazon DynamoDB для отслеживания обработанных UUID сообщений с истечением срока действия TTL. Использовать Kafka Transactions с уровнями изоляции read_committed для обеспечения атомарных коммитов смещений и производства сообщений. Автоматически масштабировать адаптеры с помощью KEDA (Kubernetes Event-driven Autoscaling) на основе метрик глубины очереди IBM MQ, экспортируемых через Prometheus. Изолировать проблемные сообщения в Очереди смертоносных писем (DLQ), реализованных в Amazon SQS или Apache Pulsar, чтобы предотвратить блокировку на уровне головы.
Инвестиционный банк первого уровня нуждался в миграции потоков выполнения сделок в реальном времени с мейнфрейма z/OS, работающего на IBM MQ, на AWS MSK (Kafka) без простоев. Устаревшая система публиковала сообщения, закодированные в копиях COBOL, представляющие заказы на покупку/продажу, в то время как современные микросервисы на Java потребляли события, сериализованные в Avro. Во время рыночной волатильности скорость сообщений возросла до 50,000 TPS, что привело к тому, что первоначальная реализация моста сбрасывала сообщения из-за недостаточного размера буферов TCP и отсутствия обратного давления.
Решение 1: Двойная запись с примирением. Этот подход модифицирует мейнфрейм для одновременной записи как в IBM MQ, так и в Apache Kafka, а затем выполняет ночные задачи примирения для исправления несоответствий. Плюсы включают минимальные изменения в инфраструктуре и быстрое время реализации. Минусы включают нарушение семантики точно один раз во время внутридневных сделок, задержка примирения, создающая проблемы с аудитом, и необходимость ручного вмешательства для разрешения конфликтов, нарушающего SLO автоматизации.
Решение 2: Хранение и пересылка с транзакциями XA. Реализовать WebSphere MQ как менеджера ресурсов X/Open XA, координируя с транзакционными производителями Kafka в рамках границ двухфазного коммита. Плюсы обеспечивают высокую консистентность через атомарные протоколы обязательств. Минусы включают блокировки, удерживаемые на миллисекунды через WAN ссылки во время репликации по регионам, блокирующее поведение, нарушающее SLO латентности менее 100 мс, и несовместимость драйвера XA с управляемыми предложениями Kafka, такими как AWS MSK.
Решение 3: Stateless протокольные мосты с внешней дедупликацией. Развернуть мосты Apache Camel как развертывания Kubernetes, преобразующие COBOL в Avro с использованием динамических парсеров JRecord с уникальными проверками UUID перед производством в Kafka. KEDA масштабирует контейнеры на основе глубины очереди, сообщаемой командой MQSC. Плюсы включают неблокирующую горизонтально масштабируемую архитектуру и точно один раз через идемпотентность, а не распределенные транзакции. Минусы требуют операционного совершенства для планирования мощностей DynamoDB и мониторинга маршрутов Camel.
Выбранное решение и результат. Решение 3 было выбрано для поддержания задержки менее 50 мс от начала до конца. Во время нагрузочного теста, имитирующего объем торговли в Черную пятницу, система обработала 2.5 миллиона сообщений без дубликатов и потерь. Когда появились неправильно сформированные сообщения (отсутствующие обязательные поля CUSIP), Circuit Breaker (Resilience4j) сработал, перенаправляя плохие сообщения на DLQ Amazon SQS, позволяя законным сделкам проходить, предотвращая катастрофическую задержку, наблюдаемую во время первоначальных испытаний.
Как вы поддерживаете семантику точно один раз, когда устаревший MQ не имеет дедупликации сообщений и потребители Kafka могут повторно обрабатывать сообщения из-за сбоев коммита смещения?
Кандидаты часто предлагают только идемпотентных производителей Kafka, что решает только проблему дедупликации внутри Kafka, но не на границе MQ-to-Kafka. Правильный подход комбинирует Outbox Pattern на исходной системе — где мейнфрейм записывает сообщения в таблицу исходящих сообщений в своей базе данных DB2 транзакционно, а затем соединитель CDC (Change Data Capture), такой как Debezium, потоково передает изменения в Kafka — с хранилищем дедупликации (Redis SETNX или DynamoDB условные записи) на стороне потребителя. Потребитель атомарно записывает UUID в хранилище с выполнением бизнес-логики, используя транзакции локальной базы данных, обеспечивая идемпотентность даже во время переспределения потребителей или переназначения разделов.
Как вы обрабатываете эволюцию схемы копий COBOL без повторного развертывания протокольного адаптера?
Большинство кандидатов предлагает статическую генерацию кода из копий COBOL с использованием таких инструментов, как CB2XML, что требует повторного развертывания для каждого изменения схемы. Надежное решение использует Runtime Schema Resolution: храните определения копий в Git или AWS S3, ссылаясь на идентификатор версии в заголовках сообщений. Маршрут Apache Camel использует JRecord с динамической загрузкой классов для разбора сообщений на основе версий схемы, указанных в заголовках. Скомбинируйте с ConfigMap Kubernetes или AWS AppConfig для горячей перезагрузки для обновления схем без перезапуска подов. Это разъединяет циклы выпуска мейнфрейма от облачных конвейеров развертывания.
Как вы предотвращаете достижение максимальной глубины очереди у устаревшего MQ в течение длительного отключения облачного назначения, учитывая, что у MQ есть конечное хранилище?
Кандидаты часто предлагают бесконечное буферизование или расширение диска MQ, что лишь откладывает неизбежное. Правильная стратегия реализует Обратное давление и Вывоз: настройте IBM MQ Application Message Routing или MQIPT (MQ Internet Pass-Thru), чтобы срабатывать предупреждения, когда глубина очереди превышает 80%. Мост прекращает чтение (применяя обратное давление) и переключается в режим Хранение и пересылка, записывая входящие сообщения в Amazon S3 или Azure Blob Storage в виде сериализованных файлов. Как только связь восстанавливается, контейнер Sidecar повторно проигрывает объекты S3 в Kafka с использованием многокомпонентных загрузок AWS SDK, очищая накопления без истощения диска MQ или потерь сообщений.