更新快，开源和云服务不同步：视频比云服务发展更早，而云服务的很多要求，开源视频服务器并不满足，很多开源项目并不考虑云架构，因此从基于开源的自建系统，迁移到云就非常难。
为什么这个问题很重要？
影响视频在各个领域的落地，阻碍新场景的发展。新场景一定是跨领域的，不会有只做直播或只做 RTC 的情况，新领域并不是直播简单的渗透，而是互联网视频的渗透，只有跨领域的开源项目，才能推动新场景的发展和落地。
无法使用云服务能力。云架构最厉害在于弹性，而且是标准的跨云的弹性。如果开源项目本身不考虑云架构，就无法迁移到云也没有弹性能力。开源的云架构并不是把开源在云主机中运行，就是云架构。
多云迁移困难。云的方向是应用上云的标准化 (K8S)，可以在多个云之间无缝迁移，这给应用非常高的可靠性。如果开源项目本身不做 K8S 所要求的改造，就无法在多个云之间迁移。
SRS 如何解决这个问题？SRS 的定位是云原生的视频服务器，应对云原生做了大量改造，可以非常方便上云和迁移。
除了云原生的能力，SRS 也是非常高性能的开源服务器。当然性能没有最高只有更高，每个大版本都需要做性能优化，然后用性能交换功能和用户体验。
特别说明下，这里并不是说 Nginx 和 Janus 就做不到 SRS 的并发，只是目前的版本压测出来的数据。性能和行业背景是非常相关的，比如 2012 年大多是千兆网络时代，所以 Nginx 的性能足够能打满带宽了。而 Janus 同类的服务器差不多都是 Janus 这个量级。SRS 之所以一直重视性能是因为互联网很关注成本，成本必须使用性能交换。
今年是 SRS 第八个年头，去年已经成为开源视频服务器的 Top1，主要还是因为国内的视频行业发展很快，另外活跃的视频开源服务器比较少。
这里说点八卦，这次疫情给全球经济带来很大影响，也带来了互联网视频的大爆发，比如直播、教育、会议、云游戏、IoT 等等。大家只能在家活动，所以互联网成了大家交流的重要方式，各个开源项目也在 20 年初有很大的增长，比如 Janus。
很可能这是我们唯一会经历的黑天鹅了，我之前一直有个疑问，就是疫情结束后，是否互联网视频会回到解放前？从 Janus 的增长速度看，半年后增长的速度回落到疫情前了。这也许也说明了，就算是做开源也不能依赖这种事件。
SRS 的快速增长是在 19 年底，这个时间点也是 SRS 支持 WebRTC、SRT 和 GB28181。所以也分不清多少是疫情的拉动，多少是因为 SRS 自己的努力。好消息是 SRS 的增长并没有回落，而且是目前增长最快的开源视频服务器项目。持续的增长和全球 Top1，这不是结束，而是一个新的开始。
我们认为只有公众号订阅的开发者超过 100K，才能有机会提升了整个视频行业开发者的创造力。只有达到 100K 的 Star，才能叫互联网视频的标准开源服务器。只有不断推动新场景的 DEMO 和探索，才能不断拓展视频的边界。
SRS 是一个雄心勃勃的开源项目，十年的 OKR 是个挺大的目标。如果我们看三十年后，那么有三代新的开发者进入视频行业，而随着视频成为互联网基础设施的一部分，那么这个目标也不算是很大，最大的问题可能是在于 SRS 能否活够 30 年吧。
什么是云原生回到今天的主题，从开源 SRS 到商业服务，还需要解决哪些问题。
长会话：RTC 中最长有 48 小时的会议，甚至更长，直播有时候也是非常长时间推流，比如昨天雷军的视频号直播，折叠小米手机的折叠屏，连续直播折叠三天。这三天直播服务怎么升级？
中心、边缘、专有云 SLA 差异大：中心云的网络状况，基础设施的完善度很高，会话的迁移相对比较容易。而边缘和专有云的 SLA 就差很多，不能用同样的机制做迁移。
端口和 IP 复用：传统 RTC 一般是内网应用，有可以随便使用的 IP，可以分配几万个随机端口，这些在云上有安全隐患，公网 IPv4 地址不能随意用，扩容就很难做。