业务处理方法、装置、计算机设备和业务处理系统与流程

1.本技术涉及计算机技术领域，特别是涉及一种业务处理方法、装置、计算机设备、计算机可读存储介质、计算机程序产品和业务处理系统。


背景技术：

2.随着计算机技术的发展，网络游戏得到了飞速的发展，出现了竞速游戏、射击游戏、策略游戏和动作角色扮演游戏等。在大型多人在线角色扮演游戏(massive multi player online role-playinggame，mmorpg)中，为了增加玩法的新鲜感，通常会开辟新的玩法和场景以供用户选择，跨服玩法应运而生。
3.传统技术中，为将客户端标识对应的业务信息跨服迁移至新业务场景，需要在原有的游戏服务器架构的基础上，新增处理跨服业务的跨服专用服务器，以及跨服专用服务器与原业务服务器的专用数据通路，在跨服专用服务器上建立新业务场景，并通过专用数据通路将客户端标识对应的业务信息跨服迁移至新业务场景。一方面，新增跨服专用服务器和专用数据通路会导致成本的增加，另一方面，由于新增的跨服专用服务器在无跨服玩法的情况下，处于闲置状态，使用率低，不利于节约资源和能源。因此，传统技术中的业务处理方法，具有成本高的缺点。


技术实现要素：

