آموزش ۵۰۰+ سوال و جواب مصاحبه میکروسرویس سال ۲۰۲۶ - آخرین آپدیت

پوشش دقیق حوزه‌های آزمون

این بانک سوالات جامع دقیقاً با شایستگی‌های معماری، عملیاتی و طراحی مورد نیاز در مصاحبه‌های سطح بالای طراحی سیستم (System Design) و مهندسی بک‌اند مطابقت دارد.

• مبانی میکروسرویس‌ها (۲۰٪): معماری اصلی میکروسرویس، کشف سرویس (Service Discovery) در سمت کلاینت و سرور، الگوهای API Gateway، توزیع هوشمند بار (Load Balancing) و پروتکل‌های ارتباطی همگام و ناهمگام.

• ارتباطات سرویس و مدیریت داده‌ها (۱۸٪): طراحی APIهای RESTful تاب‌آور، صف‌های پیام با نرخ انتقال بالا، معماری رویداد-محور (Event-Driven)، تکامل طرحواره در سریال‌سازی داده‌ها و پارادایم‌های ذخیره‌سازی توزیع‌شده (الگوی Database-per-service).

• تاب‌آوری و تحمل خطا (۱۵٪): پیاده‌سازی Circuit Breakers توزیع‌شده، مکانیزم‌های تلاش مجدد هوشمند (Retry)، جایگزین‌های تطبیقی (Fallbacks)، ایزولاسیون تردها از طریق Bulkheads و کاهش تدریجی خدمات.

• امنیت و احراز هویت (۱۲٪): جریان‌های تفویض OAuth2 سازمانی، مدیریت و اعتبارسنجی امن JWT، استراتژی‌های Token Relay بدون وضعیت، کنترل دسترسی دقیق (Fine-grained) و رمزنگاری سرتاسری داده‌ها (در حال انتقال و در حالت استراحت).

• استقرار و مانیتورینگ (۱۰٪): کانتینری‌سازی تغییرناپذیر (Immutable)، ارکستراسیون در مقیاس تولید، استقرار مستمر با زمان توقف صفر (Zero-downtime)، ردیابی توزیع‌شده (Distributed Tracing)، لاگینگ متمرکز و مانیتورینگ جامع زیرساخت.

• الگوها و اصول طراحی (۸٪): به‌کارگیری اصول SOLID در طراحی اجزا، پیروی از متدولوژی‌های 12-Factor Apps، تحلیل طراحی دامنه-محور (DDD) و پیاده‌سازی الگوهای CQRS و Event Sourcing.

• تست و تضمین کیفیت (۷٪): استراتژی‌های تخصصی تست میکروسرویس شامل تست واحد ایزوله، تست یکپارچگی سرویس، تست قرارداد (Contract Testing) مشتری-محور، اعتبارسنجی End-to-End و توسعه تست-محور (TDD).

• ابر و DevOps (۱۰٪): رایانش ابری چندمستاجری (Multi-tenant)، الگوهای معماری برای اپلیکیشن‌های Cloud Native، شیوه‌های اصلی DevOps، زیرساخت به عنوان کد (IaC) تکرارپذیر و خط لوله‌های CI پایدار.

درباره این دوره

پیمودن مسیر مصاحبه‌های مهندسی نرم‌افزار، معماری یا DevOps مدرن، بسیار فراتر از دانستن نحوه ساخت یک نقطه اتصال REST ساده است. سیستم‌های توزیع‌شده مدرن نیازمند تخصص عمیق در مدیریت خطاهای جزئی شبکه، سازگاری نهایی داده‌ها، تفویض پیچیده توکن‌ها و ارکستراسیون کانتینرها با قابلیت دسترسی بالا هستند. من این مخزن جامع ۵۵۰ سوالی را برای شبیه‌سازی دقیق چالش‌های فنی، تنگناهای ساختاری و توازن‌های طراحی (trade-offs) ایجاد کرده‌ام که مهندسان ارشد و معماران سیستم در مصاحبه‌های سخت‌گیرانه فنی با آن‌ها روبرو می‌شوند.

