CN110532106A - 进程间的通讯方法、装置、设备和存储介质 - Google Patents

Abstract

本申请提供一种进程间的通讯方法、装置、设备和存储介质，该方案中的进程间的通讯装置设置有多个服务节点以及多个内核模块，每个服务节点对应的内核模块对相应的服务请求进行解析和管理，然后分别于对应的核心服务模块进行交互完成服务，采用了去中心化的设计，避免将系统功能限定在单个服务内，将内核模块改造成单独的服务对应的模块，降低了中心化导致的功能负担，提高进程间通信的效率。

Description

进程间的通讯方法、装置、设备和存储介质

技术领域

本申请涉及智能设备技术，尤其涉及一种进程间的通讯方法、装置、设备和存储介质。

背景技术

进程间通讯(英文：inter process communication，简称：IPC)是操作系统重要的基础组件，承担了进程间相互通讯的桥梁；在终端设备的安卓(英文：Android)操作系统中，binder作为最重要、最普及的IPC机制，集诸多IPC方案的优点于一身，如可以传递文件描述符、RPC、数据只拷贝一次等。

目前的操作系统中，IPC的种类很多，如共享内存、管道、Socket、Android Binder等等，每种方式都有自己的优点和缺点。图1为Android Binder机制架构示意图，如图1所示，在Android Binder(也称为安卓进程间通讯)机制中，所有客户端(英文：client)必须通过中心化服务管理进程(英文：service manager，也称为binder守护进程)请求服务，binder将client、server、service manager链接起来，集服务查询、提交、结果转发等多个角色于一身；在client发起对某个服务的请求后，binder驱动向server端的服务请求队列插入请求，请求执行完毕返回给client执行结果。Android的IPC机制中，内核模块binder是进程间通信的桥梁和核心。

然而，Android Binder机制本身中心化的设计思想也易造成整机系统进程通讯的瓶颈，负担较重且设计复杂。

发明内容

本申请实施例提供一种进程间的通讯方法、装置、设备和存储介质，用于解决现有Android Binder机制本身中心化的设计思想也易造成整机系统进程通讯的瓶颈，负担较重且设计复杂的问题。

本申请第一方面提供一种进程间的通讯装置，包括：

至少一个客户端，服务管理模块，至少一个服务节点，至少一个核心服务模块，至少一个内核模块；内核模块，服务节点与核心服务模块之间一一对应；

所述服务管理模块用于管理每个核心服务模块的注册和授权过程，并用于处理每个客户端发送的查询请求；

在客户端根据查询结果向对应的服务节点发送服务请求后，所述服务节点对应的内核模块用于根据接收到的服务请求进行命令解析以及链接管理，还用于与所述核心服务模块进行任务交互。

本方案中提供的进程间的通讯装置，设置有多个服务节点以及多个内核模块，每个服务节点对应的内核模块对相应的服务请求进行解析和管理，然后分别于对应的核心服务模块进行交互完成服务，采用了去中心化的设计，避免将系统功能限定在单个服务内，将内核模块改造成单独的服务对应的模块，降低了中心化导致的功能负担，提高IPC效率。

在本方案的一种具体实现中，所述至少一个客户端，所述服务管理模块，所述至少一个服务节点，以及所述至少一个核心服务模块设置在用户空间内；所述至少一个内核模块设置在内核空间中。

本申请第二方面提供一种进程间的通讯方法，应用于第一方面任一项所述的进程间通讯装置，所述方法包括：

客户端向服务管理模块发送查询请求，所述查询请求携带第一服务名称；

所述服务管理模块根据所述查询请求，查询获取所述第一服务名称对应的第一服务节点的标识，并将所述第一服务节点的标识返回所述客户端；

所述客户端根据所述第一服务节点的标识向所述第一服务节点发送服务请求；

所述第一服务节点将所述服务请求转发至对应的第一内核模块；

所述第一内核模块对所述服务请求进行解析，并将解析后的服务请求发送至对应的第一核心服务模块进行处理；

所述第一内核模块获取所述服务请求对应的处理结果，并将所述处理结果通过所述第一服务节点返回所述客户端。

在本方案中，在该进程间通讯装置进行服务处理的过程中，通过服务管理模块进行查询，相应的服务节点以及与服务节点对应的内核模块对该服务请求进行解析和管理，然后分别于对应的核心服务模块进行交互完成服务，采用了去中心化的涉及，避免将系统功能限定在单个服务内，将内核模块改造成单独的服务对应的模块，降低了中心化导致的功能负担，提高IPC效率。

