JSON-RPC? Կատարեք բարդ ՀԱՆԳՍՏ

Վստահ եմ, որ վերնագիրն առողջ արձագանք է առաջացրել՝ «դե, նորից սկսվեց...»: Բայց թույլ տվեք գրավել ձեր ուշադրությունը 5-10 րոպեով, և ես կփորձեմ չհիասթափեցնել ձեր սպասելիքները:

Հոդվածի կառուցվածքը կլինի հետևյալը. վերցվում է կարծրատիպային հայտարարություն և բացահայտվում է այդ կարծրատիպի առաջացման «բնույթը»։ Հուսով եմ, որ դա ձեզ թույլ կտա նոր տեսանկյունից նայել ձեր նախագծերում տվյալների փոխանակման հարացույցի ընտրությանը:

Որպեսզի պարզ լինի, թե ինչ է RPC-ն, ես առաջարկում եմ դիտարկել ստանդարտը JSON-RPC 2.0. REST-ի հետ հստակություն չկա: Եվ դա չպետք է լինի: Այն ամենը, ինչ դուք պետք է իմանաք REST-ի մասին, այն չի տարբերվում նրանից HTTP.

RPC հարցումներն ավելի արագ և արդյունավետ են, քանի որ դրանք թույլ են տալիս կատարել խմբաքանակի հարցումներ:

Բանն այն է, որ RPC-ում կարելի է միանգամից մի քանի պրոցեդուրա կանչել մեկ հարցումով։ Օրինակ՝ օգտատեր ստեղծեք, նրան ավելացրեք ավատար և նույն հարցումով բաժանորդագրվեք որոշ թեմաների։ Ընդամենը մեկ խնդրանք, և որքան օգուտ:

Իսկապես, եթե դուք ունեք միայն մեկ հետնամասային հանգույց, այն ավելի արագ կթվա խմբաքանակի հարցումով: Քանի որ երեք REST հարցումներ կպահանջեն երեք անգամ ավելի շատ ռեսուրսներ մեկ հանգույցից կապեր հաստատելու համար:

Նկատի ունեցեք, որ REST-ի դեպքում առաջին հարցումը պետք է վերադարձնի օգտվողի ID-ն, որպեսզի հետագա հարցումները կատարվեն: Ինչը նույնպես բացասաբար է անդրադառնում ընդհանուր արդյունքի վրա։

Բայց նման ենթակառուցվածքներ կարելի է գտնել միայն ներքին լուծումներում և Enterprise-ում: Որպես վերջին միջոց՝ փոքր WEB նախագծերում։ Սակայն լիարժեք WEB լուծումները, և նույնիսկ նրանք, որոնք կոչվում են HighLoad, չարժե կառուցել: Նրանց ենթակառուցվածքը պետք է համապատասխանի բարձր հասանելիության և ծանրաբեռնվածության չափանիշներին: Եվ պատկերը փոխվում է։

Նույն սցենարով ենթակառուցվածքային գործունեության ուղիները նշված են կանաչ գույնով: Ուշադրություն դարձրեք, թե ինչպես է RPC-ն իրեն պահում հիմա: Հարցումը օգտագործում է ենթակառուցվածքը միայն մեկ ոտքի վրա՝ հավասարակշռողից մինչև հետնամաս: Մինչ REST-ը դեռ կորցնում է առաջին հարցումը, այն լրացնում է կորցրած ժամանակը՝ օգտագործելով ամբողջ ենթակառուցվածքը:

Բավական է սցենար մտնել ոչ թե երկու հարստացման խնդրանք, այլ ասենք հինգ կամ տասը... և «ո՞վ է հիմա հաղթում» հարցի պատասխանը. անհասկանալի է դառնում.

Առաջարկում եմ խնդրին էլ ավելի լայն նայել։ Դիագրամը ցույց է տալիս, թե ինչպես են օգտագործվում ենթակառուցվածքային ալիքները, սակայն ենթակառուցվածքը չի սահմանափակվում միայն ալիքներով: Բարձր բեռնված ենթակառուցվածքի կարևոր բաղադրիչը քեշերն են: Եկեք հիմա ստանանք օգտագործողի արտեֆակտ: Բազմիցս. Ասենք 32 անգամ։

