زه ډاډه یم چې سرلیک د صحي عکس العمل لامل شوی - "ښه ، دا بیا پیل شو ..." مګر اجازه راکړئ ستاسو پام د 5-10 دقیقو لپاره راجلب کړم ، او زه به هڅه وکړم چې ستاسو هیلې مایوسه نه کړم.
د مقالې جوړښت به په لاندې ډول وي: یو سټیریوټایپیک بیان اخیستل کیږي او د دې سټیریوټایپ رامینځته کیدو "طبیعت" څرګندیږي. زه امید لرم چې دا به تاسو ته اجازه درکړي چې ستاسو په پروژو کې د نوي زاویې څخه د ډیټا تبادلې تمثیل انتخاب وګورئ.
د دې لپاره چې روښانه شي چې RPC څه شی دی، زه وړاندیز کوم چې معیار په پام کې ونیسم . د REST سره هیڅ وضاحت شتون نلري. او دا باید نه وي. هرڅه چې تاسو اړتیا لرئ د REST په اړه پوه شئ - دا د توپیر وړ ندي .
د RPC غوښتنې ګړندۍ او ډیرې موثرې دي ځکه چې دوی تاسو ته اجازه درکوي د بست غوښتنې وکړي.
نقطه دا ده چې په RPC کې تاسو کولی شئ په یوه غوښتنه کې په یوځل کې ډیری پروسیجرونو ته زنګ ووهئ. د مثال په توګه، یو کارن جوړ کړئ، هغه ته یو اوتار اضافه کړئ او په ورته غوښتنه کې، هغه په ځینو موضوعاتو کې ګډون وکړئ. یوازې یوه غوښتنه، او څومره ګټه!
په حقیقت کې، که تاسو یوازې یو پس منظر نوډ ولرئ، دا به د بیچ غوښتنې سره ګړندی ښکاري. ځکه چې درې REST غوښتنې به د اړیکو رامینځته کولو لپاره له یو نوډ څخه درې چنده ډیرو سرچینو ته اړتیا ولري.
په یاد ولرئ چې د REST په قضیه کې لومړۍ غوښتنه باید د کارونکي ID بیرته راستانه کړي ترڅو د راتلونکو غوښتنو لپاره ترسره شي. کوم چې په ټولیزه توګه په پایله کې منفي اغیزه کوي.
مګر دا ډول زیربناوې یوازې په کور دننه حلونو او شرکتونو کې موندل کیدی شي. د وروستي ریزورټ په توګه، په کوچنیو ویب پروژو کې. مګر د ویب بشپړ حل حلونه، او حتی هغه چې د HighLoad په نوم یادیږي، د جوړولو وړ ندي. د دوی زیربنا باید د لوړ شتون او بار کولو معیارونه پوره کړي. او انځور بدلیږي.
د ورته سناریو لاندې د زیربنا فعالیتونو چینلونه په شنه نښه شوي. پام وکړئ چې RPC اوس څنګه چلند کوي. غوښتنه د بیلانسر څخه شاته پای ته یوازې په یوه پښه کې زیربنا کاروي. پداسې حال کې چې REST لاهم په لومړۍ غوښتنه کې له لاسه ورکوي، دا د ټول زیربنا په کارولو سره د ورک شوي وخت لپاره جوړوي.
دا بسیا ده چې په سکریپټ کې د بډایه کولو لپاره دوه غوښتنې نه وي، مګر، ووایاست، پنځه یا لس ... او د پوښتنې ځواب "اوس څوک ګټي؟" ناڅرګنده شي
زه وړاندیز کوم چې ستونزې ته حتی پراخه کتنه وکړم. ډیاګرام ښیي چې د زیربناوو چینلونه څنګه کارول کیږي، مګر زیربنا یوازې په چینلونو پورې محدوده نه ده. د لوړ بار زیربنا یوه مهمه برخه کیچونه دي. راځئ چې اوس یو ډول کاروونکي آثار ترلاسه کړو. په مکرر ډول. راځئ چې 32 ځله ووایو.
وګورئ چې څنګه د RPC زیربنا د لوړ بار غوښتنې پوره کولو لپاره د پام وړ وده کړې. خبره دا ده چې REST د RPC برعکس د HTTP پروتوکول بشپړ ځواک کاروي. په پورتني انځور کې، دا ځواک د غوښتنې میتود له لارې احساس شوی - GET.
د HTTP میتودونه، د نورو شیانو په منځ کې، د کیچ کولو ستراتیژۍ لري. تاسو کولی شئ دوی په اسنادو کې ومومئ . د RPC لپاره، د POST غوښتنې کارول کیږي، کوم چې د پام وړ نه ګڼل کیږي، دا د ورته POST غوښتنو تکرار ممکن مختلف پایلې بیرته راولي (د مثال په توګه، د هرې تبصرې لیږلو وروسته، د دې تبصرې بله کاپي به ښکاره شي)).
په پایله کې، RPC نشي کولی په اغیزمنه توګه د زیربناوو کیچونه وکاروي. دا د سافټویر کیچونو "واردولو" اړتیا ته لاره هواروي. ډیاګرام په دې رول کې ریډیس ښیې. د سافټویر کیچ، په بدل کې، پراختیا کونکي ته اړتیا لري چې د کوډ اضافي پرت او په جوړښت کې د پام وړ بدلونونه اضافه کړي.
راځئ چې اوس حساب وکړو چې څومره غوښتنې REST او RPC په زیربنا کې "زیږید" ته ورکړي؟
غوښتنې
ان باکس
شاته ته
DBMS ته
نرم زیرمې ته (ریډیس)
TOTAL
پاتې
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 د ټولو ګټو ترلاسه کولو لپاره، تاسو اړتیا لرئ د پروژې لپاره د ډوپس متخصصین وګمارئ ترڅو زیربنا ژر تر ژره پیمانه کړي، د زیربنا اداره کولو لپاره مدیران، د ویب خدماتو ټولې پرتونه ډیزاین کولو لپاره یو معمار ... او پروژه په ورته وخت کې، په ورځ کې د مارجرین درې کڅوړې پلوري ... زه به د RPC سره ودریږم، ځکه چې ... دا پروتوکول ډیر ګټور دی. دا به ژورې پوهې ته اړتیا ونلري چې څنګه زیربناوې او زیربنا کار کوي ، مګر پراختیا کونکي به په ساده او د پوهیدو وړ تلیفونونو باندې تمرکز وکړي چې هغه ورته اړتیا لري. سوداګرۍ به خوشحاله وي.
د RPC غوښتنې خورا باوري دي ځکه چې دوی کولی شي د یوې معاملې دننه د بیچ غوښتنې پلي کړي
د RPC دا ملکیت یو مشخص ګټه ده، ځکه د ډیټابیس دوامداره ساتل اسانه دي. مګر د REST سره دا ډیر او پیچلي کیږي. غوښتنې ممکن په متناسب ډول مختلف پس منظر نوډونو ته راشي.
د REST دا "نقصان" د هغې ګټې فلیپ اړخ دی چې پورته تشریح شوي - د ټولو زیربنایی سرچینو په اغیزمنه توګه کارولو وړتیا. که زیربنا په خرابه توګه ډیزاین شوې وي، او حتی نور هم که چیرې د پروژې جوړښت او په ځانګړې توګه ډیټابیس خراب ډیزاین شوی وي، نو دا واقعیا یو لوی درد دی.
مګر ایا د بیچ غوښتنې دومره معتبر دي لکه څنګه چې دوی ښکاري؟ راځئ چې یوه قضیه وګورو: موږ یو کارونکی رامینځته کوو ، د هغه پروفایل د یو څه توضیحاتو سره بډایه کوو او هغه ته د راجسټریشن بشپړولو لپاره د راز سره یو ایس ایم ایس واستوو. هغوی. په یوه بسته کې درې غوښتنې.
راځئ چې انځور ته وګورو. دا د لوړ شتون عناصرو سره زیربنا وړاندې کوي. د SMS دروازې سره دوه خپلواک مخابراتي چینلونه شتون لري. مګر ... موږ څه وینو؟ کله چې د ایس ایم ایس لیږل کیږي، یوه تېروتنه 503 واقع کیږي - خدمت په لنډمهاله توګه شتون نلري. ځکه د ایس ایم ایس لیږل په یوه بسته غوښتنه کې بسته شوي، بیا ټوله غوښتنه باید بیرته وګرځول شي. په DBMS کې عملونه لغوه شوي. پیرودونکي یوه تېروتنه ترلاسه کوي.
بله هڅه لاټری ده. یا به غوښتنه بیا ورته نوډ وهي او بیا به یوه تېروتنه راوباسي، یا تاسو به خوشحاله اوسئ او دا به اجرا شي. مګر اصلي خبره دا ده چې لږترلږه یو ځل زموږ زیربنا لا دمخه بې کاره کار کړی دی. بار وو، خو ګټه یې نه درلوده.
ښه، راځئ چې تصور وکړو چې موږ خپل ځان فشار راوړو (!) او د اختیار له لارې فکر کوو کله چې غوښتنه په بریالیتوب سره بشپړه شي. او موږ به هڅه وکړو چې د یو څه وقفې وروسته پاتې برخه بیا بشپړه کړو (کوم یو؟ ایا مخکینۍ پریکړه کوي؟). خو لاټري همداسې پاتې شوه. د SMS لیږلو غوښتنه د بیا ناکامیدو 50/50 چانس لري.
موافق یاست، د پیرودونکي اړخ څخه، خدمت هغومره د باور وړ نه ښکاري لکه څنګه چې موږ یې غواړو ... د REST په اړه څه؟
REST بیا د HTTP جادو کاروي، مګر اوس د ځواب کوډونو سره. کله چې د ایس ایم ایس ګیټ وے کې 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