在上述方案的基础上，在一种具体实现中，所述方法还包括：

所述第一核心服务模块在接收到所述服务请求之后，若待处理列表为空，则对所述服务请求进行处理，将得到的处理结果放置在共享内存区域；

若所述待处理列表不为空，则按照所述待处理列表中的顺序依次进行处理，并在对所述服务请求进行处理后，将得到的处理结果放置在所述共享内存区域。

可选的，所述第一内核模块获取所述服务请求对应的处理结果，包括：

所述第一内核模块从所述共享内存区域中读取所述服务请求对应的所述处理结果。

在该方案中，核心服务模块在接收到服务请求之后，如果只有一个服务请求则可以直接进行处理，但是一般来说，存在多个服务请求的可能，需要按照一定的顺序和队列进行处理，将处理结果直接放置在共享内存区域中，每个内核模块可自行获取对应的处理结果，进一步提高处理效率。

在另一种具体实现中，所述第一内核模块将所述处理结果通过所述第一服务节点返回所述客户端，包括：

所述第一内核模块将所述处理结果拷贝到所述客户端指定的地址空间中。

在另一种具体实现中，所述方法还包括：

所述第一核心服务模块向所述服务管理模块发送注册请求，所述注册请求中携带所述第一核心服务模块对应的第一服务节点与所述第一核心服务模块提供的至少一个服务之间的对应关系；

所述服务管理模块根据所述注册请求对所述第一核心服务模块完成注册。

本方案提供的进程间的通讯方法中，服务管理模块对所有的核心服务模块进行统一管理，在设置了新的核心服务模块之后，需要向服务管理模块进行注册，在进行服务请求处理的过程中，通过服务管理模块查询对应的节点，避免对其他服务的干扰。

在又一种具体实现中，所述服务管理模块根据所述查询请求，查询获取所述第一服务名称对应的第一服务节点的标识，并将所述第一服务节点的标识返回所述客户端，包括：

所述服务管理模块根据所述查询请求，查询获取所述第一服务名称对应的第一服务节点的标识；

根据预先配置的访问权限，确定是否允许所述客户端访问所述第一服务节点；

若允许所述客户端访问所述第一服务节点，则将所述第一服务节点的标识返回所述客户端。

在该方案中，服务管理模块需要对客户端访问的服务节点进行权限检测，确定是不是允许该客户对该服务节点进行访问，避免没有授权或者恶意的客户端获得系统提供的服务。

本申请第三方面提供一种终端设备，包括：

处理器、存储器；

存储器用于存储程序和数据，所述处理器调用存储器存储的程序，以执行第二方面任一实现方式提供的进程间的通讯方法。

本申请第四方面提供一种计算机可读存储介质，所述计算机可读存储介质包括程序，所述程序在被处理器执行时用于执行第二方面任一实现方式提供的进程间的通讯方法。

本申请提供的进程间的通讯方法、装置、设备和存储介质，进程间的通讯装置，设置有多个服务节点以及多个内核模块，每个服务节点对应的内核模块对相应的服务请求进行解析和管理，然后分别于对应的核心服务模块进行交互完成服务，采用了去中心化的设计，避免将系统功能限定在单个服务内，将内核模块改造成单独的服务对应的模块，降低了中心化导致的功能负担，提高进程间通讯的效率。

附图说明

图1为Android Binder机制架构示意图；

图2为本申请提供的进程间的通讯装置的示意图；

图3为本申请提供的进程间的通讯装置的服务初始化示意图；

图4为本申请提供的进程间的通讯方法的实施例一的流程示意图；

图5为本申请提供的进程间的通讯方法与Android binder的对比示意图；

图6为本申请提供的终端设备实施例的结构示意图。

具体实施方式

在图1所示的Android Binder(也称为安卓进程间通讯)机制中，可以看出，在客户端(client)发起对某个服务的请求后，binder驱动向server端的服务请求队列插入请求，请求执行完毕返回给client执行结果。Android的IPC机制中，内核模块binder是进程间通信的桥梁和核心，Android Binder机制本身中心化的设计思想也易造成整机系统进程通讯的瓶颈，负担较重且设计复杂。

