بنية تدفق RTSP للتحجيم التلقائي مع منسقين مزدوجين وتصفير فقدان الحزم
احتاجت منصة مراقبة إلى توسيع نطاق بنيتها التحتية لتدفق الفيديو ديناميكيًا — للتعامل مع أي عدد يتراوح من 10 إلى أكثر من 200 كاميرا IP مع مئات المشاهدين المتزامنين وعمال معالجة AI — مع ضمان عدم فقدان الحزم أثناء عمليات التحجيم والحفاظ على عناوين URL ثابتة للتدفق لا تتغير أبدًا.
ناقش مشروعك
التحدي
لم تتمكن البنية التحتية الثابتة للتدفق من التعامل مع المتطلبات المتغيرة لمنصة مراقبة متنامية:
- تقلب التحجيم — تذبذب عدد الكاميرات وطلب المشاهدين بشكل كبير على مدار اليوم (نسبة الذروة إلى القاع 10x)
- تكلفة التزويد الزائد — كان التزويد لحمل الذروة يعني أكثر من 70% من الموارد الخاملة خلال ساعات خارج الذروة
- فقدان الحزم أثناء التحجيم — أدت إضافة أو إزالة خوادم التدفق إلى انقطاعات في التدفق، مما أدى إلى فقدان الإطارات لعمال معالجة AI
- عدم استقرار عناوين URL — احتاجت الكاميرات والمشاهدون الذين تم تكوينهم باستخدام عناوين IP خادم محددة إلى إعادة تكوين عند تغير البنية التحتية
- احتياجات التحجيم المختلفة — كان لاستيعاب الكاميرات وتوزيع المشاهدين أنماط تحميل مختلفة جوهريًا تتطلب تحجيمًا مستقلاً
- تعطيل عمال AI — تعطلت خطوط أنابيب معالجة AI عندما تم تقليص خادم التدفق المصدر الخاص بها
حلنا
لقد صممنا بنية تدفق للتحجيم التلقائي بمنسقين مزدوجين مع مجموعات منفصلة للاستيعاب والتوزيع، وإيقاف تشغيل تدريجي من 5 مراحل لتصفير فقدان الحزم، وعناوين URL ثابتة تعتمد على DNS، وإعادة اتصال تلقائية لعمال AI.
البنية
- خادم التدفق: MediaMTX لدعم بروتوكولات RTSP/WebRTC/HLS
- مجموعة الاستيعاب: 1-10 خوادم تستقبل تدفقات RTSP للكاميرات
- مجموعة التوزيع: 2-20 خادمًا تخدم المشاهدين (WebRTC/HLS) وعمال AI (RTSP)
- المنسقون المزدوجون: وحدات تحكم تحجيم مستقلة للاستيعاب والتوزيع
- موازنات التحميل: موازنات تحميل منفصلة لكل مجموعة مع خوارزميات مناسبة للبروتوكول
- سجل الخدمات: Redis لحالة الخادم، وتعيينات التدفق، والتنسيق
- مراقبة الصحة: فحوصات صحية نشطة مع استعادة تلقائية
- طبقة DNS: أسماء نطاقات ثابتة تشير إلى موازنات التحميل (URLs لا تتغير أبدًا)
تصميم المنسق المزدوج
لماذا منسقان اثنان
يمتلك الاستيعاب والتوزيع خصائص تحجيم مختلفة جوهريًا:
- يتدرج الاستيعاب مع عدد الكاميرات وعرض النطاق الترددي الوارد (يمكن التنبؤ به، ينمو باطراد)
- يتدرج التوزيع مع عدد المشاهدين وطلب عمال AI (متفجر، لا يمكن التنبؤ به)
يسمح المنسقون المنفصلون لكل منهما بالتوسع بشكل مستقل مع سياسات ومقاييس وعتبات متخصصة — دون أن تؤثر قرارات التحجيم الخاصة بإحدى المجموعات على الأخرى.
منسق الاستيعاب
- المقياس الأساسي: اتصالات الكاميرا لكل خادم
- المقياس الثانوي: استخدام عرض النطاق الترددي الوارد
- التحجيم التصاعدي: عندما يتجاوز CPU العتبة أو تتجاوز الكاميرات لكل خادم السعة
- التحجيم التنازلي: عندما ينخفض الاستخدام عن العتبة لفترة استقرار مستدامة
- نطاق الخوادم: من 1 إلى 10 خوادم
منسق التوزيع
- المقياس الأساسي: اتصالات المشاهدين + عمال AI لكل خادم
- المقياس الثانوي: استخدام عرض النطاق الترددي الصادر
- التحجيم التصاعدي: عندما يتجاوز CPU العتبة أو تتجاوز الاتصالات لكل خادم السعة
- التحجيم التنازلي: عندما ينخفض الاستخدام عن العتبة لفترة مستدامة (فترة استقرار أطول من الاستيعاب)
- نطاق الخوادم: من 2 إلى 20 خادمًا (حد أدنى 2 لضمان التوافر العالي)
تصفير فقدان الحزم: إيقاف تشغيل تدريجي من 5 مراحل
عندما يتم جدولة خادم توزيع للإزالة، تضمن عملية من 5 مراحل عدم فقدان أي إطارات:
المرحلة 1: الإشعار المسبقيتم وضع علامة "DRAINING" (استنزاف) على الخادم في سجل الخدمات. يتم تقليل وزن موازن التحميل بحيث يتم توجيه الاتصالات الجديدة إلى مكان آخر. تنبه إشعارات Redis pub/sub و webhooks عمال AI للاستعداد للترحيل.
المرحلة 2: تحديث موازن التحميلتمت إزالة الخادم من مجموعة الواجهة الخلفية لموازن التحميل. لا يمكن لأي اتصالات جديدة الوصول إلى الخادم الذي يتم استنزافه. تستمر الاتصالات الحالية دون انقطاع.
المرحلة 3: ترحيل عامل AIينفصل عمال AI عن الخادم الذي يتم استنزافه ويعيدون الاتصال بخوادم التوزيع السليمة. يضمن الحفاظ على الحالة المستند إلى نقطة تفتيش استئناف المعالجة من الإطار المحدد الذي توقفت عنده. الفجوة الكلية: حوالي 3 ثوانٍ مع عدم فقدان أي إطارات.
المرحلة 4: استنزاف المشاهدينتُستنزف اتصالات المشاهدين المتبقية بشكل طبيعي خلال نافذة قابلة للتكوين. تعيد مشغلات الفيديو الحديثة الاتصال تلقائيًا بنفس URL الثابت، والذي يوجه إلى خوادم سليمة. معظم المشاهدين لا يواجهون أي انقطاع.
المرحلة 5: التنظيفالتحقق من إغلاق جميع الاتصالات. إزالة الخادم من سجل الخدمات. تدمير مثيل السحابة. تسجيل مقاييس التحجيم.
عناوين URL ثابتة
تضمن بنية URL أن الكاميرات والعملاء لا يحتاجون أبدًا إلى إعادة تكوين:
- هدف نشر الكاميرا: اسم نطاق استيعاب ثابت
- هدف وصول المشاهد/AI: اسم نطاق توزيع ثابت
- تشير سجلات DNS إلى عناوين IP لموازنات التحميل (وهي دائمة)
- تتعامل موازنات التحميل مع التوجيه إلى الخوادم الخلفية بشفافية
- يمكن إضافة الخوادم الخلفية أو إزالتها أو استبدالها دون تغييرات في URL
سجل الخدمات (Redis)
تقوم مثيل Redis مركزي بتنسيق النظام بأكمله:
- تتبع حالة الخادم (نشط، قيد الاستنزاف، غير متصل)
- تعيين التدفق إلى الخادم (أي كاميرا على أي خادم استيعاب)
- حالة عامل AI وبيانات نقطة التفتيش
- مقاييس التحميل لكل خادم لقرارات التحجيم
- قنوات Pub/sub لأحداث التنسيق في الوقت الفعلي
إعادة اتصال عميل AI
توفر مكتبة عميل AI إعادة اتصال سلسة:
- تستمع لإشعارات إزالة الخادم عبر Redis pub/sub
- التخزين التلقائي لنقاط تفتيش الإطارات على فترات منتظمة
- إعادة الاتصال بخادم توزيع سليم عند الإشعار
- استئناف المعالجة من نقطة التفتيش بحد أدنى من الفجوة
- الإبلاغ عن المقاييس لأحداث إعادة الاتصال
مراقبة الصحة
- فحوصات صحية نشطة على كل خادم على فترات منتظمة
- تحديثات تلقائية لموازن التحميل عند فشل الخوادم
- محفزات الاستعادة التلقائية للخوادم غير المستجيبة
- تتبع وقت التشغيل والإبلاغ عن التوافر
الميزات الرئيسية
- منسقون مزدوجون — تحجيم مستقل لمجموعات الاستيعاب والتوزيع
- تصفير فقدان الحزم — إيقاف تشغيل تدريجي من 5 مراحل مع ترحيل عمال AI
- عناوين URL ثابتة — يضمن التوجيه المستند إلى DNS عدم تغيير عناوين URL أبدًا أثناء التحجيم
- إعادة اتصال عامل AI — ترحيل مستند إلى نقطة تفتيش بفجوة ~3 ثوانٍ وبدون فقدان للإطارات
- تحجيم مستقل — يتدرج الاستيعاب والتوزيع بناءً على مقاييسهما الخاصة
- سجل الخدمات — تنسيق يعتمد على Redis لحالة الخادم وتعيينات التدفق
- مراقبة الصحة — فحوصات نشطة مع استعادة تلقائية
- تحسين التكلفة — تحجيم تنازلي تلقائي خلال فترات الطلب المنخفض
النتائج
المكدس التقني
caseStudyDetail.more دراسات الحالة
استكشف المزيد من تطبيقاتنا التقنية
معالجة الفواتير المدعومة بـ AI باستخدام OCR ودمج QuickBooks
كانت شركة متوسطة الحجم تعالج مئات فواتير الموردين شهريًا بحاجة إلى التخلص من إدخال البيانات يدويًا عن طريق استخلاص بيانات الفاتورة تلقائيًا باستخدام AI/OCR ومزامنتها مباشرةً مع QuickBooks للمسك الدفتري وتتبع المدفوعات.
إدراج الإعلانات من جانب العميل (CSAI) مع تحليل علامات SCTE-35 وتكامل مشغلات متعددة المنصات
احتاجت منصة بث الفيديو إلى تطبيق إدراج الإعلانات من جانب العميل (CSAI) عبر تطبيقات الويب والجوال والتلفزيون الذكي المتصل – مما يتيح تجارب إعلانية مخصصة على مستوى الجهاز مع دعم كامل لتفاعل الإعلانات (تراكبات قابلة للنقر، إعلانات مصاحبة، أزرار تخطي) التي لا يمكن لتضمين الإعلانات من جانب الخادم توفيرها.
الأسئلة الشائعة
نفذت MicrocosmWorks تصميم orchestrator مزدوج active-active حيث يحافظ كلا الـ orchestrator على حالة متزامنة حول تعيينات البث وصحة الـ worker، مع ميزة failover تلقائي تنقل إدارة البث إلى الـ orchestrator الناجي في غضون ثوانٍ إذا فشل أحدهما. هذا يلغي نقطة الفشل الفردية التي تعاني منها تصميمات الـ orchestrator الفردية التقليدية، مما يضمن عدم فقدان أي حزمة أثناء صيانة الـ orchestrator أو الأعطال غير المتوقعة.
صممت MicrocosmWorks آلية إفراغ رشيق حيث يواصل العاملون الذين يتم إخراجهم من الخدمة تقديم التدفقات المخصصة لهم حتى يتم ترحيل جميع الاتصالات بسلاسة إلى عاملين جدد عبر تسلسلات RTSP TEARDOWN و re-SETUP. يتم تهيئة العاملين الجدد بالكامل وفحص سلامتهم قبل استلام مهام التدفق، وتستخدم عملية الانتقال نوافذ متداخلة حيث يخدم كل من العاملين القدامى والجدد نفس التدفق لفترة وجيزة لمنع أي انقطاع.
اختارت MicrocosmWorks MediaMTX لهذا المشروع لأنه خفيف الوزن، ومفتوح المصدر، ومصمم خصيصًا لإعادة بث RTSP بأقل قدر من استهلاك الموارد لكل بث مقارنة بخوادم الوسائط كاملة الميزات. يدعم إنشاء البث الديناميكي عبر API، ويعمل بكفاءة في الحاويات لعمليات التوسع التلقائي القائمة على Kubernetes، ويتجنب تكاليف الترخيص لكل بث للبدائل التجارية مثل Wowza التي يمكن أن تصبح باهظة التكلفة عند التوسع.
نشرت MicrocosmWorks مكدس قابلية مراقبة شامل يتتبع المقاييس لكل بث، بما في ذلك معدل فقدان الحزم، والتذبذب، وعدد مرات إعادة الاتصال، وزمن الانتقال من البداية إلى النهاية، مع تنبيهات يتم إطلاقها قبل أن يصبح التدهور مرئيًا للمستخدمين النهائيين. كما يتتبع نظام المراقبة مقاييس اتخاذ القرار للمنسق مثل أحداث التحجيم، ومدد ترحيل البث، واتجاهات استخدام العمال لتمكين التخطيط الاستباقي للقدرة.
نعم، صممت MicrocosmWorks الـ worker nodes لدعم مخرجات RTSP المتزامنة للمشاهدين المباشرين والتسجيل المجزأ إلى object storage، مع تخصيص موارد مستقل لكل عبء عمل. يستخدم التسجيل write path منفصلًا يقوم بتخزين الأجزاء محليًا مؤقتًا قبل التحميل، وبذلك فإن ارتفاعات I/O التخزين لا تؤثر أبدًا على تسليم البث المباشر، ويأخذ الـ auto-scaler في الاعتبار الطلب المجمع للموارد لكلا أعباء العمل عند اتخاذ قرارات التوسع.
مستعد لتحويل عملك؟
دعنا نناقش كيف يمكننا تطبيق حلول مشابهة لتحدياتك.