JSON-RPC؟ استراحت دشوار را انجام دهید

من مطمئن هستم که تیتر باعث واکنش سالمی شد - "خب، دوباره شروع شد ..." اما اجازه دهید توجه شما را برای 5-10 دقیقه جلب کنم و سعی می کنم انتظارات شما را ناامید نکنم.

ساختار مقاله به این صورت خواهد بود: یک بیان کلیشه ای گرفته شده و "ماهیت" پیدایش این کلیشه آشکار می شود. امیدوارم این به شما این امکان را بدهد که از زاویه جدیدی به انتخاب پارادایم تبادل داده در پروژه های خود نگاه کنید.

برای اینکه واضح باشد RPC چیست، پیشنهاد می کنم استاندارد را در نظر بگیرید JSON-RPC 2.0. با REST هیچ وضوحی وجود ندارد. و نباید باشد. هر آنچه که باید در مورد REST بدانید - از آن قابل تشخیص نیست HTTP.

درخواست‌های RPC سریع‌تر و کارآمدتر هستند، زیرا به شما امکان می‌دهند درخواست‌های دسته‌ای ارسال کنید.

نکته این است که در RPC می توانید چندین رویه را به طور همزمان در یک درخواست فراخوانی کنید. به عنوان مثال، یک کاربر ایجاد کنید، یک آواتار به او اضافه کنید و در همان درخواست، او را در برخی موضوعات مشترک کنید. فقط یک درخواست و چقدر سود!

در واقع، اگر فقط یک گره باطن داشته باشید، با درخواست دسته ای سریعتر به نظر می رسد. زیرا سه درخواست REST به سه برابر منابع بیشتر از یک گره برای ایجاد اتصال نیاز دارند.

توجه داشته باشید که اولین درخواست در مورد REST باید شناسه کاربری را برگرداند تا درخواست های بعدی انجام شود. که بر نتیجه کلی نیز تأثیر منفی می گذارد.

اما چنین زیرساخت هایی را فقط می توان در راه حل های داخلی و Enterprise یافت. به عنوان آخرین راه حل، در پروژه های وب کوچک. اما راه حل های WEB تمام عیار و حتی آنهایی که HighLoad نامیده می شوند ارزش ساختن ندارند. زیرساخت آنها باید معیارهای در دسترس بودن و بار بالا را برآورده کند. و تصویر در حال تغییر است.

کانال‌های فعالیت زیرساخت در سناریو مشابه با رنگ سبز مشخص شده‌اند. به نحوه رفتار RPC در حال حاضر توجه کنید. این درخواست از زیرساخت تنها در یک پا از متعادل کننده تا باطن استفاده می کند. در حالی که REST هنوز در اولین درخواست ضرر می کند، با استفاده از کل زیرساخت زمان از دست رفته را جبران می کند.

کافی است وارد فیلمنامه نه دو درخواست غنی سازی، بلکه مثلاً پنج یا ده ... و پاسخ به این سوال که "حالا چه کسی برنده است؟" نامشخص می شود.

من پیشنهاد می کنم که نگاهی حتی گسترده تر به مشکل بیندازیم. نمودار نحوه استفاده از کانال های زیرساخت را نشان می دهد، اما زیرساخت به کانال ها محدود نمی شود. یکی از اجزای مهم یک زیرساخت با بار بالا، حافظه پنهان است. بیایید اکنون نوعی مصنوع کاربر را دریافت کنیم. مکرر. فرض کنید 32 بار.

ببینید که چگونه زیرساخت RPC به طور قابل توجهی برای پاسخگویی به نیازهای بار بالا بهبود یافته است. مسئله این است که REST برخلاف RPC از تمام قدرت پروتکل HTTP استفاده می کند. در نمودار بالا، این توان از طریق روش درخواست - GET تحقق می یابد.

روش‌های HTTP، در میان چیزهای دیگر، دارای استراتژی‌های کش هستند. شما می توانید آنها را در اسناد در HTTP. برای RPC از درخواست‌های POST استفاده می‌شود که بی‌توان در نظر گرفته نمی‌شوند، یعنی تکرارهای مکرر همان درخواست‌های POST ممکن است نتایج متفاوتی را به همراه داشته باشد (مثلاً پس از ارسال هر نظر، یک کپی دیگر از این نظر ظاهر می‌شود)منبع).

در نتیجه، RPC قادر به استفاده موثر از حافظه پنهان زیرساخت نیست. این منجر به نیاز به "وارد کردن" حافظه پنهان نرم افزار می شود. نمودار Redis را در این نقش نشان می دهد. کش نرم افزار به نوبه خود، توسعه دهنده را ملزم به اضافه کردن یک لایه کد اضافی و تغییرات قابل توجه در معماری می کند.

