یلدا ادامه داره... ❤️ ۴۰ درصد تخفیف همه دوره‌ها

استفاده از تخفیف‌ها
ثانیه
دقیقه
ساعت
روز
ftp
4 سال پیش توسط ftp مطرح شد
3 پاسخ

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

@ali.bayat
@abedim910
ایا میکرو سرویس نوشتن به این شکل هست که مثلا سیستم ثبت نام رو داخل یک پروژه لاراول بنویسم و سیستم حسابداری رو هم در یک پروژه و به وسیله api به هم وصلش کنیم ایا درسته یا نه؟


ثبت پرسش جدید
عرفان
تخصص : Python
@erf 4 سال پیش آپدیت شد
0

سلام
حقیقتا نه
مفهمومش همینه اما خیلی پیچیده تر از اینهاست


Muhammad
تخصص : Back-End Developer
@muhammad 4 سال پیش آپدیت شد
1

سلام
مایکروسرویس در برابر معماری monolithic مطرح میشه، یعنی بخش‌های مختلف اپلیکیشن به پروژه‌های کوچک‌تری شکسته بشه تا:

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

دوباره برگردیم به سوالتون:‌ لاراول گزینه‌ی خوبی برای سرویس authentication نیست و اگه لازم بود این بخش رو جدا کنید، از ابزارهای مناسب‌تری استفاده کنید، Lumen می‌تونه گزینه‌ی خوبی باشه. البته در مقیاس پایین هیچ دلیلی وجود نداره که سرویس authentication جدا بشه. این کارو یکی مثل کافه‌بازار انجام می‌ده که واقعا به چنین معماری نیاز پیدا کرده.


علی بیات
تخصص : توسعه دهنده ارشد وب
@ali.bayat 4 سال پیش مطرح شد
2

اگر بخواهیم کلی بهش نگاه کنیم، میشه گفت همینه اما مباحث بیشتری هم این وسط مطرح هست مثل Gateway و غیره.

اما مایکرو سرویس هم برای هر پروژه ای مناسب نیست
و برای پروژه های کوچک اصلا پیشنهاد نمیشه
چون نه تنها کار خاصی انجام نمیشه بلکه باعث پیچیدگی بیشتر هم میشه

اما برای پروژه های بزرگ داستان متفاوته
از اونجایی که سرویس ها کوچکتر از یک اپلیکیشن Monolothic هستند
پس تست نوشتن براشون راحت تره
مدت زمان توسعه هر سرویس کوتاه تره
و پروژه قابل اسکِیل هست


برای پروژه هایی در این سطح باید کد بسیار تمیزی نوشته بشه

  • مثلا حتما رعایت قانون دوم (Open-Close principle) SOLID درش واجبه

our code should be open to extension but closed for modification

بدین ترتیب برای فیچر اضافه کردن به پروژه
تغییراتی نخواهد بود بلکه سورس کدهایی اضافه میشه
و سیستم توسعه پیدا میکنه

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

  • و یا قانون آخر سالید Dependency Inversion کاملا لازمه

High level modules should not depend upon low level modules

و در نتیجه:

our Modules should depend upon abstraction, not concretions

فرض کن توی پروژت داری اس ام اس ارسال میکنی و بنا به هر دلیلی قرار باشه از کاوه نگار به یه سرویس پیامکی دیگه کوچ کنی
کد بیس های کاوه نگار نباید در سیستمت هارد کد شده باشه
باید از Interface ها استفاده کنی و تنها درایور ارسال اس ام اس رو عوض کنی
نه که قرار باشه بری در جای جای کدها و روش های کاوه نگار رو با سرویس دهنده جدید عوض کنی..


هر چقدر هم مایکروسرویس معماری خوبی باشه
اگر تمیز کد ننویسی
استفاده ازش فقط روند توسعه پروژه رو پیچیده تر میکنه


برای ارسال پاسخ لازم است وارد شده یا ثبت‌نام کنید

ورود یا ثبت‌نام