怎样评价网易的游戏服务器？

首先我个人对网易的服务器算是比较了解了，虽然不是在网易工作的，但是我经常会玩网易的游戏，而且玩的时间也比较久，对于网易的服务器有一定的了解，下面是我的个人看法。

一、个人认为网易的服务器中规中距，不算特别好，但是也不差。

为什么会给出这样的评价呢？因为网易的服务器其实算是游戏界比较好的了，他并没有说经常会服务器掉线甚至服务器死机。对于一名游戏爱好者来讲，玩一个游戏就是希望能够画面流畅，也希望服务器能够流畅，因为如果经常出现玩游戏玩到一半的时候，突然回档了，或者说突然死机了，将会是一件很烦人的事情，特别是对于一些网络游戏来讲，一个服务器的稳定是非常重要的。对于这一点，我个人觉得网易做的还不错，但是没有做的特别的好，因为网易的服务器会根据游戏不同，他会配置不一样的权重，有些游戏就会比较好。

二、网易的哪个服务器比较好？

最早读书的时候有打魔兽世界这么一款网络游戏，当时觉得网易的服务器做的还算比较好的，因为很多玩过魔兽世界的小伙伴都知道，以前魔兽世界是由九城这家公司代理的，当时九城代理的时候，因为硬件条件的限制，服务器经常死机或者游戏回档，当时给玩家造成了很大的困扰，后来网易接手之后就没有这个问题了。

三、网易的服务器管理水平怎么样？

我个人认为网易的服务器管理水平还是比较好的，但是也只针对几个比较火的游戏，对于一些比较冷门的游戏，网易的态度是置之不理，虽然游戏没有关闭，但是服务器管理的也不是很好，这一点可能就是区别对待吧，当然比较热门的游戏，网易的管理还是挺好的。

服务器资源利用率较低，IT基础设施的总拥有成本（TCO）逐年上涨，一直是困扰很多企业的难题。随着云原生技术的发展，Kubernetes逐渐成为数据中心的一项基础设施，将在/离线业务统一使用Kubernetes调度编排日渐成熟。本议题结合网易轻舟在这一领域的工作实践，介绍如何基于Kubernetes通过混合部署，在不影响在线业务的前提下将CPU利用率提高到50%以上，大幅降低企业数据中心成本。

数据分析显示，数据中心成本中，服务器采购成本占比超过50% 1, 2 ，而全球服务器平均资源利用率不到20%，并且服务器一般3~5年就会淘汰，需要购置新服务器，造成了巨大的成本浪费。

如果数据中心或者机房规模较小，服务器数量有限，很少有人会去关注资源利用率这个问题。因为在小规模场景下，耗费人力、物力想办法提高服务器资源利用率并不会获得太高的收益。如果数据中心规模比较大，提升数据中心资源利用率则能够显著降低成本、带来巨大收益，所以国内外的大型互联网公司，很早就开始投入大量的人力物力进行较多的探索实践。

近几年，随着云音乐、严选、传媒、有道等互联网业务的快速发展，网易内部的服务器数量不断攀升，而实际资源利用率又比较低，IT基础设施成本问题日益严峻。面对日益增长的业务，我们希望用最小的基础设施资源成本来支撑更大的业务需求。提升服务器资源利用率成为一个比较重要的解决手段。

网易轻舟团队提出了一套基于kubernetes的业务混部方案，目前已经在网易内部得到广泛应用，在不影响业务SLO（service-level objective）的前提下，资源利用率得到显著提升。

本文将从以下几个方面逐步展开：

资源利用率现状和原因分析

如何通过混部提高资源利用率

落地成果

未来展望

麦肯锡数据统计显示，整个业界的服务器平均利用率大约为6%，而Gartner的估计要乐观一些，大概在12%。国内一些银行的数据中心的利用率大概在5%左右 3 。

而造成利用率比较低的原因主要有以下三个方面：

不同类型的业务划分了独立的服务器资源池

