مایکروسرویس‌ها

در رایانش، مایکروسرویس‌ها (Micro به معنای بسیار کوچک است) نوعی الگوی معماری است که در آن برنامه‌های پیچیده به بخش‌های کوچک و مستقلی شکسته می‌شوند که از طریق APIهای مستقل از زبان با هم در ارتباط هستند. این سرویس‌ها کوچک هستند و سطح بسیار خوبی از استقلال را دارند (یعنی جدا شده یا decoupled هستند). به علاوه تمرکز هر یک بر روی انجام یکی از آن کارهای کوچک است.

معرفی معماری میکروسرویس‌ها

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

تفاوت با معماری یکپارچه (Monolithic)

در معماری یکپارچه، تمامی ماژول‌ها وابسته به یکدیگر هستند و به یکدیگر متصل‌اند. اما در معماری میکروسرویس‌ها:

• هر سرویس به صورت مستقل توسعه و استقرار می‌یابد.
• سرویس‌ها می‌توانند با زبان‌های برنامه‌نویسی متفاوت نوشته شوند.
• ارتباط بین سرویس‌ها معمولاً از طریق پروتکل‌های سبک (مانند REST API یا gRPC) صورت می‌گیرد.

جزئیات

ویژگی‌های معماری مایکروسرویس‌ها عبارت است از:

• سرویس‌ها را به راحتی می‌توان جایگزین کرد.
• سرویس‌ها حول قابلیت‌ها شکل می‌گیرند، مثلاً در رابطه با واسط کاربری، محصولات مشابه و توصیه شده با کاربر وب، صورت حساب و …
• سرویس‌ها را می‌توان با زبان‌های برنامه‌نویسی، پایگاه‌داده‌ها، محیط سخت‌افزاری و نرم‌افزاری مختلف و متعددی پیاده‌سازی کرد. انتخاب هر یک بستگی به کاربرد و مسئلهٔ مورد نظر دارد.
• معماری مبتنی بر مایکروسرویس‌ها:
  • بر یک روند توسعهٔ نرم‌افزاری تکیه دارد که در آن ارائهٔ پیوسته (continuous delivery) اهمیت دارد.
  • متفاوت از معماری SOA یا همان معماری سرویس محور است. زیرا که در SOA تلاش برای یکپارچه سازی چندین برنامهٔ کاربردی است در حالی که چندین مایکروسرویس تنها متعلق به یک برنامه هستند.

فلسفه

فلسفهٔ معماری مبتنی بر مایکروسرویس‌ها:

• سرویس‌ها کوچکند و به اندازهٔ کافی ریزدانه هستند (fine grained) ولی نه ریزتر به گونه‌ای که یک هدف تجاری و کاربردی خاص را انجام می‌دهند. این روند شبیه فلسفهٔ Unix است که تلاش می‌کند که «یک چیز را انجام دهد و فقط آن را به خوبی انجام دهد».
• فرهنگ سازمان باید خودکار سازی deployment و تست نرم‌افزار را مشتاقانه بپذیرد زیرا که در این معماری نیاز به چنین رویکردی وجود دارد. به این ترتیب بار از روی مدیریت، مدیران سیستمی و اجرائیات برداشته می‌شود.
• فرهنگ و الگوهای طراحی باید فرهنگ حل شکست و خطا داشته باشند و پیوسته در راستای بهبود سرویس‌ها تلاش کنند.
• سرویس‌ها باید منعطف، واکنش‌گر، با قابلیت ترکیب شدن با بقیهٔ سرویس‌ها، و در انجام تک وظیفه‌ای که دارند کامل باشند.

مزایای استفاده از معماری میکروسرویس‌ها

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

انتقاد

معماری مایکروسرویس‌ها به خاطر برخی دلایل مورد انتقاد قرار گرفته است:

