轻时代来临架构师分享手游五大设计要点

簡體傳統

第一节：轻网游时代已经来了

　　“世界频现三消，上帝也爱消除”，腾讯广告做得不多，但这次做了，而且还涵盖央视。广告充满了创意，很好的契合了最新推出的微信手游----天天爱消除。这款游戏不到三天即迅速获得了超越2000W的下载量，并在后续取得了巨大的成功！天天酷跑、全民飞机大战等后来的微信游戏在证明了自身产品优秀设计的同时也印证了一个新的时代----轻网游已经来临。

第二节：轻网游的特点

　　轻网游以最新的微信游戏为代表，他们共同的特点是产品设计轻量化，没有传统端游的巨大安装包，可占用玩家碎片化的时间随时随地利用手机等设备来体验游戏并随时可以中断游戏。轻网游用三个字可以概括“小、轻、精”，小是指安装包小；轻是指随时随地体验和终止；精则是指产品品质精良。

第三节：轻网游设计要点

　　轻网游在设计上有着自己的特殊性，需要架构设计师在如下几方面有全面的考虑；为便于后面详细说明，先看某游戏的架构设计如下图：

轻时代来临资深架构师分享手游五大设计要点 ...

　　接入层：这里解决的是玩家的接入问题。玩家如何进入游戏，如何保持链接，相关资源的下载访问速度如何解决都在这里要有设计和解决方案。

　　接入层主要问题一：帐号体系

　　各大开放平台都有一套帐号体系，互不相同，设计师需要考虑好接入哪种帐号体系并在各个帐号体系中采用何种兼容策略；幸运的是腾讯有很强的帐号体系ptlogin可直接接入，大大降低了用户进入的门槛。有些外部团队则没那么幸运，如果这个团队不打算接入其他现有的帐号体系而自己独立建设，那么成本高的会大大超出你的想象，有时候这也是团队项目成败的关键因素之一。

　　接入现有的帐号体系都比较完善了，不赘述；新建帐号体系需要额外重点考虑其安全性、稳定性和容灾。帐号体系是比较独立的系统可分解出来单独阐述，这里与网游相关性较低，不赘述。但其设计原理与本文类似，可参照执行。

　　接入层主要问题二：负载均衡

　　负载均衡主要的目的在于削峰填谷、就近接入、解决跨网等问题；

　　削峰填谷：把流量智能导到负载比较低的服务器，但又不能形成访问毛刺；

　　就近接入：把链接导向距离玩家比较近的服务器，通常这个链接质量较好

　　跨网问题：国内网络很奇葩，跨网非常普遍的存在，有时候距离玩家更近的服务器是跨网的，这时候链接质量会变差，需要优先在同网内选择服务器。

　　腾讯平台典型的解决方案就是GSLB、TGW、CDN，这里不赘述，可单独查阅资料了解。

　　接入层主要问题三：保持在线

　　网游的轻带来的问题是玩家可能处于移动当中，随时更换网络状态；频繁的登入和注销绝不是好主意，这里需要设计玩家状态保持机制，避免不必要的登录认证，以提升用户游戏体验。

　　逻辑层：通常游戏逻辑可在一个或者多个进程Gameserver中处理，现在服务器都为多核处理器，为充分发挥处理器的计算能力，建议选择多个进程协同工作的方式。轻网游一般游戏逻辑较为简单，逻辑进程通常分无状态服务和有状态服务两种模式；

　　无状态服务模式适合玩家交互不复杂的场景，这种场景不需要频繁的访问和修改玩家数据或者逻辑相对简单；无状态服务模式便于动态扩容和调度，可以做到玩家完全无感知。部落守卫战就是采用无状态服务模式开发的。这种模式在处理复杂交互的时候成本很高，需要频繁访问cache和DB，对编程要求也相对较高。

　　有状态服务模式适合玩家间有复杂交互的场景，通常一组服务中存储了大部分玩家数据，访问cache和DB回写的需求低，编程难度低；有状态服务模式通常依赖于热备来容灾，有时对数据会有回档的需求。对于轻网游来说，通常一组服务甚至可以部署在同一台物理主机上以提升通讯效率和降低热备部署要求；

　　各逻辑进程中的通讯方式可以通过共享内存、网络等完成。比如腾讯组件TBus。

　　逻辑层通常还有很多全局公用服务。比如关系链、支付、商城、邮件、经分、安全等模块。有一些系统需要抽离出来变成全局公用服务，解决共性的单一问题。已经有相当多的模块建成了独立的子系统，系统内部已经独立运营，可以支持业务的灰度和容灾，对业务则提供了接入SDK，大大降低了接入难度。

