Как спроектировать набор услуг RTC PaaS?

В настоящее время существует две распространенные формы услуг аудио- и видеосвязи в реальном времени RTC (коммуникация в реальном времени): SaaS (программное обеспечение как услуга) и PaaS (платформа как услуга).^[1]

Услуги SaaS, как правило, представляют собой большую коллекцию. Например, сценарии онлайн-обучения включают в себя не только службы RTC, но также ряд гарантий базовых услуг, необходимых для процессов онлайн-класса, и ряд учебных пособий для повышения эффективности и опыта занятий, таких как службы обмена мгновенными сообщениями, системы управления курсами, интерактивные учебные программы и электронные доски, воспроизведение по запросу и т. д.

Услуги PaaS ориентированы на возможность передачи аудио и видео в режиме реального времени, полагаясь на предварительную обработку звука 3A (эхоподавление, шумоподавление и алгоритм автоматической регулировки усиления), аудио- и видеокодек, передачу по каналу, меры противодействия слабой сети, планирование сети и другие технологии для предоставления пользователям высококачественных доступных высококачественных услуг аудио- и видеосвязи с малой задержкой. Пользователи могут быстро создавать многотерминальные приложения в реальном времени, интегрируя SDK разных платформ, и реализовывать голосовые вызовы, видеозвонки, интерактивные аудиотрансляции в прямом эфире, интерактивные видеотрансляции и т. д. в проекте, подходящем для онлайн-обучения, видеоконференций, интерактивные развлечения, аудио и видео социальные и другие сценарии.

1. Проблемы и трудности, с которыми пришлось столкнуться

Прежде всего, начиная с требований и проблем, для общедоступной облачной службы RTC PaaS, различий в получении, кодировании, сетевой отправке, сетевом приеме, декодировании и рендеринге аудио- и видеооборудования на разных платформах. как использовать текущие службы обеспечения высокой доступности, высококачественных аудио- и видеовызовов с малой задержкой в ​​сложных и нестабильных общедоступных облачных средах, и некоторые из них в основном влияют на аудио и видеоQOS(Quality of Service)элементы^[2]В основном он включает следующие аспекты:

• Задержка/задержка
• Потеря сетевых пакетов (Packect Loss)
• Доставка вне очереди
• Сетевой джиттер (джиттер)
• Перегрузка пропускной способности/перегрузка сети

Поэтому особое значение имеет то, как спроектировать архитектуру службы, обеспечить высококачественный и эффективный сетевой канал передачи, а также ряд средств или стратегий для обеспечения QOS аудио и видео в условиях слабой сети. Для сетевого уровня часто приоритетом является решение проблемы последней мили пользователей, которая также унаследована от идеи традиционного граничного узла или CDN.

2. Сервисная архитектура RTC

В соответствии с разделением функций разработать полный набор услуг RTC PaaS.^[3], что необходимо сделать:

• Планировщик (координатор)

  Поскольку независимо от того, как алгоритм сжатия и код оптимизированы, сеть по-прежнему является решающим фактором, который вносит большую часть задержки.Архитектура службы должна предоставлять механизм, гарантирующий, что пользователи получают доступ к оптимальному медиаузлу с наименьшей нагрузкой поблизости, чтобы уменьшить RTT (время прохождения туда и обратно) и обеспечить максимально возможное качество сети последней мили пользователей, это значение сервера планирования.

  Как показано в шагах 1 и 2 выше, когда новый пользователь получает доступ к службе RTC, он сначала запрашивает у сервера планирования список доступных медиасерверов, а сервер планирования получает информацию о географическом местоположении пользователя и операторе через внешнюю сеть пользователя. IP-адрес, переданный в запросе. , возвращает список медиасерверов в соответствии с определенной стратегией, а затем на шаге 3 клиент определяет сетевые условия в реальном времени со всеми медиасерверами-кандидатами с помощью сообщений ping, чтобы выбрать лучший медиасервер. для двухтактной потоковой передачи. Список состояний сети, полученный этими зондами, особенно информация о задержке, будет возвращен на сервер планирования позже, чтобы он мог более точно выделить наиболее подходящий медиасервер для обслуживания новых пользователей в будущем.

