CN111083213A - 一种通信方法及系统 - Google Patents

Abstract

本申请公开了一种通信方法及系统，其中所述方法包括：用户端将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点；所述第一服务节点对所述请求进行解析，获得所述请求包含的资源需求；所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点，所述第一服务节点与所述第二服务节点是同一类型的所述服务节点；所述第一服务节点将所述请求发送给所述第二服务节点；第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端，对OpenStack架构进行了改进，消除了控制节点和计算节点的角色隔离，提高了整个系统架构的容错率。

Description

一种通信方法及系统

技术领域

本发明涉及通信领域，尤其涉及一种通信方法及系统。

背景技术

随着云计算的快速发展，越来越多的用户开始使用IaaS服务。IaaS(Infrastructure as a Service)，即基础设施即服务，是指把IT基础设施作为一种服务通过网络对外提供，并根据用户对资源的实际使用量或占用量进行计费的一种服务模式。在IaaS服务模型中，普通用户不需要自己构建数据中心等硬件设施，而是通过租用的方式，利用Internet从IaaS服务提供商获得计算机基础设施服务，包括服务器、存储和网络等服务。

在现有技术中，通常使用OpenStack搭建IaaS的服务架构。在这种架构中，包含了控制节点、消息中间件、计算节点，由控制节点和消息中间件负责接收用户、分配处理请求的计算节点、将计算节点生成的计算结果返回给用户。一旦控制节点或者消息队列产生问题无法工作，就无法正常为用户提供服务。

发明内容

为了解决现有技术的不足，本发明的主要目的在于提供一种通信方法，通过每台服务节点独立实现OpenStack架构中控制节点和计算节点的全部功能，消除OpenStack架构中控制节点和计算节点的角色隔离，提高计算架构的稳定性。

为了达到上述目的，第一方面本发明提供了一种通信方法，所述方法包括：

用户端将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点；

所述第一服务节点对所述请求进行解析，获得所述请求包含的资源需求；

所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点，所述第一服务节点与所述第二服务节点是同一类型的所述服务节点；

所述第一服务节点将所述请求发送给所述第二服务节点；

第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端。

在一些实施例中，所述方法还包括：

每一所述服务节点按照预设的第一时间周期定时生成包含自身的调用方法及资源状态的状态消息并发送给所有所述服务节点；

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态；每个所述服务节点拥有一个所述可用服务节点池，用于保存接收到的服务节点的资源状态及调用方法；

所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点包括：

所述第一服务节点根据拥有的所述可用服务节点池中保存的所有所述服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点。

在一些实施例中，所述第一服务节点将所述请求发送给所述第二服务节点包括：

所述第一服务节点将所述资源需求序列化，获得序列化的所述资源需求；

所述第一服务节点根据拥有的所述可用服务节点池中保存的所述第二服务节点的调用方法，生成包含所述序列化的所述资源需求的调用请求并发送给所述第二服务节点。

在一些实施例中，所述状态消息包含所述状态消息的发送时间，

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态包括：

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法、资源状态及发送时间；

所有所述服务节点按照第二预设时间周期定时根据拥有的所述可用服务节点池包含的每一所述服务节点的发送时间，计算每一所述服务节点的失联时长，将失联时长超过预设阈值的所述服务节点从拥有的所述可用服务节点池中删除。

通过计算当前的实时时间与发送时间的差值，可以获得失联时长。

在一些实施例中，所述用户端将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点包括：

用户端将接收的请求发送至API网关；

所述API网关按照预先配置的负载均衡策略将所述请求转发给所述请求对应的第一服务节点；

第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端包括：

第二服务节点接收并处理所述请求，生成处理结果并返回给所述第一服务节点；

所述第一服务节点接收并将所述处理结果返回给API网关；

所述API网关将所述处理结果发送给所述用户端。

在一些实施例中，所述第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端包括：

所述第二服务节点接收所述请求，按照预设方法检查所述第二服务节点的实时资源状态是否满足所述资源需求；

当检查满足所述资源需求时，所述第二服务节点处理所述请求，生成处理结果并返回给所述用户端。

第二方面，本申请提供了一种通信系统，所述系统包括：

用户端，用于将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点；

服务节点集群，包含同一类型的第一服务节点及第二服务节点，

