游戏服务器架构和web服务器架构的区别？
关注者
241
被浏览
58,501
8 个回答
以前做WEB服务器，最近在研究游戏服务器，试着回答一下吧。不对的地方请各位斧正一下。
1-技术有什么区别
首先通信上目前的主流是HTTP协议和SOCKET这两种(HTML5提供了一种新的协议，WebScoket，对此了解并不多，因此不做评论，以免误导)。
HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。
（注：在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。）
Socket又称"套接字"，应用程序通常通过"套接字"向网络发出请求或者应答网络请求。
以J2SDK-1.3为例，Socket和ServerSocket类库位于 http:// java.net 包中。ServerSocket用于服务器端，Socket是建立网络连接时使用的。在连接成功时，应用程序两端都会产生一个Socket实例，操作这个实例，完成所需的会话。对于一个网络连接来说，套接字是平等的，并没有差别，不因为在服务器端或在客户端而产生不同级别。不管是Socket还是ServerSocket它们的工作都是通过SocketImpl类及其子类完成的。（摘自百科）
在WEB服务器中，一般情况是只需要使用HTTP协议的。因为它不太需要去与浏览器进行主动推送，只需要响应浏览器的访问就足够了
而在游戏服务器，这样的连接方式肯定是不够用的。很多时候游戏服务器是需要主动推送消息，如系统广播。
2-思维有什么区别
WEB服务器并不需要高频即时通讯，对响应速度要求不高。而游戏服务器，大多数是需要很及时的响应速度（暂不讨论弱联网游戏）。如DOTA，这种竞技类型的游戏，1秒就能发生很多事。
因此，在思考方向上，WEB服务器应该考虑是的多平台的兼容，大量用户访问的高并发。
而游戏服务器应该考虑的是高频通讯，高并发。
3-架构的侧重点有什么区别
在架构上面，一般访问量不是很大的网站是只有一台服务器的，访问量高的才会进行分布式设计或者集群设计。
而大部分游戏服务器都是需要分布式设计的。
在现有的网络游戏服务器端架构中，多是以功能和场景来划分服务器结构的。具体的划分是根据项目的需求进行的，并没有一个十分通用的架构。
以上是比较常见的结构，客户端登录的时候，连接GateServer，然后由GateServer去连接LoginServer进行登录。登录后通过CenterServer转发到GameServer（GameServer即是服务器大区）。
而其中的DCServer，主要的功能是缓存玩家角色数据，保证角色数据能快速的读取和保存。
LogServer便是保存日志的了。
4-本质有无区别
本质上，两者并无区别，只是需求不同，侧重点不同罢了。
大致就是这样，有错误地方希望能指出来。
=========================================================
一年过去了。感觉，我又强了几分。
再来补充点好了，也当作是一个自我总结。
个人感觉上，游戏和web服务器之间最大的区别就是业务上的不同。游戏的业务大多数都是很复杂的情况，而且对即时性要求比较高（部分弱联网游戏对即时性要求不高，抛开业务甚至可以直接照搬web服务器架构）。
数据的同步：
在大型游戏上，有一个很重要的话题便是数据的同步。任何即时操作的游戏都绕不开这个话题，数据的同步直接影响着用户的体验。我们既要保证数据的一致性，又要保证玩家游戏的流畅性。这其中是需要做许多取舍的。
/*目前数据的同步主要有两种，帧同步与状态同步（各有优劣，应用环境不同，在此不展开）。这两种同步都只是一个大的方向，并不是一个完善的解决方案。比如帧同步在弱网络环境下是否需要冗余保证数据完整性，比如是使用tcp还是udp，亦或者是两者混合使用。这些都没有一个确切的答案，都处于摸索之中。*/
而web服务器并无此种纠结，它们的数据都在服务器，并不需要用户与用户之间的强交互。数据同步的延迟也就不那么难以忍受了。
集群与分布式：
当一个网站访问人数很庞大的情况下，单独去提升一台物理机配置能够带来的性能提升会因为边际效应逐渐减小。这时候就需要考虑使用集群了。集群有三种，高可用集群， 负载均衡集群，科学计算集群。其中最常见的便是负载均衡。很多情况下，集群之间是不需要互相交互的，数据都在单个服务器上进行处理，也就没了同步的问题（相比游戏服务器要简单了多）。
相对于游戏的难点就在于游戏我们可以通过分区分服甚至分频道等方式来减小服务器负载压力。而网站是无法这样让用户分区之类的操作。甚至是需要，全国各地乃至全球各地访问到这个网站都是同样的用户数据（针对这种情况我们会使用cdn，部署网络各地的节点服务器可以使得不同地方的人员访问网站的速度是一致流畅的）。所以并不是网站业务简单就轻率的认为网站开发没有技术含量。
游戏服务器，因为可以分区分频道等，所以很多情况下一台服务器的负载量要求不会太高。像手游的服务器，甚至要求可以低至同时在线200人。而且有些时候我们仅需要提高某一些功能的负载量，又或者大型3D游戏存在地图，这些情况下，我们往往使用分布式架构来解决。如分离聊天、好友之类的功能，如给每个区域分配一个单独的房间/地图/场景服务器。
======================
现在来看，觉得最大的差异在于web多数是无状态服务器，而游戏服务器多数是有状态的。
之前说的高频低频问题，web也是存在高频，如淘宝，如春节的12306.
req/resp模式的卡牌类服务器其实和web差不多。
而如那些有地图的游戏是会记录每个玩家的状态，地图服务器还会在服务器内运行一个类似客户端的地图处理逻辑。
如同客户端，服务器也存在一个刷新频率。不过一般比客户端的帧率低很多。大多数服务器是用单线程轮询，也有一些多线程，目前了解也不是很多。无法具体的表述。
等再研究一下mmorpg服务器再来更新吧
1） 技术有什么区别
简单说，web服务器更看重high throughput，也就是高吞吐能力，更不看重low latency也就是低延迟，而游戏服务器正好反过来，更看重low latency，更不看重high throughput，游戏更接近实时系统，甚至你可以认为游戏就是一种实时系统，虽然精度要求没那么高，偶尔挂掉其实无关紧要
所以web服务器，会使用多层，并增加io的方法，来提升吞吐能力，但是相应的，latency会被拉高，io是latency的天敌，io只要每增加一层，latency就会被放大一倍，一般游戏服务器的io就只有一层，客户端到服务器端，然后服务器端不会在网络上再做分层，尤其是在即时的战斗中，而web服务器经常是套了一层又一层，像j2ee那样分了三层不够，前面还要挂一个反向代理，算上数据库本身还有一大堆文章可以做，所以大型web服务器经常是分了五六层，甚至更多，比如知乎，改了go的架构，华丽地分了七层，神奇得很
2）思维上有什么区别
一般web服务器被认为是stateless，也就是无状态的服务器，会通过增加io，把状态的存储放在redis，还有进一步数据库等专用存储软件中，而一般游戏服务器被认为是stateful，状态直接放在内存中，因为这样存取的速度快，原因同上
3）架构侧重点
因为游戏服务器要把状态直接放在内存中，而且对于latency的要求比较高，要在短时间内完成io操作，所以游戏服务器对于并发的各种理念的理解会要求得更加深刻一点，web服务器常见的一个操作，就是把数据丢个数据库，然后开一个事务，如果ok，就commit，如果中间数据被修改了，就rollback，这种在游戏服务器中几乎是不可能被接受的，坦克开一炮过去，没打到难道还能rollback？开玩笑吧？
所以一般web的架构侧重于对于数据库的操作，而游戏服务器则侧重对于并发的操作，actor model很早就被应用于im以及游戏服务器中，im等社交服务器的考量接近游戏服务器，但是对于latency的要求会适当放低，但是两者对于并发的考虑是一样的
还有一个就是网络协议上，web服务器侧重http这种一问一答式的应用，而游戏服务器则侧重tcp，upd这种基于长连接的应用，所以一般web服务器可以很容易做到proactive，而游戏服务器一般需要reactive，需要挂listener来处理每一次socket上发过来的请求，而且处理请求和响应这里几乎会马上卷入并发处理的问题
4）本质上有无区别
对于一般的，针对web制作的服务器框架而言，比如php，java web，j2ee那些，有区别，有很大区别，一般web服务器做不到长连接以及相应的处理
但是我们知道了这两者的区别之后，我们就可以添加新的手段，比如reactive programming这些，来同时处理web/http和tcp这两者的请求，来让这两者无处理方式上的区别
比如我们正在做的基于vert.x的 开源项目 ，就同时host了im和 web 两种客户端的接入，我们自己用的游戏服务器，则是基于该开源项目的扩展
当然现在还没做完了，主要是等paulo的es4x依赖vert.x 4的版本正式发版，等es4x发版之后，我们再做一个release