CN109101334A - 一种面向Zuul网关的微服务并发控制方法 - Google Patents

Abstract

本发明提供了一种面向Zuul网关的微服务并发控制方法，具体而言，该方法包括：(1)在REST Body中定义微服务资源属性；(2)解析REST Body中的服务请求消息，并将所述服务请求消息多线程发送至并发控制模块；(3)所述并发控制模块对接收的多线程服务请求消息进行服务设备资源的重复检测和冲突检测，优化服务请求内容和执行顺序；(4)第二线程池分配线程执行优化后的服务请求。这种方法充分考虑了HTTP消息中封装的服务请求内容，当它们之间有重复或冲突时，可以按照优先级的设定标准按一定的顺序执行，并且重复的请求消息可以转化为一个服务请求，减少线程浪费、资源冲突和错误的发生。

Description

一种面向Zuul网关的微服务并发控制方法

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种面向Zuul网关的微服务并发控制领域。

背景技术

微服务是一些协同工作的小而自治的服务。它具有高内聚性和高自治性。微服务根据业务的边界来确定服务的边界。同时，它也是一个独立的实体，可以独立地部署在PaaS上，也可以作为一个操作系统进程存在。服务之间均通过网络调用进行通信，从而加强服务之间的隔离性，避免紧耦合。

微服务架构是一种架构模式，它将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互沟通。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。在微服务架构体系中，单体应用被切割成多个微服务，如果将所有的微服务直接对外暴露，势必会出现安全方面的各种问题，为了让调用更简单，一般会在这些服务前端再封装一层，即“API网关层”。API网关是一个服务，是系统的唯一入口。API网关封装了系统内部架构，为每个客户端提供一个定制的API。

Zuul是由Netflix开源的API网关，是一个基于JVM路由和服务端的负载均衡器，提供动态路由、监控、授权、安全、调度等边缘服务。作为微服务架构的不可或缺的一部分，Zuul网关主要提供以下几个功能：1)提供路由功能，可屏蔽内部服务细节，并可提供负载均衡；2)提供一套过滤器机制，在各阶段过滤请求和响应，提供对外的权限控制。可以实现签名校验、登录校验等与业务逻辑无关的操作；3)实现了断路器，不会因为具体微服务的故障而导致服务网关的阻塞，依然可以对外服务。

Zuul服务网关技术为基于微服务架构的平台提供了有效的微服务管理技术。然而，面向越来越多的实际应用，同时也呈现出新的特点：

第一，随着信息化的发展，应用系统的数量、规模和复杂度不断增长，不同的业务功能实现需要通过网关和多个微服务进行数据交互。而作为一个系统的后端总入口，网关承载着所有服务的组合路由转换等工作，除此之外，安全，限流，缓存，日志，监控，重试，熔断等也会放到网关来做。因此，网关要做的工作越来越多，越来越复杂。

第二，由于业务功能的多样化和细粒度化，应用和微服务之间的交互更复杂。同一个业务功能要调用多个不同的微服务，而同一个微服务可能被不同的业务调用和操作。例如，在淘宝中，查看一个订单详情，它包含订单信息、结算、商品、收货和物流信息等，这些数据对于后端来说可能是位于不同的微服务系统之中。反之，同一个商品信息会被分到不同的商品类别中进行查看操作。

随着互联网的快速发展，微服务中的资源共享程度大大增加，将对微服务的并发控制提出新的机遇和挑战。在过去几年里，微服务并没有有效地并发控制研究，主要有两个方面的原因。一方面，微服务请求在资源冲突发生不频繁的情况下，仅依赖成熟的健康检查和动态的负载均衡来解决微服务的并发控制，是可以满足基本需求的。另一方面，在遇到真实的流量远远大于系统测试下来的可承载流量时(比如，在双十一等大促过程中)，如果这些流量都进来，则整个系统一定垮掉，所以服务网关常采用的方式是资源缓存、限流等。例如，对于首页和活动页，是读取比较多的，可以返回缓存中的老的页面，或者App定时刷新。对于加入购物车、下单、支付等写入请求被限流的，会返回等待页面，如果过了一段时间还进不去目标页面，就会返回“挤爆了”。因此，随着信息化的发展和业务功能的多样化，针对面向Zuul网关的微服务并发控制方法，可以说，既有强烈的需求驱动又有具体的实施目标，是互联网上成功开发微服务系统不可避免的关键研究问题。