所述第一服务节点用于对所述请求进行解析，获得所述请求包含的资源需求，根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点，将所述请求发送给所述第二服务节点；

所述第二服务节点用于接收并处理所述请求，生成处理结果并返回给所述用户端。

在一些实施例中，所述服务节点集群包含的每一服务节点按照预设的第一时间周期定时生成包含自身的调用方法及资源状态的状态消息并发送给所有所述服务节点；

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态；每个所述服务节点拥有一个所述可用服务节点池，用于保存接收到的服务节点的资源状态及调用方法；

所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点包括：

所述第一服务节点根据拥有的所述可用服务节点池中保存的所有所述服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点。

在一些实施例中，所述用户端还可用于将接收的请求发送至API网关，所述系统还包含API网关，

所述API网关用于按照预先配置的负载均衡策略将所述请求转发给所述请求对应的第一服务节点；

所述第二服务节点还可用于接收并处理所述请求，生成处理结果并返回给所述第一服务节点；

所述第一服务节点还可用于接收并将所述处理结果返回给API网关；

所述API网关用于将所述处理结果发送给所述用户端。

在一些实施例中，所述状态消息包含所述状态消息的发送时间：

所述服务节点还可用于接收并根据所述状态消息更新拥有的可用服务节点池中保存的对应的服务节点的调用方法、资源状态及发送时间；

按照第二预设时间周期定时根据拥有的所述可用服务节点池包含的每一所述服务节点的发送时间，计算每一所述服务节点的失联时长，将失联时长超过预设阈值的所述服务节点从拥有的所述可用服务节点池中删除。

本发明实现的有益效果为：

本发明提出了将用户端将接收的请求发送至按照预设规则确定的所述请求对应的第一服务节点；所述第一服务节点对所述请求进行解析，获得所述请求包含的资源需求；所述第一服务节点根据服务节点集群内每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点，所述第一服务节点与所述第二服务节点是同一类型的所述服务节点；所述第一服务节点将所述请求发送给所述第二服务节点；第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端，消除了OpenStack架构中控制节点和计算节点的角色隔离，每一服务节点既能进行用户请求的分配，也能处理用户的请求，即使整个架构中出现一部分服务节点无法工作，仍能继续为用户提供服务，提高了整个系统架构的容错率；

本申请还公开了服务节点按照预设的第一时间周期定时生成包含自身的调用方法及资源状态的状态消息并发送给所有所述服务节点；每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态，每个所述服务节点拥有一个所述可用服务节点池，用于保存接收到的服务节点的资源状态及调用方法，省去了Openstack原有的消息队列进行消息传递的过程，实现了服务节点间的资源状态交换的直接通信；进一步地，本申请提出了服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法、资源状态及发送时间；按照第二预设时间周期定时根据拥有的所述可用服务节点池包含的每一所述服务节点的发送时间，计算每一所述服务节点的失联时长，将失联时长超过预设阈值的所述服务节点从拥有的所述可用服务节点池中删除，保证用户的请求不会被分配到失效的服务节点上，提升了用户的使用体验；

本申请还提出了通过使用API网关接收用户端发送的请求，按照预先配置的负载均衡策略将所述用户端发送的请求转发给对应的第一服务节点，并接收生成的处理结果发送给用户端，实现了对服务节点的反向代理，且对用户的请求进行了分流，防止用户请求拥堵在几台服务节点上无法及时处理。

本发明所有产品并不需要具备上述所有效果。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的现有技术架构图；

图2是本申请实施例提供的改进架构结构图；

图3是本申请实施例提供的方法流程图；

图4是本申请实施例提供的系统结构图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如背景技术所述，现有的IaaS服务提供商通常使用OpenStack搭建云计算服务平台。如图1所示，以使用OpenStack包含的OpenStack Nova组件，为用户提供虚拟机创建服务为例，使用消息队列作为消息中间件，具体的实现步骤包括：

1使用控制节点中的Nova API，作为用户端与OpenStack Nova之间的中间层接收用户创建虚拟机的请求；

2、Nova API解析请求中包含的待创建虚拟机的资源参数并将其封装，将封装后的指令通过消息队列中的Compute RPCClient发送给Nova Conductor；

3、Nova Conductor接受该指令，将该指令包含的所述资源参数重新进行封装，生成计算节点的筛选请求，经过Scheduler RPCClient发送控制节点中的Nova Scheduler；