针对上述问题，本申请提供一种进程间的通讯装置，采用去中心化的设计思想，进程间的通讯还是客户端和服务模块的模式，但弱化服务管理的角色，同时离散化内核模块，去除其中心化的系统功能将其限定在单个的服务内；这样就把服务全局的内核模块改造成单独服务某个服务，降低了Android binder中心化的功能负担，提升进程间通讯的效率。

下面通过具体的实施方式对本申请提供的进程间的通讯方法以及装置进行详细说明。

图2为本申请提供的进程间的通讯装置的示意图；如图2所示，本申请提供的进程间的通讯装置中，包括：

至少一个客户端(client)，服务管理模块，至少一个服务节点，至少一个核心服务模块，至少一个内核模块。其中，图中示出了一个客户端和两个核心服务模块1和2，以及相应的两个服务节点1和2和两个内核模块1和2。服务节点也就是binder，核心服务模块指的就是服务(server)本身。

该方案提供的进程间的通讯装置中，内核模块、服务节点与核心服务模块之间一一对应的关系，如图2所示，服务节点1，内核模块1与核心服务模块1对应；服务节点2，内核模块2与核心服务模块2对应。具体应用过程中，服务节点1为内核模块1提供与客户端之间进行交互的接口，内核模块1对从服务节点1发送来的服务请求进行命令解析、请求链接管理等处理，并在处理完之后将服务请求转发至核心服务模块1进行服务处理，服务节点2，内核模块2与核心服务模块2的处理类似。

客户端(Client)是服务的请求者，主动发起请求去获得某个服务。核心服务模块(Server)是服务的提供者，每个核心服务模块拥有提供多个服务(service)的能力，被动的接收客户端发起的服务请求和应答。核心服务模块对应的内核模块主要负责，客户端的服务请求的处理(如命令解析)、请求链接管理、与核心服务模块之间的通信交互及结果处理；同时该内核模块与所服务的用户态服务强绑定，是1对1的关系；内核模块对外提供用户态程序访问的服务节点，譬如：/dev/<serverX>/binder(也可以借助内核的其他模块如sys文件系统等，如/sys/<serverX>/binder)。

在该进程间的通讯装置的具体应用过程中，所述服务管理模块用于管理每个核心服务模块的注册和授权过程，并用于处理每个客户端发送的查询请求。其含义是，在该系统中增加了新的核心服务之后，核心服务模块需要向该服务管理模块进行注册授权，以便用户在通过客户端进行该新的服务的访问时候，能够通过该核心服务模块完成查询过程。在具体应用中，客户端需要某个服务时，首先通过客户端向服务管理模块发送查询请求，查询该服务对应的服务节点，以便通过该服务节点执行后续的服务处理过程。

在客户端从服务管理模块查询到对应的服务节点之后，根据查询结果向对应的服务节点发送服务请求，继续执行服务处理过程，所述服务节点将接收到的服务请求转发至对应的内核模块，内核模块用于根据接收到的服务请求进行命令解析以及链接管理，在完成解析之后，将与所述核心服务模块进行任务交互。即内核模块在完成解析之后，将具体的服务执行任务发送至对应的核心服务模块进行处理，以便获取到服务请求的处理结果。

在该进程间的通讯装置中，所述至少一个客户端、所述服务管理模块、所述至少一个服务节点、以及所述至少一个核心服务模块设置在用户空间内(User space)；所述每个核心服务模块对应的内核模块设置在内核空间(Kernel space)中。

本实施例提供的进程间的通讯装置，设置有多个服务节点以及多个内核模块，每个服务节点对应的内核模块对相应的服务请求进行解析和管理，然后分别于对应的核心服务模块进行交互完成服务，采用了去中心化的设计，避免将系统功能限定在单个服务内，将内核模块改造成单独的服务对应的模块，降低了中心化导致的功能负担，提高进程间通信的效率。

在上述实施例的基础上，在该进程间的通讯装置的具体实现中，服务管理模块，也称为服务管理中心，该服务管理模块中需要对每个核心服务模块进行注册授权等管理。每个核心服务模块(Server)会对外提供[1，N]个服务(service)，其中N>＝1，在服务管理模块中进行管理时，可以对每个服务进行命名，例如：命名为[serviceName1，serviceNameN]，这些命名对系统所有客户端可见，而每个核心服务模块对应的内核模块对外提供一个服务节点(binder)，但服务节点和serviceName之间的对应关系并不被客户端所知，服务管理模块的一个功能就是接受核心服务模块注册的对应关系进行存储，例如下表1所示，并供客户端进行查询，然后客户端去访问该服务节点获得进程间通讯(英文：inter processcommunication，简称：IPC)的通信入口。

