gRPC: Servisler Arası Hızlı İletişim Çerçevesi

gRPC nedir?

gRPC, bir servisin başka bir makinedeki servisin işlevini sanki yerel bir fonksiyonmuş gibi çağırmasını sağlayan açık kaynaklı bir uzaktan yordam çağrısı (RPC) çerçevesidir. Ağ bağlantısı, veriyi serileştirme ve hata iletimi gibi ayrıntıları çerçeve üstlenir; geliştirici yalnızca çağırdığı yöntemin adına, aldığı parametrelere ve döndürdüğü sonuca odaklanır. Çerçeve Google tarafından geliştirilmiştir ve birçok programlama dili için istemci ile sunucu kodu üretebilir.

Kavramın özü şudur: iletişim bir sözleşmeyle başlar. Hangi yöntemlerin bulunduğu, hangi mesajları aldığı ve hangi mesajları döndürdüğü önceden tanımlanır; taraflar aynı sözleşmeden kod üretir. Bu yüzden gRPC özellikle mikroservis mimarilerinde, servislerin kendi aralarındaki iç trafikte ve farklı dillerde yazılmış servislerin birlikte çalışması gereken yerlerde tercih edilir.

gRPC nasıl çalışır: Protocol Buffers ve HTTP/2

Sözleşme, .proto uzantılı bir dosyada Protocol Buffers diliyle yazılır. Dosyada mesaj tipleri, alanları ve servisin sunduğu yöntemler tanımlanır. Bir derleyici bu dosyadan seçtiğiniz dilde istemci taslağını ve sunucu iskeletini üretir. Sunucu tarafında yalnızca iş mantığını yazarsınız; istemci tarafında ise uzak yöntemi normal bir fonksiyon gibi çağırırsınız.

Mesajlar Protocol Buffers ile ikili biçimde serileştirilir. Alan adları yerine alan numaraları taşındığı için JSON gibi metin biçimlerine göre daha küçük yer kaplar ve ayrıştırması daha ucuzdur. Taşıma katmanı HTTP/2'dir: tek bir bağlantı üzerinde eşzamanlı çok sayıda istek yürütülebilir, başlıklar sıkıştırılır ve veri çift yönde akabilir. Bağlantı açma maliyeti bu sayede azalır ve uzun ömürlü bağlantılar üzerinden akış mümkün olur.

gRPC çağrı desenleri nelerdir?

gRPC yalnızca istek-yanıt çiftiyle sınırlı değildir. Aynı sözleşme içinde farklı çağrı desenleri tanımlanabilir:

• Tekil çağrı (unary): istemci tek bir istek gönderir, sunucu tek bir yanıt döndürür. REST'e en yakın desendir.
• Sunucu akışı: istemci bir istek gönderir, sunucu parça parça birçok yanıt iletir. Örneğin bir raporun satırlarını sırayla göndermek.
• İstemci akışı: istemci birçok mesaj gönderir, sunucu hepsi bittiğinde tek bir yanıt verir. Örneğin sensör ölçümlerini toplu yüklemek.
• Çift yönlü akış: taraflar bağımsız olarak mesaj gönderir. Sohbet ve canlı bildirim gibi senaryolarda kullanılır.

Akış desenleri, istemcinin sürekli sorgu atması (polling) gerektiren birçok durumu ortadan kaldırır. Her çağrıya bir son tarih (deadline) tanımlanabilir; süre dolduğunda hem istemci hem sunucu çağrıyı iptal eder, böylece bir servisin yavaşlaması zincirleme bekleyişe dönüşmez.

gRPC ile REST arasındaki farklar nelerdir?

Ölçüt: Sözleşme. gRPC: .proto dosyası zorunludur ve kod bu dosyadan üretilir. REST: OpenAPI gibi bir tanım isteğe bağlıdır, dokümantasyon olarak kalabilir.

Ölçüt: Veri biçimi. gRPC: ikili Protocol Buffers. REST: genellikle okunabilir JSON.