حال بیایید شمارش کنیم که REST و RPC چه تعداد درخواست را در زیرساخت مورد بررسی «به دنیا آوردند»؟

درخواست ها
صندوق ورودی
به باطن
به DBMS
به حافظه نهان نرم (Redis)
TOTAL

REST
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] در بهترین حالت (در صورت استفاده از کش محلی) 1 درخواست (یک!)، در بدترین حالت 32 درخواست ورودی.

در مقایسه با طرح اول، تفاوت قابل توجه است. اکنون سود REST مشخص می شود. اما من پیشنهاد می کنم در آنجا متوقف نشوید. زیرساخت توسعه یافته شامل CDN است. اغلب مشکل مقابله با حملات DDoS و DoS را نیز حل می کند. ما گرفتیم:

اینجاست که اوضاع برای RPC خیلی بد می شود. RPC به سادگی قادر به تفویض حجم کار به CDN نیست. ما فقط می توانیم برای مقابله با حملات به سیستم ها تکیه کنیم.

مگه میشه اینجا تموم شد؟ و باز هم نه روش های HTTP، همانطور که در بالا ذکر شد، "جادوی" خود را دارند. و بی دلیل نیست که روش GET به طور گسترده در اینترنت استفاده می شود. توجه داشته باشید که این روش قادر به دسترسی به یک قطعه محتوا است، قادر است شرایطی را تنظیم کند که عناصر زیرساخت می توانند قبل از انتقال کنترل به کد شما تفسیر کنند و غیره. همه اینها به شما امکان می‌دهد زیرساخت‌های انعطاف‌پذیر و قابل مدیریتی ایجاد کنید که بتواند جریان‌های واقعاً زیادی از درخواست‌ها را مدیریت کند. اما در RPC این روش ... نادیده گرفته می شود.

پس چرا این افسانه که درخواست‌های دسته‌ای (RPC) سریع‌تر هستند تا این حد پایدار است؟ شخصاً به نظرم می رسد که اکثر پروژه ها به سادگی به سطحی از توسعه نمی رسند که REST بتواند قدرت خود را نشان دهد. علاوه بر این، در پروژه های کوچک، او تمایل بیشتری برای نشان دادن نقاط ضعف خود دارد.

انتخاب REST یا RPC یک انتخاب ارادی یک فرد در یک پروژه نیست. این انتخاب باید الزامات پروژه را برآورده کند. اگر پروژه‌ای بتواند هر چیزی را که واقعاً می‌تواند از REST جمع کند، و واقعاً به آن نیاز دارد، پس REST یک انتخاب عالی خواهد بود.

اما اگر برای به دست آوردن تمام مزایای REST، نیاز به استخدام متخصصان توسعه دهنده برای پروژه برای مقیاس سریع زیرساخت، مدیران برای مدیریت زیرساخت، یک معمار برای طراحی تمام لایه های سرویس وب ... و پروژه دارید. ، همزمان، روزی سه بسته مارگارین می فروشد ... من با RPC می چسبم، زیرا ... این پروتکل بیشتر سودمند است. این نیازی به دانش عمیق در مورد نحوه عملکرد حافظه پنهان و زیرساخت ندارد، اما توسعه دهنده را بر روی فراخوانی های ساده و قابل درک رویه های مورد نیاز خود متمرکز می کند. تجارت خوشحال خواهد شد.

درخواست های RPC قابل اعتمادتر هستند زیرا می توانند درخواست های دسته ای را در یک تراکنش واحد اجرا کنند

این ویژگی RPC یک مزیت قطعی است، زیرا ثابت نگه داشتن پایگاه داده آسان است. اما با REST پیچیده تر و پیچیده تر می شود. ممکن است درخواست ها به طور متناقض به گره های باطن مختلف برسد.

این "مضرات" REST جنبه دیگری از مزیت آن است که در بالا توضیح داده شد - توانایی استفاده بهینه از همه منابع زیرساخت. اگر زیرساخت ضعیف طراحی شده باشد، و حتی بیشتر از آن اگر معماری پروژه و به طور خاص پایگاه داده ضعیف طراحی شده باشد، این واقعاً درد بزرگی است.

اما آیا درخواست های دسته ای آنقدر که به نظر می رسد قابل اعتماد هستند؟ بیایید به یک مورد نگاه کنیم: ما یک کاربر ایجاد می کنیم، نمایه او را با مقداری توضیحات غنی می کنیم و برای تکمیل ثبت نام یک اس ام اس حاوی یک رمز برای او ارسال می کنیم. آن ها سه تماس در یک درخواست دسته ای

