gRPC Nedir? Ne Amaçla ve Nasıl Kullanılır?

Merhaba,

Gün, dağınık mimarilerin günü. Koca dev yazılımların, tek bir bütünden ziyade, onlarca parçanın(servis) bir araya gelmesiyle oluştuğu gün. İhtiyaçların değil, yaklaşımların değişikliğe uğradığı, bu değişikliklerden meydana gelen yeni şartların getirdiği zaruriyetlerin yaşandığı gün. Monolitik diyarlardan farklı bir iklim olan mikro servislere göçlerin yoğun olduğu gün.

Evet… Microservice yaklaşımının revaçta olduğu şu günlerde geliştirilen uygulamaların farklı işlevlerini yürüten organ misali servisleri arasında iletişimi sağlayabilmek için birbirleri arasında birçok avantaj ve dezavantaja sahip olan farklı yol ve yordamlar tartışılmaktadır. Kimi der servisler arası iletişim request-driven mimari ile olsun kimi event-driven mimari ile, kimi ise her ikisini harmanlayalım ve hibrid mimari yaklaşımı ile haberleşmeyi sağlayalım der. Bu söylentilerin arasında son zamanlarda yükselen bir ses işitilmektedir, gRPC. Esasında binary-message exchange altyapısı sunan ve böylece düşük CPU tüketimi ile yüksek performans gösterebilen gRPC, cihazlar ve servisler arası iletişimde tercih edilmeye yatkın son zamanların en popüler kütüphanesidir. Bu içeriğimizde bu kütüphaneyi derinlemesine teorik olarak inceliyor olacağız ve microservices mimariler açısından ne gibi temaslar kurabileceğimiz üzerine izahatlerde bulunuyor olacağız. Hadi buyrun çağa ayak uyduralım…

gRPC Nedir?

Google tarafından geliştirilmiş open source Remote-Procedure-Call(RPC) kütüphanesidir. Hemen akıllara gelebilecek olan Peki hocam o ‘g’ ne anlama geliyor? sorusunu cevaplayalım. Bu ‘g’ harfi geliştiricisi olan Google gibi düşünülebilir lakin değildir. Esasında bu ‘g’ harfi Google tarafından çıkarılan her bir sürüm için baş harfi ‘g’ ile başlayan ayrı anlamı ifade etmektedir. Bu anlamları şuradan görebilirsiniz 🙂

İlerlemeden Remote-Procedure-Call(RPC)‘ın da ne demek olduğuna değinmekte fayda olduğu kanaatindeyim. RPC; ‘Uzak Yordam Çağrısı’dır. Tabi ki de RPC için değineceğimiz Türkçe meali olarak ne olduğu değil, teknik olarak ne olduğudur.

RPC; uzak sunucudaki metotları sanki kendi ortamının birer parçasıymış gibi çağırabilen sistemdir.

gRPC, transport/iletişim/veri iletimi için Http/2 protokolünü kullanmaktadır. Burada gRPC’nin faydalarını anlayabilmek için öncelikle Http/2’nin getirilerini anlamak gerekmektedir.

gRPC; transfer edilecek dataları Google tarafından geliştirilmiş, binary serialization protokolü olan Protocol Buffers‘ı kullanarak iletmekte ve serialize ve deserialize etmektedir. Yani data’yı JSON yahut XML’de olduğu gibi text yerine binary formata çevirmekte ve diğer formatlara göre hatırı sayılır miktarda hız ve performans kazanabilmektedir.

gRPC; CPU, memory ve bandwidth kullanımının önemli ve kritik olduğu uygulamalarda JSON yerine binary formatta çalıştığı için tercih edilebilecek bir teknolojidir.

Hocam binary formatta veri insan tarafından okunabilir olmamaktadır? Evet… Belki JSON gibi insan seviyesinde okunabilir bir format değildir ama transport sürecinde bu formatta veri daha hızlı işlenebilmektedir. Ayrıca herhangi bir string parsing işleminin olmaması memory kullanımı açısından da ekstradan katkı sağlamaktadır. Tabi ihtiyaç doğrultusunda gRPC, JSON gibi text tabanlı formatları da destekleyebilmektedir.

Protocol Buffers’ın kısa adı Protobuf‘tur.

Neden gRPC Kullanmalıyız?

