Ishonchim komilki, sarlavha sog'lom reaktsiyaga sabab bo'ldi - "yaxshi, u yana boshlandi ..." Ammo 5-10 daqiqa davomida sizning e'tiboringizni jalb qilishga ruxsat bering va men umidlaringizni puchga chiqarmaslikka harakat qilaman.
Maqolaning tuzilishi quyidagicha bo'ladi: stereotipik bayonot olinadi va bu stereotipning paydo bo'lishining "tabiati" ochib beriladi. Umid qilamanki, bu sizning loyihalaringizda ma'lumotlar almashinuvi paradigmasini tanlashga yangi nuqtai nazardan qarash imkonini beradi.
RPC nima ekanligini aniq bilish uchun men standartni ko'rib chiqishni taklif qilaman . REST bilan aniqlik yo'q. Va bunday bo'lmasligi kerak. REST haqida bilishingiz kerak bo'lgan hamma narsa - uni ajratib bo'lmaydi .
RPC so'rovlari tezroq va samaraliroq, chunki ular sizga ommaviy so'rovlarni amalga oshirishga imkon beradi.
Gap shundaki, RPCda bir so'rovda bir vaqtning o'zida bir nechta protseduralarni chaqirish mumkin. Masalan, foydalanuvchi yarating, unga avatar qo'shing va xuddi shu so'rovda unga ba'zi mavzularga obuna bo'ling. Faqat bitta iltimos va qancha foyda!
Haqiqatan ham, agar sizda faqat bitta backend tuguningiz bo'lsa, u ommaviy so'rov bilan tezroq ko'rinadi. Chunki uchta REST so'rovi ulanishlarni o'rnatish uchun bitta tugundan uch baravar ko'proq resurslarni talab qiladi.
E'tibor bering, REST holatida birinchi so'rov keyingi so'rovlarni amalga oshirish uchun foydalanuvchi identifikatorini qaytarishi kerak. Bu ham umumiy natijaga salbiy ta'sir qiladi.
Ammo bunday infratuzilmalarni faqat ichki echimlar va Korxonada topish mumkin. Oxirgi chora sifatida, kichik WEB loyihalarida. Ammo to'liq huquqli WEB yechimlari va hatto HighLoad deb ataladiganlar ham qurishga arzimaydi. Ularning infratuzilmasi yuqori mavjudlik va yuklanish mezonlariga javob berishi kerak. Va rasm o'zgarmoqda.
Xuddi shu stsenariy bo'yicha infratuzilma faoliyati kanallari yashil rang bilan belgilangan. RPC hozir qanday harakat qilishiga e'tibor bering. So'rov infratuzilmani balanslashtirgichdan backendgacha faqat bitta oyoqda ishlatadi. REST birinchi so'rovda hali ham yo'qotsa-da, u butun infratuzilmadan foydalangan holda yo'qotilgan vaqtni qoplaydi.
Ssenariyga boyitish uchun ikkita soβrov emas, aytaylik, besh yoki oβn... va βendi kim yutadi?β degan savolga javobni kiritish kifoya. noaniq bo'lib qoladi.
Men muammoni yanada kengroq ko'rib chiqishni taklif qilaman. Diagrammada infratuzilma kanallaridan qanday foydalanilishi ko'rsatilgan, ammo infratuzilma faqat kanallar bilan cheklanmaydi. Yuqori yuklangan infratuzilmaning muhim komponenti keshlardir. Keling, qandaydir foydalanuvchi artefaktini olaylik. Qayta-qayta. 32 marta aytaylik.
Yuqori yuk talablarini qondirish uchun RPC infratuzilmasi qanday yaxshilanganiga qarang. Gap shundaki, REST RPC dan farqli o'laroq HTTP protokolining to'liq quvvatidan foydalanadi. Yuqoridagi diagrammada bu quvvat so'rov usuli - GET orqali amalga oshiriladi.
HTTP usullari, boshqa narsalar qatorida, keshlash strategiyalariga ega. Siz ularni quyidagi hujjatlarda topishingiz mumkin . RPC uchun idempotent deb hisoblanmaydigan POST so'rovlari qo'llaniladi, ya'ni bir xil POST so'rovlarining takroriy takrorlanishi turli natijalarni berishi mumkin (masalan, har bir sharh yuborilgandan so'ng, ushbu sharhning boshqa nusxasi paydo bo'ladi) ().
Binobarin, RPC infratuzilma keshlaridan samarali foydalana olmaydi. Bu dasturiy keshlarni "import qilish" zarurligiga olib keladi. Diagrammada Redis ushbu rolda ko'rsatilgan. Dastur keshi, o'z navbatida, ishlab chiquvchidan qo'shimcha kod qatlamini va arxitekturadagi sezilarli o'zgarishlarni qo'shishni talab qiladi.
Keling, ko'rib chiqilayotgan infratuzilmada REST va RPC qancha so'rov "tug'ilgan"ligini hisoblaylik?
so'rovlar
Qabul qiling
backend uchun
DBMSga
yumshoq keshga (Redis)
JAMI
REST
1/32 *
1
1
0
3 / 35
CPR
32
32
1
31
96
Birinchi sxema bilan solishtirganda, farq ajoyib. Endi RESTning foydasi aniq bo'ladi. Ammo men u erda to'xtamaslikni maslahat beraman. Rivojlangan infratuzilma CDNni o'z ichiga oladi. Ko'pincha u DDoS va DoS hujumlariga qarshi kurashish masalasini ham hal qiladi. Biz olamiz:
Bu erda ishlar RPC uchun juda yomonlashadi. RPC ish yukini CDN ga topshirishga qodir emas. Biz hujumlarga qarshi turish uchun faqat tizimlarga tayanishimiz mumkin.
Bu erda tugash mumkinmi? Va yana, yo'q. HTTP usullari, yuqorida aytib o'tilganidek, o'z "sehriga" ega. GET usuli internetda keng qo'llanilishi ham bejiz emas. E'tibor bering, ushbu usul kontentning bir qismiga kirishga qodir, infratuzilma elementlari sizning kodingizga boshqaruvni o'tkazishdan oldin sharhlashi mumkin bo'lgan shartlarni o'rnatishga qodir va hokazo. Bularning barchasi haqiqatan ham katta so'rovlar oqimini bajara oladigan moslashuvchan, boshqariladigan infratuzilmalarni yaratishga imkon beradi. Ammo RPCda bu usul e'tiborga olinmaydi.
Xo'sh, nega ommaviy so'rovlar (RPC) tezroq bo'lishi haqidagi afsona shunchalik barqaror? Shaxsan menimcha, aksariyat loyihalar REST o'z kuchini ko'rsatishga qodir bo'lgan rivojlanish darajasiga etib bormaydi. Bundan tashqari, kichik loyihalarda u o'zining zaif tomonlarini ko'rsatishga tayyor.
REST yoki RPC ni tanlash loyihadagi shaxsning ixtiyoriy tanlovi emas. Ushbu tanlov loyiha talablariga javob berishi kerak. Agar loyiha haqiqatan ham REST-dan hamma narsani siqib chiqara olsa va unga haqiqatan ham kerak bo'lsa, REST ajoyib tanlov bo'ladi.
Ammo, agar RESTning barcha afzalliklaridan foydalanish uchun siz infratuzilmani tezda kengaytirish uchun loyiha uchun devops mutaxassislarini, infratuzilmani boshqarish uchun ma'murlarni, WEB xizmatining barcha qatlamlarini loyihalash uchun arxitektorni... va loyihani yollashingiz kerak bo'lsa. , shu bilan birga, kuniga uch paket margarin sotadi ... Men RPC bilan yopishib olgan bo'lardim, chunki ... bu protokol ko'proq foyda keltiradi. Bu keshlar va infratuzilma qanday ishlashini chuqur bilishni talab qilmaydi, balki ishlab chiquvchini oddiy va tushunarli qo'ng'iroqlarga kerakli protseduralarga qaratadi. Biznes baxtli bo'ladi.
RPC so'rovlari yanada ishonchli, chunki ular bitta tranzaksiya doirasida ommaviy so'rovlarni bajarishi mumkin
RPC ning bu xususiyati aniq afzallik, chunki Ma'lumotlar bazasini izchil saqlash oson. Ammo REST bilan u yanada murakkablashadi. So'rovlar turli backend tugunlariga mos kelmasligi mumkin.
REST ning ushbu "kamchiligi" yuqorida tavsiflangan afzalligining ikkinchi tomoni - barcha infratuzilma resurslaridan samarali foydalanish qobiliyati. Agar infratuzilma yomon ishlab chiqilgan bo'lsa va undan ham ko'proq loyihaning arxitekturasi va ayniqsa ma'lumotlar bazasi yomon ishlab chiqilgan bo'lsa, bu haqiqatan ham katta og'riqdir.
Ammo ommaviy so'rovlar ko'rinadigan darajada ishonchlimi? Keling, bir ishni ko'rib chiqaylik: biz foydalanuvchi yaratamiz, uning profilini ba'zi tavsiflar bilan boyitamiz va ro'yxatdan o'tishni yakunlash uchun unga sirli SMS yuboramiz. Bular. bitta to'plam so'rovida uchta qo'ng'iroq.
Keling, diagrammani ko'rib chiqaylik. U yuqori mavjudlik elementlariga ega infratuzilmani taqdim etadi. SMS shlyuzlari bilan ikkita mustaqil aloqa kanali mavjud. Lekin... biz nimani ko'ramiz? SMS yuborishda 503 xatosi paydo bo'ladi - xizmat vaqtincha mavjud emas. Chunki SMS jo'natish ommaviy so'rovda paketlanadi, keyin butun so'rov orqaga qaytarilishi kerak. DBMSdagi harakatlar bekor qilinadi. Mijoz xatolikni oladi.
Keyingi urinish - lotereya. Yoki so'rov bir xil tugunga qayta-qayta uriladi va xatolik qaytaradi yoki sizga omad kulib boqadi va u bajariladi. Ammo asosiysi, hech bo'lmaganda bir marta infratuzilmamiz behuda ishlagan. Yuk bor edi, lekin foyda yo'q edi.
Tasavvur qilaylik, biz o'zimizni tirishdik (!) va so'rov qisman muvaffaqiyatli bajarilishi mumkin bo'lgan variantni o'ylab ko'rdik. Qolganini esa ma'lum vaqt oralig'idan so'ng yana yakunlashga harakat qilamiz (Qaysi biri? Front qaror qiladimi?). Ammo lotereya avvalgidek qoldi. SMS yuborish so'rovi 50/50 qayta muvaffaqiyatsizlikka uchrashi mumkin.
Qabul qiling, mijoz tomonidan xizmat biz xohlagan darajada ishonchli ko'rinmaydi... REST haqida nima deyish mumkin?
REST HTTP sehridan yana foydalanadi, lekin hozir javob kodlari bilan. SMS shlyuzida 503 xatosi yuzaga kelganda, backend bu xatoni balanserga uzatadi. Balanslashtiruvchi ushbu xatoni oladi va mijoz bilan aloqani uzmasdan, so'rovni muvaffaqiyatli qayta ishlaydigan boshqa tugunga yuboradi. Bular. mijoz kutilgan natijani oladi va infratuzilma o'zining "juda qulay" unvonini tasdiqlaydi. Foydalanuvchi xursand.
Va yana hammasi emas. Balanslashtiruvchi shunchaki 503 javob kodini olmagan. Standartga muvofiq javob berishda ushbu kodni βQayta urinib ko'rishβ sarlavhasi bilan ta'minlash tavsiya etiladi. Sarlavha balanserga ma'lum vaqt davomida ushbu marshrutdagi ushbu tugunni bezovta qilishga arzimasligini aniq ko'rsatadi. Va SMS yuborish bo'yicha keyingi so'rovlar to'g'ridan-to'g'ri SMS shlyuzi bilan bog'liq muammolar bo'lmagan tugunga yuboriladi.
Ko'rib turganimizdek, JSON-RPC ishonchliligi haddan tashqari oshirilgan. Darhaqiqat, ma'lumotlar bazasida izchillikni tashkil qilish osonroq. Ammo qurbonlik, bu holda, butun tizimning ishonchliligi bo'ladi.
Xulosa asosan oldingisiga o'xshaydi. Infratuzilma oddiy bo'lsa, JSON-RPC ning ravshanligi shubhasiz ortiqcha. Agar loyiha yuqori yuk bilan yuqori mavjudlikni nazarda tutsa, REST yanada to'g'ri, ammo murakkabroq echimga o'xshaydi.
RESTga kirish chegarasi pastroq
O'ylaymanki, yuqoridagi tahlil, RPC haqidagi o'rnatilgan stereotiplarni yo'q qilib, REST-ga kirish chegarasi, shubhasiz, RPC-ga qaraganda yuqori ekanligini aniq ko'rsatdi. Bu HTTP ning qanday ishlashini chuqur tushunish zarurati, shuningdek, WEB loyihalarida ishlatilishi mumkin bo'lgan va ishlatilishi kerak bo'lgan mavjud infratuzilma elementlari haqida etarli bilimga ega bo'lish zarurati bilan bog'liq.
Xo'sh, nega ko'p odamlar REST osonroq bo'ladi deb o'ylashadi? Mening shaxsiy fikrim shundaki, bu ko'rinadigan soddalik REST o'zini namoyon qiladi. Bular. REST bu protokol emas, balki tushunchadir... REST standartga ega emas, ba'zi ko'rsatmalar mavjud... REST HTTP dan murakkabroq emas. Ko'rinib turgan erkinlik va anarxiya "erkin rassomlarni" o'ziga tortadi.
Albatta, REST HTTP dan murakkabroq emas. Ammo HTTP-ning o'zi o'nlab yillar davomida o'z qiymatini isbotlagan yaxshi ishlab chiqilgan protokoldir. Agar HTTP-ning o'zi haqida chuqur tushuncha bo'lmasa, RESTni hukm qilib bo'lmaydi.
Ammo RPC haqida - mumkin. Uning spetsifikatsiyasini olish kifoya. Xo'sh, sizga kerak ? Yoki bu hali ham qiyin RESTmi? Sen Qaror qabul qil.
Vaqtingizni behuda o'tkazmadim deb chin dildan umid qilaman.
Manba: www.habr.com