بیایید به نمودار نگاه کنیم. این یک زیرساخت با عناصر در دسترس بالا ارائه می دهد. دو کانال ارتباطی مستقل با دروازه های پیامکی وجود دارد. اما... چه می بینیم؟ هنگام ارسال پیامک، خطای 503 رخ می دهد - سرویس به طور موقت در دسترس نیست. زیرا ارسال اس ام اس در یک درخواست دسته ای بسته بندی می شود، سپس کل درخواست باید برگشت داده شود. اقدامات در DBMS لغو شده است. مشتری یک خطا دریافت می کند.

تلاش بعدی قرعه کشی است. یا درخواست مجدداً به همان گره برخورد می کند و دوباره یک خطا برمی گرداند یا خوش شانس خواهید بود و اجرا می شود. اما نکته اصلی این است که حداقل یک بار زیرساخت های ما بیهوده کار کرده است. بار بود، اما سودی نداشت.

خوب، بیایید تصور کنیم که خودمان را تحت فشار قرار داده ایم (!) و به گزینه ای فکر کرده ایم که چه زمانی درخواست می تواند تا حدی با موفقیت تکمیل شود. و سعی می کنیم بعد از مدتی (کدام؟ جلو تصمیم می گیرد؟) بقیه را دوباره تکمیل کنیم. اما قرعه کشی ثابت ماند. درخواست ارسال پیامک 50/50 احتمال عدم موفقیت مجدد دارد.

موافقم، از طرف مشتری، سرویس آنطور که ما می خواهیم قابل اعتماد به نظر نمی رسد... در مورد REST چطور؟

REST دوباره از جادوی HTTP استفاده می کند، اما اکنون با کدهای پاسخ. هنگامی که خطای 503 در دروازه SMS رخ می دهد، backend این خطا را برای متعادل کننده پخش می کند. متعادل کننده این خطا را دریافت می کند و بدون قطع ارتباط با مشتری، درخواست را به گره دیگری ارسال می کند که با موفقیت درخواست را پردازش می کند. آن ها مشتری نتیجه مورد انتظار را دریافت می کند و زیرساخت عنوان بالای آن را "بسیار در دسترس" تأیید می کند. کاربر خوشحال است.

و باز هم این تمام نیست. متعادل کننده فقط یک کد پاسخ 503 را دریافت نکرده است. هنگام پاسخگویی، طبق استاندارد، توصیه می شود این کد را با هدر "Retry-After" ارائه کنید. هدر برای متعادل کننده روشن می کند که ارزش ندارد این گره در این مسیر برای مدت زمان مشخصی مزاحم شود. و درخواست های بعدی برای ارسال پیامک مستقیماً به گره ای ارسال می شود که مشکلی با دروازه پیامک ندارد.

همانطور که می بینیم، قابلیت اطمینان JSON-RPC بیش از حد ارزیابی شده است. در واقع، سازماندهی سازگاری در پایگاه داده آسان تر است. اما فداکاری در این مورد، قابلیت اطمینان کل سیستم خواهد بود.

نتیجه گیری تا حد زیادی شبیه به نتیجه قبلی است. وقتی زیرساخت ساده باشد، واضح بودن JSON-RPC قطعاً یک مزیت است. اگر پروژه شامل در دسترس بودن بالا با بار زیاد باشد، REST راه حل صحیح تر، هرچند پیچیده تر به نظر می رسد.

آستانه ورود به REST کمتر است

من فکر می کنم که تجزیه و تحلیل فوق، که کلیشه های ایجاد شده در مورد RPC را از بین می برد، به وضوح نشان داد که آستانه ورود به REST بدون شک بالاتر از RPC است. این به دلیل نیاز به درک عمیق از نحوه عملکرد HTTP و همچنین نیاز به دانش کافی در مورد عناصر زیرساخت موجود است که می توانند و باید در پروژه های وب مورد استفاده قرار گیرند.

پس چرا بسیاری از مردم فکر می کنند که REST ساده تر خواهد بود؟ نظر شخصی من این است که این سادگی ظاهری از REST خود را نشان می دهد. آن ها REST یک پروتکل نیست بلکه یک مفهوم است... REST استانداردی ندارد، دستورالعمل هایی وجود دارد... REST پیچیده تر از HTTP نیست. آزادی و هرج و مرج ظاهری "هنرمندان آزاد" را به خود جذب می کند.

البته REST پیچیده تر از HTTP نیست. اما خود HTTP یک پروتکل خوب طراحی شده است که ارزش خود را در طول چندین دهه ثابت کرده است. اگر درک عمیقی از خود HTTP وجود نداشته باشد، نمی توان REST را قضاوت کرد.

اما در مورد RPC - شما می توانید. کافی است مشخصات آن را بگیرید. پس آیا شما نیاز دارید JSON-RPC احمقانه? یا هنوز REST مشکل است؟ تو تصمیم بگیر.

از صمیم قلب امیدوارم که وقت شما را تلف نکرده باشم.

منبع: www.habr.com