De mult timp nu am reușit să descopăr diferența dintre apelurile RPC (adică Remote Procedure Call) și cele HTTP. Permiteți-mi să râd aici~Naiv! Acest articol prezintă pe scurt cele două forme de arhitectură C/S, în primul rând, cea mai esențială diferență a lor, și anume că RPC se bazează în principal pe protocolul TCP/IP, în timp ce serviciul HTTP se bazează în principal pe protocolul HTTP, știm cu toții că protocolul HTTP este deasupra protocolului de la stratul de transport TCP, deci din punct de vedere al eficienței, RPC este, desigur, mai bun! Să vorbim în detaliu despre serviciile RPC și serviciile HTTP.
Modelul OSI în rețea cu șapte straturi
Înainte de a vorbi despre diferența dintre RPC și HTTP, consider necesar să înțeleg modelul structurii rețelei în șapte straturi al OSI (deși în practică este practic format din cinci straturi), care poate fi împărțit în următoarele straturi: (de sus în jos)
- Primul strat: stratul de aplicare. Sunt definite interfețe pentru comunicații și transmiterea datelor în rețea;
- Al doilea strat: stratul de reprezentare. Definirea formatului de transmisie, specificațiile de codare și decodare a datelor în diferite sisteme etc.;
- Al treilea strat: stratul de conversație. Gestionează sesiunile utilizatorilor și controlează stabilirea și întreruperea conexiunilor logice între utilizatori.
- Al patrulea strat: stratul de transport. Gestionează transmiterea datelor de la un capăt la altul în rețea;
- Stratul 5: Stratul de rețea. Definiți modul în care datele sunt transferate între dispozitivele de rețea;
- Al șaselea strat: stratul de legătură. Pachetele de date ale stratului de rețea de mai sus sunt încapsulate în cadre de date pentru a facilita transmiterea stratului fizic.
- Stratul 7: Stratul fizic. Acest strat se concentrează în principal pe transmiterea acestor date binare.
În aplicarea practică, nu există un strat de prezentare și un strat de sesiune în structura protocolului cu cinci straturi. Trebuie spus că acestea se îmbină cu stratul aplicației. Ar trebui să ne concentrăm pe stratul aplicației și pe stratul de transport. Pentru că HTTP este un protocol la nivelul aplicației, în timp ce TCP este un protocol la nivel de transport. Ei bine, acum că știm modelul de stratificare a rețelei, putem înțelege mai bine de ce serviciile RPC sunt mai bune decât cele HTTP!
Servicii RPC
Serviciile RPC sunt introduse din trei perspective: arhitectura RPC, apeluri asincrone sincrone și cadre RPC populare.
Arhitectura RPC
Să vorbim despre arhitectura de bază a serviciilor RPC. Permiteți-mi să fur rușinos o imagine~ Putem vedea clar că o arhitectură completă RPC conține patru componente de bază, și anume Client, Server, Client Stub și Server Stub, care pot fi înțelese ca un stub. Să vorbim separat despre aceste componente:
- Client, apelantul serviciului.
- Serverul, adevăratul furnizor de servicii.
- Stub-ul clientului stochează mesajul de adresă al serverului, apoi ambalează parametrii cererii clientului într-un mesaj de rețea, trimițându-l apoi către partea de serviciu de la distanță prin rețea.
- Stub-ul de pe partea de server primește mesajele trimise de client, despachetează mesajele și apelează la metode locale.
RPC este folosit în principal în întreprinderile mari, deoarece întreprinderile mari au multe sisteme, linii de afaceri complexe, iar avantajele de eficiență sunt foarte importante. Acest lucru se face în dezvoltarea propriu-zisă, iar proiectele sunt în general gestionate folosind Maven. De exemplu, avem un serviciu de sistem care procesează comenzile, declară mai întâi toate interfețele sale (în special interfața în Java), apoi ambalează întregul proiect într-un pachet jar. De ce să faci asta? Scopul principal este reducerea dimensiunii pachetului jar pe partea clientului, deoarece de fiecare dată când un pachet este lansat, prea multe pachete jar vor afecta întotdeauna eficiența. De asemenea, decuplează clientul de server pentru a îmbunătăți portabilitatea codului.
Apeluri sincrone și asincrone
Ce este apelul sincron? Ce este un apel asincron? Un apel sincron este atunci când clientul așteaptă ca apelul să se finalizeze execuția și returnează rezultatul. Apelurile asincrone înseamnă că clientul nu așteaptă ca apelul să se execute și să returneze rezultatul, dar poate totuși să primească notificarea rezultatului returnat prin funcția de callback. Dacă clientul nu ține cont de rezultat, decizia poate deveni o decizie unilaterală. Acest proces este oarecum similar cu interfețele apelabile și rulabile din Java, când executăm asincron, dacă trebuie să cunoaștem rezultatul execuției, putem folosi interfața apelabilă și putem obține informațiile rezultate ale execuției asincrone prin clasa Future. Dacă nu te interesează rezultatul execuției, poți folosi pur și simplu interfața runnable pentru că nu returnează rezultatul, desigur, apelabilul este de asemenea posibil, nu avem nevoie de viitor.
Cadru RPC popular
Există încă multe cadre RPC open source populare. Iată trei momente de referință:
- gRPC este un software open-source anunțat recent de Google, bazat pe cel mai recent protocol HTTP 2.0, și suportă multe limbaje de programare comune. Știm că HTTP 2.0 este o versiune îmbunătățită a protocolului HTTP bazată pe binar, iar browserele majore îl suportă în prezent într-un ritm rapid. Acest cadru RPC se bazează pe protocolul HTTP, iar cel de bază folosește suportul framework-ului Netty.
- Thrift este un proiect open-source pentru Facebook, în principal un cadru de dezvoltare a serviciilor cross-language. Are un generator de cod pentru a genera automat un cadru de cod de serviciu pentru fișierul de definiție IDL pe care îl definește. Utilizatorii trebuie doar să efectueze dezvoltare secundară înainte de aceasta, iar comunicarea RPC de bază este transparentă. Totuși, pentru utilizatori, există totuși un anumit cost pentru a învăța limbajul unui anumit domeniu.
- Dubbo este un framework RPC bine cunoscut, open source creat de Alibaba Group, care este larg utilizat în multe companii de Internet și aplicații enterprise. Atât protocoalele, cât și cadrele de serializare pot fi conectate. Aceeași interfață la distanță se bazează pe Java Interface și se baza pe framework-ul spring pentru o dezvoltare ușoară. Poate fi ușor ambalat într-un singur fișier și rulat independent, ceea ce este în concordanță cu conceptul actual de microservicii.
Să-ți spun în secret că grupul nu mai folosește prea mult dubbo,Cel mai des folosit acum se numește HSF, cunoscut și ca "atât de confortabil". S-ar putea să existe open source mai târziu, așa că să așteptăm și să vedem.
Serviciu HTTP
De fapt, cu mult timp în urmă, am caracterizat întotdeauna modelul de dezvoltare enterprise ca fiind dezvoltare de interfețe HTTP, ceea ce numim adesea interfețe de servicii în stil RESTful. De fapt, este o metodă de comunicare adesea folosită în stadiile incipiente de rezolvare a insulelor informaționale în cazul puținelor interfețe și a interacțiunii mai reduse între sisteme; Avantajele sunt simple, directe și ușor de dezvoltat. Utilizează protocolul HTTP gata făcut pentru transmitere. Ne amintim că atunci când făceam dezvoltare de fundal în companie înainte, dezvoltam în principal interfețe și trebuia să scriem și un document mare de interfață, indicând strict care erau intrările și ieșirile. Explică metoda de cerere a fiecărei interfețe și aspectele care trebuie luate în considerare în parametrii cererii. De exemplu, următorul exemplu:
POSThttp://www.httpexample.com/restful/buyer/info/share
Interfața poate returna un șir JSON sau un document XML. Clientul procesează apoi aceste informații returnate, permițând o dezvoltare mai rapidă. Totuși, pentru întreprinderile mari, când există multe subsisteme interne și multe interfețe, avantajele cadrului RPC sunt evidențiate; în primul rând, este o legătură lungă și nu este nevoie să strângi mâna de 3 ori ca la http de fiecare dată, reducând astfel costul de rețea; în al doilea rând, cadrul RPC are, în general, un centru de înregistrare și monitorizare și management bogat; Publicarea, interfețele offline, expansiunea dinamică etc. sunt operațiuni non-perceptive și unificate pentru apelant.
rezumat
În general, serviciile RPC sunt destinate în principal întreprinderilor mari, în timp ce serviciile HTTP sunt destinate întreprinderilor mici, deoarece RPC este mai eficient, iar iterațiile de dezvoltare a serviciilor HTTP vor fi mai rapide. Pe scurt, tipul de cadru de ales nu este determinat de ceea ce este popular pe piață, ci de evaluarea completă a întregului proiect, pentru a compara cu atenție impactul celor două cadre de dezvoltare asupra întregului proiect și, în final, a decide care este cel mai potrivit pentru proiect. Nu trebuie să folosim RPC pentru fiecare proiect doar de dragul folosirii RPC, ci să ne adaptăm la condițiile locale și să analizăm situația specifică.
|
Postat pe 01.04.2019 14:02:45
|
|
|
|
