An Introduction to Microservices

 

مقدمه :

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

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

به ویژه هنگامی که با موضوعاتی همچون توسعه چابک و ارائه برنامه‌های پیچیده همراه می‌شود. این معماری سعی در حل مشکلاتی دارد كه ناشی از رشد بیش از اندازه سورس کد شماست و نگهداری از آن روز به روز دشوارتر می‌شود.

مایکروسرویس‌ها مزایای زیادی برای تیمهای Agile و DevOps به همراه دارند. همانطور که مارتین فاولر اشاره می‌کند، Netflix،eBay ،Amazon ،Twitter ،  PayPal و سایر ستاره‌های فناوری همه از معماری یکپارچه به سمت مایکروسرویس ها متمایل شده‌اند. بر خلاف مایکروسرویس‌ها، یک برنامه یکپارچه به عنوان یک واحد مستقل ساخته می‌شود.

این امر باعث می‌شود تغییرات در برنامه کند شوند، زیرا روی کل سیستم تأثیر می‌گذارند. اصلاحاتی که در بخش کوچکی از کد انجام می‌شود، ممکن است نیاز به ساخت و استقرار نسخه کاملاً جدیدی از نرم‌افزار داشته باشد. مقیاس‌گذاری توابع خاص یک برنامه، همچنین بدان معنی است که شما باید کل برنامه را مقیاس‌بندی کنید.

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

این سرویس ها ممکن است به زبان های مختلف برنامه‌نویسی نوشته شده باشند و از تکنیک‌های مختلف ذخیره اطلاعات استفاده کنند. اگرچه این امر منجر به توسعه سیستم هایی می‌شود که مقیاس‌پذیر و انعطاف‌پذیر باشند، اما به یک تغییر پویا نیاز دارد .مایکروسرویس ها اغلب از طریق API متصل می‌شوند و می‌توانند از بسیاری از ابزارها و راه حل های مشابه که در اکوسیستم RESTFUL و سرویس وب رشد کرده‌اند استفاده کنند. تست این API ها می‌تواند به تأیید جریان داده و اطلاعات در سراسر استقرار برنامه مایکروسرویس شما کمک کند.

 

 تاریخچه مختصر:

اصطلاح مایکروسرویس اولین بار توسط دکتر پیتر راجرز (Dr. Peter Rodgers) در سال 2005 ابداع شد و در ابتدا به عنوان "Micro Web Services" شناخته شد. عامل اصلی ایجاد این نوع سرویس‌ها در آن زمان، شکستن و تجزیه برنامه‌های بزرگ "یکپارچه" به چندین کامپوننت/فرآیند مستقل بود تا بدین ترتیب سورس کد برنامه دارای قابلیت دانه‌بندی و مدیریت بیشتری شود.

ایده برنامه‌های توزیع شده ماژولار، به چندین دهه قبل باز می گردد. و از این نظر، مایکروسرویس ها مفهوم جدیدی نیستند. با این حال، آنچه باعث شهرت مایکروسرویس ها شده است، اصول حاکم بر نحوه طراحی و نحوه مصرف آنها می‌باشد. در حالی که سیستم های توزیع شده معمولی آن دوران به پروتکل ‌های ارتباطی اختصاصی متکی بودند، مایکرو سرویس‌ها از استانداردهای بازی مانندHTTP ،REST ،  XMLو JSON بهره می‌بردند.

 

یک تعریف ساده:

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

 برای اینکه یک سرویس "مایکرو" در نظر گرفته شود، هیچ الزام یا مشخصاتی برای تنظیم کد شما وجود ندارد. در عوض، توسعه دهندگان و معماران برای دستیابی به سیستمی که مناسب آنها باشد باید به مجموعه ایده های کلی پایبند باشند. مارتین فاولر تعریفی را به شکل زیر ارائه داده است:

"سبک معماری مایکروسرویس، رویکردی برای توسعه یک برنامه واحد به عنوان مجموعه‌ای از سرویس های کوچک است که هرکدام در روند خاص خود اجرا می‌شوند و با مکانیزم‌های سبک، اغلب یک API ارتباط برقرار می‌کنند. "

