میکروسرویس در لاراول

@ali.bayat
ممنون از توضیحات خوبتون آقای بیات
یه نکته ای همیشه برای من سوال بوده

اگه سرویس هامون از طریق rest api با هم ارتباط دارن
پس وقتی نیاز به ارتباط بین سرویس ها باشه سرویس باید هزینه زیاد api request رو متحمل بشه، حجم هدر های ریکوئست و ارسال و دریافت و صف ریکوئست های هر سرویس و...، و همینطور همیشه سرویس ها در حال ارسال و دریافت درخواست به بقیه سرویس ها هستن و درگیرن

در حالی که در معماری MVC ما این کار ها رو مستقیما انجام میدیم، یعنی مستقیم از همه قسمت های دیتابیس دیتا دریافت میکنیم یا زمانی که به هر قسمتی نیاز داشتیم کافیه اون رو فراخوانی کنیم و مستقیما ازش استفاده کنیم چون همه کد ها یکپارچه هستن و تنها از سمت یوزر ها ریکوئست دریافت میشه.

این مورد در میکروسرویس چطور هندل میشه ؟

@saman1111

در معماری Monolothic ما همه سرویس هامون رو در یک اپلیکیشن قرار میدیم..
با بزرگ شدن پروژه و زیاد شدن تعداد کاربرا و درخواست هاشون برای قسمت های مختلف بار وارده روی اپلیکیشن خیلی بالا میره
که نهایتا منجر به استفاده از Load-Balancing و ... میشه

در سطح خیلی بزرگ درگیر بودن سرویس ها با درخواست های مختلف Rest ... در واقع فشار و بار کمتری رو به وجود میاره..
مثلا اگر شما در یک سرویس فقط کارهای مربوط به کاربر ها رو انجام بدی.. این سرویس نهایتا اونقدرها هم شلوغ نمیشه.
نهایتا داره کاربر ها رو ثبت و لاگین و ... میکنه

در حالی که در معماری یکپارچه: این میشه قسمتی از رکوئست هایی که سیستم باید پردازش کنه

این معماری هم نقاط ظعف و قوتی داره که باید دید بنا به شرایط استفاده ازش معقول هست یا نه

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

@ali.bayat
مرسی از توضیحات خوب و کاملتون
بله درست میگین ولی وقتی که یه سرویس بخواد اطلاعات کاربر ها رو بگیره باید به سرویس مربوطه ریکوئست بده و دیتا رو بیاره
در حالی که در بقیه معماری ها مثل MVC فقط کافیه از دیتابیسی که روی همون سرور هست بدون نیاز به درگیر شدن وب سرور و همینطور گذشتن ریکوئست از میدلور ها و routing و... دیتا رو خیلی سریعتر بگیره و ازش استفاده کنه
این موردی که دارم میگم واقعا وجود داره یا این که جور دیگه ایه و تفاوت زیادی از نظر کارایی ندارن ؟
فقط در رابطه با ارتباط سرویس ها با هم، نه پرفورمنس کلی سیستم

@ali.bayat
سلام ببخشید من یکم از بحث خارجم و یه سوال دارم
منظورتون دقیقا از سرویس چه بخشیه؟ میشه مثال بزنید
مقلا فانکشن مربوط به رجیستر یا لاگین رو یه سرویس حساب میکنیم؟
این کلمه رو جاهای مختلف میشنوم ولی برام گنگه دقیقا به چی گفته میشه

@miladparsi1070
برای درک راحت تر موضوع مثال اسنپ تاکسی رو در نظر بگیرید. حالت اول این هست که کل عملیات بصورت یکجا و در قالب یک پروژه یکپارچه توسعه و راه اندازی بشه. ولی وقتی حجم کار و پروژه بالا می‌ره، بدلایل متعددی که بالاتر اشاره شد، میان و کل پروژه رو به زیر سرویس‌هایی تقسیم بندی میکنند. مثلا در مثال ما، مجموعه از عملیات و فانکشن ها در رابطه با عملیات مرتبط با Auth هست. مثل ثبت نام و فراموشی رمز عبور و ورود و ...

یک سرویس می‌تونیم داشته باشیم که به صورت خاص در ارتباط با بحث مسیریابی و الگوریتم های اون حوزه ست. یک سرویس بصورت تخصصی کارش محاسبه هزینه سفر بر اساس پارامترهای مختلف. یک سرویس در نقش حسابدار وظیفه رسیدگی به تمام دستور های مرتبط با بحث مالی و پرداخت رو داره. یک سرویس به چت Real-time بین مسافر و راننده می‌پردازه و ...

و رابطه بین هر یک از این سرویس ها با یکدیگر هم معمولا در قالب Rest API هست. چند تا از مهم ترین مزیت های این قضیه هم به نظرم اینه:

• بدلیل استقلال نسبی که هر یک از این سرویس ها دارند، مهم نیست که با چه زبان برنامه نویسی Develop بشن. مهم این هست که ورودی رو بگیرند و خروجی مورد نظر ما رو تحویل بدن. و خوب این قضیه دستمون رو خیلی جاها باز میذاره.

• اگر به هر دلیلی یکی از سرویس ها دچار باگ، اختلال یا قطعی بشن کل سیستم نمی‌خوابه. بلکه محدود میشه به همون زیر سرویس.

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

@mhyeganeh
پس چیزی که من متوجه شدم اینه که سرویس های مختلف داخل همون پروژه اصلی وجود دارن درسته؟ یعنی مثلا به قول شما بخش مربوط به authentication میشه یه سرویس یا بخش چت یدونه دیگه و .... درست میگم؟
حالا سوال دیگه اینه که خب چجوری میشه هر سرویس رو با یه زبان نوشت؟ توی هاست مشکل به وجود نمیاد؟
با این که هرکردومشون از خروجی اونیکی استفاده میکنن مشکل ندارم و برام اکیه! سوالم اینه که مجموع این سرویس ها اگه با زبان های مختلف نوشته بشن، چجوری توی هاست قرار میگیرن؟!

@miladparsi1070

هر سرویس در واقع بخش کوچکی از اپلیکیشن هست

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

@ali.bayat
اها بله متوجه شدم
خیلی ممنونم

با تشکر از جناب بیات و سایر دوستان

معلومات خوبی رو در مورد میکروسرویس ها به اشتراک گذاشتید و استفاده بردیم