一种微服务请求处理方法、微服务控制器及微服务架构与流程

本发明涉及微服务架构领域，更具体地说，涉及一种微服务请求处理方法、微服务控制器及微服务架构。

背景技术：

微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。目前，随着微服务架构的发展、企业应用越来越多把功能集中的且运行在同一个应用中的单体架构拆分成多个相互独立的微服务架构后，虽然可以降低一损俱损的全局性故障风险，但由于微服务之间存在大量的依赖关系，而且每个微服务都可能发生故障，如果某一微服务发生故障后，该微服务的请求一直不能处理，导致请求堵塞，并且用户也收不到响应信息，降低用户体验。因此，如何确保系统自动把发生故障的微服务排除出去，提高用户体验，是本领域技术人员需要解决的问题。

技术实现要素：

本发明的目的在于提供一种微服务请求处理方法、微服务控制器及微服务架构，以实现确保系统自动把发生故障的微服务排除出去，提高微服务构架的安全性，提高用户体验。

为实现上述目的，本发明实施例提供了如下技术方案：

一种微服务请求处理方法，包括：

接收用户发送的微服务请求；

将所述微服务请求发送至微服务消息队列；

向所述用户发送成功响应信息。

其中，所述将所述微服务请求发送至微服务消息队列之后，还包括：

判断与所述微服务请求对应的微服务是否为关键性微服务；

若否，则执行所述向所述用户发送成功响应信息的步骤。

其中，所述接收用户发送的微服务请求之前，还包括：

实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务；

则将所述微服务请求发送至微服务消息队列之后，还包括：

判断与所述微服务请求对应的微服务是否为故障微服务；若是，则执行所述向所述用户发送成功响应信息的步骤。

其中，所述实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务包括：

实时检测每个微服务请求的请求时长是否大于预定时长阈值；

若是，则将请求时长大于预定阈值的微服务作为所述故障微服务。

其中，所述实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务包括：

实时检测是否存在服务失败次数大于预定次数阈值的微服务；

若存在，则将服务失败次数大于预定次数阈值的微服务作为所述故障微服务。

其中，所述实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务包括：

实时检测每个微服务内是否存在可用节点；

将不存在可用节点的微服务作为所述故障微服务。

一种微服务控制器，包括：

接收模块，用于接收用户发送的微服务请求；

微服务请求发送模块，用于将所述微服务请求发送至微服务消息队列；

响应信息发送模块，用于向所述用户发送成功响应信息。

其中，还包括：

第一判断模块，用于将所述微服务请求发送至微服务消息队列之后，判断与所述微服务请求对应的微服务是否为关键性微服务；

所述响应信息发送模块，用于与所述微服务请求对应的微服务不为关键性微服务时，向所述用户发送成功响应信息。

其中，还包括：

检测模块，用于接收用户发送的微服务请求之前，实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务；

第二判断模块，用于将所述微服务请求发送至微服务消息队列之后，判断与所述微服务请求对应的微服务是否为故障微服务；

所述响应信息发送模块，用于与所述微服务请求对应的微服务为故障微服务时，向所述用户发送成功响应信息。

一种微服务架构，包括上述任意微服务控制器。

通过以上方案可知，本发明实施例提供的一种微服务请求处理方法，包括：接收用户发送的微服务请求；将所述微服务请求发送至微服务消息队列；向所述用户发送成功响应信息；可见，在本方案中，微服务控制器接收到用户发送的微服务请求时，将该微服务请求直接发送至微服务队列，以使微服务队列通过异步调用机制处理微服务请求，并直接向该用户回复成功响应信息，以防由于某一微服务不能成功处理请求时，可自动的向用户发送成功响应信息，使系统自动把发生故障的微服务排除出去，提高微服务构架的安全性，提高用户体验；本发明还公开了一种微服务控制器及微服务架构，同样能实现上述技术效果。

附图说明

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

图1为本发明实施例公开的一种微服务请求处理方法流程示意图；

图2为本发明实施例公开的一种微服务架构结构示意图；

图3为本发明实施例公开的一种微服务控制器结构示意图。

具体实施方式

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

本发明实施例公开了一种微服务请求处理方法、微服务控制器及微服务架构，以实现确保系统自动把发生故障的微服务排除出去，提高微服务构架的安全性，提高用户体验。

参见图1，本发明实施例提供的一种微服务请求处理方法，包括：

S101、接收用户发送的微服务请求；

S102、将所述微服务请求发送至微服务消息队列；

具体的，本方案中接收到用户发送的微服务请求后，将请求发送至微服务消息队列，通过该消息队列采用异步调用机制处理该请求，防止微服务请求出现堵塞现象。

S103、向所述用户发送成功响应信息。

具体的，对于微服务架构，用户发送大量的微服务请求User request访问服务，该服务依赖4个微服务的协作完成，通过微服务控制器Service把请求信息发送至消息队列，参见图2，假设ServiceB出现故障，而这个ServiceB不是关键性的，运行失败也可以继续进行，比如用户注册需要调用一个服务发送注册成功的邮件给用户，如果发邮件的这个service不可用，但不会影响用户注册，所以用户注册还是会成功的，邮件可以等服务恢复后再发送，只是时间上的延迟，因此，在本方案中，将微服务请求发送至消息队列后，直接向用户发送成功响应信息，使系统自动把发生故障的微服务排除出去，提高微服务构架的安全性，提高用户体验。

基于上述实施例，在本实施例中，所述将所述微服务请求发送至微服务消息队列之后，还包括：

判断与所述微服务请求对应的微服务是否为关键性微服务；

