Ilgu laiku es neesmu izdomājis atšķirību starp RPC (t.i., attālās procedūras zvanu) un HTTP zvaniem. Lūdzu, ļaujiet man smieties šeit ~ Naivs! Šis raksts īsumā iepazīstina ar divām C / S arhitektūras formām, pirmkārt, to būtiskāko atšķirību, tas ir, RPC galvenokārt balstās uz TCP / IP protokolu, bet HTTP pakalpojums galvenokārt ir balstīts uz HTTP protokolu, mēs visi zinām, ka HTTP protokols ir virs transporta slāņa protokola TCP, tāpēc efektivitātes ziņā RPC, protams, ir labāks! Detalizēti runāsim par RPC pakalpojumiem un HTTP pakalpojumiem.
OSI tīkla septiņu slāņu modelis
Pirms runāt par atšķirību starp RPC un HTTP, es uzskatu, ka ir jāsaprot OSI septiņu slāņu tīkla struktūras modelis (lai gan praksē tas būtībā ir pieci slāņi), ko var iedalīt šādos slāņos: (no augšas uz leju)
- Pirmais slānis: pielietojuma slānis. Ir definētas saskarnes saziņai un datu pārraidei tīklā;
- Otrais slānis: reprezentācijas slānis. Definēt datu pārraides formātu, kodēšanas un dekodēšanas specifikācijas dažādās sistēmās utt.;
- Trešais slānis: sarunu slānis. Pārvaldiet lietotāju sesijas un kontrolējiet loģisko savienojumu izveidi un pārtraukšanu starp lietotājiem.
- Ceturtais slānis: transporta slānis. Tas pārvalda datu pārraidi tīklā no gala līdz galam;
- 5. slānis: tīkla slānis. Definēt, kā dati tiek pārsūtīti starp tīkla ierīcēm;
- Sestais slānis: saišu slānis. Iepriekš minētā tīkla slāņa datu paketes ir iekapsulētas datu rāmjos, lai atvieglotu fiziskā slāņa pārraidi.
- 7. slānis: fiziskais slānis. Šis slānis galvenokārt attiecas uz šo bināro datu pārsūtīšanu.
Praktiskā pielietojumā piecu slāņu protokola struktūrā nav prezentācijas slāņa un sesijas slāņa. Jāsaka, ka tie saplūst ar lietojumprogrammu slāni. Mums jākoncentrējas uz pielietojuma slāni un transporta slāni. Tā kā HTTP ir lietojumprogrammu slāņa protokols, bet TCP ir transporta slāņa protokols. Nu, tagad, kad mēs zinām tīkla slāņošanas modeli, mēs varam labāk saprast, kāpēc RPC pakalpojumi ir jaukāki par HTTP pakalpojumiem!
RPC pakalpojumi
RPC pakalpojumi tiek ieviesti no trim perspektīvām: RPC arhitektūra, sinhroni asinhroni zvani un populāri RPC ietvari.
RPC arhitektūra
Runāsim par RPC pakalpojumu pamatarhitektūru. Ļaujiet man apkaunojoši nozagt attēlu ~ Mēs varam skaidri redzēt, ka pilnīga RPC arhitektūra satur četrus galvenos komponentus, proti, Client, Server, Client Stub un Server Stub, ko var saprast kā stub. Runāsim par šiem komponentiem atsevišķi:
- Klients, pakalpojuma zvanītājs.
- Serveris, īstais pakalpojumu sniedzējs.
- Klienta stub saglabā servera adreses ziņojumu un pēc tam iepako klienta pieprasījuma parametrus tīkla ziņojumā un pēc tam nosūta to pakalpojuma pusei attālināti, izmantojot tīklu.
- Servera puses stumbrs saņem klienta sūtītos ziņojumus, izsaiņo ziņojumus un izsauc vietējās metodes.
RPC galvenokārt izmanto lielos uzņēmumos, jo lieliem uzņēmumiem ir daudz sistēmu, sarežģītas biznesa līnijas, un efektivitātes priekšrocības ir ļoti svarīgas. Tas tiek darīts faktiskajā izstrādē, un projekti parasti tiek pārvaldīti, izmantojot maven. Piemēram, mums ir sistēmas pakalpojums, kas apstrādā pasūtījumus, vispirms deklarē visas tās saskarnes (šeit īpaši saskarni Java) un pēc tam visu projektu iesaiņo burkas paketē. Kāpēc to darīt? Galvenais mērķis ir samazināt burku iepakojuma lielumu klienta pusē, jo katru reizi, kad iepakojums tiek izlaists, pārāk daudz burku iepakojumu vienmēr ietekmēs efektivitāti. Tas arī atvieno klientu un serveri, lai uzlabotu koda pārnesamību.
Sinhroni un asinhroni zvani
Kas ir sinhronais zvans? Kas ir asinhronais zvans? Sinhronais zvans ir tad, kad klients gaida, kamēr zvans tiek pabeigts, un atgriež rezultātu. Asinhroni zvani nozīmē, ka klients negaida, kamēr zvans tiks izpildīts un atgriezīs rezultātu, bet joprojām var saņemt paziņojumu par atgriešanās rezultātu, izmantojot atzvanīšanas funkciju. Ja klientam nerūp rezultāts, tas var pārvērsties par vienvirziena zvanu. Šis process ir nedaudz līdzīgs izsaucamajām un palaižamajām saskarnēm Java, kad mēs izpildām asinhroni, ja mums ir jāzina izpildes rezultāts, mēs varam izmantot izsaucamo interfeisu, un mēs varam iegūt asinhronās izpildes rezultātu informāciju, izmantojot nākotnes klasi. Ja jums nerūp izpildes rezultāts, varat vienkārši izmantot palaižamo interfeisu, jo tas neatgriež rezultātu, protams, ir iespējams arī izsaucams, mums nav jāiegūst nākotne.
Populārs RPC ietvars
Joprojām ir daudz populāru atvērtā koda RPC ietvaru. Šeit ir trīs svarīgākie aspekti:
- gRPC ir nesen izziņota Google atvērtā pirmkoda programmatūra, kuras pamatā ir jaunākais HTTP 2.0 protokols, un atbalsta daudzas izplatītas programmēšanas valodas. Mēs zinām, ka HTTP 2.0 ir uzlabota HTTP protokola versija, kuras pamatā ir binārais, un lielākās pārlūkprogrammas pašlaik to atbalsta strauji. Šī RPC sistēma ir balstīta uz HTTP protokolu, un pamatā izmanto Netty struktūras atbalstu.
- Taupība ir atvērtā koda projekts Facebook, galvenokārt starpvalodu pakalpojumu izstrādes sistēma. Tam ir koda ģenerators, lai automātiski ģenerētu pakalpojuma koda ietvaru tā definētajam IDL definīcijas failam. Lietotājiem pirms tam ir jāveic tikai sekundārā izstrāde, un pamatā esošā RPC komunikācija ir caurspīdīga. Tomēr lietotājiem joprojām ir zināmas izmaksas, lai apgūtu konkrētas jomas valodu.
- Dubbo ir labi pazīstams Alibaba Group RPC ietvara atvērtais kods, ko plaši izmanto daudzos interneta uzņēmumos un uzņēmumu lietojumprogrammās. Var pievienot gan protokolus, gan serializācijas sistēmas. Tas pats attālais interfeiss ir balstīts uz Java interfeisu un paļaujas uz pavasara ietvaru ērtai izstrādei. To var viegli iepakot vienā failā un palaist neatkarīgi, kas atbilst pašreizējai mikropakalpojumu koncepcijai.
Slepeni pastāstiet, ka grupa vairs daudz neizmanto dubbo,Tas, kas tagad tiek biežāk izmantots, tiek saukts par HSF, kas pazīstams arī kā "tik ērts". Vēlāk var būt atvērtais kods, tāpēc gaidīsim un redzēsim.
HTTP pakalpojums
Patiesībā jau sen es vienmēr esmu raksturojis uzņēmuma attīstības modeli kā HTTP interfeisa izstrādi, ko mēs bieži saucam par RESTful stila pakalpojumu saskarnēm. Patiešām, tā ir komunikācijas metode, ko bieži izmanto informācijas salu risināšanas agrīnā stadijā, ja ir maz saskarņu un mazāka mijiedarbība starp sistēmām; Priekšrocības ir vienkāršas, tiešas un viegli attīstāmas. Izmantojiet gatavo HTTP protokolu pārraidei. Mēs atceramies, ka, veicot fona izstrādi uzņēmumā, mēs galvenokārt izstrādājām saskarnes, un mums bija arī jāraksta liels interfeisa dokuments, stingri norādot, kāda bija ieeja un izeja. Izskaidrojiet katras saskarnes pieprasījuma metodi un jautājumus, kuriem jāpievērš uzmanība pieprasījuma parametros. Piemēram, šāds piemērs:
AMATShttp://www.httpexample.com/restful/buyer/info/share
Interfeiss var atgriezt JSON virkni vai XML dokumentu. Pēc tam klients apstrādā šo atgriezto informāciju, ļaujot ātrāk attīstīties. Tomēr lieliem uzņēmumiem, kad ir daudz iekšējo apakšsistēmu un daudzas saskarnes, tiek parādītas RPC sistēmas priekšrocības, pirmkārt, tā ir gara saite, un nav nepieciešams katru reizi kratīt rokas 3 reizes, piemēram, http, samazinot tīkla pieskaitāmās izmaksas; otrkārt, RPC sistēmai parasti ir reģistrācijas centrs un bagātīga uzraudzība un pārvaldība; Publicēšana, bezsaistes saskarnes, dinamiskā paplašināšana utt.
Kopsavilkuma
Vispārīgi runājot, RPC pakalpojumi galvenokārt ir paredzēti lieliem uzņēmumiem, savukārt HTTP pakalpojumi galvenokārt ir paredzēti maziem uzņēmumiem, jo RPC ir efektīvāks un HTTP pakalpojumu izstrādes iterācijas būs ātrākas. Īsāk sakot, to, kāda veida ietvaru izvēlēties, nenosaka tas, kas ir populārs tirgū, bet gan pilnībā novērtēt visu projektu, lai rūpīgi salīdzinātu abu attīstības ietvaru ietekmi uz visu projektu un visbeidzot izlemtu, kas ir vispiemērotākais projektam. Mēs nedrīkstam izmantot RPC katram projektam, lai izmantotu RPC, bet pielāgoties vietējiem apstākļiem un analizēt konkrēto situāciju.
|
Publicēts 01.04.2019 14:02:45
|
|
|
|
