میکروسرویس‌ها یکی از پرکاربردترین رویکردها در دنیای امروز فناوری هستند. توسعه دهندگان میتوانند به جای وابستگی به معماری یکپارچه، بر میکروسرویس‌ها برای ساخت برنامه‌های کاربردی بزرگ (به عنوان ترکیبی از خدمات کوچک) تمرکز کنند. برخلاف معماری یکپارچه، میکروسرویس‌ها پروژه‌های نرم‌افزاری بزرگ را به ماژول‌های مستقل، آزادانه و کوچکتر تقسیم می‌کنند. در میکروسرویس‌ها، برنامه‌های کوچک برای ارائه عملکردهای یک برنامه بزرگ یکپارچه ترکیب می‌شوند.
با خواندن این مقاله متوجه می‌شوید که یک میکروسرویس دقیقا چیست، چه مزایا و چالش‌های مرتبطی با آن وجود دارد و چه کاری می‌توان برای غلبه بر چالش‌ها انجام داد.
میکروسرویس چیست؟
میکروسرویس‌ها (Microservices) یک رویکرد معماری سرویس‌گرا (SOA) برای توسعه نرم افزار هستند. در این رویکرد برنامه‌های کاربردی به عنوان مجموعه‌ای از خدمات مستقل کوچک توسعه می‌یابند. هر سرویس در معماری میکروسرویس مستقل است و نقش منحصربه‌فرد و مشخص خود را دارد، فرآیند خود را اجرا می‌کند و از طریق APIهای HTTP یا پیام‌رسانی ارتباط برقرار می‌کند. هر میکروسرویس مسئول مدل داده خود است و میکروسرویس‌ها میتوانند بدون زحمت از طریق چندین نمونه ارتباط برقرار کنند. بنابراین، شکست در یک سرویس بر کل برنامه تاثیر نمی‌گذارد.
هیچ تعریف استانداردی برای اینکه چه مقدار کد یک "سرویس کوچک" را تشکیل می‌دهد وجود ندارد. تیم‌ها میتوانند هر میکروسرویس را مستقل از سایر خدمات مستقر در برنامه، ارتقا، مقیاس و راه‌اندازی مجدد کنند. این میکروسرویس‌ها معمولا توسط یک سیستم خودکار تنظیم می‌شوند و امکان به‌روزرسانی مکرر برنامه‌های کاربردی را در لحظه برای کاربران نهایی فراهم می‌کنند.
چه شرکت‌های بزرگی از میکروسرویس استفاده می‌کنند؟
در حال حاضر شرکت‌های معروفی مانند نتفلیکس، آمازون، اوبر، پی پال و محصولات نرم افزاری eBay بر روی میکروسرویس‌ها اجرا می‌شوند.
آمازون
آمازون روی هزاران میکروسرویس مانند سفارشات، ورود به سیستم، درگاه‌های پرداخت و…. کار می‌کند. میکروسرویس‌ها بر اساس قابلیت‌های تجاری مختلف ساخته شده‌اند. هر سرویس، داده‌ها و مدل داده خود را مدیریت می‌کند. جف بزوس، مدیر عامل آمازون قانون دو پیتزا را ایجاد کرد که اندازه ایده آل برای یک تیم میکروسرویس است. میکروسرویس‌های آمازون توسط تیم‌های دو پیتزا اداره می‌شوند، به این معنی که اندازه تیم نمی‌تواند بزرگ‌تر از اندازه دو پیتزا باشد. آمازون از قابلیت میکروسرویس‌ها برای ساخت و مدیریت یک سیستم انعطاف پذیر استفاده می‌کند.
نتفلیکس
نتفلیکس اولین شرکتی است که معماری میکروسرویس‌ها را در مقیاسی بزرگ پیاده سازی کرد. برنامه Netflix بیش از 2 میلیارد درخواست API را توسط بیش از 500 میکروسرویس مدیریت می‌کند. نتفلیکس تصمیم گرفت برای مقیاس پذیری به معماری میکروسرویس‌های مبتنی بر ابر حرکت کند. پیش از این، آنها قادر به استقرار مراکز داده نبودند. استفاده از میکروسرویس‌ها موجب شد تا افزایش تعداد کاربران، دیگر یک مشکل جدی نباشد.
اوبر
اوبر (Uber) توسعه برنامه خود را با استفاده از یک معماری یکپارچه آغاز کرد. اوایل کار، اجرای یک رویکرد یکپارچه برای توسعه برنامه‌های کاربردی در مقیاس کوچک کار ساده‌تری به نظر می‌رسید. اما زمانی که امکانات برنامه شروع به رشد کرد و ویژگی‌های جدیدی اضافه شد، اجزای مرتبط با هم استقرار را دشوار کردند. بنابراین، توسعه دهندگان تصمیم گرفتند که سیستم یکپارچه را به چندین سرویس (مانند مسافر، راننده، سفر، صورت‌حساب، پرداخت‌ها و اعلان‌ها) تقسیم کنند که هر کدام عملکرد خاص خود را دارند. هر کامپوننت از طریق REST API به یکدیگر متصل می‌شود، اما خرابی یا خطا در یک کامپوننت، هرگز بر عملکرد اجزای دیگر تاثیر نمی‌گذارد.
معماری میکروسرویس‌ها
معماری میکروسرویس نوعی زیرساخت کاربردی است که در آن یک راه حل شامل مجموعه‌ای از سرویس‌های مستقل قابل استقرار است که میتوانند به تنهایی اجرا شوند. جالب است بدانید که یک معماری میکروسرویس برای کار کردن به کیت‌های توسعه نرم افزار نیاز ندارد. در ادامه با ابزارهای توسعه میکروسرویس‌ها بیشتر آشنا خواهید شد.
API gateway
API gateway به عنوان یک سطح واسطه بین مشتریان و خدمات قرار گرفته، امنیت بیشتری را ارائه می‌کنند و درخواست‌های مشتریان را به میکروسرویس‌های مناسب هدایت می‌کنند. به عنوان مثال، Tyk یکی از مقیاس پذیرترین و امن‌ترین پلتفرم‌های مدیریت API بومی ابری است.
چه بخواهید از یک معماری یکپارچه به میکروسرویس‌ها مهاجرت کنید یا بخواهید آن را از ابتدا بسازید، این API متن باز به شما امکان می‌دهد هر زمان که برنامه شما نیاز داشته باشد، مقیاس را افزایش و کاهش دهید.
پایگاه داده
میکروسرویس‌ها میتوانند پایگاه داده یکسانی را به اشتراک بگذارند یا میتوانند پایگاه داده مستقل و ایزوله داشته باشند.
کانتینر
توسعه کانتینر (container) مناسب‌ترین راه برای اجرای میکروسرویس‌ها است. کانتینرها در اصل بسته‌هایی حاوی میکروسرویس هستند. آنها همچنین کد، وابستگی‌ها و کتابخانه‌ها را در خود جای می‌دهند. یک کانتینر برنامه‌ها را قادر می‌سازد تا به سرعت مقیاس پذیر شوند و به منابع سیستم کمتری نسبت به ماشین‌های مجازی نیاز داشته باشند. داکر (Docker) و کوبرنتیز (Kubernetes) فناوری‌های اصلی در مورد کانتینر سازی هستند. یک تفاوت عمده بین آنها این است که داکر قرار است روی یک گره اجرا شود، در حالی که کوبرنتیز در میان خوشه‌ها اجرا می‌شود. اگرچه مقایسه کوبرنتیز و داکر معمول است، اما به این معنی نیست که باید حتما یکی از این دو فناوری را انتخاب کنید؛ زیرا آنها میتوانند با هم کار کنند. داکر یک پلتفرم کانتینری برای توسعه و استقرار سریعتر برنامه‌ها است، در حالی که کوبرنتیز یک سازمان دهنده کانتینر برای پلتفرم‌هایی مانند داکر است. با پیاده سازی معماری میکروسرویس با هر دوی این فناوری‌ها، برنامه و زیرساخت خود را مقیاس پذیرتر و قوی‌تر می‌کنید.
جهت آشنایی بیشتر با کوبرنتیز، به صفحه دوره کوبرنتیز مراجعه کنید.
پیام رسانی
برای اینکه سرویس‌ها با هم همکاری کنند و درخواست‌های مشتریان را رسیدگی کنند، باید فناوری‌های پیام رسانی ناهمزمان را پیاده سازی کنید. آپاچی کافکا، یک پلتفرم جریان رویداد متن باز است که به شما امکان می‌دهد ارتباط بین میکروسرویس‌ها را مدیریت کرده، نتایج تولید شده را مقیاس بندی کنید و حجم زیادی داده را در یک خوشه ذخیره کنید. با کافکا، می‌توانید از جریان رویداد برای پردازش پرداخت‌ها در زمان واقعی، نگهداری داده‌های دستگاه‌های اینترنت اشیا و تجزیه و تحلیل تعاملات مشتری استفاده کنید.
ابزارهای بدون سرور
فناوری بدون سرور یکی از مهم‌ترین بخش‌های معماری میکروسرویس است . این فناوری فرآیند تجزیه یک برنامه واحد به چندین سرویس مستقل را بهینه می‌کند. میکروسرویس‌های بدون سرور فقط زمانی اجرا می‌شوند که مورد نیاز باشند و میتوانند به تعدادی عملکرد کوچکتر تقسیم شوند.
Iron Functions یک پلتفرم محاسباتی بدون سرور است که از توابع زیادی در هر زبان برنامه نویسی پشتیبانی می‌کند و می‌تواند به راحتی در برنامه شما پیاده سازی شود. پس از اجرای Iron Functions، فقط باید زیرساخت و پردازش کار خود را راه اندازی کنید. ادغام با ابزارهایی مانند کوبرنتیز و داکر روند توسعه را بسیار سرعت می‌بخشد.
مزایای میکروسرویس
در یک معماری یکپارچه، همه اجزای نرم افزار به هم پیوسته و وابسته هستند. اگر هر یک از مؤلفه‌ها یا عملکردهای جزیی از کار بیفتند، ممکن است برنامه به طور کامل از کار بیفتد. تصور کنید یک برنامه تحت وب دارید که شامل عملکردهایی مانند پرداخت، نگهداری تاریخچه تراکنش‌ها و ورود به سیستم است. حال اگر بخش "تاریخچه" حافظه بیشتری مصرف کند، احتمالا کل برنامه دچار مشکل می‌شود. استفاده از میکروسرویس‌ها کمک می‌کند تا چنین مشکلاتی به وجود نیاید. در ادامه برخی از مزایای معماری میکروسرویس‌ها آورده شده است:
اجزای ایزوله
معماری میکروسرویس‌ها به توسعه دهندگان اجازه می‌دهد تا سرویس‌های آزادی را ایجاد کنند که میتوانند به صورت جداگانه توسعه یابند، اصلاح شوند و مقیاس شوند.
قابلیت تغییر آسان فناوری
برخلاف معماری یکپارچه، فناوری مادر را می‌توان بدون تداخل با سایر خدمات تغییر داد. تیم‌های توسعه میتوانند یک پشته جدید برای هر میکروسرویس انتخاب کنند.
سازماندهی شده برای قابلیت‌های تجاری
میکروسرویس‌ها توسعه دهندگان را قادر می‌سازند تا به جای پروژه‌ها، محصولات بسازند. تیم توسعه می‌تواند به جای نوشتن کد از ابتدا، بر توسعه عملکردهای تجاری تاکید کند. علاوه بر این، همان سرویس را می‌توان در بیش از یک برنامه مورد استفاده مجدد قرار داد. به عنوان مثال، یک میکروسرویس برای مدیریت ورود می‌تواند در هر برنامه SaaS مورد استفاده مجدد قرار گیرد.
تیم‌های متقابل و مستقل
اگر تیم‌های گسترده یا بخش‌های متعددی در سراسر جهان دارید، توسعه یک برنامه پیچیده یکپارچه می‌تواند یک کار پیچیده باشد. میکروسرویس‌ها به توسعه دهندگان این امکان را می‌دهند که به طور مستقل کار کنند و به طور مستقل تغییراتی را ایجاد کنند.
افزایش سرعت توسعه
میکروسرویس‌ها فرآیند توسعه را موازی می‌کنند و در نتیجه چرخه تولید را به طور تصاعدی سرعت می‌بخشند. تیم‌های مختلف میتوانند بدون اینکه منتظر بمانند تیم دیگری بخشی از کار را به پایان برساند، به کار روی اجزای مختلف ادامه دهند.
شناسایی ساده‌تر خطا
همانطور که اشاره کردیم، خرابی یا عیب در یک میکروسرویس بر عملکرد میکروسرویس‌های دیگر در یک برنامه کاربردی تاثیر نمی‌گذارد. علاوه بر آن با استفاده از میکروسرویس‌ها، می‌توان تلاش‌های لازم برای کشف خطا یا کندی در برنامه را کاهش داد.
درک آسان
هر میکروسرویس دارای یک کد کوچکتر و کم حجم‌تر است که موجب می‌شود تا درک آن آسان‌تر شود.
توسعه مستقل معماری
این کار موجب می‌شود تا تیم‌های کوچک به طور مستقل خدمات مربوطه خود را توسعه، استقرار و مقیاس‌بندی کنند. این فعال سازی به توسعه دهندگان بیشتری اجازه می‌دهد تا روی پایگاه‌های کد کوچکتری کار کنند و حجم کار کاهش پیدا می‌کند.
ترویج تحویل مستمر
استفاده از میکروسرویس‌ها مراجعه به دواپس (DevOps)، یکپارچه‌سازی پیاپی، تحویل مداوم (CI/CD) و کانتینرها را تسهیل می‌کند. در این صورت نیازی به استقرار کد به طور همزمان مانند توسعه دهندگان در یک محیط یکپارچه نخواهد بود. این ویژگی به‌روزرسانی‌ها را مکرر و سریع می‌کند و CI/CD را فعال می‌کند.
خلاقیت بیشتر
توسعه‌دهندگان میتوانند از زبان‌های برنامه‌نویسی، پشته‌های فناوری و چارچوب‌های مختلف برای مؤلفه‌های مختلف استفاده کنند و هر سرویس را به‌طور مستقل اجرا کنند.
چالش‌های استفاده از میکروسرویس
علاوه بر مزایای قابل توجه معماری میکروسرویس‌ها، معایب خاصی وجود دارد که تیم توسعه ممکن است در هنگام ساخت برنامه‌های کاربردی با استفاده از میکروسرویس‌ها با آنها مواجه شود. بیایید چالش‌های موجود را درک کنیم و ببینیم چگونه می‌توانیم آن را حل کنیم.
ردیابی
در حین حرکت از معماری یکپارچه به ریز سرویس‌ها، ردیابی می‌تواند بسیار دشوار شود. اگر به‌روزرسانی‌های انجام‌شده در یک سرویس، سایر سرویس‌های برنامه را تحت تاثیر قرار دهد، ردیابی تاثیر درخواستی که بر سرویس‌های دیگر ارائه شده است، زمان زیادی می‌برد.
برای غلبه بر مشکلات ردیابی بهتر است سوابق لاگ‌ها نگهداری شود. نگه داشتن گزارش‌ها به توسعه دهندگان کمک می‌کند تا مشکلات را به سرعت پیدا کنند. از طرفی اگر توسعه‌دهندگان از زبان‌های برنامه‌نویسی مختلف برای ساخت سرویس‌های مختلف استفاده کنند، ممکن است هنگام ردیابی سرویس‌ها برای رفع مشکلات، آنها را منحرف کند. راه دیگر برای غلبه بر مشکل این است که هنگام ساخت یک برنامه با استفاده از میکروسرویس، به یک زبان برنامه نویسی پایبند باشید.
استانداردهای ورود به سیستم
میکروسرویس‌ها بر روی سرورهای متعددی اجرا می‌شوند. بنابراین، توسعه‌دهندگان ممکن است نیاز داشته باشند که خدمات مختلفی را که روی ماشین‌های مختلف اجرا می‌شوند، برای اجرای یک سیستم مشترک مدیریت کنند. این باعث می‌شود که پیام‌های گزارش تولید شده توسط میکروسرویس‌ها بین چندین میزبان توزیع شوند. برای عیب‌یابی هر مشکلی، یک توسعه دهنده باید به سرورهای مختلف رفته و همه لاگ‌ها را جستجو کند، که فرآیندی دست و پا گیر و زمان‌بر است.
توصیه می‌شود که لاگ‌های تولید شده بین چندین سرور توزیع نشوند. در عوض، بهتر است گزارش‌ها را به یک مکان مرکزی و خارجی ارسال کنید. توسعه دهندگان میتوانند به راحتی اطلاعات گزارش را از یک مکان دریافت کنند. اگر توسعه دهندگان از محیط AWS برای میزبانی برنامه‌ها استفاده کنند، ارائه دهندگان ابر مانند CloudWatch خدماتی را برای ذخیره و نظارت بر گزارش‌ها ارائه می‌دهند.
امنیت
در یک برنامه یکپارچه، فرایندها به صورت محلی با یکدیگر ارتباط برقرار می‌کنند. اما یک برنامه کاربردی که با استفاده از معماری میکروسرویس ساخته شده است دارای چندین سرویس پراکنده در یک محیط چند ابری است. هر رویکرد خاصی که باید از طریق APIها به صورت خارجی ارتباط برقرار کند، ریسک حملات را افزایش می‌دهد، به خصوص اگر مکانیسم امنیتی مناسب در هنگام ساخت برنامه‌ها اجرا نشود.
اجرای احراز هویت یا اعتبار سنجی برای فراخوانی‌های API می‌تواند خطرات امنیتی را به حداقل برساند. استفاده از SHA-256 و SSL به عنوان یک لایه امنیتی برای سرویس هایی که به صورت خارجی با رابط مشتری ارتباط برقرار می‌کنند می‌تواند به جلوگیری از حملات امنیتی کمک کند.
مصرف مازاد منابع
اگرچه شعار میکروسرویس‌ها استفاده کارآمد از منابع است، با این حال استفاده از آنها می‌تواند با رشد خدمات، مصرف منابع را نیز افزایش دهند. هر میکروسرویس به منابع خاص خود نیاز دارد و این موضوع ممکن است استفاده از CPU و ذخیره سازی را افزایش دهد.
زبان برنامه نویسی
از آنجایی که معماری میکروسرویس به توسعه دهندگان اجازه می‌دهد تا به طور مستقل یک سیستم یا برنامه را ایجاد کنند، برنامه نویسان ترجیح می‌دهند از زبان‌های برنامه نویسی مختلف برای پیاده سازی خدمات مختلف استفاده کنند. استفاده از سبک‌های مختلف استقرار را بسیار دشوار می‌کند. علاوه بر آن، تغییر و جایگزینی توسعه دهندگان در هر مرحله از توسعه دشوار می‌شود. اگر توسعه دهندگان برای همه سرویس‌ها به یک زبان برنامه نویسی پایبند باشند، فرآیند استقرار کارآمدتر می‌شود.
هزینه بالا
راه‌حل‌های مبتنی بر میکروسرویس‌ها پرهزینه‌تر از رویکرد یکپارچه هستند، زیرا میکروسرویس‌ها از طریق API کار می‌کنند و اغلب به پردازنده‌های مرکزی خود نیاز دارند. بسته به اهداف و دامنه پروژه خود، ممکن است برای ساخت میکروسرویس‌ها به یک تیم اختصاصی از توسعه دهندگان باتجربه نیاز داشته باشید که فرآیند توسعه را گران‌تر می‌کند.
طراحی رابط کاربری (UI)
هر سرویسی برای ارائه اطلاعاتی که باید به کاربر نمایش داده شود متفاوت عمل می‌کند. اضافه کردن کد بیشتر در سمت کلاینت برای پاس دادن داده‌ها در ویو ممکن است یک کار پیچیده باشد و می‌تواند عملکرد برنامه را کند کند، به خصوص اگر داده‌ها در حجم فوق‌العاده باشند. برای غلبه بر مشکل، توسعه دهندگان میتوانند یک لایه بین سرویس‌ها و بخش کلاینت (مشتری) اضافه کنند. این لایه به عنوان یک سرویس عمل می‌کند که عناصر UI را برای همه نماهای برنامه آماده می‌کند.
ارتباط بین میکروسرویس‌ها
وقتی کاربر درخواستی را از طریق پروتکل HTTP ارسال می‌کند، در ازای آن پاسخی دریافت می‌کند. اگر این پاسخ به تعامل بین میکروسرویس‌ها از طریق HTTP وابسته باشد، ممکن است منجر به زمان پاسخ بالاتر شود. استفاده از تماس شبکه مانند AMQP (پروتکل صف پیشرفته پیام) به جای REST API برای ارتباط داخلی بین میکروسرویس‌ها می‌تواند زمان پاسخگویی را به حداقل برساند.
فرمت گزارشات
هر سرویس لاگ‌های خود را با فرمت‌های مختلف نگهداری می‌کند. مدیریت گزارش‌های مختلف، موجب دشواری ردیابی مشکلات برای توسعه دهندگان می‌شود. اغلب توصیه می‌شود فرمت‌های گزارش را برای همه سرویس‌ها استاندارد کنید. به عنوان مثال، استفاده از یک requestID برای همه گزارش‌های مربوط به یک درخواست در همه سرویس‌ها، می‌تواند درک و ردیابی گزارش‌ها را برای توسعه‌دهندگان آسان‌تر کند.
چه زمانی باید از میکروسرویس‌ها استفاده کرد؟
ایوب ایرازه، مهندس نرم افزار در شیپور و مهندس نرم افزار سابق شرکت اسنپ فود در مجموعه ویدیوهای تجربه طلایی، به مسئله میکروسرویس‌ها، مزایا و معایبی که دارند و همچنین چگونگی استفاده از آن پرداخته است که توصیه می‌کنیم دیدن این ویدیو را از دست ندهید. علاوه بر آن، گاهی اوقات یک ساختار یکپارچه ممکن است بهترین راه حل باشد، اما همانطور که گفتیم معماری میکروسرویس نیز در حال رشد است. از خود بپرسید:
برنامه‌های من در چه محیطی کار می‌کنند؟
از آنجایی که بیشتر معماری‌های بومی ابری برای میکروسرویس‌ها طراحی شده‌اند، اگر می‌خواهید از مزایای کامل یک محیط بومی ابری بهره‌مند شوید، میکروسرویس‌ها یکی از مناسب‌ترین راه حل‌ها هستند. با حرکت برنامه‌ها به سمت ابری شدن، توسعه برنامه‌ها از معماری میکروسرویس‌ها حمایت می‌کند و به حرکت رو به جلو ادامه خواهد داد.
تیم شما چگونه کار می‌کند؟
در معماری میکروسرویس، بخش کد اغلب می‌تواند توسط چند تیم‌های کوچکتر مدیریت شود. با این حال، تیم‌های توسعه به ابزارهایی برای شناسایی، نظارت و اجرای فعالیت اجزای مختلف (از جمله اینکه آیا و چگونه با یکدیگر تعامل دارند) نیاز دارند. تیم‌ها همچنین باید تعیین کنند که کدام سرویس‌ها قابل استفاده مجدد هستند تا مجبور نباشند هنگام ساخت یک سرویس جدید از ابتدا شروع کنند.
برنامه‌های کاربردی شما چقدر انعطاف پذیر هستند؟
اگر مجبور هستید به طور مداوم برنامه خود را تغییر دهید یا تنظیماتی را انجام دهید، استفاده از میکروسرویس‌ها بهترین راه است؛ زیرا می‌توانید به جای کل سیستم، تنها بخشی از آن را ویرایش کنید.
چند سرویس دارید و آیا بیشتر خواهد شد؟
اگر سرویس‌های زیادی دارید یا قصد دارید آنها را بیشتر کنید (به خصوص در یک پلتفرم مبتنی بر ابر) معماری میکروسرویس ایده آل است، زیرا نرم افزار کاربردی یکپارچه قابلیت مقیاس پذیری کمتری دارند.
جمع بندی
در این مقاله تلاش کردیم تا مفاهیم مقدماتی در مورد میکروسرویس‌ها را توضیح دهیم. بسیاری از تصمیمات تجاری و فرآیندی در استفاده از معماری مبتنی بر میکروسرویس‌ها دخیل هستند. با این وجود، در حال حاضر بسیاری از شرکت‌ها معتقد هستند که میکروسرویس‌ها بهترین گزینه هستند. اگر نظر یا سوالی در کار با میکروسرویس‌ها دارید، خوش حال می‌شویم آن را با ما و سایر کاربران سون لرنی به اشتراک بگذارید.