Гарчиг нь эрүүл хариу үйлдэл үзүүлсэн гэдэгт би итгэлтэй байна - "за, энэ дахин эхэлсэн ..." Гэхдээ би таны анхаарлыг 5-10 минутын турш татахыг зөвшөөрч, хүлээлтийг хуурахгүй байхыг хичээх болно.
Өгүүллийн бүтэц нь дараах байдалтай байна: хэвшмэл ойлголтыг авч, энэ хэвшмэл ойлголт үүсэх "мөн чанарыг" илчилсэн болно. Энэ нь таны төслүүдийн өгөгдөл солилцооны парадигмын сонголтыг шинэ өнцгөөс харах боломжийг танд олгоно гэж найдаж байна.
RPC гэж юу болохыг тодорхой болгохын тулд би стандартыг авч үзэхийг санал болгож байна . REST-ийн талаар тодорхой зүйл алга. Тэгээд тийм байх ёсгүй. REST-ийн талаар юу мэдэх хэрэгтэй вэ гэвэл энэ нь үүнийг ялгах боломжгүй юм .
RPC хүсэлтүүд нь багц хүсэлт гаргах боломжийг олгодог тул илүү хурдан бөгөөд үр дүнтэй байдаг.
Хамгийн гол нь RPC-д нэг хүсэлтээр хэд хэдэн процедурыг нэгэн зэрэг дуудах боломжтой юм. Жишээлбэл, хэрэглэгч үүсгэж, түүнд аватар нэмж, ижил хүсэлтийн зарим сэдвүүдэд бүртгүүлээрэй. Зөвхөн нэг хүсэлт, хичнээн их ашиг тустай вэ!
Үнэн хэрэгтээ, хэрэв танд зөвхөн нэг арын зангилаа байгаа бол багц хүсэлтээр энэ нь илүү хурдан мэт санагдах болно. Учир нь гурван REST хүсэлт нь холболт үүсгэхийн тулд нэг зангилаанаас гурав дахин их нөөц шаардах болно.
REST тохиолдолд эхний хүсэлт нь дараагийн хүсэлт гаргахын тулд хэрэглэгчийн ID-г буцаах ёстой гэдгийг анхаарна уу. Энэ нь ерөнхий үр дүнд сөргөөр нөлөөлдөг.
Гэхдээ ийм дэд бүтцийг дотоод шийдэл, аж ахуйн нэгжээс олж болно. Хамгийн сүүлчийн арга бол жижиг 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
CPR
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 дээр зогсох болно, tk. Энэ протокол нь илүү ашигтай байдаг. Энэ нь кэш болон дэд бүтцийн талаар гүн гүнзгий мэдлэг шаарддаггүй, харин хөгжүүлэгчийг энгийн бөгөөд ойлгомжтой дуудлагад шаардлагатай журмын дагуу төвлөрүүлэх болно. Бизнес аз жаргалтай байх болно.
RPC хүсэлт нь нэг гүйлгээний дотор багц хүсэлтийг гүйцэтгэх боломжтой тул илүү найдвартай байдаг
RPC-ийн энэ өмч нь тодорхой давуу тал юм, учир нь мэдээллийн санг тогтвортой байдалд байлгахад хялбар байдаг. Гэхдээ REST-ийн тусламжтайгаар энэ нь улам хэцүү болж байна. Хүсэлтүүд өөр өөр арын зангилаанд нийцэхгүй байж болно.
REST-ийн энэхүү "алдаа" нь дээр дурдсан давуу талуудын урвуу тал нь дэд бүтцийн бүх нөөцийг үр ашигтай ашиглах чадвар юм. Хэрэв дэд бүтэц муу дизайнтай, тэр дундаа төслийн архитектур, мэдээллийн сан муу зохиогдсон бол энэ нь үнэхээр том зовлон юм.
Гэхдээ багц хүсэлтүүд нь харагдаж байгаа шигээ найдвартай юу? Нэг тохиолдлыг авч үзье: бид хэрэглэгч үүсгэж, түүний профайлыг тодорхой тайлбараар баяжуулж, бүртгэлийг дуусгахын тулд нууц үг бүхий SMS илгээдэг. Тэдгээр. нэг багц хүсэлтэд гурван дуудлага хийх.
Диаграммыг авч үзье. Энэ нь өндөр хүртээмжтэй элементүүдтэй дэд бүтцийг харуулдаг. SMS гарцтай хоёр бие даасан харилцааны суваг байдаг. Гэхдээ ... бид юу харж байна вэ? SMS илгээх үед алдаа 503 гарч ирдэг - үйлчилгээ түр хугацаанд боломжгүй байна. Учир нь SMS илгээх нь багц хүсэлтээр багцлагдсан бөгөөд дараа нь хүсэлтийг бүхэлд нь буцаах ёстой. DBMS дахь үйлдлүүд хүчингүй болсон. Үйлчлүүлэгч алдаа хүлээн авдаг.
Дараагийн оролдлого бол сугалаа юм. Хүсэлт дахин нэг зангилаа дээр бууж, дахин алдаа гаргана, эсвэл та азтай байх бөгөөд энэ нь биелэгдэх болно. Гэхдээ хамгийн гол нь манай дэд бүтэц нэг удаа ч гэсэн дэмий ажиллачихсан. Ачаалалтай байсан ч ашиг олоогүй.
За, бид хурцадсан (!) гэж төсөөлж, хүсэлтийг хэсэгчлэн амжилттай хэрэгжүүлэх хувилбарын талаар бодож үзье. Үлдсэнийг нь бид хэсэг хугацааны дараа дахин гүйцэтгэхийг оролдох болно (Юу? Урд талыг шийддэг үү?). Гэвч сугалаа урьдын адил хэвээр үлджээ. 50/50 боломж бүхий SMS илгээх хүсэлт дахин амжилтгүй болно.
Зөвшөөрч байна, үйлчлүүлэгчийн талаас харахад үйлчилгээ бидний хүссэн шиг найдвартай биш юм шиг санагдаж байна ... гэхдээ 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