تصویر زیر یک مدل مرجع بسیار ساده برای معماری مایکروسرویس است. این تصویر یک سیستم فرضی متشکل از چندین سرویس دانه دانه (مایکرو) را نشان می‌دهد که هم بصورت Sync - از طریق تماس های    API  داخلی یا Async - از طریق ارسال پیام با کمک یک کارگزار پیام (Message Broker) ارتباط برقرار می‌کنند.

کل استقرار در محدوده سیستم تصویری موجود است. سیستمهای خارجی (کاربران، برنامه ها، شرکای B2B و غیره) فقط از طریق مجموعه‌ای از API های رو به بیرون - که معمولاً به عنوان دروازه API نامیده می‌شوند، می‌توانند با مایکروسرویس ها ارتباط برقرار کنند. سرویس های داخل مرز می‌توانند آزادانه در صورت لزوم خدمات خارجی را استفاده کنند.

 

 

 

مایکروسرویس ها به عنوان راه حلی برای چالش‌های مقیاس پذیری با معماری یکپارچه تکامل یافتند. یک برنامه مایکروسرویس معمولاً کوچک است و در محدوده‌ی هزاران خط کد قرار دارد. در عمل یک برنامه "یکپارچه" معمولاً برنامه ای است که شامل صدها هزار خط کد است.

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

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

 

 

این تصویر تجزیه یک پلتفرم تجارت الکترونیکی ساده اما کاربردی است. هر مایکروسرویس در تصویر نقش ویژه‌ای را ایفا می‌کند، مراقبت کامل از یک دامنه جدا شده - مانند سبد خرید، موجودی کالا، قرار دادن سفارش، پرداخت ها، خرید، گزارش و سفارش مجدد تأمین کننده. سرویس سبد خرید به عنوان یک BFF سبک عمل می‌کند، به عنوان یک درگاه API برای جداسازی برنامه مشتری از منطق تجاری لازم برای انجام سفارشات عمل می‌کند. در مقابل، در معماری یکپارچه معمولاً همه این نگرانی‌ها و کامپوننت‌ها در یک برنامه یکپارچه می‌شوند. مثل شکل زیر در عمل:

 

 

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

 

دلایل استفاده از مایکرو سرویس ها:

برای درک اینکه چرا باید در این مسیر گام برداریم، بیایید چالش‌های معمول ذاتی برنامه های یکپارچه را در نظر بگیرید:

• برای هر تغییر، صرف نظر از بزرگ یا کوچک بودن تغییر، کل برنامه باید دوباره ساخته و دوباره به کار گرفته شود. زمان ساخت 15-30 دقیقه برای برنامه های بزرگ غیر معمول نیست.
  
  
• یک تغییر کوچک در یک قسمت از برنامه، توانایی شکستن کل سیستم را دارد.
  
  
• با بزرگ شدن برنامه، قسمتهای آن بیشتر به هم گره می‌خورند و درک و نگهداری سورس کد دشوار می‌شود.
  
  
• برنامه‌های بزرگ دارای ردپای منابع متناسب زیادی هستند - آنها معمولاً حافظه بیشتری مصرف می‌کنند و به قدرت محاسباتی بیشتری نیاز دارند. در نتیجه باید در سرورهای بزرگ با ظرفیت منابع کافی میزبانی شوند. این موضوع همچنین توانایی آنها را در مقیاس‌بندی نیز محدود می‌کند.
  
  
• همچنین تمایل دارند که زمان راه اندازی آهسته‌ای داشته باشند، که با توجه به اینکه کوچکترین تغییرات نیز نیاز به تغییر مکان کامل دارند، به هیچ وجه ایده آل نیست. این نوع معماری ها برای میزبانی در سرویس های ابری کمتر مناسب هستند.
  
  
• برای پیاده‌سازی کل برنامه، از یک فناوری واحد استفاده می‌شود که اغلب این امر سازگاری مناسبی با نیازهای خاص برنامه ندارد. جاوا و  .Netاحتمالاً کاندیدهای معماری یکپارچه هستند، زیرا از بهترین زبان‌های "همه کاره" هستند، نه به این دلیل که بطور شگفت انگیزی در انجام هر کار خاصی مهارت دارند.
  
  
• مقیاس‌پذیری تیم بطور طبیعی توسط یک کد بزرگ و پیچیده محدود می‌شود. هرچه برنامه پیچیده‌تر باشد (از نظر وابستگی های داخلی)، به سختی می‌توان نیرو جدید به تیم‌ها اضافه نمود.

 

 

 

