Ilgą laiką nesupratau skirtumo tarp RPC (ty nuotolinio procedūros skambučio) ir HTTP skambučių. Leiskite man juoktis čia ~ Naivus! Šiame straipsnyje trumpai pristatomos dvi C/S architektūros formos, visų pirma, esminis jų skirtumas, tai yra, RPC daugiausia pagrįstas TCP/IP protokolu, o HTTP paslauga daugiausia pagrįsta HTTP protokolu, visi žinome, kad HTTP protokolas yra transporto sluoksnio protokolo TCP viršuje, todėl efektyvumo požiūriu RPC, žinoma, yra geresnis! Išsamiai pakalbėkime apie RPC paslaugas ir HTTP paslaugas.
OSI tinklo septynių sluoksnių modelis
Prieš kalbant apie skirtumą tarp RPC ir HTTP, manau, kad būtina suprasti OSI septynių sluoksnių tinklo struktūros modelį (nors praktiškai tai iš esmės yra penki sluoksniai), kurį galima suskirstyti į šiuos sluoksnius: (iš viršaus į apačią)
- Pirmasis sluoksnis: aplikacijos sluoksnis. Apibrėžiamos ryšio ir duomenų perdavimo tinkle sąsajos;
- Antrasis sluoksnis: reprezentacinis sluoksnis. Apibrėžti duomenų perdavimo formatą, kodavimo ir dekodavimo specifikacijas skirtingose sistemose ir kt.;
- Trečiasis sluoksnis: pokalbio sluoksnis. Valdykite vartotojų sesijas ir kontroliuokite loginių ryšių tarp vartotojų užmezgimą ir nutraukimą.
- Ketvirtasis sluoksnis: transportavimo sluoksnis. Jis valdo duomenų perdavimą tinkle nuo galo iki galo;
- 5 sluoksnis: tinklo sluoksnis. Apibrėžkite, kaip duomenys perduodami tarp tinklo įrenginių;
- Šeštasis sluoksnis: nuorodų sluoksnis. Aukščiau esančio tinklo sluoksnio duomenų paketai yra įtraukti į duomenų rėmus, kad būtų lengviau perduoti fizinį sluoksnį.
- 7 sluoksnis: fizinis sluoksnis. Šis sluoksnis daugiausia susijęs su šių dvejetainių duomenų perdavimu.
Praktiniame pritaikyme penkių sluoksnių protokolo struktūroje nėra pristatymo sluoksnio ir sesijos sluoksnio. Reikėtų pasakyti, kad jie susilieja su programos sluoksniu. Turėtume sutelkti dėmesį į taikymo sluoksnį ir transportavimo sluoksnį. Kadangi HTTP yra programos lygmens protokolas, o TCP yra transportavimo lygmens protokolas. Na, o dabar, kai žinome tinklo sluoksniavimo modelį, galime geriau suprasti, kodėl RPC paslaugos yra gražesnės nei HTTP paslaugos!
RPC paslaugos
RPC paslaugos pristatomos iš trijų perspektyvų: RPC architektūros, sinchroninių asinchroninių skambučių ir populiarių RPC sistemų.
RPC architektūra
Pakalbėkime apie pagrindinę RPC paslaugų architektūrą. Leiskite man gėdingai pavogti paveikslėlį~ Aiškiai matome, kad pilną RPC architektūrą sudaro keturi pagrindiniai komponentai, būtent Klientas, Serveris, Kliento Stub ir Serverio Stub, kurie gali būti suprantami kaip stub. Pakalbėkime apie šiuos komponentus atskirai:
- Klientas, paslaugos skambintojas.
- Serveris, tikrasis paslaugų teikėjas.
- Kliento stub saugo serverio adreso pranešimą, tada supakuoja kliento užklausos parametrus į tinklo pranešimą, o tada siunčia jį aptarnavimo šaliai nuotoliniu būdu per tinklą.
- Serverio pusės stub gauna kliento siunčiamus pranešimus, išpakuoja pranešimus ir skambina vietiniais metodais.
RPC daugiausia naudojamas didelėse įmonėse, nes didelės įmonės turi daug sistemų, sudėtingų verslo linijų, o efektyvumo pranašumai yra labai svarbūs. Tai daroma faktinio vystymosi metu, o projektai paprastai valdomi naudojant maven. Pavyzdžiui, turime sistemos paslaugą, kuri apdoroja užsakymus, pirmiausia deklaruoja visas savo sąsajas (čia konkrečiai sąsają Java), o tada supakuoja visą projektą į jar paketą. Kodėl tai daryti? Pagrindinis tikslas yra sumažinti stiklainio pakuotės dydį kliento pusėje, nes kiekvieną kartą išleidus pakuotę, per daug stiklainių pakuočių visada turės įtakos efektyvumui. Jis taip pat atsieja klientą ir serverį, kad pagerintų kodo perkeliamumą.
Sinchroniniai ir asinchroniniai skambučiai
Kas yra sinchroninis skambutis? Kas yra asinchroninis skambutis? Sinchroninis skambutis yra tada, kai klientas laukia, kol skambutis bus baigtas, ir pateikia rezultatą. Asinchroniniai skambučiai reiškia, kad klientas nelaukia, kol skambutis bus įvykdytas ir grąžins rezultatą, bet vis tiek gali gauti pranešimą apie grąžinimo rezultatą per atgalinio skambinimo funkciją. Jei klientui nerūpi rezultatas, tai gali virsti vienpusiu skambučiu. Šis procesas yra šiek tiek panašus į iškviečiamas ir paleidžiamas sąsajas "Java", kai vykdome asinchroniškai, jei mums reikia žinoti vykdymo rezultatą, galime naudoti iškviečiamą sąsają ir asinchroninio vykdymo rezultatų informaciją galime gauti per ateities klasę. Jei jums nerūpi vykdymo rezultatas, galite tiesiog naudoti paleidžiamą sąsają, nes ji negrąžina rezultato, žinoma, galima ir iškviečiama, mums nereikia gauti ateities.
Populiari RPC sistema
Vis dar yra daug populiarių atvirojo kodo RPC sistemų. Štai trys svarbiausi dalykai:
- gRPC yra neseniai paskelbta "Google" atvirojo kodo programinė įranga, pagrįsta naujausiu HTTP 2.0 protokolu ir palaikanti daugelį įprastų programavimo kalbų. Žinome, kad HTTP 2.0 yra atnaujinta HTTP protokolo versija, pagrįsta dvejetainiu pagrindu, o pagrindinės naršyklės šiuo metu ją palaiko sparčiai. Ši RPC sistema yra pagrįsta HTTP protokolu, o pagrindinė naudoja Netty sistemos palaikymą.
- "Thrift" yra atvirojo kodo projektas, skirtas "Facebook", visų pirma kelių kalbų paslaugų kūrimo sistema. Jame yra kodų generatorius, kuris automatiškai sugeneruoja paslaugos kodo sistemą jo apibrėžtam IDL apibrėžimo failui. Vartotojams prieš tai reikia atlikti tik antrinį kūrimą, o pagrindinis RPC ryšys yra skaidrus. Tačiau vartotojams vis tiek reikia mokėti mokytis konkrečios srities kalbos.
- "Dubbo" yra gerai žinoma "Alibaba Group" atvirojo kodo RPC sistema, plačiai naudojama daugelyje interneto įmonių ir įmonių programų. Galima prijungti tiek protokolus, tiek serializacijos sistemas. Ta pati nuotolinė sąsaja yra pagrįsta "Java" sąsaja ir remiasi spyruokliniu karkasu, kad būtų lengva kurti. Jį galima lengvai supakuoti į vieną failą ir paleisti savarankiškai, o tai atitinka dabartinę mikropaslaugų koncepciją.
Slapta pasakyk, kad grupė nebenaudoja dubbo,Tas, kuris dabar dažniau naudojamas, vadinamas HSF, taip pat žinomas kaip "toks patogus". Vėliau gali būti atvirojo kodo, todėl palaukime ir pažiūrėkime.
HTTP paslauga
Tiesą sakant, seniai įmonės kūrimo modelį visada apibūdinau kaip HTTP sąsajos kūrimą, kurį dažnai vadiname RESTful stiliaus paslaugų sąsajomis. Iš tiesų, tai yra komunikacijos metodas, dažnai naudojamas ankstyvoje informacinių salų sprendimo stadijoje, kai yra nedaug sąsajų ir mažiau sąveikos tarp sistemų; Privalumai yra paprasti, tiesioginiai ir lengvai plėtojami. Perdavimui naudokite paruoštą HTTP protokolą. Prisimename, kad anksčiau įmonėje kurdami foną, daugiausia kūrėme sąsajas, taip pat turėjome parašyti didelį sąsajos dokumentą, griežtai nurodydami, kokia yra įvestis ir išvestis. Paaiškinkite kiekvienos sąsajos užklausos būdą ir dalykus, į kuriuos reikia atkreipti dėmesį užklausos parametruose. Pavyzdžiui, šis pavyzdys:
POSThttp://www.httpexample.com/restful/buyer/info/share
Sąsaja gali grąžinti JSON eilutę arba XML dokumentą. Tada klientas apdoroja šią grąžintą informaciją, kad būtų galima greičiau tobulėti. Tačiau didelėms įmonėms, kai yra daug vidinių posistemių ir daug sąsajų, parodomi RPC sistemos pranašumai, visų pirma, tai yra ilga nuoroda, ir nereikia kiekvieną kartą paspausti rankos 3 kartus kaip http, sumažinant tinklo pridėtines išlaidas; antra, RPC sistema paprastai turi registracijos centrą ir turtingą stebėseną bei valdymą; Publikavimas, sąsajos neprisijungus, dinaminis išplėtimas ir kt. yra nesuvokiamos ir vieningos skambinančiojo operacijos.
suvestinė
Paprastai kalbant, RPC paslaugos daugiausia skirtos didelėms įmonėms, o HTTP paslaugos daugiausia skirtos mažoms įmonėms, nes RPC yra efektyvesnis, o HTTP paslaugų kūrimo iteracijos bus greitesnės. Trumpai tariant, kokį karkasą pasirinkti, lemia ne tai, kas populiaru rinkoje, o viso projekto įvertinimas, kad būtų galima atidžiai palyginti dviejų plėtros sistemų poveikį visam projektui ir galiausiai nuspręsti, kas yra tinkamiausia projektui. Mes neturime naudoti RPC kiekvienam projektui vardan RPC, o prisitaikyti prie vietos sąlygų ir analizuoti konkrečią situaciją.
|
Paskelbta 2019-04-01 14:02:45
|
|
|
|
