Mi certas, ke la titolo kaŭzis sanan reagon - "nu, ĝi rekomencis..." Sed lasu min kapti vian atenton dum 5-10 minutoj, kaj mi provos ne seniluziigi viajn atendojn.
La strukturo de la artikolo estos kiel sekvas: stereotipa deklaro estas prenita kaj la "naturo" de la apero de ĉi tiu stereotipo estas malkaŝita. Mi esperas, ke ĉi tio permesos al vi rigardi la elekton de datuma interŝanĝo en viaj projektoj de nova angulo.
Por esti klara pri kio estas RPC, mi proponas konsideri la normon . Kun REST ne estas klareco. Kaj ne devus esti. Ĉio, kion vi bezonas scii pri REST - ĝi estas nedistingebla .
RPC-petoj estas pli rapidaj kaj pli efikaj ĉar ili permesas vin fari gruppetojn.
La punkto estas, ke en RPC vi povas voki plurajn procedurojn samtempe en unu peto. Ekzemple, kreu uzanton, aldonu avataron al li kaj, en la sama peto, abonu lin al iuj temoj. Nur unu peto, kaj kiom da profito!
Efektive, se vi havas nur unu malantaŭan nodon, ĝi ŝajnos pli rapida kun bata peto. Ĉar tri REST-petoj postulos trioble pli da rimedoj de unu nodo por establi ligojn.
Notu, ke la unua peto en la kazo de REST devas resendi la uzantidentigilon por ke postaj petoj estu faritaj. Kiu ankaŭ negative influas la ĝeneralan rezulton.
Sed tiaj infrastrukturoj troveblas nur en internaj solvoj kaj Enterprise. Kiel lasta rimedo, en malgrandaj TTT-projektoj. Sed plenrajtaj TTT-solvoj, kaj eĉ tiuj nomataj HighLoad, ne indas konstrui. Ilia infrastrukturo devas renkonti la kriteriojn de alta havebleco kaj ŝarĝo. Kaj la bildo ŝanĝiĝas.
Infrastrukturaj agadkanaloj sub la sama scenaro estas markitaj verde. Rimarku kiel RPC kondutas nun. La peto uzas la infrastrukturon sur nur unu kruro de la ekvilibristo ĝis la backend. Dum REST ankoraŭ perdas en la unua peto, ĝi kompensas la perditan tempon uzante la tutan infrastrukturon.
Sufiĉas enigi en la skripton ne du petojn por riĉigo, sed, ekzemple, kvin aŭ dek... kaj la respondon al la demando "kiu nun venkas?" fariĝas neklara.
Mi proponas eĉ pli larĝan rigardon al la problemo. La diagramo montras kiel infrastrukturaj kanaloj estas uzataj, sed infrastrukturo ne estas limigita al kanaloj. Grava komponento de alt-ŝarĝa infrastrukturo estas kaŝmemoroj. Ni nun akiru ian uzantan artefakton. Ripete. Ni diru 32 fojojn.
Vidu kiel la RPC-infrastrukturo signife pliboniĝis por plenumi la postulojn de alta ŝarĝo. La afero estas, ke REST uzas la plenan potencon de la HTTP-protokolo, male al RPC. En la supra diagramo, ĉi tiu potenco estas realigita per la peta metodo - GET.
HTTP-metodoj, interalie, havas kaŝmemorstrategiojn. Vi povas trovi ilin en la dokumentado ĉe . Por RPC, oni uzas POST-petojn, kiuj ne estas konsiderataj idempotentaj, tio estas, ripetaj ripetoj de la samaj POST-petoj povas redoni malsamajn rezultojn (ekzemple, post kiam ĉiu komento estas sendita, alia kopio de ĉi tiu komento aperos) ().
Sekve, RPC estas nekapabla efike uzi infrastrukturkaŝmemorojn. Ĉi tio kondukas al la bezono "importi" programarajn kaŝmemorojn. La diagramo montras Redis en tiu ĉi rolo. La programara kaŝmemoro, siavice, postulas, ke la programisto aldonu plian tavolon de kodo kaj rimarkindajn ŝanĝojn en la arkitekturo.
Ni nun kalkulu kiom da petoj REST kaj RPC "naskigis" en la konsiderata infrastrukturo?
Petoj
Enirkesto
backend
al la DBMS
al mola kaŝmemoro (Redis)
TOTAL
RESTA
1 / 32 *
1
1
0
3 / 35
CPR
32
32
1
31
96
Kompare kun la unua skemo, la diferenco estas okulfrapa. Nun la avantaĝo de REST iĝas klara. Sed mi proponas ne halti tie. La evoluinta infrastrukturo inkluzivas CDN. Ofte ĝi ankaŭ solvas la problemon kontraŭbatali DDoS kaj DoS-atakojn. Ni ricevas:
Ĉi tie aferoj vere malbonas por RPC. RPC simple ne kapablas delegi la laborkvanton al CDN. Ni povas nur fidi je sistemoj por kontraŭstari atakojn.
Ĉu eblas fini ĉi tie? Kaj denove, ne. HTTP-metodoj, kiel menciite supre, havas sian propran "magion". Kaj ne senkaŭze la GET-metodo estas vaste uzata en la Interreto. Notu, ke ĉi tiu metodo kapablas aliri enhavon, kapablas agordi kondiĉojn, kiujn infrastrukturaj elementoj povas interpreti antaŭ ol kontrolo estas transdonita al via kodo, ktp. Ĉio ĉi permesas vin krei flekseblajn, regeblajn infrastrukturojn, kiuj povas trakti vere grandajn fluojn de petoj. Sed en RPC ĉi tiu metodo... estas ignorata.
Do kial la mito, ke bataj petoj (RPC) estas pli rapidaj tiel persista? Persone, ŝajnas al mi, ke la plej multaj projektoj simple ne atingas evolunivelon kie REST kapablas montri sian forton. Krome, en malgrandaj projektoj, li pli volonte montras siajn malfortojn.
La elekto de REST aŭ RPC ne estas vola elekto de individuo en projekto. Ĉi tiu elekto devas plenumi la postulojn de la projekto. Se projekto kapablas elpremi ĉion, kion ĝi vere povas el REST, kaj ĝi vere bezonas ĝin, tiam REST estos bonega elekto.
Sed se, por akiri ĉiujn avantaĝojn de REST, vi devas dungi devops-specialistojn por la projekto por rapide skali la infrastrukturon, administrantojn por administri la infrastrukturon, arkitekton por desegni ĉiujn tavolojn de la TTT-servo... kaj la projekto. , samtempe, vendas tri pakojn da margarino tage... Mi mi restus kun RPC, ĉar... ĉi tiu protokolo estas pli utilisma. Ĝi ne postulos profundan scion pri kiel funkcias kaŝmemoroj kaj infrastrukturo, sed enfokusigos la programiston pri simplaj kaj kompreneblaj alvokoj al la proceduroj, kiujn li bezonas. Komerco estos feliĉa.
RPC-petoj estas pli fidindaj ĉar ili povas efektivigi gruppetojn ene de ununura transakcio
Ĉi tiu propraĵo de RPC estas difinita avantaĝo, ĉar Estas facile konservi la datumbazon konsekvenca. Sed kun REST ĝi fariĝas pli kaj pli komplika. Petoj povas alveni malkonsekvence al malsamaj backend nodoj.
Ĉi tiu "malavantaĝo" de REST estas la inversa flanko de sia avantaĝo priskribita supre - la kapablo efike uzi ĉiujn infrastrukturajn rimedojn. Se la infrastrukturo estas malbone desegnita, kaj eĉ pli se la arkitekturo de la projekto kaj la datumbazo precipe estas malbone desegnitaj, tiam ĉi tio estas vere granda doloro.
Sed ĉu grupaj petoj estas tiel fidindaj kiel ili ŝajnas? Ni rigardu kazon: ni kreas uzanton, riĉigas lian profilon per iu priskribo kaj sendas al li SMS kun sekreto por plenumi la registriĝon. Tiuj. tri vokoj en unu gruppeto.
Ni rigardu la diagramon. Ĝi prezentas infrastrukturon kun alta haveblecaj elementoj. Estas du sendependaj komunikadkanaloj kun SMS-enirejoj. Sed... kion ni vidas? Sendante SMS, okazas eraro 503 - la servo provizore ne disponeblas. Ĉar Sendado de SMS estas pakita en bata peto, tiam la tuta peto devas esti nuligita. Agoj en la DBMS estas nuligitaj. La kliento ricevas eraron.
La sekva provo estas la loterio. Aŭ la peto trafos la saman nodon denove kaj denove revenos eraron, aŭ vi estos bonŝanca kaj ĝi estos efektivigita. Sed la ĉefa afero estas, ke almenaŭ unufoje nia infrastrukturo jam vane funkciis. Estis ŝarĝo, sed neniu profito.
Bone, ni imagu, ke ni streĉis nin (!) kaj pripensis la opcion kiam la peto povas esti parte sukcese plenumita. Kaj ni provos kompletigi la reston denove post iom da tempointervalo (Kiu? Ĉu la fronto decidas?). Sed la loterio restis la sama. La peto sendi SMS havas 50/50 eblecon denove malsukcesi.
Konsentu, de la klienta flanko, la servo ne ŝajnas tiel fidinda kiel ni ŝatus... kio pri REST?
REST denove uzas la magion de HTTP, sed nun kun respondkodoj. Kiam eraro 503 okazas sur la SMS-enirejo, la backend elsendas ĉi tiun eraron al la ekvilibristo. La ekvilibristo ricevas ĉi tiun eraron kaj sen rompi la ligon kun la kliento, sendas la peton al alia nodo, kiu sukcese procesas la peton. Tiuj. la kliento ricevas la atendatan rezulton, kaj la infrastrukturo konfirmas sian altan titolon de "tre alirebla". La uzanto estas feliĉa.
Kaj denove tio ne estas ĉio. La ekvilibristo ne nur ricevis respondkodon de 503. Respondante, laŭ la normo, estas konsilinde provizi ĉi tiun kodon kun la kaplinio "Retry-After". La kaplinio klarigas al la ekvilibristo, ke ne indas ĝeni ĉi tiun nodon sur ĉi tiu itinero dum difinita tempo. Kaj la sekvaj petoj por sendi SMS estos senditaj rekte al nodo, kiu ne havas problemojn kun la SMS-enirejo.
Kiel ni povas vidi, la fidindeco de JSON-RPC estas trotaksita. Efektive, estas pli facile organizi konsistencon en la datumbazo. Sed la ofero, en ĉi tiu kazo, estos la fidindeco de la sistemo entute.
La konkludo estas grandparte simila al la antaŭa. Kiam la infrastrukturo estas simpla, la evidenteco de JSON-RPC estas sendube pluso. Se la projekto implikas altan haveblecon kun alta ŝarĝo, REST aspektas kiel pli ĝusta, kvankam pli kompleksa, solvo.
Enira sojlo al REST estas pli malalta
Mi pensas, ke la supra analizo, malkonfirmante la establitajn stereotipojn pri RPC, klare montris, ke la sojlo por eniro en REST estas sendube pli alta ol en RPC. Ĉi tio estas pro la bezono de profunda kompreno pri kiel funkcias HTTP, same kiel la bezono havi sufiĉan scion pri ekzistantaj infrastrukturaj elementoj, kiuj povas kaj devas esti uzataj en RETEJ-projektoj.
Do kial multaj homoj pensas, ke REST estos pli simpla? Mia persona opinio estas, ke ĉi tiu ŝajna simpleco venas de la REST manifestoj sin. Tiuj. REST ne estas protokolo sed koncepto... REST ne havas normon, ekzistas kelkaj gvidlinioj... REST ne estas pli komplika ol HTTP. Ŝajna libereco kaj anarkio altiras "liberajn artistojn".
Kompreneble, REST ne estas pli komplika ol HTTP. Sed HTTP mem estas bone desegnita protokolo, kiu pruvis sian valoron dum jardekoj. Se ne ekzistas profunda kompreno pri HTTP mem, tiam REST ne povas esti juĝita.
Sed pri RPC - vi povas. Sufiĉas preni ĝian specifon. Ĉu vi do bezonas ? Aŭ ĉu ankoraŭ estas malfacila REST? Vi decidas.
Mi elkore esperas, ke mi ne malŝparis vian tempon.
fonto: www.habr.com