0

آموزش تعمیر منبع تغذیه سوئیچینگ

اگر با برنامه نویسی و پردازش ابری سروکار داشته باشید به احتمال خیلی زیاد این روز ها عبارت میکروسرویس (MicroService) را زیاد می شنوید. اگر شما هم علاقه مند هستید = در مورد یکی از ترندهای این روزهای دنیای توسعه دهندگان (میکروسرویس) بیشتر بدونید با ما همراه باشید.

هدف این مطلب توضیح یک مفهوم به زبان ساده و کاربردی است نه بیان تئوری های علمی.

میکروسرویس از کجا پیدا شد؟

قبل از شروع یه مقدمه مختصر در مورد پیدایش میکروسرویس ها خدمت شما ارائه میکنم.

با اینکه حدود ۶۰ سال از حضور کامپیوتر ها با اشکال متفاوت در بازار میگذره اما بازار نرم افزار کامپیوتر تقریبا در دهه ۹۰ میلادی به شکوفایی رسید. در ابتدا شرکت ها نرم افزار های خودشون رو به صورت پکیج های نرم افزاری قابل نصب روی PC در قالب های متفاوتی از جمله CD روانه بازار می کردند. مثل آفیس، فوتوشاپ و …

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

پیشرفت صنایع مرتبط با کامپیوتر از جمله سخت افزار، سیستم عامل ها و اینترنت طی دو دهه شرایط صنعت نرم افزار رو به کلی تغییر داد. در ابتدا صرفا جنبه کاربردی نرم افزار ها مطرح بود اما در ادامه علاوه بر پیچیده تر شدن کاربرد های مورد نیاز کاربران، مباحثی مثل UI/UX از یک سمت و بالا رفتن تقاضا برای نرم افزار های کامپیوتری از سمت دیگه باعث این شد که کد نویسی نرم افزار ها از چند هزار خط کد به صد ها هزار خط کد افزایش پیدا کنه و همونطور که گفته شد شرکت ها مجبور بودن همراه با تغییرات نیاز کاربران برنامه ها رو بروز رسانی کنن در غیر اینصورت به سرعت توسط رقبا حذف میشدن. به عنوان مثال فتوشاپ اولین بار در سال ۱۹۹۰ منتشر شد اما نرم افزاری که اون زمان ارائه شد تقریبا چیزی در حد MS Paint امروزی بود.

فتوشاپ CC2020 و فتوشاپ 1 1990
تغییرات فتوشاپ در ۳۰ سال

در نهایت شرکت ها در توسعه این ساختار های یکپارچه بزرگ با مشکلات زیادی روبرو شدن. از یک سمت خواسته ها و سلایق کاربران روز به روز اهمیت بیشتری پیدا می کرد و از سمت دیگه برنامه روز به روز بزرگتر و بزرگتر میشد و انجام یک تغییر جزئی در یک قسمت از نرم افزار ممکن بود باعث مشکلات دیگه ای در سایر قسمت های نرم افزار بشه و روز به روز مشکلات بین توسعه دهنده ها (‌Developer) و قسمت های عملیاتی (‌Operation) بیشتر میشد.

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

معماری میکروسرویس چیست ؟

همونطور که قبلا اشاره کردم میکروسرویس به زبان ساده یعنی یک نرم افزار بزرگ رو به دهها، صد ها یا هزاران قسمت کوچکتر تقسیم کنیم!

پیشینه میکروسرویس به اوایل قرن بیست و یک برمیگرده و از اپلیکیشن های تحت وب شروع شده و با توجه به توسعه مباحث Cloud Computing روز به روز کاربرد های گسترده تری پیدا میکنه. هرچند تعریف واحد و دقیقی بین اساتید و علمای این حوزه وجود نداره اما چند فلسفه رایج از میکرو سرویس رو در ادامه ذکر خواهم کرد:

“چیزهایی که به دلایل مشترک تغییر میکنند رو در کنار هم قرار دهید و چیز هایی که به دلایل متفاوت تغییر میکنند را از هم جدا کنید” رابرت مارتین

“یک کار انجام بدید اما اون کار رو به بهترین شکل ممکن انجام بدید” فلسفه Unix

در حالی که میکروسرویس ها یک ترند نسبتا جدید محسوب میشن اما فلسفه میکروسرویس ها در حقیقت نشات گرفته از نظریه مدیریت علمی فردریک تیلور پس از انقلاب صنعتی در سال ۱۸۷۸ هست که در اصل اول به خرد کردن کارهای بزرگ به وظایف کوچک اشاره شده است.

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

چرا Microservice