Տեսեք, թե ինչպես է RPC ենթակառուցվածքը զգալիորեն բարելավվել՝ բավարարելու բարձր բեռի պահանջները: Բանն այն է, որ REST-ն օգտագործում է HTTP պրոտոկոլի ամբողջ հզորությունը՝ ի տարբերություն RPC-ի։ Վերևի գծապատկերում այս հզորությունը իրականացվում է հարցման մեթոդի միջոցով՝ GET:

HTTP մեթոդները, ի թիվս այլ բաների, ունեն քեշավորման ռազմավարություններ: Դուք կարող եք գտնել դրանք փաստաթղթերում HTTP. RPC-ի համար օգտագործվում են POST հարցումներ, որոնք չեն համարվում անիմաստ, այսինքն՝ նույն POST հարցումների կրկնվող կրկնությունները կարող են տարբեր արդյունքներ տալ (օրինակ՝ յուրաքանչյուր մեկնաբանություն ուղարկելուց հետո կհայտնվի այս մեկնաբանության մեկ այլ օրինակ) (աղբյուր).

Հետևաբար, RPC-ն ի վիճակի չէ արդյունավետ օգտագործել ենթակառուցվածքի քեշերը: Սա հանգեցնում է ծրագրային ապահովման քեշերի «ներմուծման» անհրաժեշտության: Դիագրամը ցույց է տալիս Ռեդիսին այս դերում: Ծրագրային ապահովման քեշը, իր հերթին, պահանջում է մշակողից ավելացնել կոդի լրացուցիչ շերտ և նկատելի փոփոխություններ ճարտարապետության մեջ։

Հիմա հաշվենք, թե REST-ը և RPC-ն քանի՞ հարցում են «ծնել» դիտարկվող ենթակառուցվածքում:

հարցումները
Inbox
backend-ի համար
DBMS-ին
դեպի փափուկ քեշ (Redis)
TOTAL- ը

ՀԱՆԳՍՏՅԱՆ
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] լավագույն դեպքում (եթե օգտագործվում է տեղական քեշը) 1 հարցում (մեկ!), վատագույն դեպքում՝ 32 մուտքային հարցում։

Առաջին սխեմայի համեմատ տարբերությունը ապշեցուցիչ է. Հիմա պարզ է դառնում ՀԱՆԳՍՏԻ օգուտը։ Բայց ես առաջարկում եմ դրանով կանգ չառնել։ Մշակված ենթակառուցվածքը ներառում է CDN: Հաճախ այն նաև լուծում է DDoS և DoS հարձակումներին դիմակայելու հարցը։ Մենք ստանում ենք.

Սա այն վայրն է, որտեղ ամեն ինչ իսկապես վատ է դառնում RPC-ի համար: RPC-ն պարզապես ի վիճակի չէ աշխատանքային ծանրաբեռնվածությունը փոխանցել CDN-ին: Մենք կարող ենք ապավինել միայն համակարգերին՝ հարձակումներին հակազդելու համար:

Հնարավո՞ր է այստեղ ավարտվել: Եվ նորից՝ ոչ։ HTTP մեթոդները, ինչպես նշվեց վերևում, ունեն իրենց «կախարդանքը»: Եվ առանց պատճառի չէ, որ GET մեթոդը լայնորեն կիրառվում է ինտերնետում: Նկատի ունեցեք, որ այս մեթոդը կարող է մուտք գործել բովանդակության մի հատված, կարող է պայմաններ սահմանել, որոնք ենթակառուցվածքի տարրերը կարող են մեկնաբանել նախքան վերահսկողությունը ձեր կոդի վրա փոխանցելը և այլն: Այս ամենը թույլ է տալիս ստեղծել ճկուն, կառավարելի ենթակառուցվածքներ, որոնք կարող են կարգավորել հարցումների իսկապես մեծ հոսքեր: Բայց RPC-ում այս մեթոդը... անտեսվում է:

Այսպիսով, ինչու՞ է առասպելն այն մասին, որ խմբաքանակի հարցումները (RPC) ավելի արագ են այդքան համառ: Անձամբ ինձ թվում է, որ նախագծերի մեծ մասը պարզապես չի հասնում զարգացման այնպիսի մակարդակի, որտեղ REST-ը կարողանա ցույց տալ իր ուժը։ Ավելին, փոքր նախագծերում նա ավելի պատրաստ է ցույց տալ իր թույլ կողմերը։