发明内容

本发明的目的在于提供一种面向Zuul网关的微服务并发控制方法，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

本发明提供一种面向Zuul网关的微服务并发控制方法，其特征在于：该方法包括如下步骤：在REST Body中定义微服务资源属性；解析REST Body中的服务请求消息，并将所述服务请求消息多线程发送至并发控制模块；所述并发控制模块对接收的多线程服务请求消息进行服务设备资源的重复检测和冲突检测，优化服务请求内容和执行顺序；第二线程池分配线程执行优化后的服务请求。

Zuul网关服务器在接收到服务请求后，第一线程池即分配线程用于处理HTTP消息的解析；而当并发控制模块接收到解析后的服务请求消息后，第二线程池分配线程执行具体的微服务。

在REST Body中定义微服务资源属性采用如下属性：

(1)MicroserviceID定义微服务资源ID；

(2)MicroserviceType定义微服务资源类型；

(3)MicroserviceList定义同属一个Zuul网关服务的微服务列表；

(4)MicroserviceURL定义微服务的访问地址；

(5)OperationName定义微服务资源的操作名称；

(6)OperationType定义微服务的操作类型；

(7)OperationInput定义微服务资源操作的输入变量；

(8)OperationOutput定义微服务资源操作的输出变量。

并发控制模块接收到解析的REST服务请求消息后，首先将解析的REST服务请求消息进行数学表示，然后利用重复检测方法进行重复检测并使用过滤器过滤掉重复的服务请求并送到冲突检测模块进行服务请求的冲突检测。

如果检测到服务请求存在重复，则并发控制模块分配相同的线程完成相应的重复的服务请求内容。

如果检测到冲突存在，则对冲突的服务请求赋予不同的优先级，所述优先级的设定依靠预先定义的执行顺序及场景；然后并发控制模块对标记优先级的请求进行排序并分配线程，进而执行响应的服务请求。

所述的重复检测是通过比较两个服务请求的MicroserviceURL、OperationName和OperationInput这三个属性来判断的：若这三个属性全部相同则表示这两个服务请求是重复的，若这三个属性中至少有一项不同，则表示这两个服务请求是不同的。

所述的冲突检测具体方法为：

(1)判断两个服务请求的MicroserviceList是否关联有相同的微服务资源；

(2)判断上述两个有关联的服务请求，它们所关联的某一相同的OperationType是否存在“操作”类型，若存在，则判定这两个服务请求是冲突的。

所述优先级的计算由静态优先级P_static计算和动态优先级P_dynamic计算组成。

静态优先级的计算采用如下公式：

P_static＝pY+qX

其中p+q＝1，p表示规则预定义优先级数值的权重，q表示执行时间对静态优先级的计算权重；Y表示预先设定的优先级取值，X表示一组冲突服务请求按照执行时间由长到短排序后在这个序列里的序号。

动态优先级是指优先级随服务请求在队列中的等待时间而动态变化，其计算公式为：

P_dynamic＝Z；

其中Z表示该冲突服务请求在按照一组冲突服务请求的等待时间从小到大排序产生的序列里的顺序值，改组冲突服务请求的等待时间是每隔固定时间更新的。

所述优先级的计算公式为：

P＝λP_static+γP_dynamic；

其中，λ+γ＝1，λ为静态优先级对整个优先级计算的权重，γ为动态优先级对整个优先级计算的权重，P为优先级。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出Zuul过滤器的生命周期；

图2示意性示出了传统的微服务并发控制流程；

图3示意性示出一种REST请求消息格式；

图4示意性示出微服务并发控制原理；

图5示意性示出一种并发控制模块结构；

图6示意性示出一种优先级计算中的规则描述语法和样例。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本发明将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本发明的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本发明的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本发明的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

作为API Gateway服务器，Zuul本质上是一个web servlet应用，相当于是设备和Netflix流应用的Web网站后端所有请求的前门。Zuul的核心是一系列的过滤器(filters),其作用可以类比Servlet框架的Filter，或者AOP。Zuul把HTTP请求路由到用户处理逻辑的过程中，这些filters参与一些过滤处理，比如授权、监控、负载均衡等。Zuul提供了一个框架，可以对过滤器进行动态的加载，编译，运行，其中定义了四种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期，如图1所示描述了各种类型的过滤器的执行顺序。

