游戏上云
先前的游戏服务部署都需要经历两个阶段，一个阶段是服务器硬件的采购以及服务器部署的配置，另一个阶段是服务器的长期运维。服务器采购以及部属配置的整个流程可能需要数个月之久，而且服务部署配置后需要专门的专家进行管理，这些流程对于一些中小型公司来说是很繁杂的，会造成很大的成本问题，这也就催生出了云计算。
云计算是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需求提供给计算机各种终端和其他设备，使用服务商提供的电脑基建作计算和资源。有了云计算后，公司可以快速购买和配置所需的服务资源，从而花更多的资源在产品本身上。
游戏上云需要两个技术，一个是虚拟化技术。虚拟化技术是一种资源管理技术，是将计算机的各种实体资源，如服务器、网络、内存及存储等，予以抽象、转换后呈现出来，打破实体结构间的不可切割的障碍，使用户可以比原本的组态更好的方式来应用这些资源。这些资源的新虚拟部份是不受现有资源的架设方式，地域或物理组态所限制。另一个是服务编排技术，一个游戏服务的数量可能有成百上千个，而且不同的服务可能分布在不同机器上，这会给服务管理造成很大的困难，所以需要服务编排技术来解决。
Docker
主要是三个部署方式，传统部署、虚拟机部署以及容器部署
- 传统部署
比较典型的游戏部署方式是服务器运行某个操作系统(如Ubuntu)，然后各个游戏服务以进程的方式直接运行在操作系统上，因为每个进程有自己的地址空间，所以服务间的内存空间是隔离的。这种部署方式的优点是简单直接，服务没有额外的一些运算，可以极大化的利用运算资源。但这种部署方式很难限制同一台物理机上每个服务的资源使用(CPU内核的分配)，存在资源争夺情况，很可能因为某个服务占用较大的计算资源导致其他应用不能正常服务，而且因为服务在同一个宿主操作系统中，各个服务可以通过读取文件感知到对方的存在，存在很大的安全隐患问题。
- 虚拟机部署
一台专用服务器的CPU内核数可能有上百个或者上千个，为了更好利用一台服务器的计算资源，避免不合理的竞争，所以引入一种完全虚拟化技术。虚拟化技术允许在物理机上同时运行多个次级操作系统。我之前用的比较多的虚拟软件是VMware，VMware使用Hypervisor对硬件资源进行虚拟化，在使用VMwave的时候需要配置虚拟机的CPU、内存和网络等资源，配好后在虚拟机中安装对应的操作系统和软件。每台虚拟机可以配置自己要使用的资源，各个虚拟机的资源互不干扰，有一个很好的隔离效果，但是虚拟机需要安装完整的操作系统，导致非常笨重。
- 容器部署
比虚拟机更轻量级的是容器技术，如Docker。容器与虚拟机的主要差别是隔离层不一样，虚拟机在物理层面上进行隔离，然后在之上安装操作系统，容器是直接运行在宿主操作系统上，并不需要在额外安装操作系统。Docker使用Linux隔离技术(CGroup和Namespace)来隔离各个服务，并直接调用操作系统的系统调用接口，从而降低每个容器的系统开销，实现降低容器复杂度、启动快、资源占用小等特征。
虚拟机和容器都使用镜像来存储运行环境。对于Docker来说，应用的源代码与它的依赖都打包在Docker镜像中。一个游戏产品生命周期通常要经过开发团队、测试团队和运维团队。早前没有这样的容器时候，服务的交付和升级都会导致多个团队重复性的安装新的依赖环境，而且一些老上线运营的游戏都不敢轻易升级服务，生怕环境不一致导致服务运行不起来。Docker的出现很好的解决了环境问题，环境一次配置各地运行，这也降低了各个团队的交付成本。
Kubernetes
Docker容器本身适合运行单个服务，但一个游戏的服务有可能上千个或者上万个，这些服务可以分布在不同物理机上。如果只有几个容器，那管理是非常简单的，但当容器有成千上万个的时候，很可能会导致容器管理和编排变得非常困难。对于一些大公司来说，因为要经常维护大型服务器集群，所以都会有自己写的一套集群管理方案，这些方案包含服务资源配置、服务资源使用监控、健康状态检查以及服务的负载均衡等。
- Kubernetes在游戏界的使用
2014年Google开源了自己的容器编排与管理工具Kubernetes，Kubernetes开始逐步在互联网界扩散，2017年之后大量互联网公司开始应用Kubernetes。但奇怪的是游戏界到现在其实也很少游戏服务使用Kubernetes部署，难道是因为技术原因吗？这个问题其实还有个大学老师专门写了篇论文来探讨，给出的结论是没有技术原因，只是因为习惯问题。结合自己在游戏界的经验，这个结论是正确的，当然还有一些游戏特性原因，游戏相对于互联网产品的主要差异是游戏对网络延时要求更高，使用Kubernetes的话会因为一些额外配置带来网络延时和处理延时。
之前游戏部署更多的是使用脚本部署，一些Kubernetes主要支持的特性，如服务状态监控和负载均衡功能，其实是游戏服务内部功能就要支持的，并不需要外部工具在单独支持，再加上一些大型游戏公司的产品已经上线很久了，相应的服务部署工具也会不断针对性完善，有了更熟悉的专用部署工具，而且Kubernetes本身是有上手成本的，一堆新概念要学习，所以游戏界应用Kubernetes需要一定的过度时间。当然，现在的一些新游戏都开始使用Kubernetes部署，像网易雷火的各个新游戏也都用Kubernetes部署，使用Kubernetes部署可以更方便接入公有云，动态创建游戏服务，更合理分配服务计算资源。
- Kubernetes基本概念
Kubernetes的核心概念是pod，一个pod包含一个或者多个共享存储和网络的容器，以及怎样运行这些容器的规范，pod是Kubernetes上最小的部署单元，其他的一些工作负载是多个pod的扩展组合。一个pod典型包含一个运行游戏服务的容器以及一些额外的监控容器和发送log服务容器。
Kubernetes使用YAML来定义pod如何运行，如pod名字、使用端口以及IP、CPU和内存限制。Kubernetes的整个架构图如下。
云游戏
云游戏现在使用越来越广泛，以下会总结什么是云游戏，怎么实现云游戏以及目前云游戏的主要问题点和解决方案。
什么是云游戏
随着云计算的发展，基于云的一种游戏新形态也被提出，那就是云游戏。云游戏是游戏运行逻辑以及画面渲染由远端的服务器来完成，玩家设备不用在下载安装游戏软件，只用从服务器接收音视频流并在设备上播放。因为玩家设备并不用运行游戏，所以玩家可以在任何地方用手机这种低性能的设备玩3A主机游戏。云游戏跟传统游戏运行的最大差别是游戏是否用本地设备的GPU渲染游戏画面。
云游戏工作原理
云游戏主要的工作是将服务器的游戏音视频传输到玩家播放设备上，就跟看电视差不多，不过云游戏跟电视的一个主要区别是：云游戏是有交互的，画面需要根据交互来显示，也就是需要实时渲染。大致的实现结构如下，下图也是Google云游戏平台Stadia的工作流程。
首先是对服务器游戏的音视频截取并将其编码成流媒体数据，然后使用传输协议将数据传输到玩家设备上，玩家设备将数据解码并将其播放。
画面截取
画面截取的方法很多，不同显示驱动软件或者不同操作系统有不同的画面截取方法，比如GDI 抓图、BitBit、DDA(Desktop Duplication API)、IDD(Indirect Display Driver)、DXGI等等，DXGI是Windows系统中用户模式下最底层的图形设备接口，可以直接获取显示器的内容。
音视频编解码
游戏视频数据根据不同游戏画面刷新频率和分辨率有不同的大小，但通常都是很大，所以在网络上传输时都会使用视频压缩编码，目前使用比较广泛的是H.264编码格式，H264有参考帧的运动补偿、帧内预测等新特性，视频质量更高，码率更低。相较于H.264编码，最新的是H.265编码，H265在架构上与 H264 相似，但H265在图像分块、变换编码、预测编码、熵编码等模块上提出了更优的算法，提高了编码的压缩率、鲁棒性，在相同画质的情况下理论上 H265能比H264节省一半的带宽。H.264已经在手机、平板和浏览器上支持。音频一般使用opus或aac来编码。
数据传输
视频和音频编码后得到一个个数据块，然后将数据块传输到客户端上。Google的Stadia直接使用WebRTC传输音视频数据。当然也可以直接使用原生TCP、UDP和KCP协议传输，对于一些实时性较高的产品，比如强竞技游戏，可以使用KCP传输，KCP传输数据要比TCP要快。相对来说流视频使用UDP传输会更合适，因为游戏画面对准确性要求不高但是对实时性要求高。
画面显示与输入采集
传输过来的数据块解码后得到原始的画面和声音，然后使用SDL呈现画面和声音。云游戏显示质量可以分为分辨率以及帧率。良好的云游戏画质需要高分辨率(至少1080P)，实现分辨率的提升需要编解码算法以及硬件能力的提升。游戏的每一帧图片是实时渲染的，每秒显示在显示器上的画面数量，决定了云游戏的体验(至少60FPS)。玩家的操作，比如键盘、鼠标、手柄等外设的信息采集也可以通过SDL实现，收集后将数据传给服务器。
云游戏延时
实现一个能运行的云游戏平台其实不难，现有的技术基本上很容易达到，但为什么现在很少人用云游戏平台玩游戏了？抛开什么商业模式和服务器成本不说，其中的主要原因是云游戏有很大的网络延时，这样的延时很影响游戏体验，尤其是一些对延时比较敏感的实时竞技游戏。2019年网易雷火的一位引擎大佬参加GDC时，现场测试了google Stadia云游戏平台的延时，整个延时大概在200ms左右，云游戏带来的额外延时是70ms左右，从视频上来看延时还是很明显的。据研究表明，游戏延时需要保持在150ms以下才会有一个较好的体验。
对于传统的在线游戏来说，延时是一个常见问题，比如移动延时。移动延时可以通过游戏逻辑来降低，比如影子跟随这类根据轨迹推算的算法。然而，这类算法并不适用于云游戏，因为云游戏仅仅传输游戏画面，没有游戏逻辑状态。那么是什么造成了云游戏的网络延时了？现在又有哪些解决方案了？
延时的主要原因
造成云游戏延时主要原因可以分为三类：
- 网络延时：玩家操作信息发送到服务器以及客户单接收到服务器音视频流总共时间。
- 播放延时：玩家设备接收到编码数据后到解码数据并将其显示到屏幕上的延时。
- 处理延时：服务器接收到玩家命令处理命令并返回相应视频的时间。
网络延时
现在云游戏体验最大的问题是网络延时问题，网络延时的主要原因是网络包在路由器上路由，网络包所经过的路由器越多，那么网络延时也会越大。由于云游戏基于云计算发展，云计算服务器分布在不同地理区域上，所以可以用云计算来选择离玩家最近服务器来降低延时，这类服务器被称为边缘节点(Edge node)，所形成的技术就是边缘计算。厂家将游戏部署在边缘节点上，玩家在请求云游戏时，根据每个边缘节点的延时和负载量来选择延时最低的节点进行服务。根据Google Stadia的设计者表述，Stadia有7500个边缘节点部署在合作的ISP厂商中。
边缘计算是5G的核心技术之一，5G提供10Gbps以上的峰值速率、更佳的移动性能、毫秒级时延和超高密度连接。这样的技术很好的满足了云游戏的低延时和高带宽的需求，因此5G技术的普及也会促进云游戏的进一步发展。
播放延时
播放延时主要取决于视频编解码以及视频压缩技术，目前使用广泛的是H.264格式，像Stadia也是支持这个的。对于移动云游戏来说H.264还是不够，主要的原因是，移动设备需要在严格的延迟要求下传输大量的数据，包括高质量和高帧率的图形，这就会要求移动设备需要由一个更高的带宽。
除了视频压缩技术之外，Stadia为了降低延时提出负延时(Negative Latency)技术，这个技术使用马尔科夫链预测玩家在未来几帧内的输入，并且渲染对应的画面返回给客户端，如果在错判时给出补偿(快速隐藏错误的渲染)并且调整输入渲染。负延时技术对一些单机游戏来说比较友好，但是对于一些网络游戏来说比较难应用，因为游戏变量不仅仅只有当前玩家的输入。
处理延时
渲染一个游戏画面来说，肯定选择最好的GPU来渲染，产生的延时也低。但是考虑到成本，不可能任何游戏都使用最好的GPU来渲染，比如一些对渲染要求低的2D游戏。现在云游戏厂商的持续亏本很大一部分成本来自于硬件配置的不合理使用，所以在保证游戏体验的前提下，合理的调度服务器的硬件配置可以降低成本，增加企业的营收。
虚拟化在整合游戏资源和降低硬件成本方面起着至关重要的作用。目前为止，CPU，网络接口和数据存储虚拟化技术已经发展很成熟了，典型的像Docker容器技术。但是GPU却是个例外，先前，研究人员针对虚拟机提出了一种新的GPU算法“vGPU“，“vGPU”的基本思想是将GPU计算资源分割成多个块，并在图形处理中引入CPU，以弥补GPU计算资源的损失。
GPU虚拟化可以增加服务器的游戏并发能力，增强虚拟机的计算能力。GPU虚拟化的问题是阻碍云游戏实现令人满意的延迟和响应时间的最大障碍之一。
网易云游戏
Google在2019年的GDC大会上正式发布云游戏平台Stadia，同年的11月份网易云游戏平台也推出。目前在杭州使用手机玩网易云游戏平台中的《光·遇》，网络延时可以控制在50ms以内，网络延时并不明显，游戏体验也蛮好的。
总结
随着云技术的发展，相应的游戏形式也发生了变化，产生了云游戏。云游戏因为不用下载游戏，不限设备等特性，不断发展壮大，但由于云游戏的延时和画面质量问题，云游戏也面临着挑战。
参考
- https://iopscience.iop.org/article/10.1088/1742-6596/1314/1/012211/pdf
- https://arxiv.org/pdf/2009.09786.pdf
- Youtube：Stadia Streaming Tech: A Deep Dive (Google I/O'19)
- wikipedia：Cloud gaming
- https://www.gdcvault.com/play/1027020/Cloud-Gaming-Where-Are-We
- https://www.gdcvault.com/play/1026527/Gaming-in-the-Cloud-A
- https://stadia.google.com/
- https://www.gameres.com/889974.html
- http://docs.kubernetes.org.cn/227.html
- https://draveness.me/kuberentes-federation/
- https://zhuanlan.zhihu.com/p/59924374
- https://www.diva-portal.org/smash/get/diva2:1562637/FULLTEXT01.pdf
- https://github.com/ksyun-kenc/liuguang
- https://www-file.huawei.com/-/media/corporate/pdf/ilab/2019/cloud_game_whitepaper.pdf