Сигурен съм, че заглавието предизвика здравословна реакция - "е, пак се започна..." Но нека ви привлека вниманието за 5-10 минути и ще се опитам да не разочаровам очакванията ви.
Структурата на статията ще бъде следната: взема се стереотипно твърдение и се разкрива „естеството“ на появата на този стереотип. Надявам се, че това ще ви позволи да погледнете избора на парадигма за обмен на данни във вашите проекти от нов ъгъл.
За да стане ясно какво е RPC, предлагам да разгледаме стандарта . С REST няма яснота. И не трябва да бъде. Всичко, което трябва да знаете за REST - това е неразличимо от .
RPC заявките са по-бързи и по-ефективни, защото ви позволяват да правите пакетни заявки.
Въпросът е, че в RPC можете да извикате няколко процедури наведнъж в една заявка. Например, създайте потребител, добавете аватар към него и в същата заявка го абонирайте за някои теми. Само една молба, а колко много полза!
Наистина, ако имате само един бекенд възел, ще изглежда по-бързо с пакетна заявка. Тъй като три REST заявки ще изискват три пъти повече ресурси от един възел за установяване на връзки.
Обърнете внимание, че първата заявка в случай на REST трябва да върне потребителския идентификатор, за да могат да бъдат направени последващи заявки. Което също се отразява негативно на общия резултат.
Но такива инфраструктури могат да бъдат намерени само във вътрешни решения и Enterprise. В краен случай, в малки WEB проекти. Но пълноценните WEB решения и дори тези, наречени HighLoad, не си струват изграждането. Тяхната инфраструктура трябва да отговаря на критериите за висока достъпност и натоварване. И картината се променя.
Каналите за инфраструктурна дейност при същия сценарий са маркирани в зелено. Забележете как се държи RPC сега. Заявката използва инфраструктурата само на един крак от балансиращия до бекенда. Докато REST все още губи при първата заявка, той компенсира загубеното време, използвайки цялата инфраструктура.
Достатъчно е да въведете в сценария не две заявки за обогатяване, а, да речем, пет или десет ... и отговорът на въпроса "кой печели сега?" става неясно.
Предлагам да погледнем още по-широко на проблема. Диаграмата показва как се използват инфраструктурните канали, но инфраструктурата не се ограничава до канали. Важен компонент на високонатоварена инфраструктура са кешовете. Нека сега вземем някакъв потребителски артефакт. Многократно. Да кажем 32 пъти.
Вижте как RPC инфраструктурата се е подобрила значително, за да отговори на изискванията на високо натоварване. Работата е там, че REST използва пълната мощност на HTTP протокола, за разлика от RPC. В диаграмата по-горе тази власт се реализира чрез метода на заявка - GET.
HTTP методите, наред с други неща, имат стратегии за кеширане. Можете да ги намерите в документацията на . За RPC се използват POST заявки, които не се считат за идемпотентни, т.е. многократните повторения на едни и същи POST заявки могат да върнат различни резултати (например след изпращане на всеки коментар ще се появи друго копие на този коментар) ().
Следователно RPC не е в състояние да използва ефективно кешовете на инфраструктурата. Това води до необходимостта от „импортиране“ на софтуерни кешове. Диаграмата показва Redis в тази роля. Софтуерният кеш от своя страна изисква от разработчика да добави допълнителен слой код и забележими промени в архитектурата.
Нека сега преброим колко заявки са „родили“ REST и RPC в разглежданата инфраструктура?
искания
Входящи
към бекенда
към СУБД
към мек кеш (Redis)
ОБЩО
ПОЧИВКА
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, но вече с кодове за отговор. Когато възникне грешка 503 на SMS шлюза, бекендът излъчва тази грешка към балансиращото устройство. Балансиращият получава тази грешка и без да прекъсва връзката с клиента, изпраща заявката до друг възел, който успешно я обработва. Тези. клиентът получава очаквания резултат, а инфраструктурата потвърждава високата си титла „високо достъпна“. Потребителят е доволен.
И отново това не е всичко. Балансиращият не просто получи код за отговор 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