云游戏流媒体整体架构设计（云游戏流媒体技术前瞻，最近云游戏概念很火，加之对流媒体技术略有研究，简单写一些）

前言：

遥想当年阿法狗战败一众围棋国手，风气一转，似乎所有人都懂AI。这次谷歌又放出了stadia，国内鹅厂再次跑步进场，贵州某xx云提前布局。

闲来无事，尝试体验了一下贵州某xx云的云游戏（不打广告），暂且不评论如何如何，刚好对流媒体技术略有研究，仅在这里简单聊一下这方面涉及的架构和技术。

架构设计：

总体架构自上而下大致分为四端：

1、云游戏主机端（云游戏运行端，或者叫云游戏画面渲染端，需要接收控制指令并录屏推流到流媒体服务）

主机端需要运行游戏并让通过录屏推流程序把渲染好的游戏画面（其实就是录屏）推流到流媒体服务进行实时视频分发。

有人会想这个云游戏主机端可能会很复杂，其实也还好，只是包含了录屏、推流、用户控制指令接收和一些其他诸如计费此类的相关功能。

2、流媒体服务（用于转发主机端推上来的游戏实时视频并分发出去，所有用户都可以观看这个视频）

这个不需要多讲了，只是用来转发游戏实时视频，并不涉及云游戏主机的控制权。

3、控制指令转发服务（用户需要获取控制指令服务的所有权才能控制云游戏主机）

这个是云游戏的控制核心，获取某台云游戏主机的用户就可以通过键盘或者鼠标进行云游戏的试玩（操作），理论上讲能够获取该控制权的不是只有一个用户，完全可以支持多个用户同时控制一台云游戏主机。

4、客户端（浏览器，pc客户端，ios，安卓客户端等）

客户端需要从流媒体服务拉取实时游戏视频，用户需要先获取云游戏主机的控制权，才能够发送控制指令来试玩（操作）云游戏（鼠标，键盘，手柄等）

灵魂画师绘制结构图：

架构示意图-来自灵魂画师的倾情手绘

难点或者叫待解决的点：

1、流媒体协议的选择？高延迟才是最大杀手

从流媒体技术出身开始，实时视频延迟一直是个比较棘手的问题，比如rtmp/http-flv等基于tcp的协议本身优化到极点也要几百毫秒的延迟，hls这种超高延迟到几秒的不提也罢。就目前看只有sip、rtsp以及基于udp的一些协议能够满足这种超低延迟的需求，但是这种协议就很难在浏览器上就很难实现了，除了webrtc，而webrtc协议是谷歌力推的下一代流媒体协议，不排除这次是谷歌webrtc技术的奠基之作，拭目以待。

2、云游戏主机控制指令的所有权？依然是延迟

这个所有权其实不算是难点，只是用户获取某台云游戏主机的控制权而已。难点在于控制指令的延迟，没错，就是网络延迟。尤其是在拉取实时视频时，在视频已经占用大量带宽的情况下，在这种网络负载或者网络波动较大的情况下控制指令延迟或许值得重视。

跟很多朋友讨论过云游戏这个话题，不约而同第一个想到的都是网络延迟，当然这个延迟不仅包含控制指令的延迟也指实时游戏视频的延迟。

 

后言（啰嗦几句）：

其实这块依然属于共享经济的后续，类似共享单车。

给大家举个栗子：我有一百台性能强劲的游戏主机，每台主机价值一万，当二手货卖掉可能还会亏点，好可惜。那么我把他共享出来，假设现在有十万个用户想租我这一百台机器，然后每人只收10块钱月租，不考虑电费等其他成本，请问我什么时候能回本？