حالت تاریک
فصل ۱۱ — مدیریت گردشکارهای توزیعشده
خلاصهٔ تحلیلی — این متن برداشت و صورتبندی فارسیِ مفاهیم فصل است، نه ترجمهٔ واژهبهواژه.
مسئله و زمینه
در معماری توزیعشده، انجام یک قابلیت کسبوکاری اغلب به همکاری چند سرویس نیاز دارد: ثبت سفارش، پرداخت، تأمین کالا و اطلاعرسانی نمونهای ساده از آن است. دشواری اصلی مسیر موفق نیست؛ مسیرهای جایگزین، تأخیر، لغو، پیام گمشده و جبران خطا هستند. فصل این مسئله را ذیل یکی از سه نیروی coupling پویا بررسی میکند: هماهنگی؛ دو نیروی دیگر ارتباط و سازگاریاند.
هر گردشکار مقداری وابستگی معنایی دارد که از خود مسئلهٔ دامنه میآید و حذفشدنی نیست. مثلاً تخصیص تیکت به کارشناس ناگزیر به مهارت، مکان، برنامه و وضعیت تیکت وابسته است. انتخاب معماری فقط تعیین میکند این پیچیدگی کجا قرار بگیرد. پیادهسازی نمیتواند coupling معنایی را کمتر کند؛ تنها میتواند با لایهها، پیامها و مسیرهای اضافه آن را تشدید کند.
الگوهای مرکزی
Orchestration: مالک مشخص برای گردشکار
در orchestration یک orchestrator یا mediator وضعیت، ترتیب گامها، انتخاب مسیر، اعلان، retry و رسیدگی به خطا را مدیریت میکند. سرویسهای دامنه همچنان مالک رفتار و دادهٔ bounded context خود هستند؛ orchestrator نباید به ESB سراسری تبدیل شود. در معماری microservices معمولاً برای هر workflow یک orchestrator مستقل ساخته میشود تا نقطهٔ تمرکز کل سامانه ایجاد نشود.
این الگو در مثال سفارش، پس از ثبت سفارش پرداخت را تأیید میکند، کار تأمین را در صورت مناسببودن بهشکل ناهمگام شروع میکند و اعلان را میفرستد. اگر پرداخت رد شود، orchestrator هم سفارش را به وضعیت درست برمیگرداند و هم پیام مناسب به مشتری میدهد. اگر تأمین کالا به بنبست برسد، میتواند بازپرداخت و اصلاح سفارش را بهصورت متمرکز هدایت کند.
مزیت اصلی، قابلمشاهده بودن و قابلپرسوجو بودن state گردشکار و تمرکز منطق خطاست. هزینهٔ آن، گلوگاه احتمالی، وابستگی سرویسها به mediator، کاهش موازیسازی و نیاز به افزونگی برای جلوگیری از single point of failure است.
Choreography: همکاری از راه رویدادها
در choreography هماهنگکنندهٔ مرکزی وجود ندارد. هر سرویس پس از انجام مسئولیت خود رویدادی منتشر میکند یا پیام گام بعدی را میفرستد. این مدل برای مسیر خطیِ ساده، throughput بالا و scale مستقل جذاب است: پرداخت میتواند پس از ثبت سفارش فعال شود و تأمین پس از پرداخت، بدون آنکه همهٔ مسیر از یک نقطه عبور کند.
اما با ظهور خطا، توپولوژی ساده به شبکهای از ارتباطهای جبرانی تبدیل میشود. اگر پس از پرداخت، کالا ناموجود باشد، سرویس تأمین باید رویدادهایی تولید کند که پرداخت، سفارش و اعلان را به واکنش درست وادارد. در نتیجه، هر سرویس بخشی از دانش گردشکار و منطق بازیابی را حمل میکند. نبود mediator، coupling را حذف نمیکند؛ آن را در میان شرکتکنندگان پخش میکند.
مدیریت وضعیت در choreography
سه راه رایج وجود دارد:
- Front Controller: سرویس نخستِ زنجیره، علاوه بر وظیفهٔ دامنه، state workflow را نگه میدارد. پرسوجوی وضعیت آسان میشود، اما آن سرویس عملاً شبه-orchestrator شده و ترافیک و مسئولیتش افزایش مییابد.
- Choreography بدون state ماندگار: وضعیت لحظهای از پرسوجوی سرویسهای مختلف بازسازی میشود. این روش انعطافپذیر است، ولی برای هر پرسوجو chatter شبکه و هزینهٔ ترکیب پاسخها تولید میکند.
- Stamp coupling: state گردشکار داخل قرارداد پیام حمل میشود و هر سرویس قسمت خود را بهروز میکند. پرسوجوی مجدد سرویسها کمتر میشود، ولی قرارداد بزرگتر و coupling قراردادی بیشتر میشود؛ ضمن آنکه هنوز یک نقطهٔ واحد برای status زنده وجود ندارد.
بدهبستانها و راهنمای عملی
انتخاب، «متمرکز یا مدرن» نیست. orchestration معمولاً برای جریانهای دارای مسیرهای خطا، لغو، retry، نیاز جدی به رهگیری و state قابلپرسوجو مناسبتر است. choreography زمانی ارزشمندتر است که مسیر عمدتاً ساده و خطی، خطاها کم یا قابلمدیریت، و responsiveness و elasticity اولویت باشند.
پیش از انتخاب، happy path و مهمترین failure pathها را نمودار کنید؛ سپس برای هر گزینه صریحاً بررسی کنید: مالک state کیست؟ مشتری یا عملیات چگونه وضعیت را میبینند؟ retry و اصلاح به عهدهٔ کدام مؤلفه است؟ با قطعشدن یک سرویس چه رخ میدهد؟ در نمونهٔ تیکت فصل، نیاز به کنترل تیکت گمشده، نمایش وضعیت و مدیریت لغو/تخصیص مجدد، orchestration را توجیه میکند؛ البته باید پیامد مقیاسپذیری آن در ADR ثبت و بازبینی شود.
نکات کلیدی فصل
- پیچیدگی semantic workflow حذف نمیشود؛ معماری فقط محل و شکل بروز آن را تغییر میدهد.
- orchestration کنترل، بازیابی و مشاهدهپذیری را ساده میکند، اما گلوگاه و coupling مرکزی میسازد.
- choreography scale و پاسخگویی بهتری میدهد، اما با افزایش استثناها پیچیدگی را به سرویسها و قراردادها منتقل میکند.
- با پیچیدهتر شدن workflow، ارزش mediator معمولاً افزایش مییابد.
- تصمیم را با سناریوهای خطا و نیازهای واقعی دامنه بسنجید، نه فقط با مسیر موفق.
یادداشتهای مترجم
- اصطلاحهای orchestration، choreography، orchestrator، workflow، state و stamp coupling برای حفظ دقت رایج معماری در کنار توضیح فارسی نگه داشته شدهاند.
- «وابستگی معنایی» معادل semantic coupling است؛ مقصود آن وابستگی تحمیلشده از مسئلهٔ کسبوکار است، نه صرفاً وابستگی فنی.