gRPC ve REST — Aynı Havale, İki Dil
Önce şunu oku: Servisler Arası İletişim Desenleri
30 saniyede özet
REST çoğu zaman JSON taşır: okunur, her yerden çağrılır ama alan adlarını her mesajda tekrar eder. gRPC protobuf taşır: küçük ve şemalıdır, alanları numarayla eşler. Ad mı numara mı sözleşmedir, onu bilmek kırılmaları önler.
Bir mektup yazarken her bilginin önüne ne olduğunu yazarsın: “tutar: 2500 lira”. Bir resmî form ise yalnızca numaralı kutulardan oluşur; 2 numaralı kutuya tutarı yazarsın. Mektubu herkes okur, form kısadır ama hangi kutunun ne olduğunu bilmek için şablon gerekir.
-
Bayt: Ödeme servisleri arasındaki çağrıları gRPC'ye taşıdık. Mesajlar yarı yarıya küçüldü!
-
Sen: Geçen hafta bir alanı yeniden numaralandırmıştınız, değil mi?
-
Bayt: Evet, düzen olsun diye. Şimdi bazı havalelerde alıcı IBAN'ı boş geliyor, hata da yok!
-
Bayt: Protobuf'ta sözleşme alanın adı değil, numarası. Gel, iki dilin kurallarına bakalım.
İki biçim, aynı veri
REST çağrıları çoğu zaman JSON taşır: {"amountKurus": 250000, …}. Her mesaj alan adlarını da taşır; okunur ve curl ile denenebilir.
gRPCHTTP/2 üzerinde çalışan, mesajları protobuf ile taşıyan uzak çağrı çerçevesi. Şemadan istemci ve sunucu kodu üretilir; akışları destekler.Sözlükte gör → ise protobufProtocol Buffers: alanları adla değil numarayla taşıyan ikili mesaj biçimi. Küçüktür ve şemayla okunur; numara bir kez verilir, değişmez.Sözlükte gör → taşır. Şemada her alanın bir numarası vardır ve kablodan yalnızca numara ile sıkıştırılmış değer geçer. Bizim havale JSON’da 89 bayt, protobuf’ta 41 bayt.
Kafam karıştı, daha basit anlat
JSON etiketleri de taşır ve okunur. Protobuf yalnızca numaraları taşır ve küçüktür.
Protobuf mesajı JSON'a göre neden genellikle daha küçüktür?
gRPC hangi taşıma protokolünü kullanır?
Sözleşme ad mı, numara mı?
Protobuf şemasında to_iban alanının numarası 4'ten 5'e değişti; eski istemciler güncellenmedi. Yeni sunucu bir havale gönderdiğinde eski istemci ne görür? Cevabı göster
Alıcı IBAN’ı boş görür, hata almaz. Eski istemci 5 numarayı tanımadığı için atlar; 4 numaralı alan da gelmediği için boş kalır.
Adım adım oku
- Mektupta her etiket yazılı; herkes okur ama uzun.
- Numaralı form kısa; okumak için şablon gerekir.
- Bilgi başka numaralı kutuya taşınırsa eski okuyucu boş kutuya bakar.
- Etiket mektubun, numara formun sözleşmesidir.
JSON alanları adla eşler: amountKurus adını amountMinor yaparsan eski istemci tutarı bulamaz. Protobuf alanları numarayla eşler: adı değiştirmek zararsızdır, numarayı değiştirmek ise veriyi sessizce kaybettirir.
Bu yüzden protobuf’ta kural nettir: bir numara bir kez verilir ve bir daha değişmez. Kaldırdığın alanın numarasını reserved yaparak yeniden kullanılmasını engellersin.
Kafam karıştı, daha basit anlat
JSON’da adı, protobuf’ta numarayı değiştirme. Yeni bir şey gerekiyorsa yeni bir alan ekle.
JSON API'de bir alanın adı değişti ve eski istemciler güncellenmedi. Ne olur?
Protobuf'ta bir alanın adı değişti, numarası aynı kaldı. Eski istemci ne görür?
Kendin gör
Aynı havale, iki protokol
Tohum 561478Oynat ya da adımla.
Şu an ne oldu?
Bir mesaj kaç bayt?
REST + JSON
Görevler0/3
Aynı havaleyi en az baytla gönderaçık
İpucu
Alan adlarını taşımayan biçim.
Hiç hata vermeden alıcı IBAN'ını kaybetaçık
İpucu
Protobuf'ta neyi asla değiştirmemelisin?
Bir alanın adını değiştirip eski istemciyi kıraçık
İpucu
Alanları adla eşleyen biçim.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. JSON mesajı 89 bayt.
- Protokolü gRPC yap. Aynı havale 41 bayt.
- “Bir alanın adını değiştirdi” seç. JSON’da eski istemci kırıldı, gRPC’de kırılmadı.
- “Numarasını değiştirdi” seç, gRPC’de kal. Hata yok ama IBAN kayboldu.
- “Tarayıcıdan fetch” seç. gRPC için gRPC-Web ve bir proxy gerekiyor.
Protobuf'ta to_iban alanı 4'ten 5'e taşındı. Eski istemci ne yaşar?
Bir tarayıcı uygulaması gRPC servisini çağırmak istiyor. Ne gerekir?
Tuzaklar
Tarayıcıdan doğrudan gRPC. Tarayıcılar yerel gRPC’nin ihtiyaç duyduğu HTTP/2 ayrıntılarına erişemez. gRPC-WebTarayıcıların gRPC servislerini çağırabilmesi için kullanılan uyarlama. Tarayıcı gRPC-Web konuşur, bir proxy onu gerçek gRPC'ye çevirir.Sözlükte gör → ve onu çeviren bir proxy gerekir; çoğu ekip dışarıya REST sunar.
Okunamayan mesajlar. Protobuf mesajını curl ya da log’da gözle okuyamazsın. grpcurl gibi araçlar ve şema dosyasının kendisi hata ayıklamanın parçası olur.
Zorunlu alan beklemek: protobuf 3’te gönderilmeyen bir alan varsayılan değerle (0, boş metin) okunur. “Tutar 0 mı, yoksa hiç gönderilmedi mi?” sorusunu şemada ayrıca çözmen gerekir.
Kafam karıştı, daha basit anlat
Tarayıcıya REST, içeride gRPC; okumak için araç kullan; varsayılan değeri eksik değerle karıştırma.
Protobuf'ta bir alanı kaldırırken numarasını ne yapmalısın?
Aşağıdaki örnek bir bankanın ödeme servisinden: protobuf şeması, kaldırılan alan için reserved, Spring ile gRPC servisi ve dışarıya açılan REST uç noktası.
Derinleş · Ödeme servisi: içeride gRPC, dışarıda REST 4 dosya · ~66 satır · ilk okumada atlayabilirsin
Kendini sına
Protobuf mesajı her seferinde alan adlarını da taşır.
Proto3'te amount alanı gönderilmezse alıcı ne görür?
Aklında kalacak üç şey
- 1 JSON her mesajda alan adlarını taşır ve insan okuyabilir. Protobuf yalnızca alan numaralarını ve sıkıştırılmış değerleri taşır; aynı havale 89 bayt yerine 41 bayt tutar.
- 2 JSON alanları adla, protobuf numarayla eşler. JSON'da ad değiştirmek eski istemciyi kırar; protobuf'ta ad değiştirmek zararsızdır ama numara değiştirmek veriyi sessizce kaybettirir.
- 3 Tarayıcı yerel gRPC konuşmaz; gRPC-Web ve bir proxy gerekir. Dışarıya REST, servisler arasında gRPC yaygın bir bölüşümdür.
4 kart sonraki derste seni bekliyor