网游后端平台化的技术构想.pptVIP

* 网游后端平台化的技术构想 参与过国内几款网游的后端研发工作，有 mmo，也有 web，有感于目前大大小小 的游戏公司的开发现状：重复从头开发，项目与项目缺乏共用性，直接导致项目 周期变长，成本增加，风险也随之上升。为什么不把共用的部分框架化，平台化 呢？ 有点类似于前端的引擎一样。沿着这个思路，我们来统计一下后端有哪些 部分是可以平台化的？ 1. I/O 网络 I/O，磁盘 I/O，完全可以做到对上层游戏逻辑透明，不需要关心协议，缓 存，也不需要关心到底是用 epoll，iocp，逻辑层唯一需要关心的是数据的投递 目的地和来源地。 2. 线程模型 线程模型稍微复杂一点，因为关系到游戏逻辑的并行处理，这部分在我看来，可 以做到 99%的透明。 3. 内存模型 内存模型基本上于逻辑无关，除非自定制内存池，是可以平台化的。 这三个部分，大部分公司都或多或少有一些自己的封装，虽然不够通用，但至少 满足需求。 4. 逻辑部分 大部分游戏的逻辑大同小异，至少从技术角度来看是这样的，像 Quest, mail, 甚 至技能等等，相信制作过游戏的朋友都会有这个感触，那为什么我们要重复劳动 呢？虽然这也是我们程序员存在的价值，但可不可以把事情变简单一点，让我们 轻轻松松的也能赚一份薪水。 我的初始思路是这样的： 构建一套框架， 有点类似于 bigworld 的想法，不过不同的是，我只专注于后端， 并且我希望这个框架不单单只能应用在 mmo 这样的特定场合，这个框架应该包括 这样几个部分：可定制的服务模型， 通用的逻辑流程和附加工具。 可定制的服务模型： 提供网络服务，线程服务，内存服务，文件服务等基础服 务。并且可灵活定制。这个模型让我们立即就有一个高度可用的服务器。 通用的逻辑流程：提供一整套网游基础功能的框架，比如聊天，ai，任务等等。。。 这部分可以使我们摆脱重复编写类似功能的代码，冗长而且杂乱。 附加工具： 就像前端引擎一般都会携带大量工具一样，后端其实也需要各种工 具，就性能分析工具，内存分析工具等，功能开发部分还需要表格转换工具，日 志分析工具，系统监控工具等等，工欲善其事，必先利其器嘛，完善的工具是必 备的。 由这三个部分组成的后端平台，基本上囊括了游戏后端开发的主要工作，设想一 下，当后端开发只需要变更一些配置，然后再根据游戏需求编写少量的逻辑代码， 就轻松搞定的话，岂不是乐事。 当然，以上只是我的构想，有些朋友可能会认为，光实现这套框架得要多少人力 物力呢，再者，这样的平台究竟能节省到多少的开发量呢？毕竟，每款游戏都不 太一样的。对于后者，我的回答是现在的游戏大部分都一样，或者换个说法，去 看看 17173 上的 top 10，看看他们之间能有多少的差异。所以真有这样的平台， 我相信游戏开发，至少后端部分，我初步估算是可以节省 70%-80%的开发量的。 对于前者，这套平台我其实已实现了部分原型，并且部分也应用在了商业游戏中， 业务时间也在持续的研发中，我的总体感受用一句话来概括，那就是：磨刀不误 砍柴工！ 但愿我的这些粗略想法能给各位同行以启发，共同进步。 --------------------------------------------------------------------- ------------------------------------------ rev: Oct 09 长假期间，一直远离网络，未及时更新，各位见谅。 正应了上面那位朋友说的那样： “难就难在这套服务端要以什么样的形式出 现”。事实上，同样的概念，而不同的实现，其效果可能千差万别。我不是一个 喜欢泛泛而谈的人，我喜欢把自己的想法实现，我喜欢看着代码按我的意图运转， 所以，接下来我们来谈谈实现层面的问题。 从技术的角度出发，我认为这套平台的应该拥有下面这些特性： 1： KISS 原则 简洁的东西未必是优秀的，但优秀的东西一定包含简洁这一特质，世界万物，自 然之道，无不透着简洁之美！所以，早有人就说上帝粒子是不存在的，因为理想 模型不够简洁，不符合造物主的一贯原则，而实验结果也证实了。 所以，这套 平台一定要简洁。易于掌握，易于维护。 2： 高灵活度 既是平台，自然要兼顾到尽可能多的应用场合，尽可能广的设计需求，尽可能大 的可操作空间。平台的灵活度决定了它的适用范围。 3： 高并发性 随着技术的发展，并发性受到越来越多的关注，譬如 erlang 等。很难想象现在 设计一个低并发甚至不支持并发的后台系统能有多大的实用价值。 4： 高可用性 再优秀的系统，如果不稳定，经常出错，甚至宕机，那也是白搭。高可用性是一 切设计的基石。 5： 高效率 这里说的高效率不仅仅指高运行效率，还有开发效率，在网游生命期越来越短的 背景下，从技术角度出