gRPC

Napiwek

Ta zawartość jest fragmentem książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.

Pobierz plik PDF

Do tej pory w tej książce skupiliśmy się na komunikacji opartej na protokole REST. Widzieliśmy, że rest jest elastycznym stylem architektury, który definiuje operacje oparte na operacjach CRUD względem zasobów jednostek. Klienci wchodzą w interakcje z zasobami za pośrednictwem protokołu HTTP za pomocą modelu komunikacji żądania/odpowiedzi. Podczas gdy rest jest szeroko implementowany, nowsza technologia komunikacji, gRPC, zyskała ogromny rozmach w całej społeczności natywnej dla chmury.

Co to jest gRPC?

gRPC to nowoczesna, wysokowydajna struktura, która rozwija stary protokół zdalnego wywołania procedury (RPC). Na poziomie aplikacji gRPC usprawnia obsługę komunikatów między klientami i usługami zaplecza. Pochodzący z firmy Google gRPC to open source i część ekosystemu Cloud Native Computing Foundation (CNCF) ofert natywnych dla chmury. FIRMA CNCF uważa gRPC za projekt inkubacji. Inkubacja oznacza, że użytkownicy końcowi korzystają z technologii w aplikacjach produkcyjnych, a projekt ma zdrową liczbę współautorów.

Typowa aplikacja kliencka gRPC uwidacznia lokalną funkcję w procesie, która implementuje operację biznesową. W ramach okładek funkcja lokalna wywołuje inną funkcję na maszynie zdalnej. To, co wydaje się być wywołaniem lokalnym, zasadniczo staje się przezroczystym wywołaniem poza procesem do usługi zdalnej. Instalacja wodna RPC abstrahuje komunikację sieciową punkt-punkt, serializację i wykonywanie między komputerami.

W aplikacjach natywnych dla chmury deweloperzy często pracują w różnych językach programowania, strukturach i technologiach. Ta współdziałanie komplikuje kontrakty komunikatów i instalację wodną wymaganą do komunikacji międzyplatformowej. GRPC zapewnia "jednolitą warstwę poziomą", która abstrahuje te obawy. Deweloperzy kodują na swojej natywnej platformie skoncentrowanej na funkcjach biznesowych, podczas gdy gRPC obsługuje hydraulikę komunikacji.

Usługa gRPC oferuje kompleksową obsługę najpopularniejszych stosów programistycznych, takich jak Java, JavaScript, C#, Go, Swift i NodeJS.

Korzyści z usługi gRPC

gRPC używa protokołu HTTP/2 dla protokołu transportowego. Chociaż jest zgodny z protokołem HTTP 1.1, protokół HTTP/2 oferuje wiele zaawansowanych funkcji:

• Protokół tworzenia ramek binarnych dla transportu danych — w przeciwieństwie do protokołu HTTP 1.1, który jest oparty na tekście.
• Obsługa multipleksowania wysyłania wielu żądań równoległych za pośrednictwem tego samego połączenia — protokół HTTP 1.1 ogranicza przetwarzanie do jednego komunikatu żądania/odpowiedzi jednocześnie.
• Dwukierunkowa komunikacja pełnodupleksowa do jednoczesnego wysyłania żądań klientów i odpowiedzi serwera.
• Wbudowane przesyłanie strumieniowe umożliwiające żądania i odpowiedzi na asynchroniczne przesyłanie strumieniowe dużych zestawów danych.
• Kompresja nagłówka, która zmniejsza użycie sieci.

gRPC jest lekki i wysoce wydajny. Może to być do 8 razy szybsze niż serializacja JSON z komunikatami o rozmiarze 60–80% mniejszym. W parlance programu Microsoft Windows Communication Foundation (WCF) wydajność gRPC przekracza szybkość i wydajność wysoce zoptymalizowanych powiązań NetTCP. W przeciwieństwie do netTCP, który faworyzuje stos firmy Microsoft, gRPC jest międzyplatformowy.