به جای سوالات کلی و سطحی، این دوره بر سناریوهای واقعی در سطح محیط تولید (Production) تمرکز دارد. شما با سوالات عمیقی در مورد خطاهای زنجیره‌ای (cascading failures)، شرایط رقابتی در سیستم‌های رویداد-محور، سناریوهای Split-brain در کشف سرویس و همگام‌سازی وضعیت در پایگاه‌های داده ایزوله مواجه خواهید شد. من برای هر گزینه، تحلیل خط به خط و جامع ارائه می‌دهم و توضیح می‌دهم که چرا یک انتخاب معماری خاص، مشکل را به طور بهینه حل می‌کند و چرا گزینه‌های جایگزین باعث ایجاد آسیب‌پذیری‌های بحرانی، گلوگاه‌ها یا آنتی-پترن‌ها در اکوسیستم تولیدی می‌شوند. چه توسعه‌دهنده بک‌اندی باشید که به دنبال نقش‌های طراحی سیستم است، چه مهندس ابر که در حال تسلط بر Service Mesh است و چه معماری که برای مراحل حساس فنی آماده می‌شود، این منبع عمق لازم برای قبولی با اعتمادبه‌نفس در اولین تلاش را فراهم می‌کند.

نمونه سوالات تمرینی

این سه نمونه سوال با دقت بالا را بررسی کنید تا عمق تحلیلی و استانداردهای توضیحات ارائه شده در این بانک سوالات را درک کنید.

سوال ۱: مدیریت تراکنش توزیع‌شده و سازگاری داده‌ها

یک سیستم تجارت الکترونیک از الگوی database-per-service استفاده می‌کند. هنگامی که مشتری سفارشی ثبت می‌کند، سرویس سفارش (Order Service) کالا را رزرو می‌کند، سرویس پرداخت (Payment Service) هزینه را کسر می‌کند و سرویس موجودی (Inventory Service) سطح موجودی را به‌روزرسانی می‌کند. اگر مرحله پرداخت به دلیل موجودی ناکافی شکست بخورد، معمار سیستم باید از کدام مکانیزم برای بازگرداندن سازگاری تراکنشی در شبکه استفاده کند؟

• الف) پیاده‌سازی پروتکل Two-Phase Commit (2PC) متمرکز در هر سه پایگاه داده میکروسرویس برای تضمین ویژگی‌های ACID فوری.

• ب) پیکربندی الگوی Saga ناهمگام با استفاده از تراکنش‌های جبرانی (Compensating Transactions) ارکسترال یا کورئوگرافی برای لغو مراحل رزرو تکمیل شده.

• ج) اجرای یک فراخوانی REST همگام مستقیم از سرویس پرداخت به پایگاه داده سرویس سفارش برای اجبار به بازگشت (rollback) فوری رکورد.

• د) استفاده از یک نمونه پایگاه داده توزیع‌شده جهانی مشترک که در یک مرز تراکنشی مونولیتیک قرار دارد تا تأخیر شبکه را حذف کند.

• ه) تکیه بر فرآیندهای دسته‌ای (Batch) زمان‌بندی شده برای اسکن لاگ‌ها و اصلاح دستی اختلافات موجودی در نیمه‌شب هر روز.

• و) فعال کردن یک قانون پراکسی در API Gateway برای حذف تمام درخواست‌های ورودی کاربر تا زمانی که درگاه پرداخت به طور خودکار بازیابی شود.

پاسخ صحیح و توضیحات:

• پاسخ صحیح: ب

• چرا صحیح است: در یک معماری میکروسرویس از هم گسیخته (decoupled) با الگوی database-per-service، تراکنش‌های توزیع‌شده سنتی مانند 2PC گلوگاه‌های عملکردی شدید، وابستگی‌های شدید و نقاط شکست واحد (SPOF) ایجاد می‌کنند. الگوی Saga این مشکل را با مدیریت توالی از تراکنش‌های محلی حل می‌کند. اگر یک مرحله محلی (مانند پرداخت) شکست بخورد، ارکستراتور یا هماهنگ‌کننده Saga رویدادهایی را ارسال می‌کند که تراکنش‌های جبرانی صریح را به ترتیب معکوس اجرا می‌کنند و سیستم را به یک وضعیت پاک و سازگار نهایی باز می‌گرداند.

• چرا گزینه‌های دیگر غلط هستند:

  • گزینه الف غلط است: 2PC بر اساس قفل‌های مسدودکننده (blocking locks) است که در محیط‌های ابری توزیع‌شده مقیاس‌پذیری خوبی ندارند و استقلال سرویس‌ها را مختل می‌کنند.

  • گزینه ج غلط است: دسترسی مستقیم به پایگاه داده از میان مرزهای میکروسرویس، اصول بنیادی کپسوله‌سازی و ایزولاسیون دامنه را نقض می‌کند.

  • گزینه د غلط است: ادغام پایگاه‌های داده در یک نمونه واحد، استقلال داده‌ها را از بین می‌برد و سیستم را به لایه داده‌های مونولیتیک باز می‌گرداند.

  • گزینه ه غلط است: تطبیق دسته‌ای (Batch Reconciliation) تأخیر داده‌ای قابل توجهی ایجاد می‌کند و نمی‌تواند سازگاری نزدیک به لحظه (near real-time) مورد نیاز برای مدیریت موجودی را فراهم کند.

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

