Kurumsal modernizasyon girişimleri, giderek daha fazla IBM MQ ve TIBCO altyapısını Apache Kafka ve AWS EventBridge ile yeniden yazmadan entegre etmeyi gerektirmektedir. Özellikle finansal hizmetler, tekrar eden işlemlerin maddi risk ve düzenleyici ihlal oluşturduğu yerlerde ticaret komutları için tam bir kez işleme kayıtlarını talep etmektedir.
Miras mesaj otobüsleri, yerel idempotentlik ilkesine sahip değil ve yıkıcı okuma ile zorlayıcı FIFO sıralama kullanırken, bulut yerel akışlar, offset tabanlı yeniden oynatma ile değişmez günlükleri tercih etmektedir. Protokol uyumsuzluğu—sabit genişlikteki COBOL kopya kitapları ile kendi kendini tanımlayan Avro—ve farklı teslimat garantileri, adaptör ölçekleme olayları veya geçici ağ bölünmeleri sırasında mesaj kaybı veya çoğaltma vektörleri yaratmaktadır.
Sistemler arasında aracılık yapacak stateless Protokol Adaptörü podlarını Apache Camel veya Spring Cloud Stream aracılığıyla Kubernetes üzerinde dağıtın. Redis veya Amazon DynamoDB kullanarak işlenmiş mesaj UUID'lerini TTL süresiyle izleyen Idempotent Consumer desenini uygulayın. Atomik offset taahhütleri ve mesaj üretimi sağlamak için Kafka İşlemleri ile read_committed izolasyon seviyelerini kullanın. Prometheus aracılığıyla dışa aktarılan IBM MQ kuyruk derinliği metriklerine dayalı olarak KEDA (Kubernetes Olay Tabanlı Ölçeklendirme) kullanarak adaptörleri otomatik ölçeklendirin. Zehirli mesajları baştan sona bloklama olmadan Amazon SQS veya Apache Pulsar içinde uygulanan Ölü Mektup Kuyuları (DLQ) ile izole edin.
Birinci sınıf bir yatırım bankası, IBM MQ kullanan bir z/OS ana çerçevesinden gerçek zamanlı ticaret yürütme akışlarını AWS MSK (Kafka) ye geçirmesi gerekti. Eski sistem, alım/satım emirlerini temsil eden COBOL kopya kitaplarıyla kodlanmış mesajlar yayınlarken, modern Java mikro hizmetleri Avro serileştirilmiş olayları tüketiyordu. Piyasa dalgalanmaları sırasında mesaj oranları 50,000 TPS'ye yükseldi, bu da başlangıçtaki köprü uygulamasının yetersiz TCP bellek boyutları ve geri basınç eksikliği nedeniyle mesajları düşürmesine neden oldu.
Çözüm 1: İkili yazma ve uzlaştırma. Bu yaklaşım, ana çerçeveyi hem IBM MQ hem de Apache Kafka'ya aynı anda yazacak şekilde değiştirmiştir, ardından her geceki uzlaştırma işleri ile farklılıkları düzeltmiştir. Artıları, minimum altyapı değişiklikleri ve hızlı uygulama süreleri sağlar. Eksileri arasında, gün içi ticaretler sırasında tam bir kez işleme kayıtlarını ihlal etme, uzlaştırma gecikmesinin düzenleyici denetim sorunları yaratması ve çatışma çözümü için manuel müdahale gerektirmesi yer alır ve bu otomasyon SLO'larını ihlal eder.
Çözüm 2: Depola ve ilet işlemleri ile XA işlemleri. WebSphere MQ'yu X/Open XA kaynak yöneticisi olarak uygulayarak, Kafka işlemsel üreticileri ile iki aşamalı taahhüt sınırları arasında koordinasyon sağlanır. Avantajları, atomik taahhüt protokolleri aracılığıyla güçlü tutarlılık sağlamaktadır. Dezavantajları arasında, WAN bağlantıları aracılığıyla bir kaç milisaniye boyunca kilitlerin tutulması, engelleyici davranışların alt-100ms gecikme SLO'larını ihlal etmesi ve yönetilen Kafka teklifleri gibi AWS MSK ile uyumsuz XA sürücüsü bulunur.
Çözüm 3: Dışarıdan deduplike edilen stateless protokol köprüleri. Apache Camel köprülerini Kubernetes dağıtımları olarak dağıtarak, COBOL'ı dinamik JRecord ayrıştırıcıları kullanarak Avro'ya dönüştürür ve Kafka'ya iletimden önce benzersiz UUID kontrolleri yaparız. KEDA, MQSC komutuna dayalı olarak kuyruk derinliği bildirimlerine göre podları ölçeklendirir. Artıları arasında, dağıtılmamış bir şekilde yatay olarak ölçeklenebilir bir mimari ve idempotentlik aracılığıyla tam bir kez işleme kayıtları bulunur. Eksileri, DynamoDB kapasite planlaması ve Camel güzergah izleme için operasyonel olgunluk gerektirir.
Seçilen Çözüm ve Sonuç. Çözüm 3, 50ms altı uçtan uca gecikmeyi korumak için seçildi. Black Friday ticaret hacmini simüle eden bir stres testinde, sistem 2.5 milyon mesajı sıfır çoğaltma ve sıfır kayıpla işledi. Yanlış biçimlendirilmiş mesajlar (zorunlu CUSIP alanlarının eksik olduğu) belirdiğinde, Circuit Breaker (Resilience4j) açıldı, kötü mesajları bir Amazon SQS DLQ'sine yönlendirirken, meşru ticaretlerin akışını sağlamaya devam etti ve başlangıç pilotlarında yaşanan felaket yığılmasını önledi.
Eski MQ mesaj deduplike etme yoksa ve Kafka tüketicileri offset taahhüt hataları nedeniyle mesajları yeniden işleyebiliyorsa, tam bir kez işleme kayıtlarını nasıl koruyorsunuz?
Adaylar genellikle yalnızca Kafka idempotent üreticilerin önerildiği, bunun yalnızca Kafka içinde çoğaltmayı çözdüğünü, MQ-to-Kafka sınırında değil olduğunu söyler. Doğru yaklaşım, ana sistemde mesajları kendi DB2 veritabanı içerisinde bir dış kutu tablosuna yazan Outbox Pattern ile birlikte başlar. Daha sonra bir CDC (Change Data Capture) konektörü gibi Debezium, değişiklikleri Kafka'ya akıtır—tüketici tarafında bir deduplike deposu (Redis SETNX veya DynamoDB koşullu yazmaları) ile birleştirilir. Tüketici, UUID'yi iş mantığı uygulaması ile yerel veritabanı işlemleri aracılığıyla atomik olarak depoya yazarak, tüketici yeniden dengelemeleri veya bölüm atamaları sırasında bile idempotentliği garanti eder.
Küplü kopya kitap şeması evrimini protokol adaptör köprüsünü yeniden dağıtmadan nasıl halledersiniz?
Çoğu aday, her şema değişikliği için yeniden dağıtım gerektiren COBOL kopya kitaplarından statik kod üretimini önerir. Sağlam bir çözüm, Runtime Schema Resolution kullanarak, kopya kitap tanımlarını Git veya AWS S3 içinde saklamak ve mesaj başlıklarında versiyon ID'si ile referans almayı içerir. Apache Camel rotası, başlıkta belirtilen şema sürümlerine göre mesajları ayrıştırmak için JRecord ile dinamik sınıf yüklemesi kullanır. Kubernetes ConfigMap veya AWS AppConfig sıcak yeniden yükleme ile, pod yeniden başlatmaları olmadan şemaları güncelleyebilir. Bu, ana çerçeve sürüm döngülerini bulut dağıtım hatlarından ayırır.
Bulut hedefinin uzun süreli bir kesintisi sırasında eski MQ kuyruğunun maksimum derinliğe ulaşmasını nasıl önlersiniz, çünkü MQ'nın sınırlı depolaması vardır?
Adaylar sıklıkla sonsuz yastıklama veya MQ disk genişletmesi önererek, bu yalnızca kaçınılmazı ertelemektedir. Doğru strateji, Backpressure ve Offloading uygular: IBM MQ Uygulama Mesaj Yönlendirme veya MQIPT (MQ İnternet Geçidi) yapılandırarak, kuyruk derinliği %80'i geçtiğinde eşik alarmlarını tetikler. Köprü okumayı durdurur (geri basınç uygulayarak) ve gelen mesajları Amazon S3 veya Azure Blob Storage'da serileştirilmiş dosyalar olarak yazmaya geçer. Bağlantı geri sağlandığında, bir Yan Kapak konteyneri S3 nesnelerini Kafka'ya AWS SDK çok parçalı yüklemeleri kullanarak yeniden oynatır, yığılmayı boşaltarak MQ disk tüketimini veya mesaj kaybını önler.