I lang tid har jeg ikke funnet ut forskjellen mellom RPC (altså Remote Procedure Call) og HTTP-kall. Vær så snill, la meg le her~Naiv! Denne artikkelen introduserer kort de to formene for C/S-arkitektur, først og fremst deres viktigste forskjell, nemlig at RPC hovedsakelig er basert på TCP/IP-protokollen, mens HTTP-tjenesten hovedsakelig er basert på HTTP-protokollen. Vi vet alle at HTTP-protokollen ligger på toppen av transportlagsprotokollen TCP, så når det gjelder effektivitet, er RPC selvfølgelig bedre! La oss snakke i detalj om RPC-tjenester og HTTP-tjenester.
OSI-nettverkets syvlagsmodell
Før jeg snakker om forskjellen mellom RPC og HTTP, mener jeg det er nødvendig å forstå OSI sin syv-lags nettverksstrukturmodell (selv om den i praksis i praksis er fem lag), som kan deles inn i følgende lag: (fra topp til bunn)
- Det første laget: applikasjonslaget. Grensesnitt for kommunikasjon og dataoverføring i nettverket er definert;
- Det andre laget: representasjonslaget. Definere overføringsformat, kodings- og dekodingsspesifikasjoner for data i ulike systemer, osv.;
- Det tredje laget: samtalelaget. Administrer brukersesjoner og kontroller etablering og avbrudd av logiske forbindelser mellom brukere.
- Det fjerde laget: transportlaget. Den håndterer ende-til-ende dataoverføring i nettverket;
- Lag 5: Nettverkslag. Definer hvordan data overføres mellom nettverksenheter;
- Sjette lag: lenkelag. Datapakkene i nettverkslaget ovenfor er kapslet inn i datarammer for å lette overføringen av det fysiske laget.
- Lag 7: Fysisk lag. Dette laget handler hovedsakelig om å overføre disse binære dataene.
I praktisk anvendelse finnes det verken presentasjonslag eller sesjonslag i protokollstrukturen med fem lag. Det bør sies at de smelter sammen med applikasjonslaget. Vi bør fokusere på applikasjonslaget og transportlaget. Fordi HTTP er en applikasjonslagsprotokoll, mens TCP er en transportlagsprotokoll. Vel, nå som vi kjenner nettverkslag-modellen, kan vi bedre forstå hvorfor RPC-tjenester er bedre enn HTTP-tjenester!
RPC-tjenester
RPC-tjenester introduseres fra tre perspektiver: RPC-arkitektur, synkrone asynkrone kall og populære RPC-rammeverk.
RPC-arkitektur
La oss snakke om den grunnleggende arkitekturen til RPC-tjenester. La meg skamfullt stjele et bilde~ Vi kan tydelig se at en komplett RPC-arkitektur inneholder fire kjernekomponenter, nemlig Client, Server, Client Stub og Server Stub, som kan forstås som en stub. La oss snakke om disse komponentene separat:
- Klient, den som ringer tjenesten.
- Server, den ekte tjenesteleverandøren.
- Klientstubben lagrer adressemeldingen til serveren, og pakker deretter klientens forespørselsparametere inn i en nettverksmelding, og sender den deretter til tjenesteparten eksternt gjennom nettverket.
- Server-side stubben mottar meldinger sendt av klienten, pakker ut meldingene og kaller lokale metoder.
RPC brukes hovedsakelig i store bedrifter, fordi store virksomheter har mange systemer, komplekse forretningsområder, og effektivitetsfordeler er svært viktige. Dette gjøres i selve utviklingen, og prosjektene styres vanligvis med Maven. For eksempel har vi en systemtjeneste som behandler ordre, først erklærer alle grensesnittene (her spesielt grensesnittet i Java), og deretter pakker hele prosjektet i en jar-pakke. Hvorfor gjøre dette? Hovedformålet er å redusere størrelsen på jar-pakken på klientsiden, fordi hver gang en pakke slippes, vil for mange jar-pakker alltid påvirke effektiviteten. Den kobler også fra klient og server for å forbedre kodeportabiliteten.
Synkrone og asynkrone kall
Hva er synkron samtale? Hva er en asynkron samtale? Et synkront kall er når klienten venter på at kallet skal fullføres og returnerer resultatet. Asynkrone kall betyr at klienten ikke venter på at kallet skal utføres og returnere resultatet, men likevel kan motta varsling om returresultatet gjennom callback-funksjonen. Hvis kunden ikke bryr seg om utfallet, kan det bli en enveissamtale. Denne prosessen ligner noe på de kallbare og kjørbare grensesnittene i Java; når vi kjører asynkront, hvis vi trenger å vite resultatet av utførelsen, kan vi bruke det kallbare grensesnittet, og vi kan hente resultatinformasjonen for asynkron utførelse gjennom Future-klassen. Hvis du ikke bryr deg om utførelsesresultatet, kan du bare bruke det kjørbare grensesnittet fordi det ikke returnerer resultatet, selvfølgelig er kallbart også mulig, vi trenger ikke å få fremtiden.
Populært RPC-rammeverk
Det finnes fortsatt mange populære åpen kildekode-RPC-rammeverk. Her er tre høydepunkter:
- gRPC er en nylig annonsert åpen kildekode-programvare fra Google, basert på den nyeste HTTP 2.0-protokollen, og støtter mange vanlige programmeringsspråk. Vi vet at HTTP 2.0 er en oppgradert versjon av HTTP-protokollen basert på binær, og store nettlesere støtter det for tiden i høyt tempo. Dette RPC-rammeverket er basert på HTTP-protokollen, og den underliggende bruker støtte fra Netty-rammeverket.
- Thrift er et åpen kildekode-prosjekt for Facebook, primært et nettverk for utvikling av tjenester på tvers av språk. Den har en kodegenerator som automatisk genererer et tjenestekoderammeverk for IDL-definisjonsfilen den definerer. Brukere trenger kun å gjennomføre sekundærutvikling før det, og den underliggende RPC-kommunikasjonen er transparent. For brukerne er det imidlertid fortsatt en viss kostnad å lære språket i et spesifikt felt.
- Dubbo er et velkjent RPC-rammeverk som er åpen kildekode fra Alibaba Group, og er mye brukt i mange internettselskaper og bedriftsapplikasjoner. Både protokoller og serialiseringsrammeverk kan kobles til. Det samme eksterne grensesnittet er basert på Java-grensesnittet og er avhengig av Spring-rammeverket for enkel utvikling. Den kan enkelt pakkes inn i én fil og kjøres uavhengig, noe som er i tråd med dagens konsept for mikrotjenester.
I hemmelighet forteller jeg deg at gruppen ikke bruker dubbo så mye lenger,Den som brukes mest nå kalles HSF, også kjent som «så komfortabel». Det kan bli åpen kildekode senere, så la oss vente og se.
HTTP-tjeneste
Faktisk har jeg for lenge siden alltid karakterisert bedriftsutviklingsmodellen som HTTP-grensesnittutvikling, som vi ofte kaller RESTful-stil tjenestegrensesnitt. Faktisk er det en kommunikasjonsmetode som ofte brukes i de tidlige fasene av å løse informasjonsøyer i tilfelle få grensesnitt og mindre interaksjon mellom systemene; Fordelene er enkle, direkte og enkle å utvikle. Bruk den ferdiglagde HTTP-protokollen for overføring. Vi husker at da vi drev med bakgrunnsutvikling i selskapet tidligere, utviklet vi hovedsakelig grensesnitt, og vi måtte også skrive et stort grensesnittdokument som strengt viste hva input og output var. Forklar forespørselsmetoden for hvert grensesnitt og hvilke forhold som må tas hensyn til i forespørselsparametrene. For eksempel, følgende eksempel:
POSThttp://www.httpexample.com/restful/buyer/info/share
Grensesnittet kan returnere en JSON-streng eller et XML-dokument. Klienten behandler deretter denne returnerte informasjonen, noe som gir raskere utvikling. Men for store bedrifter, når det finnes mange interne delsystemer og mange grensesnitt, vises fordelene med RPC-rammeverket, først og fremst er det en lang lenke, og det er ikke nødvendig å håndhilse tre ganger som http hver gang, noe som reduserer nettverksoverhead; for det andre har RPC-rammeverket vanligvis et registreringssenter og rik overvåking og forvaltning; Publisering, offline-grensesnitt, dynamisk utvidelse osv. er ikke-perceptive og enhetlige operasjoner for innringeren.
sammendrag
Generelt sett er RPC-tjenester hovedsakelig for store bedrifter, mens HTTP-tjenester hovedsakelig er for små bedrifter, fordi RPC er mer effektivt, og HTTP-tjenesteutviklingsiterasjoner vil gå raskere. Kort sagt, hvilken type rammeverk som skal velges ikke av hva som er populært i markedet, men av å evaluere hele prosjektet fullstendig, slik at man nøye kan sammenligne virkningen av de to utviklingsrammeverkene på hele prosjektet, og til slutt avgjøre hva som er mest egnet for prosjektet. Vi må ikke bruke RPC for hvert prosjekt bare for å bruke RPC, men tilpasse oss lokale forhold og analysere den spesifikke situasjonen.
|
Publisert på 01.04.2019 14:02:45
|
|
|
|