سوال ۲: کاهش اثرات خطاهای زنجیره‌ای از طریق طراحی Circuit Breaker تاب‌آور

یک میکروسرویس پایین‌دستی (downstream) که توصیه‌های غیرحساس محصول را ارائه می‌دهد، به دلیل مشکلات pooling در اتصال به پایگاه داده، دچار جهش شدید در تأخیر (latency spike) می‌شود. این تأخیر باعث می‌شود تردها در سرویس جزئیات محصول (Product Detail Service) به طور کامل مسدود شوند، منابع سیستم تخلیه شوند و سرویس به طور کامل آفلاین شود. کدام تنظیمات پیکربندی این الگوی شکست زنجیره‌ای را به طور مؤثرترین شکل حل می‌کند؟

• الف) افزایش مقدار timeout درخواست‌های HTTP در سرویس بالادستی برای اینکه درخواست‌ها زمان بیشتری برای پاکسازی داشته باشند.

• ب) پیاده‌سازی الگوی Circuit Breaker در فراخوانی بالادستی با یک متد Fallback سفارشی‌سازی شده که در حالت Open، توصیه‌های ذخیره‌شده در کش (static cached) را ارائه دهد.

• ج) قرار دادن لایه ارتباطی در یک حلقه تلاش مجدد (retry loop) متوالی که سعی می‌کند ده بار متوالی سرویس پایین‌دستی را پینگ کند قبل از اینکه شکست بخورد.

• د) تبدیل لایه ارتباط همگام به یک فراخوانی gRPC مسدودکننده با اولویت بالا با استفاده از استریم‌های اختصاصی HTTP/2.

• ه) اختصاص حافظه RAM فیزیکی بیشتر به کانتینر اپلیکیشن بالادستی برای اینکه بتواند تردهای مسدود شده بیشتری را به طور همزمان نگه دارد.

• و) غیرفعال کردن قوانین Load Balancing سمت کلاینت در API Gateway برای اجبار به ارسال تمام ترافیک توصیه‌ها به یک نود فیزیکی واحد.

پاسخ صحیح و توضیحات:

• پاسخ صحیح: ب

• چرا صحیح است: الگوی Circuit Breaker دقیقاً برای جلوگیری از خطاهای زنجیره‌ای در محیط‌های توزیع‌شده طراحی شده است. وقتی سرویس پایین‌دستی نرخ شکست بالا یا جهش تأخیر نشان می‌دهد، مدار (circuit) از حالت Closed به Open تغییر می‌کند. فراخوانی‌های بعدی فوراً شکست می‌خورند بدون اینکه منابع بالادستی مسدود شوند، و به سرویس بالادستی اجازه می‌دهد یک اقدام Fallback سریع (مانند بارگذاری داده‌های استاتیک یا کش شده) را اجرا کند و پاسخگو باقی بماند.

• چرا گزینه‌های دیگر غلط هستند:

  • گزینه الف غلط است: افزایش timeoutها باعث بدتر شدن مشکل می‌شود زیرا تردها را مجبور می‌کند برای مدت طولانی‌تری مسدود شوند و تخلیه منابع (pool exhaustion) سریع‌تر اتفاق می‌افتد.

  • گزینه ج غلط است: اعمال تعداد زیادی تلاش مجدد سریع در مقابل سرویس پایین‌دستی که در حال تقلا است، بار را افزایش داده و باعث ایجاد اثر DoS (Denial of Service) خود-تحریمی می‌شود.

  • گزینه د غلط است: تغییر پروتکل به gRPC مشکل بنیادی گرسنگی منابع (resource starvation) ناشی از تأخیرهای پایین‌دستی را حل نمی‌کند.

  • گزینه ه غلط است: افزودن RAM بیشتر یک راهکار موقت است که مشکل معماری را حل نمی‌کند؛ تردها همچنان به سرعت ظرفیت جدید را اشباع می‌کنند.

  • گزینه و غلط است: دور زدن Load Balancer، افزونگی (redundancy) را حذف کرده و احتمال سربار روی یک نود پردازشی واحد را افزایش می‌دهد.

سوال ۳: پیکربندی‌های امن Token Relay بدون وضعیت (Stateless)