表1：

表1服务名称与Server对外服务节点对应表

在一种具体实现方式中，客户端想获得服务serviceName2，它首先需要向服务管理模块提交查询请求，服务管理模块通过serviceName2查找到服务节点/dev/<server1>/binder，并将该服务节点的标识返回给客户端，客户端就可以通过这个服务节点来和核心服务模块1(server1)开展IPC通信。

同时服务管理模块还提供服务节点的权限访问，来避免恶意没有授权的客户端获得系统提供的服务，在客户端发送了查询请求之后，确定该客户端是否具有对查询请求中指示的服务进行获取的权限。

在一个系统中，能对外提供服务的模块基本是静态的，所以可以采用如Linux的selinux模块实现进程对某个路径文件的访问权限配置和控制，在客户端安装或者设置的过程中，进行权限设置，每个核心服务模块对应的服务节点对应相应的权限配置，在该服务管理模块中可以存储对应的权限，一种具体的实现方式中，可以通过表格的方式进行存储，例如：下表2所示。

表2：

表2进程对服务节点的访问权限管理

在该方案的一种具体实现中，每增加新的服务，需要进行服务初始化。图3为本申请提供的进程间的通讯装置的服务初始化示意图，如图3所示，在服务创建的过程的同时，会加载相应的内核模块(图3中示出的步骤1加载)，完成内核模块加载，也就是初始化之后，根据该进行对外服务节点的生成(图3中示出的步骤2生成)，同时将该服务进程变成内核模块的守护进程(图3中示出的步骤3守护进程)，然后在服务管理模块中更新服务信息(表1的信息)。

在根据上述过程完成服务初始化完，就进入空闲状态，等待接受客户端发来的请求进行处理可。

在该方案的具体实现中，服务进程本身要包含对外提供的serviceName[1，N]的逻辑实现；为了减少服务返回处理结果的数据拷贝次数，可以针对核心服务模块分别映射同一块内存空间，同时映射对应的用户进程空间，在对服务请求进行处理完之后，核心服务模块将处理结果放置在映射的内存空间中，内核模块通过获取对该内存空间进行访问，得到相应的处理结果，再通过服务节点返回给客户端。例如：可利用Linux内核提供的map_vm_area()和vm_insert_page()，实现内核的同一块物理内存，分别映射到内核态的核心服务模块和用户态服务进程空间，这样用户态的服务进程返回的数据(也就是服务请求对应的处理结果)可以直接写入对应的虚拟地址空间区域。因为该区域的物理地址和内核模块共享，无需从用户态拷贝到内核态，所以内核模块可以把区域中的数据直接返回给客户端。

通过上述方式，可以减少在进程间通讯的过程中，反馈服务请求的处理结果的数据拷贝次数，进一步提高进程间通讯的效率。

上述实施例介绍了针对单个设备操作系统内部的去中心化的进程间的通讯装置的实现，未来基于分布式操作系统和多设备，利用当前的设备互联技术，本方案提供的进程间的通讯方案依然可以发挥作用，也就是说上述的进程间的通讯装置中的各个模块可以设置在同一个设备中，也可以分布式设置在多个设备上，对此本方案不做限制。

在上述进程间的通讯装置的实现的基础上，下面对进程间的通讯方法进行介绍。

图4为本申请提供的进程间的通讯方法的实施例一的流程示意图；如图4所示，本申请提供的进程间的通讯方法的具体步骤包括：

S101：客户端向服务管理模块发送查询请求，查询请求携带第一服务名称。

在本步骤中，应理解，第一服务已经完成对应的服务初始化过程，在客户端需要该第一服务时，客户端向服务管理模块发送携带该第一服务名称的查询请求，以获取该第一服务对应的服务节点。例如：客户端首先向服务管理模块查询某个serviceName的服务节点。

S102：服务管理模块根据查询请求，查询获取第一服务名称对应的第一服务节点的标识，并将第一服务节点的标识返回客户端。

在本步骤中，服务管理模块在接收到客户端发送的查询请求之后，根据服务注册过程中得到的服务以及对应的服务节点的对应关系，例如表1，查询获取该第一服务名称对应的第一服务节点，然后将该第一服务节点通知给客户端，一般可以通过返回第一服务节点的标识的方式进行反馈，也可以直接将该第一服务节点反馈给客户端，对此本方案不做限制。