• Сигнальный сервер

  Разработка системы видеоконференцсвязи, согласование сигналов и взаимодействие с сообщениями является важной частью, но я всегда выступал за:«Световая сигнализация и тяжелые носители»,«Исходя из предпосылки обеспечения необходимого взаимодействия с сообщением, максимально уменьшите количество взаимодействий с сообщением и размер тела сообщения. Как это может быть просто?». Для проектирования сервера сигнализации рекомендуется быть кратким и достаточным. Как показано на рисунке выше, предлагается идея поставить «легкую и тонкую» службу сигнализации на стороне медиасервера, что не только удобнее в обслуживании, но и медиасервер может предоставлять услуги независимо от других служб. , Даже если другие службы работают ненормально, это не будет затронуто. Кроме того, тестирование и устранение неполадок стали более эффективными и удобными. Недостатком является то, что для сервера планирования получаемая информация о медиапользователях ограничена, а оценка и контроль потребления нагрузки не могут быть очень точными.

  Здесь я хочу обсудить вопрос,«Обязательно ли услуги RTC PaaS требуют концепции конференции, канала или помещения?»

  Для этой проблемы, я думаю, ее можно абстрагировать как проблему «длинного соединения против короткого соединения», потому что для концепции одной и той же встречи или комнаты большая часть прослушивания исходит от обмена мгновенными сообщениями. Люди могут немедленно получать или потреблять сообщения. отправленные другими, и может воспринимать онлайн или оффлайн статус других. Для услуг RTC PaaS в настоящее время пользователи могут использовать два способа:

  1. «Нет понятия встречи, комнаты, и услуга долгосрочного подключения не упакована». При использовании SDK для потоковой передачи push-pull пользователю не нужно сначала присоединяться к Channel или JoinRoom, а нужно только выбрать оптимальный узел для потоковой передачи push-pull после получения списка медиасервисов через сервер планирования. В настоящее время служба RTC PaaS сама не может отслеживать присоединение и уход участников.Для потокового действия он может полагаться только на регулярные повторные попытки SDK, чтобы убедиться, что он не может обеспечить публикацию сообщений (Publish) и подписку (Subscribe). ). Преимущество, конечно, в том, что нет необходимости разрабатывать новую услугу, подобную IM.Также непросто создать стабильную и эффективную службу IM с долгосрочным подключением, а логика разработки и процесс вызова очень просты; наоборот, некоторыми вещами приходится жертвовать, например, SDK side pull Потоковые действия необходимо повторять постоянно, что не очень элегантно Кроме того, из-за отсутствия долгосрочных подключений сервер не может воспринимать фактический онлайн-статус клиента, например сбой клиента, и многие сообщения не могут быть запущены в обычном режиме. Для некоторых задач уничтожение сеанса или записи сильно зависит от поступления сообщений на сторону, в противном случае для очистки можно полагаться только на тайм-аут.

     Подходящие сценарии: многие бизнес-пользователи часто имеют свои собственные службы обмена мгновенными сообщениями, поскольку текущее долгосрочное онлайн-соединение приложений и отправка сообщений, лайков и подарков в комнате прямой трансляции в основном стали стандартом, поэтому они могут полагаться на службы верхнего уровня, канальные сообщения для реализации публикации и подписки на сообщения, тем самым определяя синхронизацию потоков push и pull.

  2. "Концепция встречи и зала, пакетная услуга длительной связи". В отличие от первого случая, в этом случае необходимо предоставить пользователям стабильные и эффективные службы обмена мгновенными сообщениями.В общем случае для этого можно использовать веб-сокет + очереди сообщений (например, RabbitMQ).До того, как пользователь использует SDK для отправки и pull streams , вы должны сначала присоединиться к Channel или JoinRoom, а затем вы можете подписаться или получать сообщения, чтобы вы могли обрабатывать соответствующие обратные вызовы после получения уведомлений, когда другие присоединяются, покидают комнату или отправляют потоки. Соответственно, за счет наличия длинных подключений сервер может точно воспринимать статус клиента, а когда пользователь находится в офлайне, вовремя очищать сессию задачи или записывать.

     Подходящий сценарий: Некоторые небольшие компании не имеют возможности разрабатывать собственные службы обмена мгновенными сообщениями. С их точки зрения, они могут предоставить мне законченное решение. Мне не нужно заботиться о других технических деталях, просто нужно знать, что тип событий Обратный вызов выполняет все, что вызывается.

  На уровне сигнализации я также хочу обсудить, что tcp явно уступает udp с точки зрения производительности против слабых сетей, поэтому часто бывают ситуации, когда передача мультимедиа все еще может быть сигнальной, но не может быть установлена, поэтому рекомендуется попробуй udp на уровне сигнализации.надежная передача, напримерQUICЖдать.

