Większość aplikacji programowych musi być w stanie połączyć się z innym kodem z kilku powodów. Może to być wszystko, od integracji po dodanie nowej funkcjonalności. Aby upewnić się, że oprogramowanie może łączyć się z innymi aplikacjami i zapewnić ich integrację z innymi programami, programiści używają interfejsów API. Dlatego właśnie interfejs programowania aplikacji jest niezbędny dla większości oprogramowania. Pełniąc rolę pomostu między systemami, interfejsy API umożliwiają jednostkom dostęp do różnych usług internetowych. Dlatego ważne jest, aby wybrać odpowiednią technologię, aby zaoferować API do swojego projektu.
Każda organizacja, która chce udostępnić swoją aplikację lub platformę swoim użytkownikom, musi korzystać z interfejsów API. Istnieje wiele sposobów na opracowanie i dostrojenie interfejsów API, aby były one idealnie dopasowane do Twojej aplikacji. Jedną z najnowszych metod, którą programiści wykorzystują do projektowania interfejsów API, jest gRPC. Przyjrzyjmy się, czym jest gRPC oraz jakie są jego zalety i wady.
Co to jest gRPC?
gRPC oznacza Google Remote Procedure Call. gRPC to open-source'owy framework RPC, który służy do tworzenia skalowalnych i szybkich interfejsów API. Umożliwia rozwój systemów sieciowych i otwartą komunikację między gRPC aplikacjami klienckimi i serwerowymi. gRPC został przyjęty przez kilka czołowych firm technologicznych, w tym Google, IBM, Netflix i więcej. Szkielet gRPC zależy od najnowocześniejszych technologii, takich jak HTTP/2, bufory protokołów i inne, aby zapewnić optymalną ochronę API, wysoką wydajność zdalnych wywołań procedur i skalowalność.
Czym są RPCs?
RPC i REST - Representational State Transfer- historycznie były dwoma oddzielnymi podejściami do budowania interfejsów API. Dodatkowo do tego celu wykorzystywane są również protokoły takie jak SOAP i GraphQL. Zdalne wywołania procedur pozwalają pisać oprogramowanie tak, jakby było ono uruchamiane lokalnie, choć może działać na innym urządzeniu.
Są najbardziej konwencjonalnie stosowanym szkieletem do projektowania interfejsów API. W przeciwieństwie do typowego wywołania protokołu HTTP, RPC wykorzystuje wywołanie funkcji jako podstawową metodę interakcji klient-serwer. RPC jest produktywną techniką tworzenia API, ponieważ wymiana danych jest prosta, a zawartość lekka. gRPC usługi również naśladują tę architekturę komunikacji. RPC wykorzystuje IDL - Interface Definition Language do zakontraktowania typu danych i metod, które będą wywoływane. Zaadoptowane gRPC usługi z RPC stały się w ostatnich latach bardzo popularne.
Dlaczego opracowano usługi gRPC?
Ponieważ coraz więcej przedsiębiorstw otwiera kanały integracji, coraz trudniej jest połączyć takie oprogramowanie. RPC Interfejsy API są trudne w integracji i ryzykowne w dystrybucji, ponieważ mogą ujawniać wewnętrzną specyfikę. Są one tworzone w wielu językach programowania i są ściśle związane z bazowymi frameworkami.
Ten problem został rozwiązany, a dostępność API została zwiększona, gdy w 2000 roku wprowadzono REST API. W szczególności dało to użytkownikom spójny sposób pobierania informacji pośrednio przez aktywa za pomocą standardowych technik HTTP, takich jak GET, PUT, POST i innych. Podstawowym wyróżnikiem RPC od REST API jest to, że z RPC, procesy są adresowane, ale nie jest łatwo przewidzieć, jakie mogą być procesy w różnych systemach.
REST API nie mógł całkowicie zastąpić prostego i lekkiego RPC, ponieważ produkował bardzo dużo metadanych, nawet jeśli oferował ulepszony format do obsługi wielu aplikacji. Spowodowało to ostateczne pojawienie się usług Facebooka GraphQL i Google gRPC.
Google zbudował gRPC w 2015 roku jako dodatek do frameworka RPC, aby połączyć liczne architektury mikroserwisów wykonane różnymi technikami. gRPC był początkowo ściśle związany z podstawową infrastrukturą Google, ale ostatecznie został udostępniony jako open source i ustandaryzowany do użytku przez ogół społeczeństwa.
Przegląd koncepcji gRPC
Wykorzystanie najnowocześniejszych technologii, które mają wysoką wydajność w porównaniu z JSON i XML oraz oferują większą integralność API, jest odpowiedzialne za powstanie i popularność gRPC. Niektóre z koncepcji gRPC, które powinieneś znać, to:
Bufory protokołów.
Bufory protokołów, znane również jako Protobuf, to standardy serializacji lub deserializacji, które ułatwiają definiowanie aplikacji i automatycznie wykonują generowanie kodu bibliotek klienckich. Najnowsza wersja, proto3, jest prostsza w użyciu i oferuje najnowsze możliwości gRPC.
.Proto Pliki umożliwiają korzystanie z usług gRPC oraz komunikację między klientami gRPC i komunikatami serwera. Plik .proto jest ładowany do pamięci podczas wykonywania przez kompilator Protobuf - protoc. Kompilator ten buduje aplikacje gRPC klienta i gRPC serwera, które wykorzystują strukturę in-memory do serializacji i deserializacji danych binarnych. Każda komunikacja jest wysyłana i odbierana między użytkownikiem a zdalną usługą po wygenerowaniu kodu w gRPC.
Ponieważ dane są tłumaczone na postać binarną, a zaszyfrowane sygnały są mniejsze, parsowanie za pomocą Protobuf zużywa mniej CPU mocy dla gRPC. Dlatego nawet na komputerach o słabszej CPU, takich jak telefony komórkowe, wiadomości są wysyłane szybciej za pomocą gRPC.
HTTP/2
gRPC serwis jest zbudowany na HTTP/2, czyli wersji protokołu HTTP/1.1, która ma mniej ograniczeń. Chociaż działa ze starszym protokołem HTTP, HTTP/2 ma kilka zaawansowanych funkcji dla gRPC. Obejmuje to warstwę kadrowania binarnego, która dzieli każde zapytanie i odpowiedzi HTTP/2 na mniejsze wiadomości i kadruje je w formacie binarnym, aby poprawić dostarczanie wiadomości. Dodatkowo, gRPC obsługuje wiele żądań i odpowiedzi od klienta i gRPC serwera w dwukierunkowym strumieniu full-duplex.
HTTP/2 posiada metodę kontroli przepływu, która pozwala na precyzyjną kontrolę RAM potrzebną do buforowania pakietów w locie. Oferuje również kompresję nagłówków dla usług gRPC. Wszystko w HTTP/2 jest szyfrowane przed transmisją, nawet nagłówki, które zapewniają wysoką wydajność zdalnych wywołań procedur. gRPC zapewnia zarówno asynchroniczne, jak i synchroniczne przetwarzanie z HTTP/2, umożliwiając wykonywanie różnych interaktywnych i strumieniowych typów RPC.
Z pomocą tych wszystkich cech HTTP/2 usługi gRPC mogą wykorzystywać mniej zasobów, co prowadzi do szybszych czasów reakcji wśród aplikacji opartych na chmurze i usług gRPC oraz większej żywotności baterii dla klientów gRPC działających na urządzeniach mobilnych.
Streaming
Kluczową ideą wspieraną przez gRPC jest strumieniowanie, które pozwala na wykonanie kilku procesów w ramach jednego żądania. gRPC umożliwia to funkcja multipleksowania HTTP/2, która pozwala na jednoczesne wysyłanie lub odbieranie kilku odpowiedzi lub żądań w ramach jednego TCP - Transmission Control Protocol - połączenia. Podstawowe formaty przesyłania strumieniowego to RPC przesyłane przez serwer, klient przesyłany przez RPCs oraz dwukierunkowe przesyłanie strumieniowe RPCs.
Kanały
W przeciwieństwie do strumieni HTTP/2, które pozwalają na wiele jednoczesnych strumieni na jednym połączeniu żądania, kanał z gRPC obsługuje wiele ciągłych strumieni przez wiele żądań. Są one wykorzystywane do budowania odgałęzień klienta i dają mechanizm łączenia się z serwerem gRPC na określonym IP i porcie.
gRPC Architektura
Architektura gRPC składa się z klienta gRPC i serwera gRPC. Każda usługa klienta gRPC zawiera stub lub automatycznie wygenerowany plik, który jest zbliżony do interfejsu zawierającego aktywne procesy zdalne. Klient gRPC inicjuje lokalne wywołanie procedury do stuba zawierającego argumenty, które mają być przekazane do wiadomości serwera gRPC. Stub klienta gRPC wysyła następnie zapytanie do lokalnej jednostki czasu klienta na komputerze lokalnym po serializacji argumentów za pomocą procedury Protobuf marshaling.
System operacyjny używa protokołu HTTP/2 do komunikacji z odległym komputerem serwera. System operacyjny serwera przyjmuje komunikaty i wywołuje proces stub serwera, który używa Protobuf do wywołania odpowiedniej operacji po zdekodowaniu przychodzących parametrów. Następnie warstwa transportowa klienta odbiera zaszyfrowaną odpowiedź z ogniska serwera. Wykonanie przechodzi z powrotem do dzwoniącego po tym, jak gRPC klient stub otrzyma wiadomości odpowiedzi i rozpakuje dostarczone argumenty.
Zalety gRPC
gRPC ma kilka zalet w stosunku do innych mechanizmów projektowania API. gRPC ulepsza również strukturę RPC. Oto najbardziej widoczne zalety usług gRPC:
- Wysoka wydajność zdalnych wywołań procedur.
Korzystając z Protobuf i HTTP/2, usługi gRPC zapewniają do 10 razy większą wydajność i ochronę API niż interakcje REST+JSON. Dzięki wykorzystaniu funkcji server pushes, multipleksowania i kompresji nagłówków, HTTP/2 zapewnia wysoką wydajność usług gRPC. Podczas gdy multipleksowanie pozwala pozbyć się opóźnień w nagłówku linii, push serwera umożliwia HTTP/2 wypychanie materiałów z serwera do klienta, zanim będą one potrzebne. Przy użyciu HTTP/2 wiadomości są bardziej efektywnie kompresowane, co skutkuje szybszym ładowaniem w przypadku usług gRPC.
- Przesyłanie strumieniowe
Opis usługi dla usług strumieniowych gRPC zawiera już zasady strumieniowania po stronie klienta lub serwera. Dzięki temu budowanie klientów gRPC i usług strumieniowych jest znacznie łatwiejsze.
- Generowanie kodu
Generowanie kodu dla programów klienckich gRPC i serwerowych gRPC jest kluczowym elementem podejścia sieciowego gRPC. Do generowania kodu z pliku .proto, moduły gRPC wykorzystują kompilator .protoc. Format Protobuf jest kontrolowany poprzez generowanie kodu w gRPC, który jest używany do definiowania zarówno formatów danych, jak i punktów końcowych aplikacji. Może on tworzyć stuby sieci po stronie klienta i szkielety po stronie serwera, co zmniejsza ilość czasu potrzebną do zaprojektowania programów z różnymi usługami w gRPC services.
- Interoperacyjność
Liczne systemy i języki programowania, takie jak Java, Ruby, Go, C# i inne, są obsługiwane przez zasoby i biblioteki gRPC. Dzięki tym językom programowania programiści mogą tworzyć wydajne aplikacje, wykorzystując jednocześnie pełną zgodność międzyplatformową z gRPC. Jest to możliwe dzięki binarnej formie okablowania Protobuf i efektywnemu generowaniu kodu dla niemal wszystkich systemów.
- Bezpieczeństwo
Bezpieczeństwo API jest zapewnione w gRPC przy użyciu HTTP/2 przez sesję szyfrowaną TLS end-to-end. gRPC promuje przyjęcie SSL/TLS do szyfrowania danych i uwierzytelniania między serwerem a klientem gRPC.
- Produktywność i użyteczność
Ponieważ gRPC jest kompletną alternatywą dla RPC, działa bez problemu w szerokim zakresie systemów i języków. gRPC ma również świetne narzędzia, dzięki którym wiele niezbędnego kodu jest generowane ręcznie. Inżynierowie mogą teraz skoncentrować się bardziej na podstawowej funkcjonalności ze względu na znaczną oszczędność czasu dzięki gRPC.
Wady gRPC
Chociaż możemy mieć nadzieję, że wady gRPC zostaną ostatecznie rozwiązane, stanowią one pewne problemy dla jego użycia teraz. Niektóre wady gRPC, o których powinieneś wiedzieć to:
- Brak dojrzałości
Rozwój technologii może stanowić istotną barierę dla jej przyjęcia. Jest to również jasne podczas używania gRPC. GraphQL Jeden z partnerów gRPC ma ponad 14 tys. zapytań na StackOverflow, podczas gdy gRPC ma w tej chwili tylko nieco poniżej 4 tys. Społeczności gRPC brakuje wiedzy na temat najlepszych praktyk, rozwiązań i sukcesów, ponieważ poza Google nie ma zbyt wielu programistów zajmujących się HTTP/2 oraz buforami protokołów. Jednak w miarę jak społeczność gRPC będzie się rozrastać i przyciągać nowych programistów, w końcu to się rozwinie.
- Ograniczone wsparcie dla przeglądarek
Ponieważ żadna z obecnych przeglądarek internetowych gRPC nie obsługuje ramek HTTP/2, nie można efektywnie wywołać usługi gRPC z poziomu przeglądarki, ponieważ gRPC Web zależy przede wszystkim od HTTP/2. W rezultacie musisz używać proxy z gRPC, co ma kilka wad.
- Nieczytelne dla ludzi
W przeciwieństwie do XML i JSON, pliki Protobuf nie są czytelne dla człowieka, ponieważ dane są skompresowane do formatu binarnego. Programiści muszą korzystać z dodatkowych narzędzi, takich jak protokół odbicia serwera i gRPC wiersz poleceń, aby ocenić ładunki, przeprowadzić rozwiązywanie problemów i utworzyć ręczne zapytania.
- Stroma krzywa uczenia się
Zapoznanie się z buforami protokołu i odkrycie metod radzenia sobie z tarciem HTTP/2 zajmie trochę czasu, w przeciwieństwie do REST i GraphQL, z których oba w większości wykorzystują JSON.
Jak pomaga AppMaster?
No-code Generacja zmienia sposób, w jaki ludzie postrzegają programowanie. No-code Generacja umożliwia szybszą naukę i tworzenie oprogramowania dzięki generowaniu kodu. Generowanie kodu dla Twojej aplikacji jest prostsze przy użyciu no-code platform generacyjnych, takich jak AppMaster. Nie ma też problemów z własnością, ponieważ generowanie kodu jest chronione, a kod, który stworzysz, będzie należał wyłącznie do Ciebie. Możesz tworzyć aplikacje klienckie i serwerowe szybciej i łatwiej dzięki AppMaster.
Platforma generująca no-code firmy AppMaster pozwala programistom używać protokołu gRPC do wykonywania żądań między backendową architekturą mikroserwisów. W przyszłym roku rozszerzymy wsparcie gRPC poprzez włączenie API zarówno do aplikacji gRPC Web jak i gRPC Mobile.
Podsumowanie
Chociaż usługi gRPC mają kilka korzyści, które czynią je atrakcyjnymi dla firm i deweloperów, ostatecznie decyzja o użyciu usług gRPC nad innymi, takimi jak REST lub SOAP, zależy od Twojej aplikacji. Podczas gdy niektóre programy będą miały wysoką wydajność korzyści z gRPC, inne mogą być lepiej dostosowane do jego alternatyw. Powinieneś zrozumieć wady i zalety usług gRPC i zdecydować, czy to rozwiązanie będzie dla Ciebie odpowiednie.
