Geleneksel manuel test yaklaşımları, tutarlılığı zorunlu kılan tek bir veritabanının geçerliliğini sağlamak için tasarlanmış monolitik SQL işlemlerinden evrimleşti. Microservices ve Olay Tabanlı Mimari'ye geçişle birlikte, kalite güvencesi artık, durum değişikliklerinin hizmet sınırları boyunca asenkron olarak yayıldığı dağıtık Saga desenlerini doğrulama zorluğuyla karşı karşıya kalıyor; bu da iki aşamalı taahhüt kilitleri olmadan veri bütünlüğünü sağlamanın yeni metodolojilerini gerektiriyor.
Temel zorluk, ACID garantileri bireysel hizmet veritabanlarına izole edildiğinde yarış koşullarını ve kısmi arıza durumlarını tespit etmektir. Özellikle, PostgreSQL üzerindeki envanter rezervasyonlarının, harici API’lar aracılığıyla yapılan ödeme onaylarının ve Apache Kafka konuları aracılığıyla gerçekleştirilen sipariş onaylarının, ağ bölünmeleri, Kafka tüketici yeniden dengelemesi veya Redis önbellek geçersiz kılma hataları sırasında tutarlılığı sürdüğünü doğrulamak, CAP teoremi standartlarının ve nihai tutarlılık pencerelerinin anlaşılmasını gerektirir.
Kesin zaman manipülasyonu ile durum geçişi haritalama kombinasyonu ile kapsamlı bir Kaos Mühendisliği esinlenmeli manuel test metodolojisi. Bu, Kafka tüketici gruplarına manuel olarak gecikme enjekte etmek için Proxy araçları kullanmayı, aktif işlemler sırasında Redis önbellek boşaltmalarını simüle etmeyi ve aşağı akış hataları meydana geldiğinde Saga tazminat işlemlerinin doğru bir şekilde geri almak için işlemleri kontrol etmek suretiyle sistemin, hayali envanter veya çift ücretlendirmeler olmadan tutarlılığı sürdürmesini sağlamayı içerir.
Lüks bir saat pazarı, 10,000'den fazla kullanıcının beklenen eş zamanlı talebi ile 100 özel saatten oluşan sınırlı bir sürüm için hazırlık yapıyordu. Mimari, PostgreSQL'de stok yöneten Envanter Servisi, Stripe API ile entegre olan Ödeme Servisi ve aralarında asenkron iletişimi sağlayan Apache Kafka kullanıyordu. Ön üretim simülasyonunda, ekip, envanter doğrulamasının ve rezervasyonunun ayrı asenkron mesajlar halinde gerçekleşmesi nedeniyle, son mevcut birimi eş zamanlı olarak satın alan iki kullanıcıyı tespit eden kritik bir hatayı ortaya çıkardı; bu, her iki ödemenin, her iki sipariş hizmeti stok düşüşünü onaylamadan önce yakalanmasına neden olan bir bölünme senaryosu oluşturuyordu.
Çözüm 1: Kafka tüketicilerinin yatay ölçeklendirilmesi
Bu yaklaşım, mesaj işleme gecikmesini azaltmak ve yarış koşularının penceresini en aza indirmek için tüketici örneklerini artırmayı içeriyordu. Ana avantaj, normal yük altında geçiş ve gecikmenin azalmasıydı. Ancak, bu yarış koşulunu esasen çözmedi; sadece çarpışmayı istatistiksel olarak daha az olası hale getirdi, ancak yoğun trafik veya tüketici yeniden dengeleme olayları sırasında mümkün kalmaya devam etti.
Çözüm 2: Redis Redlock ile dağıtık kilitlerin uygulanması
Bu strateji, Envanter Servisi'nin herhangi bir ödeme talebini işleme almadan önce dağıtık bir kilidi edinmesini sağlayan atomik kilitleme mekanizmaları tanıttı. Bu, aynı stok maddesine yönelik eşzamanlı değişiklikleri önlese de, ödeme akışına önemli bir gecikme getirdi, Redis kümesi ağ bölünmeleri yaşarsa potansiyel bir tek nokta arızası oluşturdu ve uygulama çökmesi nedeniyle kilitlerin serbest bırakılmayacağı karmaşık arıza kurtarma senaryoları oluşturdu.
Çözüm 3: Kafka bölüm kontrolü ile manuel düzenlenmiş arıza enjeksiyonu
Bu metodoloji, testçilerin belirli Kafka bölümlerini, Kafdrop gibi yönetim araçlarını kullanarak manuel olarak durdurması ve Docker ağ politikaları aracılığıyla ağ gecikmesi enjekte etmesini gerektiriyordu. Bu, ödeme onayı ile envanter taahhüdü arasındaki kesin zamanlama penceresinin tekrarlanmasını sağladı. Bu yaklaşım zaman alıcıydı ve Kubernetes ağ politikalarını değiştirmek için yükseltilmiş yetkilere ihtiyaç duyuyordu, ancak yarış koşullarının kesin bir yeniden üretimini sağladı ve Saga tazminat işlemi tetikleyicilerinin doğrudan gözlemlenmesine olanak tanıdı.
Seçilen çözüm ve gerekçe
Çözüm 3, sadece deterministik manuel müdahalenin hizmetler arasındaki mikro saniye zamanlama açığını ortaya çıkarabileceği için seçildi. Envanter tüketicisini duraklatırken ödeme tüketicisinin işlem yapmasına izin vererek, sistemin ön ödeme rezervasyon kilidine sahip olmadığını ve tazminat iş akışlarının envanter çakışmaları tespit edildiğinde otomatik olarak tetiklenmediğini doğruladık.
Sonuç
Geliştirme ekibi, ödeme işlemlerinden önce stok ayıran Pending envanter durumu ile iki aşamalı bir taahhüt desenini uyguladı. Manuel testler, aktif ödeme sırasında Kafka yeniden dengelemesini zorladıklarında doğru bir şekilde Saga tazminatının tetiklendiğini, hem envanter rezervasyonlarını hem de ödeme tutma işlemlerini serbest bıraktığını ve veri kaybı olmadan işlemin tamamlandığını doğruladı. Sonraki ürün lansmanı, rapor edilen sıfır çift satış ile başarılı bir şekilde gerçekleşti ve tüm 100 birim son defterde hesaba katıldı.
Mikro hizmetler Olay Tabanlı Tutarlılık sağlarken ACID özelliklerini nasıl doğrularsınız?
Adaylar genellikle yerel veritabanı ACID uyumluluğunu tüm sistem tutarlılığı ile karıştırırlar. Manuel testlerde, bir PostgreSQL işleminin başarılı bir şekilde taahhüt edildiği ancak sonraki Apache Kafka mesaj yayımlamanın başarısız olduğu senaryoları kasten mühendislik yapmanız gerekir; bu, mesaj aracısını izole etmek için Docker ağ bölünmeleri kullanılarak başarılabilir. Veritabanını doğrudan sorgulayarak, mesaj aracısını engellerken, yetim kayıtların varlığını kontrol edin ve ardından geri dönüşüm mekanizmalarının nihayetinde durumu senkronize ettiğinden emin olun, böylece manuel müdahale veya veri bozulması olmadan.
Mesaj Kuyruklarındaki Idempotency testini Tam Olarak Bir Kez semantiklerinden nasıl ayırıyorsunuz ve bu, manuel QA için neden kritik?
Birçok testçi, bunları değiştirilebilir kavramlar olarak yanlış bir şekilde ele alıyor. Idempotency, aynı mesajın birden fazla kez işlenmesinin, bir kez işlenmesiyle aynı sonucu üretmesini sağlarken, bunu bir Kafka mesajını Offset Explorer aracılığıyla manuel olarak yeniden oynatarak ve herhangi bir çift ücret veya envanter düşüşü gerçekleşmediğini kontrol ederek test edersiniz. Tam Olarak Bir Kez semantiklerinin, alt yapının kendisinin çift teslimatları önlemesini sağladığını doğrulamak için broker hatası senaryoları sırasında Kafka işlemsel üretici davranışını gözlemleyerek doğrulamanız gerekir. Manuel QA, her iki boyutu da doğrulamalıdır: uygulamanın idempotent mantık aracılığıyla tekrarları düzgün bir şekilde işleyip işlemediği ve UUID tabanlı çiftleşme filtrelerinin, brokerın geçerli bir şekilde mesajları tekrar teslim etmesi nedeniyle düzgün bir şekilde çalışıp çalışmadığını kontrol edin.
Finansal veri bütünlüğünü riske atmadan, Saga deseninde Tazminat İşlemlerini nasıl doğrularsınız?
Bu, üretim Şemalarını ve API sözleşmelerini yansıtan izole test ortamları oluşturmayı gerektirir, ancak ödeme sağlayıcıları için kumanda kimlik bilgileri kullanır. Ödeme onay aşamasından hemen sonra ancak envanter hizmeti onaylamadan önce Docker kaplarını sonlandırarak arıza dizilerini manuel olarak tetikleyin. Tazminat iş akışının doğru bir şekilde geri ödeme yaptığını ve Redis dağıtık kilitlerini serbest bıraktığını doğrulayın. Adayların genellikle tazminat mekanizmasının kendisinin de başarısız olabileceğini doğrulamayı göz ardı ettiklerini, geri alma aşamasında bir ağ kesintisi simüle etmek gibi tazminat yolunu engelleyerek test etmeniz gerektiğini ve sistemin, finansal tutarsızlıklara yol açabilecek belirsiz bir tutarsızlık durumu yerine, uygun izleme uyarılarıyla birlikte açık bir şekilde tanımlanmış Tazminat Başarısız alarm durumuna girdiğinden emin olmanız gerektiğini belirtin.