例如：服务管理模块可以向该客户端返回serviceName所在的服务节点如/dev/<serverX>/binder。

S103：客户端根据第一服务节点的标识向第一服务节点发送服务请求。

在本步骤中，客户端得到了第一服务节点的标识之后，根据该标识向该第一服务节点发送服务请求，请求对应的服务。例如：客户端打开服务管理模块返回的服务节点/dev/<serverX>/binder，发送请求serviceName服务。

S104：第一服务节点将服务请求转发至对应的第一内核模块。

S105：第一内核模块对服务请求进行解析，并将解析后的服务请求发送至对应的第一核心服务模块。

在上述几个步骤中，第一服务节点在接收到客户端发送的服务请求之后，将其转发至对应的第一内核模块，内核模块承担对服务请求的解析，链接管理，以及任务交互等过程。第一内核模块对服务请求进行解析之后，转发至对应的第一核心服务模块进行处理。

例如：serverX的内核模块接受到客户端的服务请求，完成服务的解析并发送到serverX的todo list里边；当serverX的todo list不为空，将通知serverX的用户态程序，直到排空todo list里边的请求；同时serverX的内核模块还要管理多客户端的链接请求，即在模块内部维护这些客户端的多线程服务请求。

S106：第一核心服务模块对服务请求进行处理。

在本步骤中，第一核心服务模块对服务请求进行处理，得到相应的数据，也就是处理结果。例如：用户态的serverX进程获得todo list里边的一个服务请求，进行处理，将结果放到事先映射好的共享内存区域。

S107：第一内核模块获取服务请求对应的处理结果，并将处理结果通过第一服务节点返回客户端。

在本步骤中，第一核心服务模块处理得到的结果不能直接与客户端进行交互反馈，还是需要通过该第一内核模块以及第一服务节点返回给客户端。

例如：serverX的内核模块得到用户态serverX的处理结果，唤醒等待的client，并将结果拷贝到client指定的地址空间，完成整个的服务过程。

上述过程示出了一种服务请求的处理过程，针对其他客户端的服务请求，以及客户端对其他服务的请求过程，均可以按照同样的步骤，进行处理，对此本方案不做限制。

本实施例提供的进程间的通讯方法，通过服务管理模块进行查询，相应的服务节点以及与服务节点对应的内核模块对该服务请求进行解析和管理，然后分别于对应的核心服务模块进行交互完成服务，采用了去中心化的涉及，避免将系统功能限定在单个服务内，将内核模块改造成单独的服务对应的模块，降低了中心化导致的功能负担，提高IPC效率。

图5为本申请提供的进程间的通讯方法与Android binder的对比示意图。如图5所示，本方案和Android binder的一个很大的不同是，本申请的方案中将服务管理(服务的内核模块)和服务提供者(服务用户态程序)集成一体，实现了客户端与服务提供者点对点的链接，而Android binder是通过service manager(binder)作为通信的中心，再跳转到具体的服务提供者，其中service manager(binder)起到桥梁作用，本申请中的服务管理模块，仅仅提供简单的服务节点查询、权限信息管理等；同时相比binder内核驱动，这种一体和针对单个服务端(Server)的设计，简化了内核binder模块对多server维护管理的逻辑。

本申请提供的进程间的通讯装置，以及对应的进程间的通讯方法，首先削弱了进程间通信依赖中心化模块的性能瓶颈，同时提升了进程IPC交互的并发度。本方案采用去中心化、高效的进程间通讯方法，服务提供者不仅承担了服务本身的执行逻辑，还承担了与客户端的交互管理等；消除了基于通信中中心化设计带来的性能瓶颈，减少了不同的客户端、不同的核心服务模块之间的相互干扰。

图6为本申请提供的终端设备实施例的结构示意图。如图6所示，该终端设备10，包括：处理器11、存储器12；存储器12用于存储程序和数据，所述处理器11调用存储器存储的程序，以执行前述任一实施例中的进程间的通讯方法的技术方案。

在上述在终端设备10的实现中，存储器和处理器之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可以通过一条或者多条通信总线或信号线实现电性连接，如可以通过总线连接。存储器中存储有实现数据访问控制方法的计算机执行指令，包括至少一个可以软件或固件的形式存储于存储器中的软件功能模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理。