(1)PRE:这种过滤器在请求被路由之前调用，用来实现身份验证、在集群中选择请求的微服务、记录调试信息等。

(2)ROUTING：这种过滤器将请求路由到微服务，用于构建发送给微服务的请求，并使用Apache Http Client或Netfilx Ribbon请求微服务。

(3)POST：这种过滤器在路由到微服务以后执行，用来为响应添加标准的HTTPHeader、收集统计信息和指标、将响应从微服务发送给客户端等。

(4)ERROR：在其他阶段发生错误时执行该过滤器。

搭载微服务请求的HTTP消息经过Zuul网关服务器后调用微服务，线程池分配线程用以处理HTTP消息。首先经过HTTP解析得到搭载的REST消息，进一步进行XML解析，获得REST Body包含的服务请求内容，由Zuul网关实现身份验证、在集群中选择请求的微服务、构建发送给微服务的请求，由相应的微服务进行处理，经过上述相反过程对响应信息进行封装并返回给服务请求端。最后，线程释放该微服务请求实例并放回线程池以循环执行微服务请求。以上微服务并发控制核心在于：线程池维护确定数量的等待线程，每当有服务请求到达，线程池就分配一个线程为请求服务。为了运行这些线程，处理器为每个独立线程安排一些处理器时间，处理器以顺序轮换方式向线程提供时间片，实现多线程的并发处理。线程池的优势在于服务器运行之初一次性创建多个线程并循环使用，将线程创建开销分摊到多个任务上，避免了频繁创建、销毁线程带来的巨大资源开销，以及创建过多的线程耗尽系统资源。

由图2可知，Zuul网关服务器在收到服务请求时即分配线程进行响应，而具体的服务请求内容是在经过HTTP及XML解析后获得。传统的Zuul网关微服务并发控制方法缺陷就在于：线程的分配没有考虑HTTP消息中封装的服务请求内容，多个HTTP请求被分配独立的线程单独执行。如果当前的多个HTTP请求封装相同的服务请求或服务请求之间有冲突或执行优先级之分，有可能会造成线程浪费、资源冲突和错误的发生。以上面淘宝为例，用户A通过在商品页面请求微服务查看商品价格，管理用户B同时在订单界面请求微服务来修改商品价格。当用户A与用户B的请求同时到达时，目前的微服务并发控制方法是分配两个独立线程并随机执行微服务响应。但是，这两个服务请求是存在优先级之分的，用户B的请求应该优先用户A的请求执行，以避免用户A查询到的商品价格不是真实的价格。

因此，在传统的微服务并发控制基础上，本发明将在解析出RESTBody的内容后，在Zuul网关层设计新增相应的并发控制模型来实现微服务并发控制方法。

本发明首先将从REST协议入手，在REST Body中定义了微服务资源统一描述框架，从而为下一步的优先级计算和并发控制奠定基础。如表1所示，

表1，微服务资源属性定义

属性名	说明
		MicroserviceID	微服务资源ID
MicroserviceType	微服务资源类型
		MicroserviceList	同属一个Zuul网关服务的微服务列表
MicroserviceURL	微服务的访问地址
		OperationName	微服务资源的操作名称
OperationType	微服务资源的操作类型
		OperationInput	微服务资源操作的输入变量
OperationOutput	微服务资源操作的输出变量

采用上述八个属性对服务设备资源进行描述。其中，MicroserviceURL、OperationName和OperationInput、OperationOutput取自REST本身，另外定义了MicroserviceID、MicroserviceType、MicroserviceList和OperationType四个属性。Zuul网关服务依赖底层各个微服务，因此需要唯一的MicroserviceID来标识微服务资源，而业务功能的高度互联，同一微服务可能被多个应用调用，不同微服务资源也可以协同工作实现同一业务功能。因此采用MicroserviceList表示网关服务所关联的多个微服务资源，是一个由各微服务资源MicroserviceID组成的集合。OperationInput和OperationOutput分别是服务设备资源操作的输入输出，从服务IO中获取。例如，如图3所示，查询商品价格的服务请求可以按照微服务资源属性定义统一刻画。可以看出，由于REST是基于XML描述的，因此只要增加解析处理，自定义的设备属性标签<MicroserviceList>和<Operation>等可以很容易的嵌入REST。