绝大多数企业在构建数据中心或者机房的时候，对于在线服务（latency-sensitive service）和离线服务（batch job）是单独采购机器并且分开管理部署的，各自采用独立的资源调度管理系统（比如离线业务使用Yarn调度，在线业务Mesos调度），从服务器采购、规划到业务调度层面都是完全隔离的。

图1(b) 是Google 专门运行在线应用的2万台服务器CPU利用率分布图，大部分处于30%左右。图1© 是Google专门运行批处理作业的2万台服务器CPU利用率分布图，大部分在75%左右 3。

在线业务SLO要求较高，为了保证服务的性能和可靠性，通常会申请大量的冗余资源，因此，会导致资源利用率很低、浪费比较严重。而离线业务，通常关注吞吐量，SLO要求不高，容忍一定的失败，资源利用率很高。

假如将离线业务跑在在线业务的机器上，充分利用在线业务的空闲资源，那是不是就能节省下离线业务的服务器成本了呢？

服务的reserved资源和实际used资源存在较大Gap，通常overprovision

业务通常是有波峰和波谷的，用户在部署服务时，为了保证服务的性能和稳定性通常都会按照波峰申请资源，即 provision resource for the peek load，但是波峰的时间可能很短。另外，也有相当一部分用户对于自己服务的资源使用情况不是很了解，在申请资源时具有较大盲目性，但是通常也是申请过量资源而不是申请的过少。

图2 是推特数据中心资源使用情况，可以看到cpu利用率大约在20%左右，但是用户申请了60%左右的cpu资源；内存利用率在40%左右，但是用户申请了80%左右的内存资源 4。

服务A已申请的但是实际没有使用的资源，即使是空闲的，其他服务也是不能够使用的。Reserved - Used差值越大，资源浪费越多。所以我们应该如何去缩小Reserved - Used的差值，从而提高业务部署密度和资源利用率呢？

业务负载具有明显的时间上的波峰波谷，处于波谷时，空闲资源其他服务无法使用

很多面向用户的在线服务具有明显的波峰波谷，比如白天用户使用量较多，资源利用率相应较高，但是夜间用户使用量较少，资源利用率相应较低。夜间空闲出来的资源，其实都是浪费的。那夜间空闲出来的这部分资源是不是也可以用来跑离线业务呢？

在线业务（latency-sensitive service）：和用户存在交互的、并且对交互延时敏感的应用称为在线业务。例如：网络搜索服务、即时通讯服务、支付服务、游戏服务等，延迟对于这些服务的服务质量至关重要，故称为“延时敏感”，在线业务通常有着严格的SLO（service-level objective）。

离线业务(batch job)：和用户不存在交互，对延时不敏感的应用称为离线业务。例如：Hadoop生态下的MapReduce作业、Spark作业、机器学习的训练作业、视频转码服务等。这些作业对于其完成时间的容忍度较高，故称为“延时不敏感”。离线业务通常没有严格的SLO 。

混合部署（co-location）：是指将在线业务和离线业务混合部署在同一集群和服务器上。

传统的数据中心中，之所以将在/离线服务分开部署管理，实属无奈之举：

- 混部会带来底层共享资源（CPU、内存、网络、磁盘等）的竞争，会导致在线业务性能下降，并且这种下降是不可预测的

- 在/离线服务分属不同的研发、产品团队，成本管理是分开的

- 在/离线服务使用不同的资源调度管理系统，无法统一调度

如果能够将离线服务跑在在线服务的机器上，充分利用在线服务的空闲资源，则能够显著提升资源利用率降低服务器成本。

随着云原生理念、容器和微服务的普及，Kubernetes 逐步统治了容器编排领域，成为数据中心的基础设施。将在/离线业务统一使用 Kubernetes 调度管理，日渐成熟。

