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使用的开发者来说非常友好。
第一步是生成配置文件
代码语言:javascript复制docker run --rm -v$PWD:/output livekit/generate --local
第二部就是开始运行服务
代码语言:javascript复制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 配置文件。
第一步是生成一个线上的配置文件:
代码语言:javascript复制docker run --rm -it -v$PWD:/output livekit/generate
第二步就是安装依赖:
代码语言:javascript复制sudo ./init_script.sh
这一步会安装相关的依赖,以及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码率。
代码语言:javascript复制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来开发媒体服务是没太大问题的, 已经足够能满足生产环境的性能要求,毕竟谁会在线上环境把服务器跑满呢。