Under lång tid har jag inte listat ut skillnaden mellan RPC (dvs. Remote Procedure Call) och HTTP-anrop. Låt mig skratta här~Naivt! Den här artikeln introducerar kort de två formerna av C/S-arkitektur, först och främst deras mest väsentliga skillnad, nämligen att RPC huvudsakligen baseras på TCP/IP-protokollet, medan HTTP-tjänsten främst bygger på HTTP-protokollet, vi vet alla att HTTP-protokollet ligger ovanpå transportlagrets protokoll TCP, så när det gäller effektivitet är RPC förstås bättre! Låt oss prata om RPC-tjänster och HTTP-tjänster i detalj.
OSI nätverksmodell med sju lager
Innan jag pratar om skillnaden mellan RPC och HTTP anser jag att det är nödvändigt att förstå OSI:s sjulagers nätverksstrukturmodell (även om den i praktiken i princip är fem lager), som kan delas in i följande lager: (från topp till botten)
- Det första lagret: applikationslagret. Gränssnitt för kommunikation och dataöverföring i nätverket definieras;
- Det andra lagret: representationslagret. Definiera överföringsformat, kodnings- och avkodningsspecifikationer för data i olika system, etc.;
- Det tredje lagret: samtalslagret. Hantera användarsessioner och kontrollera upprättandet och avbrottet av logiska anslutningar mellan användare.
- Det fjärde lagret: transportlagret. Den hanterar end-to-end-dataöverföring i nätverket;
- Lager 5: Nätverkslager. Definiera hur data överförs mellan nätverksenheter;
- Sjätte lagret: länklagret. Datapaketen i nätverkslagret ovan kapslas in i dataramar för att underlätta överföringen av det fysiska lagret.
- Lager 7: Fysiskt lager. Detta lager handlar främst om att överföra denna binära data.
I praktisk tillämpning finns det inget presentationslager och sessionslager i den femlagers protokollstrukturen. Det bör sägas att de slås ihop med applikationslagret. Vi bör fokusera på applikationsskidret och transportlagret. Eftersom HTTP är ett applikationslagsprotokoll, medan TCP är ett transportlagerprotokoll. Nu när vi känner till nätverkslagermodellen kan vi bättre förstå varför RPC-tjänster är trevligare än HTTP-tjänster!
RPC-tjänster
RPC-tjänster introduceras från tre perspektiv: RPC-arkitektur, synkrona asynkrona samtal och populära RPC-ramverk.
RPC-arkitektur
Låt oss prata om den grundläggande arkitekturen för RPC-tjänster. Låt mig skamligt stjäla en bild~ Vi kan tydligt se att en komplett RPC-arkitektur innehåller fyra kärnkomponenter, nämligen Client, Server, Client Stub och Server Stub, som kan förstås som en stub. Låt oss prata om dessa komponenter separat:
- Klient, den som ringer upp tjänsten.
- Servern, den verkliga tjänsteleverantören.
- Klientstubben lagrar adressmeddelandet för servern och paketerar sedan klientens förfrågningsparametrar i ett nätverksmeddelande, och skickar det sedan till serviceparten på distans via nätverket.
- Serversidans stub tar emot meddelanden som skickas av klienten, packar upp meddelandena och anropar lokala metoder.
RPC används främst i stora företag eftersom stora företag har många system, komplexa affärsområden och effektivitetsfördelar är mycket viktiga. Detta görs i faktisk utveckling, och projekten hanteras vanligtvis med Maven. Till exempel har vi en systemtjänst som hanterar order, deklarerar först alla dess gränssnitt (här specifikt gränssnittet i Java), och paketerar sedan hela projektet i ett jar-paket. Varför göra detta? Huvudsyftet är att minska storleken på jar-paketet på klientsidan, eftersom varje gång ett paket släpps kommer för många jar-paket alltid att påverka effektiviteten. Den kopplar också bort klient och server för att förbättra kodportabiliteten.
Synkrona och asynkrona samtal
Vad är synkront samtal? Vad är ett asynkront samtal? Ett synkront anrop är när klienten väntar på att anropet ska slutföras och returnerar resultatet. Asynkrona anrop innebär att klienten inte väntar på att anropet ska köras och returnera resultatet, men ändå kan få notifikationen om returresultatet via callback-funktionen. Om klienten inte bryr sig om resultatet kan det bli ett envägssamtal. Denna process liknar något de anropbara och körbara gränssnitten i Java; när vi körs asynkront, om vi behöver veta resultatet av exekveringen, kan vi använda det anropsbara gränssnittet och få resultatinformationen om asynkron exekvering genom Future-klassen. Om du inte bryr dig om exekveringsresultatet kan du bara använda det körbara gränssnittet eftersom det inte returnerar resultatet, självklart är anropbar också möjligt, vi behöver inte skaffa framtiden.
Populärt RPC-ramverk
Det finns fortfarande många populära open source-ramverk för RPC. Här är tre höjdpunkter:
- gRPC är en nyligen tillkännagiven öppen källkodsprogramvara från Google, baserad på det senaste HTTP 2.0-protokollet, och stöder många vanliga programmeringsspråk. Vi vet att HTTP 2.0 är en uppgraderad version av HTTP-protokollet baserat på binär, och stora webbläsare stödjer det för närvarande i snabb takt. Detta RPC-ramverk bygger på HTTP-protokollet, och det underliggande använder stöd från Netty-ramverket.
- Thrift är ett öppen källkodsprojekt för Facebook, främst ett ramverk för tvärspråkig tjänsteutveckling. Den har en kodgenerator som automatiskt genererar ett tjänstekodramverk för IDL-definitionsfilen den definierar. Användare behöver bara genomföra sekundär utveckling innan dess, och den underliggande RPC-kommunikationen är transparent. För användare finns det dock fortfarande en viss kostnad för att lära sig språket inom ett specifikt område.
- Dubbo är ett välkänt RPC-ramverk som är öppen källkod från Alibaba Group, och används flitigt i många internetföretag och företagsapplikationer. Både protokoll och serialiseringsramverk kan kopplas in. Samma fjärrgränssnitt baseras på Java-gränssnittet och förlitar sig på fjäderramverket för enkel utveckling. Den kan enkelt paketeras i en enda fil och köras oberoende, vilket är i linje med det nuvarande konceptet för mikrotjänster.
Säger i hemlighet att gruppen inte använder dubbo så mycket längre,Den som används mest nu kallas HSF, även känd som "så bekväm". Det kan finnas öppen källkod senare, så låt oss vänta och se.
HTTP-tjänst
Faktum är att jag för länge sedan alltid har beskrivit företagsutvecklingsmodellen som HTTP-gränssnittsutveckling, vilket är vad vi ofta kallar RESTful-liknande tjänstegränssnitt. Det är faktiskt en kommunikationsmetod som ofta används i det tidiga skedet av att lösa informationsöar vid få gränssnitt och mindre interaktion mellan system; Fördelarna är enkla, direkta och lätta att utveckla. Använd det färdiga HTTP-protokollet för överföring. Vi minns att när vi tidigare gjorde bakgrundsutveckling i företaget utvecklade vi främst gränssnitt, och vi var också tvungna att skriva ett stort gränssnittsdokument som strikt angav vad in- och utdata var. Förklara förfrågningsmetoden för varje gränssnitt och de frågor som behöver uppmärksammas i förfrågningsparametrarna. Till exempel, följande exempel:
POSThttp://www.httpexample.com/restful/buyer/info/share
Gränssnittet kan returnera en JSON-sträng eller ett XML-dokument. Klienten bearbetar sedan denna returnerade information, vilket möjliggör snabbare utveckling. Men för stora företag, när det finns många interna delsystem och många gränssnitt, visas fördelarna med RPC-ramverket, för det första är det en lång länk och det finns inget behov av att skaka hand tre gånger som med http varje gång, vilket minskar nätverksöverhead; för det andra har RPC-ramverket generellt ett registreringscenter och en omfattande övervakning och förvaltning; Publicering, offline-gränssnitt, dynamisk expansion med mera är icke-perceptiva och enhetliga operationer för anroparen.
sammanfattning
Generellt sett är RPC-tjänster främst för stora företag, medan HTTP-tjänster främst är för små företag, eftersom RPC är mer effektivt och HTTP-tjänstutvecklingsiterationer går snabbare. Kort sagt, vilken typ av ramverk som ska väljas bestäms inte av vad som är populärt på marknaden, utan av att utvärdera hela projektet fullständigt, för att noggrant kunna jämföra effekterna av de två utvecklingsramarna på hela projektet och slutligen avgöra vad som är mest lämpligt för projektet. Vi får inte använda RPC för varje projekt bara för att använda RPC, utan anpassa oss till lokala förhållanden och analysera den specifika situationen.
|
Publicerad på 2019-04-01 14:02:45
|
|
|
|
