| gRPC | |
|---|---|
| Type | remote procedure call framework |
| Udvikler | |
| Skrevet i | Android Java, C#, C++, Dart, Go, Java, Kotlin/JVM, Node.js, Objective-C, PHP, Python, Ruby |
| Første udgave | august 2016 |
| nyeste version | 1.33.2 |
| Licens | Apache-licens 2.0 |
| Internet side | grpc.io |
gRPC ( Remote Procedure Calls ) er et open source remote procedure call (RPC) system, der oprindeligt blev udviklet af Google i 2015. HTTP/2 bruges som transport, Protocol Buffers bruges som grænsefladebeskrivelsessprog . gRPC giver funktioner såsom godkendelse, tovejs streaming og flowkontrol, blokerende eller ikke-blokerende bindinger og annullering og timeouts. Genererer cross-platform klient- og serverbindinger til mange sprog. Det er mest almindeligt brugt til at forbinde tjenester i en mikroservice-stil arkitektur og forbinde mobile enheder og browserklienter til back-end-tjenester.
Den komplekse brug af HTTP/2 i gRPC gør det umuligt at implementere en gRPC-klient i en browser – der kræves i stedet en proxy.
gRPC understøtter brugen af TLS og token - baseret godkendelse . Forbindelse til Google-tjenester skal bruge TLS . Der er to typer legitimationsoplysninger: kanallegitimationsoplysninger og opkaldslegitimationsoplysninger.
gRPC bruger protokolbuffere til at kode data. I modsætning til HTTP API med JSON har de en strengere specifikation.
I gRPC kan en klientapplikation direkte kalde en serverapplikationsmetode på en anden maskine, som om den var et lokalt objekt, hvilket gør det nemmere at oprette distribuerede applikationer og tjenester. Som mange RPC-systemer er gRPC baseret på ideen om at definere en tjeneste, definere metoder, der kan kaldes eksternt med deres parametre og returtyper. På serversiden implementerer serveren denne grænseflade og starter gRPC-serveren for at behandle klientkald. På klientsiden er der en stub (kaldet blot klienten på nogle sprog), der afslører de samme metoder som serveren.
gRPC- klienter og -servere kan køre og kommunikere med hinanden i en række forskellige miljøer og kan skrives på et hvilket som helst af de understøttede gRPC-sprog.
Som standard bruger gRPC Protobuf som grænsefladedefinitionssprog ( IDL ) til at beskrive servicegrænsefladen og nyttelastmeddelelsesstrukturen. Andre alternativer kan anvendes, hvis det ønskes.
gRPC giver dig mulighed for at definere fire typer servicemetoder:
Startende med en tjenestedefinition i .protoen fil, leverer gRPC Protocol Buffers compiler plugins , der genererer klient- og serverkode. gRPC-brugere kalder typisk disse API'er på klientsiden og implementerer den tilsvarende API på serversiden.
Synkrone RPC'er, som blokerer, indtil et svar modtages fra serveren, er den nærmeste tilnærmelse til procedurekaldsabstraktionen, som RPC sigter efter. På den anden side er netværk i sagens natur asynkrone, og i mange scenarier er det nyttigt at kunne køre RPC uden at blokere den aktuelle tråd.
gRPC programmerings-API'en på de fleste sprog har både synkrone og asynkrone varianter.
Klienten sender én anmodning og returnerer ét svar.
Serverstreaming RPC ligner unær RPC, bortset fra at serveren returnerer en strøm af meddelelser som svar på en klientanmodning. Efter at alle meddelelser er blevet sendt, sendes serverstatusinformation (en statuskode og en valgfri statusmeddelelse) og yderligere endelige metadata til klienten. Dette fuldender server-side behandling. Klienten afsluttes, når den har modtaget alle beskeder fra serveren.
Streaming klient RPC ligner unær RPC, bortset fra at klienten sender en strøm af meddelelser til serveren i stedet for en enkelt meddelelse. Serveren svarer med en enkelt besked (sammen med dens statusoplysninger og yderligere endelige metadata), normalt, men ikke nødvendigvis, efter at den har modtaget alle klientens beskeder.
I RPC med tovejsstreaming initieres opkaldet ved, at klienten kalder metoden, og serveren modtager klientens metadata, metodenavn og deadline. Serveren kan vælge at sende sine oprindelige metadata eller vente på, at klienten begynder at streame beskeder.
Streambehandling på klientsiden og på serversiden afhænger af applikationen. Fordi de to tråde er uafhængige, kan klienten og serveren læse og skrive beskeder i vilkårlig rækkefølge. For eksempel kan serveren vente, indtil den har modtaget alle klientens meddelelser, før den skriver sine egne meddelelser, eller serveren og klienten kan spille " ping pong " - serveren modtager en anmodning, sender derefter et svar, hvorefter klienten sender en anden anmodning baseret på svaret og så videre.
gRPC giver kunderne mulighed for at angive, hvor længe de er villige til at vente på, at en RPC er færdig, før RPC'en mislykkes. På serversiden kan serveren spørge, om en bestemt RPC har timeout, eller hvor meget tid der er tilbage for RPC'en at gennemføre.
Angivelse af en deadline eller timeout er sprogafhængig: nogle sprog-API'er fungerer i form af timeouts (en længde af tid), og nogle sprog-API'er fungerer i form af en deadline (et fast tidspunkt) og kan have eller ikke have en standarddeadline .
I gRPC foretager både klienten og serveren uafhængige og lokale beslutninger om et opkalds succes, og deres konklusioner stemmer muligvis ikke overens. Det betyder, at du for eksempel kunne have en RPC, der lykkes på serversiden, men fejler på klientsiden. Serveren kan også beslutte at afslutte, før klienten har sendt alle sine anmodninger.
Klienten eller serveren kan annullere RPC'en til enhver tid. Annullering afslutter RPC øjeblikkeligt, så der udføres ikke yderligere arbejde.
Metadata er information om et bestemt RPC-kald (såsom autentificeringsdetaljer) i form af en liste over nøgleværdi-par, hvor nøgler er strenge og værdier normalt er strenge, men kan være binære data. Metadataene er uigennemsigtige for selve gRPC - det giver klienten mulighed for at give information relateret til opkaldet til serveren og omvendt.
Metadataadgang varierer efter sprog.
En gRPC-kanal giver en forbindelse til en gRPC-server på den angivne vært og port. Bruges ved oprettelse af en klientstub. Klienter kan angive kanalargumenter for at ændre standardadfærden for gRPC, såsom at aktivere eller deaktivere meddelelseskomprimering.
Hvordan gRPC beslutter at lukke kanalen afhænger af sproget. Nogle sprog giver dig også mulighed for at forespørge om en kanals tilstand.
En række forskellige organisationer har taget gRPC til sig som Square , Netflix , IBM , CoreOS , Docker , CockroachDB , Cisco , Juniper Networks , [1] Spotify , [2] og Dropbox . [3]
Open source-projektet u-bmc bruger gRPC i stedet for IPMI . Den 8. januar 2019 annoncerede Dropbox , at den næste version af Courier, deres RPC-framework i hjertet af deres SOA-arkitektur, vil blive migreret til gRPC, primært fordi det stemmer godt overens med deres eksisterende brugerdefinerede RPC-frameworks.