پرسش طراحی
یک محصول کلاس مجازی معمولاً با دو نیاز متفاوت روبه‌روست: برخی افراد باید همان لحظه در درس مشارکت کنند و برخی دیگر فقط لازم است محتوا را پس از پایان نشست ببینند. برخورد با این دو نیاز به‌عنوان یک مسئلهٔ یکسانِ تحویل محتوا، ابهام ایجاد می‌کند.
این مقاله الگویی معماری برای تفکیک این دو مسیر را توضیح می‌دهد. این متن نه یک بنچمارک منتشرشدهٔ ظرفیت است و نه مطالعهٔ هزینه. مرز اصلی روشن است: مشارکت زنده و دوسویه روی مسیر بلادرنگ قرار می‌گیرد؛ بازپخشی که بعداً در دسترس است روی مسیر با تأخیر قرار می‌گیرد.
تعامل زنده: WebRTC
WebRTC برای بخشی از کلاس مناسب است که زمان‌بندی و ارتباط دوسویه در آن اهمیت دارد: مدرس، مدیر جلسه و فراگیری که باید در نشست جاری صحبت کند، تغییرات را ببیند یا واکنش نشان دهد. یک سرور رسانه مانند LiveKit می‌تواند لایهٔ رسانهٔ بلادرنگ را فراهم کند؛ در حالی که برنامه، مجوزها، سیاست اتاق و وضعیت محصول را بیرون از صفحهٔ رسانه نگه می‌دارد.
پرسش مهم فقط تعداد اتصال‌ها نیست. باید مشخص شود کدام کاربران به مشارکت فوری نیاز دارند، چه رسانه‌ای دریافت می‌کنند و هنگام تغییر نقش چه رفتاری از محصول انتظار می‌رود.
بازپخش بعدتر: HLS
HLS زمانی مفید است که نیاز محصول، محتوای ضبط‌شده یا پردازش‌شده‌ای باشد که بعد از نشست در دسترس قرار می‌گیرد. این مسیر برای بازپخش با تأخیر است، نه جایگزینی برای کاربری که باید همین حالا به کلاس بپیوندد.
شفاف نگه‌داشتن این تفاوت، از یک خطای رایج معماری جلوگیری می‌کند: معرفی HLS به‌عنوان جایگزین زنده بدون تعریف پیامدهای تأخیر، تعامل و مخاطب. کاربری که به رسانهٔ بلادرنگ و دوسویه نیاز دارد، نیاز متفاوتی از کاربری دارد که می‌تواند بعداً ضبط جلسه را ببیند.
رسانه و سیگنالینگ را جدا نگه دارید
مسیریابی رسانه و سیگنالینگ برنامه به هم مرتبط‌اند، اما یک مسئله نیستند. در طراحی عملی، وضعیت اتاق، مجوزها، حضور، اقدام‌های مدیریتی و رویدادهای محصول در لایهٔ کنترل برنامه نگهداری می‌شوند؛ نه اینکه انتظار داشته باشیم ترابری رسانه مالک همهٔ تغییرات وضعیت باشد.
برای هماهنگی رویدادمحور، یک لایهٔ پیام‌رسان پایدار مانند NATS JetStream می‌تواند به تبادل تغییرات وضعیت میان سرویس‌ها کمک کند؛ در حالی که مرز مالکیت‌ها روشن باقی می‌ماند. توپولوژی دقیق به محصول بستگی دارد، اما اصل ثابت است: لایهٔ رسانه برای رسانه است و رویدادهای کسب‌وکار باید قابل مشاهده و مستقل از آن بازیابی‌پذیر باشند.
تغییر نقش باید رویداد محصول باشد
تبدیل یک فراگیر به شرکت‌کنندهٔ فعال فقط تغییر در ترابری نیست. این کار می‌تواند شامل مجوز، سیاست اتاق، وضعیت رابط کاربری، مدیریت جلسه و قابلیت حسابرسی باشد. این ارتقا را به‌عنوان یک رویداد برنامه با نتیجهٔ مشخص مدل کنید و سپس مجوزهای رسانه را به‌روزرسانی کنید.
این رویکرد تحلیل خطا را ساده‌تر می‌کند: سیستم می‌تواند تصمیم مجوزدهی را از خطای اتصال رسانه جدا کند و وضعیت دقیق را به کاربر نشان دهد.
چک‌لیست بازبینی معماری
پیش از انتخاب پروتکل یا اندازه‌گذاری زیرساخت، به این پرسش‌ها پاسخ دهید:
- کدام نقش‌ها به تعامل فوری و دوسویه نیاز دارند؟
- کدام کاربران می‌توانند بازپخش با تأخیر را مصرف کنند؟
- برای هر مسیر چه تأخیری قابل قبول است؟
- مجوزها، وضعیت اتاق و رویدادهای مدیریت جلسه کجا نگهداری می‌شوند؟
- ارتقای نقش چگونه مجاز، قابل مشاهده و در صورت شکست یک عمل پایین‌دستی بازیابی می‌شود؟
- پیش از طرح ادعاهای عملکرد یا هزینه، کدام اندازه‌گیری‌ها واقعاً در دسترس‌اند؟
پاسخ روشن به این پرسش‌ها از یک عدد ظرفیت در عنوان مفیدتر است. این پاسخ به تیم محصول و مهندسی زبان مشترکی می‌دهد تا تصمیم بگیرند کجا WebRTC لازم است و کجا بازپخش با تأخیر تجربهٔ درست است.
مطالعهٔ موردی مرتبط
این راهنمای طراحی یک چارچوب تصمیم‌گیری عمومی و مستقل از پیاده‌سازی HonarAmoozesh است. برای روایتی محدود و مستند از معماری پلتفرمی که از ۵۰۰۰ کاربر همزمان پشتیبانی می‌کرد، شامل مشارکت زنده با WebRTC و بازپخش HLS که چند ساعت پس از نشست در دسترس قرار می‌گرفت، مطالعهٔ پخش زندهٔ WebRTC و بازپخش با تأخیر HLS برای ۵۰۰۰ کاربر همزمان را ببینید.