接下来，本章节会详细讲解如何基于 Kubernetes 实现在/离线业务的混部，在复杂的基础设施架构下，面对众多的共享资源，如何实现多维度的资源隔离，最小化在/离线业务之间的性能干扰，保证在线业务的运行性能、提升离线业务运行效率。

因为要基于Kubernetes 实现在/离线业务的混部，所以需要先了解 Kubernetes 有哪些功能能够帮助实现混部，以及 Kubernetes 本身存在哪些问题。

pod是有优先级（pod priority）的，相应字段是pod.spec.priority，它表示了pod的重要程度，值越大优先级越高。调度器调度的时候会优先调度高优先级的pod，Kubelet在驱逐过载节点的pod时，会优先驱逐低优先级的pod。

所以，可以将离线任务设置较小的pod priority。

Pod有三种QoS class：

- Best Effort： 如果pod的cpu/memory资源的request和limit都没有设置，则该pod属于Best Effort类型

- Guaranteed：如果pod的cpu/memory资源的request和limit都设置了，并且每个资源的request值等于limit值，则该pod属于Guaranteed类型

- Burstable: 剩下的则是Burstable类型

其中，Guaranteed pod对于 SLO 要求最高，有最高的资源保证；Burstable pod对于 SLO 要求次之，仅保证 request 部分的资源；Best Effort pod 对于 SLO 要求最低，资源无法保证。

Best Effort类型pod的 OOM Score 是最大的，也就是说在发生系统OOM的时候，首先kill的就是Best Effort类型的pod。

当节点上内存、磁盘等非可压缩资源负载过高时，kubelet会驱逐上面的pod，保证节点稳定性，驱逐的顺序是： Best Effort、Burstable、Guaranteed。

所以，是不是可以将离线任务归为Best Effort class 呢？

Kubernetes 是使用 cgroups 来实现pod的资源限制的。

图4 是Kubernetes cpu cgroups的层级，三种不同的颜色表示三种不同的QoS class：

- kubepods 的cpu.share 只在kubelet启动的时候设置一次

- besteffort和burstable的cpu.share，每隔1分钟更新一次. 有pod创建删除也会触发更新

- pod的cpu.share和cfs quota只在创建时设置，后面不再更新

图5 是Kubernetes memory cgroups的层级，三种不同的颜色表示三种不同的QoS class：

- kubepods 的memory.limit_in_bytes 只在kubelet启动时设置一次

- besteffort和burstable的memory.limit_in_bytes，后面不会更新

- pod的memory.limit_in_bytes只在创建时设置，后面不会更新

之所以在这讲一下Kubernetes pod cgroups的层级组织结构和动态更新策略，是因为我们开发的资源隔离组件也是通过更改cgroups配置来实现资源隔离的。如果不知道Kubernetes原生的cgroups管理策略，很容易发生更新失效或者冲突，引发故障。

Kubernetes是使用的静态调度。静态调度是指根据容器的资源请求（resource request）进行调度，而不考虑节点的实际负载。所以，经常会发生节点负载很低，但是调度不了新的pod上去的情况。

Kubernetes为什么会使用静态调度呢？因为要实现一个基于节点负载进行动态调度的通用框架是很困难的。而静态调度实现简单、管理方便，但是对于用户的要求要高一些，如果 resource request 配置的不合理，可能会导致节点之间负载不均衡以及利用率较低。

Kubernetes 是没有区分在线业务和离线业务的，当前的cgroups层级组织结构也很难将在/离线业务区分开，很难实现动态的资源分配和动态的资源隔离。所以，也无从谈起在/离线业务的性能隔离，顶多就是不同pod之间的隔离。

而 Kubernetes 对于pod之间的资源隔离也是很弱的，仅仅通过cgroups在cpu维度使用cpu.shares控制发生cpu争用时的时间片分配比例，使用cfs quota限制cpu使用上限；内存维度使用memory limit in bytes限制使用上限。

如果贸然将在/离线业务混部在同一台机器上，是无法保证在线业务的SLO的。

---