4、Nova Scheduler服务接收所述筛选请求，根据包含的所述资源参数筛选符合要求的计算节点，并将筛选获得的计算节点返回Nova Conductor；

5、Nova Conductor将所述资源参数存入Mysql，根据所述资源参数生成虚拟机创建请求，向筛选获得的计算节点发送所述虚拟机创建请求；

6、计算节点接收并解析所述虚拟机创建请求，根据请求中包含的资源参数创建虚拟机。

Mysql是一种关系型数据库，用于存储数据。

分析以上流程可知，OpenStack组件内部交互涉及到消息队列组件和MySQL。如果在实际部署OpenStack Nova时，将消息队列和MySQL部署在控制节点中，那么当接收的用户请求的流量达到峰值时，消息队列和MySQL产生的负载量将加大控制节点的工作压力，最终导致控制节点工作异常。即使将消息队列和MySQL从控制节点剥离，部署在独立的服务器上，当所述流量达到峰值时，消息队列的负载压力依旧很大，仍旧存在消息队列发生工作异常、导致控制节点和计算节点间的通信受到影响的风险。因此，OpenStack基于消息队列的通信方式存在以下问题：

消息队列和控制节点集中部署，消息队列负载过高时导致控制节点异常；

消息队列和控制节点分离部署，消息队列负载过高发生工作异常，控制节点和计算节点无法通信；

消息队列本身存在缓存和落盘机制，需要经常进行存储，加大了消息队列的工作压力，提升了发生工作异常的风险；

消息队列集群存在消息同步机制，降低消息队列性能；

计算节点及控制节点内的各个组件需要持续监听消息队列，各组件中断需要预先引入各类重试机制以实现与消息队列断开连接时的重新连接；

消息队列存在消息堆积风险，需要引入额外的保障机制确保消息队列运行状态正常。

针对上述技术问题，本发明提供了一种通信方法，对OpenStack架构进行了改进，可应用于IaaS服务，消除了OpenStack架构内的控制节点和计算节点的角色隔离，将控制节点和计算节点实现的功能在每个服务节点上实现，每个服务节点既是控制节点也是计算节点，既能进行用户请求的分配也能对用户请求进行处理。进一步地，通过在架构各服务节点内部使用可用结点池缓存其他服务节点的资源状态及调用方法，去除了消息中间件即消息队列，提高了IAAS集群的容错性。

图2示出了本发明提出的改进架构的结构图，包括了API Gateway即API网关、服务节点集群，服务节点集群中由Service Node即服务节点组成。API网关用于接收用户的请求、将请求按照预设的负载均衡策略转发给第一服务节点，第一服务节点根据本地缓存的可用节点池保存的每个服务节点的资源状态，筛选满足用户请求的第二服务节点，调用所述第二服务节点完成所述请求，所述第二服务节点将处理结果返回第一服务节点，第一服务节点再将所述处理结果返回API网关，由API网关返回给用户。

API网关是用户请求进入该系统的唯一入口，根据上述方法API网关按照预设的负载均衡策略进行了请求的分流、为所有的服务节点提供了反向代理，提高了整个系统的稳定性。

反向代理是指，由API网关代理所有的服务节点接收用户请求，并将所有服务节点的处理结果返回给用户，用户不需知道具体是哪一台服务节点完成了请求。

服务节点可以是一台或多台服务器，可根据用户的请求进行计算、创建虚拟机等操作。

实施例一

为了实现上述目的，以用户发出虚拟机创建请求为例，上述方案可通过如下步骤实现：

步骤一、各服务节点间资源状态市局和RPC端点信息数据定时进行同步；

如图1所示，所述同步过程具体包括：

S101、各服务节点读取配置参数，进行服务配置初始化；

配置参数具体包括：API端口、组播地址、CPU\内存超分策略、本地虚拟化驱动等节点配置信息。

每个服务节点还设置了监控核心服务的独立进程，当核心服务状态不正确时自动调整核心服务至最优状态，保证服务节点能够正常运转，所述核心服务状态包含核心服务运行状态和核心服务内部运行状态。例如，当核心服务状态为stop时，表明核心服务运行状态异常，自动将所述核心服务重启；又如服务状态为active，但服务进程内部已阻塞，表明核心服务内部运行状态异常，自动调整服务的运行时。