• سرویس‌ها گونه‌ای از موانع برای اطلاعات ایجاد می‌کنند.
• این معماری پیچیدگی مضاعفی ایجاد می‌کند و مشکلات جدیدی همچون تأخیر در شبکه، قالب پیغام‌ها، تقسیم بار و قابلیت تحمل خطابه وجود می‌آورد. نادیده گرفتن هر یک از این‌ها منجر به مشکلاتی می‌شود که در «خطاهای مربوط به پردازش توزیع شده» آمده است.
• تست کردن و بردن به محیط عملیاتی (deployment) پیچیده‌تر است.
• پیچیدگی برنامهٔ monolithic به شبکه‌ای از مایکروسرویس‌ها منتقل شده است، ولی همچنان وجود دارد:
  • شما می‌توانید آن را جابه‌جا کنید، ولی آن همچنان وجود دارد. -- رابرت آنت: پیچیدگی کجاست؟

چالش‌ها و محدودیت‌ها

1. پیچیدگی مدیریت سیستم معماری میکروسرویس‌ها به ابزارها و روش‌های پیشرفته برای مدیریت نیاز دارد. مانیتورینگ، مدیریت استقرار و اطمینان از ارتباط صحیح بین سرویس‌ها چالش‌برانگیز است.
2. هزینه‌های زیرساختی میکروسرویس‌ها نیازمند زیرساخت‌هایی مانند Docker و Kubernetes هستند که ممکن است در مقیاس کوچک هزینه‌بر باشد.
3. ارتباط بین سرویس‌ها به دلیل تعداد بالای سرویس‌ها، اطمینان از ارتباط سریع و مطمئن بین آن‌ها از اهمیت ویژه‌ای برخوردار است.

ابزارها و فناوری‌های مرتبط

1. Docker یک پلتفرم برای ایجاد و مدیریت کانتینرها که برای استقرار سریع و آسان سرویس‌ها استفاده می‌شود.
2. Kubernetes سیستمی برای مدیریت کانتینرها در مقیاس بزرگ که به طور گسترده در معماری میکروسرویس‌ها استفاده می‌شود.
3. Spring Boot یک فریم‌ورک قدرتمند برای توسعه سرویس‌های مستقل در زبان Java.
4. Prometheus و Grafana ابزارهایی برای مانیتورینگ و نمایش وضعیت سرویس‌ها.

زبان‌های برنامه‌نویسی

• زبان Jolie به منظور توسعهٔ برنامه‌های توزیع شده مبتنی بر مایکروسرویس‌ها طراحی شده است.
• Vert.X یک چارچوب توسعهٔ برنامهٔ مبتنی بر رویداد و چند زبانی (polyglot) است که بر روی JVM اجرا می‌شود.

کاربردها و نمونه‌های عملی

1. شرکت Netflix Netflix از معماری میکروسرویس‌ها برای ارائه خدمات استریم استفاده می‌کند و هر سرویس مسئول بخشی از عملکرد سیستم است.
2. Amazon Amazon با استفاده از میکروسرویس‌ها توانسته است به صورت مؤثری مقیاس‌پذیری و انعطاف‌پذیری در تجارت الکترونیکی ایجاد کند.

نمونه کد

یک مثال ساده از یک سرویس مستقل در Spring Boot:

@RestController
@RequestMapping("/users")
public class UserController {
    
    @GetMapping("/{id}")
    public ResponseEntity<User> getUser(@PathVariable Long id) {
        User user = userService.getUserById(id);
        return ResponseEntity.ok(user);
    }
}

این کد نشان می‌دهد چگونه می‌توان یک سرویس ساده برای مدیریت کاربران ایجاد کرد. این سرویس می‌تواند به صورت مستقل مستقر شود.

نتیجه‌گیری

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

منابع

• مشارکت‌کنندگان ویکی‌پدیا. «Microservices». در دانشنامهٔ ویکی‌پدیای انگلیسی، بازبینی‌شده در ۲۵ ژوئن ۲۰۱۵.