مهاجرت به سبک معماری میکروسرویس

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

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

پس با من همراه باشید تا با یکی از ترندهای جذاب حوزه مهندسی و معماری نرم افزار آشنا بشیم.

دانلود مقاله (نسخه PDF)

لینک مقاله در ریسرچ گیت

من در لینکدین

مقدمه

معماری میکروسرویس ها سبک و سیاقی از معماری است که از شیوه تفکر مبتنی بر سرویس گرایی الهام گرفته شده است. اصطلاح میکروسرویس در جست و جوهای اخیر در رابطه با اصطلاح "میکروسرویس ها" در سطح اینترنت نشان می دهد که بیشترین جست و جوها مبتنی بر فناوری هستند. این مطلب عنوان می کند که دوران جست و جوهای عامه نظیر عبارت "میکروسرویس چیست ؟ " به سرآمده است. نه فقط فروشندگان نرم افزاری نظیر مایکروسافت یا آی بی ام که تولیدکنندگان محتوی نظیر Netflix و Amazon نیز از معماری میکروسرویس ها در محصولات خود استفاده می کنند.

چند تعریف از میکروسرویس

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

مفهوم اتصال سست

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

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

سه اصل کلیدی معماری میکروسرویس

1. محدوده مرزی:‌این اصطلاح برای بار نخست توسط Eric Evan در اثر معروفش با نام طراحی مدل رانه بکار گرفته شد. و به یکی از ویژگی های کلیدی معماری میکروسرویس ها اشاره دارد. : تمرکز بر روی قابلیت های کسب و کار . ویژگی های مرتبط درون یک قابلیت کسب و کار ترکیب و سپس نهادینه می شوند و در انتها به عنوان یک سرویسپیاده سازی می شوند.
2. اندازه:‌اندازه یک مفهوم حیاتی برای میکروسرویس هاست و مزایای عمده ای را در ارتباط با قابلیت نگهداری و توسعه سرویس ها برای ما به ارمغان می آورد. استفاده ایده آل از معماری میکروسرویس ها چنین است که اگر یک سرویس خیلی بزرگ است باید به دو یا چند سرویس کوچکتر پالایش شود. بدین ترتیب حفظ دانه بندی و نگهداری بر ارائه تنها یک قابلیت کسب و کار واحد متمرکز است.
3. استقلال:این مفهوم حاکی اتصال سست و انسجام بالا در میکروسرویس ها هست بدین صورت که هر سرویس در معماری میکروسرویس ها در عمل مستقل از دیگری است و تنها راه ارتباط سرویس ها از طریق اینترفیس های منتشر شده است.

مشکلات معماری یکپارچه

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

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

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

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

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

علل مهاجرت به معماری میکروسرویس ها با بررسی نتایج تجربی 21 متخصص حوزه صنعت نرم افزار

• قابلیت نگهداری بالا :معماری ماژولار میکروسرویس ها باعث شده است که نرخ پیچیدگی سیستم های یکنواخت کاهش پیدا کند. شکستن یک سیستم به سرویس های مجزی و خودمختارباعث شده است که توسعه دهندگان ماژول های موردنیازشان را بدون نیاز به دیگر توسعه دهندگان تست کرده و به اعمال تغییرات در آن بپردازند. همین عامل سبب سادگی در امر توسعه توزیع پذیری می شود.
• مقیاس پذیری : در مقایسه با سیستم های یکنواخت ، معماریمیکروسرویس ها مقیاس پذیری بهتری دارد چرا که این امر در سیستم های یکنواخت نیازمند سرمایه گذاری عظیم در بحث سخت افزاری و کدزنی است. اگر یک Bottleneck در مولفه ای یافت شود یک قطعه سخت افزاری قدرتمند می تواند استفاده شود یا نمونه های مختلف از همان برنامه یکنواخت می تواند در سراسر سرویس های سیستم اجرا شده و توسط یک Load Balancer مدیریت شود.
• محول کردن وظایف تیمی به دیگر اعضای تیم: از آنجایی که میکروسرویس ها وابستگی خارجی ندارند می توانند توسط تیم های مختلف بصورت مستقل پیاده سازی شوند و به همین جهت نرخ سربار ارتباطی3 و نیاز به هماهنگی بین تیم ها پایین می آید. همچنین میکروسرویس ها می توانند توسط فناوری های مختلف و ساختار داخلی متفاوت پیاده سازی شوند ، در نتیجه تنها در تصمیم گیری های فنی سطح بالا نیاز به هماهنگی بین تیم ها احساس می شود و دیگر تصمیمات فنی می توانند توسط خود تیم ها اتخاذ شوند.
• مهاجرت سازمانهای عظیم به این سبک معماری: میکروسرویس ها بسیار جذاب هستند و بسیاری از کمپانی ها بزرگ در حال تطبیق این نوع معماری بر روی سیستم های خود هستند. در نتیجه بسیاری از فعالان نرم افزاری سعی در کنکاش پتانسیل این معماری ارائه می کنند و رفته رفته این علاقه در میان متخصصان نرم افزار بیشتر رواج پیدا می کند.
• پشتیبانی از DevOps : بدین جهت تیم ها می توانند سرویس های موردنظرشان را بصورت مستقل از دیگ تیم ها توسعه داده ، تست کنند و به مرحله استقرار برسند. این مبحث پشتیبانی از DevOpsبه خوبی و در قالب یک گزارش تجربی در راستای مهاجرت به یک معماری مبتنی بر رایانش ابری بر روی سرویس بکتوری در ایران در پگاه تک صورت گرفته است.
• تحمل خطا: خرابی یک میکروسرویس غالبا تمام سیستم را تحت تاثیر قرار نخواهد داد. در مقابل در معماری یکنواخت خرابی یک مولفه تمام برنامه را دچار مشکل می کرد. جالب اینجاست که در صورت خرابی میکروسرویس می توان نسخه قبلی آن را جایگزین نسخه فعلی کرد بدون آنکه نیاز به راه اندازی مجدد کل سیستم باشد و این معرکه است ، همچنین میکروسرویسی که دچار خرابی شده است می تواند به سرعت راه اندازی مجدد شود.
• آزمایش آسان فناوری : میکروسرویس ها طبق تعریف کوچک هستند و مولفه های کوچک ساده تر و سریع تر توسعه پیدا می کنند ، بنابراین برای آزمایش میکروسرویس با فناوری های جدید و اضافه کردن ویژگی های جدید به آنها کار ساده ای پیش رو خواهیمداشت ، چرا که میکروسرویس ها از طبیعت چند زبانی بهره می برند ویژگی که معماری یکنواخت فاقد آنست چرا که اجازه توسعه با چندین زبان را نخواهد داشت.
• مسئولیت های نرم افزاری مجزی : میکروسرویس ها تنها مسئول یک وظیفه خواهند بود که در راستای مرزهای خوش تعریف می باشد و دارای ویژگی خودشمولی می باشد، در نتیجه توسعه بسیار آسان خواهد بود.

