|
|
游戏服务端技术/人员整体水平是不是已经落后于互联网服务端？
关注者
587
被浏览
249,227
66 个回答
我在DAU千万的游戏干过，写过游戏微服务框架用在多款线上项目里，目前在负责一个DAU百万的游戏项目。在游戏服务端和互联网服务端这块，应该算是有一定的认识。
个人人为， 确实落后，应该说游戏服务端技术在跟着互联网技术发展 。
但是，游戏有些场景是互联网技术解决不了的；游戏服务端人员门槛比互联网更高；游戏服务端业务代码比互联网（大部分情况下）更难写。
游戏服务端从业人数和互联网的人数也不是一个数量级的，互联网整体更强正常。拿游戏行业和互联网行业比有点耍流氓，应该和金融行业、电商行业、餐饮行业这种比，如果和这些行业比，我觉得游戏不落后。
我来随便扯扯国内游戏服务器的技术现状：
如果把游戏服务端逻辑按照实时性高低区分，分为 实时性高 的（比如战斗逻辑）和 实时性低 的（比如游戏大厅、匹配、养成）。
实时性高的业务比如战斗 ，这一块属于游戏行业特有需求场景，互联网的技术栈放在这里全都凉凉。
但这一块游戏行业本身近十年并没有特别大的技术突破，KBEngine脱胎于十几年前的Bigworld引擎，现在依然活跃在MMO市场。
当然，玩家对这件事情已经接受，所以MMO大部分都是分服分线分副本等。
实时性低的业务 ，在前几年一般也是使用传统的游戏服务器引擎来做的，而传统的游戏服务器引擎其实更多是为了解决实时性强的业务逻辑，所以并不适合做这种业务。
这两年，各大公司已经开始使用互联网的技术实现这块业务。比如很多游戏已经可以实现不停服维护，服务器基于容器部署，使用微服务架构开发游戏业务、使用ELK进行日志记录和数据分析，使用Redis作为缓存或者开发业务，使用Nginx做负载均衡等等等等。所以，也可以说 游戏服务端其实在紧跟着互联网服务端的技术在发展 。
如果你所在的项目还用传统游戏服务器写全部的战斗逻辑和非战斗逻辑，互联网那些最新的技术应用不上，你难免觉得游戏服务端技术落后于互联网服务端。
前两天写了篇文章，大家可以看看。
乍一看是的，传统服务端过一两年就出一个新东西。但仔细一看，传统服务端的东西一半拿到游戏服务端领域是什么用都没有的，有用的另一半，中大厂已经用上了。什么容器化什么rpc的，游戏领域早就普及了
此外，游戏服务端和传统服务端面临的问题是不同的，同样游戏服务端也会不断的出符合自己领域的新技术，只不过传统服务端的人不会去关注罢了。
谢邀。
这是个很容易引起骂战的问题，也没法一概而论。所以我把它拆成两个：
1.国内游戏服务器所用的技术是不是已经落后于主流的互联网服务器？
这个问题的答案我个人浅见是不全对，但用技术落后来描述国内大部分厂商的服务器技术框架则我认为没什么问题。一个比较客观的事实是：你看到哪个品类的技术会议，会邀请游戏服务器上去讲架构？
凡事有例外，像鹅厂的游戏服务器中间套件就很给力，如果没有造轮子的癖好（技术人员谁敢说没有？），大概除了游戏逻辑层，其它方面都可以接入中间件解决——网络接入层，数据分发、DB都满足分布式，就近布点和接入、带负载均衡、健壮、可灵活扩容、可灰度发布、无单点故障（带冷热双备）、带冗余容灾、运维监控数据和工具也较完备 ====
前年去北京的时候，听说完美的服务器也是分布式架构。
（我不写猪厂，是不了解猪厂）
反观大部分其它厂商的服务器，9012年的今天，和十五年前的服务器架构基本完全相同。分区分组，大概的服务器种类依旧是网关、登录服务器、 中心服务器、社交服务器、DB、场景服务器、支付服务器。除了场景和网关，哪个都是单点，连DB双备的都很少，更别说跨机房跨线路容灾了。
我看到有同学说因为游戏服务器是有状态，要求反馈更及时。
但很多网服务都有状态的，状态不是游戏独有。
而及时性这个问题也一样：任何带及时互动场景的服务，都需要及时反馈，典型的如VOIP，视频电话，还有前年去年比较火的像视频抓娃娃这类的APP。
状态和及时性不是游戏服务器架构像这样裹足不前的原因，我看到的原因之一是：屁股决定脑袋，上层需求决定了技术框架。
MMO类的游戏，游戏玩法已经十几年没有进步了，那么为什么游戏服务器要改呢？
玩家也可以承受5分钟的回档，为什么我们要高可用？
宕机一个区就一个区吧，玩家也习惯了，为什么要做机房和线路隔离容灾？为什么DB要做双备？
游戏可以每周都停机维护，我们为什么要做服务器热更呢和AB Test(灰度发布）呢？
另一个原因是:把游戏服务器升级成分布式，对架构师的要求和开发人员的要求也会提高，这也就变相的提高了项目开发成本甚至拖延项目的完成时间。那么老板会问：为什么这辆跑车四平八稳在的赚钱，你非得重新发明轮子？以前哪些积累的资源怎么办？为什么要重来一遍？
2.游戏服务端人员整体水平是不是已经落后于互联网服务端 ？
作为一个游戏开发者，
这个问题我是完全不同意的。
一是 游戏技术框架是由资本、利益相关方、行业惯例、需求范围确定的，从业人员大多数不能对游戏架构说三道四。
二是 个人水平并不由他所在行业确定，而是由他的智商、他的进取心、他的毅力、习惯、持续学习能力来决定。
事实上我认为游戏行业更像是一个边缘学科，它涉及到的技术品类繁多，在别的软件开发看来，游戏程序是别人懂的他懂一些，别人不懂的他也懂一些这种状态。在个人没有合理规划的情况下，容易造成泛而不精的毛病，却同时也有着做任何其它软件也能快速上手的惊喜buffer。
本人做过游戏、APP的客户端服务器双端开发，大概都是在半懂不懂的水平上。以上回复大家娱乐看待。
互联网服务的那套东西相比游戏服务：
1 很多游戏要求实时性，大部分互联网服务没这个要求
2 很多游戏服务端都要求有状态， 互联网大部分服务都是无状态的
3 互联网那套所谓的高并发解决方案，在1，2前提下，无法适用游戏服务端
4 不是游戏落后，是互联网服务在http框架下需求比游戏简单很多
5 为了实时性，游戏界在N年前就在采用异步了，互联网到现在为止采用的都不多，因为不需要这么高的实时性，写异步逻辑比同步逻辑对程序员要求高的多。
6 为了实时性，游戏N年前就在使用缓存了，只是习以为常，互联网让缓存技术发扬光大了。
7 互联网大部分解决方案都是加大线程池和堆机器，后面还搞了个微服务，但对有状态的游戏服务器来说P用没有。
8 互联网比较会造名字和概念，我觉得这是互联网比游戏厉害的地方，因为一门技术发展初期，确实需要先提出概念，后面才能演变成业界通用解决方案。
做了5年游戏服务器，从写逻辑小工到主程序从0写框架都经历过，从业期间就一直能感受到互联网服务器和游戏的似乎非常不同，于是想看看互联网服务器到底是啥样，于是入职一个电商服务器中台坑位。转型方法就是补全一些分布式架构，mq，nosql，db，es这方面的知识，区别比较大的是游戏服务器是有状态服务，而互联网后台几乎是无状态服务，所以面试时候你说的一些游戏服务器的逻辑处理与存储落地的解决方案，互联网的面试官会觉得不在他们的套路之内，不能很好理解，造成沟通困难。我跳过去的时候是平薪过去的，毕竟业务不同，解决方案也不同，能平薪已经不错了。现在已经入职大半年，重构了一个数亿数据量的项目，深入理解体会了互联网服务器的那些套路，一方面增长了见识，技术体系也融入了新鲜血液，对服务器这块又上了一个台阶，另一方面业务确实挺无聊的，crud，分库分表和es，某些业务接口要严格幂等与可重试，技术套路很单调也很统一，数据落地与逻辑处理的解决方案其实并没有游戏的好。另外呢，游戏和互联网服务器这块从业人员也似乎互相不待见，（唉，所有的不待见都是相互不了解造成的）其实明明有很多值得互相借鉴的地方。最后，游戏加班的太多了，互联网公司虽然加班也多，但比游戏还是好太多，至少我现在可以6点下班双休了，，，