Баш макала сергек реакцияны пайда кылганына ишенем - "жакшы, кайра башталды..." Бирок мен сиздин көңүлүңүздү 5-10 мүнөткө тартып алайын, мен сиздин үмүтүңүздү актаганга аракет кылам.
Макаланын түзүлүшү төмөнкүдөй болот: стереотиптик билдирүү алынат жана бул стереотиптин пайда болушунун “мүнөзү” ачылат. Бул сиздин долбоорлоруңузда маалымат алмашуунун парадигмасын тандоону жаңы бурчтан кароого мүмкүндүк берет деп үмүттөнөм.
RPC деген эмне экенин так билүү үчүн мен стандартты карап чыгууну сунуштайм . REST менен тактык жок. Анан андай болбошу керек. Сиз REST жөнүндө билишиңиз керек болгон нерселердин баары - аны айырмалоого болбойт .
RPC суроо-талаптары тезирээк жана натыйжалуураак, анткени алар пакеттик суроо-талаптарды жасоого мүмкүндүк берет.
Кеп RPCде бир суроодо бир эле учурда бир нече процедураны чакыра аласыз. Мисалы, колдонуучуну түзүңүз, ага аватар кошуңуз жана ошол эле өтүнүчтө аны айрым темаларга жазылыңыз. Бир эле сураныч, канча пайда!
Чынында эле, эгерде сизде бир гана сервер түйүнү бар болсо, анда ал пакеттик өтүнүч менен тезирээк көрүнөт. Анткени үч REST суроосу байланыштарды орнотуу үчүн бир түйүндөн үч эсе көп ресурстарды талап кылат.
Эскерте кетсек, REST учурундагы биринчи суроо кийинки суроо-талаптар үчүн колдонуучунун ID'син кайтарып бериши керек. Бул да жалпы жыйынтыкка терс таасирин тийгизет.
Бирок мындай инфраструктураларды ички чечимдерден жана Enterpriseден табууга болот. Акыркы чара катары, кичинекей WEB долбоорлорунда. Бирок толук кандуу WEB чечимдери, ал тургай HighLoad деп аталган чечимдерди курууга арзыбайт. Алардын инфраструктурасы жогорку жеткиликтүүлүк жана жүктөө критерийлерине жооп бериши керек. Ал эми сүрөт өзгөрүп жатат.
Ошол эле сценарий боюнча инфраструктуралык активдүүлүк каналдары жашыл түс менен белгиленген. RPC азыр өзүн кандай алып жүргөнүнө көңүл буруңуз. Сурам инфраструктураны баланстоочудан арткы тарапка чейин бир гана бутунда колдонот. REST биринчи суроо-талапта дагы эле жоготот, бирок ал бүт инфраструктураны колдонуу менен жоголгон убакыттын ордун толтурат.
Сценарийге байытуу үчүн эки өтүнүч эмес, айталы, беш-он... жана “эми ким жеңет?” деген суроого жоопту киргизүү жетиштүү. түшүнүксүз болуп калат.
Мен көйгөйгө дагы кененирээк кароону сунуш кылам. Диаграмма инфраструктуралык каналдар кантип колдонуларын көрсөтөт, бирок инфраструктура каналдар менен эле чектелбейт. Жогорку жүктөмдүү инфраструктуранын маанилүү компоненти кэштер болуп саналат. Эми колдонуучунун кандайдыр бир артефактын алалы. Бир нече жолу. 32 жолу айталы.
RPC инфраструктурасы жогорку жүктөө талаптарын канааттандыруу үчүн кандайча жакшырганын көрүңүз. Кептин баары REST RPCден айырмаланып, HTTP протоколунун толук күчүн колдонот. Жогорудагы диаграммада бул күч сурам ыкмасы аркылуу ишке ашырылат - GET.
HTTP ыкмалары, башка нерселер менен катар, кэштөө стратегияларына ээ. Сиз аларды документациядан таба аласыз . RPC үчүн POST сурамдары колдонулат, алар идемпотент болуп эсептелбейт, башкача айтканда, бир эле POST суроо-талаптарын кайталап кайталоо ар кандай натыйжаларды бериши мүмкүн (мисалы, ар бир комментарий жөнөтүлгөндөн кийин, бул комментарийдин башка көчүрмөсү пайда болот) ().
Демек, RPC инфраструктуралык кэштерди эффективдүү колдоно албайт. Бул программалык кэштерди "импорттоо" зарылдыгына алып келет. Диаграмма бул ролдо Редисти көрсөтөт. Жумшак кэш, өз кезегинде, иштеп чыгуучудан коддун кошумча катмарын жана архитектурадагы байкаларлык өзгөрүүлөрдү кошууну талап кылат.
Эми каралып жаткан инфраструктурада REST жана RPC канча суроо-талапты “төрөгөнүн” санап көрөлү?
Суранычтар
Кирүү кутусу
backend үчүн
DBMS үчүн
жумшак кэшке (Redis)
БАРДЫГЫ
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 бул касиети, анткени, белгилүү бир артыкчылыгы болуп саналат Маалымат базасын ырааттуу сактоо оңой. Бирок 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пи? Сиз чечесиз.
Убактыңызды текке кетирген жокмун деп чын жүрөктөн үмүттөнөм.
Source: www.habr.com