تصميم النظام لخدمة تدفق الصوت

تصميم نظام تطبيق بث الصوت فريد من نوعه في كيفية تعامله مع احتياجات الأعمال الغريبة. عادةً ما يتطلب بث الصوت كمية كبيرة من البيانات ليتم نقلها ضمن عرض النطاق الترددي المحدود لقناة الاتصال الشبكي.

يجب على خدمة بث الصوت الناجحة التعامل مع الملايين من المستخدمين النشطين وآلاف من مقدمي المحتوى من مواقع جغرافية متنوعة. قد تدعم أجهزة ومنصات مختلفة (الهاتف الذكي، الكمبيوتر المكتبي، السماعة الذكية) صيغ صوتية مختلفة مثل MP3، FLAC، ALAC، وما إلى ذلك.

في هذا المنشور، سنستكشف تفاصيل تصميم مثل هذا النظام المعقد الذي يغطي المتطلبات الوظيفية وغير الوظيفية.

المتطلبات الوظيفية

ستغطي المتطلبات الوظيفية الميزات المطلوبة لمبدعي المحتوى ومستخدمي أو مستمعي الصوت.

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

ملاحظة: خدمات البث المباشر والدفع خارج نطاق هذه المقالة.

رسم تسلسلي لحالة الاستخدام الوظيفية

التصميم المعماري

لنحدد مكونات الخدمة لدعم المتطلبات الوظيفية.

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

1. ترميز بدون فقد – يضغط الصوت دون فقدان أي بيانات ويمكن استعادته بالكامل دون فقدان الجودة.
2. ترميز بفقد – يزيل بعض البيانات مما يساعد في تقليل الحجم بشكل كبير. يمكن أن يؤثر هذا على جودة الصوت.

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

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

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

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

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

 

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

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

يمكن للمستخدم الصوتي (المستمع) البحث عن الصوت الذي يهمه، والذي سيتم توجيهه إلى خدمة بيانات الصوت لإرجاع موقع الصوت المتعلق، من خلال جلب المعلومات من مخزن بيانات الصوت. ينقر المستخدم على الرابط، وسيتم إرجاع بايتات الصوت المعبأة والمخزنة بواسطة خدمة التعبئة.

تدير خدمة ملف تعريف المستخدم تفضيلات المستخدم، والمتابعين، والمتابعات.

يصور الرسم البياني أعلاه سير العمل الأساسي “تحميل الصوت” الذي يتم تشغيله بواسطة مقدم المحتوى وسير العمل “استماع إلى الصوت” الذي يتم تشغيله بواسطة مستخدم/مستمع الصوت.

يتم استخدام نمط تصميم الأنبوبة والتصفية مع تخزين الرسائل لدعم تدفق البيانات بين الخدمات لتوسيع العملية بكفاءة مع متعددية التوازي ومقاومة الأخطاء.

الآن، دعونا ننتقل إلى المتطلبات غير الوظيفية.

المتطلبات غير الوظيفية

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

التوسيع 

يجب أن يكون النظام الصوتي قادرًا على دعم آلاف من مبدعي المحتوى النشطين. لإدارة الحمل، يتضمن التصميم تشغيل عدة حالات من خدمة بوابة الواجهة البرمجية (API Gateway)، وخدمة الويب التطبيقية (App Web service)، وخدمة بيانات الصوت (Audio Data service) مع واجهات تحميل أمامية بواسطة موازنين حمولة.

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

تغطي هذه المتطلبات القابلية للتوسع لرفع ملفات الصوت من قبل مقدمي المحتوى.

يمكن أن تصل الملايين من طلبات البحث من مستمعي الصوت إلى النظام، مما يؤدي إلى تحميل خدمة بيانات الصوت. لتوسيع النظام الداعم لهذه العملية الضخمة للبحث، يمكن استخدام نمط تصميم فصل مسؤولية الاستعلام عن المحتوى (CQRS). يمكن إدارة عمليات القراءة والكتابة من/إلى متجر البيانات بشكل مستقل، داعمًا لمتطلبات مختلفة للتأخير، والقابلية للتوسع، والأمان.

 

تحمل الأعطال

هناك أبعاد مختلفة لتصميم تحمل الأعطال. بعضها مضمن بالفعل في التصميم.

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

الأداء

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

الأمان

تحسن خدمة توزيع المحتوى عبر الشبكة العالمية أداء الأمان من خلال توفير الوقاية من هجمات إنكار الخدمة الموزعة (DDoS) وبعض التدابير الأمنية الأخرى.

سوف توزع خدمة الحزم الملفات الصوتية إلى شبكات توزيع المحتوى لتخزينها على خوادم الحواف. ستقوم خدمة بيانات الصوت بتحديث موقع شبكة توزيع المحتوى في البيانات الوصفية الخاصة بها التي ستتم توجيهها إلى خدمة البحث للاستعلام عنها من قبل المستخدمين.

 

تصور الرسم البياني أعلاه الهندسة المكونات الرئيسية على مستوى عالٍ لنظام صوتي نموذجي.

الاستنتاج

في قلب نظام صوتي جيد تكون التطويلية والأداء والمرونة لضمان تجربة مستخدم جيدة مع تشويش أدنى وتأخير منخفض وموثوقية.