ثبت سفارش اینترنتی یک عملیات کوتاه و یکپارچه نیست. رزرو کالا ممکن است سریع باشد، تأیید پرداخت چند دقیقه طول بکشد و پاسخ انبار ساعت ها بعد برسد. در این فاصله سرویس ها راه اندازی مجدد می شوند، شبکه قطع می شود و نسخه تازه برنامه منتشر می شود. نگه داشتن همه این وضعیت در حافظه یک فرایند کافی نیست. Temporal برای اجرای بادوام گردش کار طراحی شده است. ایده اصلی آن ثبت تاریخچه رخدادهای اجرا و بازسازی پیشرفت برنامه از روی آن تاریخچه است. فهم تفاوت Workflow و Activity کمک می کند این قابلیت را بدون نسبت دادن تضمین های اشتباه به آن به کار ببریم.
Workflow نقشه تصمیم های فرایند است
Workflow توالی تصمیم های یک فرایند را در کد بیان می کند. در مثال سفارش، این تصمیم ها می توانند شامل درخواست رزرو موجودی، انتظار برای پرداخت، آغاز ارسال و رسیدگی به لغو باشند. Workflow باید بتواند بعد از توقف Worker، از تاریخچه خود دوباره به همان نقطه تصمیم برسد. در نتیجه کدی که تصمیم های آن به زمان تصادفی سیستم، عدد تصادفی معمولی یا پاسخ مستقیم یک سرویس خارجی وابسته باشد، می تواند هنگام بازپخش رفتار متفاوتی تولید کند.
این محدودیت به معنی ناتوانی در استفاده از زمان یا تصادف نیست. SDKهای Temporal سازوکارهای مناسب محیط Workflow را فراهم می کنند. موضوع اصلی این است که هر اثر قابل مشاهده بر مسیر اجرا باید با مدل بازپخش سازگار باشد. نویسنده برنامه باید مرز میان «تصمیم درباره مرحله بعد» و «انجام اثر خارجی» را روشن کند. قرار دادن همه منطق در یک تابع بزرگ، این مرز را پنهان می کند و بررسی تغییرات بعدی را سخت تر می سازد.
Activity محل انجام اثر خارجی است
تماس با درگاه پرداخت، نوشتن در یک سامانه دیگر یا پردازش یک فایل معمولاً در Activity انجام می شود. Activity توسط Worker اجرا می شود و نتیجه آن به تاریخچه Workflow راه پیدا می کند. اگر اجرای Activity شکست بخورد یا پاسخ آن به موقع ثبت نشود، بسته به سیاست تکرار ممکن است دوباره اجرا شود. بنابراین فراخوانی سرویس پرداخت از داخل Activity به خودی خود از برداشت دوباره پول جلوگیری نمی کند.
برای عملیات دارای اثر مالی، باید کلید idempotency با معنای تجاری روشن انتخاب شود. این کلید می تواند به شناسه سفارش و نوع عملیات وابسته باشد. درگاه یا لایه پرداخت باید درخواست تکراری با همان کلید را تشخیص دهد. استفاده از یک شناسه تازه در هر تلاش، این حفاظت را خنثی می کند. همچنین کلید پرداخت و کلید بازپرداخت نباید بدون تحلیل یکسان فرض شوند، زیرا این دو اثر تجاری متفاوت هستند و ممکن است هر دو برای یک سفارش لازم باشند.
تاریخچه اجرا چه چیزی را نگه می دارد؟
تاریخچه شامل رخدادهایی است که پیشرفت اجرای Workflow را توصیف می کنند. شروع اجرا، زمان بندی Activity، ثبت نتیجه، دریافت Signal و رخدادهای زمان سنج نمونه هایی از این اطلاعات هستند. Worker هنگام نیاز با بازپخش تاریخچه وضعیت منطقی را بازسازی می کند. در این فرایند هدف اجرای دوباره همه تماس های خارجی نیست. نتایج ثبت شده به کد بازپخش شده ارائه می شوند تا تصمیم های قبلی به صورت سازگار بازسازی شوند.
این تفاوت برای هزینه و امنیت اهمیت دارد. تاریخچه می تواند ورودی و خروجی مراحل را در بر داشته باشد، بنابراین نباید بی فکر اطلاعات محرمانه یا فایل های بزرگ را به آن فرستاد. یک طراحی مناسب اغلب داده حجیم را در ذخیره ساز مجاز نگه می دارد و شناسه یا مرجع لازم را از مسیر گردش کار عبور می دهد. چرخه عمر آن مرجع باید با مدت اجرای Workflow هماهنگ باشد تا بازپخش یا رسیدگی دیرهنگام به یک فایل حذف شده وابسته نشود.
Worker و Task Queue دو نقش متفاوت دارند
Worker فرایندی است که کد Workflow یا Activity را اجرا می کند. Task Queue مسیر توزیع کار به Workerهای مناسب است. نام صف باید با استقرار واقعی هماهنگ باشد. اگر یک گردش کار مرحله ای را روی صفی زمان بندی کند که هیچ Worker سازگاری آن را گوش نمی دهد، مشکل لزوماً در کد آن مرحله نیست. کار ممکن است صرفاً منتظر پردازشگر مناسب بماند. مشاهده صف و ظرفیت Worker برای تشخیص این وضعیت ضروری است.
تقسیم صف ها می تواند برای جداسازی کار سنگین، وابستگی به سخت افزار خاص یا مرزهای عملیاتی مفید باشد. با این حال هر صف تازه بار پیکربندی و پایش ایجاد می کند. برای یک سامانه کوچک، تقسیم بیش از اندازه می تواند ظرفیت بلااستفاده در یک بخش و انتظار طولانی در بخش دیگر بسازد. انتخاب تعداد Worker باید بر اساس زمان اجرای مراحل، همزمانی مجاز و محدودیت سرویس پایین دست باشد. افزایش مصرف کننده بدون توجه به نرخ مجاز درگاه پرداخت ممکن است شکست های بیشتری تولید کند.
Timeout باید با محل انتظار هماهنگ باشد
در Activity چند نوع زمان انتظار معنا دارد. زمان انتظار برای شروع کار با مدت مجاز خود اجرای کار یکی نیست. همچنین بازه کلی تلاش ها با زمان یک تلاش منفرد تفاوت دارد. اگر تیم همه این وضعیت ها را با یک عدد عمومی پوشش دهد، تشخیص اینکه ظرفیت Worker کم بوده یا سرویس خارجی کند شده دشوار می شود. مستندات Activity باید برای نام و رفتار دقیق هر timeout در SDK مورد استفاده خوانده شود.
یک سناریوی قابل اندازه گیری طراحی کنید. ابتدا Worker را متوقف کنید تا کار در صف بماند. سپس Worker را اجرا کنید ولی پاسخ سرویس آزمایشی را کند کنید. خطاها و مدت انتظار این دو آزمایش باید قابل تمایز باشند. برای مراحل طولانی، heartbeat می تواند پیشرفت را گزارش کند و در تشخیص قطع Worker نقش داشته باشد. با این حال heartbeat جای ثبت پایدار نتیجه تجاری را نمی گیرد و نباید به اشتباه نشانه اتمام موفق کار تلقی شود.
تکرار خودکار نیازمند طبقه بندی خطاست
خطای موقت اتصال و رد قطعی یک پرداخت نباید سیاست یکسانی داشته باشند. تلاش دوباره برای خطای شبکه می تواند مفید باشد، اما تکرار بی پایان یک درخواست نامعتبر فقط منابع را مصرف می کند. نوع خطا، سقف تلاش و فاصله زمانی باید با معنای عملیات هماهنگ شوند. تصمیم درباره قابل تکرار بودن خطا نباید فقط به کد وضعیت عمومی یک کتابخانه محدود شود. ممکن است سرویس خارجی پاسخ مبهم داده باشد ولی اثر را انجام داده باشد.
در چنین حالت مبهمی، پرس وجوی وضعیت عملیات با شناسه تجاری می تواند از اجرای کورکورانه دوباره بهتر باشد. برای مثال پس از قطع ارتباط با پرداخت، ابتدا می توان وضعیت همان درخواست را از درگاه خواند. این راهکار به امکانات درگاه وابسته است و باید در قرارداد یکپارچه سازی ثبت شود. Temporal مدیریت تلاش ها را سازمان می دهد، اما حقیقت بیرونی عملیات همچنان در سامانه ای است که اثر را انجام داده است.
انتظار طولانی با خواب یک پردازش فرق دارد
گردش کار می تواند برای یک رخداد یا زمان مشخص منتظر بماند، بدون اینکه یک رشته سیستم عامل در تمام این مدت به شکل سنتی اشغال شود. این ویژگی برای فرایندهایی مانند تأیید انسانی یا مهلت پرداخت مفید است. با این حال انتظار طولانی هزینه صفر ندارد. وضعیت اجرا، تاریخچه، سیاست نگهداری و ظرفیت سرویس باید مدیریت شوند. تعداد بسیار زیادی اجرای باز نیز باید در مدل عملیاتی سامانه دیده شود.
در مثال سفارش، می توان مهلت پرداخت را به صورت یک تصمیم روشن مدل کرد. اگر پرداخت پیش از موعد برسد، مسیر ارسال ادامه پیدا می کند. اگر موعد بگذرد، مسیر آزاد کردن موجودی آغاز می شود. حالت مرزی رسیدن پرداخت نزدیک پایان مهلت باید از قبل تعریف شود. بدون تعریف ترتیب تصمیم و قواعد تجاری، هیچ موتور گردش کاری نمی تواند به تنهایی تعیین کند مشتری باید کالا دریافت کند یا بازپرداخت شود.
Signal، Query و تغییر وضعیت
Signal راهی برای رساندن اطلاعات به اجرای در حال کار است. Query برای مشاهده وضعیت به کار می رود و نباید با فرمانی که اثر پایدار ایجاد می کند اشتباه شود. در SDKها و نسخه های مختلف، امکانات دیگری مانند Update نیز برای تعامل با Workflow وجود دارد. انتخاب روش تعامل باید بر اساس نیاز به تغییر وضعیت، پاسخ، اعتبارسنجی و تضمین های همان API انجام شود، نه فقط راحتی نام تابع.
برای پیام لغو سفارش، احراز هویت درخواست کننده باید در لایه ورودی برنامه انجام شود. دانستن Workflow ID نباید به تنهایی مجوز لغو باشد. همچنین درخواست تکراری لغو باید رفتار روشن داشته باشد. اگر کالا قبلاً ارسال شده، پاسخ منطقی ممکن است آغاز فرایند مرجوعی باشد. وضعیت داخلی Workflow باید این تفاوت را بیان کند تا کاربران و تیم پشتیبانی با یک برچسب مبهم «لغوشده» روبه رو نشوند.
تغییر کد و سازگاری با تاریخچه
کدی که امروز منتشر می شود ممکن است تاریخچه اجرایی را بازپخش کند که چند هفته پیش آغاز شده است. حذف یا جابه جا کردن تصمیم ها می تواند با آن تاریخچه ناسازگار شود. بنابراین استقرار نسخه جدید فقط مسئله اجرای تست روی سفارش تازه نیست. باید تاریخچه های نماینده اجراهای موجود نیز در بررسی سازگاری دیده شوند. Temporal ابزارها و الگوهای نسخه بندی دارد که انتخاب دقیق آن ها به زبان، SDK و روش استقرار وابسته است.
یک رویه مناسب، نگه داشتن نمونه تاریخچه از مسیرهای مهم و بازپخش آن ها با کد پیشنهادی است. مسیر موفق، لغو، خطای موقت و انتظار طولانی باید در نمونه ها حضور داشته باشند. داده حساس این نمونه ها نیز باید کنترل شود. موفقیت تست واحد یک تابع محاسباتی ثابت نمی کند که تغییر ساختار Workflow با اجراهای زنده سازگار است. این دو نوع آزمون پرسش های متفاوتی را پاسخ می دهند.
Continue-As-New برای ادامه با تاریخچه تازه
اجرایی که برای مدت طولانی رویداد دریافت می کند، می تواند تاریخچه بزرگی بسازد. Continue-As-New روشی برای ادامه منطقی کار در یک اجرای جدید با تاریخچه تازه است. این گذار باید وضعیت لازم را به ورودی اجرای بعد منتقل کند. انتقال همه جزئیات قدیمی معمولاً هدف مناسبی نیست، زیرا مزیت کوچک کردن تاریخچه را کاهش می دهد. باید حداقل وضعیت لازم برای تصمیم های آینده مشخص شود.
مرز این گذار از نظر پیام های در راه و فعالیت های جاری مهم است. کد باید مطابق راهنمای SDK اطمینان دهد تعاملات مهم از دست نمی روند و وضعیت نیمه تمام به شکل مبهم باقی نمی ماند. برای یک پردازشگر چرخه ای می توان گذار را پس از یک تعداد مشخص کار یا در نقطه ای آرام از فرایند انجام داد. انتخاب آستانه باید از مشاهده اندازه تاریخچه و رفتار واقعی سامانه بیاید، نه یک عدد کپی شده از پروژه دیگر.
آزمون خرابی به جای اعتماد به مسیر خوشحال
برای پذیرش طراحی، Worker را هنگام اجرای یک Activity متوقف کنید و بعد دوباره بالا بیاورید. سپس قطع پاسخ سرویس خارجی پس از انجام اثر را شبیه سازی کنید. باید مشخص شود گردش کار از کجا ادامه داده، چند تلاش ثبت شده و آیا اثر تجاری تکراری رخ داده است. در آزمایش جداگانه، نسخه جدید Worker را روی تاریخچه های قبلی بازپخش کنید و تفاوت تصمیم ها را بررسی کنید.
گزارش عملیاتی خوب میان شکست Workflow، شکست یک تلاش Activity و تأخیر صف تمایز می گذارد. این تفکیک به تیم اجازه می دهد به جای راه اندازی دوباره تصادفی سرویس ها، محل واقعی مشکل را پیدا کند. ارزش Temporal زمانی آشکار می شود که فرایندهای طولانی را قابل مشاهده و قابل بازیابی کند و همزمان مرز مسئولیت کد برنامه، سرویس خارجی و تاریخچه اجرا روشن باقی بماند.
