Pikka aega pole ma aru saanud, mis on RPC-l (ehk kaugprotseduuride kutsel) ja HTTP-kõnedel. Palun lase mul siin naerda~Naiivne! See artikkel tutvustab lühidalt kahte C/S arhitektuuri vormi, esiteks nende kõige olulisemat erinevust, nimelt RPC põhineb peamiselt TCP/IP protokollil, samas kui HTTP teenus põhineb peamiselt HTTP protokollil. Me kõik teame, et HTTP protokoll asub transpordikihi protokolli TCP peal, seega efektiivsuse mõttes on RPC muidugi parem! Räägime üksikasjalikult RPC ja HTTP teenustest.
OSI võrgu seitsmekihiline mudel
Enne kui räägime RPC ja HTTP erinevusest, pean vajalikuks mõista OSI seitsmekihti võrgustruktuuri mudelit (kuigi praktikas on see põhimõtteliselt viis kihti), mida saab jagada järgmisteks kihtideks: (ülevalt alla)
- Esimene kiht: rakenduskiht. Võrgus on määratletud suhtlus- ja andmeedastuse liidesed;
- Teine kiht: esituskiht. Määratleda andmete edastusformaat, kodeerimise ja dekodeerimise spetsifikatsioonid erinevates süsteemides jne;
- Kolmas kiht: vestluskiht. Halda kasutajasessioone ja kontrolli loogiliste ühenduste loomist ja katkestamist kasutajate vahel.
- Neljas kiht: transpordikiht. See haldab võrgus otsast lõpuni andmeedastust;
- Kiht 5: Võrgukiht. Määratle, kuidas andmeid võrguseadmete vahel edastatakse;
- Kuues kiht: linkkiht. Võrgukihi andmepaketid on kapseldatud andmeraamidesse, et hõlbustada füüsilise kihi edastamist.
- Kiht 7: Füüsiline kiht. See kiht on peamiselt binaarandmete edastamine.
Praktilises rakenduses puudub viiekihilises protokollistruktuuris esitlus- ja sessioonikihti. Tuleb öelda, et need sulanduvad rakenduskihiga. Me peaksime keskenduma rakenduskihile ja transpordikihile. Sest HTTP on rakenduskihi protokoll, samas kui TCP on transpordikihi protokoll. Nüüd, kui me teame võrgukihistamise mudelit, mõistame paremini, miks RPC teenused on HTTP-teenustest paremad!
RPC teenused
RPC teenuseid tutvustatakse kolmest vaatenurgast: RPC arhitektuur, sünkroonsed asünkroonsed kõned ja populaarsed RPC raamistikud.
RPC arhitektuur
Räägime RPC teenuste põhiarhitektuurist. Lubage mul häbiga pilti varastada~ Näeme selgelt, et täielik RPC arhitektuur koosneb neljast põhikomponendist: klient, server, kliendi stub ja serveri stub, mida võib mõista kui stub'i. Räägime neist komponentidest eraldi:
- Klient, teenuse helistaja.
- Server, tõeline teenusepakkuja.
- Kliendi stub salvestab serveri aadressisõnumi, pakendab kliendi päringuparameetrid võrgusõnumiks ja saadab selle teenuseosakonnale võrgu kaudu.
- Serveripoolne stub võtab vastu kliendi saadetud sõnumeid, pakib need lahti ja kutsub kohalikke meetodeid.
RPC-d kasutatakse peamiselt suurtes ettevõtetes, kuna suurtes ettevõtetes on palju süsteeme, keerukaid ärisuundi ja efektiivsuse eelised on väga olulised. See toimub tegelikus arenduses ja projekte juhitakse üldiselt maveniga. Näiteks on meil süsteemiteenus, mis töötleb tellimusi, deklareerib esmalt kõik oma liidesed (siin täpsemalt Java liidese) ja seejärel pakendab kogu projekti jar-paketti. Miks seda teha? Peamine eesmärk on vähendada jar-paketi suurust kliendipoolel, sest iga kord, kui pakett välja antakse, mõjutab liiga palju jar-pakette alati efektiivsust. See eraldab ka kliendi ja serveri, et parandada koodi ülekantavust.
Sünkroonsed ja asünkroonsed kutsed
Mis on sünkroonne kõne? Mis on asünkroonne kõne? Sünkroonne kõne tähendab, et klient ootab kutse täitmise lõppu ja tagastab tulemuse. Asünkroonsed kõned tähendavad, et klient ei oota kõne käivitamist ega tagasta tulemust, vaid saab siiski tagasikõne funktsiooni kaudu teate. Kui klient ei hooli tulemusest, võib see muutuda ühesuunaliseks kõneks. See protsess on mõnevõrra sarnane Java kutsutavatele ja käivitatavatele liidestele, kus kui me täidame asünkroonselt ja vajame täitmise tulemust, saame kasutada kutsutavat liidest ning saada asünkroonse täitmise tulemuse info Future klassi kaudu. Kui sind ei huvita täitmise tulemus, võid lihtsalt kasutada käivitatavat liidest, sest see ei tagasta tulemust, muidugi on ka kutsutav võimalus, tulevikku pole vaja.
Populaarne RPC raamistik
On endiselt palju populaarseid avatud lähtekoodiga RPC raamistikke. Siin on kolm tipphetke:
- gRPC on Google'i hiljuti välja kuulutatud avatud lähtekoodiga tarkvara, mis põhineb uusimal HTTP 2.0 protokollil ja toetab paljusid levinud programmeerimiskeeli. Me teame, et HTTP 2.0 on HTTP protokolli uuendatud versioon, mis põhineb binaarsel, ning suuremad brauserid toetavad seda praegu kiiresti. See RPC raamistik põhineb HTTP protokollil ning aluseks on Netty raamistik.
- Thrift on Facebooki avatud lähtekoodiga projekt, peamiselt keeleülene teenuste arendusraamistik. Sellel on koodigeneraator, mis automaatselt genereerib teenusekoodi raamistiku IDL definitsioonfailile, mille ta määratleb. Kasutajad peavad enne seda tegema vaid sekundaarset arendust ning aluseks olev RPC suhtlus on läbipaistev. Siiski on kasutajatele teatud hind konkreetse valdkonna keele õppimisel.
- Dubbo on tuntud avatud lähtekoodiga RPC raamistik Alibaba Groupi poolt, mida kasutatakse laialdaselt paljudes internetiettevõtetes ja ettevõtete rakendustes. Nii protokolle kui ka serialiseerimisraamistikke saab ühendada. Sama kaugliides põhineb Java liidesel ja tugineb lihtsaks arenduseks vedruraamistikule. Seda saab hõlpsasti pakendada ühte faili ja käivitada iseseisvalt, mis on kooskõlas tänapäevase mikroteenuste kontseptsiooniga.
Salaja ütlen, et grupp ei kasuta enam palju dubbot,Praegu sagedamini kasutatav variant on HSF, tuntud ka kui "nii mugav". Võib-olla tuleb hiljem avatud lähtekoodiga, nii et ootame ja vaatame.
HTTP teenus
Tegelikult olen ammu aega tagasi iseloomustanud ettevõtte arendusmudelit kui HTTP liidese arendust, mida me sageli nimetame RESTful-stiilis teenuseliidesteks. Tõepoolest, see on kommunikatsioonimeetod, mida sageli kasutatakse infosaarte lahendamise varajases faasis, kui liidesed on vähesed ja süsteemidevaheline interaktsioon väheneb; Eelised on lihtsad, otsesed ja kergesti arendatavad. Kasuta edastamiseks valmis HTTP protokolli. Mäletame, et kui tegime ettevõttes taustaarendust, arendasime peamiselt liideseid, ja pidime kirjutama suure liidesedokumendi, mis näitas rangelt, mis on sisend ja väljund. Selgita iga liidese päringu meetodit ja küsimusi, millele päringuparameetrites tähelepanu pöörata. Näiteks järgmine näide:
POSThttp://www.httpexample.com/restful/buyer/info/share
Liides võib tagastada JSON-stringi või XML-dokumendi. Klient töötleb seejärel tagastatud infot, võimaldades kiiremat arendust. Kuid suurte ettevõtete puhul, kui on palju sisemisi alamsüsteeme ja palju liideseid, ilmnevad RPC raamistiku eelised: esiteks on see pikk link ja pole vaja kätt suruda kolm korda nagu http iga kord, vähendades võrgu koormust; teiseks on RPC raamistikul tavaliselt registreerimiskeskus ning rikkalik jälgimine ja haldus; Avaldamine, võrguühenduseta liidesed, dünaamiline laiendamine jne on helistaja jaoks mittetajuvad ja ühtsed toimingud.
Kokkuvõte
Üldiselt on RPC teenused peamiselt suurtele ettevõtetele, samas kui HTTP teenused on peamiselt väikestele ettevõtetele, sest RPC on tõhusam ja HTTP teenuste arenduse iteratsioonid kiiremad. Lühidalt, millist raamistikku valida, ei sõltu sellest, mis turul populaarne on, vaid kogu projekti täielik hindamine, et hoolikalt võrrelda kahe arendusraamistiku mõju kogu projektile ja lõpuks otsustada, mis on projektile kõige sobivam. Me ei tohi kasutada RPC-d iga projekti jaoks ainult RPC kasutamise pärast, vaid kohaneda kohalike tingimustega ja analüüsida konkreetset olukorda.
|
Postitatud 01.04.2019 14:02:45
|
|
|
|
