Porównanie usług gRPC za pomocą interfejsów API protokołu HTTP

Artykuł
11/30/2023

W tym artykule wyjaśniono, w jaki sposób usługi gRPC porównują się z interfejsami API HTTP z JSwłączonymi (w tym ASP.NET Core internetowymi interfejsami API). Technologia używana do udostępniania interfejsu API dla aplikacji jest ważnym wyborem, a biblioteka gRPC oferuje unikatowe korzyści w porównaniu z interfejsami API PROTOKOŁU HTTP. W tym artykule omówiono mocne i słabe strony gRPC i zaleca scenariusze używania gRPC w innych technologiach.

Porównanie wysokiego poziomu

W poniższej tabeli przedstawiono ogólne porównanie funkcji między interfejsami API gRPC i HTTP z włączonym JS.

Funkcja	gRPC	Interfejsy API HTTP z włączonym JS
Kontrakt	Wymagane (`.proto`)	Opcjonalne (OpenAPI)
Protokół	HTTP/2	HTTP
Ładunek	Protobuf (mały, binarny)	JSON (duży, czytelny dla człowieka)
Preskrypcja	Ścisła specyfikacja	Luźne. Każdy protokół HTTP jest prawidłowy.
Przesyłanie strumieniowe	Klient, serwer, dwukierunkowy	Klient, serwer
Obsługa przeglądarek	Nie (wymaga grpc-web)	Tak
Zabezpieczenia	Transport (TLS)	Transport (TLS)
Generowanie kodu klienta	Tak	OpenAPI + narzędzia innych firm

Mocne siły gRPC

Wydajność

Komunikaty gRPC są serializowane przy użyciu protobuf, wydajnego formatu komunikatów binarnych. Protobuf serializuje się bardzo szybko na serwerze i kliencie. Serializacja Protobuf powoduje niewielkie ładunki komunikatów, co jest ważne w scenariuszach z ograniczoną przepustowością, takich jak aplikacje mobilne.

GRPC jest przeznaczony dla protokołu HTTP/2, głównej poprawki protokołu HTTP, która zapewnia znaczne korzyści z wydajności za pośrednictwem protokołu HTTP 1.x:

Ramowanie binarne i kompresja. Protokół HTTP/2 jest kompaktowy i wydajny zarówno w zakresie wysyłania, jak i odbierania.
Multipleksowanie wielu wywołań HTTP/2 za pośrednictwem jednego połączenia TCP. Multipleksowanie eliminuje blokowanie nagłówków linii.

Protokół HTTP/2 nie jest wyłączny dla gRPC. Wiele typów żądań, w tym interfejsów API HTTP z JSwłączonym, może korzystać z protokołu HTTP/2 i korzystać z ulepszeń wydajności.

Generowanie kodu

Wszystkie struktury gRPC zapewniają najwyższej jakości obsługę generowania kodu. Podstawowym plikiem do programowania gRPC jest .proto plik, który definiuje kontrakt usług gRPC i komunikatów. Na podstawie tego pliku struktury gRPC generują klasę bazową usługi, komunikaty i kompletnego klienta.

.proto Udostępnianie pliku między serwerem a klientem umożliwia wygenerowanie komunikatów i kodu klienta od końca do końca. Generowanie kodu klienta eliminuje duplikowanie komunikatów na kliencie i serwerze i tworzy silnie typizowanego klienta. Nie trzeba pisać klienta oszczędza znaczący czas programowania w aplikacjach z wieloma usługami.

Ścisła specyfikacja

Formalna specyfikacja interfejsu API HTTP z włączonym protokołem JSNIE istnieje. Deweloperzy omawiają najlepszy format adresów URL, czasowników HTTP i kodów odpowiedzi.

Specyfikacja gRPC jest nakazowa dotycząca formatu, który musi być zgodny z usługą gRPC. GRPC eliminuje debatę i oszczędza czas dewelopera, ponieważ gRPC jest spójny na różnych platformach i implementacjach.

Przesyłanie strumieniowe

Protokół HTTP/2 stanowi podstawę dla długotrwałych strumieni komunikacji w czasie rzeczywistym. GRPC zapewnia najwyższej klasy obsługę przesyłania strumieniowego za pośrednictwem protokołu HTTP/2.

Usługa gRPC obsługuje wszystkie kombinacje przesyłania strumieniowego:

Jednoargumentowy (bez przesyłania strumieniowego)
Przesyłanie strumieniowe serwer-klient
Przesyłanie strumieniowe klienta na serwer
Dwukierunkowe przesyłanie strumieniowe

Termin/przekroczenie limitu czasu i anulowanie

GRPC umożliwia klientom określenie, jak długo chcą czekać na ukończenie procedury RPC. Termin ostateczny jest wysyłany do serwera, a serwer może zdecydować, jakie działania należy podjąć, jeśli przekroczy termin ostateczny. Na przykład serwer może anulować żądania gRPC/HTTP/database w toku po przekroczeniu limitu czasu.

Propagowanie terminu ostatecznego i anulowania za pomocą podrzędnych wywołań gRPC pomaga wymusić limity użycia zasobów.

Zalecane scenariusze gRPC

Usługa gRPC jest odpowiednia dla następujących scenariuszy:

