|
副问题[/!--empirenews.page--]
1.需求
因为“越通用的代码，就是越没用的代码”，以是在计划之初，我就以为应该行使分层的模式来构建整个体系。凭证游戏处事器的一样平常需求分别，最根基的可以分为两层：
底层基本成果：包罗通讯、耐久化等很是通用的部门，存眷的是机能、易用性、扩展性等指标。
高层逻辑成果：包罗详细的游戏逻辑，针对差异的游戏会有差异的计划。
我但愿能有一个根基完备的“底层基本成果”的框架，可以被复用于多个差异的游戏。因为方针是开拓一个得当独立游戏开拓的游戏处事器框架。以是最根基的需求说明为：
成果性需求
- 并发：全部的处事器措施，城市遇到这个根基的题目：如那里理赏罚并发使命。一样平常来说，会有多线程、异步两种技能。多线程编程在编码上较量切合人类的思想风俗，但带来了“锁”这个题目。而异步非阻塞的模子，其措施执行的环境是较量简朴的，并且也能较量充实的操作硬件机能，可是题目是许多代码必要以“回调”的情势编写，对付伟大的营业逻辑来说，显得很是繁琐，可读性很是差。固然这两种方案各有利弊，也有人团结这两种技能但愿能各取所长，可是我更倾向于基本是行使异步、单线程、非阻塞的调治方法，由于这个方案是最清楚简朴的。为了办理“回调”的题目，我们可以在其上再添加其他的抽象层，好比协程可能添加线程池之类的技能予以改进。
- 通讯：支持哀求相应模式以及关照模式的通讯(广播视为一种多方针的关照)。游戏有许多登录、交易、打开背包之类的成果，都是明晰的有哀求和相应的。而大量的联机游戏中，多个客户端的位置、HP 等对象都必要颠末收集同步，着实就是一种“主动关照”的通讯方法。
- 耐久化：可以存取工具。游戏存档的名目很是伟大，但其索引的需求每每都是按照玩家 ID 来读写就可以。在许多游戏主机如 PlayStation 上，早年的存档都是可以以相同“文件”的方法存放在影象卡里的。以是游戏耐久化最根基的需求，就是一个 key-value 存取模子。虽然，游戏中还会有更伟大的耐久化需求，好比排行榜、拍卖行等，这些需求应该特殊看待，不得当包括在一个最根基的通用底层中。
- 缓存：支持长途、漫衍式的工具缓存。游戏处事根基上都是“带状态”的处事，由于游戏要求相应耽误很是苛刻，根基上都必要操作处事器历程的内存来存放进程数据。可是游戏的数据，每每是变革越快的，代价越低，好比履历值、金币、HP，而品级、设备等变革较量慢的，代价则越高，这种特性，很是适实用一个缓存模子来处理赏罚。
- 协程：可以用 C++ 来编写协程代码，停止大量回调函数支解代码。这个是对付异步代码很是有效的特征，能大大进步代码的可读性和开拓服从。出格是把许多底层涉及IO的成果，都提供了协程化 API，行使起来就会像同步的 API 一样轻松恬静。
- 剧本：起源假想是支持可以用 Lua 来编写营业逻辑。游戏需求变革是出了名快的，用剧本说话编写营业逻辑正好能提供这方面的支持。现实上剧本在游戏行业里的行使很是普及。以是支持剧本，也是一个游戏处事器框架很重要的手段。
- 其他成果：包罗按时器、处事器端的工具打点等等。这些成果很常用，以是也必要包括在框架中，但已经有许多成熟方案，以是只要选取常见易懂的模子即可。好比工具打点，我会回收相同 Unity 的组件模子来实现。
非成果性需求
- 机动性：支持可替代的通讯协议;可替代的耐久化装备(如数据库);可替代的缓存装备(如 memcached/redis);以静态库和头文件的方法宣布，差池行使者代码做过多的要求。游戏的运营情形较量伟大，出格是在差异的项目之间，也许会行使差异的数据库、差异的通讯协议。可是游戏自己营业逻辑许多都是基于工具模子去计划的，以是应该有一层可以或许基于“工具”来抽象全部这些底层成果的模子。这样才气让多个差异的游戏，都基于一套底层举办开拓。
- 陈设便利性：支持机动的设置文件、呼吁行参数、情形变量的引用;支持单独历程启动，而无须依靠数据库、动静行列中间件等办法。一样平常游戏城市有至少三套运行情形，包罗一个开拓情形、一个内测情形、一个外测或运营情形。一个游戏的版本更新，每每必要更新多个情形。以是怎样能只管简化陈设就成为一个很重要的题目。我以为一个好的处事器端框架，应该能让这个处事器端措施，在无设置、无依靠的环境下独立启动，以切合在开拓、测试、演示情形下快速陈设。而且能很简朴的通过设置文件、可能呼吁行参数的差异，在集群化下的外部测试可能运营情形下启动。
- 机能：许多游戏处事器，城市行使异步非阻塞的方法来编程。由于异步非阻塞可以很好的进步处事器的吞吐量，并且可以很明晰的节制多个用户使命并发下的代码执行次序，从而停止多线程锁之类的伟大题目。以是这个框架我也但愿是以异步非阻塞作为根基的并发模子。这样做尚有其它一个甜头，就是可以手工的节制详细的历程，充实操作多核 CPU 处事器的机能。虽然异步代码可读性由于大量的回调函数，会变得很难阅读，幸好我们还可以用“协程”来改进这个题目。
- 扩展性：支持处事器之间的通讯，历程状态打点，相同 SOA 的集群打点。自动容灾和自动扩容，着实要害点是处事历程的状态同步和打点。我但愿一个通用的底层，可以把全部的处事器间挪用，都通过一个同一的集权打点模子打点起来，这样就可以不再每个项目去体谅集群间通讯、寻址等题目。
一旦需求明晰，根基的层级布局也可以计划了：
最后，整体的架构模块相同：
2.通讯模块
对付通讯模块来说，必要有机动的可替代协议的手段，就必需按必然的条理举办进一步的分别。对付游戏来说，最底层的通讯协议，一样平常会行使 TCP 和 UDP 这两种，在处事器之间，也会行使动静行列中间件一类通讯软件。框架必必要有能同事支持这几通讯协议的手段。故此计划了一个条理为: Transport。
（编辑：河北网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