Bufory protokołu

GRPC obejmuje technologię open source o nazwie protokołu. Zapewniają one wysoce wydajny i neutralny dla platformy format serializacji ustrukturyzowanych komunikatów wysyłanych do siebie przez usługi. Korzystając z wieloplatformowego języka definicji interfejsu (IDL), deweloperzy definiują kontrakt usługi dla każdej mikrousługi. Kontrakt, zaimplementowany jako plik tekstowy .proto , opisuje metody, dane wejściowe i wyjściowe dla każdej usługi. Ten sam plik kontraktu może być używany dla klientów i usług gRPC opartych na różnych platformach deweloperskich.

Za pomocą pliku proto kompilator Protobuf generuje zarówno kod klienta, protocjak i usługi dla platformy docelowej. Kod zawiera następujące składniki:

• Silnie typizowane obiekty, współużytkowane przez klienta i usługę, reprezentujące operacje usługi i elementy danych dla komunikatu.
• Silnie typizowana klasa bazowa z wymaganą siecią wodociągową, którą zdalna usługa gRPC może dziedziczyć i rozszerzać.
• Wycinkę klienta zawierającą wymaganą instalację wodną w celu wywołania zdalnej usługi gRPC.

W czasie wykonywania każdy komunikat jest serializowany jako standardowa reprezentacja Protobuf i wymieniana między klientem a usługą zdalną. W przeciwieństwie do formatu JSON lub XML komunikaty Protobuf są serializowane jako skompilowane bajty binarne.

Obsługa gRPC na platformie .NET

GRPC jest zintegrowana z zestawem .NET Core 3.0 SDK i nowszymi wersjami. Obsługiwane są następujące narzędzia:

• Program Visual Studio 2022 z zainstalowanym pakietem roboczym ASP.NET i tworzeniem aplikacji internetowych
• Visual Studio Code
• Interfejs dotnet wiersza polecenia

Zestaw SDK obejmuje narzędzia do routingu punktów końcowych, wbudowanej IoC i rejestrowania. Serwer sieci Web Kestrel typu open source obsługuje połączenia HTTP/2. Rysunek 4–20 przedstawia szablon programu Visual Studio 2022, który szkieletuje szkielet projektu dla usługi gRPC. Zwróć uwagę, jak platforma .NET w pełni obsługuje systemy Windows, Linux i macOS.

Rysunek 4–20. Obsługa gRPC w programie Visual Studio 2022

Rysunek 4–21 przedstawia szkieletową usługę gRPC wygenerowaną na podstawie wbudowanego szkieletu uwzględnionego w programie Visual Studio 2022.

Rysunek 4–21. Projekt gRPC w programie Visual Studio 2022

Na poprzedniej ilustracji zanotuj plik opisu proto i kod usługi. Jak zobaczysz wkrótce, program Visual Studio generuje dodatkową konfigurację zarówno w klasie startowej, jak i bazowym pliku projektu.

Użycie gRPC

Preferuj gRPC w następujących scenariuszach:

• Synchroniczna komunikacja mikrousługi między mikrousługami zaplecza, w której wymagana jest natychmiastowa odpowiedź w celu kontynuowania przetwarzania.
• Środowiska wielolotowe, które muszą obsługiwać platformy programowania mieszanego.
• Małe opóźnienia i komunikacja o wysokiej przepływności, w której wydajność jest krytyczna.
• Komunikacja w czasie rzeczywistym typu punkt-punkt — gRPC może wypychać komunikaty w czasie rzeczywistym bez sondowania i ma doskonałą obsługę dwukierunkowego przesyłania strumieniowego.
• Środowiska ograniczone sieci — binarne komunikaty gRPC są zawsze mniejsze niż równoważny tekstowy komunikat JSON.

