Hizmet sanallaştırması, organizasyonların mikro hizmet mimarisine geçiş yapmaya ve giderek daha fazla harici SaaS sağlayıcılarına, ödeme geçitlerine ve test ortamlarında erişimi imkansız veya pahalı olan eski sistemlere bağımlı hale gelmesiyle 2010'ların ortalarında kritik bir model olarak ortaya çıktı. Otomasyon QA ekiplerinin karşılaştığı temel sorun, üçüncü parti API'lere doğrudan bağımlılıkların, oran sınırlama, kumanda istikrarsızlığı ve öngörülemeyen veri durumlarıyla birlikte deterministik olmayan bir durum oluşturmasıdır. Bu öngörülemezlik, test güvenilirliğini yok eder, veri çakışmaları nedeniyle paralel yürütmeyi engeller ve geçit zaman aşımı veya kısmi sistem arızaları gibi nadir ama kritik hata senaryolarını test etmeyi imkansız hale getirir.
Çözüm, mikro hizmetlerinizle harici bağımlılıklar arasında deterministik bir aracı olarak hareket eden akıllı bir hizmet sanallaştırma katmanının uygulanmasını gerektirir. Bu katman, test altyapınız içinde konteynerleştirilmiş yan hizmetler veya bağımsız hizmetler olarak dağıtılan WireMock, Mountebank veya Hoverfly gibi araçları kullanır. Bu mimari, sanal hizmetin ardışık istekler arasında iç durumu sürdürdüğü durumsal senaryo modellemesini desteklemelidir; örneğin, bir siparişin "beklemede" durumundan "gönderildi" ve "teslim edildi" durumuna ilerlemesini simüle ederken, sözleşme doğrulama için uç noktalar açmalıdır. Bu doğrulama mekanizmaları, gelen istekleri OpenAPI spesifikasyonları veya kaydedilmiş trafik ile otomatik olarak karşılaştırarak şemadaki kaymaları tespit eder ve prodüksiyona etki etmeden önce müdahale eder.
Uygulama, keşif testleri sırasında gerçek API etkileşimlerini yakalamak için bir trafik kaydetme mekanizmasını içermelidir. Bu kayıtlar PII için dezenfekte edilir ve sürüm kontrolüne "altın ustalar" olarak işlenir, bu da sanallaştırma katmanının gerçekçi yanıtları tekrar vermesini sağlar. Ayrıca, sistem, gerçek kumanda ortamlarında tetiklenmesi imkansız ama dayanıklılık testi için kritik olan gecikme, zaman aşımı ve hata kodları ekleyerek kaos mühendisliği ilkelerini desteklemelidir.
Bir fintech şirketinde önceki rolümde, kredi verme platformumuzun otomasyon paketi, üç harici sisteme olan bağımlılıklar nedeniyle felaket derecede istikrarsızdı. Bu sistemler arasında, sadece iş saatlerinde erişilebilen bir kredi bürosu API'si ile agresif oran sınırlaması, sadece iş saatlerinde erişilebilen bir eski banka ana çerçevesi ve her dört saatte bir kumanda verilerini rastgele sıfırlayan bir üçüncü taraf kimlik doğrulama hizmeti bulunuyordu. İki yüz uçtan uca testimiz, %40 oranında 429 Fazla İstek hataları ve süresiz veri referansları nedeniyle başarısız oluyordu. Ayrıca, bakım pencereleri uluslararası CI/CD takvimimizle kötü bir şekilde hizalanıyor ve çoklu saat dilimlerinde çalışarak sürüm gecikmeleri yaratıyordu, bu da sürümlerin gecikmesine ve otomasyonun ROI'sine olan paydaş güvenini azalmasına yol açıyordu.
Bu bağımlılıkları çözmek için üç farklı mimari yaklaşımı değerlendirdik. İlk seçenek, test kodu içinde Mockito gibi standart sahteleme kütüphanelerini kullanmaktı; bu hızlı bir yürütme ve basit bir kurulum sağlıyordu fakat test uygulamaları ile API sözleşmeleri arasında sıkı bir bağımlılık oluşturuyordu. Herhangi bir şema değişikliği, on test dosyasının güncellenmesini gerektiriyordu ve bu yaklaşım, beklenen davranışları değiştirmek için geliştirici müdahalesi olmadan teknik olmayan QA mühendislerinin değişim yapma imkanı sağlamıyordu. İkinci yaklaşım, önceden kaydedilmiş JSON yanıtları ile paylaşılan, sabit bir sahte sunucusu kullanmaktı ki bu, tekrar etme sorununu çözmüştü ancak testlerin paralel olarak çalışırken durum çakışmalarını getirmişti. Birden fazla test, aynı "müşteri hesap" kaydını güncellemeye çalışırken birbirlerinin durumunu üzerine yazıyor ve bu öngörülemez hatalara yol açıyordu, bu da hataların çözümlenmesini imkansız hale getiriyor ve test yürütme sürelerini saatlerce artıran ardışık test yürütmeyi gerektiriyordu.
Sonunda, her test yürütmesi için geçici Docker konteynerleri olarak dağıtılan WireMock kullanarak dinamik bir hizmet sanallaştırma mimarisini seçtik, ayrıca sürekli olarak sanallaştırılmış yanıtlarımızı gerçek API şemaları karşısında doğrulayan bir "sözleşme koruyucusu" hizmeti ile birleştirdik. Her test, kendi durumunu geçici bir bellekteki veritabanında sürdüren izole bir sanal ortam aldı; bu, "kredi almak için başvur → kredi kontrolü başarısız → birlikte imza ile yeniden deneyin → onay" gibi karmaşık çok aşamalı iş akışlarını temsil etmesine olanak tanıdı. Sistem, geceleri gerçek trafiği yakalamak ve kaydedilmiş ile gerçek API yanıtları arasında tutarsızlıklar otomatize ederek ayıklamak için kaydedici bir proxy modu kullandı, bu da sözleşme kaymasını saatler içinde uyararak yapıyordu.
Sonuçlar dönüştürücüydü. CI boru hattı istikrarımız %60'tan %98'e geçme oranları ile iyileşti ve test yürütme süresi %40 azaldı çünkü ağ gecikmeleri ve tekrar mantıkları ortadan kaldırıldı. Nihayetinde, gerçek kumanda ortamlarının asla simüle edemediği geçit zaman aşımını ve hatalı XML yanıtlarını test edebildik. QA ekibi, kod yazmadan basit bir web arayüzü aracılığıyla sanallaştırılmış senaryoları değiştirme yetkisi kazandı. Aynı zamanda, geliştiriciler, sözleşme koruyucu uyarıları sayesinde entegrasyon uyumluluğu hakkında hemen geri bildirim aldı ve bu da kırıcı değişiklikleri tanıtımlarının saatler içinde yakalanan işbirlikçi bir kalite kapısı yarattı.
Paylaşılan sanallaştırma altyapısında paralel test yürütmeleri arasında durum sızıntısını nasıl önlersiniz?
Birçok aday, testlerden önce sadece sahte sunucuyu sıfırlamanın yeterli olduğunu varsayıyor, ancak bu, Test A'nın durumu sıfırlarken Test B'nin yürütme aşamasında olduğu yüksek paralelleştirilmiş ortamlarda yarış koşulları yaratır. Bu, yerel olarak yeniden üretmenin imkansız olduğu Heisenbug'lara yol açar ve sayısız mühendislik saatini boşa harcar. Doğru yaklaşım, her test hattı veya sürecinin, ayrı bir sanal hizmet örneği veya adı alanı almasını sağlamak için mimari izolasyonu içerir. Bu, dinamik port tahsisi veya Docker veya Kubernetes kullanarak test başına konteyner örnekleri ile uygulanır. Paylaşılan örneklerin zorunlu olduğu, kaynak kısıtlı ortamlarda, her testin benzersiz bir korelasyon kimliği içermesi gereken kiracıya duyarlı yönlendirme uygulamanız gerekir ve sanallaştırma katmanı, bu kimliklerle anahtarlanan ayrı durum sözlüklerini sürdürerek, fiziksel altyapı kopyalanmadan tam mantıksal izolasyon sağlar.
Hızla gelişen üçüncü taraf API sözleşmeleriyle sanallaştırılmış hizmetlerin senkronize kalmasını sağlayan mekanizmalar nelerdir?
Adaylar sıklıkla, testler kırıldığında elle güncellenmelere güvenerek, otomatik sözleşme kayması tespitinin gerekliliğini göz ardı eder. Bu, üretim sistemlerinin test edilen kodlarla uyumsuz hale gelme gecikmeleri yaratır ki bu gecikmeler günler veya haftalar içinde keşfedilir ve acil yamanın veya geri dönüşlerin yapılmasına yol açar. Sağlam bir çözüm, sanallaştırma katmanınızla ayrı bir sürekli doğrulama boru hattı oluşturmak için Pact veya Spring Cloud Contract gibi sözleşme test çerçevelerini entegre etmektedir. Gerçek sağlayıcı API, sanallaştırılmış beklentilere karşı periyodik olarak örneklenir ve tutarsızlıklar tespit edildiğinde—yeni gereklilik alanları veya eski uç noktalar gibi—sistem otomatik olarak stub tanımlarını güncellemek için pull request'ler oluşturmalı veya sahip ekibe uyarılar tetiklemiştir. Ayrıca, bir "sözleşme öncelik" modeli uygulamak, deneyselli alanları için katı doğrulama modlarının gevşetilmesini sağlar, bu da kritik iş mantığı için sertliğini korurken API geçişleri sırasında sanallaştırmanın işlevsel kalmasını sağlar; bu da, küçük şema eklemeleri için CI boru hattını engellememesini sağlar.
Sisteminizin gerçek ağ hataları altında doğru şekilde davrandığını nasıl doğrularsınız, hizmet sanallaştırması yanıtları yerel ağdan anında dönerken?
Bu, sanallaştırılmış hizmetlere karşı testlerin geçerli olduğu "gerçeklik açığı" problemidir, ancak üretim aşamasında ağ gecikmesi, paket kaybı veya TCP bağlantı zaman aşımı nedeniyle başarısız olurlar. Adaylar sıklıkla, localhost testinin dağıtılmış sistem davranışını doğru bir şekilde temsil ettiğini varsayarak, ağ sanallaştırma veya kaos mühendisliği entegrasyonunu sahte katmanında gözden kaçırır. Çözüm, sanallaştırma aracınızı, yapay gecikmeler ekleyerek, bağlantıları rastgele düşürerek veya bant genişliğini sınırlayarak gerçekçi ağ koşullarını simüle edecek şekilde yapılandırmaktır; bu, üretim ağ topolojilerini yansıtır. İleri düzey uygulamalar, Toxiproxy veya Netflix'in Chaos Monkey'i gibi araçları, sanallaştırma ile birlikte kullanarak, uygulamanız ile sanal hizmet arasında "toksik" aracıları oluşturur. Bu, çevrim kesicilerin, tekrar politikalarının ve zaman aşımı yapılandırmalarının düzgün çalıştığını doğrulamanıza olanak tanır. Bu test olmadan, uygulamalar anında yanıtlar varsayabilir ve gerçek dünya ağ bozulmalarıyla karşılaştıklarında çökme veya donma gerçekleştirebilirler.