为了解决服务节点集群内的所有服务节点的数据一致性问题，所有服务节点使用同一个数据库集群进行数据存储，将保证数据一致性的任务交由数据库集群解决，现有技术中存在成熟的数据库集群内部的数据同步机制。

S102、服务节点按照预设的第一时间周期定时获取自身的资源状态数据，解析封装自身的RPC端点信息数据；

RPC指远程过程调用，主要应用于分布式系统架构中不同的系统之间的远程通信和相互调用。

根据所述RPC端点信息数据可查找获得对应的服务节点、对对应的服务节点提供的服务进行调用。

所述资源状态数据包括：VCPU的状态参数、可用内存状态、自身的CPU的拓扑结构等。

S103、将资源状态数据以及RPC端点信息数据、发出时间发向所述组播地址，所述组播地址对应的网络设备接收所述资源状态数据以及RPC端点信息数据并发送给其他的服务节点；

每个服务节点都预置了重试、重传等机制，用于在通信发生异常时重新建立通信，以保证为了保证能够服务节点间的通信质量。

S104、各服务节点接收由所述网络设备转发的其他服务节点的资源状态数据以及RPC端点信息数据；

S105、各服务节点解析接收的其他服务节点的资源状态数据和RPC端点信息数据，经过数据解密、权限校验等多个步骤，将所述资源状态数据和RPC端点信息数据更新到拥有的可用节点池中，同时记录可用节点池中每个服务节点对应的发送时间，该可用节点池缓存于各服务节点的本地内存中；

步骤S106、各服务节点的主服务进程根据预先配置的服务地址和监听端口进行服务监听，等待被其他服务节点、API网关调用。

为了保证拥有的可用节点池中的服务节点都处于可正常调用的状态，各服务节点会按照预设的第二时间周期，定时检查可用节点池内的每个服务节点的发送时间，计算当前时间与发送时间过去的差值即失联时长，将失联时长超过预设阈值的服务节点从可用节点池中删除。

步骤二、API网关接收到用户端发出的创建请求，根据预设的负载均衡策略转发给服务节点，由所述服务节点将请求分配给满足所述请求的服务节点进行处理并返回结果；

所述过程具体包括：

S201、API网关进行初始化；

所述初始化过程包括加载预设的负载均衡策略、加载各服务节点API服务地址。

S202、API网关接收用户端发送的请求；

S203、API网关根据预先配置的负载均衡策略，确定符合所述策略的第一服务节点；

所述负载均衡策略可通过轮询、权重、Hash等多种方式实现。

S204、API Gateway将所述请求转发到所述第一服务节点；

具体的，可根据第一服务节点的API服务地址，将所述请求转发到所述第一服务节点。

S205、第一服务节点接收所述请求并解析，获得所述请求包含的请求的虚拟机的资源需求参数；

S206、第一服务节点根据本地内存中缓存的可用节点池中每一服务节点的资源状态数据，确定满足所述资源需求参数的服务节点为第二服务节点；

S207、第一服务节点将所述资源需求参数序列化，并根据所述请求的请求类型、第二服务节点的所述RPC端点数据生成处理请求，所述处理请求以RPC调用的方法调用所述第二服务节点包含的对应所述请求类型的处理方法，所述请求包含了所述序列化的资源需求参数；

S208、第二服务节点接收第一服务节点的所述请求，将序列化的资源需求参数进行反序列化，根据资源需求参数检查本地的资源状态是否满足所述资源需求参数，若满足则调用对应的处理方法进行处理，生成对应的虚拟机；

S209、第二服务节点将处理结果返回第一服务节点，第一服务节点将处理结果返回API网关，由API网关返回用户端，供用户端使用。

当用户端接收处理结果后，会根据预设的任务保障策略，检测该处理结果对应的虚拟机的实际运行状态是否符合预设的要求，如果不符合则重新向API网关发送请求重新创建虚拟机，直到创建的虚拟机的实际运行状态符合期望值。

实施例二

对应上述实施例，本申请提供了一种通信方法，如图3所示，所述方法包括：

310、用户端将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点；

优选的，所述方法还包括：

311、每一所述服务节点按照预设的第一时间周期定时生成包含自身的调用方法及资源状态的状态消息并发送给所有所述服务节点；

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态；每个所述服务节点拥有一个所述可用服务节点池，用于保存接收到的服务节点的资源状态及调用方法；

