Sdílet prostřednictvím

Porovnání služeb gRPC pomocí rozhraní HTTP API

  • Článek

Poznámka:

Toto není nejnovější verze tohoto článku. Aktuální verzi najdete ve verzi .NET 8 tohoto článku.

Upozorňující

Tato verze ASP.NET Core se už nepodporuje. Další informace najdete v tématu .NET a .NET Core Zásady podpory. Aktuální verzi najdete ve verzi .NET 8 tohoto článku.

Důležité

Tyto informace se týkají předběžného vydání produktu, který může být podstatně změněn před komerčním vydáním. Microsoft neposkytuje žádné záruky, výslovné ani předpokládané, týkající se zde uváděných informací.

Aktuální verzi najdete ve verzi .NET 8 tohoto článku.

Autor: James Newton-King

Tento článek vysvětluje, jak služby gRPC porovnávají s rozhraními HTTP API s JSon (včetně webových rozhraní API ASP.NET Core). Technologie použitá k poskytování rozhraní API pro vaši aplikaci je důležitou volbou a gRPC nabízí jedinečné výhody v porovnání s rozhraními HTTP API. Tento článek popisuje silné a slabé stránky gRPC a doporučuje scénáře použití gRPC oproti jiným technologiím.

Porovnání vysoké úrovně

Následující tabulka nabízí základní porovnání funkcí mezi gRPC a rozhraními HTTP API s JSON.

Funkce gRPC Rozhraní HTTP API s on-endem JS
Smlouva Povinné (.proto) Volitelné (OpenAPI)
Protokol HTTP/2 HTTP
Datová část Protobuf (malý, binární) JSZAPNUTO (velké, čitelné člověkem)
Prescriptiveness Striktní specifikace Volný. Jakýkoli protokol HTTP je platný.
Streamování Klient, server, obousměrný Klient, server
Podpora prohlížečů Ne (vyžaduje grpc-web) Ano
Zabezpečení Přenos (TLS) Přenos (TLS)
Generování kódu klienta Ano OpenAPI + nástroje třetích stran

silné stránky gRPC

Výkon

Zprávy gRPC jsou serializovány pomocí Protobuf, efektivní binární formát zprávy. Protobuf serializuje velmi rychle na serveru a klientovi. Serializace Protobuf vede k malým datovým částem zpráv, které jsou důležité ve scénářích s omezenou šířkou pásma, jako jsou mobilní aplikace.

GRPC je navržená pro HTTP/2, hlavní revize PROTOKOLU HTTP, která poskytuje významné výhody výkonu oproti HTTP 1.x:

  • Binární rámování a komprese. Protokol HTTP/2 je kompaktní a efektivní jak při odesílání, tak přijímání.
  • Multiplexování více volání HTTP/2 přes jedno připojení TCP. Multiplexing eliminuje blokování hlavy řádku.

HTTP/2 není výhradní pro gRPC. Mnoho typů požadavků, včetně rozhraní HTTP API s JSON, může využívat protokol HTTP/2 a těžit z jeho vylepšení výkonu.

Generování kódu

Všechny architektury gRPC poskytují prvotřídní podporu pro generování kódu. Základním souborem .proto pro vývoj gRPC je soubor, který definuje kontrakt služeb a zpráv gRPC. Z tohoto souboru generují rozhraní gRPC základní třídu služby, zprávy a kompletního klienta.

Sdílením .proto souboru mezi serverem a klientem je možné generovat zprávy a kód klienta od konce do konce. Generování kódu klienta eliminuje duplicitu zpráv na klientovi a serveru a vytvoří pro vás silného klienta. Nemusíte psát klienta, ale šetří významnou dobu vývoje v aplikacích s mnoha službami.

Striktní specifikace

Formální specifikace pro rozhraní HTTP API s JSON neexistuje. Vývojáři diskutují o nejlepším formátu adres URL, příkazů HTTP a kódů odpovědí.

Specifikace gRPC je preskriptivní pro formát, který musí služba gRPC dodržovat. gRPC eliminuje debatu a šetří čas vývojářů, protože gRPC je konzistentní napříč platformami a implementacemi.

Streamování

HTTP/2 poskytuje základ pro dlouhotrvající komunikační streamy v reálném čase. gRPC poskytuje prvotřídní podporu streamování prostřednictvím protokolu HTTP/2.

Služba gRPC podporuje všechny kombinace streamování:

  • Unární (bez streamování)
  • Streamování serveru do klienta
  • Streamování klienta na server
  • Obousměrné streamování

Konečný termín/vypršení časových limitů a zrušení

gRPC umožňuje klientům určit, jak dlouho budou ochotni čekat na dokončení rpc. Konečný termín se odešle na server a server může rozhodnout, jakou akci provést, pokud překročí konečný termín. Server může například zrušit probíhající požadavky gRPC/HTTP/database při vypršení časového limitu.

