Olen kindel, et pealkiri tekitas eluterve reaktsiooni – "noh, see on jälle alanud..." Aga lubage mul teie tähelepanu 5-10 minutiks köita ja ma püüan teie ootusi mitte petta.
Artikli ülesehitus saab olema järgmine: võetakse stereotüüpne väide ja paljastatakse selle stereotüübi tekkimise “olemus”. Loodan, et see võimaldab teil vaadata andmevahetuse paradigma valikut oma projektides uue nurga alt.
Selleks, et saada selgeks, mis on RPC, teen ettepaneku kaaluda standardit . RESTiga pole selgust. Ja see ei tohiks olla. Kõik, mida pead RESTi kohta teadma – see on eristamatu .
RPC-päringud on kiiremad ja tõhusamad, kuna võimaldavad teil teha paketttaotlusi.
Asi on selles, et RPC-s saate ühe taotlusega korraga helistada mitmele protseduurile. Näiteks looge kasutaja, lisage talle avatar ja samas taotluses tellige talle mõni teema. Ainult üks taotlus ja kui palju kasu!
Tõepoolest, kui teil on ainult üks taustasõlm, tundub see pakktaotlusega kiirem. Sest kolm REST-taotlust nõuavad ühenduste loomiseks ühest sõlmest kolm korda rohkem ressursse.
Pange tähele, et REST-i puhul peab esimene päring tagastama kasutaja ID, et järgnevaid päringuid teha. Mis mõjutab negatiivselt ka üldist tulemust.
Kuid selliseid infrastruktuure võib leida ainult ettevõttesisesest lahendusest ja ettevõttest. Viimase abinõuna väikestes WEB-projektides. Kuid täisväärtuslikke WEB-lahendusi ja isegi neid, mida nimetatakse HighLoadiks, ei tasu ehitada. Nende infrastruktuur peab vastama kõrge käideldavuse ja koormuse kriteeriumidele. Ja pilt muutub.
Sama stsenaariumi kohased infrastruktuuri tegevuskanalid on tähistatud rohelisega. Pange tähele, kuidas RPC praegu käitub. Taotlus kasutab infrastruktuuri ainult ühel jalal tasakaalustajast taustaprogrammini. Kuigi REST kaotab endiselt esimese taotlusega, korvab see kogu infrastruktuuri kasutades kaotatud aja.
Piisab, kui stsenaariumi sisestada mitte kaks rikastamistaotlust, vaid näiteks viis või kümme... ja vastus küsimusele "kes nüüd võidab?" muutub ebaselgeks.
Teen ettepaneku vaadelda probleemi veelgi laiemalt. Diagramm näitab, kuidas infrastruktuuri kanaleid kasutatakse, kuid infrastruktuur ei piirdu kanalitega. Suure koormusega infrastruktuuri oluline komponent on vahemälud. Võtame nüüd mingisuguse kasutaja artefakti. Korduvalt. Ütleme 32 korda.
Vaadake, kuidas RPC infrastruktuur on märkimisväärselt paranenud, et vastata suure koormuse nõudmistele. Asi on selles, et REST kasutab erinevalt RPC-st HTTP-protokolli kogu võimsust. Ülaltoodud diagrammil realiseeritakse see võimsus päringumeetodi - GET kaudu.
HTTP-meetoditel on muu hulgas vahemällu salvestamise strateegiad. Need leiate dokumentatsioonist aadressil . RPC puhul kasutatakse POST-päringuid, mida ei peeta idempotentseks, see tähendab, et samade POST-päringute korduv kordamine võib anda erinevaid tulemusi (näiteks pärast iga kommentaari saatmist ilmub selle kommentaari teine koopia) ().
Järelikult ei saa RPC infrastruktuuri vahemälu tõhusalt kasutada. See toob kaasa vajaduse "importida" tarkvara vahemälu. Diagramm näitab Redist selles rollis. Tarkvara vahemälu omakorda nõuab arendajalt täiendava koodikihi lisamist ja märgatavaid muudatusi arhitektuuris.
Loeme nüüd kokku, mitu taotlust REST ja RPC vaadeldavas infrastruktuuris “sünnitasid”?
taotlused
Postkast
taustaks
DBMS-ile
pehmesse vahemällu (Redis)
KOKKU
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Võrreldes esimese skeemiga on erinevus silmatorkav. Nüüd selgub REST kasulikkus. Kuid ma soovitan sellega mitte peatuda. Arendatud infrastruktuur sisaldab CDN-i. Sageli lahendab see ka DDoS-i ja DoS-rünnakute vastu võitlemise probleemi. Saame:
Siin lähevad asjad RPC jaoks väga halvaks. RPC lihtsalt ei suuda töökoormust CDN-ile delegeerida. Rünnakute vastu võitlemisel saame loota ainult süsteemidele.
Kas siin on võimalik lõpetada? Ja jälle, ei. HTTP-meetoditel, nagu eespool mainitud, on oma "maagia". Ja mitte ilmaasjata ei kasutata GET-meetodit Internetis laialdaselt. Pange tähele, et see meetod pääseb juurde sisule, suudab seada tingimusi, mida infrastruktuuri elemendid saavad tõlgendada enne juhtimise ülekandmist teie koodile ja nii edasi. Kõik see võimaldab teil luua paindlikke, hallatavaid infrastruktuure, mis suudavad käsitleda tõeliselt suuri päringute voogusid. Kuid RPC-s seda meetodit... ignoreeritakse.
Miks on müüt, et pakettpäringud (RPC) on kiiremad, nii püsiv? Mulle isiklikult tundub, et enamik projekte lihtsalt ei jõua sellisele arengutasemele, kus REST suudaks oma tugevust näidata. Pealegi on ta väikestes projektides rohkem valmis oma nõrkusi välja näitama.
REST või RPC valik ei ole üksikisiku vabatahtlik valik projektis. See valik peab vastama projekti nõuetele. Kui projekt suudab RESTist välja pigistada kõik, mida ta tegelikult suudab, ja ta seda tõesti vajab, on REST suurepärane valik.
Kui aga kõigi REST-i eeliste kasutamiseks on vaja projekti jaoks palgata devopsi spetsialiste, et taristut kiiresti skaleerida, administraatorid taristu haldamiseks, arhitekti, kes kavandaks kõik WEB-teenuse kihid... ja projekti , samal ajal müüb kolm pakki margariini päevas... Mina jääksin RPC juurde, sest... see protokoll on utilitaarsem. See ei nõua sügavaid teadmisi vahemälu ja infrastruktuuri toimimise kohta, vaid keskendub arendajale vajalike protseduuride lihtsatele ja arusaadavatele kõnedele. Äri saab õnnelikuks.
RPC-päringud on usaldusväärsemad, kuna need suudavad täita paketttaotlusi ühe tehinguga
See RPC omadus on kindel eelis, kuna Andmebaasi järjepidevana on lihtne hoida. Aga RESTiga läheb see aina keerulisemaks. Taotlused võivad erinevatesse taustasõlmedesse jõuda ebajärjekindlalt.
See REST-i "puudus" on selle ülalkirjeldatud eelise - võime kasutada tõhusalt kõiki infrastruktuuri ressursse - tagakülg. Kui infrastruktuur on halvasti kujundatud ja veelgi enam, kui projekti arhitektuur ja eriti andmebaas on halvasti kujundatud, on see tõesti suur valu.
Kuid kas paketttaotlused on nii usaldusväärsed, kui nad tunduvad? Vaatame juhtumit: loome kasutaja, rikastame tema profiili mõne kirjeldusega ja saadame talle registreerimise lõpuleviimiseks SMS-i saladusega. Need. kolm kõnet ühes partiitaotluses.
Vaatame diagrammi. See esitleb kõrge kättesaadavusega elementidega infrastruktuuri. SMS-lüüsidega on kaks sõltumatut sidekanalit. Aga... mida me näeme? SMS-i saatmisel ilmneb tõrge 503 - teenus pole ajutiselt saadaval. Sest SMS-i saatmine pakitakse pakkpäringusse, siis tuleb kogu päring tagasi kerida. DBMS-i toimingud tühistatakse. Klient saab veateate.
Järgmine katse on loterii. Kas päring tabab ikka ja jälle sama sõlme, tagastab veateate või siis läheb õnneks ja see täidetakse. Kuid peamine on see, et vähemalt korra on meie infrastruktuur juba asjata töötanud. Koormust oli, aga tulu polnud.
Olgu, kujutame ette, et pingutasime end (!) ja mõtlesime läbi variandi, millal võiks päringu osaliselt edukalt täita. Ja ülejäänu proovime mõne ajaintervalli järel uuesti lõpetada (milline? Kas rinne otsustab?). Aga loterii jäi samaks. SMS-i saatmise taotlusel on 50/50 tõenäosus, et see ebaõnnestub uuesti.
Nõus, kliendi poole pealt ei tundu teenus nii usaldusväärne kui me tahaksime... aga REST?
REST kasutab taas HTTP võlu, kuid nüüd koos vastusekoodidega. Kui SMS-lüüsis ilmneb tõrge 503, edastab taustaprogramm selle vea tasakaalustajale. Tasakaalustaja saab selle vea ja saadab kliendiga ühendust katkestamata päringu teisele sõlmele, mis päringu edukalt töötleb. Need. klient saab oodatud tulemuse ja infrastruktuur kinnitab oma kõrget "kõrgelt ligipääsetava" tiitlit. Kasutaja on rahul.
Ja see pole jällegi kõik. Tasakaalustaja ei saanud lihtsalt vastusekoodi 503. Vastamisel on standardi järgi soovitav see kood varustada päisega “Retry-After”. Päis teeb tasakaalustajale selgeks, et antud marsruudil ei tasu seda sõlme kindla aja jooksul häirida. Ja järgmised SMS-i saatmise taotlused saadetakse otse sõlme, millel pole SMS-lüüsiga probleeme.
Nagu näeme, on JSON-RPC töökindlus ülehinnatud. Tõepoolest, andmebaasis on järjepidevust lihtsam korraldada. Kuid ohverdus on antud juhul süsteemi kui terviku usaldusväärsus.
Järeldus on suures osas sarnane eelmisele. Kui infrastruktuur on lihtne, on JSON-RPC ilmselgus kindlasti plussiks. Kui projekt hõlmab suurt käideldavust suure koormusega, tundub REST õigem, kuigi keerulisem lahendus.
REST sisenemise lävi on madalam
Ma arvan, et ülaltoodud analüüs, mis kummutab RPC-st väljakujunenud stereotüübid, näitas selgelt, et REST-i sisenemise lävi on kahtlemata kõrgem kui RPC-sse. Selle põhjuseks on vajadus sügava arusaamise järele HTTP toimimisest, samuti vajadusest omada piisavalt teadmisi olemasolevate taristuelementide kohta, mida saab ja tuleks kasutada WEB-projektides.
Miks siis paljud inimesed arvavad, et REST on lihtsam? Minu isiklik arvamus on, et see näiline lihtsus tuleneb REST avaldumistest. Need. REST ei ole protokoll vaid kontseptsioon... REST-il pole standardit, seal on mingid juhised... REST pole HTTP-st keerulisem. Näiline vabadus ja anarhia tõmbavad ligi “vabu kunstnikke”.
Muidugi pole REST keerulisem kui HTTP. Kuid HTTP ise on hästi läbimõeldud protokoll, mis on aastakümnete jooksul end tõestanud. Kui HTTP-st endast sügavat arusaamist pole, ei saa RESTi hinnata.
Aga RPC kohta - saate. Piisab, kui võtta selle spetsifikatsioon. Nii et kas teil on vaja ? Või on see ikkagi keeruline PUHKUS? Sina otsustad.
Loodan siiralt, et ma pole teie aega raisanud.
Allikas: www.habr.com