我们团队建立伊始，是从原来的Web产品团队抽调人员组成的，在开发游戏的过程中，遭遇了惨痛的教训，在解决这些问题的过程中，本人对游戏系统和Web系统的本质区别做了深入思考。特通过三篇文章来记录思考所得，虽然本人没有大型游戏经历，结论难免有偏颇支出，希望对同行有一些价值。
说明：我们游戏服务器是使用java技术栈来实现的，文中不可避免涉及spring、redis这些技术因素，但不影响其普遍性。
这里要讲游戏系统的封闭性是对比web系统的开放性，对于从web转型做游戏的技术团队，理解这一点非常关键，如果照搬web系统的技术方案和解决问题思路，后果会惨不忍睹。
web系统的特点：
常见的web系统一般是解决现实世界某个特定需求的软件系统，这个系统是一个复杂业务链条中的一个环节，因此它必须能够与其他环节进行互操作。
以现在最常见的电商平台为例，思考一下它提供服务的过程中牵涉到的外部环节：
1）浏览商品信息
商品信息是从哪来的？一定是相关人员在系统的运行过程中不断录入的，在系统上线的时候，我们不可能预知有多少商品，最多预定义一下商品信息的格式
2）下单
这里就有一个库存问题，库存的变化是由商品的供货方提供的
3）用户下单支付
填写好发货信息后，选择某种支付方式进行支付，支付服务的提供者是谁？支付宝、微信、银行等，反正一定是一个第三方平台。
5）发货收货
订单支付成功后，系统通知商品的供货方发货，后续还要从快递公司拉取物流信息。
真实的情况可能比上面还要复杂得多，这里要强调的关键点是这个系统是开放的，在运行的过程中，需要与用户、商品供货方、支付平台、快递公司以及相关运营人员不断交换数据。
这种开放性对技术实现方案产生了极大的影响
1、整个系统被划分成很多独立性很高的业务子系统
每个子系统解决各自的问题，这样有益于降低整个系统的复杂度，方便各个子系统单独部署和上线。
2、无状态服务成为最理想方案
数据尽量都放在数据库或缓存系统里面，方便各个子系统共享必要的数据，同时由于数据完全独立于业务逻辑，那么这些子系统可以很方便地发布、重启，而不影响在其他业务。
3、对性能相对不敏感
用户使用web系统对性能要求不是特别高，用户通过若干的步骤以达成一个目标，每一个步骤1s以内的延迟是可以接受的。
4、技术标准化
把整个业务链放在一起考虑，其规模、复杂性、不可控性是令人恐怖的，需要多个公司、多个团队参与才能完成开发。因此每个独立的系统最好符合某种行业标准规范，对外提供标准的接口。进而导致各种标准的技术组件和技术方案层出不穷。
游戏系统的特点：
游戏系统是一个和现实世界没啥关联的虚拟系统（文化艺术上的关联对系统的技术实现不会有直接影响，这里不讨论），它试图构造一个虚拟世界，让用户沉浸其中。这个虚拟的世界是基本封闭的，它不与外部世界沟通，游戏角色的所有活动完全在这个世界内部完成。
从技术角度分析这里有两个重要的特点
1）游戏系统基本不与外部系统交互，所以在运行过程的所有的数据状态变化都在本系统内部完成，理论上可以一切尽在掌握
2）玩家在这个封闭世界中的活动应该非常的流畅自然，才能有沉浸的感觉，服务器的响应性能必须非常地高。
3）除非单机游戏，否则玩家与玩家之间的互动非常频繁，进一步增加了服务器的响应压力
由此导致了一系列的技术特点：
1）采用有状态的服务模式
玩家在游戏中的活动是连续的，他的状态连续地发生着快速的变化，无状态的服务系统是无法满足这样的性能需求的，所以游戏系统基本上都采用有状态的服务模式。所谓有状态的服务，就是用户的数据状态是驻留在服务器内存的，这样才能保证快速完成操作并响应客户端。只有在某些节点，用户的数据才会持久化到数据库。可以反面想一下，为什么web服务无法采用这种模式呢？原因就在于“开放性”上，一个不断和外部交换数据的系统，如果使用有状态的服务模式的，基本无法保证数据的一致性。
2）各个子服务之前独立性差
现在的游戏系统也是比较复杂的，也是一个分布式的计算系统；依据不同的场景将游戏系统先划分为若干子系统，每个子系统依据实际需要，部署一台或多台服务器实例，用户的数据和游戏指令在各服务器之间高速地流动，形成一个封闭的计算环境。但是，对比web系统，子系统相互之间的独立性相对“差很多”，为了保证性能，数据在各台服务器之间的流动是经过精心规划的，这样就导致系统的横向扩容能力没那么好，于是就需要分服机制。举个简单例子，在一个扔骰子博彩游戏里，大量玩家聚集在一个房间下注，那么一个房间的承载玩家数量必然是很有限的，你没办法通过添加硬件来扩充这个容量。
在这种情况下，为了针对各自的业务模式实现性能最大化，各大游戏开发商都形成自己一套特有的解决方案，开放的技术框架比较少。
3）前后端使用二进制通讯协议
另一方面，为了保证高性能，服务器到用户侧的通讯量也要尽量地少，于是通讯上一般采用二进制的格式，更多地考虑效率而不是可读性、兼容性。游戏系统避免考虑客户端版本的兼容，在PC游戏时代，客户端都具备自我更新的功能，在手游时代都是用脚本来编写客户端游戏逻辑。
4）开发人员素质要求
对开发人员的要求，从技术广度上要求较低，在这个领域，新的技术或方案更新挺慢的。但是对网络、算法、内存调优等技能有更高要求。因此，一旦后台框架建设完成，游戏领域经常出现开发者同时编写前后端逻辑的情形。
封闭系统的一扇门：
一个完全封闭的系统的是没有社会意义的，游戏系统唯一开放的部分就是“登录支付”。每个游戏系统基本都会有一个独立的登录支付系统，而且在中国特殊的国情下，这个系统有时候还蛮复杂，甚至超过游戏本省，因为要支持的渠道实在太多了。登录支付系统就好像游戏系统的一扇大门，大门背后是一个完全不同的虚拟世界。登录支付功能虽然重要，但要从游戏本质上来说，属于边缘子系统，订单、支付这样的功能从来不应该给系统造成性能压力（否则老板半夜要笑醒了）。