• Медиа-сервер (медиа-сервер или потоковый сервер)

  Все медиа-серверы полностью независимы.Когда сервер присоединяется или покидает сеть RTC, система может автоматически регулировать его распределение, не позволяя пользователям воспринимать и влиять. В случае высокой нагрузки можно выполнить «горизонтальное масштабирование» за счет добавления новых сервисов развертывания машин.

  Медиа-серверы обычно можно разделить на две категории в зависимости от топологии сети.^[4]:"SFU (выбранный передовой блок)"а также"MCU (многоточечный блок управления)”.

Как показано на рисунке, SFU отвечает только за пересылку медиапотоков и не выполняет слишком сложную сложную обработку медиа.Узким местом является ввод-вывод, а возможность параллелизма высока. В дополнение к приему/отправке медиапотоков MCU также необходимо выполнять транскодирование и микширование потоков, что требует высокой производительности сервера, высоких затрат на развертывание сервисов, узких мест ЦП, плохих возможностей параллелизма и небольшого количества пересылаемых потоков.Это приводит к дополнительной задержке и производительность в режиме реального времени несколько ниже; преимущество заключается в том, что полоса пропускания нисходящей линии связи менее занята, а требования к пропускной способности и оборудованию на стороне пользователя низкие.

Для сценариев конференций с высокими требованиями к работе в реальном времени и высокому параллелизму чаще выбирается архитектура SFU. С продвижением технологии 5G в будущем можно предвидеть, что пропускная способность будет становиться все меньшей и меньшей проблемой, а преимущества SFU станут более очевидными.

Однако в реальных бизнес-сценариях архитектура службы часто представляет собой гибридный подход SFU+MCU для удовлетворения потребностей бизнеса. Так вот вопрос, как сделать MCU и SFU вместе? То есть услуга может быть перенаправлена ​​или смешана, или SFU и MCU полностью независимы, а медиаузлы на пути пересылки — все чистые SFU?

Поскольку с точки зрения потока обработки мультимедиа и функционального уровня, SFU можно рассматривать как подмножество MCU, а MCU поддерживает определенные возможности пересылки.Также имеет функцию SFU).

Как показано на рисунке, рекомендуется, чтобы разные возможности реализовывались разными узлами.^[5]Например, узел SFU службы пересылки отвечает за пересылку мультимедиа и трансграничное каскадирование, а узел MCU сервера микширования загружает транскодирование, микширование звука и потоковую передачу, поскольку конструкция службы может быть максимально простой, связь низка, и стратегия планирования для различных типов услуг также может быть намного проще, уменьшая сложность всей системы и повышая эффективность.

Для полного набора услуг PaaS в режиме реального времени часто необходимо дополнить различные возможности.Помимо вышеперечисленных типов медиауслуг, также необходимо:

"Облачный сервер записи (RTP в flv или mp4)"а также"Облачный ретвит-сервер (RTP в RTMP)»., облачная запись в основном используется для воспроизведения по запросу, а облачный ретвит в основном используется для обхода прямых трансляций, снижения нагрузки на узлы пересылки и снижения затрат в сценарии 1vsN. Как показано на рисунке выше, как SFU, так и MCU могут использоваться в качестве входных терминалов для облачной записи и облачного ретвита, и по аналогии могут быть выбраны различные методы вывода медиапакетов. Кроме того, живая запись CDN RTMP также может использоваться для воспроизведения и по запросу.Однако с увеличением количества ссылок увеличивается и вероятность соответствующих проблем.Необходимо сделать разумный выбор, исходя из формы бизнеса и Стадия НИОКР.

Если это частный протокол, для поддержки веб-стороны необходимо спроектировать и разработать «шлюз WebRTC» для преобразования сигналов и мультимедиа.

3. Эволюция сетевой архитектуры

История всегда поразительно похожа.Вы можете обратиться к развитию и эволюции архитектуры прямых трансляций RTMP, потому что, по сути, проблемы, которые должны решать прямые трансляции RTMP и RTC, одинаковы на сетевом уровне.

• Первый этап,«Режим происхождения из одного региона», каждый регион отправляет и извлекает потоки с исходного сайта. Как показано на рисунке выше, очевидно, что эффект двухтактной потоковой передачи не может быть гарантирован при пересечении регионов и операторов.