4.基于此，有必要针对上述技术问题，提供一种能够降低成本的业务处理方法、装置、计算机设备、计算机可读存储介质、计算机程序产品和业务处理系统。
5.第一方面，本技术提供了一种业务处理方法。所述方法包括：
6.接收第一业务服务器发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识；
7.确定与所述目标场景标识关联的第二业务服务器；
8.若所述第二业务服务器与所述第一业务服务器不同，向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接，所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；
9.通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。
10.在其中一个实施例中，所述方法还包括：
11.若所述第二业务服务器与所述第一业务服务器一致，则向所述第一中介层反馈第三链接关系修改指令，所述第三链接关系修改指令用于指示所述第一中介层将所述客户端
标识对应的第三链接关系，由所述第一中介层与所述第一业务服务器的第一场景标识关联的第一业务组件链接，修改为所述第一中介层与所述目标场景标识关联的第三业务组件链接。
12.在其中一个实施例中，与所述目标场景标识对应的业务组件存在两个以上；所述接收第一业务服务器发送的业务处理请求之前，还包括：
13.在达到所述目标场景标识关联的目标场景的预设开放条件时，根据所述客户端标识对应的属性特征信息，向所述客户端标识对应的客户端展示场景开放界面；所述场景开放界面关联的第二业务组件，与所述属性特征信息匹配。
14.在其中一个实施例中，业务服务器的负载权重的确定方式，包括：
15.获取业务服务器关联的各业务场景的业务场景信息，根据各业务场景信息分别确定各业务场景的场景负载权重；
16.根据各业务场景的场景负载权重，确定所述业务服务器的负载权重。
17.在其中一个实施例中，所述业务场景信息包括同时存在的npc(non-player character，非玩家角色)数量上限和参与人数上限，根据业务场景信息确定业务场景的场景负载权重，包括：
18.将所述同时存在的npc数量上限乘以npc关联系数，获得npc负载，并将所述参与人数上限乘以人数关联系数，获得人数负载；
19.根据所述npc负载和所述人数负载，确定所述业务场景信息关联的业务场景的场景负载权重。
20.在其中一个实施例中，所述业务处理请求携带时间戳；通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景，还包括：
21.根据所述业务处理请求携带的时间戳的先后顺序，向所述第一业务服务器发送跳出请求，并向所述第二业务服务器发送跳入请求。
22.在其中一个实施例中，所述方法还包括：按照先入先出的顺序，将所述业务处理请求加入业务请求队列；通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景，还包括：
23.从所述业务请求队列中依次取出所述业务处理请求；
24.根据所述业务处理请求，按照先入先出的顺序，在跳入请求队列中添加与所述业务处理请求对应的跳入请求；按照先入先出的顺序，在跳出请求队列中添加与所述业务处理请求对应的跳出请求；
25.从所述跳出请求队列中取出所述跳出请求，并向所述第一业务服务器发送所述跳出请求，从所述跳入请求队列中取出所述跳入请求，并向所述第二业务服务器发送所述跳入请求。
26.第二方面，本技术还提供了一种对象处理装置。所述装置包括：
27.业务处理请求接收模块，用于接收第一业务服务器发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识；
28.业务服务器确定模块，用于确定与所述目标场景标识关联的第二业务服务器；
29.链接关系修改模块，用于若所述业务服务器确定模块确定的第二业务服务器与所
述第一业务服务器不同，向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接，所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；
30.业务信息迁移模块，用于通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。
31.第三方面，本技术还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
32.接收第一业务服务器发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识；
33.确定与所述目标场景标识关联的第二业务服务器；
34.若所述第二业务服务器与所述第一业务服务器不同，向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接，所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；
35.通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。
36.第四方面，本技术还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
37.接收第一业务服务器发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识；
38.确定与所述目标场景标识关联的第二业务服务器；
39.若所述第二业务服务器与所述第一业务服务器不同，向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接，所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；
40.通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。
41.第五方面，本技术还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：
42.接收第一业务服务器发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识；
43.确定与所述目标场景标识关联的第二业务服务器；
44.若所述第二业务服务器与所述第一业务服务器不同，向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接，所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；
45.通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。
46.第六方面，本技术还提供了一种业务处理系统。所述系统包括：全局服务器以及业务服务器，所述全局服务器与所述业务服务器通信连接，所述业务服务器至少包括第一业务服务器和第二业务服务器；
47.所述第一业务服务器，接收客户端发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识，若所述第一业务服务器接收所述业务处理请求的业务场景的第一场景标识与所述目标场景标识不同，将所述业务处理请求转发至所述全局服务器；
48.所述全局服务器，接收所述业务处理请求，确定与所述目标场景标识关联的第二业务服务器；向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接，所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；
49.所述全局服务器，还通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。
50.在一个实施例中，所述业务服务器还包括中心控制节点，所述中心控制节点链接所述业务服务器的通信层；所述中心控制节点用于接收所述业务处理请求，还用于判断所述第一场景标识与所述目标场景标识是否关联同一业务服务器，并在所述第一场景标识与所述目标场景标识关联不同业务服务器时，将所述业务处理请求转发至所述全局服务器。
51.上述业务处理方法、装置、计算机设备、存储介质、计算机程序产品和业务处理系统，在需要对客户端标识对应的业务信息进行跨服迁移时，向与客户端链接的第一业务服务器的第一接入层反馈第一链接关系修改指令，指示第一接入层将客户端标识对应的第一链接关系，由第一接入层与第一业务服务器的第一中介层链接，修改为第一接入层与第二业务服务器的第二中介层链接；并向第二业务服务器的第二中介层反馈第二链接关系修改指令，指示第二中介层添加与客户端标识对应的第二链接关系，第二链接关系为第二中介层与第二业务服务器的目标场景标识关联的第二业务组件链接。上述链接关系修改后，客
户端可以依次通过第一接入层和第二中介层，链接目标场景标识关联的第二业务组件，相当于无需新增额外的数据通路，即可更改客户端链接的业务组件，使得客户端可以接入区别于第一业务服务器的第二业务服务器上的目标场景。进一步的，通过第一业务服务器和第二业务服务器之间的数据通路，将客户端标识对应的业务信息迁移至目标场景，相当于无需新增额外的服务器即可实现业务信息的跨服迁移。上述技术方案相互配合，可以在实现业务信息的跨服迁移的同时，提高机器利用率，有利于降低成本。
附图说明
52.图1为一个实施例中业务处理方法的应用环境图；
53.图2为一个实施例中业务处理系统的结构框图；
54.图3为另一个实施例中业务处理系统的结构框图；
55.图4为一个实施例中业务处理方法的流程示意图；
56.图5为一个实施例中创建新业务场景的流程示意图；
57.图6为一个实施例中业务服务器的负载权重的确定方式的流程示意图；
58.图7为一个实施例中根据业务场景信息确定业务场景的场景负载权重的流程示意图；
59.图8为另一个实施例中业务服务器的负载权重的确定方式的流程示意图；
60.图9为一个实施例中通过第一业务服务器和第二业务服务器之间的数据通路，将客户端标识对应的业务信息迁移至目标场景的流程示意图；
61.图10为一个实施例中的权重上报机制示意图；
62.图11为一个实施例中的双向跳服队列示意图；
63.图12为一个实施例中跳服请求处理时序示意图；
64.图13为一个实施例中业务处理装置的结构框图；
65.图14为一个实施例中计算机设备的内部结构图。
具体实施方式
66.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
67.本技术实施例提供的业务处理方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与业务处理系统104进行通信。数据存储系统可以存储业务处理系统104需要处理的数据，该数据存储系统可以集成在业务处理系统104中的服务器上，也可以放在云上或其他服务器上。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。业务处理系统104由多个服务器组成的服务器集群来实现。
68.在一个实施例中，提供了一种业务处理系统。如图2所示，该系统包括全局服务器210以及业务服务器220，全局服务器210与业务服务器220通信连接，该业务服务器220至少包括第一业务服务器221和第二业务服务器222。
69.在执行业务处理方法的过程中：第一业务服务器221接收客户端发送的业务处理请求，该业务处理请求携带客户端标识和目标场景标识，若第一业务服务器221接收业务处理请求的业务场景的第一场景标识，与该目标场景标识不同，将该业务处理请求转发至全局服务器210；全局服务器210接收业务处理请求，确定与目标场景标识关联的第二业务服务器222；若第二业务服务器222与第一业务服务器221不同，向第一业务服务器221的第一接入层反馈第一链接关系修改指令，向第二业务服务器222的第二中介层反馈第二链接关系修改指令；该第一链接关系修改指令用于指示第一接入层将客户端标识对应的第一链接关系，由第一接入层与第一业务服务器221的第一中介层链接，修改为第一接入层与第二中介层链接；该第二链接关系修改指令用于指示第二中介层添加与客户端标识对应的第二链接关系，该第二链接关系为第二中介层与第二业务服务器222的目标场景标识关联的第二业务组件链接；全局服务器210还通过第一业务服务器221和第二业务服务器222之间的数据通路，将客户端标识对应的业务信息迁移至目标场景。
70.其中，终端通过客户端链接业务服务器220上的业务场景，全局服务器210负责关联多个业务服务器220的业务的处理，例如，给所有客户端的玩家发放福利和发放通知。第一业务服务器221为客户端当前链接的业务场景所在的业务服务器，第二业务服务器222为客户端请求加入的目标场景所在的业务服务器。第一业务服务器221和第二业务服务器222之间的数据通路，是指第一业务服务器221经由全局服务器210，链接第二业务服务器222的数据通路。
71.具体的，各业务服务器220上均承载有业务场景，各业务场景可以通过对应的玩法核心逻辑进程实现。客户端所在的终端通过与客户端链接的业务场景，与业务场景所在的业务服务器进行通信。客户端向当前链接的业务场景发送的业务处理请求，包括在第一业务服务器221的业务逻辑范围内的请求，例如符合当前链接的业务场景的游戏玩法逻辑的处理请求，针对这一类型的业务处理请求，由第一业务服务器221直接响应该业务处理请求。客户端向当前链接的业务场景所在的第一业务服务器221发送的业务处理请求，还包括超出该第一业务服务器221的业务逻辑范围的请求，例如，请求加入第二业务服务器222中的目标场景的跳服请求，针对这一类型的业务处理请求，由第一业务服务器221将该业务处理请求转发至全局服务器210，再由全局服务器210进行请求的处理。
72.上述业务处理系统，在需要对客户端标识对应的业务信息进行跨服迁移时，向与客户端链接的第一接入层反馈第一链接关系修改指令，指示第一接入层将客户端标识对应的第一链接关系，由第一接入层与第一业务服务器的第一中介层链接，修改为第一接入层与第二业务服务器的第二中介层链接；并向第二业务服务器的第二中介层反馈第二链接关系修改指令，指示第二中介层添加与客户端标识对应的第二链接关系，第二链接关系为第二中介层与第二业务服务器的目标场景标识关联的第二业务组件链接。上述链接关系修改后，客户端可以依次通过第一接入层和第二中介层，链接目标场景标识关联的第二业务组件，相当于无需新增额外的数据通路，即可更改客户端链接的业务组件，使得客户端可以接入区别于第一业务服务器的第二业务服务器上的目标场景。进一步的，通过第一业务服务器和第二业务服务器之间的数据通路，将客户端标识对应的业务信息迁移至目标场景，相当于无需新增额外的服务器即可实现业务信息的跨服迁移。上述技术方案相互配合，可以在实现业务信息的跨服迁移的同时，提高机器利用率，有利于降低成本。
73.在一个实施例中，如图3所示，第一业务服务器221包括依次链接的第一接入层311、第一中介层312、第一业务层313和第一通信层314；第二业务服务器222包括依次链接的第二接入层321、第二中介层322、第二业务层323和第二通信层324；该第一业务层313和该第二业务层323用于承载业务场景；第一通信层314和第二通信层324链接全局服务器210。第一接入层311还用于链接客户端和第二中介层322；第二接入层321还用于链接客户端和第一中介层312。
74.其中，接入层负载接入鉴权；中介层负载消息转发和解耦；业务层负载实现玩法核心逻辑；通信层负责消息转发，具体可以通过无状态转发进程实现。第一接入层311和第二接入层322分别包括至少一个接入组件，客户端具体通过其中一个接入组件与业务服务器链接。如图3中，客户端可以通过第一接入层311中的第二接入组件与业务服务器链接。进一步的，第一业务层313和第二业务层323分别包括至少一个业务组件，各业务组件上承载有对应的业务场景，且各业务场景的游戏玩法逻辑可以相同，也可以不相同。如图3中，第一业务层313可以包括第一业务组件和第三业务组件，第二业务层323可以包括第二业务组件和第四业务组件。
75.具体的，接入层中的各接入组件，可以链接所有业务服务器的中介层，如图3中，第一接入层311中的各接入组件，构成接入组件集群，接入组件集群中每一个接入组件均可以链接第一业务服务器221的第一中介层312，以及第二业务服务器222的第二中介层322。业务服务器的业务层的各业务组件，均可以链接该业务服务器的中介层和通信层。客户端经由其链接的接入层和中介层，发送业务处理请求至中介层链接的业务组件中承载的业务场景，各业务场景仅处理对应业务逻辑范围内的请求，并通过通信层转发业务逻辑范围外的请求。
76.以第一业务服务器221的第一业务层313包括两个业务组件，且客户端链接第一业务组件中的第一业务场景的情况为例。第一业务场景转发至第一通信层314的业务处理请求，包括与第一业务场景的第一场景标识不相同的目标场景标识。如图3所示，目标场景标识对应的目标场景所在的业务组件，存在以下三种情况：第一种，目标场景与第一业务场景关联的业务组件相同，均为第一业务组件；第二种，目标场景与第一业务场景关联的业务服务器相同，但业务组件不同，例如目标场景所在的业务组件为第一业务服务器221的第三业务组件；第三种，目标场景与第一业务场景关联的业务服务器不相同，例如目标场景所在的业务组件为第二业务服务器222的第二业务组件。
77.基于此，通信层的业务处理请求的转发对象并不唯一。
78.在一个实施例中，通信层的业务处理请求的转发对象包括全局服务器210。如图3所示，具体由通信层将业务处理请求转发至全局服务器210的全局通信层214，再由全局服务器210中的业务层从全局通信层214获取该业务处理请求，并在获取业务处理请求后响应该业务处理请求。
79.针对第一种情况，全局服务器210通过第一通信层314将客户端标识对应的业务信息由第一业务组件的第一业务场景，迁移至第一业务组件中的目标场景。
80.针对第二种情况，一方面，全局服务器210向第一中介层312反馈第三链接关系修改指令，该第三链接关系修改指令用于指示第一中介层312将客户端标识对应的第三链接关系，由第一中介层312与第一业务服务器221的第一场景标识关联的第一业务组件链接，
修改为第一中介层312与目标场景标识关联的第三业务组件链接；另一方面，全局服务器210通过第一通信层314将客户端标识对应的业务信息由第一业务组件中的第一业务场景，迁移至第三业务组件中的目标场景。
81.针对第三种情况，一方面，全局服务器210向第一接入层311反馈第一链接关系修改指令，向第二中介层322反馈第二链接关系修改指令；该第一链接关系修改指令用于指示第一接入层311将客户端标识对应的第一链接关系，由第一接入层311与第一中介层312链接，修改为第一接入层311与第二中介层322链接；该第二链接关系修改指令用于指示第二中介层322添加与客户端标识对应的第二链接关系，该第二链接关系为第二中介层322与目标场景关联的第二业务组件链接；另一方面，全局服务器210还通过第一业务组件和第二业务组件之间的数据通路，将客户端标识对应的业务信息由第一业务组件中的第一业务场景，迁移至第二业务组件中的目标场景。如图3所示，第一业务组件和第二业务组件之间的数据通路，依次为第一业务组件、第一通信层314、全局通信层214、第二通信层324和第二业务组件。
82.在一个实施例中，业务服务器还可以包括中心控制节点，该中心控制节点链接该业务服务器的通信层。中心控制节点用于接收业务处理请求，还用于判断第一场景标识与目标场景标识是否关联同一业务服务器，并在第一场景标识与目标场景标识关联不同业务服务器时，将业务处理请求转发至全局服务器。
83.可以理解，在该实施例的情形下，通信层的业务处理请求的转发对象包括中心控制节点。其中，中心控制节点掌握同一业务服务器中业务层的各业务组件的状态信息，包括各业务组件承载的业务场景，以及各业务场景的玩法逻辑。如图3中，第一业务服务器221包括链接第一通信层314的第一中心控制节点315，则第一中心控制节点315掌握第一业务层313中第一业务组件和第三业务组件中承载的各业务场景的场景标识，以及各场景标识对应的玩法逻辑。
84.具体的，第一通信层314先将业务处理请求转发至第一中心控制节点315，第一中心控制节点315可以基于第一业务服务器221中各业务组件承载的业务场景，将各业务场景对应的业务场景标识与目标场景标识进行比对，判断业务处理请求中携带的目标场景标识关联的业务服务器，是否为接收该业务处理请求的业务场景的第一场景标识关联的第一业务服务器221。若第一业务服务器221中，存在与目标场景标识一致的业务场景标识，则目标场景标识关联的业务服务器为第一业务服务器211，对应上文中的第一种和第二种情况；若第一业务服务器221中，不存在与目标场景标识一致的业务场景标识，则目标场景标识关联的业务服务器不是第一业务服务器211，对应上文中的第三种情况。针对第三种情况，由第一中心控制节点315将业务处理请求退回至第一通信层314，再由第一通信层314将该业务处理请求转发至全局服务器210，关于全局服务器210响应业务处理请求的具体过程参见上文，此处不再赘述。
85.针对第一种情况，第一中心控制节点315可以通过第一通信层314将客户端标识对应的业务信息由第一业务组件中的第一业务场景，迁移至第一业务组件中的目标场景。
86.针对第二种情况，一方面，第一中心控制节点315向第一中介层312反馈第三链接关系修改指令，该第三链接关系修改指令用于指示第一中介层312将客户端标识对应的第三链接关系，由第一中介层312与第一业务服务器221的第一场景标识关联的第一业务组件
链接，修改为第一中介层312与目标场景标识关联的第三业务组件链接；另一方面，第一中心控制节点315通过第一通信层314将客户端标识对应的业务信息由第一业务组件中的第一业务场景，迁移至第三业务组件中的目标场景。
87.需要说明的是，为便于客户端与其他客户端进行交互，如图3所示，业务服务器还可以包括对话进程控制组件，如图3中的第一对话进程控制组件316和第二对话进程控制组件326。对应的，业务服务器的接入层还可以包括对话接入组件，如图3中的第一对话接入组件317和第二对话接入组件327，该对话接入组件用于链接客户端与对话进程控制组件。如图3中，第一对话接入组件317用于链接客户端与第一对话进程控制组件316。
88.进一步的，业务服务器中各组件之间的通信方式，可以是基于tcp(transmission control protocol，传输控制协议)的通信，也可以是基于共享内存的通信，如图3中基于tbus的通信。
89.上述实施例中，通过对业务服务系统的架构进行改进，可以实现硬件和进程的复用，即在不新增机器的前提下实现前端接入层跳服，和后端业务信息的跨服迁移，有利于降低成本。并且在各业务服务器中配置通信层负责同一业务服务器中不同业务组件之间的消息转发，在全局服务器中配置全局通信层214负责各业务服务器之间的消息转发，形成星形的网络拓扑结构，可以降低进程之间的连接耦合，有利于提高工作效率。
90.在一个实施例中，如图4所示，提供了一种业务处理方法，该方法也可以应用于全局服务器，也可以通过全局服务器与业务服务器的交互实现。以该方法应用于图2中的全局服务器210为例进行说明，包括以下步骤：
91.步骤s402，接收第一业务服务器发送的业务处理请求。
92.其中，业务处理请求携带客户端标识和目标场景标识。客户端标识是指可唯一标识发起业务处理请求的客户端的信息。该客户端标识具体可以是客户端所在终端的设备号，或者客户端关联的玩家标识。目标场景标识是指可唯一标识客户端申请加入的目标场景的信息。该目标场景标识，具体可以是目标场景的场景标识。
93.具体的，全局服务器接收业务处理请求的前提条件，可以是第一业务服务器中接收该业务处理请求的业务场景的第一场景标识与目标场景标识不同；也可以是第一场景标识与目标场景标识不同，并且目标场景标识关联的第二业务服务器与第一场景标识关联的第一业务服务器不同。关于上述情况下，业务处理请求在第一业务服务器中的消息转发通路参见上文业务处理系统实施例，此处不再赘述。为便于理解，下面均以全局服务器接收业务处理请求的前提条件，为第一场景标识与目标场景标识不同的情况为例进行说明。
94.进一步的，全局服务器接收业务处理请求的具体方式，可以是主动获取，也可以是被动接收。
95.步骤s404，确定与目标场景标识关联的第二业务服务器。
96.具体的，全局服务器掌握所有与之连接的业务服务器的状态信息，包括各业务服务器承载的业务场景。基于此，全局服务器可以根据业务处理请求中携带的目标场景标识，以及预存的业务场景与业务服务器的对应关系，确定与目标场景标识关联的第二业务服务器。
97.步骤s406，若第二业务服务器与第一业务服务器不同，向第一业务服务器的第一接入层反馈第一链接关系修改指令，向第二业务服务器的第二中介层反馈第二链接关系修
改指令。
98.关于第一接入层和第二中介层的具体限定参见业务处理系统实施例中的描述，此处不再赘述。其中，第一链接关系修改指令用于指示第一接入层将客户端标识对应的第一链接关系，由第一接入层与第一业务服务器的第一中介层链接，修改为第一接入层与第二中介层链接；第二链接关系修改指令用于指示第二中介层添加与客户端标识对应的第二链接关系，该第二链接关系为第二中介层与第二业务服务器的目标场景标识关联的第二业务组件链接。
99.可以理解，在添加第二链接关系的同时，全局服务器还可以向第一中介层发送链接删除指令，以指示第一中介层断开与第一业务组件的链接关系。具体的，第一接入层和第二中介层分别响应对应的链接关系修改指令后，客户端可以依次通过第一接入层和第二中介层链接目标场景标识关联的第二业务组件。
100.步骤s408，通过第一业务服务器和第二业务服务器之间的数据通路，将客户端标识对应的业务信息迁移至目标场景。
101.其中，客户端标识对应的业务信息可以包括玩家的状态信息，包括角色、级别、物品等等。如前文所述，第一业务服务器和第二业务服务器分别链接全局服务器。因此，第一业务服务器和第二业务服务器之间的数据通路，是指第一业务服务器经由全局服务器，链接第二业务服务器的数据通路。将客户端标识对应的业务信息迁移至目标场景的数据通路，依次为第一业务服务器中第一业务场景所在的业务组件、第一业务服务器的通信层、全局服务器的通信层、第二业务服务器的通信层、第二业务服务器中目标场景所在的业务组件。
102.具体的，全局服务器可以基于其自身与第一业务服务器和第二业务服务器的链接，通过镜像迁移或其他数据迁移方式，将客户端标识对应的业务信息迁移至目标场景。
103.上述业务处理方法，在需要对客户端标识对应的业务信息进行跨服迁移时，基于业务处理系统的架构，向与客户端链接的第一业务服务器的第一接入层反馈第一链接关系修改指令，并向第二业务服务器的第二中介层反馈第二链接关系修改指令，使得客户端可以依次通过第一接入层和第二中介层，链接目标场景标识关联的第二业务组件，相当于无需新增额外的数据通路，即可更改客户端链接的业务组件，使得客户端可以接入区别于第一业务服务器的第二业务服务器上的目标场景。进一步的，通过第一业务服务器和第二业务服务器之间的数据通路，将客户端标识对应的业务信息迁移至目标场景，相当于无需新增额外的服务器即可实现业务信息的跨服迁移。上述技术方案相互配合，可以在实现业务信息的跨服迁移的同时，提高机器利用率，有利于降低成本。
104.可以理解，目标场景标识关联的第二业务服务器并不必然与第一业务服务器不同。在一个实施例中，业务处理方法还包括：若第二业务服务器与第一业务服务器一致，则向第一中介层反馈第三链接关系修改指令。
105.其中，第三链接关系修改指令用于指示第一中介层将客户端标识对应的第三链接关系，由第一中介层与第一业务服务器的第一场景标识关联的第一业务组件链接，修改为第一中介层与目标场景标识关联的第二业务组件链接。在该实施例的情形下，通过第一业务服务器的第一业务组件和第二业务组件之间的数据通路，将客户端标识对应的业务信息迁移至目标场景。具体的，客户端标识对应的业务信息通过第一业务服务器的第一通信层，
由第一业务组件中的第一业务场景，迁移至第二业务组件中的目标场景。
106.上述实施例中，在第二业务服务器与第一业务服务器一致的情况下，向第一中介层反馈第三链接关系修改指令，使得客户端可以通过第一中介层链接至目标场景，可以实现同一服务器之间不同业务场景的数据迁移，有利于扩展业务处理方法的应用场景。
107.需要说明的是，在目标场景为大规模跨服场景的前提下，一方面，考虑到若将所有玩家集中于同一业务组件，对业务组件的性能要求太高，另一方面，由于不同玩家的属性特征信息不同，若将所有玩家集中于同一业务组件，不利于提高用户体验度。以对战游戏为例，对战双方的实力悬殊过大，必然导致对战的激烈程度降低，引起用户体验度的下降。基于此，在一个实施例中，目标场景标识对应多个目标场景副本，各目标场景副本至少关联两个业务组件。其中，各目标场景副本的游戏玩法逻辑相同。在此前提下，与目标场景标识对应的业务组件存在两个以上，对应的，与目标场景标识关联的业务服务器可能也存在两个以上。进一步的，在该情形下，确定与目标场景标识关联的第二业务服务器的具体方式并不唯一。
108.在一个实施例中，确定与目标场景标识关联的第二业务服务器，包括：根据客户端标识对应的属性特征信息，从与目标场景标识对应的各业务组件中，选择与该属性特征信息匹配的业务组件作为第二业务组件，并将第二业务组件所在的业务服务器确定为第二业务服务器。
109.其中，属性特征信息可以包括客户端标识对应的玩家的级别属性和家族属性。客户端标识对应的玩家是游戏中的虚拟角色。玩家的级别属性用以区分不同玩家的战力和操作频率，具体可以通过玩家的经验值确定，例如可以根据玩家的级别属性，将玩家分为菜鸟组和专家组，其中，专家组的战力和操作频率高于菜鸟组。玩家的家族属性用于区分不同玩家所在的群组。例如，国战类游戏中，家族属性具体可以是指玩家所在的阵营或者联盟。
110.具体的，可以在不同业务组件上建立多个目标场景副本，每个目标场景副本对应不同的属性特征信息。全局服务器可以在接收到业务处理请求后，基于客户端标识对应的属性特征信息，以及预存的属性特征信息与业务组件的对应关系，从各备选业务组件中，选择与该属性特征信息匹配的业务组件作为第二业务组件，并将第二业务组件所在的业务服务器确定为第二业务服务器。全局服务器也可以在接收到业务处理请求后，根据业务处理请求中携带的客户端标识对应的属性特征信息，从各备选业务组件包括的备选目标场景副本中，筛选出与该属性特征信息匹配的目标场景副本，再将承载该目标场景副本的业务组件作为第二业务组件，并将第二业务组件所在的业务服务器确定为第二业务服务器。
111.在另一个实施例中，接收第一业务服务器发送的业务处理请求之前，还包括：在达到目标场景标识关联的目标场景的预设开放条件时，根据客户端标识对应的属性特征信息，向客户端标识对应的客户端展示场景开放界面。
112.其中，目标场景的预设开放条件，可以是指时间达到预设时间或者游戏剧情达到预设剧情。具体的，由客户端响应于场景开放界面触发的业务处理操作，向第一业务服务器发送业务处理请求。由于场景开放界面与客户端标识对应的属性特征信息匹配，场景开放界面关联的第二业务组件，也与客户端标识对应的属性特征信息匹配。因此，客户端响应于该场景开放界面发送的业务处理请求所携带的目标场景标识，可以用于标识客户端标识对应的属性特征信息匹配的目标场景副本。基于此，场景开放界面直接关联与客户端标识对
应的属性特征信息匹配的第二业务组件，根据业务处理请求，即可关联唯一的第二业务组件，进而确定第二业务服务器。进一步的，场景开放界面可以通过弹窗或浮层的方式展现。场景开放界面触发业务处理操作的方式，可以是在满足预设条件之后自动触发，也可以是在用户点击之后触发。
113.上述实施例中，在与目标场景标识对应的业务组件存在两个以上的情况下，将与客户端标识对应的属性特征信息匹配的业务组件作为第二业务组件，可以均衡各业务组件的负载压力，提升用户体验度，有利于提高业务处理方法的科学性。
114.如前文所述，为增加玩法的新鲜感，通常会开辟新的玩法和场景以供用户选择，这就需要创建新业务场景。在一个实施例中，如图5所示，业务处理方法还包括步骤s502至步骤s506。
115.步骤s502，获取各业务服务器的负载权重。
116.其中，各业务服务器的负载权重的获取方式，可以是主动获取，也可以是被动接收。具体的，可以根据业务服务器的标识信息，依次获取各业务服务器的负载权重。
117.进一步的，可以由各业务服务器的中心控制节点确定对应业务服务器的负载权重，再分别将该负载权重通过通信层发送至全局服务器；也可以根据各业务服务器的服务器标识，确定主业务服务器，由各业务服务器的中心控制节点确定对应业务服务器的负载权重后，统一发送至主业务服务器的中心控制节点，再由主业务服务器的中心控制节点将各业务服务器的负载权重通过通信层发送至全局服务器；还可以由全局服务器直接确定各业务服务器的负载权重。
118.进一步的，各业务服务器的负载权重的确定方式并不唯一。
119.在一个实施例中，如图6所示，业务服务器的负载权重的确定方式，包括步骤s602至步骤s604。
120.步骤s602，获取业务服务器关联的各业务场景的业务场景信息，根据各业务场景信息分别确定各业务场景的场景负载权重。
121.其中，业务场景信息由业务场景的玩法逻辑确定，该业务场景信息可以包括同时存在的npc数量上限和参与人数上限等信息。场景负载权重是指该业务场景运行过程中，对业务场景所在的业务服务器的资源消耗大小。业务场景的场景负载权重越大，对应的业务服务器的资源消耗越大。具体的，可以对不同的业务场景信息分配不同的权重关联系数，并基于权重关联系数及其对应的业务场景信息，确定该业务场景的场景负载权重。
122.在一个实施例中，业务场景信息包括同时存在的npc数量上限和参与人数上限。在该实施例的情形下，如图7所示，根据业务场景信息确定业务场景的场景负载权重，包括步骤s702和步骤s704。
123.步骤s702，将同时存在的npc数量上限乘以npc关联系数，获得npc负载，并将参与人数上限乘以人数关联系数，获得人数负载。
124.其中，npc是游戏中区别于玩家角色的其他角色的通称。参与人数上限是指游戏场景可以同时容纳的玩家数量的上限值。npc关联系数可以基于npc对场景负载的影响程度确定，对应的，人数负载系数可以基于参与的玩家数量对场景负载的影响程度确定。游戏场景中可以设定多个不同作用的npc，例如不攻击型npc、主动攻击型npc、群体攻击型npc等等，npc的种类越多、行动逻辑越复杂，对场景负载的影响程度相对越大，npc关联系数相对越
大。例如，在一个实施例中，npc关联系数为10，人数关联系数为1。进一步的，在确定npc关联系数和人数关联系数时，还可以综合考虑业务场景是否支持玩家对战，若是，在npc关联系数不变的基础上增大人数关联系数。例如，在一个实施例中，npc关联系数为10，若支持玩家对战，人数关联系数为2，若不支持玩家对战，人数关联系数为1。
125.可以理解，同时存在的npc数量上限越大，参与人数上限越大，游戏的玩法激烈度越大，场景负载越大。具体的，将同时存在的npc数量上限乘以npc关联系数，可以获得npc负载；将参与人数上限乘以人数关联系数，可以获得人数负载。
126.步骤s704，根据npc负载与人数负载，确定业务场景信息关联的业务场景的场景负载权重。
127.具体的，可以叠加npc负载与人数负载，得到业务场景信息关联的业务场景的场景负载权重，也可以将npc负载与人数负载的平均值或较大值，作为业务场景信息关联的业务场景的场景负载权重。
128.步骤s604，根据各业务场景的场景负载权重，确定业务服务器的负载权重。
129.具体的，将同一业务服务器中各业务场景的场景负载权重叠加，即可确定业务服务器的负载权重。
130.在另一个实施例中，业务服务器包括至少两个业务组件，如图8所示，业务服务器的负载权重的确定方式，包括步骤s802至步骤s806。
131.步骤s802，获取业务服务器包括的各业务组件关联的各业务场景的业务场景信息，根据各业务场景信息分别确定各业务场景的场景负载权重。
132.其中，同一业务组件关联多个业务场景。具体的，根据各业务场景的业务场景信息，可以分别确定各业务场景的场景负载权重。关于场景负载权重的具体限定参见上文，此处不再赘述。
133.步骤s804，根据各业务组件关联的业务场景的场景负载权重，确定各业务组件的业务负载权重。
134.其中，业务组件的业务负载权重，是指该业务组件关联的业务场景运行过程中，对该业务组件所在的业务服务器的资源消耗大小。具体的，叠加同一业务组件上各业务场景的场景负载权重，即可确定该业务组件的业务负载权重。
135.步骤s806，根据各业务组件的业务负载权重，确定业务服务器的负载权重。
136.如上文所述，业务服务器包括多个业务组件，这些业务组件用于执行游戏玩法的核心逻辑，是业务服务器中资源消耗较大的组成部分。基于此，业务服务器上业务组件的业务负载权重，可以表征业务服务器的负载权重。具体的，叠加业务服务器上各业务组件的业务负载权重，可以获得业务服务器的负载权重。
137.步骤s504，将负载权重最小的业务服务器确定为目标服务器。
138.具体的，根据各业务服务器的负载权重，可以将负载权重最小的业务服务器确定为目标服务器。
139.步骤s506，在目标服务器上创建新业务场景。
140.具体的，可以基于新业务场景的源数据，建立数据引用，并基于该数据引用在目标服务器上创建新业务场景；也可以将新业务场景的源数据，建立数据副本，发送至目标服务器，用于在目标服务器上创建新业务场景。
141.可以理解，在需要创建新业务场景的多个场景副本的情况下，在完成一个场景副本的创建之后，再重新获取各业务服务器的负载权重，并根据各负载权重，将当前负载权重最小的业务服务器确定为新的目标服务器，并在新的目标服务器上创建下一个场景副本，依此类推，直至所有的场景副本创建完成。
142.上述实施例中，将负载权重最小的业务服务器确定为目标服务器，并在目标服务器上创建新业务场景，可以平衡各业务服务器的负载，有利于提高业务处理系统的性能稳定性。
143.可以理解，目标服务器上具体承载新业务场景的组件为业务组件，而目标服务器上业务组件的数量并不唯一，因此，在目标服务器上创建新业务场景的过程中，需要在各业务组件中，选择承载新业务场景的目标业务组件。
144.在一个实施例中，目标服务器仅包括一个业务组件，在该实施例的情形下，步骤s506包括：在目标服务器的业务组件上创建新业务场景。其中，目标服务器的业务组件为该目标服务器唯一关联的业务组件，因此，只需在该业务组件上创建新业务场景，即可实现目标服务器上新业务场景的创建。
145.在另一个实施例中，目标服务器包括至少两个业务组件，在该实施例的情形下，步骤s506，包括：获取目标服务器的各业务组件的业务负载权重，确定目标服务器中业务负载权重最小的业务组件为目标业务组件，并在目标业务组件上创建新业务场景。
146.关于业务负载权重的具体限定参见上文，此处不再赘述。具体可以根据目标服务器的各业务组件的标识信息，对各业务组件进行排序依次获取各业务组件的业务负载权重。
147.具体的，目标业务组件为目标服务器中业务负载权重最小的业务组件。根据目标服务器中各业务组件的业务负载权重，可以将业务负载权重最小的业务组件确定为目标业务组件，并在目标业务组件上创建新业务场景。
148.进一步的，可以由目标服务器的中心控制节点确定目标服务器中各业务组件的业务负载权重，再将该业务负载权重通过通信层发送至全局服务器；也可以由全局服务器确定目标服务器的各业务组件的业务负载权重。同样的，可以由目标服务器的中心控制节点确定目标业务组件，也可以由全局服务器确定目标业务组件。
149.可以理解，在需要创建新业务场景的多个场景副本的情况下，在完成一个场景副本的创建之后，再重新获取各业务服务器的负载权重，并根据各负载权重，将当前负载权重最小的业务服务器确定为新的目标服务器，并根据新的目标服务器中各业务组件的业务负载权重，将业务负载权重最小的业务组件确定为目标业务组件，并在该目标业务组件上创建下一个场景副本，依此类推，直至所有的场景副本创建完成。
150.上述实施例中，在负载权重最小的业务服务器中，业务负载权重最小的业务组件上创建新业务场景，可以在确保业务服务器之间负载均衡的前提下，平衡同一业务服务器中各业务组件的负载，有利于进一步提高业务处理系统的性能稳定性。
151.在一个实施例中，步骤s408的通过第一业务服务器和第二业务服务器之间的数据通路，将客户端标识对应的业务信息迁移至目标场景，包括：向第一业务服务器发送跳出请求，并向第二业务服务器发送跳入请求。
152.其中，跳出请求用于指示第一业务服务器将客户端标识对应的业务信息迁出第一
场景标识关联的第一业务组件；跳入请求用于指示第二业务服务器将客户端标识对应的业务信息迁入目标场景标识关联的第二业务组件。
153.进一步的，跳出请求还可以用于指示第一业务服务器的第一接入层，将客户端标识对应的第一链接关系，由第一接入层与第一业务服务器的第一中介层链接，修改为第一接入层与第二中介层链接；跳入请求还用于指示第二业务服务器的第二中介层添加与客户端标识对应的第二链接关系，该第二链接关系为第二中介层与第二业务服务器的目标场景标识关联的第二业务组件链接。也即，跳出请求和跳入请求的处理过程，均可以包括链接关系更改和业务信息迁移两个部分。
154.在大规模跨服场景开启的瞬间，可能产生批量的跳服业务处理请求，存在大量玩家同时请求离开原业务场景，并加入新的目标场景。此时，全局服务器将会接收到大量的跳服业务处理请求，同一业务服务器将接收到大量的跳出请求和/或跳入请求，受自身性能的制约，若服务器同时处理所有的请求，可能会导致服务器的中央处理器出现性能毛刺，产生卡顿，影响用户体验度。基于此，引入请求队列，按照先入先出的顺序处理请求，以削峰填谷降低性能瓶颈的影响。
155.在一个实施例中，业务处理请求携带时间戳；步骤s408还包括：根据业务处理请求携带的时间戳的先后顺序，向第一业务服务器发送跳出请求，并向第二业务服务器发送跳入请求。
156.可以理解，由于业务处理请求携带时间戳，根据业务处理请求携带的时间戳的先后顺序发送的跳出请求和跳入请求相当于也携带了时间戳，该时间戳对应为业务服务器接收到跳出/跳入请求的时刻。具体的，第一业务服务器可以根据接收到的跳出请求的时间先后顺序，将跳出请求加入第一业务服务器的跳出请求队列；第二业务服务器可以根据接收到的跳入请求的时间先后顺序，将跳入请求加入第二业务服务器的跳入请求队列。再按照先入先出的顺序，依次在请求队列中取出并响应对应的跳出请求和跳入请求，实现客户端标识对应的业务信息的迁移，以降低大量跳服业务处理请求对业务服务器的影响。需要说明的是，在存在多个目标场景副本的情况下，同一业务服务器可能会同时接收到跳出请求和跳入请求，此时，可以在该服务器中分别建立跳入请求队列和跳出请求队列，针对每个请求队列，分别按照先入先出的顺序，依次取出并响应该请求队列中的请求。
157.在一个实施例中，业务处理方法还包括：按照先入先出的顺序，将业务处理请求加入业务请求队列。在该实施例的情形下，如图9所示，步骤s408还包括：
158.步骤s902，从业务请求队列中依次取出业务处理请求。
159.具体的，全局服务器接收到大量业务处理请求时，可以先按照先入先出的顺序，将业务处理请求加入业务请求队列，再从业务请求队列中依次取出业务处理请求。
160.步骤s904，根据业务处理请求，按照先入先出的顺序，在跳入请求队列中添加与业务处理请求对应的跳入请求；按照先入先出的顺序，在跳出请求队列中添加与业务处理请求对应的跳出请求。
161.具体的，全局服务器可以根据业务处理请求，按照先入先出的顺序，分别在跳入请求队列中添加与业务处理请求对应的跳入请求，以及在跳出请求队列中添加与业务处理请求对应的跳出请求。
162.步骤s906，从跳出请求队列中依次取出跳出请求，并发送至第一业务服务器；从跳
入请求队列中依次取出跳入请求，并发送至第二业务服务器。
163.具体的，全局服务器可以按照先入先出的顺序，从跳出请求队列中取出跳出请求，并向第一业务服务器发送跳出请求，从跳入请求队列中取出跳入请求，并向第二业务服务器发送跳入请求。可以理解，同一业务处理请求关联的跳出请求和跳入请求，在跳出请求队列和跳入请求队列中的顺序是相同的，因此，按照先入先出的顺序，成对取出的跳出请求和跳入请求必然也与发送业务处理请求的客户端标识关联。
164.进一步的，跳出请求和跳入请求的发送和响应频率，可以根据服务器同一时间接收的请求数量确定。同一时间的请求数量越多，服务器的负载越重，可以将响应频率调低以避免卡顿。
165.上述实施例中，通过引入请求队列，按照先入先出的顺序处理请求，可以降低批量跳服请求对服务器性能的影响，有利于提高业务处理系统的稳定性。
166.如上文所述，通过业务处理系统架构方案的设计，可以在不增加机器和进程的情况下实现了跨服业务。在该方案的基础上，还需要通过负载平衡机制和性能平滑机制来保证业务处理系统的稳定性。为便于理解，下面结合图10至图12，对本技术涉及的负载平衡机制和性能平滑机制进行详细说明。
167.下面对负载平衡机制进行说明。在大规模跨服场景的玩法逻辑前提下，一方面，考虑到若将所有玩家集中于同一业务组件，对业务组件的性能要求太高，另一方面，由于不同玩家的属性特征信息不同，若将所有玩家集中于同一业务组件，不利于提高用户体验度。以对战游戏为例，对战双方的实力悬殊过大，必然导致对战的激烈程度降低，引起用户体验度的下降。因此，在建立新的跨服场景时，建立多个跨服场景副本，且将各跨服场景副本分散于各业务服务区的业务组件上。
168.具体的，每个跨服副本创建的时候，各业务服务器都会根据业务组件上原业务场景的同时存在的npc数量上限度、参与人数上限以及是否支持玩家对战，计算各业务场景的场景负载权重，同时存在的npc数量上限越大，参数人数上限越多，玩法逻辑对应的激烈程度越大，场景负载权重越大。再将同一业务组件上关联的业务场景的场景负载权重叠加，得到各业务组件的业务负载权重，最后将同一业务服务器的各业务组件的业务负载权重叠加，得到该业务服务器的负载权重。上述负载权重由业务服务器自己管理，如图10所示，负载权重具体可以由业务服务器的中心控制节点管理，每个中心控制节点都可以得到本服的负载权重以及该服每个业务组件的业务负载权重；
169.进一步的，如图10所示，可以根据各业务服务器的服务器标识，确定主业务服务器，由各业务服务器的中心控制节点确定对应业务服务器的负载权重后，统一上报至主业务服务器的中心控制节点。这样，通过两层权重上报机制，使得主业务服务器掌握所有业务服务器的负载情况，可以将需要创建的跨服场景副本创建在负载最小的业务服务器中负载最小的业务组件上，在确保业务服务器之间负载均衡的前提下，平衡同一业务服务器中各业务组件的负载，有利于提高业务处理系统的性能稳定性。
170.可以理解，在完成一个跨服场景副本的创建之后，再重新获取各业务服务器的负载权重，并根据各负载权重，将当前负载权重最小的业务服务器确定为新的目标服务器，并根据新的目标服务器中各业务组件的业务负载权重，将业务负载权重最小的业务组件确定为目标业务组件，并在该目标业务组件上创建下一个跨服场景副本，依此类推，直至所有的
跨服场景副本创建完成。
171.下面对性能平滑机制进行说明。在大规模跨服场景开启的瞬间，可能产生批量的跳服业务处理请求，存在大量玩家同时请求离开原业务场景，并加入新的目标场景。此时，全局服务器将会接收到大量的跳服业务处理请求，同一业务服务器将接收到大量的跳出请求和/或跳入请求，受自身性能的制约，若服务器同时处理所有的请求，可能会导致服务器的中央处理器出现性能毛刺，产生卡顿，影响用户体验度。基于此，引入请求队列，按照先入先出的顺序处理请求，以削峰填谷降低性能瓶颈的影响。
172.在一个实施例中，如图11所示，引入双向跳服队列，削峰填谷。具体的，业务处理请求携带时间戳，全局服务器210根据业务处理请求携带的时间戳的先后顺序，向第一业务服务器221发送跳出请求，并向第二业务服务器222发送跳入请求。
173.可以理解，由于业务处理请求携带时间戳，根据业务处理请求携带的时间戳的先后顺序发送的跳出请求和跳入请求也相当于也携带了时间戳，该时间戳对应为业务服务器接收到请求的时刻。具体的，第一业务服务器221可以根据接收到的跳出请求的时间先后顺序，将跳出请求加入第一业务服务器的跳出请求队列；第二业务服务器222可以根据接收到的跳入请求的时间先后顺序，将跳入请求加入第二业务服务器的跳入请求队列。需要说明的是，在存在多个跨服场景副本的情况下，同一业务服务器可能会同时接收到跳出请求和跳入请求，此时，如图11所示，可以在该服务器中分别建立跳入请求队列和跳出请求队列。
174.业务服务器按照先入先出的顺序，依次在请求队列中取出并响应对应的跳出请求和跳入请求，实现客户端标识对应的业务信息的迁移，以降低大量跳服业务处理请求对业务服务器的影响。具体的，如图12所示，客户端经由第一业务组件，通过全局服务器210，向第二业务组件发送跳入请求，第二业务组件根据当前跳入请求队列，通过全局服务器210，向第一业务组件反馈跳入序号，并将该跳入请求添加至跳入请求队列。按照先入先出的顺序，在可以响应该跳入请求时，第一业务组件通过全局服务器210通知第一接入层跳服，前端跳服成功后再通过镜像玩家实现后端数据的跨服迁移。进副本成功后，再删除第一业务组件上的客户端标识对应的玩家对象和会话，并更新客户端标识的在线服务器。
175.进一步的，跳出请求和跳入请求的发送和响应频率，可以根据服务器同一时间接收的请求数量确定。同一时间的请求数量越多，服务器的负载越重，可以将响应频率调低以避免卡顿。
176.采用上述业务处理系统和方法，可以实现跨服业务复用现有业务服务器的机器和进程，使现有资源得到了更充分的利用，既节省了机器运营成本又减少了运维工作量，有利于降低成本，提高业务处理方法的科学性。
177.应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
178.基于同样的发明构思，本技术实施例还提供了一种用于实现上述所涉及的业务处
理方法的业务处理装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个业务处理装置实施例中的具体限定可以参见上文中对于业务处理方法的限定，在此不再赘述。
179.在一个实施例中，如图13所示，提供了一种业务处理装置1300，包括：业务处理请求接收模块1302、业务服务器确定模块1304、链接关系修改模块1306和业务信息迁移模块1308，其中：
180.业务处理请求接收模块1302，用于接收第一业务服务器发送的业务处理请求，该业务处理请求携带客户端标识和目标场景标识；
181.业务服务器确定模块1304，用于确定与该目标场景标识关联的第二业务服务器；
182.链接关系修改模块1306，用于若业务服务器确定模块1304确定的第二业务服务器与第一业务服务器不同，向第一业务服务器的第一接入层反馈第一链接关系修改指令，向第二业务服务器的第二中介层反馈第二链接关系修改指令；该第一链接关系修改指令用于指示第一接入层将客户端标识对应的第一链接关系，由第一接入层与第一业务服务器的第一中介层链接，修改为第一接入层与第二中介层链接，该第二链接关系修改指令用于指示第二中介层添加与客户端标识对应的第二链接关系，该第二链接关系为第二中介层与第二业务服务器的目标场景标识关联的第二业务组件链接；
183.业务信息迁移模块1308，用于通过第一业务服务器和第二业务服务器之间的数据通路，将客户端标识对应的业务信息迁移至目标场景。
184.在一个实施例中，链接关系修改模块1306还用于：若第二业务服务器与第一业务服务器一致，向第一中介层反馈第三链接关系修改指令；该第三链接关系修改指令用于指示第一中介层将客户端标识对应的第三链接关系，由第一中介层与第一业务服务器的第一场景标识关联的第一业务组件链接，修改为第一中介层与目标场景标识关联的第二业务组件链接。
185.在一个实施例中，与目标场景标识对应的业务组件存在两个以上，业务服务器确定模块1304具体用于：根据客户端标识对应的属性特征信息，从与目标场景标识对应的各业务组件中，选择与该属性特征信息匹配的业务组件作为第二业务组件，并将第二业务组件所在的业务服务器确定为第二业务服务器。
186.在一个实施例中，与目标场景标识对应的业务组件存在两个以上；业务处理装置还包括：场景开放界面展示模块，用于在达到目标场景标识关联的目标场景的预设开放条件时，根据客户端标识对应的属性特征信息，向客户端标识对应的客户端展示场景开放界面；该场景开放界面关联的第二业务组件，与该属性特征信息匹配。
187.在一个实施例中，属性特征信息包括级别属性和家族属性。
188.在一个实施例中，业务处理装置还包括：服务器负载权重获取模块，用于获取各业务服务器的负载权重；目标服务器确定模块，用于将负载权重最小的业务服务器确定为目标服务器；新业务场景创建模块，用于在目标服务器上创建新业务场景。
189.在一个实施例中，服务器负载权重获取模块包括：场景负载权重获取单元，用于获取业务服务器关联的各业务场景的业务场景信息，根据各业务场景信息分别确定各业务场景的场景负载权重；服务器负载权重获取单元，用于根据各业务场景的场景负载权重，确定业务服务器的负载权重。
190.在一个实施例中，业务服务器包括至少两个业务组件，在该实施例的情形下，场景负载权重获取单元，具体用于获取业务服务器包括的各业务组件关联的各业务场景的业务场景信息，根据各业务场景信息分别确定各业务场景的场景负载权重。服务器负载权重获取模块还包括：业务负载权重确定单元，用于根据各业务组件关联的业务场景的场景负载权重，确定各业务组件的业务负载权重。服务器负载权重获取单元，具体用于根据各业务组件的业务负载权重，确定业务服务器的负载权重。
191.在一个实施例中，业务场景信息包括同时存在的npc数量上限和参与人数上限，场景负载权重获取单元具体用于：将同时存在的npc数量上限乘以npc关联系数，获得npc负载，并将参与人数上限乘以人数关联系数，获得人数负载；根据npc负载和人数负载，确定业务场景信息关联的业务场景的场景负载权重。
192.在一个实施例中，业务服务器包括至少两个业务组件，新业务场景创建模块具体用于：获取目标服务器的各业务组件的业务负载权重，确定目标服务器中业务负载权重最小的业务组件为目标业务组件，并在目标业务组件上创建新业务场景。
193.在一个实施例中，业务处理请求携带时间戳；业务信息迁移模块1308具体用于：根据业务处理请求携带的时间戳的先后顺序，向第一业务服务器发送跳出请求，并向第二业务服务器发送跳入请求。
194.在一个实施例中，业务处理方法还包括：按照先入先出的顺序，将业务处理请求加入业务请求队列。在该实施例的情形下，业务信息迁移模块包括：业务处理请取出单元，用于从业务请求队列中依次取出业务处理请求；跳入跳出请求添加单元，用于根据业务处理请求，按照先入先出的顺序，在跳入请求队列中添加与业务处理请求对应的跳入请求；按照先入先出的顺序，在跳出请求队列中添加与业务处理请求对应的跳出请求；跳入跳出请求发送单元，用于从跳出请求队列中依次取出跳出请求，并发送至第一业务服务器，从跳入请求队列中依次取出跳入请求，并发送至第二业务服务器。
195.上述业务处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
196.在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图14所示。该计算机设备包括处理器、存储器、输入/输出接口(input/output，简称i/o)和通信接口。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口通过输入/输出接口连接到系统总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储各业务场景的玩法逻辑以及关联该计算机设备的客户端标识对应的业务信息数据。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种业务处理方法。
197.本领域技术人员可以理解，图14中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
198.在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。
199.在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
200.在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
201.需要说明的是，本技术所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。
202.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read-only memory，rom)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(reram)、磁变存储器(magnetoresistive random access memory，mram)、铁电存储器(ferroelectric random access memory，fram)、相变存储器(phase change memory，pcm)、石墨烯存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器等。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。本技术所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本技术所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。
203.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
204.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术的保护范围应以所附权利要求为准。

