gRPC'ün derlenen sözleşmeleri, REST'in gözünden kaçan mikro servis hatalarını yakalar

gRPC'ün hedeflediği hata modu

dev.to'da yazı yayımlayan bir geliştirici — metin ilk olarak yazarın kendi sitesi olan juanchi.dev'de yayımlandı — birçok mikro servis ekibinin tanıyacağı bir senaryoyla başlıyor: on beş servis, her biri kendi JSON adlandırma kurallarıyla kendi REST API'sini sunuyor, Swagger dokümantasyonu bayatlıyor ve HTTP istemcileri ya elle yazılmış ya da OpenAPI'den gevşekçe üretilmiş durumda. Yazara göre bu kurulumda, payments servisindeki bir alan değişikliğini üç aşağı yönlü ekip yalnızca üretim ortamı çöktüğünde fark ediyor. Buna saniyede on bin çağrılık servisler arası trafiği ve HTTP/1.1 üzerindeki JSON yükünü eklediğinizde, ek maliyet altyapı faturasında görünmeye başlıyor. Yazarın iddiası, gRPC'ün tam olarak bu acı için var olduğu: Google, onu açık kaynak olarak yayımlamadan önce dahili servisler arası iletişim için geliştirdi ve bundan çok daha küçük ölçekler için pek uygun değil.

Derlenen sözleşmeler

gRPC, HTTP/2 üzerinde çalışan ve varsayılan serileştirme olarak Protocol Buffers kullanan bir uzaktan prosedür çağrısı (RPC) çerçevesidir. Endpoint yayımlayıp her istemcinin kendi isteklerini oluşturmasına izin vermek yerine, ekip bir servis ve mesajlarını bildiren bir .proto dosyası yazar ve protobuf derleyicisi (protoc) bu tek tanımdan Go, Java, Python, C++ veya Node için serileştirme sınıflarıyla birlikte istemci ve sunucu stub'ları üretir. Geçmişi Java olan yazar, bu düzenlemeyi WSDL'li SOAP'a benzetiyor — tipli, sürümlenebilir sözleşmeler — ama XML'in yükü olmadan ve daha iyi performansla. Yazı, proto3 ile küçük bir orders servisini ve üretilen bir temel sınıfı genişleten bir Java uygulamasını adım adım ele alıyor; hiçbir yerde JSON yok: yükler ikili (binary) olarak taşınıyor. Pratik kazanç, alan adlarının ve tiplerin, biri güncellemeyi unutmuş bir dokümantasyon yerine üretilmiş kod tarafından zorunlu kılınması — uyumsuz bir değişiklik, üretim olayı yerine derleme hatası oluyor.

Değişen güvenle dile getirilen hız iddiaları

Yazının iki sürümü dev.to'da birbirinden saniyeler arayla yayımlandı; biri İspanyolca, biri İngilizce ve performans konusunu ne kadar kesin dile getirdiklerinde hafifçe ayrışıyorlar. İkisi de HTTP/2'ye tek bir TCP bağlantısı üzerinden istekleri çoklama, doğal çift yönlü akış (streaming) ve başlık sıkıştırması için itibar ediyor — gRPC'ün yoğun yük altında REST artı HTTP/1.1'i geçme eğiliminin yapısal nedenleri. Ancak İspanyolca özgün metin, bunu ölçülmüş bir sonuç olarak sunmayı açıkça reddediyor ve bunu yazarın yaptığı bir benchmark değil, gRPC projesi tarafından belgelenmiş bir tasarım avantajı olarak nitelendiriyor; İngilizce sürüm bu uyarıyı düşürüyor. JVM ekipleri için yazar, yerleşik Spring Boot desteği olarak grpc-spring-boot-starter'a işaret ediyor.

Yanlış araç olduğu durumlar

Yazı, tanıtım kadar karşı durumlar üzerine de emek harcıyor. Protobuf ve asenkron streaming modeli, tanıdık istek/yanıt düşünce tarzından farklı ve yazar, bunun gerçek bir sürtünme noktası olduğunu, birkaç saatlik okumayla aşılamayacağını söylüyor; takıma bağlı olduğu için bir sayı vermiyor. Hata ayıklama daha zahmetli, çünkü curl bir gRPC endpoint'ini çağıramıyor; trafiği incelemek grpcurl veya BloomRPC gibi araçlar gerektiriyor. Tarayıcı istemcileri, gRPC-Web artı bir ara proxy'e ihtiyaç duyuyor; bu da ek bir karmaşıklık katmanı. Üçüncü taraflarca tüketilen ve yığınları üzerinde kontrolünüzün olmadığı genel API'lar, OpenAPI'lı REST olarak daha dostane kalıyor. Ve iki üç düşük trafikli servisten oluşan bir sistem, muhtemelen ihtiyaç duymadığı karmaşıklığı üstleniyor — yazar orada REST'te kalmayı, ya da TypeScript monorepo'da tRPC'yi değerlendirmeyi öneriyor.

Neden önemli

Metin bir savunma yazısından çok bir karar prosedürü gibi okunuyor. Merkezî iddiası gRPC'ün ötesine genellenebilir: servis ve ekip sayısı arttıkça baskın risk tek bir endpoint değil, servisler arasında zorunlu kılınan bir uzlaşmanın yokluğudur. Sözleşmeyi bir derleyicinin denetlediği bir şeye dönüştürmek, entegrasyon hatalarının bütün bir sınıfını runtime'dan derleme zamanına taşıyor. Bedel açık — bir öğrenme eğrisi, daha zayıf bir tarayıcı hikâyesi, daha zor hata ayıklama — ve yazarın sonuç ödünleşimin yalnızca altta yatan sorun gerçekten mevcutken karşılığını vermesi: yoğun servisler arası trafik, güçlü sözleşmelere gerçek bir ihtiyaç ve giriş maliyetine hazırlıklı bir ekip. Yazarın belirttiği gibi, topluluk onayı size bir aracın kanıtlanmış olduğunu söyler, ekibinizin ona hazır olduğunu değil.