CBE引擎概览

摘录于CBE官方文档:https://www.comblockengine.com/docs/1.0/overview/index/

架构图总览：

Switch Fabric：交换机网络，根据网络环境的不同而不同，根据用户自己的情况进行配置，不属于引擎范畴。

运作流程：

1：Client接入我们提供的SDK或API，通过API连接Loginapp。
2：Loginapp处理账号登录的验证，其中数据会从DBMgr中请求获取。（如果挂接了Interfaces， 则可以通过Interfaces将登陆和注册请求转发到第三方服务，并且接收第三方服务的处理结果让引擎执行后续流程 ）
3：如果登录验证通过，Loginapp会从BaseappMgr拿到最低负载的Baseapp，并通知Client该Baseapp的连接ip和端口。
4：Client通过API连接该Baseapp，并在Baseapp上生成Proxy代理对象与Client关联（默认的，会使用Account实体与之关联）。
5：根据业务的情况，需要创建一个Space空间内的实体时，如果目标空间不存在，则会向CellappMgr请求一个低负载的Cellapp，并在其上创建该空间。
6：在目标空间上创建Proxy对象(它是一个Entity的子类)的cell部分，使得该Proxy有了base部分以及对应空间内的cell部分。
7：通过Proxy，传递和接收Client、Baseapp上base部分、Cellapp上cell的信息，完成通讯过程。

Account实体是Client接入Baseapp时，第一个生成的实体，相当于账户实体。
其他涉及到的概念会在本文后面进行阐述。

基本概念：

Entity实体的概念

Entity实体被定义为服务端最基本的对象，类似Python的基础对象object。我们的通讯(远程访问)是通过Entity上的方法申明；我们的数据存储(数据库持久化存储)也是通过Entity上的属性进行。我们可以大体的理解为，引擎端的开发是基于Entity实体的。

实体包含哪几部分？

1、base部分：

实体在Baseapp上的对象（或称为实现），这部分叫做base部分。

2、cell部分：

实体在Cellapp上的对象（或称为实现），这部分叫做cell部分。

3、client部分：

实体在客户端上的对象（或称为实现），这部分叫做client部分。一般在客户端上进行实现，不在服务端范围内；

Proxy实体

有一个特殊的Entity实体–Proxy，它是Entity的子类，俗称代理类。它是连接客户端和服务端的通讯通道，但一个客户端只能拥有并控制一个Proxy，通过它可以把客户端的控制、交互传递给该实体的base和cell上。它只有在base上有而cell上没有。详情请查看api手册-Proxy

EntityCall的概念

《运作流程》中的通讯，都是靠EntityCall进行传递的，可以简单的理解为：封装远程交互、通讯等方法的一种对象，是脚本层与实体远程交互的常规手段。详情见《基础概念-EntityCall》。

Space的概念

Space空间是一个抽象概念，它只是存在于cellapp的内存中。由于空间是一个抽象的概念，所以具体是什么，是由用户来定义，它可以是一个场景、副本、房间等等等。

比如，在一个MMORPG中，一张地图或一个副本就是一个Space空间，只有空间内的角色、怪物、NPC可以互相交互。当跳转或传送到另一张地图时，之前的怪物、NPC就不可见了，你也无法对刚才地图里的怪物进行攻击，也无法对刚才地图中的NPC进行交谈。再比如，棋牌游戏中，一般有很多房间，每个房间是一个牌局，玩家在一个房间内进行该局游戏过程，两个房间互相之间不会有交互（聊天等等的系统除外）。

详情请查看Space空间。

必要组件的描述：

自上而下依次是：

Client

用户的客户端。我们会给客户端提供支持，Unity3D、UnrealEngine、HTML5、Cocos2d等客户端我们提供专门的SDK，使接入变得非常方便和直接，能快速和服务器端对接。其他的，我们会提供一个lib文件和一套API接口，开发者自行决定输入输出控制、图形渲染等方式。

Loginapp

作用：

登录验证、注册、Client的接入口。

可在多台机器部署多个Loginapp进程来负载，降低单台登录业务的压力。详情见《负载均衡》一文。

Baseapp

作用：

1. 通过Loginapp分配过来的Client会与Baseapp保持连接，完成客户端与服务端的交互。
2. 定时把Entity的数据保存进数据库。
3. Baseapp之间会进行互相备份，保证数据的安全。
4. 灾难恢复-当Baseapp发生问题（崩溃、断开连接等）时，会自动进行恢复。

常见用法：

Baseapp上不涉及与空间或位置相关的逻辑，所以脚本层通常会选择在baseapp上实现如：社交系统、广播聊天、排行、游戏大厅等等逻辑系统。

可在多台机器部署多个baseapp进程来负载，降低单台baseapp的连接带宽压力和计算压力。详情见《负载均衡》一文。

Cellapp

作用：

1. 处理游戏、空间或位置有关的逻辑
2. 空间数据管理，如增加几何映射（KBEngine.addSpaceGeometryMapping）、设置空间数据（KBEngine.setSpaceData）
3. 抽象概念-Space空间的创建和摧毁。

常见用法：

1. Navigate导航
2. AI逻辑
3. 战斗系统
4. View视图的控制
5. 可以增加一个副本或者房间

可在多台机器部署多个cellapp进程来负载，降低单台cellapp的压力。详情见《负载均衡》一文。

BaseappMgr

作用：

1. 协调所有Baseapp的工作，包括Baseapp负载均衡处理等。

一个KBE架构中，只会出现一个BaseappMgr。

CellappMgr

作用：

1. 负责协调所有Cellapp的工作，包括负载均衡处理等。

一个KBE架构中，只会出现一个CellappMgr。

DBMgr

数据库管理器，管理与底层数据库的通讯。可以连接Mysql、Redis等多种数据库，并且能连接多台数据库进行负载均衡。

DBMgr最多可以挂65535个数据库，这些数据库可以在不同硬件上也可以在相同的机器上，api使用时，通过Entity.writeToDB等接口和一定的算法，指定存储到某个地方，这样就可以平均分配到不同的数据库上了。同时，Mysql等数据库都有自己的分库分表机制，可以共同协助完成这项工作。

作用：

1. 对数据库的访问。
2. 高性能多线程的数据存取。

默认使用Mysql作为数据库。同时，一个KBE架构中，只会出现一个DBMgr。

Machine

抽象出来的一个服务端硬件节点(一台硬件服务器只能存在一个这样的进程)。

作用：

1. 接收远程指令，处理本机上的组件启动与关闭；
2. 通知服务器群组各个进程的存活状态；
3. 提供本机上运行组件的接入口；
4. 收集当前机器上的一些信息，如：CPU、内存、带宽等。

服务端工具组件的描述：

Interfaces

作用：

1. 快速接入第三方计费、第三方账号、第三方数据
2. 快速与运营系统耦合

多台机器下可以共同一个Interfaces。

Logger

日志服务器。

作用：

1. 收集和备份各个组件的运行日志。

---