سلام دوستان! من سعی کردم در این مقاله چکیده ای از مقاله کنفرانسی " Performance Analysis of RESTful API and RabbitMQ for Microservice Web Application" را برای شما قرار دهم.

چکیده:
     هدف اولیه این تحقیق بررسی چگونگی مدیریت برنامه های کاربردی وب میکروسرویس ارتباط بین اجزای خود است.

 **روش**
    - این تحقیق از دو فناوری مختلف RabbitMQ و REST API به عنوان میان افزار پیام گرا برای برنامه های کاربردی وب میکروسرویس استفاده می کند. میان افزار پیام گرا به بخش های مختلف یک برنامه کاربردی توزیع شده کمک می کند تا با ارسال پیام ها یا داده ها ارتباط برقرار کنند.

 **آزمایش**:
    - محققان آزمایشاتی را شامل RabbitMQ و REST API انجام دادند. این آزمایش‌ها تحت شرایط مختلفی انجام شد که احتمالاً شامل تعداد متفاوتی از کاربران می‌شد. هدف این آزمایش ها ارزیابی و مقایسه میزان عملکرد هر روش در موقعیت ها یا سناریوهای مختلف است.

 **هدف **:
    - هدف اولیه این تحقیق ارائه بینش و درک در مورد این دو روش ارتباطی در زمینه برنامه های کاربردی وب میکروسرویس است. این اطلاعات برای کمک به ارائه دهندگان خدمات یا توسعه دهندگان در تصمیم گیری آگاهانه در هنگام انتخاب روش مناسب بر اساس نیازها و شرایط خاص آنها در نظر گرفته شده است.

 **یافته ها**:
    - نتایج تجربی به‌دست‌آمده از تحقیق نشان می‌دهد که وقتی تعداد زیادی از کاربران به طور همزمان درخواست‌هایی را به یک برنامه وب ارسال می‌کنند، استفاده از RabbitMQ به عنوان میان‌افزار پیام‌گرا در مقایسه با روش ارتباطی REST API پایدارتر است. به عبارت دیگر، به نظر می رسد RabbitMQ در سناریوهایی با سطوح بالای فعالیت همزمان کاربر، عملکرد بهتری دارد.

مقدمه:
یکی از استفاده‌های شائبه از این معماری REST، API های RESTful هستند. API یک واسط است که به شما این امکان را می‌دهد که به منابع (مثلاً داده‌ها) به یک شکل بسیار آسان و شفاف دسترسی داشته باشید و پیچیدگی سرویس‌دهی را به حداقل برسانید. بسیاری از میکروسرویس‌ها از API های RESTful برای ارسال پیام‌ها استفاده می‌کنند.
توجه به این نکته که صفحات وب یا نرم‌افزار ممکن است برای تعداد زیادی کاربر که به طور همزمان درخواست‌ها ارسال می‌کنند، خدمت‌دهی کنند، مقاله موجود مورد بررسی قرار می‌دهد و به عنوان جایگزین از پروتکل AMQP استفاده می‌کند. AMQP (Advanced Message Queuing Protocol) یک پروتکل پیام‌رسانی پیشرفته در لایه برنامه‌ای است که خدمات پیام‌رسانی یکپارچه را فراهم می‌کند. این پروتکل اجازه می‌دهد تا ارسال پیام‌ها دقیق‌تر و پایدارتر انجام شود.
وقتی تعداد زیادی کاربر به طور همزمان درخواست می‌فرستند، حتی اگر این درخواست‌ها به موقع پردازش نشوند، پیام‌ها در یک صف پیام ذخیره می‌شوند. سپس درخواست‌ها به تدریج پردازش می‌شوند. در این مقاله، از RabbitMQ بر پایه پروتکل AMQP به عنوان وسیله‌ای برای میان‌افزار پیام‌رسانی استفاده می‌شود تا عملکرد آن با حالت ارتباطی RESTful API مقایسه شود.
در نهایت، یک میکروسرویس ساده پیاده‌سازی و تست می‌شود تا عملکرد حالت‌های ارتباطی RESTful API و AMQP در معماری صفحات وب میکروسرویس تحلیل شود. عملکرد این دو حالت ارتباطی تحت تعداد مختلفی از کاربران ارزیابی می‌شود و عملکرد آنها با افزایش تعداد کاربران تغییر می‌کند.

