#挑战30天在头条写日记#

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

项目地址

LiveKit · GitHubTwitter

快速上手

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

第二步就是安装依赖：

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码率。

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来开发媒体服务是没太大问题的， 已经足够能满足生产环境的性能要求，毕竟谁会在线上环境把服务器跑满呢。