g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

GRPC'yi ve sunum katmanı durum geçişi ile uzak prosedür çağrısı mimarisi arasındaki farkı anlayın

Tam metin 2925 Kelimeler, tahmini öğrenme süresi 9 dakika

Bugünün makalesinde Xiaoxin, herkesi yüksek düzeyde gRPC anlayışına götürecek ve ayrıca gRPC ve ağ uygulamalarının iletişim kurmak için izlediği mevcut protokoller ve mimariler arasındaki benzerlikleri ve farklılıkları açıklayacak.

Hazır mısın?

GRPC nedir?

gRPC, sunucular arasında verimli bağlantı için açık kaynaklı bir uzaktan prosedür çağrısı çerçevesidir. Yük dengeleme, izleme, durum kontrolü ve kimlik doğrulama için takılabilir arabirimler aracılığıyla farklı dillerde yazılmış sunuculara verimli bir şekilde bağlanın. Varsayılan olarak gRPC, verileri hafif ve verimli bir yapılandırılmış depolama formatı aracılığıyla seri hale getirir. Genel olarak konuşursak, gRPC, mikro hizmet mimarisinde REST protokolüne daha iyi bir alternatif olarak kabul edilir. GRPC'deki "g", bu teknolojiyi orijinal olarak geliştiren Google'dan gelir.

GRPC ile ilgili daha fazla ayrıntıya geçmeden önce, mikro hizmet mimarisine bir göz atalım.

Mikro Hizmetler ve Monolitik Mimari (Monoliths)

Monolitik mimari, uygulamaları tasarlamanın geleneksel yoludur. İstemci kullanıcı arabirimleri, sunucu tarafı uygulamaları ve veritabanları için hizmetler sağlayan ayrılmaz bir kod tabanı içerir. Proje üzerinde çalışan tüm geliştiriciler kodu aynı kod tabanında saklayacaktır. Monolitik bir mimariye en sevdiğim benzetme, onu bir stüdyo daire olarak düşünmek. Tek kişilik bir oda ihtiyaca göre farklı alanlara bölünecektir.

Monolitik mimarinin avantajı, yalnızca bir birim olduğu için günlük tutma, performans izleme ve önbelleğe alma gibi işlemlerin kolayca tamamlanabilmesidir. Ek olarak, geliştirme, test etme, hata ayıklama ve dağıtım basittir.

Ancak uygulamaların artmasıyla monolitik mimarilerin bakımı, ölçeklendirilmesi ve hatta anlaşılması zorlaşıyor. Ek olarak, koddaki küçük bir değişiklik tüm uygulamayı etkileyecek kadar karmaşık hale gelebilir.

Monolitik mimarinin bir diğer önemli dezavantajı ise tek bir teknolojiyi katı bir şekilde kısıtlamasıdır. Yeni bir çerçeve veya dil benimsemek, tam bir sistemin yeniden yazılmasını gerektirebilir.

Mikro hizmet mimarisi hakkında konuşalım!

Monolitik mimari bir stüdyo daire ise, mikro hizmet binası birçok odalı bir ev olarak kabul edilebilir. Bu, tüm uygulamanın birden çok küçük uygulama veya hizmete bölüneceği anlamına gelir.

Bu, geliştirme ekibine ihtiyaçlarına en uygun teknolojiyi seçme esnekliği verir ve hizmetlerin bağımsız olarak genişletilmesine izin verir. Mikro hizmet uygulamasındaki herhangi bir hata, uygulamanın tamamını değil, yalnızca belirli bir hizmeti etkiler.

Bu hizmetler bağımsız olarak geliştirilebilir, korunabilir ve dağıtılabilir ve API (uygulama programlama arayüzü) aracılığıyla birbirine bağlanabilir.

HTTP protokolüne dayalı mikro hizmetler arasındaki iletişim çeşitli şekillerde tamamlanabilir. En yaygın kullanılan yöntem, REST protokolünü takip etmektir. gRPC, bu iletişimi gerçekleştirmenin başka bir yoludur. Mikro hizmet iletişiminde REST sınırlamalarının üstesinden gelmek için kurulmuştur.

Kaynak: Pexels

REST mimarisi

REST, HTTP protokolü kullanan bir ağ mimarisidir. Ağ uygulamaları geliştirmek için yaygın olarak kullanılır. Kısaca, REST, arka uç verilerinin basit temsiller (JSON / XML gibi) aracılığıyla istemciye sağlandığı bir istemci-sunucu ilişkisidir. Roy Fielding'in tanımladığı gibi, REST Temsilci Devlet Transferi anlamına gelir. REST bir protokoldür ve daha düşük bir seviyede nasıl uygulanması gerektiğine dair herhangi bir kural uygulamaz. Üst düzey mimarinin uygulanması için rehberlik sağlar.

Herhangi bir uygulamayı gerçekten DİNLENEN yapmak için, altı mimari kural izlenmelidir:

1. Birleşik arayüz: API arayüzü, web uygulamasındaki kaynakları API kullanıcısına sunmalıdır.

2. İstemci / Sunucu: İstemci ve sunucu birbirinden bağımsız olmalı ve müşterinin yalnızca bağlantıyı bilmesi gerekir.

3. Durum Bilgisi İçermeyen Sunucu, istemci istekleriyle ilgili herhangi bir içeriği saklayamaz. Müşteri, uygulamanın durumunu korumaktan sorumludur.

4. Önbelleğe alınabilir: Kaynak önbelleğe alınabilir olmalıdır.