مزایای مایکروسرویس ها:

• مقیاس‌پذیری: پروسه‌های مستقل در معماری مایکروسرویس‌ها می‌توانند به راحتی مقیاس‌بندی شوند. برنامه‌های کوچکتر می‌توانند هم بصورت افقی (با اضافه کردن نمونه های بیشتر) و هم به صورت عمودی (با افزایش منابع موجود برای هر نمونه) مقیاس‌بندی شوند.
  
  
• ماژولار بودن: یک مزیت آشکار در داشتن برنامه های مستقل کوچکتر، این است که جدایی فیزیکی بین فرآیندها، شما را مجبور می‌کند تا نحوه اتصال را در راس طراحی خود قرار دهید. هر برنامه مسئولیت انجام مسئولیت‌های کمتری می‌باشد و در نتیجه یک کد منسجم‌تر و فشرده‌تر ایجاد می‌شود.
  
  
• تنوع فناوری: مایکروسرویس‌ها واحدهای مستقلی هستند که با استانداردهای باز ارتباط برقرار می‌کنند. این بدان معنی است که گزینه های فناوری پشت پیاده‌سازی مایکروسرویس‌ها در مقایسه با یکپارچه بسیار متنوع است. می‌توان گفت مایکروسرویس مورد نظر نیز مهم است، اما این انتخاب مربوط به بقیه سیستم نیست.

 دیدن معماری مایکروسرویس‌ها با ترکیبی از فناوری‌هایی چون جاوا و Go برای منطق کسب و کار،       Node.js  برای دروازه های API، و پایتون برای گزارش و تجزیه و تحلیل غیر معمول نیست.

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

 این خودمختاری به تیم اجازه می‌دهد تا با خیال راحت فناوری‌های جدید، رویکردها و فرآیندها را تست کنند و در صورت عدم موفقیت در یکی از تست ها، سریعاً شکست بخورد و هزینه‌ های کمتری ایجاد شود و البته این موضوع صرفا محدود به یک مایکروسرویس خواهد بود و نه کل سیستم.

• مهاجرت آسان: همه ما روی سیستم های بزرگ نرم‌افزاری یکپارچه‌ای کار کرده‌ایم که بر اساس فناوری دو دهه گذشته ساخته شده‌اند و بروزرسانی آنها بسیار دشوار و پر خطر است. این مورد به ندرت در مورد مایکروسرویس ها مطرح است و شما می توانید به راحتی هر کامپوننت را بروزرسانی کنید، بدون اینکه نگران شکست کل پروژه باشید!
  
  
  
• انعطاف‌پذیری و در دسترس بودن: وقتی یک برنامه از نوع معماری یکپارچه پایین می‌رود، تجارت متوقف می‌شود. البته ممکن است همین امر در مورد مایکروسرویس هایی که بسیار ضعیف طراحی شده نیز گفته شود. با این حال، معماری مایکروسرویس ها بر اتصال به اصطلاح شل تأکید می‌کند، جایی که سرویس ها مستقل هستند، کاملاً وابستگی های خود را دارند و ارتباطات همزمان (مسدود کننده) را به حداقل می‌رسانند.

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

 

مایکروسرویس ها هم DevOps را فعال می‌کنند و هم به آن نیاز دارند:

معماری مایکروسرویس ها اغلب برای DevOps و ادغام مداوم / تحویل مداوم  (CI / CD) بهینه شده توصیف می‌شود، و در زمینه سرویس های کوچک که می‌توانند بطور مکرر مستقر شوند، درک دلیل این امر آسان است. اما یک روش دیگر برای بررسی رابطه بین مایکروسرویس‌ها و DevOps این است که معماری مایکروسرویس‌ها برای موفقیت لازم در واقع به DevOps نیاز دارد.

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

 

نتیجه‌گیری:

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

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