معماری REST  چیست؟
REST معماری یک سیستم ابررسانه ای توزیع شده است که اولین بار توسط Roy Rleding در مقاله یادداشت شده خود در سال 2000 ارائه شد. انتزاع اطلاعات کلیدی در REST یک مفهوم به نام "منبع" است. هرچیزی که نام دارد، می‌تواند یک منبع باشد: یک سند یا تصویر، یک سرویس موقت، یک مجموعه دیگر از منابع یا یک شیء غیرمجاز (مثلاً یک وظیفه درونی).
API‌های RESTful از این اصول برای ایجاد واسط‌هایی برای ارتباط بین اجزا استفاده می‌کنند. هر منبع در هر لحظه، یک نمایش از آن منبع است. این نمایش شامل داده، اطلاعات توصیفی در مورد داده، و پیوندهای هایپرمدیا است که به کاربر این امکان را می‌دهد که وضعیت منبع را تغییر دهد.
یکی از مزایای اصلی API‌های RESTful این است که انعطاف زیادی را فراهم می‌کنند. داده به منابع یا روش‌ها وابسته نیست، بنابراین این API‌ها می‌توانند انواع مختلفی از تماس‌ها را اداره کنند و فرمت‌های داده‌ای مختلفی را ارائه دهند.اما در مواردی که تعداد زیادی درخواست همزمان ارسال می‌شود، این روش ممکن است به مشکل بخورد. به این مشکل مواجه می‌شویم که تعداد درخواست‌ها به حدی زیاد باشد که سرور نتواند آنها را به موقع پردازش کند. در اینجا به یک میان‌افزار پیام‌رسانی نیاز داریم که می‌تواند با این وضعیت برخورد کند.

پروتکل AMQP  چیست؟
 یک پروتکل پیام‌رسانی پیشرفته است. این پروتکل به عنوان یک استاندارد متن باز در لایه برنامه برای ارائه خدمات میان‌افزار پیام‌مند مورد استفاده قرار می‌گیرد. AMQP به برنامه‌ها این امکان را می‌دهد که پیام‌ها را بفرستند و دریافت کنند. این مانند پیام‌رسانی فوری یا ایمیل عمل می‌کند. اما AMQP در مقایسه با راه‌حل‌های دیگر از نظر تعیین اینکه کدام پیام‌ها باید دریافت شوند و چگونه باید امنیت، قابلیت اطمینان و عملکرد را با هم تعادل برقرار کنند، متفاوت است. سیستم‌هایی که از AMQP استفاده می‌کنند، عملکرد بهتری نسبت به راه‌حل‌های دیگر در مواردی که به صورت بدون نیاز به مداخله انسانی (lights out) عمل می‌کنند، دارند.
چند دلیل وجود دارد که AMQP به عنوان پیشنهادی مناسب در مسابقه انتخاب می‌شود. این دلایل شامل سهولت استفاده، امکان اتصال برنامه‌ها بر روی پلتفرم‌های مختلف، امکان اتصال با شرکاء تجاری با استفاده از استانداردهای باز و موقعیت نوآورانه مبتنی بر AMQP هستند.
همچنین، در سرویس، سه ماژول عملکردی اصلی به یک زنجیره پردازشی متصل می‌شوند تا عملکرد مورد نظر را انجام دهند. پیام‌هایی که توسط برنامه‌ی ارسالی فرستاده می‌شوند، ابتدا توسط "مبادله" دریافت می‌شوند و بر اساس قوانین خاصی به "صف پیام" ارسال می‌شوند. "صف پیام" پیام‌ها را تا زمانی که توسط مصرف‌کننده به صورت کامل پردازش شوند، ذخیره می‌کند. "ارتباط" تعیین کننده ارتباط بین "مبادله" و "صف پیام" است و قوانین مسیردهی را فراهم می‌کند.
به عبارت دیگر، AMQP به برنامه‌نویسان این امکان را می‌دهد تا پیام‌ها را با دقت مدیریت کرده و منابع را به بهترین شکل ممکن به کاربران ارائه دهند.
 

