/ We know how

Czy warto stosować usługi gRPC? Poznajcie wady i zalety wysokowydajnego zdalnego wywoływania procedur

Czy wiecie co to jest RPC? To oczywiście skrót od remote procedure call, czyli zdalnego wywołania procedury. Umożliwia ona programom (klientom) wysyłanie przez sieć żądań wykonania sparametryzowanych działań przez określone zdalne komputery (serwery). Jako idea pojawiła się już na początkowych etapach rozwoju rozproszonych systemów przetwarzania, czyli w latach 60-tych ubiegłego wieku, natomiast pierwsze praktyczne i od razu biznesowe zastosowania datowane są na początek lat 80-tych. Bardzo szybko pojawiały się nowe implementacje. Jedną z najpopularniejszych jest implementacja RPC na Unix zrealizowana przez firmę Sun.

Z czasem w jednak, w miarę rozwoju systemów informatycznych oraz Internetu, popularyzacją urządzeń mobilnych i eksplozją danych, pojawiła się potrzeba opracowania nowego frameworku RPC, który odpowiadałby na nowe potrzeby i wyzwania. Taka jest właśnie geneza stworzonego przez Google gRPC.

 

 

gRPC – czym jest?

 

Programiści Google już od wielu lat pracowali z architekturą mikro usługową, wieloma językami, technologiami, usługami własnymi i zewnętrznymi. Mieli przez to coraz większe trudności m.in. z uwierzytelnianiem, autoryzacją, logowaniem i monitorowaniem, co przede wszystkim wpływało na szybkość ich działania. Potrzebę zmiany zaczęli odczuwać już blisko dwie dekady temu. Dlatego przez blisko 15 lat, konsekwentnie rozwijano wewnętrzny framework Stubby. Celem było stworzenie implementacji RPC, która byłaby w stanie obsłużyć „skalę internetową”, w której napływające żądania liczone są w dziesiątkach miliardów na sekundę. W 2016 firma postanowiła udostępnić Stubby jako projekt open source pod nazwą gRPC.

gRPC to nowoczesny, niezwykle wydajny framework RPC, który może działać w dowolnym środowisku. Umożliwia efektywne łączenie usług w obrębie jednego centrum danych, jak również pomiędzy wieloma ośrodkami a przy tym ułatwia wiele innych rzeczy np. równoważenie obciążeń, monitorowanie czy uwierzytelnianie. Doskonale sprawdza się także podczas rozszerzania usług na urządzenia końcowe i zainstalowane na nich oprogramowanie, w szczególności na urządzenia mobilne.

Dzięki gRPC podłączanie, obsługa czy debugowanie w systemach rozproszonych staje się równie proste jak wykonywanie tych czynności lokalnie. Za rozwiązanie wszystkich problemów pojawiających się, kiedy trzeba świadczyć usługi bardzo wysokiej jakości odpowiada framework.

 

 

Jak działa gRPC?

 

Podstawowa idea pozostaje taka sama: aplikacja kliencka bezpośrednio wywołuje metodę na aplikacji działającej na serwerze jakby to był obiekt lokalny. Podobnie jak w innych implementacjach RPC, gRPC opiera się na idei definiowania usługi. Metody, które mogą być wywoływane zdalnie wraz z ich parametrami i zwrotnymi informacjami są ściśle określone. Po stronie serwera wymagany jest odpowiedni serwer gRPC, który będzie obsługiwał wywołania klienta. Po stronie klienta, działa „stub”, który udostępnia te same metody co serwer.

Co jest nowe to fakt, że klient i serwer gRPC mogą ze sobą współpracować i komunikować się tak, jakby były jednym środowiskiem, bez względu na to w jakim języku zostały napisane. Przykład podany we Wprowadzeniu na stronie gRPC.io  to serwer gRPC napisany w Javie działający z klientami napisanymi w Go, Pythonie czy Ruby.

Najważniejszym wyróżnikiem gRPC jest wykorzystanie zamiast JSON/XML jako domyślnego języka definiującego interfejs Protocol Buffers, opracowanego przez Google, niezależnego do języka programowania sposobu (a także zestawu narzędzi) na binarną serializację strukturalnych danych.

