Сигуран сам да је наслов изазвао здраву реакцију - "па, опет је почело..." Али дозволите ми да вам заокупим пажњу на 5-10 минута и потрудићу се да не разочарам ваша очекивања.
Структура чланка ће бити следећа: узима се стереотипна изјава и открива се „природа” настанка овог стереотипа. Надам се да ће вам ово омогућити да сагледате избор парадигме размене података у вашим пројектима из новог угла.
Да би било јасно шта је РПЦ, предлажем да размотримо стандард . Са РЕСТ-ом нема јасноће. И не би требало да буде. Све што треба да знате о РЕСТ-у - то се не разликује од .
РПЦ захтеви су бржи и ефикаснији јер вам омогућавају да правите пакетне захтеве.
Поента је да у РПЦ-у можете позвати неколико процедура одједном у једном захтеву. На пример, направите корисника, додајте му аватар и, у истом захтеву, претплатите га на неке теме. Само један захтев, а колика корист!
Заиста, ако имате само један позадински чвор, то ће изгледати брже са пакетним захтевом. Зато што ће три РЕСТ захтева захтевати три пута више ресурса из једног чвора да би се успоставиле везе.
Имајте на уму да први захтев у случају РЕСТ-а мора да врати кориснички ИД да би се извршили наредни захтеви. Што такође негативно утиче на укупан резултат.
Али такве инфраструктуре се могу наћи само у интерним решењима и Ентерприсе. У крајњем случају, у малим ВЕБ пројектима. Али пуноправна ВЕБ решења, па чак и она која се зову ХигхЛоад, нису вредна изградње. Њихова инфраструктура мора да испуњава критеријуме високе доступности и оптерећења. И слика се мења.
Канали инфраструктурних активности по истом сценарију су означени зеленом бојом. Обратите пажњу на то како се РПЦ понаша сада. Захтев користи инфраструктуру само на једној нози од балансера до позадине. Док РЕСТ и даље губи у првом захтеву, он надокнађује изгубљено време користећи целокупну инфраструктуру.
Довољно је уписати у сценарио не два захтева за богаћење, већ, рецимо, пет или десет... и одговор на питање „ко сада побеђује?“ постаје нејасно.
Предлажем да се проблем сагледа још шире. Дијаграм показује како се инфраструктурни канали користе, али инфраструктура није ограничена на канале. Важна компонента инфраструктуре високог оптерећења су кеш меморије. Хајде сада да добијемо неку врсту корисничког артефакта. У више наврата. Рецимо 32 пута.
Погледајте како се РПЦ инфраструктура значајно побољшала да би задовољила захтеве високог оптерећења. Ствар је у томе што РЕСТ користи пуну снагу ХТТП протокола, за разлику од РПЦ-а. На дијаграму изнад, ова моћ се реализује путем методе захтева – ГЕТ.
ХТТП методе, између осталог, имају стратегије кеширања. Можете их пронаћи у документацији на . За РПЦ се користе ПОСТ захтеви који се не сматрају идемпотентним, односно поновљена понављања истих ПОСТ захтева могу да дају различите резултате (на пример, након слања сваког коментара, појавиће се још једна копија овог коментара) ().
Сходно томе, РПЦ није у стању да ефикасно користи инфраструктурне кеш меморије. Ово доводи до потребе за „увозом“ софтверских кеша. Дијаграм приказује Редис у овој улози. Софтверска кеш меморија, заузврат, захтева од програмера да дода додатни слој кода и приметне промене у архитектури.
Хајде да сада избројимо колико је захтева РЕСТ и РПЦ „породило“ у инфраструктури која се разматра?
zahtevi
Примљено
то бацкенд
на ДБМС
у меку кеш меморију (Редис)
УКУПНО
ОДМОР
КСНУМКС / КСНУМКС *
1
1
0
КСНУМКС / КСНУМКС
РПЦ
32
32
1
31
96
У поређењу са првом шемом, разлика је упадљива. Сада постаје јасна корист од РЕСТ-а. Али предлажем да се ту не зауставља. Развијена инфраструктура укључује ЦДН. Често такође решава питање супротстављања ДДоС и ДоС нападима. Добијамо:
Овде ствари постају заиста лоше за РПЦ. РПЦ једноставно није у стању да делегира радно оптерећење на ЦДН. Можемо се ослонити само на системе за сузбијање напада.
Да ли је могуће завршити овде? И опет, не. ХТТП методе, као што је горе поменуто, имају своју „магију“. И није без разлога што се метода ГЕТ широко користи на Интернету. Имајте на уму да овај метод може да приступи делу садржаја, може да постави услове које елементи инфраструктуре могу да тумаче пре него што се контрола пренесе на ваш код, итд. Све ово вам омогућава да креирате флексибилну инфраструктуру којом се може управљати која може да поднесе заиста велике токове захтева. Али у РПЦ-у овај метод... се игнорише.
Па зашто је мит да су пакетни захтеви (РПЦ) бржи тако упоран? Лично ми се чини да већина пројеката једноставно не достиже ниво развоја где РЕСТ може да покаже своју снагу. Штавише, у малим пројектима, он је спремнији да покаже своје слабости.
Избор РЕСТ-а или РПЦ-а није вољни избор појединца у пројекту. Овај избор мора задовољити захтеве пројекта. Ако је пројекат у стању да из РЕСТ-а истисне све што заиста може, а то му је заиста потребно, онда ће РЕСТ бити одличан избор.
Али ако, да бисте добили све предности РЕСТ-а, морате да ангажујете девопс стручњаке за пројекат да брзо скалирају инфраструктуру, администраторе да управљају инфраструктуром, архитекту да дизајнира све слојеве ВЕБ услуге... и пројекат , у исто време продаје три паковања маргарина дневно... Ја бих се држао РПЦ-а, јер... овај протокол је више утилитаран. Неће захтевати дубоко знање о томе како кеш меморије и инфраструктура функционишу, већ ће се програмер фокусирати на једноставне и разумљиве позиве процедурама које су му потребне. Посао ће бити срећан.
РПЦ захтеви су поузданији јер могу да изврше групне захтеве у оквиру једне трансакције
Ово својство РПЦ-а је дефинитивна предност, јер Лако је одржавати базу података доследном. Али са РЕСТ-ом то постаје све компликованије. Захтеви могу да стижу недоследно на различите позадинске чворове.
Овај „недостатак“ РЕСТ-а је супротна страна његове предности описане изнад – способност да се ефикасно користе сви инфраструктурни ресурси. Ако је инфраструктура лоше дизајнирана, а још више ако су архитектура пројекта и посебно базе података лоше дизајнирани, онда је то заиста велика мука.
Али да ли су пакетни захтеви поуздани као што изгледају? Хајде да погледамо случај: креирамо корисника, обогатимо његов профил неким описом и пошаљемо му СМС са тајном да заврши регистрацију. Оне. три позива у једном пакетном захтеву.
Погледајмо дијаграм. Представља инфраструктуру са елементима високе доступности. Постоје два независна комуникациона канала са СМС гатеваи-има. Али... шта видимо? Приликом слања СМС-а јавља се грешка 503 - услуга је привремено недоступна. Јер Слање СМС-а је упаковано у пакетни захтев, а затим се цео захтев мора вратити назад. Акције у ДБМС-у су отказане. Клијент добија грешку.
Следећи покушај је лутрија. Или ће захтев поново погодити исти чвор и поново вратити грешку, или ћете имати среће и биће извршен. Али главна ствар је да је бар једном наша инфраструктура већ узалуд радила. Било је оптерећења, али не и профита.
Добро, замислимо да смо се напрегнули (!) и размислили о опцији када се захтев може делимично успешно завршити. А остатак ћемо покушати да завршимо поново након неког временског интервала (Који? Да ли фронт одлучује?). Али лутрија је остала иста. Захтев за слањем СМС-а има 50/50 шансе да поново не успе.
Слажем се, са стране клијента, услуга не делује тако поуздано колико бисмо желели... шта је са РЕСТ-ом?
РЕСТ поново користи магију ХТТП-а, али сада са кодовима одговора. Када се грешка 503 појави на СМС гатеваи-у, позадинска мрежа емитује ову грешку балансеру. Балансер прима ову грешку и без прекида везе са клијентом, шаље захтев другом чвору, који успешно обрађује захтев. Оне. клијент добија очекивани резултат, а инфраструктура потврђује своју високу титулу „високо приступачне“. Корисник је задовољан.
И опет то није све. Балансер није само добио код одговора 503. Приликом одговарања, према стандарду, препоручљиво је да овај код обезбедите са заглављем „Ретри-Афтер“. Заглавље јасно ставља до знања балансеру да не вреди ометати овај чвор на овој рути одређено време. А следећи захтеви за слање СМС-а биће послати директно чвору који нема проблема са СМС гатеваи-ом.
Као што видимо, поузданост ЈСОН-РПЦ-а је прецењена. Заиста, лакше је организовати доследност у бази података. Али жртва ће, у овом случају, бити поузданост система у целини.
Закључак је у великој мери сличан претходном. Када је инфраструктура једноставна, очигледност ЈСОН-РПЦ-а је дефинитивно плус. Ако пројекат укључује високу доступност са великим оптерећењем, РЕСТ изгледа као исправније, иако сложеније решење.
Праг уласка у РЕСТ је нижи
Мислим да је горња анализа, разоткривајући устаљене стереотипе о РПЦ, јасно показала да је праг за улазак у РЕСТ несумњиво већи него у РПЦ. Ово је због потребе за дубљим разумевањем како ХТТП функционише, као и потребе да се поседује довољно знања о постојећим елементима инфраструктуре који се могу и треба користити у ВЕБ пројектима.
Па зашто многи мисле да ће РЕСТ бити једноставнији? Моје лично мишљење је да ова привидна једноставност долази од ОСТАЛО манифестованих. Оне. РЕСТ није протокол већ концепт... РЕСТ нема стандард, постоје неке смернице... РЕСТ није ништа компликованији од ХТТП-а. Привидна слобода и анархија привлаче „слободне уметнике“.
Наравно, РЕСТ није ништа компликованији од ХТТП-а. Али сам ХТТП је добро дизајниран протокол који је доказао своју вредност деценијама. Ако нема дубоког разумевања самог ХТТП-а, онда се РЕСТ не може судити.
Али о РПЦ-у - можете. Довољно је узети његову спецификацију. па ти треба ? Или је још увек незгодно РЕСТ? Ти одлучујеш.
Искрено се надам да нисам губио време.
Извор: ввв.хабр.цом