最近给 Solar Network 做了直播的功能，而今天想来讲一下它是怎么做出来的。
之前 Solar Network 已经有音视频通话的功能了，用的是 LiveKit 做的。而这个新的直播也是 LK 做的。LK 真是个好东西啊，非常方便就可以做即时音视频的服务，并且支持的平台特别的多，基本上熟悉的平台都有 SDK 可用。
只要简简单单一两行代码就可以搭建好一个 Voice Chat，真的是不要太舒服。最近有想法做直播的功能，主要是我要用直播，但是因为地缘政治关系很明显大家熟知的直播平台都不让未成年人开播。所以只好自己做咯～
音视频
在一切开始之前，让我们先了解一下 LiveKit 是干什么。很明显，它是一个 WebRTC 服务器，帮你处理了 SDP，TURN 等乱七八糟的东西。同时很明显，我不是什么 WebRTC 专家，曾经想自己造一个类似的出来，但是很明显过于困难所以放弃。不管怎么说，很明显的 LK 可以帮你把音视频这块搞好，客户端用 LK SDK 就够了。
其次 WebRTC 最开始设计是由 participants（参会者）和 tracks（媒体轨道）组成的，设计出来是为了做视频通话什么的，和直播不是很对口。还有一些其他的障碍之类的，如用的编码格式就不是传统的 acc 而是 opus。不过 LK 在设计的时候早就想到了这点，有两个额外的模块，叫做 ingress 和 egress 负责处理这个。学数据结构的 DNA 动了
入度（ingress）
当然，你可把这个模块叫做入站也可以。其主要的功能就是把常用的推流用的格式 RTMP 转换成 WebRTC 能兼容的视频 track 和音频 track。这个部份和主服务可以分开部署，而我也是这么做的。只用接入同一个 redis cluster 就可以了。（并且 ingress node 要可以访问到主服务器不然怎么推送信息）
当然 ingress 的计算开销还是比较大的，例如上文说到 RTMP 和 WebRTC 的媒体编码不是很契合，而 ingress 会负责转换这里的编码。
出度（egress）
出度不是必要的模块，虽然入度也不是，但是我们在讲做直播的这块。其主要的用途是将 WebRTC 的媒体流转换成通常可以接受的 HLS 或者 RTMP 流。
出度模块被用来生成录播 HLS 流，虽然你可以用 HLS 做播放，但是这个延迟就大很多。不过还是有优势的，例如有随时回看的功能。但是 SN 使用的 WebRTC 做播放，用户加入同一个 LK 房间就可以了，缺点就是兼容性不是特别好，并且 ICE 和 Singaling 会造成进入直播间有点延迟。
聊天
直播聊天这块就有很多可以讲得了，你可以自己做一个 WS 服务器来处理这块。但是很明显我们都在用 LK 了，直接用 LK 的解决方案岂不是妙哉？
LK 里面有一套 publishData 和 on dataReceived 的方法，可以用来方便的实现这个功能。下面就是 SN 利用 LK 做出的解决方案。
v1
第一版本我是发给了 participants 的 publishData 权限，让客户端自己发布数据。好处是延迟低，坏处是没有消息记录，消息内容单一，也没法审计。
这个东西太简单，所以就不讲不讲。
v2
第二版本发信的方式改成了 POST 我服务器的 API，然后服务器用 LK 的 Server SDK publish data 到整个房间。好处有很多，服务器有了更多的控制权，例如敏感词的过滤等，并且还可以对消息进行留档，加载消息记录等。
同时服务器的 publish data SDK 还可以对打赏等信息进行广播，让我们的直播有了 SuperChat 的功能。
不过坏处就是服务器端需要携带更多的信息在 publish data 过程中，消息包的大小增加造成了延迟的增加，额外的 HTTP 请求也造成了延迟的增加。不过讲真这些都可以忽略不计。
结论
给我去用 LK Cloud！不要害他们公司没钱赚然后饿死了没人维护这么好的一个服务。
其他东西没什么可以讲得了，所以就这样吧。也是因为不知道要讲什么所以 DV14 比 DV15 晚发（