所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点包括：

312、所述第一服务节点根据拥有的所述可用服务节点池中保存的所有所述服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点。

优选的，所述状态消息包含所述状态消息的发送时间，

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态包括：

313、每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法、资源状态及发送时间；

所有所述服务节点按照第二预设时间周期定时根据拥有的所述可用服务节点池包含的每一所述服务节点的发送时间，计算每一所述服务节点的失联时长，将失联时长超过预设阈值的所述服务节点从拥有的所述可用服务节点池中删除。

优选的，所述方法具体包括：

314、用户将接收的请求发送给API网关；

所述API网关按照预先配置的负载均衡策略将所述请求转发给所述请求对应的第一服务节点；

320、所述第一服务节点对所述请求进行解析，获得所述请求包含的资源需求；

330、所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点，所述第一服务节点与所述第二服务节点是同一类型的所述服务节点；

340、所述第一服务节点将所述请求发送给所述第二服务节点；

优选的，所述过程具体包括：

341、所述第一服务节点将所述资源需求序列化，获得序列化的所述资源需求；

所述第一服务节点根据拥有的所述可用服务节点池中保存的所述第二服务节点的调用方法，生成包含所述序列化的所述资源需求的调用请求并发送给所述第二服务节点。

350、第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端。

优选的，所述方法包括：

351、第二服务节点接收并处理所述请求，生成处理结果并返回给所述第一服务节点；

所述第一服务节点接收并将所述处理结果返回给API网关；

所述API网关将所述处理结果发送给所述用户端。

优选的，所述方法包括：

352、所述第二服务节点接收所述请求，按照预设方法检查所述第二服务节点的实时资源状态是否满足所述资源需求；

当检查满足所述资源需求时，所述第二服务节点处理所述请求，生成处理结果并返回给所述用户端。

本申请公开的上述方法除可应用于云计算平台的搭建外，也可应用于其他的分布式系统架构中，本申请对此不加限定。

实施例三

对应上述方法实施例，本申请提供了一种通信系统，如图4所示，所述系统包括：

用户端410，用于将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点；

服务节点集群420，包含同一类型的第一服务节点430及第二服务节点440，

所述第一服务节点430用于对所述请求进行解析，获得所述请求包含的资源需求，根据服务节点集群中每一服务节点430的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点440，将所述请求发送给所述第二服务节点440；

所述第二服务节点440用于接收并处理所述请求，生成处理结果并返回给所述用户端410。

优选的，所述服务节点集群420包含的每一服务节点按照预设的第一时间周期定时生成包含自身的调用方法及资源状态的状态消息并发送给所有所述服务节点；

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态；每个所述服务节点拥有一个所述可用服务节点池，用于保存接收到的服务节点的资源状态及调用方法；

所述第一服务节点430根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点440包括：

所述第一服务节点430根据拥有的所述可用服务节点池中保存的所有所述服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点440。

优选的，第一服务节点430还可用于将所述资源需求序列化，获得序列化的所述资源需求；

根据拥有的所述可用服务节点池中保存的所述第二服务节点440的调用方法，生成包含所述序列化的所述资源需求的调用请求并发送给所述第二服务节点440。

优选的，所述状态消息包含所述状态消息的发送时间：

所述服务节点还可用于接收并根据所述状态消息更新拥有的可用服务节点池中保存的对应的服务节点的调用方法、资源状态及发送时间；

按照第二预设时间周期定时根据拥有的所述可用服务节点池包含的每一所述服务节点的发送时间，计算每一所述服务节点的失联时长，将失联时长超过预设阈值的所述服务节点从拥有的所述可用服务节点池中删除。

优选的，所述系统还包含API网关450；

所述API网关450用于按照预先配置的负载均衡策略将所述请求转发给所述请求对应的第一服务节点430；

所述第二服务节点440还可用于接收并处理所述请求，生成处理结果并返回给所述第一服务节点430；

所述第一服务节点430还可用于接收并将所述处理结果返回给API网关450；

所述API网关450用于将所述处理结果发送给所述用户端410。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种通信方法，其特征在于，所述方法包括：

用户端将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点；

所述第一服务节点对所述请求进行解析，获得所述请求包含的资源需求；

所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点，所述第一服务节点与所述第二服务节点是同一类型的所述服务节点；