　　数据层：游戏数据的临时及持久化方案在这里解决，cache是一种临时的高效数据存储单元，持久化数据则需要使用各种DB或文件来落地。

　　数据层问题一：Cache

　　除了本机内存用作临时的cache存储数据外，还有很多公用的开源组件可供选择，比如Memcached， CMEM等。选择cache组件的时候要充分考虑系统对cache分布能力、灾备能力、存储能力等的需求；有状态的服务多采用本地共享内存，无状态服务多采用分布能力、容灾能力较强的公用组件如Memcached。由于往往cache无法缓存所有数据，这时候需要设计cache的淘汰策略，按照热度淘汰往往效果不错；硬件越来越便宜，使用超大内存尽可能多的缓存数据甚至全部数据也是一种不错的方案。如果简单的增加内存就可解决问题，就不要太在乎硬件成本，那根本不值得设计者为其绞尽脑汁，因为增加内存太廉价高效了。

　　数据层问题二：DB

　　轻网游对存储要求依赖于系统的规模，在设计之初要充分考虑，可通过各种数据模型估算出整个系统对数据的存储规模，这非常关键，在这里太短视或者懒惰会导致后期的维护及修改成本非常高昂。

　　通常mySql是不错的选择，redis也不错，他们适合小型游戏的存储，在分布、灾备方面做得还不够，仍需要有更多设计和考虑；幸运的是公司这方面有很多可供使用的系统如CDB、GCS等等，可分别详细了解并根据需求选择。

　　数据库的表设计通常需要避免同一张表中有太多的记录，mysql中一张表的记录在百万级别就差不多了，不宜超过千万，可通过分库分表的方式减小表的记录数。这会大大提高数据库的查询效率。

第四节：轻网游的灰度、扩容和容灾

　　灰度

　　轻网游的研发周期一般都不长，研发人员没有足够的时间去充分测试和验证各系统，团队往往通过运营一个灰度版本的方式来试错。通常体验服、抢先服都是这类方法。即使是正式服，有时候也有必要跟据玩家属性进行必要的游戏内容控制，这些在设计之初都必须充分考虑并合理设计。灰度做得好，产品就多了一个保证，可以让运营上更加灵活，控制事故对项目的影响范围。

　　扩容

　　游戏一旦在线上，很多需求都是用户和运营驱动的，玩家爆炸式的来临的时候，系统需要有足够的灵活性以迅速响应。设计师需要了解运营策略，并根据数据模型对扩容提前做出设计。全区全服的游戏可随着玩家的情况动态扩容，分区分服的游戏则需要不停的开新服、合老服；这些必须在设计之初进行充分设计。而有些系统并非项目组内可控制比如GSLB，需要对相关系统的容量及扩容策略有足够的了解。有些系统需要项目组来申请才会扩容。

　　容灾

　　系统一旦出现了问题，这时候灾备策略就非常重要。设计者要悲观思维，充分考虑每个节点的容灾设计，做到万无一失。没有无故障的系统，只有无故障的设计。优秀的设计会是系统良好运营的保障。系统中不同模块的容灾策略也有区别，热备、冷备要根据系统进行合理选择。

第五节：更新及安全

　　更新

　　更新是轻网游的重要组成部分，同传统的端游、页游等PC平台上的游戏不同，以手机为代表的轻网游对游戏安装包非常敏感。设计师需要针对不同用户场景设计系统的更新策略，需要保持版本兼容性的同时又要兼顾不同版本、不同终端的玩家的游戏体验。这是一个很难权衡的工作，设计师必须做出一个合适的选择。通常第一个安装包要够小，至少要做到不太大，这样有利于产品用户的新进；软件更新则需要跟据用户不同的网络条件给出差异化的选择，移动网络状态下尽量减少不必要的更新，待用户在Wifi状态下则可以进行较大的版本更新；设计不好的更新策略会导致玩家迅速流失，有时候只是一个更新时机的选择问题，有时候就是一个友好的提示，就这么简单。

　　安全：外挂和反作弊

　　外挂的多少有时也是判断游戏是否成功和有影响力的标志，外挂泛滥也会导致一款良好的游戏夭折；设计师要设计好一整套立体的反作弊检测及运营处理机制，从客户端一直到后端，反作弊的检测无刻不在。对内存的保护、协议的加密、异常数据检测都非常基础但也非常重要；还有对前端传来的数据都必须怀疑检测，不信任前端通常是正确的。完善的日志记录和保存也是反作弊的重要手段，有时候这需要消耗大量的存储空间，设计师必须做好准备。