Günümüzde yoğun bir şekilde uygulama geliştirme yaklaşımı olarak benimsenen microservice yapılanması, sistemin gelişim sürecini her ne kadar dinamize etsede bir o kadar da servisler arası iletişim hızını monolithic yaklaşıma binaen oldukça düşürmektedir. Bu durum ise bizlere klasik Restful mimarisinden ziyade daha hızlı bir altyapı ihtiyacı hissettirmekte ve mümkün mertebe iletişim hızımızı güçlendirecek farklı teknolojilere yönlendirmektedir. Nihayetinde Restful service’ler çoğunlukla external(dış) bir client tarafından consume edilmek için daha uygun bir fıtrata sahiptir ve text-based messsaging’e dayandığı için internal(iç) service iletişimine pekte yatkın bir seçenek değildir. Haliyle dış dünya tarafından tüketilmeyen internal projelerde Restful’dan ziyade binary-based messaging’i benimseyen gRPC’yi kullanmamız, bizleri iletişim hızı açısından monolithic’e en yakın seviyeye çıkarmaktadır diyebiliriz.

gRPC sayesinde Restfull’un etkisini yitirdiğini düşünmek yanlış olacaktır. En nihayetinde external client’lar tarafından consume edilen uygulamalarda Restfull mimarisi hala en kolay, kullanışlı ve efektif çözümdür.

Yukarıda ele alınan durumdan yola çıkarak IoT(Internet of Things) çağında cihazlar arası iletişim içinde gRPC iyi bir seçenek diyebiliriz.

Ayrıca gRPC dilden bağımsız birbiriyle performanslı iletişim kurabilen uygulamalar geliştirmemizi sağlayabilmekte ve bundan daha da mühim olan birden fazla dil tarafından desteklenebilmektedir. Desteklenen diller; C#, C++, Java, Php, Python vs. şeklinde özetlenebilir. Tüm dilleri görmek için bknz : https://www.grpc.io/docs/languages/

gRPC Avantajları Nelerdir?

• Http/1’e nazaran Http/2’yi kullanmaktadır. Böylece Http/2 stream desteği verebilmektedir.
• TCP socket haberleşmesi sağlayabilmektedir.
• Http/2 sayesinde binary serialization kullanmaktadır. Böylece text-based mesajlaşmaya nazaran oldukça hızlıdır.
• Yapılan optimizasyonlar neticesinde Http/1 kullanan Restfull servislere nazaran 2.5 kat daha hızlı olduğu tespit edilmiştir. Http/1 ile Http/2 arasındaki hız farkını daha net görebilmek için http2demo.io adresindeki demoyu inceleyebilirsiniz.
• Aynı bağlantı üzerinden birden fazla paralel request desteği sağlanmaktadır. Http/1’de ise bir request’e nazaran bir response söz konusudur.
• Client ile server arasında çift yönlü iletişim vardır.
• Moderndir.
• Yukarıdaki özelliklerle birlikte birçok niteliğinden dolayı yüksek performanslıdır.
• Default olarak Protocol Buffers kullanarak dilden bağımsız olacak şekilde birçok uygulama tarafından kullanılabilmektedir.

Protocol Buffers Nedir(Protobuf)?

Google’ın geliştirdiği ve hala geliştirmekte olduğu bir binary serialization protokolüdür. Özünde bir Arayüz Tanımlama Dili/Interface Definition Language(IDE)’dir. Kullanılan platform ve programlama dili farkını gözetmeksizin, client ve server arasında haberleşmeyi sağlayabilmek için IDL compiler sayesinde her iki tarafa da(client ve server) ‘stub’ ismi verilen gerekli arayüzlerin oluşturulmasını sağlayan bir dildir. İçerik olarak gRPC servis tanımlarını ve import edilen paket tanımlarını ve iletişim sürecinde kullanılacak olan mesaj tanımlarını tutmaktadır.

gRPC vs Restfull

• Rest servislerde yapılan request neticesinde response’un alınabilmesi için gönderilen tüm dataların topyekün işlenmesi gerekmektedir. Halbuki gRPC’de ise yapılan request neticesinde response, tüm dataların işlenmesini beklemeksizin alınabilmekte ve veriler parça parça işlendikçe bütünden bağımsız bir şekilde response edilmektedir. Bu durum gRPC’de Data Stream olarak nitelendirilmektedir.
• gRPC isteklerinde encoding ve decoding işlemleri istemcide gerçekleştirilmektedir. Böylece bu işlemlerin yükü serverdan arındırılmış olmaktadır.
• gRPC’de farklı platformlar ve diller arası tür dönüşümleri için serialization ve deserialization yapmaya gerek yoktur. Bunun nedeni protokol üzerinde veri tipinin önceden belirlenmiş olmasıdır ve hedef dile ait kodun ilgili protokol üzerinden(protobuf) üretilmesindendir. Nihayetinde hem client’ın hem de server’ın kodlarını inşa eden protobuf protokolü her iki uygulamanın da diline uygun servisleri inşa edecek ve böylece iletişim sürecinde ekstra bir dönüşüme gerek duyulmayacaktır.
• gRPC avantajları olduğu kadar şimdilik dezavantajlara da sahiptir. IIS ve Azure App Service üzerinde barındırılamamakta lakin Kestrel tarafından desteklenmektedir.
• Restfull servislerde tarayıcı desteği varken, gRPC’de kısmi bir destek söz konusudur.