如图4所示，在解析出REST Body内容后，我们建立了一个并发控制模块来实现Zuul网关微服务的并发控制。

与传统的Zuul网关微服务并发控制流程不同，该并发控制维护两个线程池。在解析出REST Body中的请求消息后，消息即被送到并发控制模块，此时先前的线程释放微服务请求实例并放回第一线程池。并发控制模块接收到多线程送来的微服务请求消息，根据一定的策略进行请求服务设备资源的重复和冲突检测，优化服务请求内容及其执行顺序，由第二线程池分配线程通过执行模块完成相应服务请求。通过并发控制模块，避免了线程浪费、资源冲突和错误的发生。

第一线程池主要负责解析微服务，因为用户的请求是不连续的；而第二线程池主要负责执行微服务，在执行之前，调用并发控制模块，对于冲突的服务请求进行优先级计算并协调，而对于重复的服务请求则分配单独的线程进行执行。

并发控制模块内部组成如图5所示：并发控制模块主要包括重复检测模块和冲突检测检测、优先级设定模块和执行模块。消息接收模块负责接收解析的REST服务请求消息，并将请求消息送到预处理模块。预处理模块用于将解析得到的信息进行数学表示。然后将预处理后的消息送到重复检测模块，利用重复检测方法进行重复检测并使用过滤器过滤掉重复的服务请求并送到冲突检测模块进行服务请求的冲突检测。若存在冲突，需要对冲突的服务请求赋予不同的优先级，优先级的设定依靠预先定义的规则及当前的场景。请求消息处理模块对标记优先级的请求进行排序并分配线程，进一步地，使用寻址模块通过消息发送模块执行服务请求。

Zuul微服务并发控制的出发点是避免请求的重复与冲突。若服务请求存在重复，则可以使用相同的线程完成相应请求内容；若服务请求存在冲突，则需要对冲突的服务请求线程赋予不同的优先级。下面首先将重复和冲突检测中用到的服务设备资源进行相应的数学定义和描述，接着给出具体的检测计算方法。

Zuul网关服务器收到REST请求后将通过解析获得各个具体属性的取值。S服务的微服务资源列表MicroserviceList可定义为ML(S)＝{MI₁,MI₂,…,MI_N}，其中MI_i为微服务编号，i∈自然数集合。微服务资源MI的操作类型可定义为OT(MI)＝{OM₁,…,OM_q}。其中OM₁定义的查询操作为客户端发送请求并需要等待服务器端的响应，而OM₂定义的操作则为客户端发送请求后除了确认信息外并不需要服务器端返回其他信息。由于目前支持的仅有查询(query)和操作(do)两种操作类型，因此OM₁＝’query’，OM₂＝’do’，即q＝1，2。S服务的访问地址URL可定义为URL(S)＝l，其中l为字符串变量。同理，微服务资源MI的操作名称OperationName可定义为ON(MI)＝p，其中p为字符串变量。微服务资源操作的输入OperationInput可定义为OI(MI)＝{OM₁,OM₂,…,OM_M}，其中OM_i为输入变量，i为自然数集合。

服务请求的重复检测需要通过比较两个服务请求的访问地址URL、OperationName和OperationInput来判断，若全部相同则表示两个服务请求是重复的，若至少有一项不同，则两个服务请求是不同的。假设有两个服务请求M₁和M₂同时到达，通过解析我们可以得到R₁的服务访问地址为M₁.URL(S₁)，微服务资源的操作名称OperationName为M₁.ON(MI₁)，服务资源的操作输入OperationInput为M₁.OI(MI₁)，同样M₂的服务访问地址为M₂.URL(S₂)，OperationName为M₂.ON(MI₂)，OperationInput为M₂.OI(MI₂)，则判断服务请求重复的条件表达式为：

M₁.URL(S₁)＝M₂.URL(S₂)∧M₁.ON(MI₁)＝M₂.ON(MI₂)∧M₁.OI(MI₁)＝M₂.OI(MI₂)