Mikrousługi: gRPC jest przeznaczona do komunikacji o małych opóźnieniach i wysokiej przepływności. GRPC doskonale nadaje się do lekkich mikrousług, w których wydajność ma kluczowe znaczenie.
Komunikacja punkt-punkt w czasie rzeczywistym: gRPC ma doskonałą obsługę dwukierunkowego przesyłania strumieniowego. Usługi gRPC mogą wypychać komunikaty w czasie rzeczywistym bez sondowania.
Środowiska wielolotowe: narzędzia gRPC obsługują wszystkie popularne języki programistyczne, dzięki czemu gRPC jest dobrym wyborem w środowiskach wielojęzycznych.
Środowiska ograniczone sieci: komunikaty gRPC są serializowane za pomocą protobuf, uproszczonego formatu komunikatów. Komunikat gRPC jest zawsze mniejszy niż równoważny JSkomunikat ON.
Komunikacja między procesami (IPC): transporty IPC, takie jak gniazda domeny systemu Unix i nazwane potoki, mogą być używane z gRPC do komunikacji między aplikacjami na tym samym komputerze. Aby uzyskać więcej informacji, zobacz Komunikacja między procesami z gRPC.

Słabe punkty gRPC

Ograniczona obsługa przeglądarki

Obecnie nie można bezpośrednio wywołać usługi gRPC z przeglądarki. Usługa gRPC intensywnie używa funkcji HTTP/2 i żadna przeglądarka nie zapewnia poziomu kontroli wymaganej przez żądania internetowe do obsługi klienta gRPC. Na przykład przeglądarki nie zezwalają wywołującym na wymaganie użycia protokołu HTTP/2 lub zapewnienie dostępu do podstawowych ramek HTTP/2.

Usługa gRPC w systemie ASP.NET Core oferuje dwa rozwiązania zgodne z przeglądarką:

gRPC-Web umożliwia aplikacjom przeglądarki wywoływanie usług gRPC za pomocą klienta gRPC-Web i narzędzia Protobuf. gRPC-Web wymaga, aby aplikacja przeglądarki wygenerowała klienta gRPC. GRPC-Web umożliwia aplikacjom przeglądarki korzystanie z wysokiej wydajności i niskiego użycia sieci gRPC.

Platforma .NET ma wbudowaną obsługę gRPC-Web. Aby uzyskać więcej informacji, zobacz gRPC-Web in ASP.NET Core gRPC apps (Aplikacje gRPC core).
Transkodowanie gRPC JSON umożliwia aplikacjom przeglądarki wywoływanie usług gRPC tak, jakby były RESTto pełne interfejsy API z włączonymJS. Aplikacja przeglądarki nie musi generować klienta gRPC ani nic wiedzieć o gRPC. RESTInterfejsy API ful można automatycznie tworzyć na podstawie usług gRPC, dodając adnotacje do .proto pliku za pomocą metadanych HTTP. Transkodowanie umożliwia aplikacji obsługę zarówno interfejsów gRPC, jak i JSON internetowych interfejsów API bez duplikowania nakładu pracy nad tworzeniem oddzielnych usług dla obu tych usług.

Platforma .NET ma wbudowaną obsługę tworzenia JSinternetowych interfejsów API ON z usług gRPC. Aby uzyskać więcej informacji, zobacz transkodowanie gRPC JSON w aplikacjach gRPC platformy ASP.NET Core.

Uwaga

Transkodowanie gRPC JSON wymaga platformy .NET 7 lub nowszej.

Nie czytelne dla człowieka

Żądania interfejsu API HTTP są wysyłane jako tekst i mogą być odczytywane i tworzone przez ludzi.

Komunikaty gRPC są domyślnie kodowane za pomocą narzędzia Protobuf. Chociaż protobuf jest wydajny do wysyłania i odbierania, jego format binarny nie jest czytelny dla człowieka. Protobuf wymaga opisu interfejsu komunikatu określonego w pliku w celu poprawnego .proto deserializacji. Dodatkowe narzędzia są wymagane do analizowania ładunków Protobuf na przewodach i tworzenia żądań ręcznie.

Funkcje takie jak odbicie serwera i narzędzie wiersza polecenia gRPC istnieją, aby pomóc w binarnych komunikatach Protobuf. Ponadto komunikaty Protobuf obsługują konwersję na i z włączonejJS. Wbudowana JSkonwersja ON zapewnia wydajny sposób konwertowania komunikatów Protobuf na i z formularza czytelnego dla człowieka podczas debugowania.

Scenariusze alternatywnej struktury

Inne struktury są zalecane w następujących scenariuszach za pośrednictwem usługi gRPC:

Interfejsy API dostępne dla przeglądarki: usługa gRPC nie jest w pełni obsługiwana w przeglądarce. Usługa gRPC-Web może oferować obsługę przeglądarki, ale ma ograniczenia i wprowadza serwer proxy serwera proxy.
Emisja komunikacji w czasie rzeczywistym: gRPC obsługuje komunikację w czasie rzeczywistym za pośrednictwem przesyłania strumieniowego, ale koncepcja emisji komunikatu wychodzącego z zarejestrowanymi połączeniami nie istnieje. Na przykład w scenariuszu pokoju rozmów, w którym nowe wiadomości czatu powinny być wysyłane do wszystkich klientów w pokoju rozmów, każde wywołanie gRPC jest wymagane do indywidualnego przesyłania strumieniowego nowych wiadomości czatu do klienta. SignalR jest przydatną strukturą dla tego scenariusza. SignalR ma pojęcie trwałych połączeń i wbudowaną obsługę emisji komunikatów.