REST-ի կամ RPC-ի ընտրությունը նախագծում անհատի կամավոր ընտրությունը չէ: Այս ընտրությունը պետք է համապատասխանի նախագծի պահանջներին: Եթե ​​նախագիծն ի վիճակի է քամել այն ամենը, ինչ իրականում կարող է REST-ից, և դա իսկապես կարիք ունի, ապա REST-ը հիանալի ընտրություն կլինի:

Բայց եթե REST-ի բոլոր առավելությունները ստանալու համար դուք պետք է վարձեք մշակող մասնագետներ նախագծի համար՝ ենթակառուցվածքը արագ չափելու համար, ադմինիստրատորներ՝ ենթակառուցվածքը կառավարելու համար, ճարտարապետ՝ WEB ծառայության բոլոր շերտերը նախագծելու համար... և նախագիծը: , միևնույն ժամանակ վաճառում է օրական երեք տուփ մարգարին... Ես կկպչեի RPC-ով, քանի որ... այս արձանագրությունն ավելի օգտակար է: Այն չի պահանջի խորը գիտելիքներ այն մասին, թե ինչպես են աշխատում քեշերը և ենթակառուցվածքը, այլ կկենտրոնացնի ծրագրավորողին պարզ և հասկանալի զանգեր՝ իրեն անհրաժեշտ ընթացակարգերի վրա: Բիզնեսը ուրախ կլինի:

RPC հարցումներն ավելի հուսալի են, քանի որ դրանք կարող են կատարել փաթեթային հարցումներ մեկ գործարքի ընթացքում

RPC-ի այս հատկությունը որոշակի առավելություն է, քանի որ Հեշտ է տվյալների բազան հետևողական պահել: Բայց REST-ի հետ ավելի ու ավելի է բարդանում: Հարցումները կարող են անհամապատասխան կերպով հասնել տարբեր հետնամասային հանգույցներ:

REST-ի այս «թերությունը» վերը նկարագրված նրա առավելությունի հակառակ կողմն է՝ բոլոր ենթակառուցվածքային ռեսուրսները արդյունավետ օգտագործելու կարողությունը: Եթե ​​ենթակառուցվածքը վատ է նախագծված, և առավել եւս, եթե նախագծի ճարտարապետությունը և հատկապես տվյալների բազան վատ են նախագծված, ապա սա իսկապես մեծ ցավ է:

Բայց արդյո՞ք խմբաքանակի հարցումներն այնքան հուսալի են, որքան թվում են: Դիտարկենք մի դեպք. մենք ստեղծում ենք օգտատեր, հարստացնում ենք նրա պրոֆիլը ինչ-որ նկարագրությամբ և գաղտնի SMS ուղարկում նրան գրանցումն ավարտելու համար: Նրանք. երեք զանգ մեկ խմբաքանակի հարցում:

Եկեք նայենք դիագրամին: Այն ներկայացնում է բարձր հասանելիության տարրերով ենթակառուցվածք: Կան երկու անկախ կապի ուղիներ՝ SMS դարպասներով: Բայց... ի՞նչ ենք մենք տեսնում։ SMS ուղարկելիս տեղի է ունենում 503 սխալ՝ ծառայությունը ժամանակավորապես անհասանելի է: Որովհետեւ SMS ուղարկումը փաթեթավորվում է խմբաքանակի հարցումով, այնուհետև ամբողջ հարցումը պետք է հետ վերադարձվի: Գործողությունները DBMS-ում չեղարկված են: Հաճախորդը սխալ է ստանում:

Հաջորդ փորձը վիճակախաղն է: Կամ հարցումը նորից կհարվածի նույն հանգույցին և նորից սխալ կվերադարձնի, կամ ձեր բախտը կբերի և այն կկատարվի: Բայց գլխավորն այն է, որ գոնե մեկ անգամ մեր ենթակառուցվածքն արդեն իզուր է աշխատել։ Բեռ կար, բայց շահ չկար։

Լավ, եկեք պատկերացնենք, որ մենք լարվել ենք մեզ (!) և մտածել ենք այն տարբերակը, երբ հարցումը կարող է մասնակիորեն ավարտվել հաջողությամբ: Իսկ մնացածը որոշ ժամանակային ընդմիջումից հետո նորից կփորձենք լրացնել (Ո՞րը, ճակատն է որոշում)։ Բայց վիճակախաղը մնաց նույնը։ SMS ուղարկելու հարցումը կրկին ձախողվելու հավանականությունը 50/50 է:

