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

Článek
11/30/2023

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
Kontrakt	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ů.

Doporučené scénáře gRPC

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.

Sdílet prostřednictvím