یک کاربر از طریق API Gateway وارد می‌شود و یک JSON Web Token (JWT) رمزنگاری شده دریافت می‌کند. سپس کاربر درخواستی ارسال می‌کند که نیاز دارد سرویس پروفایل کاربر (User Profile Service) جزئیات حساس را از یک سرویس حسابرسی داخلی (Audit Service) محافظت شده دریافت کند. بافتار (context) کاربر و جزئیات احراز هویت چگونه باید به صورت امن در زنجیره داخلی منتقل شود؟

• الف) API Gateway توکن را رمزگشایی کرده، آن را دور می‌اندازد و کلیدهای اصلی (primary keys) خام پایگاه داده را مستقیماً در هدرهای سفارشی HTTP query قرار می‌دهد.

• ب) پیاده‌سازی الگوی Token Relay که در آن API Gateway توکن JWT معتبر شده و بدون تغییر را در هدر Authorization به سرویس‌های داخلی پایین‌دستی ارسال می‌کند.

• ج) قرار دادن یک توکن مدیریتی جهانی (master administrative token) به صورت Hardcode در سورس کد هر یک از ایمیج‌های میکروسرویس.

• د) احراز هویت مجدد کاربر در هر مرز میکروسرویس داخلی با درخواست نام کاربری و رمز عبور در هر مرحله از فرآیند.

• ه) ذخیره کل Payload توکن JWT در یک کش Redis متمرکز و رمزنگاری نشده که هر سرور داخلی می‌تواند بدون بررسی امضا (signing check) آن را تغییر دهد.

• و) استفاده از کوکی‌های سمت کلاینت برای ذخیره مجوزهای کاربر، که به سرویس‌های داخلی اجازه می‌دهد مقادیر را مستقیماً از حافظه مرورگر کاربر استخراج کنند.

پاسخ صحیح و توضیحات:

• پاسخ صحیح: ب

• چرا صحیح است: الگوی Token Relay استانداردترین و امن‌ترین روش برای انتقال هویت کاربر در سیستم‌های توزیع‌شده داخلی است. API Gateway کاربر را احراز هویت می‌کند و میکروسرویس‌ها آن JWT بدون وضعیت را از طریق هدرهای استاندارد به پایین‌دستی منتقل می‌کنند. این به هر میکروسرویس پایین‌دستی اجازه می‌دهد به طور مستقل هویت کاربر را استخراج کرده، امضاهای رمزنگاری را تأیید کند و بررسی‌های دقیق نقش‌ها (role checks) را اعمال کند بدون اینکه کاربر دوباره احراز هویت شود.

• چرا گزینه‌های دیگر غلط است:

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

  • گزینه ج غلط است: توکن‌های مشترک باعث حذف ردیابی حسابرسی (audit tracking) دقیق، نقض اصل کمترین امتیاز (least privilege) و ایجاد مشکلات شدید در مدیریت اعتبارنامه‌ها می‌شود.

  • گزیینه د غلط است: درخواست مکرر اعتبارنامه‌ها از کاربر در یک نشست (session) واحد، تجربه کاربری را تخریب کرده و اهداف استاندارد Single Sign-On (SSO) را راs حذف می‌کند.

  • گزینه ه غلط است: ذخیره داده‌های بدون امضا و رمزنگاری شده در یک کش جهانی قابل تغییر، منجر به افزایش سطح دسترسی (privilege escalation) و تغییرات غیرمجاز در داده‌ها می‌شود.

  • گزینه و غلط است: میکروسرویس‌های داخلی مستقیماً با مرورگر کلاینت ارتباط ندارند و بنابراین پارس کردن کوکی‌های خام برای لایه‌های عمیق پایین‌دستی غیرممکن است.

چه انتظاراتی داشته باشید

• به آزمون‌های سوالات مصاحبه خوش آمدید تا شما را در آمادگی برای ارزیابی سوالات مصاحبه میکروسرویس‌ها یاری دهد.

• // می‌توانید آزمون‌ها را هر چند بار که بخواهید تکرار کنید.

• // این یک بانک سوالات جامع و اورجینال است.

• // شما در صورت داشتن هرگونه سوال، از پشتیبانی مدرسین بهره‌مند خواهید شد.

• // هر سوال دارای یک توضیح دقیق است.

• // با اپلیکیشن Udemy سازگار است و در موبایل قابل دسترسی است.

امیدواریم که تا کنون متقاعد شده باشید! و سوالات بسیار بیشتری در داخل دوره وجود دارد.