مون کي پڪ آهي ته هيڊ لائن هڪ صحتمند ردعمل جو سبب بڻيو آهي - ”چڱو، اهو ٻيهر شروع ٿي ويو آهي...“ پر مون کي توهان جي توجه 5-10 منٽن لاءِ پڪڙڻ ڏيو، ۽ مان ڪوشش ڪندس ته توهان جي اميدن کي مايوس نه ڪريان.
مضمون جي جوڙجڪ هن ريت ٿيندي: هڪ اسٽريٽجڪ بيان ورتو ويو آهي ۽ هن اسٽريٽائپ جي ظاهر ٿيڻ جي "فطرت" کي ظاهر ڪيو ويو آهي. مون کي اميد آهي ته هي توهان کي توهان جي منصوبن ۾ ڊيٽا جي تبادلي جي پيراگراف جي چونڊ کي نئين زاويه کان ڏسڻ جي اجازت ڏيندو.
آر پي سي ڇا آهي بابت واضح ٿيڻ لاء، مان معيار تي غور ڪرڻ جي تجويز پيش ڪريان ٿو . REST سان ڪابه وضاحت ناهي. ۽ اهو نه هجڻ گهرجي. هر شي جيڪا توهان کي REST بابت ڄاڻڻ جي ضرورت آهي - اهو ان کان الڳ ناهي .
RPC درخواستون تيز ۽ وڌيڪ ڪارائتيون آھن ڇو ته اھي توھان کي اجازت ڏين ٿيون بيچ درخواستون.
نقطي اهو آهي ته آر پي سي ۾ توهان هڪ درخواست ۾ هڪ ڀيرو ڪيترن ئي طريقن کي ڪال ڪري سگهو ٿا. مثال طور، ھڪڙو صارف ٺاھيو، ھڪڙو اوتار شامل ڪريو ۽، ساڳئي درخواست ۾، کيس رڪنيت حاصل ڪريو ڪجھ عنوانن تي. صرف هڪ عرض، ۽ ڪيترو فائدو!
درحقيقت، جيڪڏهن توهان وٽ صرف هڪ پس منظر نوڊ آهي، اهو هڪ بيچ جي درخواست سان تيز نظر ايندو. ڇو ته ٽي REST درخواستون ڪنيڪشن قائم ڪرڻ لاءِ ھڪڙي نوڊ کان ٽي ڀيرا وڌيڪ وسيلن جي ضرورت پوندي.
نوٽ ڪريو ته REST جي صورت ۾ پهرين درخواست کي لازمي طور تي صارف جي ID واپس ڪرڻ گهرجي ته جيئن ايندڙ درخواستون ڪيون وڃن. جنهن جو مجموعي نتيجي تي پڻ منفي اثر پوي ٿو.
پر اهڙا بنيادي ڍانچا صرف اندرين حل ۽ انٽرپرائز ۾ ملي سگهن ٿا. آخري ريزورٽ جي طور تي، ننڍن WEB منصوبن ۾. پر مڪمل WEB حل، ۽ حتي جن کي HighLoad سڏيو وڃي ٿو، تعمير ڪرڻ جي لائق نه آهن. انهن جي بنيادي ڍانچي کي اعلي دستيابي ۽ لوڊ جي معيار کي پورا ڪرڻ گهرجي. ۽ تصوير بدلجي رهي آهي.
انفراسٽرڪچر سرگرمي چينلز ساڳئي منظر ۾ سائي ۾ نشان لڳل آهن. نوٽ ڪريو ته ڪيئن RPC ھاڻي ڪم ڪندو. درخواست انفراسٹرڪچر کي استعمال ڪري ٿو صرف هڪ ٽنگ تي بيلنسر کان پس منظر تائين. جڏهن ته REST اڃا تائين پهرين درخواست ۾ وڃائي ٿو، اهو سڄو انفراسٽرڪچر استعمال ڪندي گم ٿيل وقت لاءِ ٺاهي ٿو.
اهو ڪافي آهي ته لکت ۾ داخل ٿيڻ لاءِ ٻه درخواستون نه پر افزودگي لاءِ، پر، چئو، پنج يا ڏهه... ۽ ان سوال جو جواب ”هاڻي ڪير کٽي؟“ غير واضح ٿي وڃي ٿو.
مان تجويز ڪريان ٿو ته مسئلي تي اڃا به وسيع نظر وٺو. ڊراگرام ڏيکاري ٿو ته انفراسٽرڪچر چينلز ڪيئن استعمال ڪيا ويا آهن، پر انفراسٽرڪچر چينلن تائين محدود ناهي. هڪ اعلي لوڊ انفراسٽرڪچر جو هڪ اهم حصو ڪيش آهي. اچو ته ھاڻي ڪنھن قسم جي استعمال ڪندڙ جي نموني حاصل ڪريون. بار بار. اچو ته 32 ڀيرا چئو.
ڏسو ته ڪيئن آر پي سي انفراسٽرڪچر بهتر ٿي چڪو آهي تمام گهڻي لوڊ جي مطالبن کي پورو ڪرڻ لاءِ. شيء اها آهي ته REST استعمال ڪري ٿو HTTP پروٽوڪول جي مڪمل طاقت، RPC جي برعڪس. مٿي ڏنل ڊراگرام ۾، هن طاقت کي درخواست جي طريقي سان محسوس ڪيو ويو آهي - GET.
HTTP طريقن، ٻين شين جي وچ ۾، ڪيشنگ حڪمت عمليون آهن. توھان انھن کي ڳولي سگھو ٿا دستاويزن ۾ . RPC لاءِ، POST درخواستون استعمال ڪيون وينديون آھن، جن کي غيرمعمولي نه سمجھيو ويندو آھي، يعني ساڳي پوسٽ جي درخواستن کي بار بار ورجائڻ سان مختلف نتيجا اچي سگھن ٿا (مثال طور، ھر تبصرو موڪلڻ کان پوءِ، ھن تبصري جي ٻي ڪاپي ظاهر ٿيندي) ().
نتيجي طور، RPC مؤثر طور تي انفراسٹرڪچر ڪيچ استعمال ڪرڻ جي قابل ناهي. هي "درآمد" سافٽ ويئر ڪيش جي ضرورت جي ڪري ٿي. ڊراگرام ڏيکاري ٿو Redis هن ڪردار ۾. سافٽ ويئر ڪيش، موڙ ۾، ڊولپر کي ڪوڊ جي اضافي پرت شامل ڪرڻ ۽ فن تعمير ۾ قابل ذڪر تبديلين جي ضرورت آهي.
اچو ته هاڻي ڳڻيون ته ڪيترين درخواستن کي REST ۽ RPC ”جنم ڏنو“ زير غور انفراسٽرڪچر ۾؟
درخواستون
انباڪس
پسمنظر ڏانهن
DBMS ڏانهن
نرم ڪيش ڏانهن (ريڊيس)
TOTAL
REST
1 / 32 *
1
1
0
3 / 35
آر پي سي
32
32
1
31
96
پهرين منصوبي جي مقابلي ۾، فرق شاندار آهي. هاڻي REST جو فائدو واضح ٿئي ٿو. پر مان صلاح ڏيان ٿو ته اتي نه روڪيو. ترقي يافته انفراسٽرڪچر ۾ هڪ سي ڊي اين شامل آهي. گهڻو ڪري اهو پڻ حل ڪري ٿو DDoS ۽ DoS حملن کي منهن ڏيڻ جو مسئلو. اسان حاصل ڪريون ٿا:
هي آهي جتي شيون واقعي خراب ٿي وڃن ٿيون RPC لاءِ. RPC صرف قابل نه آهي ته ڪم لوڊ هڪ CDN ڏانهن ورهائڻ جي. اسان صرف نظام تي ڀروسو ڪري سگهون ٿا حملن کي منهن ڏيڻ لاء.
ڇا اهو هتي ختم ڪرڻ ممڪن آهي؟ ۽ ٻيهر، نه. HTTP طريقن، جيئن مٿي ڄاڻايل آهي، انهن جو پنهنجو "جادو" آهي. ۽ اهو بغير ڪنهن سبب جي ناهي ته GET طريقو وڏي پيماني تي انٽرنيٽ تي استعمال ڪيو ويندو آهي. نوٽ ڪريو ته هي طريقو مواد جي هڪ ٽڪرا تائين رسائي حاصل ڪرڻ جي قابل آهي، شرطن کي سيٽ ڪرڻ جي قابل آهي ته انفراسٽرڪچر عناصر تفسير ڪري سگھن ٿا ان کان اڳ ڪنٽرول توهان جي ڪوڊ ڏانهن منتقل ڪيو وڃي، وغيره. هي سڀ توهان کي اجازت ڏئي ٿو لچڪدار، قابل انتظام انفراسٽرڪچر ٺاهڻ جيڪي درخواستن جي واقعي وڏي وهڪري کي سنڀالي سگهن. پر آر پي سي ۾ اهو طريقو ... نظر انداز ڪيو ويو آهي.
پوءِ اهو افسانو ڇو آهي ته بيچ درخواستون (RPC) تيز آهن ايتريون مسلسل؟ ذاتي طور تي، اهو مون کي لڳي ٿو ته اڪثر منصوبا صرف ترقي جي سطح تي نه پهچندا آهن جتي REST پنهنجي طاقت ڏيکارڻ جي قابل آهي. ان کان سواء، ننڍن منصوبن ۾، هو پنهنجي ڪمزورين کي ڏيکارڻ لاء وڌيڪ راضي آهي.
REST يا RPC جو انتخاب هڪ منصوبي ۾ هڪ فرد جي رضامندي پسند نه آهي. هي اختيار منصوبي جي گهرجن کي پورو ڪرڻ گهرجي. جيڪڏهن هڪ پروجيڪٽ هر شي کي نچوض ڪرڻ جي قابل آهي اهو واقعي REST کان ٻاهر ڪري سگهي ٿو، ۽ ان کي واقعي ان جي ضرورت آهي، پوء REST هڪ بهترين انتخاب هوندو.
پر جيڪڏهن، REST جا سڀ فائدا حاصل ڪرڻ لاءِ، توهان کي ضرورت آهي ڊيوپس جي ماهرن کي ڀرتي ڪرڻ لاءِ پروجيڪٽ لاءِ تيزيءَ سان انفراسٽرڪچر کي اسڪيل ڪرڻ لاءِ، منتظمين کي انفراسٽرڪچر کي منظم ڪرڻ لاءِ، هڪ معمار کي ڊزائين ڪرڻ لاءِ WEB سروس جي سڀني پرتن کي ڊزائين ڪرڻ لاءِ... ۽ پروجيڪٽ ، ساڳئي وقت، هڪ ڏينهن ۾ مارجرين جا ٽي پيڪ وڪرو ڪري ٿو ... مان آر پي سي سان لٺ ويندس، ڇاڪاڻ ته ... هي پروٽوڪول وڌيڪ مفيد آهي. ان کي گهري ڄاڻ جي ضرورت نه هوندي ته ڪيش ۽ انفراسٽرڪچر ڪيئن ڪم ڪندو آهي، پر ڊولپر کي سادي ۽ سمجھڻ واري ڪالن تي ڌيان ڏيندو جنهن جي هن کي ضرورت آهي. ڪاروبار خوش ٿيندو.
آر پي سي درخواستون وڌيڪ قابل اعتماد آهن ڇو ته اهي هڪ ٽرانزيڪشن اندر بيچ درخواستن تي عمل ڪري سگهن ٿيون
RPC جي هي ملڪيت هڪ خاص فائدو آهي، ڇاڪاڻ ته ڊيٽابيس کي مسلسل رکڻ آسان آهي. پر REST سان اهو وڌيڪ ۽ وڌيڪ پيچيده ٿي ويندو آهي. درخواستون مختلف پس منظر نوڊس تائين غير مطابقت سان پهچي سگھن ٿيون.
REST جو هي ”نقصان“ مٿي بيان ڪيل ان جي فائدي جو فلپ پاسو آهي - تمام انفراسٽرڪچر وسيلن کي موثر طريقي سان استعمال ڪرڻ جي صلاحيت. جيڪڏهن انفراسٽرڪچر خراب طرح سان ٺهيل آهي، ۽ ان کان به وڌيڪ، جيڪڏهن منصوبي جو فن تعمير ۽ خاص طور تي ڊيٽابيس خراب ٺهيل آهي، ته اهو واقعي هڪ وڏو درد آهي.
پر ڇا بيچ درخواستون قابل اعتماد آهن جيئن اهي لڳي رهيا آهن؟ اچو ته هڪ ڪيس تي نظر رکون: اسان هڪ صارف ٺاهيو، هن جي پروفائل کي ڪجهه تفصيل سان وڌايو ۽ کيس رجسٽريشن مڪمل ڪرڻ لاء راز سان هڪ ايس ايم ايس موڪليو. اهي. هڪ بيچ جي درخواست ۾ ٽي ڪالون.
اچو ته ڊائريگرام تي نظر وجهون. اهو هڪ زيربنا پيش ڪري ٿو اعلي دستيابي عناصر سان. ايس ايم ايس گيٽ ويز سان گڏ ٻه آزاد مواصلاتي چينل آهن. پر... اسان ڇا ٿا ڏسو؟ جڏهن هڪ ايس ايم ايس موڪلڻ، هڪ غلطي 503 ٿئي ٿي - خدمت عارضي طور تي دستياب ناهي. ڇاڪاڻ ته ايس ايم ايس موڪلڻ هڪ بيچ درخواست ۾ پيڪيج ٿيل آهي، پوء سڄي درخواست کي واپس رول ڪيو وڃي. ڊي بي ايم ايس ۾ ڪارناما منسوخ ڪيا ويا آهن. ڪسٽمر کي هڪ غلطي ملي ٿي.
ايندڙ ڪوشش لاٽري آهي. يا ته درخواست ساڳئي نوڊ کي ٻيهر ماريندو ۽ ٻيهر غلطي واپس آڻيندو، يا توهان خوش قسمت ٿي ويندا ۽ ان تي عمل ڪيو ويندو. پر بنيادي شيء اها آهي ته گهٽ ۾ گهٽ هڪ ڀيرو اسان جي انفراسٽرڪچر اڳ ۾ ئي بيڪار ڪم ڪيو آهي. هڪ لوڊ هو، پر ڪو فائدو نه.
ٺيڪ، اچو ته تصور ڪريون ته اسان پاڻ کي تنگ ڪيو (!) ۽ اختيار ذريعي سوچيو جڏهن درخواست جزوي طور تي ڪاميابي سان مڪمل ٿي سگهي ٿي. ۽ باقي ڪجهه وقت جي وقفي کان پوءِ ٻيهر مڪمل ڪرڻ جي ڪوشش ڪنداسين (ڪهڙو؟ ڇا فرنٽ فيصلو ڪندو؟). پر لاٽري ساڳي رهي. ايس ايم ايس موڪلڻ جي درخواست کي ٻيهر ناڪام ٿيڻ جو 50/50 موقعو آهي.
اتفاق ڪريو، ڪلائنٽ جي پاسي کان، خدمت ايترو قابل اعتماد نه لڳي جيترو اسان چاهيون ٿا... REST بابت ڇا؟
REST ٻيهر HTTP جو جادو استعمال ڪري ٿو، پر هاڻي جوابي ڪوڊ سان. جڏهن هڪ غلطي 503 ايس ايم ايس گيٽ وي تي ٿيندي آهي، پس منظر هن غلطي کي بيلنسر ڏانهن نشر ڪري ٿو. بيلنسر هن غلطي کي حاصل ڪري ٿو ۽ ڪلائنٽ سان ڪنيڪشن کي ٽوڙڻ کان سواء، درخواست موڪلي ٿو ٻئي نوڊ ڏانهن، جيڪو ڪاميابي سان درخواست تي عمل ڪري ٿو. اهي. ڪلائنٽ متوقع نتيجو حاصل ڪري ٿو، ۽ انفراسٹرڪچر ان جي اعلي عنوان جي تصديق ڪري ٿو "انتهائي رسائي لائق". استعمال ڪندڙ خوش آهي.
۽ ٻيهر اهو سڀ ڪجهه ناهي. بيلنسر صرف 503 جو جوابي ڪوڊ حاصل نه ڪيو. جواب ڏيڻ وقت، معيار جي مطابق، اهو مشورو ڏنو ويو آهي ته هي ڪوڊ "ٻيهر ڪوشش کان پوء" هيڊر سان مهيا ڪيو وڃي. هيڊر بيلنس کي واضح ڪري ٿو ته اهو هن رستي تي هن نوڊ کي هڪ مخصوص وقت تائين پريشان ڪرڻ جي قابل ناهي. ۽ ايس ايم ايس موڪلڻ لاء ايندڙ درخواستون سڌو سنئون هڪ نوڊ ڏانهن موڪليا ويندا جنهن کي ايس ايم ايس گيٽ وي سان ڪو مسئلو ناهي.
جئين اسان ڏسي سگهون ٿا، JSON-RPC جي اعتبار کي ختم ڪيو ويو آهي. درحقيقت، ڊيٽابيس ۾ تسلسل کي منظم ڪرڻ آسان آهي. پر قرباني، هن معاملي ۾، سڄي نظام جي reliability ٿيندو.
نتيجو گهڻو ڪري اڳئين هڪ سان ملندڙ جلندڙ آهي. جڏهن انفراسٽرڪچر سادو آهي، JSON-RPC جو واضع ضرور هڪ پلس آهي. جيڪڏهن منصوبي ۾ اعلي لوڊ سان اعلي دستيابي شامل آهي، REST هڪ وڌيڪ صحيح نظر اچي ٿو، جيتوڻيڪ وڌيڪ پيچيده، حل.
داخلا جي حد REST تائين گھٽ آھي
مان سمجهان ٿو ته مٿين تجزيي، RPC بابت قائم ڪيل اسٽريٽائپائپ کي رد ڪندي، واضح طور تي ظاهر ڪيو ته REST ۾ داخلا جي حد بلاشبہ RPC کان وڌيڪ آهي. اهو هڪ گهري سمجهڻ جي ضرورت آهي ته HTTP ڪيئن ڪم ڪري ٿو، انهي سان گڏ موجوده انفراسٽرڪچر عناصر جي باري ۾ ڪافي ڄاڻ حاصل ڪرڻ جي ضرورت آهي جيڪا WEB منصوبن ۾ استعمال ٿي سگهي ٿي.
پوءِ ڇو گھڻا ماڻھو سوچين ٿا ته آرام آسان ٿيندو؟ منهنجي ذاتي راءِ اها آهي ته اها ظاهري سادگي باقي مان ظاهر ٿئي ٿي. اهي. REST هڪ پروٽوڪول نه آهي پر هڪ تصور آهي... REST جو ڪو معيار ناهي، ڪجهه هدايتون آهن... REST HTTP کان وڌيڪ پيچيده ناهي. ظاهري آزادي ۽ انتشار ”آزاد فنڪارن“ کي متوجه ڪن ٿا.
يقينا، REST HTTP کان وڌيڪ پيچيده ناهي. پر HTTP پاڻ هڪ چڱي طرح ٺهيل پروٽوڪول آهي جيڪو ثابت ڪيو آهي ته ان جي قيمت ڏهاڪن کان مٿي آهي. جيڪڏهن HTTP جي پاڻ ۾ ڪا گهڻي ڄاڻ نه آهي، ته پوء REST فيصلو نه ٿو ڪري سگهجي.
پر RPC بابت - توھان ڪري سگھو ٿا. ان جي specification وٺڻ لاء ڪافي آهي. تنهنڪري توهان کي ضرورت آهي ؟ يا اهو اڃا تائين مشڪل REST آهي؟ تون فيصلو ڪر.
مون کي خلوص سان اميد آهي ته مون توهان جو وقت ضايع نه ڪيو آهي.
جو ذريعو: www.habr.com