I lang tid har jeg ikke fundet ud af forskellen mellem RPC (dvs. Remote Procedure Call) og HTTP-kald. Lad mig grine her~Naiv! Denne artikel introducerer kort de to former for C/S-arkitektur, først og fremmest deres mest væsentlige forskel, nemlig at RPC hovedsageligt er baseret på TCP/IP-protokollen, mens HTTP-tjenesten hovedsageligt er baseret på HTTP-protokollen; vi ved alle, at HTTP-protokollen ligger oven på transportlagsprotokollen TCP, så hvad angår effektivitet, er RPC selvfølgelig bedre! Lad os tale om RPC-tjenester og HTTP-tjenester i detaljer.
OSI-netværkets syv-lags model
Før jeg taler om forskellen mellem RPC og HTTP, mener jeg, det er nødvendigt at forstå OSIs syv-lags netværksstrukturmodel (selvom det i praksis grundlæggende er fem lag), som kan opdeles i følgende lag: (fra top til bund)
- Det første lag: applikationslaget. Grænseflader til kommunikation og datatransmission i netværket er defineret;
- Det andet lag: repræsentationslaget. Definer transmissionsformat, kodnings- og dekodningsspecifikationer for data i forskellige systemer osv.;
- Det tredje lag: samtalelaget. Styr brugersessioner og kontroller etablering og afbrydelse af logiske forbindelser mellem brugere.
- Det fjerde lag: transportlaget. Den håndterer end-to-end datatransmission i netværket;
- Lag 5: Netværkslag. Definer, hvordan data overføres mellem netværksenheder;
- Sjette lag: linklag. Datapakkerne i netværkslaget ovenfor er indkapslet i datarammer for at lette transmissionen af det fysiske lag.
- Lag 7: Fysisk lag. Dette lag handler hovedsageligt om at transmittere disse binære data.
I praksis findes der ikke noget præsentationslag og sessionslag i den femlags protokolstruktur. Det skal siges, at de smelter sammen med applikationslaget. Vi bør fokusere på applikationslaget og transportlaget. Fordi HTTP er en applikationslagsprotokol, mens TCP er en transportlagsprotokol. Nu hvor vi kender netværkslagsmodellen, kan vi bedre forstå, hvorfor RPC-tjenester er bedre end HTTP-tjenester!
RPC-tjenester
RPC-tjenester introduceres fra tre perspektiver: RPC-arkitektur, synkrone asynkrone kald og populære RPC-rammeværker.
RPC-arkitektur
Lad os tale om den grundlæggende arkitektur for RPC-tjenester. Tillad mig skamfuldt at stjæle et billede~ Vi kan tydeligt se, at en komplet RPC-arkitektur indeholder fire kernekomponenter, nemlig klient, server, klientstub og serverstub, som kan forstås som en stub. Lad os tale om disse komponenter hver for sig:
- Klient, opkalderen af tjenesten.
- Server, den rigtige tjenesteudbyder.
- Klientstubben gemmer serverens adressebesked og pakker derefter klientens anmodningsparametre ind i en netværksbesked, som derefter sendes til serviceparten eksternt gennem netværket.
- Server-side stubben modtager beskeder sendt af klienten, pakker beskederne ud og kalder lokale metoder.
RPC anvendes hovedsageligt i store virksomheder, fordi store virksomheder har mange systemer, komplekse forretningsområder, og effektivitetsfordele er meget vigtige. Dette sker i selve udviklingen, og projekter styres generelt med Maven. For eksempel har vi en systemservice, der behandler ordrer, først erklærer alle dens interfaces (her specifikt interfacet i Java), og derefter pakker hele projektet i en jar-pakke. Hvorfor gøre det? Hovedformålet er at reducere størrelsen på jar-pakken på klientsiden, fordi hver gang en pakke frigives, vil for mange jar-pakker altid påvirke effektiviteten. Det adskiller også klient og server for at forbedre kodeportabiliteten.
Synkrone og asynkrone kald
Hvad er synkront opkald? Hvad er et asynkront opkald? Et synkront kald er, når klienten venter på, at kaldet er færdigt, og returnerer resultatet. Asynkrone kald betyder, at klienten ikke venter på, at kaldet bliver udført og returnerer resultatet, men stadig kan modtage notifikationen om returresultatet via callback-funktionen. Hvis klienten ikke bekymrer sig om resultatet, kan det ende som et envejsopkald. Denne proces ligner noget de kaldbare og kørbare grænseflader i Java; når vi udfører asynkront, kan vi, hvis vi skal kende resultatet af eksekveringen, bruge det kaldbare interface, og vi kan opnå resultatinformationen om asynkron eksekvering gennem Future-klassen. Hvis du ikke går op i udførelsesresultatet, kan du bare bruge det kørende interface, fordi det ikke returnerer resultatet, selvfølgelig er callable også muligt, vi behøver ikke at få fremtiden.
Populær RPC-ramme
Der findes stadig mange populære open source RPC-frameworks. Her er tre højdepunkter:
- gRPC er en nyligt annonceret open source-software fra Google, baseret på den nyeste HTTP 2.0-protokol, og understøtter mange almindelige programmeringssprog. Vi ved, at HTTP 2.0 er en opgraderet version af HTTP-protokollen baseret på binær, og store browsere understøtter det i øjeblikket i et hurtigt tempo. Dette RPC-framework er baseret på HTTP-protokollen, og det underliggende bruger understøttelsen fra Netty-frameworket.
- Thrift er et open source-projekt for Facebook, primært en tværsproglig serviceudviklingsramme. Den har en kodegenerator til automatisk at generere et servicekode-framework for den IDL-definitionsfil, den definerer. Brugerne behøver kun at udføre sekundær udvikling før det, og den underliggende RPC-kommunikation er gennemsigtig. Dog er der stadig en vis pris for brugerne ved at lære sproget inden for et bestemt felt.
- Dubbo er et velkendt RPC-framework open source fra Alibaba Group, som er bredt anvendt i mange internetvirksomheder og virksomhedsapplikationer. Både protokoller og serialiseringsrammeværk kan tilsluttes. Den samme fjerngrænseflade er baseret på Java-grænsefladen og er afhængig af fjederrammen for nem udvikling. Det kan nemt pakkes i en enkelt fil og køres uafhængigt, hvilket er i overensstemmelse med det nuværende koncept for mikrotjenester.
Hemmeligt fortælle dig, at gruppen ikke bruger dubbo så meget længere,Den, der bruges mest i dag, kaldes HSF, også kendt som "så behagelig". Der kan komme open source senere, så lad os vente og se.
HTTP-tjeneste
Faktisk har jeg for længe siden altid karakteriseret enterprise-udviklingsmodellen som HTTP-grænsefladeudvikling, hvilket er det, vi ofte kalder RESTful-stil servicegrænseflader. Det er faktisk en kommunikationsmetode, der ofte bruges i de tidlige faser af løsning af informationsøer i tilfælde af få grænseflader og mindre interaktion mellem systemer; Fordelene er enkle, direkte og nemme at udvikle. Brug den færdiglavede HTTP-protokol til transmission. Vi husker, at da vi tidligere lavede baggrundsudvikling i virksomheden, udviklede vi primært grænseflader, og vi skulle også skrive et stort interface-dokument, der nøje angivede, hvad input og output var. Forklar anmodningsmetoden for hvert interface og de forhold, der skal tages hensyn til i anmodningsparametrene. For eksempel, følgende eksempel:
POSThttp://www.httpexample.com/restful/buyer/info/share
Grænsefladen kan returnere en JSON-streng eller et XML-dokument. Klienten behandler derefter denne returnerede information, hvilket muliggør hurtigere udvikling. Men for store virksomheder, hvor der er mange interne delsystemer og mange grænseflader, vises fordelene ved RPC-rammeværket, først og fremmest er det en lang forbindelse, og der er ikke behov for at give hånd tre gange som http hver gang, hvilket reducerer netværksoverhead; for det andet har RPC-rammen generelt et registreringscenter og rig overvågning og ledelse; Publicering, offline-grænseflader, dynamisk udvidelse osv. er ikke-perceptive og ensartede operationer for opkalderen.
resumé
Generelt er RPC-tjenester primært til store virksomheder, mens HTTP-tjenester primært er til små virksomheder, fordi RPC er mere effektivt, og HTTP-serviceudviklingsiterationer vil være hurtigere. Kort sagt, hvilken slags ramme man vælger, bestemmes ikke af, hvad der er populært på markedet, men af at evaluere hele projektet fuldstændigt, så man nøje kan sammenligne virkningen af de to udviklingsrammer på hele projektet og til sidst beslutte, hvad der er mest egnet til projektet. Vi må ikke bruge RPC til hvert projekt for at bruge RPC, men tilpasse os lokale forhold og analysere den specifikke situation.
|
Opslået på 01/04/2019 14.02.45
|
|
|
|
