Livekit-开源实时音视频基础设施介绍

Livekit 是今年开源的一个全栈的RTC解决方案,包括各种版本的sdk以及开箱即用服务端。之所以引起我的关注是这个开源项目背后的团队以及运作方式,相比于其他的WebRTC相关的开源项目,Livekit是由全职的团队在做开源,并且拿到了700w$的融资, 相比于数据库领域火热的开源商业化,这把火也烧到的RTC 基础设施领域。某种意义上也说明了RTC领域越来越成熟,越来越被大家关注。抛开RTC开源商业化之外,livekit本身的设计也有一些可取之处,后面会详细介绍。

项目地址

Livekit:

LiveKit – Open source infrastructure for real time audio and video.

LiveKit · GitHub

快速上手

livekit的后台组件&命令行工具全部打包为docker镜像,这个对于熟悉docker使用的开发者来说非常友好。

第一步是生成配置文件

docker run --rm -v$PWD:/output livekit/generate --local

第二部就是开始运行服务

docker run --rm -p 7880:7880 \
    -p 7881:7881 \
    -p 7882:7882/udp \
    -v $PWD/livekit.yaml:/livekit.yaml \
    livekit/livekit-server \
    --config /livekit.yaml \
    --node-ip <machine-ip>

第三部就可以开始测试了, 这里需要说明的是livekit非常nice的开放了一个自带https的测试网页demo,填入信令地址和token地址即可以体验,大大降低了上手体验的成本,这里其他的产品可以借鉴一下。

线上部署:

如果要线上部署的话也相当简单,livekit 已经提供了线上部署的镜像和docker compose 配置文件。

第一步是生成一个线上的配置文件:

docker run --rm -it -v$PWD:/output livekit/generate

第二步就是安装依赖:

这一步会安装相关的依赖,以及docker compose等等。

需要补充一下的是livekit的默认安装运行是需要依赖caddy这个http server,可以自动帮你解决https证书等问题,对caddy不了解的话需要花费点时间了解caddy。

caddy的依赖不是必须的,你也可以使用nginx或者其他的反向代理服务,这里就不详细展开,具体的可以自己摸索一下。

如果你对caddy和docker 使用比较了解,可以看到就两步就可以跑起来,易用性上livekit确实下了一些功夫。

后台部分特性

后台部分特性我翻了几遍代码和文档总结出几条,我个人认为做的比较好的点:

  • 使用golang开发,上手成本较低,云计算必备编程语言,看两天就能写
  • 单体架构,信令、调度、turn、监控、媒体服务在一个服务上,部署方案简单
  • 支撑单机模式和集群模式,只需要配置一个redis服务就可以完成横向拓展
  • 支持基于位置的DNS解析调度接入
  • 提供基于Prometheus的监控和数据上报
  • 没有user概念,只有房间和track概念,一个peer可以推拉多路流
  • 支持数据通道 — datachannel
  • 支持录制成mp4,转推到rtmp系统

关于节点到节点之间的relay支持暂时没有看到,对这个了解的同学欢迎反馈。

SDK部分

livekit另一个要提的就是全栈的开源方案,包括各个语言和平台的sdk,对开发者快速搭建起一个RTC基础服务非常重要。

  • 提供js、react、flutter版本、reactnative版本、swift(iOS)、Android平台等版本client SDK
  • 提供golang、nodejs、ruby语言的 server SDK

运维部署部分

在运维和监控部分livekit也提供了一些方案:

  • 提供基于docker 和 k8s部署方案
  • 提供aws上的部署方案
  • 提供连接检查工具
  • 提供性能压测工具

特别是连接检查工具和性能压测工具特别好用,用连接检查工具可以额快速让我们知道有没有部署成功,以及可能哪个环节出问题了。

性能压测工具可以让开发者对livekit的性能有个直观的了解,程序员一大爱好不就是比比性能么? :)

性能压测

我在腾讯云的服务器上做了一些简单的压测,8核心,16G内存配置的开发服务器。

在服务器开始压测,推一路流,拉100路流,音频正常,视频1.7Mbps码率。

livekit-load-tester --url wss://xxxxxxx.com --api-key APIVYioj5ERqte5 --api-secret f5rKzm3vjiDUa2A5VKK3yUlejAooZZMgb0jj1RAaUSj --room test-room --publishers 1  --subscribers 100 --duration 5m

压测数据如下:

100路 1.7Mbps的拉流 占用单核心 50%CPU. 如果换算为500kbps的码率,单核跑满差不多500-600路( 只是简单的线性计算,不严谨,不负责吵架)。够不够用自有判断。

对我来说这个性能数据超出预期的,用go来开发媒体服务是没太大问题的, 已经足够能满足生产环境的性能要求,毕竟谁会在线上环境把服务器跑满呢。

PS:

最后 我组建了一个WebRTC技术交流的群,基本涵盖了行业内做RTC相关的公司的研发伙伴,对于想做技术交流的伙伴可以加我Q群,备注“名字@公司名字 ” 我拉你进群,仅限技术产品交流。