目录

CBE引擎概览

引擎特性介绍一节已经让大家了解了CBE引擎拥有的能力,那是怎么样的架构来支撑这些特性的呢?让我们先来看一张图。

架构图总览:

1

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

运作流程:

1:Client接入我们提供的SDK或API,通过API连接Loginapp
2:Loginapp处理账号登录的验证,其中数据会从DBMgr中请求获取。(如果挂接了Interfaces, 则可以通过Interfaces将登陆和注册请求转发到第三方服务,并且接收第三方服务的处理结果让引擎执行后续流程 )
3:如果登录验证通过,Loginapp会从BaseappMgr拿到最低负载的Baseapp,并通知ClientBaseapp的连接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. 收集和备份各个组件的运行日志。

Copyright © 2018 Yolo Technologies. Publication: 2.0-025. Built: 2018-12-07.