面向网络游戏的“云”应用平台浅析——2009-1-15 CTO俱乐部第一次聚会“云计算”后记

　　CTO俱乐部第一次聚会的主题是“云计算”，关于聚会的概述发表在：
　　2009-1-15 CTO俱乐部第一次聚会，http://blog.csdn.net/hu_zhenghui/archive/2009/01/16/3793180.aspx
　　此后我在“云”存储、应用实例与应用平台、应用平台粒度、“专用”与“通用”、市场与销售等几个方面谈了个人对于“云计算”的粗浅认识，接下来我将尝试在这些认识的基础上，参考SWOT分析思路，以网络游戏为例探讨“云”应用平台的分析思路，请各位前辈和专家斧正。
　　首先从威胁（Threats）的角度考虑，目前的网络游戏有哪些局限性，先从玩家的角度分析。
　　1. 单服务器性能瓶颈。目前多数网络游戏的单服务器性能瓶颈是几千玩家同时在线。
　　2. 由于单服务器的性能瓶颈，因此有了转服（转区）、合服（合区）、开新服（开新区）等处理方式，同时也已经常态化，但毕竟会影响玩家的体验。
　　3. 不同服务器间的玩家分布不平衡导致用户在转服（转区）、合服（合区）会选择对自己有利的方案，不利于游戏的平衡性。
　　4. 单服务器限制了游戏中玩家的组织，影响了游戏对于玩家的粘度。
　　……
　　再从运营商的角度考虑。
　　1. 单服务器使得克隆成为可能，并进而导致私服的出现，造成损失。
　　2. 对于第三方团队开发的网络游戏而言，运营商难以对开发团队进行控制。
　 　3. 由于开发团队的技术水平参差不齐，由于程序缺陷导致玩家虚拟资产的损失将由运营商承担，虽然运营商可以要求关键数据和敏感数据调用专门的程序接口，但是无 法保证代码缺陷对非关键数据和非敏感数据的误操作，进而间接导致玩家虚拟资产的损失或者可玩性下降，运营商也不可能通过审阅代码来避免这个问题。
　　……
　　然后从优势（Strengths）的角度考虑，这些局限性是否属于“云”平台的解决范围。
　　1. 可扩展的性能是“云”应用平台的主要功能。
　　2. “云”应用平台可以提供超过普通单服务器的大容量数据访问能力。
　　3. “云”应用平台没有独立的服务器的概念。
　　4. “云”应用平台为之上的具体应用提供相应的接口。
　　……
　　接下来从机会（Opportunities）的角度衡量。如果有了面向网络游戏的“云”应用平台，那么能否解决上述的问题呢？
　　1. 可扩展的性能可以消除单服务器性能瓶颈。
　　2. 可扩展的性能可以消除转服（转区）、合服（合区）、开新服（开新区）等处理方式，消除了由此对玩家体验的影响。
　　3. 消除了转服（转区）、合服（合区）之后，所有玩家在同一个游戏区域中，可以消除分区对于游戏平衡性的影响。
　　4. 大容量数据访问能力可以使所有玩家在同一个游戏区域中，可以自由的形成组织，保证了玩家组织对于玩家的粘度。
　　5. 不存在独立服务器的概念，也就不可能克隆服务器，也就不会有私服。
　　6. 由于游戏在“云”应用平台需要调用相应的程序接口，形成技术壁垒后，便于运营商对开发团队的控制。
　　7. “云”应用平台不仅通过提供专门的接口来处理关键数据和敏感数据，而且由于用户数量的庞大，使得开发团队将必须通过“云”应用平台来存取用户的非关键数据和非敏感数据，排除了在自行存储区中存取的可能。
　　……
　　最后看劣势（Weaknesses），在解决这些问题的同时，又会出现出现哪些新情况，新问题呢。
　　1. 无论对于持续的TCP连接，还是对于无状态的HTTP连接，都应当向用户提供统一的接入，因此网络接入和具体运算单元之间需要分离，同时还需要保证效率。
　　2. 大容量的数据访问使得不能提供关系型数据库的查询能力。
　　3. 由于不能提供关系型数据库的查询能力，因此在数据结构设计时，就不能遵循第三范式，这就需要重新制订数据库结构设计的工作方法。
　　4. 大容量的数据访问需要将大容量的单表进行切片（例如百万级的用户数据），对于影响到多个切片的单表的事务，应尽量拆分来避免死锁。
　　5. 由于一个应用的负荷超过单服务器的容量，因此所有中间状态数据都应通过“云”应用平台统一的接口存放，因此不适宜采用服务实例中有状态的应用服务器（例如JAVA、.NET），适宜选用脚本。
　　……
　　面对这些问题，合理的安排路线图、设置里程碑会有助于解决这些问题，下面谈一下我所设想的面向网络游戏的“云”应用平台的几个关键里程碑。
　　1. 抛弃对于单机开发既有技术特点的执着，例如数据库的管理和优化、程序开发的设计模式等等，避免陷入单机思维。
　　2. 将数据结构按照两个维度分解，第一个维度是能否简化为第一范式和第二范式，第二个维护是数据量是否符合单独数据库服务器的负荷。
　　3. 将可简化为第一范式和第二范式，又符合单独数据库服务器负荷的数据结构独立出来。
　　4. 将不可简化为第一范式和第二范式，但符合单独数据库服务器负荷的数据结构独立出来。
　　5. 将可简化为第一范式和第二范式，但不符合单独数据库服务器负荷的数据结构独立出来，此时需要考虑将数据结构切片，典型的例子就是用户个人信息。
　 　6. 依据游戏本身特征，将不不可简化为第一范式和第二范式，也不符合单独数据库服务器负荷的数据结构中，找出在实际运行过程中，对于“实时”要求最低的数据结 构，将这部分数据结构转化为符合第一范式和第二范式的情况，结合游戏本身的延时来保证第三范式所要求数据一致性，例如在基于地图的游戏中，将地图按坐标分 区，当玩家在地图中跨越区域时，通过过场动画的延时为服务器端的数据传输赢得时间。
　　7, 对于不可简化为第一范式和第二范式、也不符合单独数据库服务器负荷、还要求实时的数据结构，搭建专门的自动仲裁服务器、保证部分处理的实时，而对另一部分延迟，从而避免出现由于大量的锁等待导致全面延迟的情况。
　　……
　　最后关于本文的讨论，需要特别说明的是：
　　1. 本文的着眼点不是讨论一个用于生产的网络游戏“云”应用平台，而是尝试通过一个具体的“云”应用平台分析过程来深索分析“云”应用平台的思路。
　　2. 对于专业游戏人士，本文的认识难免粗陋，敬请指正。
　　3. 本文参考了SWOT的分析思路，但并不是严格遵循。
　　4. 对于路线图仍只是设想。