• вторая стадия,«Многорегиональный и многоканальный режим BGP + частная линия с каскадным возвратом к источнику», как показано на рисунке выше, может эффективно улучшить состояние сети между пользователем и сервером. Alibaba Cloud ECS представляет собой многолинейный компьютерный зал BGP.Различные области соединены выделенными линиями для поддержания каскадного соединения.По сравнению с магистральной сетью оператора условия в сети намного стабильнее.Однако эта модель очень дорогая, а устройство цена многоканальных машинных залов BGP очень высока в зависимости от трафика.Кроме того, для Alibaba Cloud ECS не каждый регион имеет соответствующий VPC, некоторые регионы не могут нормально покрываться, и каждый раз, когда вводится новый узел, это может быть необходимо выкупить выделенную линию.Некоторые частные линии между узлами также ограничены физическими факторами, такими как внутренние оптические кабели за границей, которые выходят только из Восточного Китая и Шанхая.

  На этом этапе необходимо провести «разумное зонирование» по актуальным потребностям.,«Точка-точка развертывания»а также«Настроить определенную стратегию планирования»**, например, назначить комнату в той же области одному и тому же серверу, насколько это возможно, чтобы избежать каскадирования; динамически генерировать маршруты в соответствии с топологией сети фактического макета, когда пользователи тянут потоки, выбирают оптимальный путь через сервер планирования, динамический возврат к источнику; предотвращение потребления полосы пропускания выделенной линии при определенных обстоятельствах и одновременный мониторинг использования полосы пропускания выделенной линии, когда она превышает определенный порог, тревога и использование внешней сети связь во избежание схода лавин.

• Третий этап,«Multi-Region Edge Uode (INS) Access + Multi-Line BGP (ECS) Кросс-регион и перекрестный транзит + Cloud Enterprise Network (CEN) режим (CEN)». Как показано на рисунке выше (украл лень~😊), один и тот же оператор в одной области осуществляет передачу через граничные узлы, в случае разных регионов или разных операторов каскадная передача осуществляется через ЭКС, и разные ЭКС взаимодействуют друг с другом через облачную корпоративную сеть, выделенную линию связи. По сравнению с узлами ECS, ENS граничного узла имеет более широкое покрытие, меньшую стоимость и лучшую масштабируемость топологии сети; облачная корпоративная сеть может помочь пользователям избежать проблем с подключением двух или двух выделенных линий при внедрении новых узлов VPC и может совместно использовать ресурсы пропускной способности между частные линии не связаны со структурой и физическими ограничениями фактической топологии сети частных линий Маршрутизация между VPC гарантируется Alibaba Cloud, который более удобен в использовании и более удобен и эффективен для расширения узлов. Надо сказать, что Alibaba Cloud действительно думает о том, чтобы решить болевые точки пользователей, и в то же время привлекать клиентов, а также добиваться себя.

• четвертый этап,«Модель стандартизации пограничных узлов CDN+WebRTC». На этом также основывается исторический закон развития RTMP-прямого вещания, и он до сих пор находится в идеальном и нереализованном состоянии. Насколько мне известно, крупные поставщики облачных услуг также прилагают усилия. Поставщики облачных услуг поддерживают стандартный протокол WebRTC в службах CDN на граничных узлах. Пользователям не нужно поддерживать свои собственные исходные сайты и серверы, а достаточно получить доступ к оптимальной сети CDN поблизости для потоковой передачи push-pull. Сетевой канальный уровень гарантируется облаком. продавец. . Однако для того, чтобы это осознать, потребуется много времени. В будущем для небольших заводов аудио- и видеовзаимодействие в режиме реального времени необходимо будет проводить только в соответствии со стандартом согласования сигналов и потоковой передачи мультимедиа, что не только значительно снижает затраты на разработку и обслуживание, но и обеспечивает более высокий уровень обслуживания. Для тех, у кого особые требования к настройке и сценарии, соответствующая гибкость будет меньше.

4. Тенденция развития и предназначение аудио- и видеоиндустрии.

Быстрое развитие Интернета ускорило распространение информации, изменило жизнь людей, а также способствовало постоянному обновлению и повторению технологий. С неустанным стремлением людей к аудио- и видео-сенсорному опыту появились различные формы аудио- и видеоприложений, влияющих на жизнь людей и изменяющих их привычки. В развитии технологий, ориентированных на ценность, различные технологии поднялись от подъема до популярности, а затем стали популярными, порог изменился с высокого на низкий, а высокая стоимость небольших мастерских стала единой ценой на капусту. Интернет постоянно меняет жизнь мира, а развитие технологий меняет и жизнь программистов.Эпоха сидения на горе с технологией давно закончилась.Остались постоянные предтечи и боль 35 лет. . По сравнению с другими областями, аудио- и видеоиндустрия имеет относительно высокую степень специализации, но все же не может избежать закона обобществленного массового производства.

