سلام و وقت بخیر ؛ من میخام یک وب سایت آزمون آنلاین با معماری میکروسرویس طراحی کنم که برای فرانتش از فریم ورک ویو و برای بک از نود استفاده کنم ، کورس های آموزشی در رابطه با این موضوع رو کسی میشناسه معرفی کنه ، ممنون میشم و اینکه از کجا باید شروع کنم؟
این معماری در کنار مزایایی که داره، معایبی هم داره که بررسی میکنیم
بر خلاف معماری مونولیتیک، در یک اپلیکیشنی که در آن از معماری میکروسرویس استفاده شده باشد سرویسها هرگز بر اساس معماری MVC تقسیمبندی نمیشوند بلکه بر اساس کاری که انجام میدهند به بخشهای مختلف تقسیم میشوند. به عبارت دیگر، یک سرویس همچون آپلود فایل شامل بخشهایی همچون رابط کاربری، مدلهای مرتبط با دیتابیس، کنترلر، سیستم لاگینگ و ... خواهد بود (در چنین شرایطی، فرض کنیم دولوپر سرویسی تحت عنوان File Uploader میسازد و از آن پس به سادگی قادر خواهد بود سرویس مد نظر را در دیگر پروژهها که کاربرد یکسانی دارند نیز استفاده کند.)
یکی دیگر از مزیتهای میکروسرویسها این است که ما مجبور به استفاده از صرفاً یک زبان برنامهنویسی یا فناوری در کل پروژه نمیشویم. در واقع، با توجه به اینکه امروزه برخی زبانهای برنامهنویسی برای حوزههای خاصی تخصصیتر هستند و استفاده از زبانی که اختصاصاً برای کار خاصی طراحی شده پرفورمنس اپلیکیشن ما را بالاتر میبرد، با استفاده از میکروسرویسها قادر خواهیم بود تا بسته به نوع سرویس مد نظر خود از چندین زبان برنامهنویسی و فناوری مختلف استفاده کرده و پرفورمنس را به حد اعلای خود برسانیم.
علاوه بر موارد فوق، میکروسرویسها اصطلاحاً Scalable (قابلتوسعه) هستند. ماهیت مستقل ماژولهای مختلف یک میکروسرویس این امکان را برایمان فراهم میآورند تا با استفاده از زبانی خاص، دیتابیسی خاص و همچنین سروری خاص به توسعهٔ اپلکیکشن مد نظر خود بپردازیم و در صورت نیاز صرفاً منابع همان پلتفرم را ارتقاء دهیم.
از آنجا که هر سرویس مسئول انجام تَسک خاصی است، در اپلیکیشنها بسیار بزرگ تعداد سرویسهای بیشماری خواهیم داشت و از همین روی برقراری ارتباط مابین این سرویسها و از همه مهمتر مانیتور کردن آنها کاری بس دشوار خواهد بود (برخی دادهها حاکی از آنند که سرویسی همچون نتفلیکسن صدها سرویس مختلف دارد.)
با توجه به اینکه سرویسها برای برطرف کردن نیازهای خود دیگر سرویسها را کال (فراخوانی) میکنند، رصد کردن آنها و بالتبع فرایند دیباگینگ بسیار دشوار خواهد شد.
هر سرویس لاگگیری اختصاصی خود را دارا است و از همین روی هیچ سیستم مانیتورینگ مرکزی برای بررسی لاگها وجود ندارد و در چنین شرایطی نیاز به یک سیستم مدیریت لاگ مرکزی وجود خواهد داشت.
با توجه به اینکه ارتباط سرویسها با یکدیگر معمولا از طریق API است، تعداد رکوئستها نسبت به یک معماری مونولیتیک به مراتب بیشتر خواهد بود.
دیپلوی کردن اپلیکیشنهایی که با استفاده از معماری میکروسرویس طراحی شدهاند به صورت دستی مشکل است و در چنین شرایطی نیاز به ابزارهای اتوماسیون پیشرفته خواهد بود. مبحث معماری میکروسرویس بسیار گسترده است و زمانی که بخواهیم وارد این حوزه شویم، نیاز است تا با مفاهیمی همچون Continuous Integration ،Continuous Deploymnet ،Container و همچنین ابزارهای دیپلوی خودکار نیز آشنا شویم
ورژنبندی میکروسرویسها باید به صورت مجزا از یکدیگر صورت گیرد و اینجا است که نیاز داریم تا مشخص کنیم به طور مثال کدام ورژن سرویس A با کدام ورژن سرویس Z باید دیپلوی شود.
مستنداتسازی چنین اپلیکیشنهایی مشکلتر است چرا که با توجه به ماهیت مستقل هر ماژول، سرویسها باید به صورت کامل مستندسازی شوند.
ا توجه به اینکه ممکن است از چندین زبان برنامهنویسی و تکنولوژی مختلف در چنین اپلیکیشنهایی استفاده شود، هزینهٔ نگهداری چنین سیستمها گاهی اوقات زیاد میشود به طوری که مثلاً نیاز به استخدام دولوپر زبانهای مختلف خواهیم داشت.
در نهایت نیاز های پروژه هست که مشخص میکنه ما به چه معماری نیاز داریم.
@soniaamiri04
سایت یودمی دوره های خوبی برگزار میکنه که سرتیفیکیت معتبر هم میده. دوتا دوره خوب در این رابطه داره که باید هزینه کنید که البته زیاد نیست:
آموزش اولی
آموزش دومی
دو تا دوره رایگان شده هم داره:
رایگان اولی
رایگان دومی
یه نکته خوب هم بگم اینکه کانال های تلگرامی و وب سایت هایی هستن که روزانه کد تخفیف یودمی میذارن و از دوره های رایگان شده اطلاع میدن. که اگه حواست باشه همین دوره های پولی رو هم احتمال خیلی زیاد بتونی رایگان بگیری.
موفق باشی.
Website For Free Coupons: http://www.Coursevania.com
Telegram chanel
https://t.me/DMCACoursevania/3
با سلام
میتونین از پکیج اموزشی نود جی اس در خود سایت راکت و همچنین ویو جی اس استفاده کنید
و برای ارتباط بین سرور نود جی اس و همچنین نود جی اس از کتابخانه هایی مثل axios ، ajax استفاده کنید و همچنین میتونین برای مدیریت ریل تایم از سوکت استفاده کنید ، موفق و پیروز باشید
جدا از بحث فرانت و بک که باید اون فریم ورک ها رو یاد بگیری
باید دید هدف استفاده از معماری میکروسرویس چی هست و چقدر بهش تسلط داری
اینکه صرفا بدون دلیل بخواهیم از معماری میکروسرویس استفاده کنیم، بیشتر مواقع پیچیدگی رو بیشتر میکنه
همچنین Miantain کردن سرویس ها چالش های خودش رو خواهد داشت
تازه بحث ارتباط سرویس ها هم پیش میاد که به احتمال زیاد باید از یه مسیج بروکر هم استفاده بشه
اگر در این زمینه تجاربی داری که هیچ، اگر نه ابتدا پروژه رو به صورت Monolithic پیاده سازی کن و بعد به سمت مایکرو سرویس کوچ کن.
@ali.bayat سلام ، متاسفانه درباره میکروسرویس هیچ گونه تجربه و زمینه ای ندارم...،ممنونم از راهنماییتون
این معماری در کنار مزایایی که داره، معایبی هم داره که بررسی میکنیم
بر خلاف معماری مونولیتیک، در یک اپلیکیشنی که در آن از معماری میکروسرویس استفاده شده باشد سرویسها هرگز بر اساس معماری MVC تقسیمبندی نمیشوند بلکه بر اساس کاری که انجام میدهند به بخشهای مختلف تقسیم میشوند. به عبارت دیگر، یک سرویس همچون آپلود فایل شامل بخشهایی همچون رابط کاربری، مدلهای مرتبط با دیتابیس، کنترلر، سیستم لاگینگ و ... خواهد بود (در چنین شرایطی، فرض کنیم دولوپر سرویسی تحت عنوان File Uploader میسازد و از آن پس به سادگی قادر خواهد بود سرویس مد نظر را در دیگر پروژهها که کاربرد یکسانی دارند نیز استفاده کند.)
یکی دیگر از مزیتهای میکروسرویسها این است که ما مجبور به استفاده از صرفاً یک زبان برنامهنویسی یا فناوری در کل پروژه نمیشویم. در واقع، با توجه به اینکه امروزه برخی زبانهای برنامهنویسی برای حوزههای خاصی تخصصیتر هستند و استفاده از زبانی که اختصاصاً برای کار خاصی طراحی شده پرفورمنس اپلیکیشن ما را بالاتر میبرد، با استفاده از میکروسرویسها قادر خواهیم بود تا بسته به نوع سرویس مد نظر خود از چندین زبان برنامهنویسی و فناوری مختلف استفاده کرده و پرفورمنس را به حد اعلای خود برسانیم.
علاوه بر موارد فوق، میکروسرویسها اصطلاحاً Scalable (قابلتوسعه) هستند. ماهیت مستقل ماژولهای مختلف یک میکروسرویس این امکان را برایمان فراهم میآورند تا با استفاده از زبانی خاص، دیتابیسی خاص و همچنین سروری خاص به توسعهٔ اپلکیکشن مد نظر خود بپردازیم و در صورت نیاز صرفاً منابع همان پلتفرم را ارتقاء دهیم.
از آنجا که هر سرویس مسئول انجام تَسک خاصی است، در اپلیکیشنها بسیار بزرگ تعداد سرویسهای بیشماری خواهیم داشت و از همین روی برقراری ارتباط مابین این سرویسها و از همه مهمتر مانیتور کردن آنها کاری بس دشوار خواهد بود (برخی دادهها حاکی از آنند که سرویسی همچون نتفلیکسن صدها سرویس مختلف دارد.)
با توجه به اینکه سرویسها برای برطرف کردن نیازهای خود دیگر سرویسها را کال (فراخوانی) میکنند، رصد کردن آنها و بالتبع فرایند دیباگینگ بسیار دشوار خواهد شد.
هر سرویس لاگگیری اختصاصی خود را دارا است و از همین روی هیچ سیستم مانیتورینگ مرکزی برای بررسی لاگها وجود ندارد و در چنین شرایطی نیاز به یک سیستم مدیریت لاگ مرکزی وجود خواهد داشت.
با توجه به اینکه ارتباط سرویسها با یکدیگر معمولا از طریق API است، تعداد رکوئستها نسبت به یک معماری مونولیتیک به مراتب بیشتر خواهد بود.
دیپلوی کردن اپلیکیشنهایی که با استفاده از معماری میکروسرویس طراحی شدهاند به صورت دستی مشکل است و در چنین شرایطی نیاز به ابزارهای اتوماسیون پیشرفته خواهد بود. مبحث معماری میکروسرویس بسیار گسترده است و زمانی که بخواهیم وارد این حوزه شویم، نیاز است تا با مفاهیمی همچون Continuous Integration ،Continuous Deploymnet ،Container و همچنین ابزارهای دیپلوی خودکار نیز آشنا شویم
ورژنبندی میکروسرویسها باید به صورت مجزا از یکدیگر صورت گیرد و اینجا است که نیاز داریم تا مشخص کنیم به طور مثال کدام ورژن سرویس A با کدام ورژن سرویس Z باید دیپلوی شود.
مستنداتسازی چنین اپلیکیشنهایی مشکلتر است چرا که با توجه به ماهیت مستقل هر ماژول، سرویسها باید به صورت کامل مستندسازی شوند.
ا توجه به اینکه ممکن است از چندین زبان برنامهنویسی و تکنولوژی مختلف در چنین اپلیکیشنهایی استفاده شود، هزینهٔ نگهداری چنین سیستمها گاهی اوقات زیاد میشود به طوری که مثلاً نیاز به استخدام دولوپر زبانهای مختلف خواهیم داشت.
در نهایت نیاز های پروژه هست که مشخص میکنه ما به چه معماری نیاز داریم.
آیا مایل به ارسال نوتیفیکیشن و اخبار از طرف راکت هستید ؟