مایکروسرویس‌ها
در رایانش، مایکروسرویس‌ها (Micro به معنای بسیار کوچک است) نوعی الگوی معماری است که در آن برنامه‌های پیچیده به بخش‌های کوچک و مستقلی شکسته می‌شوند که از طریق APIهای مستقل از زبان با هم در ارتباط هستند.[۱] این سرویس‌ها کوچک هستند و سطح بسیار خوبی از استقلال را دارند (یعنی جدا شده یا decoupled هستند). به علاوه تمرکز هر یک بر روی انجام یکی از آن کارهای کوچک است.[۲]
جزئیات[ویرایش]
ویژگی‌های معماری مایکروسرویس‌ها عبارت است از:
- سرویس‌ها را به راحتی می‌توان جایگزین کرد.
- سرویس‌ها حول قابلیت‌ها شکل می‌گیرند، مثلاً در رابطه با واسط کاربری، محصولات مشابه و توصیه شده با کاربر وب، صورت حساب و …
- سرویس‌ها را می‌توان با زبان‌های برنامه‌نویسی، پایگاه‌داده‌ها، محیط سخت‌افزاری و نرم‌افزاری مختلف و متعددی پیاده‌سازی کرد. انتخاب هر یک بستگی به کاربرد و مسئلهٔ مورد نظر دارد.
- معماری مبتنی بر مایکروسرویس‌ها:
- بر یک روند توسعهٔ نرم‌افزاری تکیه دارد که در آن ارائهٔ پیوسته (continuous delivery) اهمیت دارد.
- متفاوت از معماری SOA یا همان معماری سرویس محور است. زیرا که در SOA تلاش برای یکپارچه سازی چندین برنامهٔ کاربردی است در حالی که چندین مایکروسرویس تنها متعلق به یک برنامه هستند.
فلسفه[ویرایش]
فلسفهٔ معماری مبتنی بر مایکروسرویس‌ها:
- سرویس‌ها کوچکند و به اندازهٔ کافی ریزدانه هستند (fine grained) ولی نه ریزتر به گونه‌ای که یک هدف تجاری و کاربردی خاص را انجام می‌دهند. این روند شبیه فلسفهٔ Unix است که تلاش می‌کند که «یک چیز را انجام دهد و فقط آن را به خوبی انجام دهد».
- فرهنگ سازمان باید خودکار سازی deployment و تست نرم‌افزار را مشتاقانه بپذیرد زیرا که در این معماری نیاز به چنین رویکردی وجود دارد. به این ترتیب بار از روی مدیریت، مدیران سیستمی و اجرائیات برداشته می‌شود.
- فرهنگ و الگوهای طراحی باید فرهنگ حل شکست و خطا داشته باشند و پیوسته در راستای بهبود سرویس‌ها تلاش کنند.
- سرویس‌ها باید منعطف، واکنش‌گر، با قابلیت ترکیب شدن با بقیهٔ سرویس‌ها، و در انجام تک وظیفه‌ای که دارند کامل باشند.[۳][۴][۵]
انتقاد[ویرایش]
معماری مایکروسرویس‌ها به خاطر برخی دلایل مورد انتقاد قرار گرفته است:
- سرویس‌ها گونه‌ای از موانع برای اطلاعات ایجاد می‌کنند.[۶]
- این معماری پیچیدگی مضاعفی ایجاد می‌کند و مشکلات جدیدی همچون تأخیر در شبکه، قالب پیغام‌ها، تقسیم بار و قابلیت تحمل خطا[۷]به وجود می‌آورد. نادیده گرفتن هر یک از این‌ها منجر به مشکلاتی می‌شود که در «خطاهای مربوط به پردازش توزیع شده» آمده است.
- تست کردن و بردن به محیط عملیاتی (deployment) پیچیده‌تر است.
- پیچیدگی برنامهٔ monolithic به شبکه‌ای از مایکروسرویس‌ها منتقل شده است، ولی همچنان وجود دارد:
- شما می‌توانید آن را جابه‌جا کنید، ولی آن همچنان وجود دارد. -- رابرت آنت: پیچیدگی کجاست؟
زبان‌های برنامه‌نویسی[ویرایش]
- زبان Jolie به منظور توسعهٔ برنامه‌های توزیع شده مبتنی بر مایکروسرویس‌ها طراحی شده است.[۸]
- Vert.X یک چارچوب توسعهٔ برنامهٔ مبتنی بر رویداد و چند زبانی (polyglot) است که بر روی JVM اجرا می‌شود.[۹]
کاربران[ویرایش]
منابع[ویرایش]
- ↑ Martin Fowler. "Microservices".
- ↑ Sam Newman (2015). Building Microservices. ISBN 978-1-4919-5035-7.
- ↑ Lucas Krause. Microservices: Patterns and Applications. ASIN B00VJ3NP4A.
- ↑ Lucas Krause. "Philosophy of Microservices?". Archived from the original on 12 November 2016. Retrieved 26 June 2015.
- ↑ Jim Bugwadia. "Microservices: Five Architectural Constraints".
- ↑ Jan Stenberg (11 August 2014). "Experiences from Failing with Microservices".
- ↑ ۷٫۰ ۷٫۱ ۷٫۲ "Microservices" (PDF).[پیوند مرده]
- ↑ "Jolie".
- ↑ "Vertx".
- مشارکت‌کنندگان ویکی‌پدیا. «Microservices». در دانشنامهٔ ویکی‌پدیای انگلیسی، بازبینی‌شده در ۲۵ ژوئن ۲۰۱۵.