存储器可以是，但不限于，随机存取存储器(Random Access Memory，简称：RAM)，只读存储器(Read Only Memory，简称：ROM)，可编程只读存储器(Programmable Read-OnlyMemory，简称：PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，简称：EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，简称：EEPROM)等。其中，存储器用于存储程序，处理器在接收到执行指令后，执行程序。进一步地，上述存储器内的软件程序以及模块还可包括操作系统，其可包括各种用于管理系统任务(例如内存管理、存储设备控制、电源管理等)的软件组件和/或驱动，并可与各种硬件或软件组件相互通信，从而提供其他软件组件的运行环境。

处理器可以是一种集成电路芯片，具有信号的处理能力。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，简称：CPU)、网络处理器(NetworkProcessor，简称：NP)等。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述程序在被处理器执行时用于执行前述任一方法实施例中进程间的通讯方法的技术方案。

本领域普通技术人员应理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质，具体的介质类型本申请不做限制。

Claims (10)

1.一种进程间的通讯装置，其特征在于，包括：

至少一个客户端，服务管理模块，至少一个服务节点，至少一个核心服务模块，至少一个内核模块；内核模块，服务节点与核心服务模块之间一一对应；

所述服务管理模块用于管理每个核心服务模块的注册和授权过程，并用于处理每个客户端发送的查询请求；

在客户端根据查询结果向对应的服务节点发送服务请求后，所述服务节点对应的内核模块用于根据接收到的服务请求进行命令解析以及链接管理，还用于与所述核心服务模块进行任务交互。

2.根据权利要求1所述的装置，其特征在于，所述至少一个客户端，所述服务管理模块，所述至少一个服务节点，以及所述至少一个核心服务模块设置在用户空间内；所述至少一个内核模块设置在内核空间中。

3.一种进程间的通讯方法，其特征在于，应用于权利要求1或2所述的进程间通讯装置，所述方法包括：

客户端向服务管理模块发送查询请求，所述查询请求携带第一服务名称；

所述服务管理模块根据所述查询请求，查询获取所述第一服务名称对应的第一服务节点的标识，并将所述第一服务节点的标识返回所述客户端；

所述客户端根据所述第一服务节点的标识向所述第一服务节点发送服务请求；

所述第一服务节点将所述服务请求转发至对应的第一内核模块；

所述第一内核模块对所述服务请求进行解析，并将解析后的服务请求发送至对应的第一核心服务模块进行处理；

所述第一内核模块获取所述服务请求对应的处理结果，并将所述处理结果通过所述第一服务节点返回所述客户端。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

所述第一核心服务模块在接收到所述服务请求之后，若待处理列表为空，则对所述服务请求进行处理，将得到的处理结果放置在共享内存区域；

若所述待处理列表不为空，则按照所述待处理列表中的顺序依次进行处理，并在对所述服务请求进行处理后，将得到的处理结果放置在所述共享内存区域。

5.根据权利要求4所述的方法，其特征在于，所述第一内核模块获取所述服务请求对应的处理结果，包括：

所述第一内核模块从所述共享内存区域中读取所述服务请求对应的所述处理结果。

6.根据权利要求3至5任一项所述的方法，其特征在于，所述第一内核模块将所述处理结果通过所述第一服务节点返回所述客户端，包括：

所述第一内核模块将所述处理结果拷贝到所述客户端指定的地址空间中。

7.根据权利要求3至6任一项所述的方法，其特征在于，所述方法还包括：

所述第一核心服务模块向所述服务管理模块发送注册请求，所述注册请求中携带所述第一核心服务模块对应的第一服务节点与所述第一核心服务模块提供的至少一个服务之间的对应关系；

所述服务管理模块根据所述注册请求对所述第一核心服务模块完成注册。

8.根据权利要求3至7任一项所述的方法，其特征在于，所述服务管理模块根据所述查询请求，查询获取所述第一服务名称对应的第一服务节点的标识，并将所述第一服务节点的标识返回所述客户端，包括：

所述服务管理模块根据所述查询请求，查询获取所述第一服务名称对应的第一服务节点的标识；

根据预先配置的访问权限，确定是否允许所述客户端访问所述第一服务节点；

若允许所述客户端访问所述第一服务节点，则将所述第一服务节点的标识返回所述客户端。

9.一种终端设备，其特征在于，包括：

处理器、存储器；

存储器用于存储程序和数据，所述处理器调用存储器存储的程序，以执行权利要求3至8任一项所述的进程间的通讯方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括程序，所述程序在被处理器执行时用于执行权利要求3至8任一项所述的进程间的通讯方法。