一种服务控制的方法和装置与流程

1.本发明涉及计算机领域，特别是涉及一种服务控制的方法和装置。


背景技术：

2.随着设备、技术等不断的演进，目前对游戏等应用的功能丰富性、高品质等需求越来越高，以游戏为例，为了丰富游戏玩法，提高游戏品质，游戏设计者就需要设计更复杂的逻辑、更多的游戏对象，而面对复杂且存在依赖的游戏对象，其依赖关系将直接影响游戏的开发进度和可维护性，甚至于对游戏对象之间的依赖维护将直接影响服务器的性能。
3.在现有技术中，通常是在对象启动成功后进行日志输出，由另外的平台根据日志控制依赖对象的启动，而随着对象的增多，对象之间相互依赖的关系变复杂，这种方式也将变得异常的复杂，增加和删除依赖关系都需要额外的工作，扩展性、可维护性较差，且对于开发者学习成本高，影响开发效率。


技术实现要素：

4.鉴于上述问题，提出了以便提供克服上述问题或者至少部分地解决上述问题的一种服务控制的方法和装置，包括：
5.一种服务控制的方法，所述方法包括：
6.服务管理对象响应于第一事件，在第一进程上创建第一服务对象，并根据预置的依赖配置信息，在所述第一进程上启动针对第二服务对象的第二服务访问对象，其中，所述第一服务对象的启动依赖于所述第二服务对象的启动，所述第二服务访问对象用于监控所述第二服务对象的运行状态；
7.所述第二服务访问对象检测到所述第二服务对象启动成功时，向所述第一服务对象发送第一消息；
8.所述第一服务对象在接收到所述第一消息时，启动服务。
9.可选地，还包括：
10.所述服务管理对象响应于第一事件，在第二进程上创建第二服务对象，并根据所述依赖配置信息，在所述第二进程上启动针对第一服务对象的第一服务访问对象，其中，所述第一服务访问对象用于监控所述第一服务对象的运行状态；
11.所述服务管理对象响应于第二事件，向所述第二服务对象发送停止控制消息；
12.所述第一服务访问对象检测到所述第一服务对象停止成功时，向所述第二服务对象发送第二消息；
13.所述第二服务对象在接收到所述停止控制消息，且，接收到所述第二消息时，停止服务。
14.可选地，还包括：
15.所述第二服务对象在启动成功后，向应用管理对象进行注册；
16.所述应用管理对象对所述第二服务对象的注册信息进行分发；
17.所述第二服务访问对象在接收到所述第二服务对象的注册信息时，构建针对所述第二服务对象的访问映射信息；
18.所述第二服务访问对象检测到所述第二服务对象启动成功，包括：
19.所述第二服务访问对象在针对所述第二服务对象的访问映射信息构建成功的情况下，判定所述第二服务对象启动成功。
20.可选地，所述第二服务对象的注册信息包括所述第二服务对象的路由信息，针对所述第二服务对象的访问映射信息包括所述第二服务对象的服务标识和路由信息的映射关系。
21.可选地，还包括：
22.所述第一服务对象在停止成功后，向应用管理对象进行注销；
23.所述应用管理对象对所述第一服务对象的注销消息进行分发；
24.所述第一服务访问对象在接收到所述第一服务对象的注销消息时，删除针对所述第一服务对象的访问映射信息；
25.所述第一服务访问对象检测到所述第一服务对象停止成功，包括：
26.所述第一服务访问对象在针对所述第一服务对象的访问映射信息删除成功的情况下，判定所述第一服务对象停止成功。
27.可选地，所述依赖配置信息为根据多个服务对象之间的依赖关系链路生成，所述依赖配置信息包括所述多个服务对象之间的启动顺序。
28.可选地，所述第一事件包括应用开启的事件，所述第二事件包括应用关闭的事件。
29.一种服务控制的装置，所述装置包括服务管理对象、第一服务对象、第二服务对象，以及针对所述第二服务对象的第二服务访问对象，其中：
30.所述服务管理对象，用于响应于第一事件，在第一进程上创建第一服务对象，并根据预置的依赖配置信息，在所述第一进程上启动针对第二服务对象的第二服务访问对象，其中，所述第一服务对象的启动依赖于所述第二服务对象的启动，所述第二服务访问对象用于监控所述第二服务对象的运行状；
31.所述第二服务访问对象，用于检测到所述第二服务对象启动成功时，向所述第一服务对象发送第一消息；
32.所述第一服务对象，用于在接收到所述第一消息时，启动服务。
33.一种电子设备，包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上所述的服务控制的方法。
34.一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如上所述的服务控制的方法。
35.本发明实施例具有以下优点：
36.在本发明实施例中，通过服务管理对象响应于第一事件，在第一进程上创建第一服务对象，并根据预置的依赖配置信息，在第一进程上启动针对第二服务对象的第二服务访问对象，第一服务对象的启动依赖于第二服务对象的启动，第二服务访问对象可以监控所述第二服务对象的运行状态，第并在检测到第二服务对象启动成功时，向第一服务对象发送第一消息，第一服务对象在接收到第一消息时，启动服务，实现了自动控制服务对象的
启动和停止，提升了依赖关系的扩展性、可维护性，且对于开发者学习成本低、开发效率高，间接地增加了应用的安全性和稳定性。
附图说明
37.为了更清楚地说明本发明的技术方案，下面将对本发明的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
38.图1是本发明一实施例提供的一种服务架构的示意图；
39.图2a是本发明一实施例提供的一种服务控制的方法的步骤流程图；
40.图2b是本发明一实施例提供的一种依赖关系链路的有向无环图；
41.图2c是本发明一实施例提供的一种服务启动顺序的示意图；
42.图2d是本发明一实施例提供的一种服务停止顺序的示意图；
43.图3是本发明一实施例提供的一种服务启动实例的步骤流程图；
44.图4是本发明一实施例提供的一种服务停止实例的步骤流程图；
45.图5是本发明一实施例提供的另一种服务控制的方法的步骤流程图。
具体实施方式
46.为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
47.为了实现自动控制服务对象的启动和停止，根据服务对象的启动和停止之间的依赖关系，提出了新的服务架构，该服务架构将服务器(如游戏服务器)中各种服务对象进行逻辑封装，为封装后的服务对象提供服务对象的启停控制、状态维护，以及服务访问的结构，如图1，服务架构可以设置有应用管理对象(appmanager)、服务管理对象(servicemanager)、服务访问对象(serviceaccessor)，以及服务对象(service)。
48.其中，应用管理对象可以为游戏管理对象(gamemanage)，应用管理对象主要处理进程信息和服务对象信息的收集和分发，在应用启动时，其可以与服务管理对象进行连接，如图1中步骤102，并将应用的进程信息打包发向服务管理对象，同时可以从服务管理对象获取进程信息。
49.服务管理对象主要处理服务对象的创建和监控服务对象的变化，负责单个服务的启动、停止、状态维护以及容灾管理，如图1中步骤104，服务管理对象可以根据应用管理对象提供的进程信息，选择指定进程创建出对应的服务对象，如图1中步骤102。
50.其中，状态维护主要用于记录具体的服务对象的创建记录及是否已经正确启动的状态，容灾管理主要是基于状态维护进行操作，例如，有一个服务对象异常退出，服务管理对象检测到则会再选择进程重新创建服务对象。
51.服务对象主要处理具体的服务功能，提供具体的应用逻辑功能，当启动成功后会向应用管理对象注册服务对象的信息，如图1中步骤101。
52.服务访问对象主要处理服务对象的访问，维护具体的多个服务对象的路由信息，启动后会从应用管理对象获取对应服务对象的信息，如图1中步骤103，并构建访问映射，访问映射可以用于对服务对象的访问，如图1中步骤105。
53.其中，服务访问对象会有对应服务对象的就绪(on_ready，即启动)和销毁(on_destroy，即停止)的回调方法，服务对象的就绪和销毁会通知服务管理对象，服务管理对象会通知对应的服务访问对象，则服务访问对象能获知某个服务对象的状态，而在底层可以对其变化进行封装，当就绪的时候就进行就绪方法的调用，而销毁的时候就进行销毁方法的调用。
54.以下在上述服务架构的基础上，对本发明实施例进行详细说明：
55.参照图2a，示出了本发明一实施例提供的一种服务控制的方法的步骤流程图，具体可以包括如下步骤：
56.步骤201，服务管理对象响应于第一事件，在第一进程上创建第一服务对象，并根据预置的依赖配置信息，在第一进程上启动针对第二服务对象的第二服务访问对象，其中，第一服务对象的启动依赖于第二服务对象的启动，第二服务访问对象用于监控所述第二服务对象的运行状态。
57.作为一示例，第一事件包括应用开启的事件，如游戏开服。
58.在检测到第一事件时，服务管理对象可以在第一进程上创建第一服务对象，其还可以根据实际需求，在检测到第一事件时，在其他进程上创建其他的服务对象，如在第二进程上创建第二服务对象，同时，为了防止单点的性能上限，同一服务可以启动多个服务对象。
59.在一示例中，在进程启动时可以配置对应的进程标识，可以通过进程标识指定服务对象创建在哪些进程上，如可以根据进程标识将进程分类，创建某个服务对象的进程可以为指定类型的进程。
60.由于服务对象之间的启动和停止存在依赖关系，则可以预先生成服务对象之间的依赖配置信息，如依赖配置信息可以记录服务对象a的启动依赖于服务对象b、服务对象b的停止依赖于服务对象a。根据预置的依赖配置信息，可以确定第一服务对象的启动依赖于第二服务对象的启动，即需要等待第二服务对象启动后第一服务对象才能启动，相应地，其停止依赖为启动依赖的反方向，第二服务对象的停止依赖于第一服务对象的停止，即需要等待第一服务对象停止后第二服务对象才能停止。
61.而且，由于第一服务对象为在第一进程上创建的服务对象，第二服务对象为在第二进程上创建的服务对象，即第一服务对象和第二服务对象之间为跨进程依赖的服务对象，则可以在创建第一服务对象的第一进程上启动针对第二服务对象的第二服务访问对象，第二服务访问对象可以用于监控第二服务对象的运行状态，如启动情况和停止情况。
62.在本发明一实施例中，依赖配置信息为根据多个服务对象之间的依赖关系链路生成，依赖配置信息可以包括多个服务对象之间的启动顺序。
63.在具体实现中，在不同服务对象之间可能存在着多条顺序的依赖关系链路，每一条链路都是一个有向无环图(dag,directed acyclic graph)，如图2b，即为多个服务对象(service_a、service_b、service_c、service_d、service_e、service_f)之间的一条依赖关联链路的有向无环图。
64.对于每一个有向无环图都可以转化成一个多个服务对象之间的启动顺序，多条依赖关系链路最终也可以整合成一条启动顺序，如图2c，启动顺序为service_b
→
service_a和service_e
→
service_f
→
service_c
→
service_d。
65.在实际应用中，依赖配置信息可以根据多个服务对象之间的启动顺序得到，如图2c，service_d的启动就依赖于service_c和service_f，而service_f的启动又依赖于service_e和service_a，service_a的启动又依赖于service_b，，而依赖配置信息可以如下：
66.service_d：[service_c，service_f]
[0067]
service_f：[service_e，service_a]
[0068]
service_a：[service_b]
[0069]
由于依赖关系的存在，在触发启动服务时，需要确保所有的服务对象都该启动顺序进行一一启动，如图2c，service_b
→
service_a和service_e
→
service_f
→
service_c
→
service_d，而在触发停止服务时需要确保按照启动顺序的反方向进行停止工作，如图2d，service_b
←
service_a和service_e
←
service_f
←
service_c
←
service_d。
[0070]
在一示例中，对于可能存在的错综复杂的服务对象的依赖关系，可以通过深度优先搜索(dfs，depth first search)算法对多个有向无环图进行转化合并得出一条简明的启动顺序。具体的，深度优先搜索算法就是由一个起点，沿着一条依赖路径就行搜索，直到找到没有依赖的节点，如图2c中依赖关系，深度优先搜索算法的路径分别是：
[0071]
service_d
‑
>service_c
[0072]
service_d
‑
>service_f
‑
>service_e
[0073]
service_d
‑
>service_f
‑
>service_a
‑
>service_b
[0074]
而且，通过深度优先搜索算法能够很方便的判断是否存在循环依赖，因为有了依赖配置信息，所以在触发服务启动时就会触发循环依赖的检测，如果存在循环依赖会提示开启失败，如service_a的启动依赖于service_b，service_b的启动依赖于service_c，而service_c的启动又依赖于service_a，那么这样的一套依赖关系就是循环依赖了，即深度搜索的路径如下：
[0075]
service_a
‑
>service_b
‑
>service_c
‑
>service_a
[0076]
步骤202，第二服务访问对象检测到第二服务对象启动成功时，向第一服务对象发送第一消息。
[0077]
对于第二服务对象，服务管理对象可以响应于第一事件，在第二进程创建第二服务对象，并可以根据预置的依赖配置信息来控制第二服务对象的启动，第二服务对象的启动过程可以参考第一服务对象的启动过程，需要确保第二服务对象所依赖的所有的服务对象启动成功后才能进行启动。
[0078]
由于在创建第一服务对象的第一进程上同时启动了用于监控第二服务对象的第二服务访问对象，则在要启动第一服务对象的需求下，第二服务访问对象可以实时监控第一服务对象依赖的第二服务对象的启动情况。
[0079]
由于为了防止单点的性能上限，同一服务可以启动多个服务对象，即第二服务对象可以为一个或多个，则需要在所有的第二服务对象均启动成功时，才可以向第一服务对象发送用于通知所有的第二服务对象已启动成功的第一消息，具体的，服务访问对象会有
对应服务对象的就绪(on_ready，即启动)的回调方法，第一消息其可以为on_ready消息。
[0080]
在本发明一实施例中，还可以包括如下步骤：
[0081]
s11，第二服务对象在启动成功后，向应用管理对象进行注册。
[0082]
服务管理对象可以响应于第一事件，在第二进程创建第二服务对象，并可以根据预置的依赖配置信息来控制第二服务对象的启动。
[0083]
第二服务对象在启动成功后，可以向应用管理对象注册与其相关的信息，第二服务对象的注册信息可以包括第二服务对象的路由信息。
[0084]
具体的，路由信息可以为服务对象的访问地址，每个服务对象都有一个唯一的访问地址，其可以包括ip、port(端口)、id(标识)，其中ip和port能够唯一确定一个进程，而id能够访问进程中具体的服务对象。
[0085]
s12，应用管理对象对第二服务对象的注册信息进行分发。
[0086]
在第二服务对象注册成功后，应用管理对象可以对第二服务对象的注册信息进行分发，以使针对第二服务对象的第二服务访问对象获知。
[0087]
s13，第二服务访问对象在接收到第二服务对象的注册信息时，构建针对第二服务对象的访问映射信息。
[0088]
其中，访问映射信息可以包括服务标识和路由信息的映射关系。
[0089]
具体的，每个服务对象启动的时候会有一个服务标识，如服务编号(no)，服务标识是服务管理对象分配的，当服务访问对象收到注册信息的时候，注册信息中携带有服务对象的路由信息，则其可以在本地构建该服务对象的服务标识到路由信息的映射关系。
[0090]
例如，servicemanager_c需要创建2个service，则在本地的serviceaccessor_c上就会有两个对应的映射关系：
[0091]
no_1：(ip_1，port_1，id_1)
[0092]
no_2：(ip_2，port_2，id_2)
[0093]
其中，no_1和no_2是servicemanager分配的两个service的创建编号，(ip，port，id)是service的路由信息。
[0094]
相应地，第二服务访问对象检测到第二服务对象启动成功，可以包括：
[0095]
第二服务访问对象在针对第二服务对象的访问映射信息构建成功的情况下，判定第二服务对象启动成功。
[0096]
对于每个第二服务对象，第二服务访问对象可以通过判断其对应的访问映射信息是否在本地构建成功，在构建成功的情况下，可以判定该第二服务对象启动成功，在存在多个第二服务对象的情况下，则在第二服务访问对象中构建有所有的第二服务对象的访问映射信息时，判定第二服务对象启动成功，可以向第一服务对象发送第一消息。
[0097]
步骤203，第一服务对象在接收到第一消息时，启动服务。
[0098]
在接收第一消息时，表征第一服务对象依赖的所有第二服务对象都已启动成功，则第一服务对象可以启动服务。
[0099]
在启动成功后，第一服务对象也可以采用s11
‑
s13的方式向应用管理对象进行注册，使得针对第一服务对象的第一服务访问对象在接收到第一服务对象的注册信息时，构建针对第一服务对象的访问映射信息，进而可以向依赖于第一服务对象的其他服务对象能够获知第一服务对象的启动情况。
[0100]
在一示例中，在根据预置的依赖配置信息，确定某个服务对象的启动并不依赖于其他服务对象时，则可以直接进行逻辑启动。
[0101]
在本发明实施例中，通过服务管理对象响应于第一事件，在第一进程上创建第一服务对象，并根据预置的依赖配置信息，在第一进程上启动针对第二服务对象的第二服务访问对象，第一服务对象的启动依赖于第二服务对象的启动，第二服务访问对象检测第二服务对象的启动情况，并在所有的第二服务对象启动成功时，向第一服务对象发送第一消息，第一服务对象在接收到第一消息时，启动服务，实现了自动控制服务对象的启动和停止，提升了依赖关系的扩展性、可维护性，且对于开发者学习成本低、开发效率高，间接地增加了应用的安全性和稳定性。
[0102]
具体如下：
[0103]
对于提升了依赖关系的扩展性、可维护性：
[0104]
通过将服务对象之间的依赖抽象出一套通用结构，自动地控制服务对象的启动和停止，可以更加方便的新增和删除服务对象，扩展性、可维护性高。
[0105]
对于开发者学习成本低、开发效率高：
[0106]
通过更优的结构将带来更高的开发效率，由于底层已经进行封装，功能开发人员不再需要关注底层实现，只要在指定文件中增加依赖配置项即可，能快速开发出复杂依赖关系的服务，对于开发者学习成本低、开发效率高。
[0107]
对于间接地增加了应用的安全性和稳定性：
[0108]
通过将服务对象的启动和停止交由通用的模块处理，相比单独的服务对象处理，能提高服务的稳定性，且通过将服务对象之间的依赖结构化，更加方便进行错误的检查，如循环依赖，使得错误能在开发过程中就暴露出，大大的提升了游戏等应用的安全性和稳定性。
[0109]
以下结合图3对本发明实施例进行示例性说明：
[0110]
设置有gamemanager(即游戏管理对象)、servicemanager(服务管理对象)，以及三个服务对象(service_a、service_b、service_c)，三个服务对象的依赖关系为：service_a
‑
>service_b
‑
>service_c，即service_a的启动依赖于service_b的启动成功，service_b的启动依赖于service_c的启动成功，即其启动顺序应该为：service_c
‑
>service_b
‑
>service_a。
[0111]
由于依赖关系的存在，设置有多个服务访问对象(serviceaccessor_b、serviceaccessor_c)，在service_a所在的进程上会启动serviceaccessor_b用于监控service_b的启动，在service_b所在的进程上启动serviceaccessor_c用于监控service_c的启动。
[0112]
步骤301、在游戏服务器开服时，由servicemanager发起在指定类型的进程创建指定数量的service_a。
[0113]
步骤302、在游戏服务器开服时，由servicemanager发起在指定类型的进程创建指定数量的service_b。
[0114]
步骤303、在游戏服务器开服时，由servicemanager发起在指定类型的进程创建指定数量的service_c。
[0115]
步骤304、由于依赖关系的存在，service_a创建后，需要等待serviceaccessor_b
的所有service_b单位启动成功的消息(即on_ready消息)，然后才能进行service_a逻辑启动。
[0116]
步骤305、由于依赖关系的存在，service_b创建后，需要等待serviceaccessor_c的所有service_c单位启动成功的消息(即on_ready消息)，然后才能进行service_b逻辑启动。
[0117]
步骤306、由于不存在依赖，service_c单位创建后，直接进行逻辑启动。
[0118]
步骤307、service_c的逻辑启动成功后，会向gamemanager注册service_c的服务相关信息。
[0119]
步骤308、gamemanager分发service_c的注册信息，对应的serviceaccessor_c将收到对应的注册信息，并在本地构建访问映射信息。
[0120]
步骤309、gamemanager分发service_c的注册信息，对应的serviceaccessor_c将收到对应的注册信息，并在本地构建访问隐射映射信息。
[0121]
步骤310、service_b单位的逻辑启动成功后，会向gamemanager注册service_b的服务相关信息。
[0122]
步骤311、gamemanager分发service_b的注册信息，对应的serviceaccessor_b将收到对应的注册信息，并在本地构建访问隐射信息。
[0123]
步骤312、如果serviceaccessor_b上指定数量的服务都注册了，则表示service_b启动成功了，此时进行service_a的逻辑启动。
[0124]
步骤313、service_a单位的逻辑启动成功后，会向gamemanager注册service_a的服务相关信息。
[0125]
参照图5，示出了本发明一实施例提供的另一种服务控制的方法的步骤流程图，具体可以包括如下步骤：
[0126]
步骤501，服务管理对象响应于第一事件，在第一进程上创建第一服务对象，并在第二进程上创建第二服务对象。
[0127]
作为一示例，第一事件包括应用开启的事件，如游戏开服。
[0128]
在检测到第一事件时，服务管理对象可以在第一进程上创建第一服务对象，还可以在第二进程上创建第二服务对象，同时，为了防止单点的性能上限，同一服务可以启动多个服务对象。
[0129]
步骤502，服务管理对象根据预置的依赖配置信息，在第一进程上启动针对第二服务对象的第二服务访问对象，并在第二进程上启动针对第一服务对象的第一服务访问对象，其中，第一服务对象的启动依赖于第二服务对象的启动，第一服务访问对象用于监控所述第一服务对象的运行状态，第二服务访问对象用于监控所述第二服务对象的运行状态。
[0130]
由于服务对象之间的启动和停止存在依赖关系，则可以预先生成服务对象之间的依赖配置信息，如依赖配置信息可以记录服务对象a的启动依赖于服务对象b、服务对象b的停止依赖于服务对象a。根据预置的依赖配置信息，可以确定第一服务对象的启动依赖于第二服务对象的启动，即需要等待第二服务对象启动后第一服务对象才能启动，相应地，其停止依赖为启动依赖的反方向，即第二服务对象的停止依赖于第一服务对象的停止，即需要等待第一服务对象停止后第二服务对象才能停止。
[0131]
而且，由于第一服务对象为在第一进程上创建的服务对象，第二服务对象为在第
二进程上创建的服务对象，即第一服务对象和第二服务对象之间为跨进程依赖的服务对象，则可以在创建第一服务对象的第一进程上启动针对第二服务对象的第二服务访问对象，第二服务访问对象可以用于监控第二服务对象的运行状态，如启动情况和停止情况，并可以在创建第二服务对象的第二进程上启动针对第一服务对象的第一服务访问对象，第一服务访问对象可以用于监控第一服务对象的运行状态，如启动情况和停止情况。
[0132]
步骤503，第二服务访问对象检测到第二服务对象启动成功时，向第一服务对象发送第一消息。
[0133]
对于第二服务对象，服务管理对象可以响应于第一事件，在第二进程创建第二服务对象，并可以根据预置的依赖配置信息来控制第二服务对象的启动，第二服务对象的启动过程可以参考第一服务对象的启动过程，需要确保第二服务对象所依赖的所有的服务对象启动成功后才能进行启动。
[0134]
由于在创建第一服务对象的第一进程上同时启动了用于监控第二服务对象的第二服务访问对象，则在要启动第一服务对象的需求下，第二服务访问对象可以实时监控第一服务对象依赖的第二服务对象的启动情况。
[0135]
由于为了防止单点的性能上限，同一服务可以启动多个服务对象，即第二服务对象可以为一个或多个，则需要在所有的第二服务对象均启动成功时，才可以向第一服务对象发送用于通知所有的第二服务对象已启动成功的第一消息，具体的，服务访问对象会有对应服务对象的就绪(on_ready，即启动)的回调方法，第一消息其可以为on_ready消息。
[0136]
步骤504，第一服务对象在接收到第一消息时，启动服务。
[0137]
在接收第一消息时，表征第一服务对象依赖的所有第二服务对象都已启动成功，则第一服务对象可以启动服务。
[0138]
步骤505，服务管理对象响应于第二事件，向第二服务对象发送停止控制消息。
[0139]
作为一示例，第二事件可以包括应用关闭的事件，如游戏关服。
[0140]
在检测到第二事件时，服务管理对象可以触发对在先创建并开启的第二服务对象的停止，即可以向第二服务对象发送停止控制消息，触发对服务对象的停止可以为触发对服务对象进行销毁，则该停止控制消息可以为销毁控制消息，当然，在检测到第二事件时，服务管理对象还可以触发对在先创建并开启的其他服务对象的停止，如触发对第一服务对象的停止。
[0141]
步骤506，第一服务访问对象检测到第一服务对象停止成功时，向第二服务对象发送第二消息。
[0142]
由于在检测的第二事件时，也触发了对第一服务对象的停止，即也可以向第一服务对象发送停止控制消息，而根据预置的依赖配置信息，可知第一服务对象的启动依赖于第二服务对象的启动，即需要等待第二服务对象启动后第二服务对象才能启动，相应地，其停止依赖为启动依赖的反方向，第二服务对象的停止依赖于第一服务对象的停止，即需要等待第一服务对象停止后第二服务对象才能停止。
[0143]
需要说明的是，第一服务对象的停止也可以由其他事件触发，不限于与触发第二服务对象的停止的第二事件为同一事件，第一服务对象的停止过程也可以参考第二服务对象的停止过程，需要确保其依赖的所有的服务对象停止成功后才能进行停止。
[0144]
由于在创建第二服务对象的第二进程上同时也启动了用于监控第一服务对象的
第一服务访问对象，则在要停止第二服务对象的需求下，则可以通过第一服务访问对象检测第一服务对象的停止情况。
[0145]
由于为了防止单点的性能上限，同一服务可以启动多个服务对象，即第一服务对象可以为一个或多个，在所有的第一服务对象均停止成功时，则可以向第二服务对象发送用于通知所有的第一服务对象已停止成功的第二消息，具体的，服务访问对象会有对应服务对象的销毁(on_destroy，即停止)的回调方法，第二消息其可以为on_destroy消息。
[0146]
在本发明一实施例中，还可以包括：
[0147]
s21，第一服务对象在停止成功后，向应用管理对象进行注销。
[0148]
由于在创建第一服务对象时，已经向应用管理对象进行注册，第一服务对象的注册信息可以包括第一服务对象的路由信息，则第一服务对象可以在其自身停止成功后，向应用关系对象进行注销，如删除注册信息。
[0149]
具体的，路由信息可以为服务对象的访问地址，每个服务对象都有一个唯一的访问地址，其可以包括ip、port(端口)、id(标识)，其中ip和port能够唯一确定一个进程，而id能够确定进程中具体的服务对象。
[0150]
s22，应用管理对象对第一服务对象的注销消息进行分发。
[0151]
由于应用管理对象在注册时会将注册信息进行分发，则在对第一服务对象进行注销时，可以将其自身存储的注册信息进行销毁，并可以向外分发针对第一服务对象的注销消息。
[0152]
s23，第一服务访问对象在接收到第一服务对象的注销消息时，删除针对第一服务对象的访问映射信息。
[0153]
其中，访问映射信息可以包括服务标识和路由信息的映射关系。
[0154]
具体的，每个服务对象启动的时候会有一个服务标识，如服务编号(no)，服务标识是服务管理对象分配的，当服务访问对象收到注册信息的时候，会在本地构建该服务对象的服务标识到路由信息的映射关系。
[0155]
例如，servicemanager_c需要创建2个service，则在本地的serviceaccessor_c上就会有两个对应的映射关系：
[0156]
no_1：(ip_1，port_1，id_1)
[0157]
no_2：(ip_2，port_2，id_2)
[0158]
其中，no_1和no_2是servicemanager分配的两个service的创建编号，(ip，port，id)是service的路由信息。
[0159]
在接收到第一服务对象的注销消息时，第一服务访问对象可以删除在先构建的针对第一服务对象的访问映射信息。
[0160]
在本发明一实施例中，第一服务访问对象检测到第一服务对象停止成功，可以包括：
[0161]
第一服务访问对象在针对第一服务对象的访问映射信息删除成功的情况下，判定第一服务对象停止成功。
[0162]
对于每个第一服务对象，第一服务访问对象可以通过判断其对应的访问映射信息是否在本地删除成功，在删除成功的情况下，可以判定该第一服务对象启动成功，在存在多个第一服务对象的情况下，则在第一服务访问对象中删除所有的第二服务对象的访问映射
信息时，则判定第一服务对象停止成功，可以向第二服务对象发送第二消息。
[0163]
步骤507，第二服务对象在接收到停止控制消息，且，在接收到第二消息时，停止服务。
[0164]
在接收到停止控制消息后，第二服务对象可以进一步判断其要进行停止时依赖的第一服务对象的停止情况，在接收第二消息时，表征第二服务对象依赖的所有第一服务对象都已停止成功，则第二服务对象可以停止服务。
[0165]
在停止成功后，第二服务对象也可以采用s21
‑
s23的方式向应用管理对象进行注销，使得针对第二服务对象的第二服务访问对象在接收到第二服务对象的注销消息时，删除针对第二服务对象的访问映射信息，进而可以向依赖于第二服务对象的其他服务对象能够获知第二服务对象的停止情况。
[0166]
以下结合图4对本发明实施例进行示例性说明：
[0167]
设置有gamemanager(即游戏管理对象)、servicemanager(服务管理对象)，以及三个服务对象(service_a、service_b、service_c)，三个服务对象的依赖关系为：service_a
‑
>service_b
‑
>service_c，由于停止服务需要进行启动顺序的反方向进行，即service_c的停止依赖于service_b的停止成功，service_b的停止依赖于service_a的停止成功，即其停止顺序应该为：service_a
‑
>service_b
‑
>service_c。
[0168]
由于依赖关系的存在，设置有多个服务访问对象(serviceaccessor_a、serviceaccessor_b)，在service_b所在的进程上会启动serviceaccessor_a用于监控service_a的注销，同理，会在service_c所在的进程上启动serviceaccessor_b用于监控service_b的注销。
[0169]
步骤401、在游戏服务器关服时，由servicemanager发起对指定的service_c类型的所有单位进行销毁。
[0170]
步骤402、在游戏服务器关服时，由servicemanager发起对指定的service_b类型的所有单位进行销毁。
[0171]
步骤403、在游戏服务器关服时，由servicemanager发起对指定的service_a类型的所有单位进行销毁。
[0172]
步骤404、由于依赖关系的存在，service_c收到销毁控制消息(即停止控制消息)后，需要等待serviceaccessor_b的所有service_b单位销毁成功的消息(即on_destroy消息)，然后才能进行service_c的销毁。
[0173]
步骤405、由于依赖关系的存在，service_b收到销毁控制消息(即停止控制消息)后，需要等待serviceaccessor_a的所有service_a单位销毁成功的消息(即on_destroy消息)，然后才能进行service_b的销毁。
[0174]
步骤406、根据依赖关系，确定service_a收到销毁控制消息(即停止控制消息)后，会直接进行销毁流程。
[0175]
步骤407、service_a销毁成功后，会向gamemanager注销对应的service_a的服务相关信息。
[0176]
步骤408、gamemanager分发service_a的注销消息，对应的serviceaccessor_a将收到对应的注销消息，并在本地删除访问映射信息。
[0177]
步骤409、如果serviceaccessor_a上指定数量的服务都注销了，则表示service_a
注销成功了，此时进行service_b的注销。
[0178]
步骤410、service_b单位注销成功后，会向gamemanager注销对应的service_b的服务相关信息。
[0179]
步骤411、gamemanager分发service_b的注销消息，对应的serviceaccessor_b将收到对应的注销消息，并在本地删除访问隐射信息。
[0180]
步骤412、如果serviceaccessor_b上指定数量的服务都注销了，则表示service_b注销成功了，此时进行service_c的注销。
[0181]
步骤413、service_c单位注销成功后，会向gamemanager注销对应的service_c的服务相关信息。
[0182]
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
[0183]
本发明一实施例还提供的一种服务控制的装置。
[0184]
该装置可以包括服务管理对象、第一服务对象、第二服务对象，以及针对第二服务对象的第二服务访问对象，其中：
[0185]
服务管理对象，用于响应于第一事件，在第一进程上创建第一服务对象，并根据预置的依赖配置信息，在第一进程上启动针对第二服务对象的第二服务访问对象，其中，第一服务对象的启动依赖于第二服务对象的启动，第二服务访问对象用于监控所述第二服务对象的运行状态；
[0186]
第二服务访问对象，用于检测到第二服务对象启动成功时，向第一服务对象发送第一消息；
[0187]
第一服务对象，用于在接收到第一消息时，启动服务。
[0188]
在本发明一实施例中，服务管理对象，还用于响应于第一事件，在第二进程上创建第二服务对象，并根据依赖配置信息，在第二进程上启动针对第一服务对象的第一服务访问对象，其中，第一服务访问对象用于监控所述第一服务对象的运行状态；
[0189]
服务管理对象，还用于响应于第二事件，向第二服务对象发送停止控制消息；
[0190]
该装置还可以包括针对第一服务对象的第一服务访问对象，第一服务访问对象，用于检测到第一服务对象停止成功时，向第二服务对象发送第二消息；
[0191]
第二服务对象，还用于在接收到停止控制消息，且，接收到第二消息时，停止服务。
[0192]
在本发明一实施例中，第二服务对象，还用于在启动成功后，向应用管理对象进行注册；
[0193]
该装置还可以包括应用管理对象，应用管理对象，用于对第二服务对象的注册信息进行分发；
[0194]
第二服务访问对象，还用于在接收到第二服务对象的注册信息时，构建针对第二服务对象的访问映射信息；
[0195]
第二服务访问对象在检测第二服务对象到启动成功时，具体用于：
[0196]
在针对第二服务对象的访问映射信息构建成功的情况下，判定第二服务对象启动
成功。
[0197]
在本发明一实施例中，第二服务对象的注册信息包括第二服务对象的路由信息，针对第二服务对象的访问映射信息包括第二服务对象的服务标识和路由信息的映射关系。
[0198]
在本发明一实施例中，第一服务对象，还用于在停止成功后，向应用管理对象进行注销；
[0199]
应用管理对象，还用于对第一服务对象的注销消息进行分发；
[0200]
第一服务访问对象，还用于在接收到第一服务对象的注销消息时，删除针对第一服务对象的访问映射信息；
[0201]
第一服务访问对象在检测第一服务对象到停止成功时，具体用于：
[0202]
在针对第一服务对象的访问映射信息删除成功的情况下，判定第一服务对象停止成功。
[0203]
在本发明一实施例中，依赖配置信息为根据多个服务对象之间的依赖关系链路生成，依赖配置信息包括多个服务对象之间的启动顺序。
[0204]
在本发明一实施例中，第一事件包括应用开启的事件，第二事件包括应用关闭的事件。
[0205]
在本发明实施例中，通过服务管理对象响应于第一事件，在第一进程上创建第一服务对象，并根据预置的依赖配置信息，在第一进程上启动针对第二服务对象的第二服务访问对象，第一服务对象的启动依赖于第二服务对象的启动，第二服务访问对象可以监控第二服务对象的运行状，并在第二服务对象启动成功时，向第一服务对象发送第一消息，第一服务对象在接收到第一消息时，启动服务，实现了自动控制服务对象的启动和停止，提升了依赖关系的扩展性、可维护性，且对于开发者学习成本低、开发效率高，间接地增加了应用的安全性和稳定性。
[0206]
本发明一实施例还提供了一种电子设备，可以包括处理器、存储器及存储在存储器上并能够在处理器上运行的计算机程序，计算机程序被处理器执行时实现如上服务控制的方法。
[0207]
本发明一实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现如上服务控制的方法。
[0208]
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0209]
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
[0210]
本领域内的技术人员应明白，本发明实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
[0211]
本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些
计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0212]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0213]
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0214]
尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
[0215]
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
[0216]
以上对所提供的一种服务控制的方法和装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。