服务请求的冲突检测不仅涉及两个请求关联的微服务是否有重复，而且依赖服务请求对微服务资源的操作类型。同样假设有两个服务请求M₁，M₂，关联的微服务资源列表分别表示为M₁.ML(S₁)，M₂.ML(S₂)，首先服务请求存在冲突的前提条件为 即两个服务请求M₁，M₂关联有相同的微服务资源，因此存在冲突的可能。其次，服务请求M₁，M₂对其关联的相同微服务的不同操作类型决定了冲突是否存在。判断依据如下：若M₁，M₂对其关联的某一相同微服务操作类型同为查询，则不存在冲突；若M₁(M₂)为查询、M₂(M₁)为操作或M₁，M₂同为操作则存在冲突，判断条件为：if(！(M₁.OT(MI_i)＝＝M₂.OT(MI_i)＝＝{OT₁}))then conflict＝true，其中MI_i∈ML(S)。

对于检测到服务请求冲突的情况，需要对其进行优先级计算，并对冲突的服务请求赋予不同的优先级。与其他优先级计算方法不同的是，本方法中优先级计算由静态优先级计算和动态优先级计算两部分组成，其中静态优先级的计算又综合考虑了规则和场景两个因素，从而实现了上下文感知和动静结合两大特色功能。

静态优先级是指优先级的计算值将不随时间变化而改变，主要考虑利用预先定义的规则和场景计算服务请求的优先级。我们采用CFA规则(事件-条件-动作)来预先指定部分可能冲突的优先级，其中C刻画触发该规则的冲突事件，F刻画规则条件中包含的服务请求，A设定冲突服务请求的优先级。该规则描述语法和样例如图6所示，当有两个服务请求M₁，M₂到达，且M₁，M₂均对MI₁表示的摄像头进行了操作，由冲突检测可知服务请求M₁，M₂冲突，由此触发规则r1。规则条件部分表示当M₁的操作名称为“turn to east”，而M₂的操作名称为“turn to south”，在规则的动作部分，我们设定M₁的优先级为10，高于M₂的优先级，其中优先级值∈自然数集合N。事实上，在微服务中，某个服务请求可能在一个场景下优先级较低，但在另一场景下优先级最高。因此，在规则定义中引入当前场景使得优先级的设定更加准确。

前面提到，目前支持的微服务资源操作类型仅有查询(query)和操作(do)两种，冲突检测依据的也是不同服务请求对微服务资源的操作类型。假设有两个服务请求M₁，M₂，对于服务请求冲突的一种情况，即对服务设备资源的操作类型M₁(M₂)为查询、M₂(M₁)为操作，表示为：M₁.OT(MI)＝＝{OT₁}，且M₂.OT(MI)＝＝{OT₂}，我们利用规则设定操作的优先级永远高于查询的优先级，即do.Priority>query.Priority；对于服务请求冲突的另一种情况，即对微服务资源的操作类型M₁，M₂均为操作，表示为：M₁.OT(MI)＝＝M₂.OT(MI)＝＝{OT₂}，优先级的计算仅使用规则是不够的，还需要综合静态优先级和动态优先级。

从规则中，我们可以直接得到预先设定的优先级取值，表示为Y。由于CFA规则和场景是预先定义的，因此无法考虑服务执行时间对静态优先级的影响。若有一组冲突的服务请求M₁，M₂，….，M_N，按执行时间由长到短排序，可以得到一组序列MT＝{1,2,…N}。假设冲突服务请求MS(1≤S≤N)在MT序列中的序号为X(1≤X≤N)，则静态优先级计算公式可表示为：P_static＝pY+qX，(p+q＝1)。其中，p表示规则预定义优先级数值的权重，而q表示执行时间对静态优先级的计算权重。

动态优先级是指优先级随服务请求在队列中的等待时间而动态变化，即随等待时间增加优先级逐渐提升。系统通过不断更新服务的等待时间，按从小到大顺序产生一组等待时间序列MW＝{1,2,…N}。与执行时间序列不同的是MW是每隔固定间隔更新的。假设冲突服务请求MS(1≤S≤N)在MW序列中的序号为Z(1≤Z≤N)，则动态优先级计算公式为：P_dynamic＝Z。

综合考虑静态和动态优先级，我们得到统一的优先级计算公式：

P＝λP_static+γP_dynamic，(λ+γ＝1)，其中λ，γ分别为静态和动态优先级的对整个优先级计算的权重。