W momencie pisania tego tekstu gRPC jest używana głównie z usługami zaplecza. Nowoczesne przeglądarki nie mogą zapewnić poziomu kontroli HTTP/2 wymaganej do obsługi klienta gRPC frontonu. Oznacza to, że istnieje obsługa biblioteki gRPC-Web za pomocą platformy .NET , która umożliwia komunikację gRPC z aplikacji opartych na przeglądarce utworzonych przy użyciu języka JavaScript lub Blazor WebAssembly technologii. gRPC-Web umożliwia aplikację gRPC platformy ASP.NET Core do obsługi funkcji gRPC w aplikacjach przeglądarki:

• Silnie typizowane, generowane przez kod klienci
• Komunikaty Compact Protobuf
• Przesyłanie strumieniowe serwera

Implementacja gRPC

Architektura referencyjna mikrousług, eShop on Containers firmy Microsoft, pokazuje, jak zaimplementować usługi gRPC w aplikacjach platformy .NET. Rysunek 4–22 przedstawia architekturę zaplecza.

Rysunek 4–22. Architektura zaplecza dla aplikacji eShop on Containers

Na poprzedniej ilustracji zwróć uwagę, jak eShop obejmuje wzorzec zaplecza frontonu (BFF), uwidaczniając wiele bram interfejsu API. Omówiliśmy wzorzec BFF wcześniej w tym rozdziale. Zwróć szczególną uwagę na mikrousługę agregatora (w kolorze szarym), która znajduje się między bramą internetowego interfejsu API zakupów a mikrousługami zakupów zaplecza. Agregator odbiera pojedyncze żądanie od klienta, wysyła je do różnych mikrousług, agreguje wyniki i wysyła je z powrotem do klienta żądającego. Takie operacje zwykle wymagają synchronicznej komunikacji w celu utworzenia natychmiastowej odpowiedzi. W programie eShop wywołania zaplecza z agregatora są wykonywane przy użyciu gRPC, jak pokazano na rysunku 4–23.

Rysunek 4–23. gRPC w eShop w kontenerach

Komunikacja gRPC wymaga zarówno składników klienta, jak i serwera. Na poprzedniej ilustracji zwróć uwagę, jak agregator zakupów implementuje klienta gRPC. Klient wykonuje synchroniczne wywołania gRPC (na czerwono) do mikrousług zaplecza, z których każda implementuje serwer gRPC. Zarówno klient, jak i serwer korzystają z wbudowanej instalacji hydraulicznej gRPC z zestawu SDK platformy .NET. Wycinki po stronie klienta umożliwiają wywołanie zdalnych wywołań gRPC. Składniki po stronie serwera zapewniają kanalizacji gRPC, które niestandardowe klasy usług mogą dziedziczyć i zużywać.

Mikrousługi, które uwidaczniają zarówno interfejs API RESTful, jak i komunikację gRPC, wymagają wielu punktów końcowych do zarządzania ruchem. Zostanie otwarty punkt końcowy, który nasłuchuje ruchu HTTP dla wywołań RESTful, a drugi dla wywołań gRPC. Punkt końcowy gRPC musi być skonfigurowany dla protokołu HTTP/2 wymaganego do komunikacji gRPC.

Chociaż staramy się rozdzielić mikrousługi za pomocą asynchronicznych wzorców komunikacji, niektóre operacje wymagają wywołań bezpośrednich. gRPC powinna być podstawowym wyborem dla bezpośredniej synchronicznej komunikacji między mikrousługami. Jego protokół komunikacyjny o wysokiej wydajności oparty na HTTP/2 i protokołów sprawia, że jest to doskonały wybór.

Patrząc w przyszłość

Patrząc w przyszłość, gRPC będzie nadal zyskać przyczepność dla systemów natywnych dla chmury. Korzyści z wydajności i łatwość programowania są atrakcyjne. Jednak rest będzie prawdopodobnie około przez długi czas. Jest on przeznaczony dla publicznie uwidocznionych interfejsów API i ze względów zgodności z poprzednimi wersjami.

PoprzedniNastępny