معماری میکروسرویس‌ها: مفاهیم، محرک‌ها و الگوهای پیاده‌سازی

1. مقدمه و مرور کلی

این محتوا برگرفته از یک قسمت از پادکست رادیو مهندسی نرم‌افزار (قسمت ۲۱۳) است که شامل گفت‌وگویی بین یوهانس تونز و جیمز لوئیس در مورد موضوع میکروسرویس‌ها می‌باشد. این گفت‌وگو به بررسی تعریف، انگیزه‌ها و ملاحظات عملی پیرامون این سبک معماری می‌پردازد که در اوایل سال ۲۰۱۵ به عنوان پاسخی به چالش‌های نگهداری برنامه‌های یکپارچه و بزرگ، در حال جلب توجه قابل توجهی بود.

2. تعریف میکروسرویس‌ها

یک میکروسرویس به عنوان یک مؤلفه کوچک و متمرکز برنامه در نظر گرفته می‌شود.

3. ظهور میکروسرویس‌ها

4. الگوهای پذیرش و پیاده‌سازی

5. بینش‌های کلیدی و تحلیل

6. چارچوب فنی و مدل‌های ریاضی

در حالی که پادکست گفت‌وگویی است، اصول زیربنایی را می‌توان صوری کرد. یک مدل کلیدی، رابطه بین اندازه تیم (N)، مسیرهای ارتباطی و پیوندگی معماری است.

در یک معماری یکپارچه با N تیم، مسیرهای ارتباطی بالقوه با $O(N^2)$ مقیاس می‌یابند، زیرا تغییرات در یک ماژول می‌تواند بر بسیاری دیگر تأثیر بگذارد. این امر سربار هماهنگی ایجاد می‌کند. میکروسرویس‌ها با اعمال زمینه‌های محدود و API‌ها هدف کاهش این امر را دارند. هدف این است که هزینه ارتباط بین سرویس‌ها، $C_{comm}$، از طریق فراخوانی‌های شبکه به صراحت بالا برود، در نتیجه مدولاریتی قوی درون یک سرویس تشویق شود که هزینه تغییر، $C_{internal}$، در آن پایین است.

یک مدل ساده شده برای احتمال انتشار تغییر ($P_{prop}$) می‌تواند به این صورت باشد:

$P_{prop} \approx \frac{C_{comm}}{C_{comm} + C_{internal}}$

جایی که یک معماری میکروسرویس خوب طراحی شده، $P_{prop}$ را برای تغییرات نامرتبط با تبدیل کردن $C_{comm}$ (تأخیر شبکه، نسخه‌بندی API) به عامل غالب برای تغییرات فرامرزی، به حداقل می‌رساند.

7. نتایج تجربی و مطالعات موردی

پادکست نتفلیکس را به عنوان یک مطالعه موردی اولیه ذکر می‌کند. تا سال ۲۰۱۵، نتفلیکس به طور مشهوری بک‌اند یکپارچه خود را به صدها میکروسرویس تجزیه کرده بود که امکان موارد زیر را فراهم می‌کرد:

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

توضیح نمودار (فرضی): یک نمودار میله‌ای که یک برنامه یکپارچه را با یک معماری میکروسرویس در دو محور مقایسه می‌کند: (۱) فرکانس استقرار (استقرار/روز): برنامه یکپارچه یک میله پایین نشان می‌دهد (مثلاً ۰.۱)، میکروسرویس‌ها یک میله بالا نشان می‌دهند (مثلاً ۵۰+). (۲) میانگین زمان بازیابی (MTTR) از یک خرابی: برنامه یکپارچه یک میله بالا نشان می‌دهد (مثلاً ۴ ساعت)، میکروسرویس‌ها یک میله پایین‌تر نشان می‌دهند (مثلاً ۳۰ دقیقه)، زیرا خرابی‌ها می‌توانند به سرویس‌های خاصی محدود شوند.

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

8. چارچوب تحلیل: یک مثال عملی

سناریو: یک برنامه یکپارچه تجارت الکترونیک با به‌روزرسانی‌ها دست و پنجه نرم می‌کند. تغییرات ویژگی «پرداخت» نیاز به آزمون رگرسیون کامل دارد و با به‌روزرسانی‌های «کاتالوگ محصول» در تضاد است.

کاربرد چارچوب:

1. شناسایی زمینه‌های محدود: با استفاده از طراحی مبتنی بر دامنه، دامنه‌های اصلی را شناسایی کنید: سفارش‌دهی، کاتالوگ، موجودی، مدیریت کاربر، پرداخت.
2. تعریف مرزهای سرویس: برای هر زمینه یک میکروسرویس ایجاد کنید. سرویس سفارش مالک منطق پرداخت و داده‌های سفارش است.
3. ایجاد قراردادها: APIهای واضح تعریف کنید. سرویس سفارش، API processPayment(orderId, amount) سرویس پرداخت و API reserveStock(itemId, quantity) سرویس موجودی را فراخوانی خواهد کرد.
4. مالکیت داده: هر سرویس مالک پایگاه داده خود است. سرویس سفارش جدول «سفارشات» خود را دارد؛ به طور مستقیم از پایگاه داده موجودی پرس و جو نمی‌کند.
5. استقرار و قابلیت مشاهده: هر سرویس کانتینریزه شده، به طور مستقل مستقر می‌شود و معیارها (تأخیر، نرخ خطا) را به یک داشبورد مرکزی ارسال می‌کند.

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

9. کاربردهای آینده و جهت‌های پژوهشی

تکامل میکروسرویس‌ها فراتر از دیدگاه سال ۲۰۱۵ ادامه دارد:

• مش‌های سرویس: فناوری‌هایی مانند Istio و Linkerd برای رسیدگی به نگرانی‌های فرامرزی (امنیت، قابلیت مشاهده، مدیریت ترافیک) در لایه زیرساخت ظهور کرده‌اند که بار کد بر سرویس‌های فردی را کاهش می‌دهند.
• سرورلس و FaaS: سرویس‌های تابع‌محور (مانند AWS Lambda) نمایانگر شکل افراطی میکروسرویس‌ها هستند که پیچیدگی عملیاتی را کاملاً به ارائه‌دهنده ابر منتقل می‌کنند و امکان مقیاس‌پذیری حتی ریزدانه‌تر را فراهم می‌کنند.
• ادغام هوش مصنوعی/یادگیری ماشین: میکروسرویس‌ها در حال تبدیل شدن به الگوی پذیرفته شده برای استقرار مدل‌های ML به عنوان سرویس‌های پیش‌بینی مستقل هستند که امکان آزمون A/B و تکرار سریع الگوریتم‌ها را فراهم می‌کنند.
• رایانش لبه: استقرار میکروسرویس‌های سبک‌وزن روی دستگاه‌های لبه برای پردازش کم‌تأخیر در سناریوهای اینترنت اشیا و تحلیل‌های بلادرنگ.
• تمرکز پژوهشی: پژوهش‌های آینده در ابزارهای تجزیه خودکار سرویس، پیش‌بینی هوشمند خطا در سیستم‌های توزیع‌شده و تأیید صوری تعاملات در رقص‌های سرویس مورد نیاز است.

10. منابع

1. Lewis, J., & Fowler, M. (2014). Microservices. MartinFowler.com. Retrieved from https://martinfowler.com/articles/microservices.html
2. Newman, S. (2015). Building Microservices. O'Reilly Media.
3. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
4. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28-31.
5. Google Cloud. (2019). The 2019 Accelerate State of DevOps Report. DORA.
6. Netflix Technology Blog. (Various). https://netflixtechblog.com/