服务请求存在重复和冲突两种情况。并发控制模型需要对这两种情况设定不同的策略。对于服务请求重复的情况，可以通过共用进程来减少不必要的线程使用，具体通过过滤器将重复的服务请求转化为一个服务请求，然后第二线程池分配线程，执行完毕后将响应结果返回给重复服务请求组内的每一个源地址。对于服务请求冲突的情况，按照我们提出的优先级计算公式，对冲突的服务请求赋予不同优先级，按优先级先后顺序执行。总之，并发控制模块收到一系列服务请求后首先将会对其进行排序。排序整体按照先来先服务的原则，但对于存在冲突的服务请求按照优先级高低顺序。之后服务请求被依次放入执行队列，通过寻址模块由第二线程池分配线程执行服务请求。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (10)

1.一种面向Zuul网关的微服务并发控制方法，Zuul网关服务器在接收到服务请求后，第一线程池即分配线程用于处理HTTP消息的解析，而当并发控制模块接收到解析后的服务请求消息后，第二线程池分配线程执行具体的微服务，其特征在于：该方法还包括如下步骤：

(1)在REST Body中定义微服务资源属性；

(2)解析REST Body中的服务请求消息，并将所述服务请求消息多线程发送至并发控制模块；

(3)所述并发控制模块对接收的多线程服务请求消息进行服务设备资源的重复检测和冲突检测，优化服务请求内容和执行顺序；

(4)第二线程池分配线程执行优化后的服务请求。

2.根据权利要求1所述的方法，其特征在于：所述步骤(1)中定义微服务资源属性采用如下属性：

(1)MicroserviceID定义微服务资源ID；

(2)MicroserviceType定义微服务资源类型；

(3)MicroserviceList定义同属一个Zuul网关服务的微服务列表；

(4)MicroserviceURL定义微服务的访问地址；

(5)OperationName定义微服务资源的操作名称；

(6)OperationType定义微服务的操作类型；

(7)OperationInput定义微服务资源操作的输入变量；

(8)OperationOutput定义微服务资源操作的输出变量。

3.根据权利要求1-2中任一项所述的方法，其特征在于：并发控制模块接收到解析的REST服务请求消息后，首先将解析的REST服务请求消息进行数学表示，然后利用重复检测方法进行重复检测并使用过滤器过滤掉重复的服务请求并送到冲突检测模块进行服务请求的冲突检测。

4.根据权利要求3所述的方法，其特征在于：如果检测到服务请求存在重复，则并发控制模块分配相同的线程完成相应的重复的服务请求内容。

5.根据权利要求3所述的方法，其特征在于：如果检测到冲突存在，则对冲突的服务请求赋予不同的优先级，所述优先级的设定依靠预先定义的执行顺序及场景；然后并发控制模块对标记优先级的请求进行排序并分配线程，进而执行响应的服务请求。

6.根据权利要求4所述的方法，其特征在于：所述的重复检测是通过比较两个服务请求的MicroserviceURL、OperationName和OperationInput这三个属性来判断的：若这三个属性全部相同则表示这两个服务请求是重复的，若这三个属性中至少有一项不同，则表示这两个服务请求是不同的。

7.根据权利要求5所述的方法，其特征在于：所述的冲突检测具体方法为：

(1)判断两个服务请求的MicroserviceList是否关联有相同的微服务资源；

(2)判断上述两个有关联的服务请求，它们所关联的某一相同的OperationType是否存在“操作”类型，若存在，则判定这两个服务请求是冲突的。

8.根据权利要求5或7所述的方法，其特征在于：所述优先级的计算由静态优先级P_static计算和动态优先级P_dynamic计算组成；

静态优先级的计算采用如下公式：

P_static＝pY+qX

其中p+q＝1，p表示规则预定义优先级数值的权重，q表示执行时间对静态优先级的计算权重；Y表示预先设定的优先级取值，X表示一组冲突服务请求按照执行时间由长到短排序后在这个序列里的序号。

9.根据权利要求8所述的方法，其特征在于：动态优先级是指优先级随服务请求在队列中的等待时间而动态变化，其计算公式为：

P_dynamic＝Z；

其中Z表示该冲突服务请求在按照一组冲突服务请求的等待时间从小到大排序产生的序列里的顺序值，改组冲突服务请求的等待时间是每隔固定时间更新的。

10.根据权利要求8-9中任一项所述的方法，其特征在于：所述优先级的计算公式为：

P＝λP_static+γP_dynamic；

其中，λ+γ＝1，λ为静态优先级对整个优先级计算的权重，γ为动态优先级对整个优先级计算的权重，P为优先级。