技术特征：
1.一种业务处理方法，其特征在于，所述方法包括：接收第一业务服务器发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识；确定与所述目标场景标识关联的第二业务服务器；若所述第二业务服务器与所述第一业务服务器不同，向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接；所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。2.根据权利要求1所述的方法，其特征在于，与所述目标场景标识对应的业务组件存在两个以上；所述确定与所述目标场景标识关联的第二业务服务器，包括：根据所述客户端标识对应的属性特征信息，从与所述目标场景标识对应的各所述业务组件中，选择与所述属性特征信息匹配的业务组件作为所述第二业务组件，并将所述第二业务组件所在的业务服务器确定为所述第二业务服务器。3.根据权利要求1所述的方法，其特征在于，所述方法还包括：获取各业务服务器的负载权重；将负载权重最小的业务服务器确定为目标服务器；在所述目标服务器上创建新业务场景。4.根据权利要求3所述的方法，其特征在于，所述业务服务器包括至少两个业务组件，所述业务服务器的负载权重的确定方式，包括：获取所述业务服务器包括的各业务组件关联的各业务场景的业务场景信息，根据各业务场景信息分别确定各业务场景的场景负载权重；根据各业务组件关联的业务场景的场景负载权重，确定各所述业务组件的业务负载权重；根据各所述业务组件的业务负载权重，确定所述业务服务器的负载权重。5.根据权利要求4所述的方法，其特征在于，所述在所述目标服务器上创建新业务场景，包括：获取所述目标服务器的各业务组件的业务负载权重，确定目标服务器中业务负载权重最小的业务组件为目标业务组件，并在所述目标业务组件上创建新业务场景。6.根据权利要求1至5任意一项所述的方法，其特征在于，通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景，包括：向所述第一业务服务器发送跳出请求，并向所述第二业务服务器发送跳入请求；所述跳出请求用于指示所述第一业务服务器将所述客户端标识对应的业务信息迁出所述第一场景标识关联的第一业务组件；所述跳入请求用于指示所述第二业务服务器将所述客户端
标识对应的业务信息迁入所述目标场景标识关联的目标业务组件。7.一种对象处理装置，其特征在于，所述装置包括：业务处理请求接收模块，用于接收第一业务服务器发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识；业务服务器确定模块，用于确定与所述目标场景标识关联的第二业务服务器；链接关系修改模块，用于若所述业务服务器确定模块确定的第二业务服务器与所述第一业务服务器不同，向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接，所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；业务信息迁移模块，用于通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。8.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的方法的步骤。9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。10.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。11.一种业务处理系统，其特征在于，所述系统包括：全局服务器以及业务服务器，所述全局服务器与所述业务服务器通信连接，所述业务服务器至少包括第一业务服务器和第二业务服务器；所述第一业务服务器，接收客户端发送的业务处理请求，所述业务处理请求携带客户端标识和目标场景标识，若所述第一业务服务器接收所述业务处理请求的业务场景的第一场景标识与所述目标场景标识不同，将所述业务处理请求转发至所述全局服务器；所述全局服务器，接收所述业务处理请求，确定与所述目标场景标识关联的第二业务服务器；若第二业务服务器与所述第一业务服务器不同，向所述第一业务服务器的第一接入层反馈第一链接关系修改指令，向所述第二业务服务器的第二中介层反馈第二链接关系修改指令；所述第一链接关系修改指令用于指示所述第一接入层将所述客户端标识对应的第一链接关系，由所述第一接入层与所述第一业务服务器的第一中介层链接，修改为所述第一接入层与所述第二中介层链接，所述第二链接关系修改指令用于指示所述第二中介层添加与所述客户端标识对应的第二链接关系，所述第二链接关系为所述第二中介层与所述第二业务服务器的所述目标场景标识关联的第二业务组件链接；所述全局服务器，还通过所述第一业务服务器和所述第二业务服务器之间的数据通路，将所述客户端标识对应的业务信息迁移至所述目标场景。12.根据权利要求11所述的业务处理系统，其特征在于，所述第一业务服务器包括依次链接的第一接入层、第一中介层、第一业务层和第一通信层；所述第二业务服务器包括依次
链接的第二接入层、第二中介层、第二业务层和第二通信层；所述第一业务层和所述第二业务层用于承载业务场景；所述第一通信层和所述第二通信层链接所述全局服务器；所述第一接入层还用于链接客户端和所述第二中介层；所述第二接入层还用于链接客户端和所述第一中介层。

技术总结
本申请涉及一种业务处理方法、装置、计算机设备、计算机可读存储介质、计算机程序产品和业务处理系统。所述方法包括：接收第一业务服务器发送的业务处理请求，该业务处理请求携带客户端标识和目标场景标识；确定与目标场景标识关联的第二业务服务器；若第二业务服务器与第一业务服务器不同，向第一业务服务器的第一接入层反馈第一链接关系修改指令，向第二业务服务器的第二中介层反馈第二链接关系修改指令；通过第一业务服务器和第二业务服务器之间的数据通路，将客户端标识对应的业务信息迁移至目标场景。采用上述方法，可以在实现业务信息的跨服迁移的同时，提高机器利用率，有利于降低成本。于降低成本。于降低成本。


技术研发人员：伍贤俊 熊松
受保护的技术使用者：腾讯科技（深圳）有限公司
技术研发日：2022.02.17
技术公布日：2023/8/31