所述第一服务节点将所述请求发送给所述第二服务节点；

第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端。

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

每一所述服务节点按照预设的第一时间周期定时生成包含自身的调用方法及资源状态的状态消息并发送给所有所述服务节点；

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态；每个所述服务节点拥有一个所述可用服务节点池，用于保存接收到的服务节点的资源状态及调用方法；

所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点包括：

所述第一服务节点根据拥有的所述可用服务节点池中保存的所有所述服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点。

3.根据权利要求2所述的方法，其特征在于，所述第一服务节点将所述请求发送给所述第二服务节点包括：

所述第一服务节点将所述资源需求序列化，获得序列化的所述资源需求；

所述第一服务节点根据拥有的所述可用服务节点池中保存的所述第二服务节点的调用方法，生成包含所述序列化的所述资源需求的调用请求并发送给所述第二服务节点。

4.根据权利要求2或3所述的方法，其特征在于，所述状态消息包含所述状态消息的发送时间，

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态包括：

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法、资源状态及发送时间；

所有所述服务节点按照第二预设时间周期定时根据拥有的所述可用服务节点池包含的每一所述服务节点的发送时间，计算每一所述服务节点的失联时长，将失联时长超过预设阈值的所述服务节点从拥有的所述可用服务节点池中删除。

5.根据权利要求1-3任一所述的方法，其特征在于，所述用户端将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点包括：

用户端将接收的请求发送至API网关；

所述API网关按照预先配置的负载均衡策略将所述请求转发给所述请求对应的第一服务节点；

第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端包括：

第二服务节点接收并处理所述请求，生成处理结果并返回给所述第一服务节点；

所述第一服务节点接收并将所述处理结果返回给API网关；

所述API网关将所述处理结果发送给所述用户端。

6.根据权利要求1-3任一所述的方法，其特征在于，所述第二服务节点接收并处理所述请求，生成处理结果并返回给所述用户端包括：

所述第二服务节点接收所述请求，按照预设方法检查所述第二服务节点的实时资源状态是否满足所述资源需求；

当检查满足所述资源需求时，所述第二服务节点处理所述请求，生成处理结果并返回给所述用户端。

7.一种通信系统，其特征在于，所述系统包括：

用户端，用于将接收的请求发送至按照预设规则从服务节点集群中确定的与所述请求对应的第一服务节点；

服务节点集群，包含同一类型的第一服务节点及第二服务节点，

所述第一服务节点用于对所述请求进行解析，获得所述请求包含的资源需求，根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点，将所述请求发送给所述第二服务节点；

所述第二服务节点用于接收并处理所述请求，生成处理结果并返回给所述用户端。

8.根据权利要求7所述的通信系统，其特征在于，

所述服务节点集群包含的每一服务节点按照预设的第一时间周期定时生成包含自身的调用方法及资源状态的状态消息并发送给所有所述服务节点；

每一所述服务节点接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法及资源状态；每个所述服务节点拥有一个所述可用服务节点池，用于保存接收到的服务节点的资源状态及调用方法；

所述第一服务节点根据服务节点集群中每一服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点包括：

所述第一服务节点根据拥有的所述可用服务节点池中保存的所有所述服务节点的资源状态，确定所述资源状态满足所述资源需求的所述服务节点为第二服务节点。

9.根据权利要求8所述的通信系统，其特征在于，所述系统还包含API网关，所述用户端还可用于将接收的请求发送至API网关，

所述API网关用于按照预先配置的负载均衡策略将所述请求转发给所述请求对应的第一服务节点；

所述第二服务节点还可用于接收并处理所述请求，生成处理结果并返回给所述第一服务节点；

所述第一服务节点还可用于接收并将所述处理结果返回给API网关；

所述API网关用于将所述处理结果发送给所述用户端。

10.根据权利要求8或9所述的通信系统，其特征在于，所述状态消息包含所述状态消息的发送时间：

所述服务节点还可用于接收并根据所述状态消息更新拥有的可用服务节点池中对应的服务节点的调用方法、资源状态及发送时间；

按照第二预设时间周期定时根据拥有的所述可用服务节点池包含的每一所述服务节点的发送时间，计算每一所述服务节点的失联时长，将失联时长超过预设阈值的所述服务节点从拥有的所述可用服务节点池中删除。

Images