Udostępnij za pośrednictwem


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

Uwaga

Nie jest to najnowsza wersja tego artykułu. Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.

Ostrzeżenie

Ta wersja ASP.NET Core nie jest już obsługiwana. Aby uzyskać więcej informacji, zobacz .NET i .NET Core Support Policy (Zasady obsługi platformy .NET Core). Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.

Ważne

Te informacje odnoszą się do produktu w wersji wstępnej, który może zostać znacząco zmodyfikowany, zanim zostanie wydany komercyjnie. Firma Microsoft nie udziela żadnych gwarancji, jawnych lub domniemanych, w odniesieniu do informacji podanych w tym miejscu.

Aby zapoznać się z bieżącą wersją, zapoznaj się z wersją tego artykułu platformy .NET 8.

Autor: James Newton-King

W tym artykule wyjaśniono, w jaki sposób usługi gRPC są porównywane z interfejsami API PROTOKOŁU HTTP za pomocą kodu JSON (w tym ASP.NET Core internetowych interfejsów 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 w formacie JSON.

Funkcja gRPC Interfejsy API HTTP z plikiem JSON
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źny. 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 w formacie JSON, może używać 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 plikiem JSON nie 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.

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 komunikat JSON.
  • 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 to interfejsy API RESTful z formatem JSON. Aplikacja przeglądarki nie musi generować klienta gRPC ani nic wiedzieć o gRPC. Interfejsy API RESTful 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 internetowych interfejsów API gRPC, jak i JSON bez duplikowania nakładu pracy nad tworzeniem oddzielnych usług dla obu tych usług.

    Platforma .NET ma wbudowaną obsługę tworzenia internetowych interfejsów API JSON 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 formatu JSON. Wbudowana konwersja JSON 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.

Dodatkowe zasoby