游戏框架和互联网框架的对比

原贴：https://www.cnblogs.com/beef/p/7743594.html

• 项目迭代周期对比互联网的迭代模式

  

  游戏项目的开发周期

  

通过上面的比对，我们可以看出互联网项目每次的需求迭代可以更敏捷、更快速，因为它可以把大的需求拆分为多个小的具体实现，这样能保证不断地持续交付和部署。

而游戏相比互联网的迭代就会困难些、时间周期更长些，因为一款游戏能开始交付给用户，最基础的功能和玩法都要完备了才能测试和使用。

• 请求通信机制对比

互联网中一般为请求-响应模式，通常情况下每次请求都是同步阻塞方式；而游戏中大多为请求-推送模式，不仅推送自己，还推送给游戏中其他的用户，游戏中每次请求都为异步非阻塞方式。

小结：互联网服务器和游戏服务器最大的区别实际上就在于“状态”，游戏服务器的状态是实时快速变化的、可以容忍丢失的、需要大量广播同步的；而互联网服务器的状态一般是持久化的、不容忍丢失的、只和特定客户端相关的。所以在游戏中实现DevOps的难度比互联网大得多，而互联网成熟的实现方案也不能完全的照搬照抄到游戏中来。接下来我将从游戏构架—DevOps实施的源头—来分析介绍常见游戏服务架构是什么样的？

常见游戏服务架构分析–DevOps根源

• 休息卡牌游戏

  这类游戏一般采用http通信模式，它的架构和常用的web服务器架构差不多，使用redis集中式缓存保存游戏状态，这样就能通过nginx进行负载，游戏服可以支持无限水平扩展。

• 开房间游戏

  这类型的游戏一般来说服务器端会分为两个部分：一是大厅服务器，一是房间服务器。大厅服务器是一个巨大的广播集群，负责不太实时的数据传输和查询。房间服务器是一组可以快速租用、退还的小型实时广播服务进程。

  在大厅服务器中，所有在线的玩家，都按其ID来分布在多个进程中的一个，在玩家之间的查询、广播操作时，采用多个服务器并行操作，最后汇总结果的方式来提供。这样的操作延迟是会比较高，但是能让海量的用户数据存储到不同的机器上；而房间服务器则只负责提供具体的游戏广播功能，一旦玩家组成了群组进入，大厅服务器会拷贝数据到房间服务器，而房间服务器就只对这几个玩家负责了，游戏结束则清理掉这些玩家数据，准备新的游戏。

• 分服游戏

  分服模型是游戏服务器中最典型，也是历久最悠久的。其特征是游戏服务器是一个个单独的世界，每个服务器的帐号是独立的，每台服务器用户的状态都是不一样的，一个服就是一个平行的世界，各服之间互不相干。

• 全服模式

  尽管分服的游戏模型已经运营了很多年，但是有一些游戏运营商还是希望能让尽量多的玩家一起玩，因为网游的人气越活跃，产生的交互越多，游戏的乐趣也就越多，所以就要求能开发出满足大量用户在线互动的游戏服务器模型——全服全线模型。

  SOA架构模式是一个经典的分布式软件架构模式，服务之间使用RPC运程调用功能，而服务的注册和发现则使用ZooKeeper这样的目录服务器。这样游戏服务就拆分为三层结构：最前边的网关（gate）服务器、中间为各游戏服务器（gameServer），最后边的数据库（DB）服务器。这样把网络功能单独提取出来，让用户统一去连接一个网关服务器，再由网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网关服进行交换。所有与DB交互的都连接到DB服务器来代理处理。

小结：现在游戏服务器变得越来越大，不同游戏其实又具有很多相同的功能，所以如何把游戏服务进行拆分解耦，从而实现游戏的服务化就变得相当重要了，接下来我将进一步介绍游戏服务是如何拆分的？

游戏服务的解耦–分而治之思想

• 业务层面拆分

  从业务层面，其实所有的RPG游戏都具有武将、属性、背包、任务和技术等五大基础系统，而各游戏的差异化大多在不同的玩法系统，业务系统和活动系统也有很多相似的地方。板面的做法和配料

• 功能层面拆分

  从功能层面，像登陆系统、客服系统、统计系统和监控系统我们也都可以做为通用的游戏服务，提供给各游戏项目使用，从而实现游戏业的SAAS平台。

• 多维度架构

  一套游戏平台面向不同的部门和人员，所以也需要从不同的维度考虑和构建，从而尽量满足大部分人的需求和便利。