gRPC hizmetleri için otomatik sözleşme testleri uygulamak, REST doğrulamasına kıyasla temelde farklı bir yaklaşım gerektirir, çünkü Protokol Buffers (protobuf) insan okunabilir metin yerine ikili seri hale getirmeye dayanır. Strateji üç temel alana odaklanmalıdır: şema evrimi yönetimi, ikili yük bütünlüğü ve dil bağımsız seri hale getirme doğrulaması.
buf (Protokol Buffers yapı sistemi) kullanarak, CI/CD boru hatlarındaki linting kurallarını ve kırıcı değişiklik tespitini zorlayın. Mevcut proto tanımlarını önceki Git komiteleri veya bir Protobuf Schema Registry temel çizgisi ile karşılaştırmak için buf breaking komutlarını yapılandırın; alan numaralarının değişmez kaldığından ve silinen alanların, seri format bozulmasını önlemek için uygun şekilde rezerve edildiğinden emin olun.
Dil bağımsız doğrulama için, gRPC eklenti desteği ile Pact kullanın veya Java, Go ve Python'da yürütme yapan özel ikili doğrulama suitleri uygulayarak bir dilden diğerine seri hale getirilmiş mesajların doğru bir şekilde ayrıştırıldığını doğrulayın. Bu, dil spesifik uygulamaların varsayılan değerleri veya paketlenmiş tekrarlanan alanları farklı bir şekilde yorumlayabileceği ince sorunları yakalar.
Ayrıca, prototool veya buf generate'i Bazel ile entegre ederek, üretilen istemci kütüphanelerinin hizmet dağıtımlarıyla senkronize kalmasını sağlayın ve tüketicilerin eski proto sözleşmelere karşı derlenmesini önleyin.
Problem tanımı
Bir finansal teknoloji şirketi, bir Java tabanlı monoliti ile risk hesaplamasını yöneten yeni Go mikro hizmetleri arasındaki gecikmeyi iyileştirmek için ödeme işlemlerini REST’ten gRPC’ye taşımıştır. Üç haftalık üretim süresinin ardından, Java hizmeti güncellenmiş Go hizmetiyle iletişim kurarken yanlış risk puanları hesaplamaya başlamıştır. Araştırmalar, Go ekibinin bir proto alanını (risk_factor'dan risk_score'a) yeniden adlandırdığını ve aynı dağıtımda alan numarasını 5'ten 6'ya değiştirdiğini ortaya çıkarmıştır; isim değişikliğinin güvenli olduğunu varsayarak. Ancak, Java istemcisi hala etiket 5 ile ikili veri gönderiyordu; bu, Go hizmetinin farklı bir alanı (boolean is_flagged) olarak yorumlamasına neden oldu ve bu da sessiz mantıksal hatalara yol açtı, ayrıştırma hataları yerine.
Düşünülen farklı çözümler
Pull request'ler üzerinden manuel proto dosyası incelemesi: Ekipler proto değişiklikleri için pull request'leri görsel olarak inceleyecekti, kırıcı değişiklikleri yakalamak için kod sahiplerine güvenerek. Artıları: Sıfır altyapı maliyeti, mevcut GitHub iş akışlarını kullanıyor. Eksileri: İnsan denetçileri, isimleri aynı anda güncellendiğinde alan numarası değişimlerini sürekli olarak gözden kaçırdı; ikili yüklerin uyumlu kaldığını garanti eden otomatik bir yöntem sunmadı; günlük dağıtımlarda 15'ten fazla mikro hizmette kötü bir şekilde ölçeklendi.
buf kırıcı tespitini kullanarak statik analiz: Alan etiketleri değiştirilmeden veya rezerve edilmeden proto dosyalarını ana dal ile karşılaştırdığı ve derlemeleri başarısız kıldığı otomatik buf kırıcı kontrolleri CI boru hattında uygulayın. Artıları: Anlık geri bildirim (alt saniye yürütme), belirli alan numarası değişiklik sorununu önledi, hafif entegrasyon. Eksileri: Sadece şema tanımını doğruladı, gerçek ikili seri hale getirme davranışını veya dil spesifik kenar durumlarını (örneğin, Go'nun nil dilimlerini nasıl ele aldığı ile Java'nın boş listeleri nasıl ele aldığı) doğrulamadı; her iki hizmetin de doğru şemalar kullandığı ancak farklı protobuf kütüphane sürümlerinin bilinmeyen alanları farklı yorumladığı sorunları yakalayamadı.
İkili yük doğrulaması ile çift yönlü sözleşme testi: Java istemcisinin beklenen ikili istek/cevap yüklerini kaydettiği ve Go sağlayıcısının eşleşen byte dizilerini üretebileceğini doğruladığı tüketici odaklı sözleşmeler oluşturmak için Pact gRPC uzantılarını kullanın. Ayrıca, önerilen değişikliklerden üretilen proto stub'larla her iki hizmeti döndürmek için Docker Compose kullanarak dil bağımsız entegrasyon testleri uygulayın. Artıları: Gerçek seri hale getirme/ayrıştırma gidiş dönüşlerini doğruladı, dil spesifik varsayılan değer tutarsızlıklarını yakaladı, her iki hizmetin dağıtım öncesinde seri formatı üzerinde mutabık kalmasını sağladı. Eksileri: Her iki ekibin de paylaşılan sözleşme deposunu sürdürmesini gerektiren karmaşık bir başlangıç kurulumu; çoklu konteyner düzenlemesi nedeniyle her derleme için CI yürütme süresini 4 dakika artırdı.
Seçilen çözüm ve gerekçe
Ekip, özellik dallarındaki geliştirici geri bildirimi için anında geri dönüş sağlayan buf kırıcı ile pull request derlemeleri sırasında Pact sözleşme doğrulamasını birleştiren hibrit bir yaklaşım seçti. buf aracı, ilk olaya neden olan alan numarası değişimini önleyerek iç döngü geliştirme için gerekli hızı sağladı. Pact katmanı, sıfır uyumlu spontane durumu yakalayarak, Java'nın boş dizeleri boyut sınırlı sıfır bayt olarak seri hale getirdiği ve Go'nun protobuf optional dizeleri için yok alanları beklediği kritik güvenlik ağı sağladı. Bu kombinasyon, yürütme hızını kapsamlı güvenlikle dengelemiştir.
Sonuç
Uygulamadan sonra, boru hattı ilk ayda 12 kırıcı proto değişikliği tespit etti (3 alan numarası değişimi ve 2 rezerve edilen alan çatışması dahil), tümü geliştirme sırasında yakalandı. Dağıtımdan sonra sıfır seri hale getirme ile ilgili olay yaşandı. Sözleşme ihlallerini tespit etme süresi ortalama 4,2 günden (üretim hata ayıklama) 3 dakikaya (CI hatası) düştü ve dil bağımsız test paketi, Java ve Go mühendislik ekipleri arasındaki API sürüm grafiği tartışmaları için gerçek kaynak haline geldi.
Sözleşme testi senaryosunda protobuf mesajlarından alanları kalıcı olarak kaldırırken geriye dönük uyumluluğu nasıl sağlarsınız?
Adaylar genellikle sadece alan satırını .proto dosyasından silmeyi önerir. Doğru uygulama, alan numarasının gelecekteki yeniden kullanımını önlemek için reserved anahtar kelimesinin kullanılmasını ve silinmeden önce en az bir ana sürüm döngüsü boyunca alanın kullanılmaktan kaldırılmasını sağlamak için [deprecated=true] notasyonu ile işaretlenmesini gerektirir. Sözleşme testleri, kaldırılan alanların hata ayıklama hatalarına neden olmadan sıfır değerlerine veya açık varsayılanlara dönebilmesi (ileriye dönük uyumluluk) için, eski tüketicilerin yeni mesajları ayrıştırabildiğini doğrulamalıdır. Ayrıca, testler, söz konusu olan rezerve edilmeden kaldırılan alanlara karşı çıkan yeni bir alanın herhangi bir örneğinin Protobuf derleyicisi tarafından reddedildiğini doğrulamalıdır; bu genellikle buf lint kuralları PROTO3_FIELDS_NOT_RESERVED ve kaldırılan alanlar için karşılık gelen rezervasyon bildirileri tarayan özelleştirilmiş CI kapıları aracılığıyla sağlanır.
Protobuf sözleşme evriminde alan numaralarının ve alan isimlerinin önemi nedir ve bu ayrım otomatik test stratejilerini nasıl etkiler?
Birçok aday alan isimlerine odaklanır çünkü insan okunabilir JSON temsillerinde veya hata ayıklama araçlarında görünür. İkili seri hale getirmede, alan numaraları (etiketler) tek önemli belirleyicilerdir; "customer_id"'yi "user_id" olarak yeniden adlandırmak, ikili uyumluluğu korur, ancak etiket 1'i etiket 2'ye değiştirmek, tüm mevcut tüketicileri bozar. Bu nedenle, otomatik testler etiket değişmezliğini isim stabilitesine göre önceliklendirmelidir. Stratejiler, özellikle alan etiket değişiklikleri için buf kırıcı kurallarını uygulamayı, ikili seri hale getirme formatı (kullanarak hex dumps veya protobuf-text-format) üzerinde doğrulama yapmayı ve gRPC yansıma hizmetlerinin sürümlere göre tutarlı alan numaraları döndürdüğünü doğrulamayı içermelidir. Testler ayrıca, isimlerin önemli olduğu JSON transcodlama senaryolarını (yaygın olarak Envoy veya gRPC-Gateway içinde) kapsamalı ve REST-gRPC çeviri katmanları için ayrı bir doğrulama gerektirmelidir.
gRPC akış yöntemlerini (sunucu tarafı, istemci tarafı ve çift yönlü) sözleşme testinde tekil RPC yöntemlerine göre nasıl test edersiniz?
Tekil yöntemler, tek istek/cevap yüklerini doğrularken, akış, mesaj sırası, akış kontrolü (geri basınç) ve bağlantı yaşam döngüsü yönetimi etrafında karmaşıklıklar getirir. Sunucu tarafı akışı için, sözleşme testleri tüketicilerin kısmi akış hatalarını nasıl ele aldığını ve doğru context cancellation yayılımını uyguladığını doğrulamalıdır. İstemci tarafı akışı için, testler sunucuların doğru şekilde mesajları biriktirdiğini ve akış sona erme (yarım kapama) olaylarını nasıl ele aldığını doğrulamalıdır. Çift yönlü akış, sırayla karıştırılmış mesaj değişimi ve uzun ömürlü bağlantılar için zaman aşımı yönetimini test etmeyi gerektirir. Uygulama, manuel doğrulama için gRPCurl kullanma, akış verimliliğini yük test etmek için ghz kullanma ve mesaj dizilerini kaydetmek için Pact v4 (akışı destekleyen) kullanmayı içerir. Kritik olarak gözden kaçırılan yönler, akışlar anormal şekilde sona erdiğinde kaynak sızıntılarını test etme (aktif akış sayısını gösteren Prometheus/grpc istemci metrikleri ile doğrulanmış) ve zaman aşımlarının akış bağlamında doğru çalıştığından emin olmaktır.