Že dolgo časa ne razumem razlike med RPC (tj. oddaljenim klicem postopka) in HTTP klici. Prosim, dovolite mi, da se tukaj smejim~Naivni! Ta članek na kratko predstavi dve obliki C/S arhitekture, predvsem njuno najpomembnejšo razliko, torej RPC temelji predvsem na protokolu TCP/IP, medtem ko je HTTP storitev večinoma osnovana na HTTP protokolu; vsi vemo, da je HTTP protokol na vrhu transportnega protokola TCP, zato je RPC glede učinkovitosti seveda boljši! Pogovorimo se podrobneje o RPC storitvah in HTTP storitvah.
OSI omrežni sedemplastni model
Preden govorimo o razlikah med RPC in HTTP, menim, da je potrebno razumeti OSI-jev sedemplastni omrežni model (čeprav je v praksi v bistvu pet plasti), ki ga lahko razdelimo na naslednje plasti: (od zgoraj navzdol)
- Prva plast: aplikacijska plast. Definirani so vmesniki za komunikacijo in prenos podatkov v omrežju;
- Druga plast: plast predstavitev. Določite format prenosa, specifikacije kodiranja in dekodiranja podatkov v različnih sistemih itd.;
- Tretja plast: plast pogovora. Upravljanje uporabniških sej ter nadzor vzpostavljanja in prekinitve logičnih povezav med uporabniki.
- Četrta plast: transportna plast. Upravlja prenos podatkov od konca do konca v omrežju;
- Plast 5: Omrežna plast. Določite, kako se podatki prenašajo med omrežnimi napravami;
- Šesta plast: povezovalna plast. Podatkovni paketi omrežne plasti zgoraj so zapakirani v podatkovne okvire, da se olajša prenos fizične plasti.
- Plast 7: Fizična plast. Ta plast je predvsem namenjena prenosu teh binarnih podatkov.
V praktični uporabi v petplastni protokolni strukturi ni predstavitvene in sejske plasti. Treba je povedati, da se združujejo z aplikacijsko plastjo. Osredotočiti se moramo na aplikacijsko plast in transportno plast. Ker je HTTP protokol aplikacijske plasti, medtem ko je TCP protokol transportne plasti. No, zdaj, ko poznamo model plastenja omrežja, bolje razumemo, zakaj so RPC storitve boljše od HTTP storitev!
Storitve RPC
RPC storitve so predstavljene s treh vidikov: RPC arhitektura, sinhroni asinhroni klici in priljubljeni RPC ogrodji.
Arhitektura RPC
Pogovorimo se o osnovni arhitekturi RPC storitev. Dovolite mi, da sramotno ukradem sliko~ Jasno vidimo, da popolna RPC arhitektura vsebuje štiri osnovne komponente, in sicer odjemalec, strežnik, odjemalski stub in strežniški stub, ki ga lahko razumemo kot osnutk. Pogovorimo se o teh komponentah ločeno:
- Stranka, klicatelj storitve.
- Strežnik, pravi ponudnik storitev.
- Odjemalski stub shrani naslovno sporočilo strežnika, nato pa zapakira parametre zahteve odjemalca v omrežno sporočilo in ga nato pošlje servisni strani na daljavo prek omrežja.
- Strežniški stub prejme sporočila, ki jih pošlje odjemalec, jih razpakira in pokliče lokalne metode.
RPC se predvsem uporablja v velikih podjetjih, ker imajo velika podjetja veliko sistemov, zapletene poslovne linije, prednosti v učinkovitosti pa so zelo pomembne. To se izvaja v dejanskem razvoju, projekti pa se običajno upravljajo z uporabo maven. Na primer, imamo sistemsko storitev, ki obdeluje naročila, najprej deklarira vse svoje vmesnike (tukaj posebej vmesnik v Javi), nato pa celoten projekt zapakira v jar paket. Zakaj to storiti? Glavni namen je zmanjšati velikost paketa jar na strani odjemalca, saj vsakič, ko je paket izdan, preveč paketov jar vedno vpliva na učinkovitost. Prav tako loči odjemalca in strežnika, da izboljša prenosljivost kode.
Sinhroni in asinhroni klici
Kaj je sinhroni klic? Kaj je asinhroni klic? Sinhroni klic je, ko odjemalec počaka, da se klic zaključi, in vrne rezultat. Asinhroni klici pomenijo, da odjemalec ne čaka, da se klic izvede in vrne rezultat, vendar lahko še vedno prejme obvestilo o povratnem rezultatu preko funkcije povratnega klica. Če stranki ni mar za izid, se lahko odločitev spremeni v enosmerni klic. Ta postopek je nekoliko podoben klicateljskim in zagonskim vmesnikom v Javi; ko izvajamo asinhrono, če potrebujemo rezultat izvajanja, lahko uporabimo klicni vmesnik in pridobimo informacije o rezultatu asinhronega izvajanja preko razreda Future. Če ti ni mar za rezultat izvajanja, lahko preprosto uporabiš zagonski vmesnik, ker ne vrne rezultata, seveda je mogoče tudi klicati, prihodnosti ne potrebujemo.
Priljubljeni RPC okvir
Še vedno obstaja veliko priljubljenih odprtokodnih RPC ogrodij. Tukaj so trije poudarki:
- gRPC je nedavno predstavljena odprtokodna programska oprema podjetja Google, ki temelji na najnovejšem protokolu HTTP 2.0 in podpira številne pogoste programske jezike. Vemo, da je HTTP 2.0 nadgrajena različica HTTP protokola, ki temelji na binarni datoteki, in večji brskalniki ga trenutno hitro podpirajo. Ta RPC okvir temelji na HTTP protokolu, osnova pa uporablja podporo ogrodja Netty.
- Thrift je odprtokodni projekt za Facebook, predvsem okvir za razvoj storitev med jeziki. Ima generator kode, ki samodejno generira okvir kode storitev za IDL definicijsko datoteko, ki jo definira. Uporabniki morajo pred tem opraviti le sekundarni razvoj, osnovna RPC komunikacija pa je transparentna. Vendar pa je za uporabnike še vedno določen strošek za učenje jezika določenega področja.
- Dubbo je dobro znan RPC ogrodje odprtokodne skupine Alibaba Group, ki se široko uporablja v številnih internetnih podjetjih in poslovnih aplikacijah. Tako protokoli kot ogrodja za serializacijo so lahko priključeni. Isti oddaljeni vmesnik temelji na Java vmesniku in se zanaša na spring framework za enostaven razvoj. Enostavno ga je mogoče zapakirati v eno datoteko in zagnati neodvisno, kar je skladno s trenutnim konceptom mikroservisov.
Skrivaj ti povem, da skupina dubbo ne uporablja več veliko,Tisti, ki se danes pogosteje uporablja, se imenuje HSF, znano tudi kot "tako udobno". Morda bo kasneje odprtokoden, zato počakajmo in vidimo.
HTTP storitev
Pravzaprav sem že dolgo nazaj model razvoja v podjetjih vedno opisoval kot razvoj HTTP vmesnikov, kar pogosto imenujemo storitveni vmesniki v slogu RESTful. Pravzaprav gre za komunikacijsko metodo, ki se pogosto uporablja v zgodnji fazi reševanja informacijskih otokov v primeru malo vmesnikov in manj interakcije med sistemi; Prednosti so preproste, neposredne in enostavne za razvoj. Uporabite že pripravljen HTTP protokol za prenos. Spomnimo se, da smo v podjetju, ko smo prej delali razvoj v ozadju, večinoma razvijali vmesnike, poleg tega pa smo morali napisati tudi obsežen dokument o vmesnikih, ki je natančno določal, kakšen je vhod in izhod. Pojasnite metodo zahtevkov vsakega vmesnika in zadeve, na katere je treba biti pozoren v parametrih zahtev. Na primer, naslednji primer:
POŠTAhttp://www.httpexample.com/restful/buyer/info/share
Vmesnik lahko vrne JSON niz ali XML dokument. Odjemalec nato obdela te vrnjene informacije, kar omogoča hitrejši razvoj. Vendar pa se za velika podjetja, ko je veliko notranjih podsistemov in vmesnikov, prednosti RPC ogrodja pokažejo; najprej gre za dolgo povezavo in ni potrebe, da bi se vsakič trikrat rokovali kot pri http, kar zmanjšuje obremenitev omrežja; drugič, okvir RPC ima običajno registracijski center ter bogato spremljanje in upravljanje; Objavljanje, vmesniki brez povezave, dinamična širitev itd. so ne-zaznavne in enotne operacije za klicatelja.
Povzetek
Na splošno so RPC storitve namenjene predvsem velikim podjetjem, medtem ko so HTTP storitve predvsem za mala podjetja, ker je RPC učinkovitejši, razvoj HTTP storitev pa hitrejši. Skratka, kakšen okvir izbrati, ni odvisen od tega, kaj je priljubljeno na trgu, temveč od popolne ocene celotnega projekta, da se natančno primerja vpliv obeh razvojnih okvirov na celoten projekt in na koncu odloči, kaj je najbolj primerno za projekt. RPC ne smemo uporabljati za vsak projekt zgolj zaradi uporabe RPC, temveč se prilagodimo lokalnim razmeram in analiziramo specifično situacijo.
|
Objavljeno na 1. 04. 2019 14:02:45
|
|
|
|
