Modal تربط الجلسة بحاوية واحدة وتحافظ على السياق عند إعادة الاتصال

يتحدث روبوت صوتي مع المستخدم، فينقطع الاتصال، ويعيد المستخدم الاتصال ليجد نفسه أمام عملية لا تعرف عنه شيئًا. بالنسبة إلى البنية التحتية للخوادم قد يكون ذلك توزيعًا طبيعيًا للحمل، أما بالنسبة إلى المنتج فهو محادثة مكسورة. قدمت Modal ميزة Sticky Sessions: آلية توجّه طلبات الجلسة الواحدة إلى الحاوية نفسها وتوسّع البنية التحتية بحسب عدد الجلسات النشطة.

عمليًا، يستطيع المطوّر الاحتفاظ بحالة مؤقتة بجوار الشيفرة قيد التشغيل: سياق وكيل صوتي، أو حالة مفكك التعرف على الكلام، أو غرفة ألعاب مشتركة. وعند إعادة الاتصال يعود الطلب إلى المكان الذي توجد فيه هذه الحالة بالفعل ما دامت الجلسة قائمة.

لماذا لا يكفي WebSocket وحده

لنتخيل خدمة للتدرب على مقابلات العمل بواسطة ذكاء اصطناعي صوتي. في الحاوية يعمل الوكيل ومعالجة الصوت، وفيها أيضًا حالة المحادثة الحالية. ينتقل المستخدم من Wi-Fi إلى الإنترنت المحمول، فيجب إنشاء الاتصال من جديد، لكن على المنتج أن يواصل المقابلة من النقطة نفسها.

كما تشرح Modal، يرتبط WebSocket في Web Functions لديها باستدعاء دالة محدد. وبعد الانقطاع يظهر استدعاء جديد قد يصل إلى حاوية أخرى. لذلك لا يحل WebSocket وحده مشكلة العودة إلى العملية السابقة.

الحل البديل هو حصر التطبيق في حاوية واحدة. عندها لا يجد الطلب مكانًا آخر يذهب إليه، لكن مع اختفاء مشكلة التوجيه تختفي أيضًا إمكانية التوسع الأفقي. وتوفر Modal Servers كذلك توجيهًا عبر الترويسة Modal-Affinity-Routing-Key، لكنه يعمل على أساس بذل أفضل جهد: فقد تُوقَف الحاوية أو تُستبدل.

تقدم Sticky Sessions ربطًا أشد صرامة طوال مدة الجلسة. وهذا مفيد خصوصًا لتطبيقات Gradio وStreamlit، حيث ترتبط حالة المستخدم بعملية خادم محددة. ولا يضطر المطوّر إلى إبقاء الخدمة كلها في نسخة واحدة من أجل استمرارية سيناريوهات مستخدمين بعينهم.

كيف يجد الطلب العملية المطلوبة

لتفعيل الآلية يُوضع على فئة Modal Server المزخرف @modal.sessioned()، ثم تُنشأ جلسة عبر SDK أو HTTP API. في المثال الذي قدمته الشركة، يعيد الاستدعاء sessions.start(idle_timeout=600) كائنًا يحتوي على رمز. ويمرر العميل هذا الرمز في الترويسة Modal-Authorization عند الطلبات اللاحقة.

الرمز موقّع ويحتوي على المعلومات اللازمة للتوجيه. يتحقق الوكيل (proxy) منه ويرسل الطلب إلى الحاوية التي تملك الجلسة. وبفضل ذلك لا يحتاج الوكيل إلى الاحتفاظ بجدول مطابقة متسق بين الجلسات والحاويات على جميع نسخه.

يمكن تمرير رمز واحد إلى عدة مشاركين في غرفة مشتركة. فمثلًا يتصل مستخدمان بالدردشة نفسها ويعملان على حالة موجودة في عملية واحدة. وتعيد إعادة الاتصال المشارك إلى الغرفة نفسها ضمن عمرها. ولأن الرمز يمنح الوصول إلى الجلسة، ينبغي التعامل معه في التطبيق كبيانات اعتماد.

وتتغير أيضًا وحدة التوسع. فالحاوية تقبل عددًا محددًا من الجلسات المتزامنة. وعندما لا تتوفر أماكن شاغرة، تنتظر الجلسات الجديدة انتهاء الجلسات القائمة أو جاهزية حاوية إضافية. ويأخذ التوسع التلقائي في الحسبان الجلسات النشطة وطابور الانتظار، لأن المحادثة التي بدأت لا يمكن نقلها اعتباطيًا إلى عملية مجاورة.

ما الذي يجب التحقق منه قبل الاعتماد

القيد الرئيسي: تثبيت المسار لا يعني سلامة البيانات عند عطل الحاوية. فالمنشور يصف استمرارية الطلبات ضمن الجلسة، لكنه لا يعد باستعادة ذاكرتها بعد الحادث. ولا يزال من الضروري حفظ سجل المحادثات ونتائج العمل وغيرها من البيانات المهمة بشكل منفصل إذا كان على المنتج أن يصمد أمام مثل هذه الأحداث.

وهناك أيضًا مسألة توزيع الحمل. فقد تستهلك جلستان موارد مختلفة: محادثة نصية قصيرة وتدفق صوتي متواصل يولّدان حملًا مختلفًا تمامًا. لذلك سيتعين اختيار عدد الجلسات لكل حاوية بحسب السيناريو الفعلي. ولا تنقل الآلية تلقائيًا جلسة ثقيلة قائمة من أجل موازنة الحمل.

أما للفريق الذي يعمل على وكلاء صوتيين أو على واجهة تعتمد على ذاكرة العملية، فهذه فرصة لفحص السلوك عند انقطاع الاتصال وتقدير تكلفة الجلسات الطويلة. تسد Sticky Sessions فجوة بنيوية محددة: فهي تتيح الجمع بين الإضافة التلقائية للحاويات وإعادة المستخدم إلى عملية قيد التشغيل. وتبقى خطة التعافي من الأعطال جزءًا من بنية التطبيق.