Ölçüt: Akış. gRPC: sunucu, istemci ve çift yönlü akış yerleşik gelir. REST: akış için ek çözümler gerekir.

Ölçüt: Tarayıcı desteği. gRPC: tarayıcılar HTTP/2 üzerindeki gRPC çağrısını doğrudan yapamaz; gRPC-Web ya da bir ağ geçidi gerekir. REST: her tarayıcı ve istemci doğrudan çağırabilir.

Ölçüt: Hata ayıklama. gRPC: ikili içerik elle okunamaz, özel araçlar gerekir. REST: bir tarayıcı ya da basit bir komutla denenebilir.

Ölçüt: Önbellekleme. gRPC: HTTP önbellek altyapısından kolay yararlanılamaz. REST: GET isteklerinde ara katmanlarda önbellek kullanılabilir.

Pratikte yaklaşımlar birlikte kullanılır: dışarıya açılan genel API REST olarak sunulur, servisler arası iç iletişim gRPC ile yürütülür. Bir API ağ geçidi bu yaklaşımları birbirine çevirebilir.

Küçük bir örnek: sipariş servisi stok servisini çağırıyor

Örneğin bir e-ticaret sisteminde sipariş servisi, ürünün stokta olup olmadığını stok servisine sormak istiyor. Stok servisinin .proto dosyasında bir stok sorgulama yöntemi, ürün kodunu taşıyan bir istek mesajı ve eldeki miktarı taşıyan bir yanıt mesajı tanımlıdır. Sipariş servisi Java, stok servisi Go ile yazılmış olsa bile ikisi de aynı dosyadan kod üretir.

Sipariş servisi stok yöntemini çağırırken kısa bir son tarih verir. Stok servisi yavaşlarsa çağrı kontrollü biçimde hata kodu ile döner ve sipariş servisi yeniden deneme ya da alternatif yanıt kararını verir. Stok değişimlerini canlı izlemek isteyen bir panel ise aynı servisten sunucu akışı ile güncellemeleri sürekli alabilir.

gRPC ne zaman tercih edilmez, sık yapılan hatalar nelerdir?

Dışarıdaki geliştiricilere açılan, tarayıcıdan doğrudan çağrılan ya da basit entegrasyonların yoğun olduğu genel API'lerde REST daha pratik olabilir. Hata ayıklamanın kolaylığı ve herkesin bildiği bir yapı, ham hızdan daha değerli olabilir.

Sık yapılan hatalar şunlardır: • Çağrılara son tarih koymamak; yavaşlayan bir servis tüm zinciri bekletir. • Yayına çıkmış bir mesajdaki alan numarasını değiştirmek ya da başka alana vermek; eski istemciler yanlış veri okur. Alanlar eklenir, kullanım dışı bırakılır, numaraları yeniden kullanılmaz. • Hata durumlarını yalnızca genel bir hata mesajıyla bildirmek; gRPC'nin standart durum kodları anlamlı biçimde kullanılmalıdır. • Uzun ömürlü bağlantılar yüzünden yük dengelemeyi hesaba katmamak; bağlantı düzeyinde dengeleme isteklerin eşit dağılmasını sağlamayabilir. • Güvenlik ve kimlik doğrulamayı sonraya bırakmak; interceptor adı verilen ara katmanlar bu işi tek noktada çözer.

Bu kavram Mindset programlarında nerede çalışılır?

Mindset kataloğundaki gRPC ile Yüksek Performanslı Servis İletişimi eğitiminin modül başlıkları bu kavramın bileşenlerini izler: gRPC mimarisi ve Protocol Buffers, çağrı desenleri ve servis geliştirme, hata yönetimi ile son tarih ve dayanıklılık, interceptor ile güvenlik ve kimlik doğrulama, performans ile yük dengeleme ve ölçekleme, gözlemlenebilirlik ile test ve entegrasyon.