若否，则执行所述向所述用户发送成功响应信息的步骤。

具体的，在本实施例中，向用户发送成功响应信息之前，可判断用户发送的访问请求所对应的微服务是否为关键性微服务，若不是，则发送成功响应的步骤。需要说明的是，与访问请求所对应的微服务有可能为多个，若该多个微服务中存在关键性微服务，则代表该请求很重要，因此，可不直接向用户发送成功响应信息，等到该请求全部执行结束后再发送成功响应信息，提高用户体验。

基于上述实施例，在本实施例中，所述接收用户发送的微服务请求之前，还包括：

实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务；

则将所述微服务请求发送至微服务消息队列之后，还包括：

判断与所述微服务请求对应的微服务是否为故障微服务；若是，则执行所述向所述用户发送成功响应信息的步骤。

具体的，在本实施例中，向用户发送成功响应信息之前，微服务控制器可实时检测是否存在出现故障的微服务，并将出现故障的微服务标记为故障微服务；这时若接收到用户发送的微服务请求，可查看该请求中是否存在出现故障的微服务，若存在，则可直接执行向所述用户发送成功响应信息的步骤，若不存在，则可以等到成功响应该请求后再发送成功响应信息，提高用户体验。

其中，所述实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务包括：

实时检测每个微服务请求的请求时长是否大于预定时长阈值；

若是，则将请求时长大于预定阈值的微服务作为所述故障微服务。

具体的，在本实施例中，在判定故障微服务时，若某一访问请求的访问时长大于预定阈值，则说明在响应该访问请求时，对应的微服务出现了故障，因此在本实施例中，当检测到存在访问请求的请求时长大于预定时长阈值时，则判定与该访问请求对应的微服务为故障微服务。

需要说明的是，本实施例中的访问请求的请求时长，可以是正在访问某微服务的请求时长，例如：访问请求访问微服务A时，通过计时器开始计时，若该计时时长大于预设时长阈值，则判定微服务A出现故障，因此，将微服务A作为故障微服务；本实施例中的访问请求的请求时长同样也可以是已经结束访问的请求时长，例如：访问请求访问微服务B时，对该访问从开始访问至访问结束进行计时，若该访问时长大于预定时长阈值，则将微服务B作为故障微服务。但是，为了避免某一微服务由于非故障原因导致出现超时情况，可对每个微服务的超时次数进行统计，当统计次数大于次数阈值时，再将该微服务作为故障微服务。

其中，所述实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务包括：

实时检测是否存在服务失败次数大于预定次数阈值的微服务；

若存在，则将服务失败次数大于预定次数阈值的微服务作为所述故障微服务。

具体的，本实施例中的服务失败次数可以为预定时长内某微服务出现的失败次数，也可以是同一访问请求访问同一微服务出现失败的次数，在此并不限定；当某一微服务累积的服务失败次数大于预定次数阈值时，代表该微服务成功处理访问请求的概率变低，很可能出现故障，因此将服务失败次数大于预定次数阈值的微服务作为故障微服务。

其中，所述实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务包括：

实时检测每个微服务内是否存在可用节点；

将不存在可用节点的微服务作为所述故障微服务。

具体的，在本实施例中的每个微服务可能存在多个节点，若该微服务中不存在可用节点时，则代表该微服务已经没有能力响应访问请求，因此，在本实施例中，若检测到某微服务不存在可用节点，则将该微服务作为故障微服务。需要说明的是，在上述实施例中，提供了三种判定故障微服务的方法，即：通过访问时长、服务失败次数和可用节点数量进行判定，微服务控制器可同时执行这三种判定方法，也可以执行任意一者或者任意两者，在此并不具体限定。

下面对本发明实施例提供的微服务控制器进行介绍，下文描述的微服务控制器与上文描述的微服务请求处理方法可以相互参照。

参见图3，本发明实施例提供的一种微服务控制器，包括：

接收模块100，用于接收用户发送的微服务请求；

微服务请求发送模块200，用于将所述微服务请求发送至微服务消息队列；

响应信息发送模块300，用于向所述用户发送成功响应信息。

基于上述实施例，本实施例还包括：

第一判断模块，用于将所述微服务请求发送至微服务消息队列之后，判断与所述微服务请求对应的微服务是否为关键性微服务；

所述响应信息发送模块，用于与所述微服务请求对应的微服务不为关键性微服务时，向所述用户发送成功响应信息。

基于上述实施例，本实施例还包括：

检测模块，用于接收用户发送的微服务请求之前，实时检测每个微服务是否满足预设故障条件，将满足故障条件的微服务作为故障微服务；

第二判断模块，用于将所述微服务请求发送至微服务消息队列之后，判断与所述微服务请求对应的微服务是否为故障微服务；

所述响应信息发送模块，用于与所述微服务请求对应的微服务为故障微服务时，向所述用户发送成功响应信息。

本发明实施例提供一种微服务架构，包括上述任意实施例所述的微服务控制器。

本发明实施例提供的一种微服务请求处理方法，包括：接收用户发送的微服务请求；将所述微服务请求发送至微服务消息队列；向所述用户发送成功响应信息；可见，在本方案中，微服务控制器接收到用户发送的微服务请求时，将该微服务请求直接发送至微服务队列，以使微服务队列通过异步调用机制处理微服务请求，并直接向该用户回复成功响应信息，以防由于某一微服务不能成功处理请求时，可自动的向用户发送成功响应信息，使系统自动把发生故障的微服务排除出去，提高微服务构架的安全性，提高用户体验；本发明还公开了一种微服务控制器及微服务架构，同样能实现上述技术效果。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。