gRPC hizmetlerini HTTP API’leriyle karşılaştırma

Yayınlayan James Newton-King

Bu makalede gRPC hizmetlerinin JSON (ASP.NET Core web API'leri dahil) ile HTTP API'leriyle karşılaştırması açıklanmaktadır. Uygulamanız için API sağlamak için kullanılan teknoloji önemli bir seçenektir ve gRPC, HTTP API'lerine kıyasla benzersiz avantajlar sunar. Bu makalede gRPC'nin güçlü ve zayıf yönleri ele alınmaktadır ve gRPC'yi diğer teknolojilere göre kullanma senaryoları önermektedir.

Üst düzey karşılaştırma

Aşağıdaki tabloda gRPC ile HTTP API'leri arasındaki özelliklerin JSON ile üst düzey bir karşılaştırması sunulmaktadır.

gRPC güçlü yönleri

Performans

gRPC iletileri, verimli bir ikili ileti biçimi olan Protobuf kullanılarak serileştirilir. Protobuf, sunucuda ve istemcide çok hızlı bir şekilde seri hale getirmektedir. Protobuf serileştirmesi, mobil uygulamalar gibi sınırlı bant genişliği senaryolarında önemli olan küçük ileti yükleriyle sonuçlanır.

gRPC, HTTP 1.x'e göre önemli performans avantajları sağlayan büyük bir HTTP düzeltmesi olan HTTP/2 için tasarlanmıştır:

• İkili çerçeveleme ve sıkıştırma. HTTP/2 protokolü hem gönderme hem de almada kompakt ve verimlidir.
• Tek bir TCP bağlantısı üzerinden birden çok HTTP/2 çağrısının katlanması. Çoğullama, satır başı engellemeyi ortadan kaldırır.

HTTP/2, gRPC'ye özel değildir. JSON içeren HTTP API'leri de dahil olmak üzere birçok istek türü HTTP/2 kullanabilir ve performans geliştirmelerinden yararlanabilir.

Kod oluşturma

Tüm gRPC çerçeveleri, kod oluşturma için birinci sınıf destek sağlar. gRPC geliştirmesinin temel dosyası, gRPC hizmetlerinin ve iletilerinin sözleşmesini tanımlayan dosyadır.proto. Bu dosyadan gRPC çerçeveleri bir hizmet temel sınıfı, iletileri ve eksiksiz bir istemci oluşturur.

Sunucu ve istemci arasında dosya paylaşılarak .proto , iletiler ve istemci kodu uçtan uca oluşturulabilir. İstemcinin kod oluşturma işlemi, istemci ve sunucudaki iletilerin yinelenmesini ortadan kaldırır ve sizin için kesin olarak belirlenmiş bir istemci oluşturur. İstemci yazmak zorunda kalmak, birçok hizmeti olan uygulamalarda önemli geliştirme süresi kazandırır.

Katı belirtim

JSON ile HTTP API için resmi bir belirtim yoktur. Geliştiriciler URL'lerin, HTTP fiillerinin ve yanıt kodlarının en iyi biçimini tartışır.

gRPC belirtimi, bir gRPC hizmetinin izlemesi gereken biçim hakkında açıklayıcıdır. gRPC, tartışmayı ortadan kaldırır ve gRPC platformlar ve uygulamalar arasında tutarlı olduğundan geliştirici zamanından tasarruf sağlar.

Akışlar

HTTP/2, uzun ömürlü, gerçek zamanlı iletişim akışları için bir temel sağlar. gRPC, HTTP/2 üzerinden akış için birinci sınıf destek sağlar.

gRPC hizmeti tüm akış bileşimlerini destekler:

• Birli (akış yok)
• Sunucudan istemciye akış
• İstemciden sunucuya akış
• çift yönlü akış

Son tarih/zaman aşımları ve iptal

gRPC istemcilerin bir RPC'nin tamamlanmasını ne kadar süre beklemeye istekli olduklarını belirtmesine olanak tanır. Son tarih sunucuya gönderilir ve son tarihi aşarsa hangi eylemin gerçekleştirileceğine sunucu karar verebilir. Örneğin, sunucu zaman aşımında devam eden gRPC/HTTP/veritabanı isteklerini iptal edebilir.

Son tarihi ve iptali alt gRPC çağrıları aracılığıyla yaymak, kaynak kullanım sınırlarının uygulanmasına yardımcı olur.

gRPC önerilen senaryolar

gRPC aşağıdaki senaryolar için çok uygundur:

• Mikro hizmetler: gRPC, düşük gecikme süresi ve yüksek aktarım hızı iletişimi için tasarlanmıştır. gRPC, verimliliğin kritik olduğu hafif mikro hizmetler için mükemmeldir.
• Noktadan noktaya gerçek zamanlı iletişim: gRPC, çift yönlü akış için mükemmel desteğe sahiptir. gRPC hizmetleri, yoklama yapmadan iletileri gerçek zamanlı olarak gönderebilir.
• Çok teknolojili ortamlar: gRPC araçları tüm popüler geliştirme dillerini destekler ve bu da gRPC'yi çok dilli ortamlar için iyi bir seçim haline getirir.
• Ağ kısıtlanmış ortamları: gRPC iletileri basit bir ileti biçimi olan Protobuf ile serileştirilir. gRPC iletisi her zaman eşdeğer bir JSON iletisinden küçüktür.
• İşlemler arası iletişim (IPC): Unix etki alanı yuvaları ve adlandırılmış kanallar gibi IPC aktarımları, aynı makinedeki uygulamalar arasında iletişim kurmak için gRPC ile kullanılabilir. Daha fazla bilgi için bkz . gRPC ile işlemler arası iletişim.

gRPC zayıflıkları

Sınırlı tarayıcı desteği

Bugün bir tarayıcıdan gRPC hizmetini doğrudan çağırmak mümkün değildir. gRPC, HTTP/2 özelliklerini yoğun bir şekilde kullanır ve hiçbir tarayıcı, gRPC istemcisini desteklemek için web istekleri üzerinde gereken denetim düzeyini sağlamaz. Örneğin, tarayıcılar çağıranın HTTP/2 kullanılmasını gerektirmesine veya temel HTTP/2 çerçevelerine erişim sağlamasına izin vermez.

ASP.NET Core'da gRPC, tarayıcıyla uyumlu iki çözüm sunar:

• gRPC-Web , tarayıcı uygulamalarının gRPC-Web istemcisi ve Protobuf ile gRPC hizmetlerini çağırmasına olanak tanır. gRPC-Web, tarayıcı uygulamasının bir gRPC istemcisi oluşturmasını gerektirir. gRPC-Web, tarayıcı uygulamalarının gRPC'nin yüksek performanslı ve düşük ağ kullanımından yararlanmasını sağlar.

  .NET, gRPC-Web için yerleşik desteğe sahiptir. Daha fazla bilgi için bkz . ASP.NET Core gRPC uygulamalarında gRPC-Web.

• gRPC JSON kodlama, tarayıcı uygulamalarının gRPC hizmetlerini JSON ile RESTful API'leriymiş gibi çağırmasına olanak tanır. Tarayıcı uygulamasının gRPC istemcisi oluşturması veya gRPC hakkında bir şey bilmesi gerekmez. RESTful API'leri, http meta verileriyle dosyaya .proto ek açıklama eklenerek gRPC hizmetlerinden otomatik olarak oluşturulabilir. Kod dönüştürme, bir uygulamanın her ikisi için ayrı hizmetler oluşturma çabasını yinelemeden hem gRPC hem de JSON web API'lerini desteklemesine olanak tanır.

  .NET, gRPC hizmetlerinden JSON web API'leri oluşturmak için yerleşik desteğe sahiptir. Daha fazla bilgi için bkz . ASP.NET Core gRPC uygulamalarında gRPC JSON kodlaması dönüştürme.

İnsan tarafından okunamaz

HTTP API istekleri metin olarak gönderilir ve insanlar tarafından okunabilir ve oluşturulabilir.

gRPC iletileri varsayılan olarak Protobuf ile kodlanır. Protobuf gönderip almak için verimli olsa da ikili biçimi insan tarafından okunamaz. Protobuf, düzgün seri durumdan çıkarmak için iletinin .proto dosyada belirtilen arabirim açıklamasını gerektirir. Kablodaki Protobuf yüklerini analiz etmek ve istekleri el ile oluşturmak için ek araçlar gereklidir.

İkili Protobuf iletilerine yardımcı olmak için sunucu yansıması ve gRPC komut satırı aracı gibi özellikler mevcuttur. Ayrıca, Protobuf iletileri JSON'a ve JSON'dan dönüştürmeyi destekler. Yerleşik JSON dönüştürmesi, hata ayıklama sırasında Protobuf iletilerini okunabilir ve okunabilir biçimden dönüştürmek için verimli bir yol sağlar.

Alternatif çerçeve senaryoları

Aşağıdaki senaryolarda gRPC üzerinden diğer çerçeveler önerilir:

• Tarayıcı tarafından erişilebilen API'ler: gRPC tarayıcıda tam olarak desteklenmez. gRPC-Web tarayıcı desteği sunabilir, ancak sınırlamaları vardır ve bir sunucu ara sunucusu sunar.
• Gerçek zamanlı iletişim yayınlama: gRPC, akış yoluyla gerçek zamanlı iletişimi destekler, ancak kayıtlı bağlantılara ileti yayınlama kavramı mevcut değildir. Örneğin, sohbet odasındaki tüm istemcilere yeni sohbet iletilerinin gönderilmesi gereken bir sohbet odası senaryosunda, istemciye tek tek yeni sohbet iletilerinin akışını yapmak için her gRPC çağrısı gereklidir. SignalR bu senaryo için kullanışlı bir çerçevedir. SignalR kalıcı bağlantılar kavramına ve iletileri yayınlamaya yönelik yerleşik desteğe sahiptir.

Ek kaynaklar

• ASP.NET Core'de .NET Core gRPC istemcisi ve sunucusu oluşturma
• .NET üzerinde gRPC'ye genel bakış
• C ile gRPC hizmetleri#
• .NET için gRPC'yi C çekirdeğinden gRPC'ye geçirme