عنوان سخنرانی: Orchestrating A Path to Success - a Conversation with Bernd Ruecker
سخنران: Bernd Ruecker
رویداد: همایش بینالمللی QCon 2024
:لینک ویدیوhttp://www.youtube.com/watch?v=cxh2IrfGLvQ
مقدمه:
یکی از بنیادیترین چالشها در گذار از معماریهای یکپارچه به سیستمهای توزیعشده و میکروسرویسها، مسئله مدیریت وضعیت یا همان State Management و هماهنگی جریانهای کاری یا Workflow Coordination است. زمانی که یک سیستم به دهها سرویس مستقل تجزیه میشود، فرآیندهای تجاری یکپارچه مثل فرآیند ثبت و پردازش یک سفارش نیز تکهتکه شده و در سراسر شبکه پخش میشوند. در این نقطه، معماری با یک دوراهی کلاسیک مواجه میشود: استفاده از الگوی Choreography یا الگوی Orchestration. برنت روکر، از معماران پیشگام در حوزه اتوماسیون فرآیند، در سخنرانی خود در رویداد QCon 2024، به بررسی عمیق و تحلیلی این دو الگو میپردازد. این سخنرانی تلاش میکند تا با رد تعصبات رایج نسبت به معماریهای رویدادمحور، رویکردی مهندسی و عملگرایانه برای مدیریت تراکنشهای توزیعشده ارائه دهد. در این نوشتار، استدلالهای مطرح شده در این زمینه را کالبدشکافی کرده و منطق بازگشت به ارکستراسیون در سیستمهای مدرن را تحلیل خواهیم کرد.
تله رقصآرایی محض - The Fallacy of Pure Choreography
در سالهای اخیر، معماری رویدادمحور و الگوی رقصآرایی (Choreography) به عنوان راهحل نهایی برای کاهش وابستگی در میکروسرویسها تبلیغ شده است. در این الگو، هیچ کنترلکننده مرکزی وجود ندارد؛ هر سرویس وظیفه خود را انجام داده و یک رویداد منتشر میکند تا سرویس بعدی با شنیدن آن رویداد، کار خود را آغاز کند.
روکر این رویکرد را از منظر ساختاری به شدت نقد میکند و آن را معماری ماشین پینبال (Pinball Machine Architecture) مینامد. در یک ماشین پینبال، شما توپ را شلیک میکنید (شروع فرآیند) و توپ به صورت تصادفی به موانع مختلف برخورد میکند (رویدادها منتشر میشوند)، اما هیچکس دقیقاً نمیداند توپ در نهایت چه مسیری را طی خواهد کرد. در سیستمهای نرمافزاری، رقصآرایی محض باعث میشود که هیچ کدی به صورت متمرکز نمایانگر یک فرآیند تجاری کامل نباشد. اگر در فرآیند ثبت سفارش مشکلی پیش بیاید، مهندسان برای ردیابی خطا مجبورند لاگهای پراکنده دهها سرویس مختلف را کنار هم قرار دهند تا متوجه شوند فرآیند در کدام نقطه متوقف شده است. این نبود شفافیت، هزینه نگهداری سیستم را به شدت افزایش میدهد.
عبور از سایه سنگین ESB
بخش مهمی از این ارائه، به ریشهیابی ترس مهندسان از الگوی ارکستراسیون میپردازد. در دهه گذشته و در دوران معماری سرویسگرا (SOA)، ابزارهایی به نام گذرگاه سرویس سازمانی (ESB) برای ارکستراسیون استفاده میشدند که به شدت سنگین و غیرمنعطف بودند و منطق تجاری را درون خود حبس میکردند. همین تجربه تلخ باعث شد تا معماران مدرن به سمت رقصآرایی فرار کنند.
اما روکر مفهوم ارکستراسیون مدرن و سبکوزن یا همان Lightweight Orchestration را معرفی میکند. در این پارادایم جدید، موتور ارکستراسیون صرفاً یک تسهیلگر جریان کار است، نه محلی برای نوشتن کدهای تجاری. موتور ارکستراتور دقیقاً میداند که فرآیند X از مراحل A، B و C تشکیل شده است. او سرویس A را فراخوانی میکند، منتظر نتیجه میماند و سپس به سراغ سرویس B میرود. در این حالت، منطق تجاری همچنان درون خود میکروسرویسها باقی میماند، اما منطق جریان کار در یک نقطه مرکزی و شفاف مدیریت میشود.
مدیریت تراکنشهای توزیعشده و الگوی ساگا - The Saga Pattern
از دیدگاه مهندسی نرمافزار، پیچیدهترین مسئله در سیستمهای توزیعشده، عدم امکان استفاده از تراکنشهای استاندارد پایگاهداده یعنی ACID Transactions در سطح شبکه است. اگر در مرحله اول از حساب کاربر پول کسر شود و در مرحله دوم سیستم انبار دچار قطعی گردد، چگونه میتوان پول را به صورت امن و خودکار بازگرداند؟
سخنران، الگوی Saga را به عنوان راهحل منطقی این بحران مطرح میکند. ساگا یک تراکنش طولانیمدت را به مجموعهای از تراکنشهای محلی تقسیم میکند که هر کدام دارای یک عملیات جبرانی هستند. اجرای دقیق الگوی ساگا در بستر رقصآرایی به شدت پیچیده و مستعد خطاست، چون نیازمند شبکهای درهمتنیده از رویدادهای بازگشتی است. اما در یک معماری مبتنی بر ارکستراسیون، موتور مرکزی به راحتی و به صورت خودکار، در صورت بروز خطا در هر مرحله، عملیات جبرانی مراحل قبل را به ترتیب معکوس فراخوانی میکند تا سیستم به وضعیت پایدار بازگردد.
همسویی فناوری با کسبوکار - Business-IT Alignment
یکی از ارزشهای افزودهای که ارکستراسیون مدرن ایجاد میکند، ایجاد یک زبان بصری مشترک است. ابزارهای مدرن ارکستراسیون معمولاً از استانداردهایی مثل BPMN برای مدلسازی فرآیند استفاده میکنند. این امر باعث میشود که یک فرآیند پیچیده تجاری به شکل یک فلوچارت گرافیکی زنده و قابل اجرا در بیاید.
این شفافیت بصری، شکاف تاریخی میان تحلیلگران کسبوکار و مهندسان نرمافزار را پر میکند. تحلیلگر میتواند با نگاه به مانیتورینگ موتور ارکستراسیون متوجه شود که در حال حاضر چند هزار سفارش در مرحله پرداخت متوقف شدهاند. این سطح از شفافیت و نظارت، در سیستمهای رویدادمحور و مبتنی بر رقصآرایی تقریباً غیرممکن است.
تحلیل از مباحث سخنرانی
کالبدشکافی استدلالهای برنت روکر، یک اصل بنیادین در طراحی سیستمها را یادآوری میکند: وابستگی در فرآیندهای تجاری یک واقعیت گریزناپذیر است.
نخستین نتیجهگیری منطقی از این ارائه آن است که تلاش برای پنهان کردن وابستگیهای ذاتی یک فرآیند تجاری از طریق رویدادهای نامتمرکز، یک خطای معماری است. زمانی که فرآیند ارسال کالا، ذاتاً و منطقاً وابسته به موفقیتآمیز بودن پرداخت وجه است، معماری نرمافزار باید این وابستگی را به شکلی شفاف، صریح و کنترلشده مدیریت کند، نه اینکه آن را در پشت زنجیرهای از پیامهای ناهمگام مخفی کند.
دومین محور تحلیلی، مسئله توزیع پیچیدگی است. رقصآرایی پیچیدگی را از بین نمیبرد، بلکه آن را از یک نقطه متمرکز یعنی موتور ارکستراتور به تمام نقاط شبکه پمپاژ میکند. منطق سیستمی نشان میدهد که تمرکز پیچیدگی در یک ماژول مشخص که ابزارهای قدرتمندی برای نظارت بر آن وجود دارد، بسیار ایمنتر از توزیع همان پیچیدگی در میان دهها سرویس مختلف است.
در نهایت، دفاع از ارکستراسیون نشاندهنده یک رویکرد واقعگرایانه به مهندسی است. در دنیای واقعی، قابلیت دیباگ کردن و مدیریت خطاهای شبکهای مهمتر از دستیابی به یک معماری کاملاً غیرمتمرکز روی کاغذ است. موتورهای ارکستراسیون با مدیریت بومی این خطاهای شبکهای، بار شناختی سنگینی را از روی دوش توسعهدهندگان برمیدارند.
به طور خلاصه، این سخنرانی اثبات میکند که در معماری سیستمهای توزیعشده مدرن، رقصآرایی و ارکستراسیون نباید به عنوان دو رقیب متقابل دیده شوند، بلکه باید بر اساس نیاز سیستم انتخاب گردند؛ رقصآرایی برای واکنش به تغییرات محیطی و ایجاد اتصال نرم یا به اصطلاح Loose Coupling میان دامنههای مختلف، و ارکستراسیون برای کنترل دقیق و قطعیِ فرآیندهای حیاتی درون یک دامنه مشخص.
منابع و مراجع:
· ویدیو و پنل تخصصی Orchestrating A Path to Success در رویداد QCon 2024
· مفاهیم مرتبط با الگوی Saga و مدیریت تراکنشهای توزیعشده در میکروسرویسها
· اصول طراحی BPMN و اتوماسیون فرآیندهای تجاری در معماری مدرن
· این مطلب، بخشی از تمرین درس معماری نرمافزار در دانشگاه شهیدبهشتی است.
