الگوی حماسه یک الگوی طراحی سیستم های توزیع شده برای کاری است که مرزهای ماشین یا میکروسرویس را در بر می گیرد که در آن اجرای کامل همه مراحل ضروری است. اجرای جزئی مطلوب نیست. یک مثال رایج زندگی که برای توضیح مفید بودن الگوی حماسه استفاده می شود، برنامه ریزی سفر است. برای مثال، اگر قصد شرکت در Replay را دارید، باید بلیط کنفرانس، بلیط هواپیما و هتل رزرو کنید. اگر نتوانید یکی از این موارد را بدست آورید، ملاقات حضوری با افراد سرگرم کننده در مهندسی باطن را از دست خواهید داد.
در زیر سطح، دو راه اصلی وجود دارد که میکروسرویس ها می توانند با یکدیگر صحبت کنند که حماسه شما را ممکن می کند: رقص و ارکستراسیون.
رقص
رقص شبیه به مورچه ها در کلنی مورچه ها است. مانند مورچه ها، هر میکروسرویس دارای این ویژگی است محلی دانش، و اطلاعات مربوط به تغییرات حالت را با سایر خدمات از طریق سیگنال های شیمیایی به نام فرومون به اشتراک می گذارد – منظورم از طریق ارسال پیام است. درست همانطور که یک دنباله مورچه به سمت غذا به صورت ارگانیک از فرمون ها بیرون می آید، رفتار کلی یک سیستم به عنوان یک کل که حاوی ریزسرویس های طراحی شده است به صورت ارگانیک از دستورالعمل های هر میکروسرویس ظاهر می شود.
یک مستاجر که در سر هر مهندس نرم افزار حفر می شود، ارزش جداسازی است. رقص مظهر این ایده است و اجرای آن به طور کلی آسان است. رقص می تواند یک انتخاب محبوب و آسان برای سیستم هایی باشد که به تدریج از معماری یکپارچه به معماری میکروسرویس می روند. با این حال، اگر شما هر نوع نیاز به ترتیب کارها، مانند مراحل مرتب شده در حماسه خود دارید، رقص می تواند نسبتاً به سرعت سخت شود. فرض کنید می خواهیم ابتدا هواپیما را رزرو کنیم تا هتل شماره پرواز شما را بداند و شما را از فرودگاه ببرد. سپس بلیط کنفرانس خود را رزرو می کنیم (شاید با هتل های خاصی تخفیف داشته باشد). دنباله پیام هایی که هر سرویس به آنها پاسخ می دهد به صورت زیر است:
با این حال، تنها با نگاه کردن به پایگاه کد جداگانه هر میکروسرویس، درک ترتیبی که سیستم باید از آنجایی که این سفارش در سراسر کد توزیع می شود. این منجر به انواع نمودارهای منطق تجاری سطح بالاتری می شود که باید با کد هماهنگ باشند… اما آیا بهتر نیست که خواندن کد در وهله اول ساده تر باشد؟ همچنین ممکن است اشکال زدایی توالی دقیق رویدادهایی که منجر به یک باگ می شوند دشوار باشد زیرا جریان کنترل بلافاصله مشخص نیست. بنابراین، مگر اینکه همه میکروسرویس‌های شما واقعاً مستقل از یکدیگر باشند و هیچ گونه منطق «پیش از این اتفاق می‌افتد» نداشته باشند، به جای آن از ارکستراسیون استفاده کنید.
تنظیم و ارکستراسیون
از طرف دیگر، ارکستراسیون مانند یک برج کنترل ترافیک هوایی است که هواپیماها یا خدمات میکرو را هدایت می کند. یکی از سرویس‌ها، یک «ابر میکروسرویس»، اگر بخواهید، به‌عنوان واسطه‌ای عمل می‌کند که پیام‌ها را مستقیماً به میکروسرویس‌های جداگانه ارسال می‌کند و به آنها می‌گوید چه کاری انجام دهند، درست مانند هواپیماهایی که منتظر مجوز برای بلند شدن هستند.
از آنجا که ارکستراسیون جریان کنترل را متمرکز می کند، اشکال زدایی و درک جریان کنترل بسیار ساده تر است. علاوه بر این، از آنجایی که هر مرحله نیازی به پیگیری پیام‌هایی که «قبل از آن اتفاق می‌افتد» برای گوش دادن به آنها نیست، کد برای میکروسرویس‌های فردی بسیار ساده‌تر است. ارکستراسیون همچنین در شرایطی که بسیاری از خدمات نیاز به تعامل در یک مرحله حماسی دارند می درخشد. پاشنه آشیل خیره کننده این روش، آفت تمام سیستم های توزیع شده است: واسطه پیام تنها نقطه شکست است.
همه اش را بگذار کنار هم
بنابراین به طور خلاصه، رقص:
- غیرمتمرکز و جدا شده است
- برای میکروسرویس های بسیار مستقل خوب است
- حداقل در ابتدا “آسان تر” است
- یک انتخاب آسان برای تبدیل یکپارچه‌های ثابت به میکروسرویس است
- می تواند جریان کنترل را نامشخص کند
- اشکال زدایی می تواند چالش برانگیز باشد
و ارکستراسیون:
- دارای یک سرویس است که “فرمان” را برای اجرای میکروسرویس ها صادر می کند
- درک جریان کنترل را آسان تر می کند
- ساخت آسان تر با برنامه های سبز
- اشکال زدایی و مدیریت خرابی را واضح تر می کند
- در ابتدا “سخت تر” است، اما بعدا سود سهام پرداخت می کند
- دارای یک نقطه شکست (کارگزار پیام)
معاوضه جالب بین این دو رویکرد این است که می‌خواهید در روزهای اولیه به گزینه سبک و چابک (رقص رقص) دست پیدا کنید و از معماری بیش از حد پروژه خود اجتناب کنید، اما به طور غیرمستقیم، زمانی که از همان ابتدا از آن استفاده می‌کنید، ارکستراسیون آسان‌تر است.
بنابراین، تمپورال چه می کند؟
تمپورال از ارکستراسیون زیر کاپوت استفاده می کند (نیازی نیست خودتان آن را اجرا کنید)، ولی همچنین از آن اشکال اساسی یک نقطه شکست اجتناب می کند. چگونه چنین چیزی ممکن است؟ در داخل، Temporal پیشرفت برنامه شما را در یک گزارش ثبت می کند. اگر آن واسطه پیام آفلاین شود، کل تاریخچه برنامه شما ذخیره می شود و به این ترتیب دستگاه دیگری می تواند دقیقاً از جایی که برنامه شما متوقف شده است راه اندازی شود، گویی هیچ اتفاقی نیفتاده است. این باعث می شود Temporal به صورت کاملاً افقی مقیاس پذیر باشد.
برای بازگرداندن این ایده به الگوی حماسه، یک جزء مهم از الگوی حماسه، حرکت به سمت تکمیل تمام مراحل حماسه است. این واقعیت که Temporal تضمین می‌کند هیچ پیشرفتی هرگز از بین نمی‌رود به این معنی است که دقیقاً همان جایی را که متوقف کرده است ادامه می‌دهد، از جمله شکست‌ها برای مدت زمان نامعلوم، تکمیل حماسه بدون کد اضافی یا انجام کارهای سنگین از جانب شما.
علاوه بر این، برخلاف برخی از موتورهای ارکستراسیون، در Temporal، منطق گردش کار شما به طور کامل به صورت کد بیان می‌شود، بنابراین شما مجبور نیستید با json سر و کار داشته باشید. در اصل، برای ایجاد یک برنامه قوی و مقاوم در برابر شکست، به غیر از منطق تجاری خود برنامه، به هیچ چیز اضافی نیاز نیست.
نتیجه
رقص و ارکستراسیون رویکردهای متفاوتی برای هماهنگی ارتباط بین میکروسرویس ها ارائه می دهند. رقص جدا شده است، اما می تواند اشکال زدایی و کنترل جریان را دشوار کند. ارکستراسیون متمرکز است، اما منجر به یک نقطه شکست می شود. تمپورال از ارکستراسیون زیر پوشش استفاده می کند، ولی با طراحی محافظت در برابر یک نقطه شکست، به شما این امکان را می دهد که روی نوشتن کد خود با اطمینان از مقاوم بودن آن تمرکز کنید.
