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ą, zobacz wersję tego artykułu platformy .NET 9.
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ą, zobacz wersję tego artykułu platformy .NET 9.
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.
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 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
.protopliku 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.
