Ez piştrast im ku sernivîsê bû sedema reaksiyonek tendurist - "baş e, dîsa dest pê kir ..." Lê bila ez 5-10 hûrdem bala we bikişînim, û ez ê hewl bidim ku hêviyên we nerazî bikim.
Avaniya gotarê dê bi vî rengî be: gotinek stereotipîk tê girtin û "xwezaya" derketina vê qalibê derdikeve holê. Ez hêvî dikim ku ev ê bihêle ku hûn ji aliyek nû ve li hilbijartina paradîgmaya danûstendina daneyê di projeyên xwe de binihêrin.
Ji bo ku ez zelal bikim ka RPC çi ye, ez pêşniyar dikim ku standard bihesibînim . Bi REST re zelaliyek tune. Û divê nebe. Her tiştê ku hûn hewce ne ku di derbarê REST de zanibin - ew jê nayê cûda kirin .
Daxwazên RPC zûtir û bikêrtir in ji ber ku ew destûrê didin we ku hûn daxwazên hevîrê bikin.
Mesele ev e ku di RPC de hûn dikarin di yek daxwazek de bi yekcarî çend proseduran bang bikin. Mînakî, bikarhênerek biafirînin, avatarek jê re zêde bikin û di heman daxwazê de, wî bibin aboneya hin mijaran. Tenê yek daxwaz, û çiqas feyde!
Bi rastî, heke we tenê yek nodek paşverû hebe, ew ê bi daxwazek hevîrê zûtir xuya bike. Ji ber ku sê daxwazên REST dê sê caran bêtir çavkaniyan ji yek nodê hewce bike ku pêwendiyan saz bikin.
Bala xwe bidinê ku daxwaza yekem di doza REST de divê nasnameya bikarhêner vegere da ku daxwazên paşîn bêne kirin. Ev jî bandorek neyînî li ser encamên giştî dike.
Lê binesaziyên weha tenê di çareseriyên hundurîn û Enterprise de têne dîtin. Wekî çareya dawîn, di projeyên piçûk ên WEB de. Lê çareseriyên WEB-ê yên bêkêmasî, û hetta yên ku jê re HighLoad têne gotin, ne hêja ne ku werin çêkirin. Pêdivî ye ku binesaziya wan pîvanên hebûna bilind û bargiraniyê bicîh bîne. Û wêne diguhere.
Kanalên çalakiya binesaziyê di bin heman senaryoyê de bi kesk têne nîşankirin. Bala xwe bidin ka RPC niha çawa tevdigere. Daxwaz binesaziyê li ser yek lingê tenê ji balanserê berbi paşîn bikar tîne. Dema ku REST hîn jî di daxwaza yekem de winda dike, ew dema winda bi karanîna tevahiya binesaziyê digire.
Bes e ku meriv ne du daxwazên dewlemendkirinê, lê bêje, pênc an deh… û bersiva pirsa "niha kî bi ser dikeve?" ne diyar dibe.
Ez pêşniyar dikim ku meriv li pirsgirêkê hîn berfirehtir binêre. Diagram nîşan dide ka kanalên binesaziyê çawa têne bikar anîn, lê binesaziya bi kanalan re sînordar nabe. Parçeyek girîng a binesaziyek bargiraniya bilind caches e. Ka em naha celebek hunera bikarhênerê bistînin. Repeatedly. Em bêjin 32 caran.
Binêrin ka binesaziya RPC çawa bi girîngî çêtir bûye da ku daxwazên bargiraniya bilind bicîh bîne. Tişt ev e ku REST berevajî RPC, hêza tevahî ya protokola HTTP bikar tîne. Di diagrama li jor de, ev hêz bi riya rêbaza daxwaznameyê - GET tê fêm kirin.
Rêbazên HTTP, di nav tiştên din de, stratejiyên caching hene. Hûn dikarin wan di belgeyê de bibînin . Ji bo RPC, daxwazên POST têne bikar anîn, yên ku bêhêz nayên hesibandin, ango dubarekirina heman daxwazên POST-ê dibe ku encamên cûda vegerîne (mînakî, piştî ku her şîrove tê şandin, dê kopiyek din a vê şîroveyê xuya bibe)).
Ji ber vê yekê, RPC nekare bi bandor binesaziyê veşêre. Ev dibe sedema hewcedariya "îtxalkirina" kaşên nermalavê. Diagram di vê rolê de Redis nîşan dide. Keşeya nermalavê, di encamê de, ji pêşdebir re hewce dike ku qatek kodek din û guhertinên berbiçav di mîmariyê de zêde bike.
Ka em niha bijmêrin ka REST û RPC di binesaziya li ber çavan de çend daxwaz "jidayikbûn"?
Daxwazên
Inbox
paşvekêşin
ji DBMS re
ber cache nerm (Redis)
TOTAL
REHETÎ
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Li gorî plansaziya yekem, cûdahî balkêş e. Niha feydeya RESTê diyar dibe. Lê ez pêşniyar dikim ku li wir nesekinim. Binesaziya pêşkeftî CDN heye. Pir caran ew pirsgirêka dijberiya êrîşên DDoS û DoS jî çareser dike. Em distînin:
Li vir tişt ji bo RPC-ê pir xirab dibin. RPC bi tenê nekare bargiraniya kar ji CDN re veguhezîne. Em tenê dikarin xwe bispêrin pergalên ku li hember êrîşan bisekinin.
Ma gengaz e ku li vir biqede? Û dîsa, na. Rêbazên HTTP, wekî ku li jor behs kirin, xwedan "efsûn" in. Û ne bê sedem e ku rêbaza GET bi berfirehî li ser Înternetê tê bikar anîn. Bala xwe bidinê ku ev rêbaz dikare bigihîje perçeyek naverokê, dikare şert û mercên ku hêmanên binesaziyê dikarin şîrove bikin berî ku kontrol ji koda we re were veguheztin, û hwd. Hemî ev dihêle hûn binesaziyên maqûl, birêkûpêk biafirînin ku dikarin herikînên bi rastî mezin ên daxwaziyan bicîh bînin. Lê di RPC de ev rêbaz ... tê paşguh kirin.
Ji ber vê yekê çima efsaneya ku daxwazên berhevokê (RPC) zûtir ew qas domdar in? Bi kesane, ji min re wusa dixuye ku pir proje bi hêsanî nagihîjin astek pêşkeftinê ku REST bikaribe hêza xwe nîşan bide. Wekî din, di projeyên piçûk de, ew bêtir dilxwaz e ku qelsiyên xwe nîşan bide.
Hilbijartina REST an RPC ne hilbijartinek dilxwazî ya kesek di projeyekê de ye. Divê ev hilbijartin hewcedariyên projeyê bicîh bîne. Ger projeyek karibe her tiştê ku bi rastî dikare ji REST derxîne, û ew bi rastî jê re hewce dike, wê hingê REST dê bijarek hêja be.
Lê heke, ji bo ku hûn hemî feydeyên REST-ê bistînin, hûn hewce ne ku hûn pisporên devops ji bo projeyê kar bikin da ku zû binesaziyê mezin bikin, rêvebiran ku binesaziyê birêve bibin, mîmarek ku hemî qatên karûbarê WEB-ê sêwirîne… û proje , di heman demê de, rojê sê pakêt margarîn difiroşe... Ez ê bi RPC re bisekinim, ji ber ku ... ev protokol bêtir bikêrhatî ye. Ew ê ne hewceyî zanîna kûr a ka kaş û binesaziyê çawa dixebite, lê dê pêşdebir li ser bangên hêsan û têgihîştî yên prosedurên ku wî hewce dike balê bikişîne. Karsaz dê kêfxweş bibin.
Daxwazên RPC pêbawertir in ji ber ku ew dikarin di nav danûstendinek yekane de daxwazên hevîrê pêk bînin
Ev taybetmendiya RPC avantajek diyar e, ji ber Ew hêsan e ku meriv databasê bihevre bimîne. Lê bi REST re ew her ku diçe tevlihevtir dibe. Dibe ku daxwaz bi rengek nehevgirtî bigihîjin girêkên paşerojê yên cûda.
Ev "dezavantaj" a REST-ê aliyek berjewendiya wê ye ku li jor hatî diyar kirin - şiyana karanîna bi bandor hemî çavkaniyên binesaziyê. Ger binesaziyek nebaş were sêwirandin, û hêj bêtir heke mîmariya projeyê û bi taybetî databas kêm were sêwirandin, wê hingê ev bi rastî êşek mezin e.
Lê gelo daxwazên bacê ew qas pêbawer in ku ew xuya dikin? Ka em li dozekê binihêrin: em bikarhênerek diafirînin, profîla wî bi hin şiroveyan dewlemend dikin û ji wî re SMSek bi veşartî dişînin da ku qeydkirinê temam bike. Ewan. sê bang li yek daxwaza hevîrê.
Ka em li diagramê binêrin. Ew binesaziyek bi hêmanên hebûna bilind pêşkêşî dike. Bi dergehên SMS re du kanalên ragihandinê yên serbixwe hene. Lê... em çi dibînin? Dema ku SMSek dişîne, xeletiyek 503 çêdibe - karûbar bi demkî nayê peyda kirin. Bo Şandina SMS di daxwaznameyek hevîrê de tête pak kirin, wê hingê pêdivî ye ku hemî daxwaz paşde were vegerandin. Çalakiyên di DBMS-ê de têne betal kirin. Xerîdar xeletiyek distîne.
Hewldana paşîn loto ye. An daxwaz dê dîsa li heman girêkekê bixe û dîsa xeletiyek vegerîne, an hûn ê bi şens bin û ew ê were darve kirin. Lê ya sereke ev e ku bi kêmanî carekê binesaziya me jixwe bêkêr xebitiye. Barek hebû, lê fêde tune.
Baş e, em bifikirin ku me xwe teng kiriye (!) û li ser vebijarka ku daxwaz dikare bi qismî bi serfirazî were qedandin fikiriye. Û em ê hewl bidin ku yên mayî piştî çend navberek demkî dîsa temam bikin (Kîjan? Pêşî biryar dide?). Lê lotik wek xwe ma. Daxwaza şandina SMS-ê şansê 50/50 heye ku dîsa têk biçe.
Bipejirînin, ji hêla xerîdar ve, karûbar bi qasî ku em dixwazin pêbawer xuya nake ... li ser REST çi ye?
REST dîsa sêrbaziya HTTP-ê bikar tîne, lê naha bi kodên bersivê. Gava ku xeletiyek 503 li ser deriyê SMS-ê çêdibe, paşverû vê xeletiyê ji balanserê re belav dike. Balanser vê xeletiyê distîne û bêyî ku têkiliya bi xerîdar re qut bike, daxwazê ji nodek din re dişîne, ku daxwazê bi serfirazî dişoxilîne. Ewan. xerîdar encama çaverêkirî distîne, û binesaziya wê sernavê bilind a "pir gihîştî" piştrast dike. Bikarhêner kêfxweş e.
Û dîsa ev ne hemî. Balanser ne tenê kodek bersivê ya 503 werdigire. Dema bersivdayinê, li gorî standardê, tê pêşniyar kirin ku hûn vê kodê bi sernavê "Dîsa biceribîne-Piştî" peyda bikin. Sernivîs ji balanserê re eşkere dike ku ne hêja ye ku ev girêk li ser vê rêyê ji bo demek diyarkirî aciz bike. Û daxwazên din ên şandina SMS-ê dê rasterast ji girêkek ku bi dergehê SMS-ê re pirsgirêk tune ne werin şandin.
Wekî ku em dibînin, pêbaweriya JSON-RPC pir zêde ye. Bi rastî, hêsantir e ku meriv hevrêziya di databasê de organîze bike. Lê fedakarî, di vê rewşê de, wê pêbaweriya pergalê bi tevahî be.
Encam bi piranî mîna ya berê ye. Gava ku binesaziyek hêsan e, eşkerebûna JSON-RPC bê guman plusek e. Ger proje hebûna zêde bi bargiraniyek mezin ve girêdayî ye, REST wekî çareseriyek rasttir, her çend tevlihevtir xuya dike.
Rêjeya têketina REST kêmtir e
Ez difikirim ku analîza li jor, ku stereotipên sazkirî yên di derbarê RPC de hilweşand, bi zelalî destnîşan kir ku sînorê têketina REST-ê bê guman ji RPC-ê bilindtir e. Ev ji ber hewcedariya têgihiştinek kûr a ka HTTP çawa dixebite, û her weha hewcedariya zanîna têr li ser hêmanên binesaziya heyî yên ku dikarin û divê di projeyên WEB de werin bikar anîn de ye.
Ji ber vê yekê çima pir kes difikirin ku REST dê hêsantir be? Nêrîna min a kesane ev e ku ev sadebûna eşkere ji REST xwe diyar dike. Ewan. REST ne protokol e lê têgehek e... REST ne xwediyê standardek e, hin rêgez hene... REST ji HTTP ne tevlihevtir e. Azadî û anarşiya xuya “hunermendên azad” dikişîne.
Bê guman, REST ji HTTP ne tevlihevtir e. Lê HTTP bixwe protokolek sêwirandî ye ku bi dehsalan hêjabûna xwe îsbat kiriye. Ger têgihîştina kûr a HTTP-ê bi xwe tune be, wê hingê REST nikare were darizandin.
Lê di derbarê RPC de - hûn dikarin. Ew bes e ku meriv taybetmendiya wê bigire. Ji ber vê yekê hûn hewce ne ? An jî ew hîn jî REST dijwar e? Hûn biryar didin.
Ez ji dil hêvî dikim ku min wextê we winda nekiriye.
Source: www.habr.com