摘录于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
作用：
- 通过Loginapp分配过来的Client会与Baseapp保持连接，完成客户端与服务端的交互。
- 定时把Entity的数据保存进数据库。
- Baseapp之间会进行互相备份，保证数据的安全。
- 灾难恢复-当Baseapp发生问题（崩溃、断开连接等）时，会自动进行恢复。
常见用法：
Baseapp上不涉及与空间或位置相关的逻辑，所以脚本层通常会选择在baseapp上实现如：社交系统、广播聊天、排行、游戏大厅等等逻辑系统。
可在多台机器部署多个baseapp进程来负载，降低单台baseapp的连接带宽压力和计算压力。详情见《负载均衡》一文。
Cellapp
作用：
- 处理游戏、空间或位置有关的逻辑
- 空间数据管理，如增加几何映射（KBEngine.addSpaceGeometryMapping）、设置空间数据（KBEngine.setSpaceData）
- 抽象概念-Space空间的创建和摧毁。
常见用法：
- Navigate导航
- AI逻辑
- 战斗系统
- View视图的控制
- 可以增加一个副本或者房间
可在多台机器部署多个cellapp进程来负载，降低单台cellapp的压力。详情见《负载均衡》一文。
BaseappMgr
作用：
- 协调所有Baseapp的工作，包括Baseapp负载均衡处理等。
一个KBE架构中，只会出现一个BaseappMgr。
CellappMgr
作用：
- 负责协调所有Cellapp的工作，包括负载均衡处理等。
一个KBE架构中，只会出现一个CellappMgr。
DBMgr
数据库管理器，管理与底层数据库的通讯。可以连接Mysql、Redis等多种数据库，并且能连接多台数据库进行负载均衡。
DBMgr最多可以挂65535个数据库，这些数据库可以在不同硬件上也可以在相同的机器上，api使用时，通过Entity.writeToDB等接口和一定的算法，指定存储到某个地方，这样就可以平均分配到不同的数据库上了。同时，Mysql等数据库都有自己的分库分表机制，可以共同协助完成这项工作。
作用：
- 对数据库的访问。
- 高性能多线程的数据存取。
默认使用Mysql作为数据库。同时，一个KBE架构中，只会出现一个DBMgr。
Machine
抽象出来的一个服务端硬件节点(一台硬件服务器只能存在一个这样的进程)。
作用：
- 接收远程指令，处理本机上的组件启动与关闭；
- 通知服务器群组各个进程的存活状态；
- 提供本机上运行组件的接入口；
- 收集当前机器上的一些信息，如：CPU、内存、带宽等。
服务端工具组件的描述：
Interfaces
作用：
- 快速接入第三方计费、第三方账号、第三方数据
- 快速与运营系统耦合
多台机器下可以共同一个Interfaces。
Logger
日志服务器。
作用：
- 收集和备份各个组件的运行日志。