Համաձայնեք, հաճախորդի կողմից ծառայությունն այնքան հուսալի չի թվում, որքան մենք կցանկանայինք... իսկ REST-ը:

REST-ը կրկին օգտագործում է HTTP-ի կախարդանքը, բայց այժմ պատասխանի կոդերով: Երբ 503 սխալ է տեղի ունենում SMS դարպասի վրա, հետնախագիծը հեռարձակում է այս սխալը հավասարակշռողին: Հավասարակշռողը ստանում է այս սխալը և առանց խզելու հաճախորդի հետ կապը, հարցումն ուղարկում է մեկ այլ հանգույց, որը հաջողությամբ մշակում է հարցումը։ Նրանք. հաճախորդը ստանում է ակնկալվող արդյունքը, իսկ ենթակառուցվածքը հաստատում է «բարձր հասանելիության» իր բարձր կոչումը: Օգտագործողը գոհ է:

Եվ կրկին սա դեռ ամենը չէ. Հավասարակշռողը պարզապես չի ստացել պատասխանի 503 ծածկագիրը: Պատասխանելիս, ըստ ստանդարտի, խորհուրդ է տրվում այս կոդը տրամադրել «Reetry-After» վերնագրով: Վերնագիրը հստակեցնում է հավասարակշռողին, որ չարժե այս երթուղու այս հանգույցը որոշակի ժամանակով անհանգստացնել: Իսկ SMS ուղարկելու հաջորդ հարցումները կուղարկվեն անմիջապես մի հանգույց, որը խնդիրներ չունի SMS դարպասի հետ:

Ինչպես տեսնում ենք, JSON-RPC-ի հուսալիությունը գերագնահատված է: Իսկապես, տվյալների բազայում ավելի հեշտ է հետևողականություն կազմակերպել: Բայց զոհաբերությունն այս դեպքում կլինի ամբողջ համակարգի հուսալիությունը։

Եզրակացությունը մեծապես նման է նախորդին. Երբ ենթակառուցվածքը պարզ է, JSON-RPC-ի ակնհայտությունը միանշանակ առավելություն է: Եթե ​​նախագիծը ներառում է բարձր հասանելիություն մեծ բեռով, REST-ն ավելի ճիշտ, թեև ավելի բարդ լուծում է թվում:

REST-ի մուտքի շեմն ավելի ցածր է

Կարծում եմ, որ վերոնշյալ վերլուծությունը, տապալելով RPC-ի վերաբերյալ հաստատված կարծրատիպերը, հստակ ցույց տվեց, որ REST-ի մուտքի շեմը, անկասկած, ավելի բարձր է, քան RPC-ին: Սա պայմանավորված է HTTP-ի աշխատանքի խորը ընկալման անհրաժեշտությամբ, ինչպես նաև առկա ենթակառուցվածքային տարրերի մասին բավարար գիտելիքներ ունենալու անհրաժեշտությամբ, որոնք կարող են և պետք է օգտագործվեն WEB նախագծերում:

Ուրեմն ինչու են շատերը կարծում, որ ՀԱՆԳՍՏԱՑՈՒՄն ավելի պարզ կլինի: Իմ անձնական կարծիքն այն է, որ այս թվացյալ պարզությունը գալիս է ՀԱՆԳՍՏԻ դրսևորումներից: Նրանք. REST-ը պրոտոկոլ չէ, այլ հայեցակարգ... REST-ը ստանդարտ չունի, կան որոշ ուղեցույցներ... REST-ը HTTP-ից ավելի բարդ չէ: Թվացյալ ազատությունն ու անարխիան գրավում են «ազատ արվեստագետներին»:

Իհարկե, REST-ը HTTP-ից ավելի բարդ չէ: Բայց HTTP-ն ինքնին լավ մշակված արձանագրություն է, որն ապացուցել է իր արժեքը տասնամյակների ընթացքում: Եթե ​​չկա ինքնին HTTP-ի խորը ըմբռնում, ապա REST-ին չի կարելի դատել:

Բայց RPC-ի մասին - կարող եք: Բավական է վերցնել դրա ճշգրտումը։ Այսպիսով, դուք պետք է հիմար JSON-RPC? Թե՞ դեռ բարդ ՀԱՆԳՍՏՈՒՄ է: Դուք որոշեք.

Ես անկեղծորեն հուսով եմ, որ ես իզուր չեմ վատնել ձեր ժամանակը:

Source: www.habr.com