Bir gRPC İncelemesi
- hacer_bakirci
- Dec 12, 2020
- 2 min read
Updated: Dec 23, 2020
gRPC açıkçası şu sıralar yeni duyduğum, mantık olarak aslında çok da yabancı olmadığımız Google'ın başlattığı ve sonra open-source olarak hayatına devam eden yeni bir teknoloji.
Servislere daha efektif bir şekilde bağlanmak ve dağıtık sistemler oluşturmak için geliştirilmiş bir framework desek daha doğru tanımlamış oluruz.
Aslında yaptığı şey servisler arasında RPC (Remote Procedure Call) modelini uygulamak. Burada da yine en önemli ihtiyaçlarımızdan biri olan yüksek performansa odaklanılmış.
Daha fazla ilerlemeden önce Protocol Buffers'dan (Protobuf) kısaca bahsedeyim;
Protobuf, bir serileştirme yöntemidir. Binary standarttır. Birbiriyle network üzerinden haberleşen programlar geliştirmede ve /veya veri depolama konusunda çok faydalıdır.
Verilerin yapısını açıklayan bir interface tanımlama dili ve bu tanımlanmış verileri temsil eden bir byte stream oluşturmak veya parse etmek için bu tanımlamadan kaynak kodu üreten bir program içerir.
gRPC de Protobuf diline dayanan servis contract'ları tanımlar. Biz developerlara servislerimizi diğer servislerle daha efektif haberleşecek şekilde ve programlama dilinden bağımsız olarak tasarlamamıza olanak sağlar.
Çünkü Protobuf ile bir contract tanımladığı zaman diğer servisler bu contract'a göre kendi yapısını oluşturur.
Bu durum ayrıca servislerin etkileşimini basitleştirir.
Protobuf, pure text formatından ziyade (RESTful servis) daha küçültülmüş bir payload sağlar. Yani machine-readable payload documentation sağlıyor.
En başta belirttiğim efektiflik işte tam da buradan geliyor. Yani payload'ı nasıl handle ettiğinden.
Bu arada contract, interface vs. deyince sanki SOAP/wsdl veya WCF çağrışımı yapıyor bir yerlerden:) Neyse...
Şu sıralar RESTful servisler popüler olduğu için aslında benim duyduğumda ilk aklıma gelen, "acaba bu yaklaşım REST 'in yerini mi alacak?" oldu. Açıkçası bilemiyorum, yorum yapmak için erken gibi.
gRPC, REST'in aksine bir çok tasarım kuralları vs. içeren mimari bir yaklaşım değil. Daha çok client'ın hangi platformda çalıştığına bakmaksızın bir prosedür çağrısı yapılmasına izin veriyor.
Protokol tarafında HTTP/2 ile çalışıyor çünkü bu protokol direkt olarak binary payload yapısını destekliyor.
Bu durumda şöyle bir gereksinimimiz oluştu o zaman; gRPC servislerin kullanılabilmesi için client server HTTP/2 'yi destekliyor olmalı.
HTTP/2 nin faydalarından da önceki postta bahsetmiştim. Otomatikman bu faydaları da bereberinde gRPC servislerde de görebileceğiz.
Bir güzel özelliği de etkileşim modelinin bidirectionality'i desteklemesidir. Yani çift yönlü etkileşimi bizlere sunar. Mesela web api'lerde tek etkileşim modeli client-server dır.
Peki gRPC hangi durumlarda tercih sebebi olabilir? :
Bu bilgiler ışığında bakacak olursak, public servisler için en azından şu aşamada pek de mantıklı gözükmüyor.
Daha çok uygulama içi haberleşen servisler (mikroservisler) arasında kullanılması iyi olabilir.
Mesela normalde microservisler arası veri alışverişinde araya bir service bus veya event-driven bir yapı koymaktansa latency'i azaltmak için gRPC servis kullanılabilir.
Event-driven sistemlerde event manager ile iletişim kurmak için tercih edilebilecek bir seçenek olabilir.
Şimdilik sadece bir inceleme olarak burada kalsın bu yazı. İşten güçten fırsat bulduğumda hemen .Net Core ile ufak bir gRPC servis geliştirip github repo'ma eklemek istiyorum.
References
Comentários