معماری AMQP

معماری AMQP
 به منظور آزمایش API RESTful برای معماری Microservice، یک برنامه وب ساده طراحی شده است که در شکل زیر نشان داده شده است. همه سرویس ها و دروازه های API حاوی API های REST هستند که اقدامات را از قبل تعریف می کنند، بر اساس METHOD و URL دریافتی پیاده سازی می شوند. بنابراین، تا زمانی که این اقدامات از قبل تعریف شده باشند، نیازی به درک اصول داخلی نیست. سرویس ها می توانند برای پردازش درخواست با یکدیگر ارتباط برقرار کنند. دروازه API آدرس تمام سرویس ها را جمع آوری می کند. وظیفه اصلی آن ارسال درخواست ها به سرویس های مربوطه است. هنگامی که دروازه API درخواست را دریافت می کند، ابتدا روش و URL را بررسی می کند و از طریق RESTful API که از قبل تعریف شده است، درخواست را به سرویس مربوطه ارسال می کند. هنگامی که یک کاربر درخواستی را به برنامه وب ارائه می کند، ابتدا دروازه API دریافت می کند درخواست و مشاهده روش و URL. دروازه API این درخواست را از طریق REST API تعریف شده به سرویس مناسب ارسال می کند. هنگامی که سرویس درخواست را دریافت می کند، مجدداً روش و URL را بررسی می کند، درخواست را از طریق REST API تعریف شده پردازش می کند و اقدامی انجام می دهد.

"برنامه وب میکروسرویس با رابط برنامه‌نویسی RESTful"

روش RabbitMQ
روش RabbitMQ به منظور آزمایش صف پیام معماری Microservice، معماری Microservice شکل بالا همانطور که در شکل زیر نشان داده شده است اصلاح شده است. REST API در اینجا استفاده نمی شود و دروازه API لغو می شود. این معماری از RabbitMQ به عنوان ابزار تبادل اطلاعات استفاده می کند و اقداماتی در Event API که طبق پیام دریافتی اجرا می شوند.
همانطور که در شکل زیر نشان داده شده است، RabbitMQ دارای یک ماژول تابع Exchange در داخل است. این ماژول برای مسیریابی انتشار پیام استفاده می شود و پیام را در صف مشخص شده منتشر می کند. Exchange ماژول اصلی RabbitMQ است و دارای چهار نوع است. این چهار نوع تبادل مستقیم، تبادل Fanout، تبادل موضوع و تبادل سرصفحه هستند. از آنجایی که هر نوع سربار CPU متفاوتی دارد. ما نوع مناسب را با توجه به نیازهای مختلف انتخاب می کنیم .در این معماری نیاز است که یک پیام به صف مشخص شده ارسال شود و توسط سرویس مشخص شده دریافت شود، بنابراین از Direct Exchange استفاده می شود. هنگامی که پیامی توسط ماژول Exchange دریافت می شود، بررسی می کند که پیام به کدام صف ارسال شده و پیام را به صف ارسال می کند. ماژول خدماتی که به صف گوش می دهد، اطلاعات موجود در صف را دریافت می کند، پیام را بررسی می کند و رویداد را با توجه به محتوای پیام اجرا می کند. اقدامات از قبل در API تعریف شده اند.

"برنامه وب میکروسرویس با RabbitMQ" به معنای یک برنامه وب میکروسرویس است که از RabbitMQ به عنوان یک سیستم پیام‌رسانی برای تبادل پیام بین اجزای مختلف آن استفاده می‌کند.

به منظور ارزیابی دو معماری فوق، از سخت افزار و ابزارهای زیر برای آزمایش استفاده می کنیم:
مدل کامپیوتری: Intel NUC NUC5I7RYH، پردازنده: Intel Core i7(Fifth)(4Mcache,3.1GHz,2cores, 4threads); حافظه: 16 گیگابایت DDR3L 1600 مگاهرتز؛ دیسک: SSD 256 گیگابایت؛ شبکه: رابط 10 گیگابیت بر ثانیه، پهنای باند 1 گیگابایت؛ سیستم عامل: ubuntu 16.04 (64 بیتی)؛ RabbitMQ: 3.7.3; Apache: 2.4.29 (64 بیتی); ابزار تست عملکرد: apache jmeter 4.0.