چالش های پیش روی میکروسرویس ها

• توسعه سیستم های توزیع شده دارای پیچیدگی است. به دلیل اینکه هر چیز یک سرویس مستقل است و حجم رسیدگی به درخواست هایی که بین ماژول ها در جریان است امری است فزاینده و صعودی پس کنترل جریان انتقال، امری حیاتی تلقی می شود.
• مدیریت پایگاه های داده متعدد و تراکنش های سنگینامری چالش برانگیز تلقی خواهد شد.
• فرآیند تست بسیار پرزحمت خواهد بود. بر خلاف معماری یکنواخت که ما تنها نیاز به راه اندازی WAR بر روی سرور برنامه داشتیم و اطمینان حاصل کنیم اتصال با پایگاه داده مبنایی برقرار خواهد شد. اما در میکروسرویس ها ، هر سرویس مجزی پیش از انجام فرآیند تست می بایست تایید شده باشد
• پیاده سازی میکروسرویس ها دارای پیچیدگی است. نیاز به هماهنگی میکروسرویس ها در میان حجم کثیری از سرویس ها امری متحمل است، در حالی که شاید به مانند پیاده سازی WAR درون یک Container ساده و بی دردسر نخواهد بود.
  اما راه حل چیست ؛ چطور می توانیم این معایب را برطرف کنیم ؟ البته که با یک نوع خودکارسازی و ابزارهای مطلوب می توانند معایب فوق را رفع کرد.

شاید بتوان گفت بزرگترین مزیت میکروسرویس ها این هست که درون پکیج های یکپارچه WAR-like مستقر نخواهند شد. پس استقرار میکروسرویس ها به چه صورت خواهد بود ؟

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

استقرار معماری میکروسرویس ها

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

داکر

داکر خود را اینطور معرفی می کند:‌ هر برنامه ای را که تمایل داشتید بسازید ، هر جایی که خواستید ارسال کنید و هر جایی که خواستید آنرا اجرا کنید.

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

از جمله ویژگی های Docker می توان به موارد ذیل اشاره کرد :

• چابکی ایجاد و حذف سریع محفظه ها
• انتقال پذیری سبک و آسان
• صرفه جویی در هزینه
• مدیریت قدرتمند مصرف منابع
• امنیت

اجزای اصلی داکر

• داکر دیمن:‌مدیر و مجری محفظه ها
• داکر سی ال آی:‌ رابط دستوری مرتبط با Daemon
• ایمیج ها: ایمیج ها متنوع داکر

نکته مهم و پایانی

اصل کاری ها قواعد و الگوها هستند نه فناوری : امکان دارد فناوری Docker که در بالا معرفی کردیم به زودی قدیمی شود و جای خود را به یک فناوری جدیدتر بدهد، همانطور که یک روز Hypervisor ها در Virtual Machine ها یکه تازی میکردند و بی رقیب پیش می رفتند، البته درصد فعلی Hypervisor ها به نسبت Docker مقدار 90% به 10% می باشد که پیش بینی میشود در 5 سال آینده به 50% برسد. پس نتیجه میگیریم نمی توان به فناوری وابسته بود و الگوها مقدم هستند.

در پایان از دوست عزیز و توانا مسعود بهرامی تشکر می کنم با که با ریفکتور ما رو با میکروسریس ها بیشتر آشنا کرد. از مارتین فاولر هم متشکرم که اعجوبه ای هست تو معماری :-)