5. Hiyerarşik sistem: Mimari seviyelere sahip olmalıdır, bu da mimarinin bileşenlerinin birden çok sunucuda var olabileceği anlamına gelir.

6. Talep üzerine kodlama: İstemci, yanıt olarak çalıştırılabilir kodu alabilmelidir. Bu, isteğe bağlı bir kısıtlamadır.

REST tabanlı web servislerine RESTful web servisleri denir. Bu uygulamalarda, her bileşen bir kaynaktır ve bu kaynaklara, HTTP standart yöntemlerine dayalı ortak bir arabirim üzerinden erişilebilir. Aşağıdaki dört HTTP yöntemi, REST yapısında yaygın olarak kullanılır:

· GET Kaynaklara salt okunur erişim.

· POST Yeni bir kaynak oluşturun.

· SİL Kaynakları silin.

· PUT Mevcut kaynakları güncelleyin / yeni kaynaklar oluşturun.

RPC mimarisi

RPC, uzak prosedür çağrısı anlamına gelir. Adından da anlaşılacağı gibi, uzak bir sunucuda bir işlev / yöntem çağrılabilir. RPC protokolü nerede uygulanırsa uygulansın, problemin sonucunun aynı formatta elde edilmesini sağlar. Yerel bir sunucu veya daha iyi kaynaklar kullanan uzak bir sunucu olabilir.

RPC, REST'ten daha eski bir protokoldür. ARPANET'in 1970'lerde ortaya çıkışından bu yana, ağ işlemlerini gerçekleştirmek için kullanılmıştır. 1981'de Bruce Jay Nelson, RPC terimini ilk kez icat etti. Ancak göreceğimiz gibi, RPC hala alakalı ve modern API tabanlı uygulamalarda farklı şekillerde uygulanmaktadır.

Fikir şudur. Genel yöntemleri tanımlayarak bir uygulama programlama arabirimi oluşturun. Ardından bu yöntemleri parametrelerle çağırın. RPC yalnızca bir dizi işlevdir, ancak HTTP API için yöntemi URL'ye ve parametreleri de sorgu dizesine veya gövdesine koyması gerekir.

RPC API, POST / deleteResource'a benzer bir yöntem kullanır ve gövdesi REST yöntemi yerine {"id": 1}, yani DELETE / resource / 1 kullanır.

RPC, IoT cihazları ve düşük güçlü cihazlar için özelleştirilmiş iletişim gerektiren diğer çözümlerde çok popülerdir, çünkü birçok bilgi işlem işlemi başka bir cihaza aktarılabilir. Geleneksel olarak, uzaktan işlem kontrolü RPC-XML ve RPC-JSON için kullanılabilir.

gRPC, RPC protokolünde oluşturulan en son çerçevedir. Geleneksel RPC'nin avantajlarından tam olarak yararlanır ve geleneksel RPC'nin sorunlarını çözmeye çalışır.

GRPC nedir?

Şimdiye kadar okuduklarımız gRPC'yi yeniden tanımlayabilir. Geleneksel RPC çerçevesinin bir uyarlamasıdır. Öyleyse, mevcut RPC çerçevesinden farkı nedir?

En önemli fark, gRPC'nin JSON / XML yerine serileştirme ve iletişim için arayüz tanımlama dili olarak protokol arabelleklerini kullanmasıdır. Protokol tamponu, verilerin yapısını tarif edebilir ve kod, yapılandırılmış verileri temsil eden bayt akışını oluşturmak veya ayrıştırmak için açıklamadan üretilebilir. Bu nedenle gRPC, birden çok dilde yazılmış (farklı teknolojilerle uygulanmış) ağ uygulamaları için daha uygundur. İkili veri formatı, daha hafif iletişime izin verir. gRPC diğer veri formatlarıyla da kullanılabilir, ancak tercih edilen format protokol arabelleğidir.

Ek olarak, gRPC HTTP / 2 üzerine inşa edilmiştir ve iki yönlü iletişimi ve geleneksel istek / yanıtı destekler. gRPC, sunucu ve istemci arasında gevşek bağlantıya izin verir. Aslında, istemci gRPC sunucusuyla uzun vadeli bir bağlantı kurar ve her RPC çağrısı için yeni bir HTTP / 2 akışı oluşturur.

Kaynak: Pexels

REST ve gRPC

JSON kullanan çoğu REST'in aksine, gRPC, verileri kodlamanın daha iyi bir yolu olan protokol arabelleklerini kullanır. JSON, metin tabanlı bir format olduğundan, protobuf formatındaki sıkıştırılmış verilerden daha fazla depolama alanı kaplar.

REST ile karşılaştırıldığında, gRPC'nin bir diğer önemli iyileştirmesi de taşıma protokolü olarak HTTP 2 kullanmasıdır. REST tarafından kullanılan HTTP 1.1, temelde bir istek-yanıt modelidir. gRPC, HTTP 2'nin iki yönlü iletişim özelliklerinden ve geleneksel yanıt isteği yapısından yararlanır. HTTP 1.1'de, birden çok istemciden birden çok istek geldiğinde, hizmetleri sırayla sağlarlar. Bu, sistem hızını düşürecektir. HTTP 2 çoğullamaya izin verir, böylece birden çok istek ve yanıt aynı anda işlenebilir.

Yukarıdaki bakış açısına dayanarak, kullanım senaryosu çoklu dil iletişimi veya geleneksel API'ler kullanılarak büyük ölçekli mikro hizmet iletişimini içerdiğinde gRPC'nin iyi bir seçim olduğu sonucuna varılabilir.