参与过多款国产网络游戏的后端研发工作，包括mmo、web等。 令我印象深刻的是目前大大小小的游戏公司的开发现状：从头开始重复开发，项目之间缺乏共性，直接导致项目周期较长。 随着成本的增加，风险也随之增加。 为什么不框架和平台化共享部分呢？ 它有点像前端引擎。 顺着这个思路，我们来算一下后端有哪些部分可以平台化？
1.输入/输出
网络I/O和磁盘I/O对于上层游戏逻辑可以完全透明。 无需关心协议、缓存、是否使用 epoll 或 iocp。 逻辑层唯一需要关心的是数据的传递目的地。 和原产地。
2. 线程模型
线程模型稍微复杂一些，因为它涉及游戏逻辑的并行处理。 在我看来，这部分可以做到99%透明。
3. 内存模型
内存模型基本与逻辑无关，除非定制内存池，否则可以基于平台。
对于这三个部分，大多数公司或多或少都有自己的套餐。 虽然不够通用，但至少满足了需求。
4.逻辑部分
大多数游戏的逻辑都是类似的，至少从技术角度来看，比如任务，邮件，甚至技能等等，相信做过游戏的朋友都会有这样的感觉，那为什么还要重复工作呢？ ？ 虽然这也是我们程序员存在的价值，但是我们能不能把事情变得简单一点，这样就可以轻松的赚到工资呢？
我最初的想法是这样的：
构建一个框架和bigworld的思路有些类似，但不同的是我只关注后端，并且希望这个框架不仅仅能够应用在mmo等特定场景，这个框架应该包括以下内容部分：可定制的服务模型、通用逻辑流程和附加工具。
可定制的服务模型：提供网络服务、线程服务、内存服务、文件服务等基础服务。 并且可以灵活定制。 这种模型使我们能够立即拥有一个高可用的服务器。
通用逻辑流程：提供一套完整的基本网络游戏功能的框架，如聊天、AI、任务等。 。 这部分可以让我们免去重复编写类似功能的代码，冗长而混乱。
附加工具：就像前端引擎一般都会搭载大量的工具一样，后端其实也需要各种工具，比如性能分析工具、内存分析工具等，功能开发部分还需要表转换工具、日志分析工具、系统监控工具等等，工欲善其事，必先利其器。 完美的工具是必须的。
这三部分组成的后端平台基本涵盖了游戏后端开发的主要工作。 想象一下，当后端开发只需要改变一些配置，然后根据游戏需求编写少量的逻辑代码，就可以轻松完成。 如果真是这样，岂不是一件值得高兴的事？
当然，以上只是我的想法。 有的朋友可能会想，实现这个框架需要多少人力、物力。 此外，这样的平台可以节省多少开发工作量？ 毕竟，每场比赛都是不同的。 对于后者，我的回答是，现在的游戏大部分都是一样的，或者换个说法，看看17173上的前10名，看看它们之间有多大的差别。 所以如果有这样一个平台的话，我相信游戏开发，至少是后端部分，我初步估计可以节省70%-80%的开发精力。 对于前者，我实际上已经实现了这个平台的部分原型，其中一些也被用于商业游戏中。 该业务也在不断研究和开发中。 我的总体感受可以用一句话来概括，那就是：磨刀不误。 樵夫！
希望我的这些粗略的想法能够给同事们带来启发，共同进步。
-------------------------------------------------- -------------------------------------------------- ----------
修订：10 月 9 日
长假期间，我一直没有上网，没有及时更新。 请原谅我。
正如上面朋友所说：“困难在于这个服务器会以什么形式出现”。 事实上，同样的理念但不同的实现可能会产生截然不同的效果。 我不是一个喜欢泛泛而谈的人。 我喜欢实现自己的想法，也喜欢看到代码按照我的意图运行。 那么，接下来我们来谈谈实施问题。
从技术角度来看，我认为这个平台应该具备以下特点：
1：KISS原理
简单的东西不一定是优秀的游戏后端开发，但优秀的东西一定包含着简单的品质。 世间万物、自然之道，无不充满着质朴之美！ 因此，很早就有人说上帝粒子不存在，因为理想模型不够简单，不符合造物主的一贯原则，而实验结果也证实了这一点。 因此3D角色，这个平台必须简单。 易于掌握且易于维护。
2：灵活性高
作为一个平台，自然要考虑尽可能多的应用场景、尽可能广泛的设计需求、尽可能大的可操作空间。 平台的灵活性决定了其应用范围。
3：高并发
随着技术的发展，并发受到越来越多的关注，比如erlang等。 很难想象设计一个低并发甚至不支持并发的后端系统会有多大的实用价值。
4：高可用性
系统再优秀，如果不稳定，经常出错，甚至死机，也是没有用的。 高可用性是所有设计的基石。
5：效率高
这里所说的高效率游戏后端开发，不仅指运行效率高，还指开发效率高。 在网络游戏生命周期越来越短的背景下，从技术角度来看，如何快速开发一款游戏产品是一个值得认真思考的问题。 。
针对以上特点，我们来讨论一下设计思路。 我的想法应该大致是这样的：
平台的原子组件是服务（以下简称服务），也就是说服务是系统的最小组件。 整个平台由多项服务组成。 服务与服务可以组合成服务，运行时可以增加或减少服务。 这里的服务有点类似于Erlan中的进程概念，可以并行处理，可以热替换。 服务由事件驱动。 服务有标准接口和自定义接口。 系统组成大致如下图所示：
图中的方框代表各个服务。 这些服务的划分非常随意，没有经过深思熟虑。 它仅用于说明该想法。 服务之间是事件流，它驱动整个系统。 它看起来有点像微内核操作系统模型。
服务的划分是一个小困难。 其实我觉得没有什么独特的。 除了元服务之外，其他服务的划分取决于设计者的想法。 这里可以实现上面提到的通用逻辑处理模型。 举个小例子，比如团队系统。 事实上，大多数团队系统都是相似的。 不可能是人数不同、权限不同、组队奖金不同，但组队处理流程却几乎是一样的。 对于这个功能，你完全可以创建一个可定制的团队功能原型。 在不同的产品中，您可以根据需要修改一些设置，以快速达到目的。
关于服务的并发，我的假设是服务应该自由支持并发，这意味着它们可以并行处理并独立部署。 服务的并发性要求每个服务的编写变得更加困难，在这方面可以做出妥协数据报告，取决于系统设计者。
总结一下我的想法，简单来说就是构建一个以服务为单位、事件流驱动的服务模型。 在这种模式下开发游戏时，在我看来，与游戏逻辑无关的服务基本可以保持不变。 甚至可以在9个成品服务的基础上，通过修改设置、配置、参数等来修改与逻辑相关的服务，通过服务实现的手段来达到目的。 大家想一想，是不是比现在的方法简单呢？ 至少，听起来是这样！
抛砖引玉，筑巢引凤！ 如果你有更好的实现思路，甚至更好的想法，可以和我交流。 这是我的最终目标，共同进步。