Ayrıca gRPC ile API arasındaki temel farkları aşağıdaki tabloda ele almakta fayda görmekteyim:

gRPC’de server ve client arasındaki haberleşme için iletilecek mesajın türünü ve iletim yöntemini bildirecek bir servis sözleşmesi gerekmektedir. Bu sözleşme her iki uygulamada da(client ve server) ‘proto’ dosyası olarak ayarlanmalıdır.

gRPC Konseptleri ve Client/Server Arasındaki İletişim Tipleri Nelerdir?

gRPC, client ile server arasında yapısal olarak ‘Unary‘, ‘Server Streaming‘, ‘Client Streaming‘ ve ‘Bi-directional Streaming‘ olmak üzere dört farklı iletişim tipi sunmaktadır. Şimdi gelin bu dört iletişim tipini teoride inceleyelim;

• Unary
  Client’ın server’a tek bir istek gönderdiği ve normal bir işlev çağrısı gibi tek bir yanıt geri aldığı RPC türüdür.
   
   
   
   
• Server Streaming
  Client’ın servar’a tek bir istek gönderdiği ve server’ın stream dönmeye başladığı RPC türüdür.
   
   
   
   
• Client Streaming
  Client’ın server’a stream mesaj gönderdiği ve server’ın tek bir response döndürüğü RPC türüdür. Yani client birden çok mesaj gönderiyor, server buna karşılık tek bir cevap döndürüyor. Anlayacağınız Server Streaming’in tam tersi bir akış söz konusudur.
   
• Bi-directional Streaming
  Client’ın server’a stream mesaj gönderdiği ve server’ın stream response döndürdüğü RPC türüdür. Yani hem client hem de server karşılıklı message streaming gerçekleştirmektedir ve böylece birden çok mesaj transferi sağlanabilmektedir. bknz: Duplex messaging

gRPC Yaşam Döngüsü(Lifecycle)

gRPC’nin yaşam döngüsünü anlayabilmek için aşağıdaki görüntüyü inceleyelim;

Görüldüğü üzere Client ve Server arasında yapılacak veri iletiminin kontratı ‘Protobuf’ dosyası vasıtasıyla gerçekleştirilmekte ve ilgili uygulamalar derlendiği vakit protoc compiler sayesinde tanıma uygun servis türleri generate edilebilmektedir. Burada dilden bağımsız bir oluşum süreci olduğuna dikkatinizi çekerim. Tabi, haberleşecek uygulamaların aralarında kontratı sağlayabilmek için her iki uygulamada da aynı içeriğe sahip ‘Protobuf’ dosyası olması gerekmektedir. Aksi taktirde ev sahibinde satış sözleşmesi, alıcıda ise kira sözleşme gibi tutarsız bir durum söz konusu olacak ve ortada kontratın bir hükmü kalmayacaktır.

Ayrıca gRPC kütüphanesi client ile server arasındaki haberleşme esnasında direkt olarak request’i eriştirmeden önce, server’a tetiklenmek istenen metot adı ve meta data vs. gibi bilgileri göndermekte ve server bu gelen bilgilere karşılık meta data bilgilerini dönmektedir. Yani bir nebze ilgili kontrat doğrulanmakta ve bu süreçten sonra client’ın gönderdiği asıl request server’a gönderilecek ve başarılıysa response elde edilecektir.

Nihai olarak;
Microservices yapılanmalarda uygulamaların hızlarını monolithic seviyeye indirgeyebilmek ve ilgili yaklaşımın dezavantajlarını törpüleyerek tercih edilebilirliğini daha da arttırabilmek için gRPC biçilmiş kaftandır diyebiliriz. Bu içeriğimizde gRPC üzerine uzun ve tek soluklu teorik incelemede bulunduk. Sonraki yazılarımızda bu kütüphanenin client ile server arasındaki iletişim tiplerini tek tek ele alıyor olacağız. O halde fazla arayı soğutmadan yeni makalenin ilk mürekkeplerini akıtmaya başlayalım 🙂

İlgilenenlerin faydalanması dileğiyle…
Sonraki yazılarımda görüşmek üzere…
İyi çalışmalar…