Jego użycie polega na zdefiniowaniu struktury danych jako wiadomości i zapisanie ich w pliku proto – to standardowy plik tekstowy z rozszerzeniem .proto. Każda wiadomość to porcja informacji składająca się z serii part nazwa-wartość. To tzw. pola. Następnie przy pomocy kompilatora protoc ze specjalna wtyczką tworzone są w wybranym języku klasy dostępu do danych. To prosty sposób dostępu dla każdego pola a także metody do serializacji czy parsowania całej struktury do albo z surowych bajtów.

 

 

Jakie są główne zalety i wady gRPC?

 

gRPC niesie ze sobą, w zależności od konkretnej sytuacji, wiele zalet. Skupmy się jednak na czterech podstawowych. Pierwsza, to wyjątkowo proste definiowanie usług z wykorzystaniem Protocol Buffers. Przy tym pisane tak wiadomości są o wiele mniejsze w porównaniu do JSON. Druga to możliwość szybkiego uruchomienia a później łatwego, praktycznie nieograniczonego skalowania. Do zainstalowania środowiska deweloperskiego i uruchomieniowego wystarczy jedno polecenie. Przy tym ocenia się, że gRPC jest kilkukrotnie bardziej wydajne w porównaniu do JSON. Trzecia – interoperacyjność. gRPC działa niezależnie od języka czy platformy. Automatycznie generuje potrzebne do realizacji usługi obiekty stub dla klienta i serwera. Wreszcie czwarta, to dwukierunkowa komunikacja i zintegrowana autentykacja wykorzystująca transport HTTP/2.

Czy gRPC ma jakieś wady? Pomimo tego, że technologia została udostępniona kilka lat temu, stosunkowo powoli zyskuje sobie popularność. Większość ekspertów to nadal pracownicy Google. Być może dlatego, że opanowanie Protocol Buffers i narzędzi wymaga poświęcenie więcej czasu i wysiłku niż JSON.

 

 

Do czego najlepiej nadaje się gRPC?

 

Pomimo wysiłku, jaki trzeba włożyć w opanowanie Protocol Buffers już dzisiaj z gRPC korzysta poza Google wiele organizacji. Przykłady zastosowania obejmują scenariusze, w których łączonych jest od kilku do kilkuset usług, zarówno w środowiskach lokalnych jak również chmurowych. Najważniejsze z nich efektywne łączenie usług zbudowanych z wykorzystaniem różnych języków i platform w architekturze mikrousługowej, wymiana informacji między usługami w czasie rzeczywistym, łączenie urządzeń i aplikacji mobilnych z systemów biznesowych, szybkie budowanie RPC API.

 

 

Przykłady użycia gRPC przez duże firmy

 

Jednym z użytkowników gRPC jest Netflix. Firma początkowo używała bazującego na HTTP/1.1 własnego stosu technologicznego umożliwiającego komunikację między usługami. Z czasem zaczął być on jednak pewnym obciążeniem. Wymagał ręcznego dokodowywania a jednocześnie utrudniał wykorzystywanie API. Dlatego firma zaczęła poszukiwać rozwiązania umożliwiającego działanie programów klienckich niezależnie od konkretnego języka. Podjęte zostały próby stworzenia własnej implementacji RPC, ale jednak stosunkowo szybko zdecydowano, że lepszym wyborem będzie gRPC.

Jakie przyniosło to efekty? W przypadku każdego klienta setki linii kodu można było zastąpić kilkoma liniami konfiguracji w proto. Zamiast poświęcać np. 3 tygodnie na stworzenie programu klienckiego, dzisiaj można to zrobić w kilka minut. To znacznie przełożyło się na szybkość wprowadzania nowych produktów i usług na rynek. Pojawia się także mniej błędów – wynika to z faktu, że klient nie zawiera już pisanego ręcznie kodu.

Inna znana firma, która zastąpiła własny stos technologiczny i używa gRPC to Spotify. Zadecydowała o tym przede wszystkim szybko rosnąca skala działania. Na początku własne rozwiązania były wystarczające, ale szybko zaczęły być ograniczeniem. gRPC w szczególności ułatwia Spotify m.in. projektowanie API.

Pełne opisy case studies dotyczące Netflix, Spotify, a także innych organizacji korzystających z gRPC można znaleźć na stronie Cloud Native Computing Foundation.