آزمایش و نتایج:
در آزمایش‌ها، به منظور مقایسه دو برنامه کاربردی وب Microservice مستقر شده، این مطالعه آزمایش‌های متعددی انجام داده و آنها را به کار می‌گیرد. برای اطمینان از صحت تست، تست ها را تکرار می کنیم و نتایج را به عنوان مقادیر متوسط محاسبه می کنیم. به منظور آزمایش تأثیر عملکرد تعداد کاربران بر روی دو سرویس استقرار، تعداد کاربران را از 50، 100، 150، 200، 250، تا 300 کاربر تغییر می دهیم که درخواست اطلاعات را به طور همزمان به این سرویس ارسال می کنند. نتایج در شکل ارائه شده است

از طریق آزمایش‌ها می‌توان نتیجه گرفت که در حالت RESTful API، زمانی که تعداد کاربران آنلاین کم است، سرعت درخواست پاسخ سریع‌تر از روش RabbitMQ است، اما زمانی که تعداد درخواست‌ها از بار بیشتر شود، عملکرد به تدریج کاهش می‌یابد و خطاها رخ می دهد و حتی سرویس ارائه نمی شود. از آنجایی که تعداد اطلاعات درخواست از بار پردازشی سیستم بیشتر است و نمی تواند به این درخواست ها پاسخ دهد، خطاهایی رخ می دهد. هنگامی که تعداد درخواست ها از حد معینی بیشتر شود، خطا بسیار زیاد است و سیستم نمی تواند به طور معمول سرویس شود. در حالت RabbitMQ، زمانی که تعداد کاربران کم است، سرعت درخواست پاسخ به روش RESTful API خوب نیست، اما افزایش تعداد کاربران آنلاین تأثیر زیادی بر عملکرد ندارد و عملکرد نسبتاً پایدار است. . از آنجایی که همه درخواست‌ها به صف پیام میان‌افزار پیام‌گرا ارسال می‌شوند و ذخیره می‌شوند، می‌توان آن‌ها را در صورت امکان از صف پیام استخراج و پردازش کرد. پردازش می شود، به جای درخواست مستقیم و پاسخگویی مانند HTTP. در نتیجه، وقتی حجم درخواست نسبتاً کم است، سرعت پاسخ در مقایسه با روش RESTful API، نسبتاً کند است. با این حال، هنگامی که تعداد درخواست ها افزایش می یابد، خطایی وجود ندارد یا نمی توان به درخواست پاسخ داد. عملکرد نسبتاً پایدار حفظ می شود.

نتیجه‌گیری:
به منظور آزمایش دو روش ارتباطی معماری Microservice، این مقاله آزمایش‌های شبیه‌سازی را بر روی برنامه وب Microservice با استفاده از روش RESTful API و روش RabbitMQ انجام می‌دهد. نتیجه نهایی این است که برنامه وب Microservice از RESTful API استفاده می کند و عملکرد درخواست پاسخ نسبتاً خوب است زمانی که تعداد درخواست های همزمان کم باشد. با این حال، زمانی که تعداد درخواست ها از بار بیشتر شود، عملکرد به طور جدی تحت تأثیر قرار می گیرد یا حتی سرویس به طور معمول ارائه نمی شود. برنامه وب Microservice با استفاده از روش RabbitMQ، اگرچه عملکرد درخواست پاسخ به خوبی API RESTful در زمانی که تعداد کمی از کاربران آنلاین وجود دارد، نیست، تعداد درخواست‌ها تأثیر زیادی بر عملکرد ندارد و نسبتاً پایدار است. از آنجایی که محیط تست بسیاری از عوامل عملی را در نظر نمی گیرد، به عنوان یک برنامه آینده، انواع موقعیت ها و عوامل واقعی که ممکن است رخ دهد اضافه می کند. تست را دقیق تر و قابل اطمینان تر می کند.