Rozšíření konečného termínu a zrušení prostřednictvím podřízených volání gRPC pomáhá vynucovat limity využití prostředků.

GRPC je vhodný pro následující scénáře:

  • Mikroslužby: GRPC je navržená pro komunikaci s nízkou latencí a vysokou propustností. GRPC je skvělá pro jednoduché mikroslužby, kde je důležitá efektivita.
  • Komunikace typu point-to-point v reálném čase: gRPC má vynikající podporu pro obousměrné streamování. Služby gRPC můžou odesílat zprávy v reálném čase bez dotazování.
  • Polyglotová prostředí: nástroje gRPC podporují všechny oblíbené vývojové jazyky, takže gRPC je dobrou volbou pro vícejazyčná prostředí.
  • Síťová omezená prostředí: zprávy gRPC jsou serializovány pomocí Protobuf, zjednodušeného formátu zpráv. Zpráva gRPC je vždy menší než ekvivalentní JSzpráva ON.
  • Komunikace mezi procesy (IPC):: Přenosy IPC, jako jsou sokety domény unixu a pojmenované kanály, lze použít s gRPC ke komunikaci mezi aplikacemi na stejném počítači. Další informace naleznete v tématu Komunikace mezi procesy s gRPC.

Slabá místa gRPC

Omezená podpora prohlížeče

Dnes není možné přímo volat službu gRPC z prohlížeče. GRPC silně využívá funkce HTTP/2 a žádný prohlížeč neposkytuje úroveň kontroly vyžadované webovými požadavky na podporu klienta gRPC. Prohlížeče například neumožňují volajícímu vyžadovat použití protokolu HTTP/2 nebo poskytnutí přístupu k podkladovým rámcům HTTP/2.

GRPC na ASP.NET Core nabízí dvě řešení kompatibilní s prohlížečem:

  • gRPC-Web umožňuje aplikacím prohlížeče volat služby gRPC pomocí klienta gRPC-Web a Protobuf. gRPC-Web vyžaduje, aby aplikace prohlížeče vygenerovala klienta gRPC. gRPC-Web umožňuje aplikacím v prohlížeči využívat výhod vysokého výkonu a nízkého využití sítě gRPC.

    .NET má integrovanou podporu gRPC-Web. Další informace najdete v tématu gRPC-Web v aplikacích ASP.NET Core gRPC.

  • Transkódování gRPC JSON umožňuje aplikacím v prohlížeči volat služby gRPC, jako by šlo RESTo ful rozhraní API s JSON. Aplikace prohlížeče nemusí generovat klienta gRPC ani nic vědět o gRPC. RESTful API je možné automaticky vytvořit ze služeb gRPC přidáním poznámek k .proto souboru s metadaty HTTP. Překódování umožňuje aplikaci podporovat rozhraní gRPC i JSON web API bez duplikování úsilí o vytvoření samostatných služeb pro oba.

    .NET má integrovanou podporu pro vytváření JSwebových rozhraní API na webu ze služeb gRPC. Další informace najdete v tématu gRPC JSON transkódování v aplikacích ASP.NET Core gRPC.

Poznámka:

Transkódování gRPC JSON vyžaduje .NET 7 nebo novější.

Nečitelný člověk

Požadavky rozhraní HTTP API se odesílají jako text a můžou je číst a vytvářet lidé.

Zprávy gRPC jsou ve výchozím nastavení kódovány pomocí Protobuf. I když je protobuf efektivní k odesílání a příjmu, jeho binární formát není čitelný člověkem. Protobuf vyžaduje, aby popis rozhraní zprávy zadaný v .proto souboru správně deserializovat. K analýze datových částí Protobuf na drátě a k ručnímu vytváření žádostí je potřeba další nástroje.

Existují funkce, jako je odraz serveru a nástroj příkazového řádku gRPC, které pomáhají s binárními zprávami Protobuf. Zprávy Protobuf také podporují převod na a z JSON. Integrovaný JSpřevod ON poskytuje efektivní způsob, jak při ladění převést zprávy Protobuf do a z lidské čitelné formy.

Alternativní scénáře architektury

V následujících scénářích se doporučují jiné architektury než gRPC:

  • Přístupná rozhraní API prohlížeče: GRPC není v prohlížeči plně podporovaná. gRPC-Web může nabízet podporu prohlížeče, ale má omezení a zavádí proxy serveru.
  • Komunikace vysílání v reálném čase: GRPC podporuje komunikaci v reálném čase prostřednictvím streamování, ale koncept vysílání zprávy na registrovaná připojení neexistuje. Například ve scénáři chatovací místnosti, ve kterém by se nové zprávy chatu měly posílat všem klientům v chatovací místnosti, je každé volání gRPC potřeba k individuálnímu streamování nových chatových zpráv klientovi. SignalR je užitečná architektura pro tento scénář. SignalR má koncept trvalých připojení a integrovanou podporu pro vysílání zpráv.

Další materiály