До и после накопление талантов в отечественной аудио- и видеоиндустрии происходит примерно из трех эпох:

• «Эпоха игроков.«Соответствующая форма заявки есть»Видео по запросу и короткие видео», Приложения по требованию включают Tencent Video, iQiyi, Youku, Mango TV, сокращающиеся Sohu Video, LeTV, Tudou и т. д. Приложения для коротких видео включают Douyin и Kuaishou. Требуемый стек технологий - это игрок +ffmpeg, отдать должное ffmpeg, он реально многих кормит.

• «Эпоха прямых трансляций по протоколу RTMP.«Соответствующие формы заявок: «** развлекательная прямая трансляция, спортивная прямая трансляция, прямая трансляция шоу, прямая трансляция с товарами, онлайн-образование большого класса» ** и т. д. Репрезентативные приложения прямой трансляции включают Huya, Douyu, Yingke, Fallen Panda и т. д. После эпидемии в этом году прямые трансляции стали очень популярными, и кажется, что все компании электронной коммерции стесняются этого не делать. В первые дни роста потокового вещания существовали собственные исходные сайты и CDN, а также были производители, специализирующиеся на CDN, такие как Wangsu, Lanxun, Dilian, Baiyunshan и т. д., и постепенно Tencent Cloud, Alibaba Cloud, Kingsoft Cloud, Huawei Cloud и другие гиганты При переходе на CDN затраты на оплату труда и техническое обслуживание исследований и разработок в области прямых трансляций становятся все ниже и ниже.

  Более зрелый проект с открытым исходным кодом клиента прямой трансляции первым продвигаетOBS, обычно используется серверnginx-rtmp-moduleа такжеSRS.

• «Эпоха РТК.«Форма заявки соответствует «** даже пшенице, аудио- и видеозвонкам, видеоконференциям, онлайн-обучению 1 на 1 и групповым занятиям» ** и т. д., у старых традиционных поставщиков видеоконференций есть Cisco Cisco, Polycom Polycom, Huawei HuaWei, новый Jin Xinxiu Zoom, а также неброский Vidyo и так далее. Программное обеспечение для видеозвонков Apple FaceTime, Microsoft Skype, Google Hangouts и Duo и так далее. Внутренние более известные поставщики RTC PaaS аудио сети Agora, должны составлять технологии Zego, Tencent Ali облака и облака и так далее.

  Хотя VOIP и видеоконференцсвязь развивались за границей в течение многих лет, до 2017 года они все еще были нишевым рынком, и накопление технических талантов было ограниченным. Я должен упомянуть, что Google открыл исходный код в 2011 году.WebRTC, До появления WebRTC аудио- и видеосвязь в реальном времени была недостижимой областью, требующей большого профессионального опыта, чтобы начать работу.Теперь все больше и больше разработчиков используют WebRTC для глубокого понимания технологии RTC. Мне тоже посчастливилось познакомиться с ней в 2014 году, с нетерпением жду того времени, когда стандарт WebRTC будет унифицирован, и я буду есть мясо старым гугловским железом.

  Ссылаясь на четвертый этап «Эволюции сетевой архитектуры» выше, как и на процедуру разработки прямой трансляции, осталось только две формы RTC:

  1. Для CDN WebRTC поставщика облачных услуг пользователям нужно использовать только SDK поставщика облачных услуг или собственный настраиваемый SDK для передачи данных на ближайший лучший узел CDN. Сетевое соединение гарантируется поставщиком облачных услуг. Он поддерживает развертывание как в частном, так и в общедоступном облаке. Пользователи могут выбрать дополнительные услуги облачной записи, облачного ретвита, транскодирования и микширования и т. д.
  2. Не прикасайтесь к нижнему слою, выберите самостоятельную сборку в сочетании с непрерывными инновациями передовой бизнес-формы технологии RTC и специализацией или потребностями безопасности небольших заводов.

В наши дни единственной константой являются перемены. С точки зрения разработчика технологий, мы не можем остановить поток истории. Все, что мы можем сделать, это приспосабливаться и приспосабливаться. Нам нужно быть строгими к себе. Что мы можем сделать, так это заложить прочный фундамент, постоянно преодолевать трудности и стремиться быть грамотным и профессиональным.

Приветствую всех, кто может оставить сообщение и обменяться мнениями, и приглашаю всех обратить внимание на мой личный общедоступный номер!

Reference

В этой статье используетсяmdniceнабор текста