در حالی که معماری مونلیتیک یا یکپارچه بسیار متداول و معمول است و معمولا اغلب استارت آپ ها در ابتدا از این معماری برای طراحی نرم افزار های خود استفاده می کنند این سوال مطرح می شود که چرا باید از معماری میکروسرویس استفاده کرد؟! در ادامه سعی میکنم با یک مثال کاربرد میکروسرویس رو بیشتر توضیح بدم.

معماری یکپارچه

به عنوان مثال نرم افزار دیجی کالا رو در نظر میگیریم. در سال های اول دیجی کالا از یک سیستم مدیریت محتوا یکپارچه (Monolithic) استفاده می کرد و عملکرد دیجی کالا به شکل زیر بود.

یک برنامه تحت وب یکپارچه Monolithic Architecture

همونطور که در تصویر مشاهده می کنید کاربران در این مدل به وب سرور دیجی کالا متصل میشدن و بر روی اون سرور یک برنامه به زبان PHP نوشته شده بود که تمام کار های مورد نیاز رو انجام میداد و اطلاعات رو در یک دیتابیس ذخیره می کرد یا مورد بازخوانی قرار میداد. اون برنامه که با آیکن </> در تصویر نمایش داده شده همه کارهای مورد نیاز کاربران دیجی کالا رو انجام میداد و پردازش ها رو انجام میداد و در نهایت نتایج رو از طریق وب سرور به کاربر ارسال می کرد.

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

معماری میکرو سرویس

اما فرض کنید زمانی که دیجی کالا با این چالش ها مواجه شد به سمت معماری میکروسرویس حرکت می کرد. در این صورت عملکرد دیجی کالا به شکل زیر تغییر می کرد.

معماری میکروسرویس - Microservice Architecture
معماری میکروسرویس

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

در معماری میکروسرویس، هر میکروسرویس می تواند از زبان برنامه نویسی متفاوتی استفاده نماید. حتی ممکن است سیستم عامل مورد استفاده هر میکروسرویس متفاوت باشد و در نهایت تمام میکروسرویس ها بر روی یک شبکه با یکدیگر ارتباط برقرار می کنند. به همین جهت استفاده از میکروسرویس ها انعطاف پذیری تیم ها را برای استفاده از توسعه دهندگان متفاوت در کنار یکدیگر فراهم می کند. به عنوان مثال اگر وب سایت دیجی کالا از PHP برای نمایش وب سایت استفاده نماید می تواند از زبان دیگری مانند جاوا، پایتون یا سی و … برای بخش های دیگر مانند مدیریت انبار و لجستیک استفاده کند.

قانون 2 پیتزا جف بزوس و میکروسرویس Microservice

قانون دو پیتزا

جف بزوس موسس آمازون قانونی تحت عنوان Two Pizza Rule رو در شرکت آمازون اجرا کرده که طبق این قانون تعداد افراد تیم های داخلی آمازون باید به اندازه ای باشه که نهایتا با ۲ پیتزا بشه اونا رو سیر کرد! یقینا هدف جف بزوس از این قانون صرفه جویی در هزینه خوراک پرسنل نبوده و نیست! یکی از اهداف این قانون انجام کار های بزرگ در قالب مجموعه ای از کارهای کوچک هست.

معماری میکروسرویس و یکپارچه

میکروسرویس یا مونولیتیک، مسئله این است!

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

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

معمولا برای پروژه های کوچک در ابتدای کار استفاده از معماری میکروسرویس زمان انجام پروژه و منابع مورد نیاز را افزایش می دهد و ممکن است این مورد برای بسیاری از استارت آپ ها مطلوب نباشد. اما در سیستم های بزرگ یا در توسعه های آینده به شدت توسعه پذیری را ساده تر و زمان و منابع مورد نیاز پروژه ها را کاهش می دهد.

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

در نهایت از شما به خاطر وقتی که صرف خوندن این مطلب کردید تشکر می کنم و خوشحال میشم نظرات خودتون رو از طریق قسمت نظرات پایین همین صفحه برای من ارسال کنید. تک تک نظرات شما در فعالیت ما موثر خواهد بود.

برای نوشتن این مطلب که در کمتر از ۱۰ دقیقه قابل خوندن هست بیش از ۵ ساعت مطالعه و بررسی صورت گرفته تا دانش لازم در قالب کلمات و مثال های ساده قابل انتقال باشه. تمام تلاش من و همکارانم در دیجی نیک ارائه مطالب اختصاصی، باکیفیت و مستند به فارسی زبانان سراسر دنیاست. امیدوارم شما هم با صرف چند ثانیه از وقت گران بهای خودتون نظرات ارزشمندتون رو برای ما بفرستید.

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.