Тақырып дұрыс реакция тудырғанына сенімдімін - «жақсы, ол қайтадан басталды...» Бірақ назарыңызды 5-10 минутқа аударуға рұқсат етіңіз, мен сіздің үміттеріңізді ақтауға тырысамын.
Мақаланың құрылымы келесідей болады: стереотиптік мәлімдеме қабылданып, осы стереотиптің пайда болуының «табиғаты» ашылады. Бұл сіздің жобаларыңызда деректер алмасу парадигмасын таңдауға жаңа қырынан қарауға мүмкіндік береді деп үміттенемін.
RPC дегеніміз не екенін түсіну үшін мен стандартты қарастыруды ұсынамын . REST көмегімен анықтық жоқ. Және ол болмауы керек. REST туралы білуіңіз керек барлық нәрсе - оны ажыратуға болмайды .
RPC сұраулары жылдамырақ және тиімдірек, себебі олар пакеттік сұрауларды жасауға мүмкіндік береді.
Мәселе мынада, RPC-де бір сұраныста бірден бірнеше процедураны шақыруға болады. Мысалы, пайдаланушы жасаңыз, оған аватар қосыңыз және сол сұрауда оны кейбір тақырыптарға жазылыңыз. Бір ғана өтініш, оның пайдасы қанша!
Шынында да, егер сізде тек бір сервер түйіні болса, ол пакеттік сұраумен жылдамырақ көрінеді. Өйткені үш REST сұрауы қосылымдарды орнату үшін бір түйіннен үш есе көп ресурстарды қажет етеді.
REST жағдайындағы бірінші сұрау келесі сұраулар жасалуы үшін пайдаланушы идентификаторын қайтаруы керек екенін ескеріңіз. Бұл да жалпы нәтижеге теріс әсер етеді.
Бірақ мұндай инфрақұрылымдарды тек ішкі шешімдер мен кәсіпорында табуға болады. Соңғы шара ретінде шағын WEB жобаларында. Бірақ толыққанды WEB шешімдері, тіпті HighLoad деп аталатындар да құруға тұрарлық емес. Олардың инфрақұрылымы жоғары қолжетімділік пен жүктеме критерийлеріне сай болуы керек. Ал сурет өзгереді.
Бір сценарий бойынша инфрақұрылымдық қызмет арналары жасыл түспен белгіленген. RPC қазір қалай әрекет ететініне назар аударыңыз. Сұрау теңдестіргіштен серверге дейін тек бір аяқта инфрақұрылымды пайдаланады. REST бірінші сұрауда әлі жоғалса да, ол бүкіл инфрақұрылымды пайдалана отырып, жоғалған уақыттың орнын толтырады.
Сценарийге байыту туралы екі өтініш емес, айталық, бес-он... және «енді кім жеңеді?» деген сұраққа жауап беру жеткілікті. түсініксіз болады.
Мен мәселеге кеңірек қарауды ұсынамын. Диаграмма инфрақұрылым арналарының қалай пайдаланылатынын көрсетеді, бірақ инфрақұрылым арналармен шектелмейді. Жоғары жүктемелі инфрақұрылымның маңызды құрамдас бөлігі кэштер болып табылады. Енді пайдаланушы артефактінің қандай да бір түрін алайық. Бірнеше рет. 32 рет айтайық.
Жоғары жүктеме талаптарын қанағаттандыру үшін RPC инфрақұрылымының қалай айтарлықтай жақсарғанын қараңыз. Мәселе мынада, REST RPC-ден айырмашылығы HTTP протоколының толық қуатын пайдаланады. Жоғарыдағы диаграммада бұл қуат сұрау әдісі - GET арқылы жүзеге асырылады.
HTTP әдістерінде, басқалармен қатар, кэштеу стратегиялары бар. Сіз оларды құжаттамадан таба аласыз . RPC үшін идемпотентті болып саналмайтын POST сұраулары пайдаланылады, яғни бір POST сұрауларының қайталануы әртүрлі нәтижелерді беруі мүмкін (мысалы, әрбір түсініктеме жіберілгеннен кейін осы түсініктеменің басқа көшірмесі пайда болады) ().
Демек, RPC инфрақұрылым кэштерін тиімді пайдалана алмайды. Бұл бағдарламалық жасақтама кэштерін «импорттау» қажеттілігіне әкеледі. Диаграмма осы рөлде Редисті көрсетеді. Бағдарламалық жасақтаманың кэші өз кезегінде әзірлеушіден кодтың қосымша қабатын және архитектурадағы елеулі өзгерістерді қосуды талап етеді.
Енді қарастырылып жатқан инфрақұрылымда REST және RPC қанша сұранысты «туғанын» санап көрейік?
сұраулар
Кіріс жәшігі
серверге
ДҚБЖ-ға
жұмсақ кэшке (Redis)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
RPC
32
32
1
31
96
Бірінші схемамен салыстырғанда, айырмашылық таң қалдырады. Енді REST артықшылығы анық болды. Бірақ мен мұнымен тоқтамауды ұсынамын. Дамыған инфрақұрылымға CDN кіреді. Көбінесе ол DDoS және DoS шабуылдарына қарсы тұру мәселесін шешеді. Біз алып жатырмыз:
Бұл жерде RPC үшін жағдай өте нашар болады. RPC жұмыс жүктемесін CDN-ге тапсыра алмайды. Біз тек шабуылдарға қарсы тұру үшін жүйелерге сене аламыз.
Осымен аяқталуы мүмкін бе? Және тағы да, жоқ. HTTP әдістері, жоғарыда айтылғандай, өздерінің «сиқыры» бар. Интернетте GET әдісінің кеңінен қолданылуы бекер емес. Бұл әдіс мазмұнның бір бөлігіне қол жеткізе алатынын, басқару кодыңызға тасымалданбас бұрын инфрақұрылым элементтері түсіндіре алатын шарттарды орнатуға қабілетті екенін және т.б. Мұның бәрі сұраулардың шынымен үлкен ағындарын өңдей алатын икемді, басқарылатын инфрақұрылымдарды жасауға мүмкіндік береді. Бірақ RPC-де бұл әдіс... еленбейді.
Неліктен пакеттік сұраулар (RPC) жылдамырақ деген миф соншалықты тұрақты? Менің ойымша, жобалардың көпшілігі REST өзінің күшін көрсете алатын даму деңгейіне жете алмайды. Оның үстіне, шағын жобаларда ол өзінің әлсіз жақтарын көрсетуге дайын.
REST немесе RPC таңдау жобадағы жеке адамның ерікті таңдауы емес. Бұл таңдау жобаның талаптарына сай болуы керек. Егер жоба REST ішінен шынымен қолынан келгеннің барлығын сығып алса және оған шынымен қажет болса, REST тамаша таңдау болады.
Бірақ егер REST-тің барлық артықшылықтарын алу үшін инфрақұрылымды жылдам масштабтауға арналған жобаға devops мамандарын, инфрақұрылымды басқару үшін әкімшілерді, WEB қызметінің барлық қабаттарын жобалау үшін сәулетшіні... және жобаны жалдау қажет болса. , сонымен бірге күніне үш қорап маргарин сатады... Мен RPC-ді ұстанатын едім, өйткені... бұл протокол тиімдірек. Ол кэштер мен инфрақұрылымның қалай жұмыс істейтіні туралы терең білімді қажет етпейді, бірақ әзірлеушіге қажетті процедураларға қарапайым және түсінікті қоңырауларға назар аударады. Бизнес бақытты болады.
RPC сұраулары сенімдірек, себебі олар пакеттік сұрауларды бір транзакция ішінде орындай алады
RPC бұл қасиеті белгілі артықшылық болып табылады, өйткені Дерекқорды дәйекті сақтау оңай. Бірақ REST көмегімен ол барған сайын күрделене түседі. Сұраулар әртүрлі серверлік түйіндерге сәйкес келмеуі мүмкін.
REST-тің бұл «кемшілігі» оның жоғарыда сипатталған артықшылығының екінші жағы - барлық инфрақұрылымдық ресурстарды тиімді пайдалану мүмкіндігі. Егер инфрақұрылым нашар жобаланған болса және одан да көп жобаның архитектурасы және әсіресе деректер базасы нашар жобаланған болса, бұл шынымен де үлкен азап.
Бірақ пакеттік сұраулар көрінгендей сенімді ме? Бір жағдайды қарастырайық: біз пайдаланушы жасаймыз, оның профилін кейбір сипаттамалармен байытамыз және тіркеуді аяқтау үшін құпиясы бар SMS жібереміз. Анау. бір пакеттік сұраудағы үш қоңырау.
Диаграмманы қарастырайық. Ол жоғары қолжетімділік элементтері бар инфрақұрылымды ұсынады. SMS шлюздері бар екі тәуелсіз байланыс арнасы бар. Бірақ... біз не көріп тұрмыз? SMS жіберу кезінде 503 қатесі пайда болады - қызмет уақытша қолжетімсіз. Өйткені SMS жіберу пакеттік сұранысқа жинақталған, содан кейін бүкіл сұрау кері қайтарылуы керек. ДҚБЖ-дағы әрекеттер жойылады. Клиент қатені алады.
Келесі әрекет - лотерея. Сұраныс бір түйінге қайта-қайта соғылып, қатені қайтарады немесе сәттілікке ие боласыз және ол орындалады. Бірақ ең бастысы, бір рет болса да инфрақұрылымымыз бекер жұмыс істеп үлгерді. Жүк болды, бірақ пайда жоқ.
Жарайды, біз өзімізді қиындатып (!) Елестетіп көрейік және сұрауды жартылай сәтті аяқтауға болатын опцияны ойластырдық. Ал қалғанын біраз уақыт аралығынан кейін қайта аяқтауға тырысамыз (Қайсысы? Майдан шеше ме?). Бірақ лотерея сол күйінде қалды. SMS жіберу сұрауының қайта сәтсіздікке ұшырау мүмкіндігі 50/50.
Келісіңіз, клиент тарапынан қызмет біз қалағандай сенімді емес сияқты... REST туралы не айтасыз?
REST HTTP сиқырын қайтадан пайдаланады, бірақ енді жауап кодтары бар. SMS шлюзінде 503 қатесі орын алған кезде, сервер бұл қатені балансизаторға таратады. Баланстауыш бұл қатені алады және клиентпен байланысты үзбей сұрауды сәтті өңдейтін басқа түйінге жібереді. Анау. клиент күтілетін нәтижені алады, ал инфрақұрылым оның «жоғары қолжетімді» деген жоғары атағын растайды. Пайдаланушы қуанады.
Және тағы да бұл бәрі емес. Теңгерім 503 жауап кодын жай ғана алған жоқ. Жауап беру кезінде стандартқа сәйкес бұл кодты «Қайталау-Кейін» тақырыбымен берген жөн. Тақырып теңгерушіге осы маршруттағы бұл түйінді белгілі бір уақыт ішінде бұзудың қажеті жоқ екенін түсіндіреді. Ал SMS жіберуге келесі сұраулар тікелей SMS шлюзімен проблемалары жоқ түйінге жіберіледі.
Көріп отырғанымыздай, JSON-RPC сенімділігі жоғары бағаланған. Шынында да, дерекқордағы жүйелілікті ұйымдастыру оңайырақ. Бірақ құрбандық, бұл жағдайда, тұтастай алғанда жүйенің сенімділігі болады.
Қорытынды негізінен алдыңғыға ұқсас. Инфрақұрылым қарапайым болған кезде, JSON-RPC айқындығы сөзсіз плюс. Егер жоба жоғары жүктемемен жоғары қолжетімділікті қамтыса, REST күрделірек болса да дұрысырақ шешім болып көрінеді.
REST-ке кіру шегі төмен
Менің ойымша, жоғарыда келтірілген талдау, RPC туралы қалыптасқан стереотиптерді жоққа шығара отырып, REST-ке кіру шегінің RPC-ге қарағанда жоғары екенін анық көрсетті. Бұл HTTP қалай жұмыс істейтінін терең түсіну қажеттілігімен, сондай-ақ WEB жобаларында пайдаланылуы мүмкін және қажет болатын бар инфрақұрылым элементтері туралы жеткілікті білімнің қажеттілігімен байланысты.
Неліктен көптеген адамдар REST оңайырақ болады деп ойлайды? Менің жеке пікірім, бұл көрінетін қарапайымдылық REST көріністерінен туындайды. Анау. REST протокол емес, концепция... REST стандарты жоқ, кейбір нұсқаулар бар... REST HTTP-ден күрделі емес. Көрінетін еркіндік пен анархия «еркін суретшілерді» тартады.
Әрине, REST HTTP-ден күрделі емес. Бірақ HTTP өзі ондаған жылдар бойы өзінің құндылығын дәлелдеген жақсы жобаланған протокол. HTTP өзін терең түсіну болмаса, REST-ті бағалау мүмкін емес.
Бірақ RPC туралы - сіз аласыз. Оның сипаттамасын алу жеткілікті. Сонымен сізге керек пе ? Немесе бұл әлі де қиын REST ме? Өзің шеш.
Уақытыңызды босқа өткізген жоқпын деп шын жүректен үміттенемін.
Ақпарат көзі: www.habr.com