kbengine底层架构很庞大功能很完善。底层采用c++，而写逻辑只需要使用python，大家都知道python是一种开发效率非常高的语言。
网络层被底层封装的很好，在写逻辑的时候几乎可以忘记rpg等细节过程，远程访问非常方便
例如访问客户端的一个远程方法:
self.client.func(xxxx)
数据库的读写也变成全自动化了，在一个def文件中对一个实体进行定义底层就能自动建表，自动存储和读取， 对于逻辑层而言几乎可以忽略繁琐的db操作了， sql文件都不用了。
只关心怎么使用这些数据。
kbengine下载:
https://github.com/kbengine/kbengine
KBEngine。 这个是我最近使用的。从零开始学习服务器相关的内容，并且在一个月的时间内实现了一个棋牌游戏（服务器+客户端）。这个开源的服务器是我感觉最专业，代码实现最漂亮的。 参考BigWorld引擎，c++加python的实现。理论上可以实现全区全服或者是魔兽世界那样的mmo。 我之前也想一步到位，学习一个终极的服务器框架，然后可以解决自己的所有问题。 不过现在看来他有几个缺点（严格来说是与我自己的习惯和实际情况有出入），这个也是我要重点分析的，同时也是我选择游戏服务器框架的依据。
a、框架结构非常专业，但是同时非常厚重。 编译时间很长，服务器启动时间也很长（10~20秒），部署也非常麻烦（在linux上面要安装openssl，编译python，设置环境变量）
b、分布式并不仅仅体现在多个逻辑服务器上面，而体现在多个逻辑服务器（场景服务器）数据可互通。 这个也是KBEngine非常强大的地方。但是我对这方面的需求反而很低，因为这样的需求是专为MMO服务的，但是我要实现一个棋牌游戏或者手游并不需要考虑太多的数据互通。 只要把公共数据库维护好就可以做一个简单的全区全服的手游了（比如coc）。 没有这方面的需求，但是又需要承担其消耗有点得不偿失。
c、python作为脚本语言，我如果仅仅是实现简单的逻辑还没什么问题。但是一旦我所有的服务器逻辑都是python来实现了，那么性能就会成为问题，甚至可能还不如Node.js性能高。 脚本语言比c++、java这样的静态编译的语言开发效率要高，但是实际操作起来却发现很多不顺手的地方，很多静态语言编译期就能检查出来的低级错误，现在必须运行时才发现某个变量名写错了。 在我看来服务器其实对热更新并没有那么高的需求，而且要做成安全可靠的热更新是非常困难的，客户端影响比较小还可以考虑，服务器一旦出错就成百上千倍的放大。能把配置做成热加载的，能不关服务器的情况下开启和关闭某个系统就足够了。 脚本语言除了开发效率高就是热更新方便，然而现在看来热更新需求不大，开发效率也不如使用c#+vs高效。
d、RPC的通信方式很棒，可以让客户端和服务器以函数调用的方式来调用远程函数，而不需要考虑通信细节。 然而我非常不习惯这种方式，当需要传的数据复杂了，维护起来反而麻烦。而且传输效率上来讲肯定不如protobuf高。 如果是protobuf来维护的话，只要proto定好了，客户端和服务器共同使用，有类型修改的时候只要关注proto就可以了。 然而KBEngine中的rpc定义参数修改了需要改三处地方，并且还不是静态检查，只有运行时才能发现哪个参数定义的不一致。 另外，如果客户端和服务器都是使用python的话，应该还是比较方便的，但是客户端是c#而服务器是python，rpc反而造成了维护的不方便。
e、以实体为单位管理数据，不需要维护数据库，只要定义好实体，那么就会自动将数据保存在数据库中。这点非常棒，因为我没有什么服务器的经验，数据库的优化是我最不放心的地方。 使用KBEngine我完全不需要操心数据库的东西，只要实体定义好就可以了。 不过这里也藏着一些坑，万一它优化的不好怎么办？ 频繁的写数据会不会造成性能问题？ 它是如何加载相关性数据的？ 会不会因为某些实体关系定义的不合理，造成内存爆涨？
f、引擎本身有一些小Bug，比如被自己的账号踢了导致这个账号再也登不上去了。 经常出现消息延迟较大，但是不知道原因是什么。 引擎的代码量还是很大的，要想整理清楚所有的问题还是有一些令人头疼的地方。
服务端组成
|----------|
| client | x N
|----------|
------------------------|-----|-------------------------------
|----------| |----------| |----------|
| loginsrv | x N | basesrv | x N |basesrvmgr| x 1
|----------| |----------| |----------|
------------------------|-----|-------------------------------
|----------| |----------|
| cellsrv | x N |cellsrvmgr| x 1
|----------| |----------|
------------------------|-----|-------------------------------
|----------| |----------|
| dbmgr | x 1 |interfaces| x 1
|----------| |----------|
------------------------|-----|-------------------------------
|----------|
| mysql | x 1
|----------|
目录结构：
|- kbengine (KBE_ROOT 根目录)
|- assets (默认的游戏项目资产库，你可以添加新的资产库通过环境变量绑定)
|- res (所有资源文件)
|- spaces (通常存放游戏场景相关的资源，例如Navmesh)
|- server (通常放置服务端相关的配置文件)
|- scripts (所有的游戏逻辑，Python文件)
|- base (Base的Python逻辑)
|- cell (Cell的Python逻辑)
|- client (Client的Python逻辑)
|- bots (机器人的Python逻辑，压力测试)
|- common (逻辑公共文件夹)
|- data (游戏逻辑用到的数据资源)
|- db (dbmgr扩展脚本)
|- entity_defs (实体定义与声明)
|- interfaces (实体的接口声明)
|- server_common (服务端逻辑公共)
|- user_type (自定义用户类型目录)
|- kbe (引擎目录)
|- tools (引擎工具)
|- server (引擎服务端工具)
|- guiconsole (可视化的控制台工具)
|- install (引擎安装工具)
|- pycluster (跨平台的集群控制Python脚本工具)
|- xlsx2py (游戏数据表导出工具)
|- src (KBEngine源代码)
|- build (makefile公共脚本)
|- client (客户端插件和例子目录)
|- kbengine_dll (Windows应用程序插件源代码)
|- common (公共目录)
|- lib (各种模块源代码)
|- client_lib (客户端底层公共框架)
|- cstdkbe (KBEngine标准库)
|- db_mysql (Mysql存取实现)
|- dbmgr_lib (数据存取公共接口)
|- dependencies (依赖库)
|- entitydef (实体定义解析模块)
|- helper (一些通用的协助性模块)
|- math (数学相关)
|- navigation (2D/3D导航模块)
|- network (网络模块)
|- pyscript (脚本插件)
|- python (python源代码)
|- resmgr (资源管理器)
|- server (服务端公共模块)
|- thread (多线程模块)
|- xmlplus (xml解析库)
|- libs (编译后的*.lib, *.a文件)
|- server (服务端app源代码)
|- baseapp (baseapp源代码)
|- baseappmgr (baseappmgr源代码)
|- cellapp (cellapp源代码)
|- cellappmgr (cellappmgr源代码)
|- dbmgr (dbmgr源代码)
|- loginapp (loginapp源代码)
|- machine (machine源代码)
|- resourcemgr (resourcemgr源代码)
|- tools (服务端助手工具)
|- interfaces (支持第三方计费、第三方账号等接口)
|- bots (压力测试， 虚拟客户端, 源码)
|- guiconsole (可视化的控制台工具源码)
|- message_log (服务端log收集工具源码)
|- res (引擎资源目录)
|- key (RSA密钥)
|- scripts (Python脚本库)
|- server (服务端引擎配置)
|- log4cxx_properties (log4cxx配置)
|- doc (指南文档源代码)
|- bin (编译后的可执行文件存放目录)
|- client (编译后的客户端exe可执行文件存放目录)
|- server (编译后的服务端可执行文件存放目录)
|- logs (服务端运行日志)
|- tutorial (指南文档)
KBEngine的服务端底层框架使用c++编写，游戏逻辑层使用Python(支持热更新)。现在服务器大多数是用C++做的，python作脚本也比较多，另外一个就是lua。
kbengine底层架构被设计为多进程分布式动态负载均衡方案， 理论上只需要不断扩展硬件就能够不断增加承载上限，单台机器的承载上限取决于游戏逻辑本身的复杂度。这里对多进程分布式不是很理解，以后再解答。
kbengine主要组件
baseapp，baseappmgr，cellapp，cellappmgr，dbmgr，loginapp，machine。
工作组件：
bot，guiconsole，interfaces，logger。
后缀有mgr的组件都是相应的管理器。
数据库用的是mysql，可以考虑一下加上redis。
必要组件描述
· loginapp:
登录验证、注册、接入口。可在多台机器部署多个loginapp进程来负载。
· dbmgr:
高性能多线程的数据存取。默认使用Mysql作为数据库。
· baseapp:
客户端与服务端的交互只能通过loginapp分配的baseapp来完成。定时写entity的数据到数据库、baseapp数据相互备份、灾难恢复。可在多台机器部署多个baseapp进程来均衡负载。脚本层通常会选择在baseapp上实现如：社交系统、广播聊天、排行、游戏大厅、等等逻辑系统。
· baseappmgr:
协调所有baseapp的工作，包括baseapp负载均衡处理等。
· cellapp:
处理游戏与空间和位置有关的逻辑，如：AOI、Navigate、AI、战斗等等。可在多台机器部署多个cellapp进程来动态均衡负载。
· cellappmgr:
负责协调所有cellapp的工作，包括负载均衡处理等。
· machine:
抽象出一个服务端硬件节点(一台硬件服务器只能存在一个这样的进程)。主要用途是接收远程指令处理本机上的组件启动与关闭, 提供本机上运行组件的接入口以及收集当前机器上的一些信息， 如：CPU、内存等。 这些信息会提供给一些对此比较感兴趣的组件。
· client:
客户端我们将提供基础框架，这个框架不包括渲染部分和输入输出部分的具体实现, 我们将提供一个lib文件和一套API接口，开发者可以选择使用自己比较适合的图形渲染引擎与输入输出控制部分。Unity3D, HTML5, Cocos2d等技术我们提供了相关插件，能够快速的和服务端对接。
工具组件描述
· interfaces:
支持快速接入第三方计费、第三方账号、第三方数据， 快速与运营系统耦合。
· logger:
收集和备份各个组件的运行日志。
其它组件描述
· bots:
机器人，通常用来做压力测试。
· guiconsole:
可视化控制台，这个图形工具只能在Windows运行。
