CN108055322B - 请求消息处理方法及装置 - Google Patents

Abstract

本发明实施例提供一种请求消息处理方法及装置，该方法包括：网关接收客户端发送的请求消息；网关确定请求消息对应的第一应用程序编程接口API；网关根据预设的发布方案中当前执行的发布步骤确定第一API的运行状态，运行状态包括发布状态和未发布状态，发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；网关根据第一API的运行状态，确定目标服务实例，其中，目标服务实例加载的API的版本与第一API的运行状态对应；网关向目标服务实例发送请求消息，以使目标服务实例根据其加载的第一API处理请求消息。用于提高服务发布的效率。

Description

请求消息处理方法及装置

技术领域

本发明实施例涉及通信技术领域，尤其涉及一种请求消息处理方法及装置。

背景技术

目前，客户端/服务器(Client/Server，简称CS)架构中，通常由服务器向客户端提供服务，在实际应用过程中，对于服务器提供的服务，还可以发布新的版本，以升级服务器提供的服务。

在现有技术中，在确定服务的新版本之后，为了保证服务版本的稳定过度，通常先向一部分用户发布服务的新版本，另一部分用户依然使用服务的旧版本。即，在网关接收到用户发送的请求消息之后，根据用户的标识，将请求消息转发给新版本的服务实例或者旧版本的服务实例，其中，一个服务服务实例通常包括多个应用程序编程接口(ApplicationProgramming Interface，简称API)，新版本的服务实例加载的API为新版本的API，旧版本的服务实例加载的API为旧版本的API。

然而，在现有技术中，在通过新版本的服务实例向用户提供服务的过程中若出现故障，则无法定位新的服务实例出现故障的API，使得整个服务发布失败，导致服务发布的效率低下。

发明内容

本发明实施例提供一种请求消息处理方法及装置，提高了服务发布的效率。

第一方面，本发明实施例提供一种请求消息处理方法，包括：

网关接收客户端发送的请求消息；

所述网关确定所述请求消息对应的第一应用程序编程接口API；

所述网关根据预设的发布方案中当前执行的发布步骤确定所述第一API的运行状态，所述运行状态包括发布状态和未发布状态，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；

所述网关根据所述第一API的运行状态，确定所述目标服务实例，其中，所述目标服务实例加载的API的版本与所述第一API的运行状态对应；

所述网关向所述目标服务实例发送所述请求消息，以使所述目标服务实例根据其加载的所述第一API处理所述请求消息。

在一种可能的实施方式中，所述网关确定所述请求消息对应的第一API，包括：

所述网关判断所述请求消息中是否包括API标识；

若是，则所述网关将所述API标识对应的API确定为所述第一API；

若否，则所述网关获取第一对应关系和所述请求消息的类型，并根据所述第一对应关系和所述请求消息的类型确定所述第一API，所述第一对应关系中包括至少一个API的标识、及每一个API的标识对应的请求消息的类型。

在另一种可能的实施方式中，所述网关根据预设的发布方案中当前执行的发布步骤确定所述第一API的运行状态，包括：

所述网关在所述网关的内部缓存中获取处于发布状态的API的标识；

所述网关判断所述第一API的标识和所述内部缓存中的API标识是否相同；

若是，则所述网关确定所述第一API的运行状态为发布状态；

若否，则所述网关确定所述第一API的运行状态为未发布状态。

在另一种可能的实施方式中，所述内部缓存包括主缓存和从缓存；所述网关在所述网关的内部缓存中获取处于发布状态的API的标识，包括：

所述网关获取所述主缓存和所述从缓存的处理状态，所述处理状态包括有效状态和无效状态；其中，在同一时刻，所述主缓存和所述从缓存中存在一个缓存的处理状态为有效状态，另一个缓存的处理状态为无效状态；

所述网关在有效状态的缓存中获取所述处于发布状态的API的标识。

在另一种可能的实施方式中，所述网关在有效状态的缓存中获取所述处于发布状态的API的标识之前，还包括：

所述网关接收第一服务器发送的、所述处于发布状态的API的标识；

所述网关在所述无效状态的缓存中存储所述处于发布状态的API的标识；

所述网关更换所述主缓存和所述从缓存的处理状态。

在另一种可能的实施方式中，所述网关根据所述第一API的运行状态，确定所述目标服务实例，包括：

所述网关判断所述第一API的运行状态是否为发布状态；

若是，则所述网关根据外部缓存中的第二对应关系和所述第一API的标识，确定所述目标服务实例，所述第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识；

若否，则所述网关将默认服务实例确定为所述目标服务实例，所述默认服务实例为未加载最新版本API的服务实例。

在另一种可能的实施方式中，所述网关向所述目标服务实例发送所述请求消息，包括：

若所述第一API为未发布状态，则在所述网关的内部缓存中获取默认路径信息，并根据所述默认路径信息，向所述目标服务实例发送所述请求消息，所述默认路径信息为默认服务实例的路径信息，所述默认服务实例为未加载最新版本API的服务实例；

若所述第一API为发布状态，则向注册中心请求获取所述目标服务实例的路径信息，并根据所述目标服务实例的路径信息，向所述目标服务实例发送所述请求消息。

在另一种可能的实施方式中，所述方法还包括：

所述网关接收所述目标服务实例发送的响应消息；

所述网关在所述响应消息中添加所述第一API的标识；

所述网关向所述客户端发送包括所述第一API的标识的响应消息，以使所述客户端在下一次发送请求消息时，携带所述第一API的标识。

第二方面，本发明实施例提供一种请求消息处理方法，包括：

第一服务器确定发布方案中当前执行的第一发布步骤、在所述第一发布步骤中发布的应用程序编程接口API，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；

所述第一服务器向网关发送所述API的标识，以使所述网关在所述网关的内部缓存中存储所述API的标识。

在另一种可能的实施方式中，所述方法还包括：

所述第一服务器根据所述发布方案确定第二对应关系，所述第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识；

所述第一服务器在外部缓存中存储所述第二对应关系。

第三方面，本发明实施例提供一种请求消息处理装置，包括接收模块、第一确定模块、第二确定模块、第三确定模块和发送模块，其中，

所述接收模块用于，接收客户端发送的请求消息；

所述第一确定模块用于，确定所述请求消息对应的第一应用程序编程接口API；

所述第二确定模块用于，根据预设的发布方案中当前执行的发布步骤确定所述第一API的运行状态，所述运行状态包括发布状态和未发布状态，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；

所述第三确定模块用于，根据所述第一API的运行状态，确定所述目标服务实例，其中，所述目标服务实例加载的API的版本与所述第一API的运行状态对应；

所述发送模块用于，向所述目标服务实例发送所述请求消息，以使所述目标服务实例根据其加载的所述第一API处理所述请求消息。

在一种可能的实施方式中，所述第一确定模块具体用于：

判断所述请求消息中是否包括API标识；

若是，则将所述API标识对应的API确定为所述第一API；

若否，则获取第一对应关系和所述请求消息的类型，并根据所述第一对应关系和所述请求消息的类型确定所述第一API，所述第一对应关系中包括至少一个API的标识、及每一个API的标识对应的请求消息的类型。

在另一种可能的实施方式中，第二确定模块具体用于：

在所述网关的内部缓存中获取处于发布状态的API的标识；

判断所述第一API的标识和所述内部缓存中的API标识是否相同；

若是，则确定所述第一API的运行状态为发布状态；

若否，则确定所述第一API的运行状态为未发布状态。

在另一种可能的实施方式中，所述内部缓存包括主缓存和从缓存；第二确定模块具体用于：

获取所述主缓存和所述从缓存的处理状态，所述处理状态包括有效状态和无效状态；其中，在同一时刻，所述主缓存和所述从缓存中存在一个缓存的处理状态为有效状态，另一个缓存的处理状态为无效状态；

在有效状态的缓存中获取所述处于发布状态的API的标识。

在另一种可能的实施方式中，所述装置还包括存储模块和更换模块，其中，

所述接收模块还用于，在所述第二确定模块在有效状态的缓存中获取所述处于发布状态的API的标识之前，接收第一服务器发送的、所述处于发布状态的API的标识；

所述存储模块用于，在所述无效状态的缓存中存储所述处于发布状态的API的标识；

所述更换模块用于，更换所述主缓存和所述从缓存的处理状态。

在另一种可能的实施方式中，第三确定模块具体用于：

判断所述第一API的运行状态是否为发布状态；

若是，则根据外部缓存中的第二对应关系和所述第一API的标识，确定所述目标服务实例，所述第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识；

若否，则将默认服务实例确定为所述目标服务实例，所述默认服务实例为未加载最新版本API的服务实例。

在另一种可能的实施方式中，所述发送模块具体用于：

若所述第一API为未发布状态，则在所述网关的内部缓存中获取默认路径信息，并根据所述默认路径信息，向所述目标服务实例发送所述请求消息，所述默认路径信息为默认服务实例的路径信息，所述默认服务实例为未加载最新版本API的服务实例；

若所述第一API为发布状态，则向注册中心请求获取所述目标服务实例的路径信息，并根据所述目标服务实例的路径信息，向所述目标服务实例发送所述请求消息。

在另一种可能的实施方式中，所述装置还包括添加模块，其中，

所述接收模块还用于，接收所述目标服务实例发送的响应消息；

所述添加模块用于，在所述响应消息中添加所述第一API的标识；

所述发送模块还用于，向所述客户端发送包括所述第一API的标识的响应消息，以使所述客户端在下一次发送请求消息时，携带所述第一API的标识。

第四方面，本发明实施例提供一种请求消息处理装置，包括第一确定模块和发送模块，其中，

所述第一确定模块用于，确定发布方案中当前执行的第一发布步骤、在所述第一发布步骤中发布的应用程序编程接口API，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；

所述发送模块用于，向网关发送所述API的标识，以使所述网关在所述网关的内部缓存中存储所述API的标识。

在一种可能的实施方式中，所述装置还包括第二确定模块和存储模块，其中，

所述第二确定模块用于，根据所述发布方案确定第二对应关系，所述第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识；

所述存储模块用于，在外部缓存中存储所述第二对应关系。

本发明实施例提供的请求消息处理方法及装置，预先制定的发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识，每一个发布步骤对应一个最新版本的API，即，进行服务发布时，在每一个发布步骤中仅发布一个最新版本的API。相应的，在网关接收到客户端发送的请求消息之后，获取客户端对应的第一API，并根据第一API的运行状态确定目标服务实例，目标服务实例加载的第一API的版本与第一API的运行状态对应，例如，当第一API为发布状态时，则确定得到目标服务实例加载的API的版本为最新版本，当第一API为未发布状态时，则确定得到的目标服务实例加载的API的版本不是最新版本，这样，可以实现在不同的发布步骤中将不同的最新版本的API发布至对应的客户端。在上述过程中，在进行服务发布时，按照API的粒度进行发布，减小了服务发布粒度，这样，在服务发布的过程若出现故障，可以及时定位出现故障的API，进而提高服务发布的效率。

附图说明

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

图1为本发明实施例提供的请求消息处理方法的架构图；

图2为本发明实施例提供的请求消息处理方法的示意图一；

图3为本发明实施例提供的请求消息处理方法的示意图二；

图4为本发明实施例提供的一种请求消息处理装置的结构示意图一；

图5为本发明实施例提供的一种请求消息处理装置的结构示意图二；

图6为本发明实施例提供的另一种请求消息处理装置的结构示意图一；

图7为本发明实施例提供的另一种请求消息处理装置的结构示意图二。

具体实施方式

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

图1为本发明实施例提供的请求消息处理方法的架构图。请参见图1，包括客户端101、网关102、服务集群103、第一服务器104、容器管理服务器105、外部缓存106和注册中心107。

客户端101可以为手机、电脑等设备，客户端101可以通过网关102向服务集群103发送请求消息，并通过网关102接收服务集群103发送的响应消息。

网关102中设置有内部缓存，内部缓存中存储有处于发布状态的API的标识和默认路径信息。第一服务器104可以根据发布方案中当前正在执行的发布步骤确定处于发布状态的API，并更新内部缓存中处于发布状态的API的标识。默认路径信息是指默认服务实例的路径信息，默认服务实例是指没有加载最新版本的API的服务实例。当然，内部缓存中还可以存储每一个API的运行状态，API的运行状态包括发布状态和未发布状态。

在服务集群103中包括多个服务实例，每一个服务实例均可以通过网关102向客户端102提供服务。第一服务器104可以根据发布方案中当前正在执行的发布步骤控制容器管理服务器105进行服务实例部署。

第一服务器104中加载有发布方案，发布方案用于指示发布服务中的API的发布步骤、以及发布步骤之间的切换条件，每一个发布步骤指示向预设用户群发布一个API。例如，发布方案的第一发布步骤可以为向第一用户群发布API1，在第一发布步骤执行一天之后，执行发布方案的第二发布步骤，发布方案的第二发布步骤可以为向第二用户群发布API2。

容器管理服务器105可以在第一服务器104的控制下进行服务实例的部署。例如，在不同的发布步骤下，容器管理服务器105部署的服务实例的个数可能不同。

外部缓存106中包括API的标识和服务实例的标识之间的对应关系。可选的，可以在初始化的过程中，由第一服务器104将该对应关系存储至外部缓存106中。

注册中心107中包括服务实例的路径信息。可选的，注册中心107中可以仅包括加载了最新版本的API的服务实例的路径信息，即，注册中心107中可以不包括默认服务实例的路径信息。

在本申请中，发布方案中包括多个发布步骤，每一个发布步骤指示向预设用户群发布一个最新版本的API，即，进行服务发布时，在不同的时段发布不同的API。相应的，在网关接收到客户端发送的请求消息之后，可以根据发布方案中当前正在执行的发布步骤，确定将该请求消息转发至的目标服务实例，例如，假设客户端对应第一API，在接收到客户端发送的请求消息之后，当第一API处于未发布状态时，则将该请求消息转发至加载旧版本的第一API的服务实例，当第一API处于发布状态时，则将该请求消息转发至加载新版本的第一API的服务实例，以实现在不同时段将不同的最新版本的API发布至对应的客户端。在上述过程中，在进行服务发布时，按照API的粒度进行发布，减小了服务发布粒度，这样，在服务发布的过程若出现故障，可以及时定位出现故障的API，进而提高服务发布的效率。

下面，通过具体实施例，对本申请所示的技术方案进行详细说明。需要说明的是，下面几个具体实施例可以相互结合，对于相同或相似的内容，在不同的实施例中不再进行重复说明。

图2为本发明实施例提供的请求消息处理方法的示意图一。请参见图2，包括：

S201、第一服务器确定发布方案中当前执行的第一发布步骤、在第一发布步骤中发布的API。

其中，发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识。每一个发布步骤用于指示发布一个对应的API，在同一时刻仅有一个发布步骤正在执行，因此，当前正在执行的发布步骤中的API为处于发布状态的API。

可选的，第一发布步骤为发布方案中的任意一个步骤。第一服务器按照发布方案中的执行步骤执行发布方案。

可选的，发布方案中还包括发布步骤之间的切换条件。例如，切换条件可以为执行时长大于预设时长、执行成功率大于预设成功率等。当然，在实际应用过程中，可以根据实际需要设置该切换条件，本发明实施例对此不作具体限定。

例如，发布方案可以如下：在启动之后执行第一发布步骤，第一发布步骤为将API1发布给客户端1-客户端1000；在第一发布步骤的执行时长大于10个小时之后，执行第二发布步骤，第二发布步骤为将API发布给客户端1-客户端2000；在第二发布步骤的执行成功率大于90％时，执行第三发布步骤，以此类推，直至执行最后一个发布步骤。

需要说明的是，在S201之后，第一服务器还向容器管理服务器发送实例部署通知，以使容器管理服务器进行服务实例的部署。

可选的，在不同的发布步骤中，服务实例的个数也可以不同。在实际应用过程中，可以根据实际需要设置每一个发布步骤中的服务实例的个数，本发明实施例对此不作具体限定。

可选的，容器管理服务器部署的服务实例中包括至少一个默认服务实例，和至少一个新服务实例。其中，该默认服务实例加载的API均为旧版本的API。新服务实例加载的API均为最新版本的API。

还需要说明的是，在S201之前，第一服务器可以据发布方案确定第二对应关系，第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识，并在外部缓存中存储所述第二对应关系。

例如，第二对应关系可以如表1所示：

表1

API的标识	服务实例的标识
		API1	服务实例1
API2	服务实例2
		API3	服务实例3
……	……

需要说明的是，表2只是以示例的形式示意第二对应关系，并非对第二对应关系的限定。

S202、第一服务器向网关发送处于发布状态的API的标识。

S203、网关将处于发布状态的API的标识存储在网关的内部缓存中。

可选的，网关可以判断网关的内部缓存中是否存在API标识，若是，则将内部缓存中的API标识更新为API的标识；若否，则第一服务器将API的标识存储在内部缓存中。

S204、客户端向网关发送请求消息。

S205、网关确定请求消息对应的第一API。

在本发明实施例中，对于不同类型的请求消息，需要不同的API对其进行处理，即，请求消息的类型和API之间具有预设的第一对应关系，第一对应关系中包括至少一个API的标识、及每一个API的标识对应的请求消息的类型。例如，第一对应关系可以如表2所示：

表2

请求消息的类型	API的标识
		第一类型请求消息	API1
第二类型请求消息	API2
		第三类型请求消息	API3
……	……

可选的，在进行API发布时，还可以向部分用户API，相应的，在第一对应关系中还可以包括客户端的标识，相应的，在S206中，网关需要根据客户端的标识和请求消息的类型，确定第一API。例如，第一对应关系可以如表3所示：

表3

客户端的标识	请求消息的类型	API的标识
			客户端1-客户端1000	第一类型请求消息	API1
客户端200-客户端1000	第二类型请求消息	API2
			客户端500-客户端2000	第三类型请求消息	API3
……	……	……

需要说明的是，表2和表3只是以示例的形式示意请求消息的类型和API之间的第一对应关系，并非对该第一对应关系的限定，在实际应用过程中，可以根据实际需要设置该第一对应关系，本发明实施例对此不作具体限定。

可选的，在客户端向网关发送一次请求消息之后，若网关根据上述第一对应关系确定得到客户端对应的API为第一API，则网关在向客户端发送的响应消息中携带第一API的标识。这样，在客户端下一次发送请求消息时，可以在请求消息中携带第一API的标识，这样，在网关接收到请求消息之后，直接将请求消息中包括的API标识对应的API确定为第一API即可，网关无需查找上述第一对应关系即可确定得到客户端对应的第一API，进而提高了网关的处理效率。

需要说明的是，在服务发布的过程中，可能不对某部分客户端发布任意一个最新的API，相应的，该部分客户端没有对应任何一个API，则网关无法获取得到该部分客户端对应的第一API。在该种情况下，网关可以将该客户端发送的请求消息发送给未加载最新版本的API的服务实例。

S206、网关根据预设的发布方案确定第一API的运行状态。

其中，运行状态包括发布状态和未发布状态。当发布方案中正在执行的发布步骤中发布的API为第一API时，则第一API的运行状态为发布状态，当发布方案中正在执行的发布步骤中发布的API不是第一API时，则第一API的运行状态为未发布状态。

可选的，网关的内部缓存中可以存储有处于发布状态的API的标识，这样，网关可以在内部缓存中获取处于发布状态的API的标识，并判断第一API的标识和处于发布状态的API的标识是否相同，若是，则确定第一API的状态为发布状态，若否，则确定第一API的状态为未发布状态。

由于网关可以对内部缓存进行快速访问，因此，通过上述方法网关可以快速确定得到第一API的运行状态。进一步的，通过在网关的内部缓存中存储处于发布状态的API的标识，使得在启动发布服务时、及发布步骤进行切换时，只需更新内部缓存中处于发布状态的API的标识即可，无需进行网关重启。

当然，网关的内部缓存中还可以存储每一个API的运行状态。例如，内部缓存中存储的每一个API的运行状态可以如表4所示：

表4

API的标识	运行状态
		API1	发布状态
API2	未发布状态
		API3	未发布状态
……	……

需要说明的是，表4只是以示例的形式示意每一个API的运行状态，并非对API的运行状态的限定。

S207、网关根据第一API的运行状态，确定目标服务实例。

其中，目标服务实例加载的第一API的版本与第一API的运行状态对应。即，当第一API的运行状态为发布状态时，则目标服务实例加载的API的版本为最新版本，当第一API的状态为未发布状态时，则目标服务实例加载的API的版本不是最新版本。

可选的，网关可以判断第一API的运行状态是否为发布状态；若是，则网关根据外部缓存中的第二对应关系和第一API的标识，确定目标服务实例；若否，则网关将默认服务实例确定为目标服务实例，默认服务实例为未加载最新版本API的服务实例。

其中，网关可以对外部缓存进行快速访问，使得网关可以快速根据外部缓存中的第二对应关系确定目标服务实例，提高了确定目标服务实例的效率。

S208、网关向目标服务实例发送请求消息。

在网关选择得到目标服务实例之后，可以获取目标服务实例的路径信息，并根据目标服务实例的路径信息向目标服务实例发送请求消息，以使目标服务实例处理请求消息。

可选的，目标服务实例的路径信息可以通过目标服务实例的互联网协议(Internet Protocol，简称IP)地址和/或媒体访问控制(Medium Access Control，简称MAC)地址表示。

可选的，当第一API为未发布状态时，则可以通过如下可行的实现方式获取目标服务实例的路径信息：在网关的内部缓存中获取默认路径信息，并将该默认路径信息确定为目标服务实例的路径信息。

可选的，当第一API为发布状态时，则可以通过如下可行的实现方式获取目标服务实例的路径信息：向注册中心请求获取目标服务实例的路径信息。

S209、目标服务器向网关发送请求消息对应的响应消息。

目标服务器可以根据其加载的第一API，对请求消息进行处理，得到响应消息。

其中，当第一API为发布状态时，确定得到的目标服务器中加载的API为最新版本的API，即，目标服务器中加载的第一API也是最新版本的API，这样，可以使得目标服务器通过最新版本的第一API对请求消息进行处理。

S210、网关向客户端发送响应消息。

本发明实施例提供的请求消息处理方法，预先制定的发布方案中包括多个发布步骤，每一个发布步骤对应一个最新版本的API，即，进行服务发布时，在每一个发布步骤中仅发布一个最新版本的API。相应的，在网关接收到客户端发送的请求消息之后，获取客户端对应的第一API，并根据第一API的运行状态确定目标服务实例，目标服务实例加载的第一API的版本与第一API的运行状态对应，例如，当第一API为发布状态时，则确定得到目标服务实例加载的API的版本为最新版本，当第一API为未发布状态时，则确定得到的目标服务实例加载的API的版本不是最新版本，这样，可以实现在不同的发布步骤中将不同的最新版本的API发布至对应的客户端。在上述过程中，在进行服务发布时，按照API的粒度进行发布，减小了服务发布粒度，这样，在服务发布的过程若出现故障，可以及时定位出现故障的API，进而提高服务发布的效率。

在图2所示实施例的基础上，下面，通过图3所示的实施例，对图2所示的实施例进行进一步详细说明。

图3为本发明实施例提供的请求消息处理方法的示意图二。请参见图3，包括：

S301、第一服务器确定发布方案中当前执行的第一发布步骤、在第一发布步骤中发布的第二API。

S302、第一服务器根据第一发布步骤确定服务实例的个数。

可选的，第一服务实例可以根据第一发布步骤确定需要部署的默认服务实例的个数、以及新服务实例的个数。

例如，假设第一发布步骤中发布的API的负载承受能力有限，则可以确定新服务实例的个数为多个。假设第一发布步骤中发布的API的负载承受能力较强，则可以确定新服务实例的个数为1个。

S303、第一服务器向容器管理服务器发送实例部署请求，实例部署请求中包括服务实例的个数。

S304、容器管理服务器根据服务实例的个数进行服务实例部署。

需要说明的是，在S304之后，服务集群中的服务实例向注册中心发送每一个服务实例的路径信息(图中未示出)。

S305、第一服务器向网关发送第二API的标识。

S306、网关在网关的内部缓存中存储第二API的标识。

需要说明的是，S306的执行过程可以参见S203，此时不再进行赘述。

S307、客户端向网关发送请求消息。

S308、网关确定请求消息对应的第一API。

可选的，网关可以判断请求消息中是否包括API标识；若是，则网关将API标识对应的API确定为第一API；若否，则网关获取第一对应关系和请求消息的类型，并根据第一对应关系和请求消息的类型确定第一API。

S309、网关根据预设的发布方案确定第一API的运行状态。

可选的，可以根据第一API的标识和网关的内部缓存中的第二API的标识，确定第一API的运行状态。当第一API的标识和第二API的标识相同时，则确定第一API的运行状态为发布状态，否则，则确定第一API的运行状态不是发布状态。

需要说明的是，在S311中，网关需要从读取内部缓存中的内容，在S308中，第一服务器需要在内部缓存中写入内容。为了避免读写发生冲突，可以设置主缓存和从缓存，在不同的发布步骤中，可以将主缓存和从缓存中的一个缓存设置有有效缓存。相应的，当需要进行数据读操作时，从有效缓存中读取数据，当需要进行写操作时，对非有效缓存进行写操作。

可选的，内部缓存包括主缓存和从缓存；网关可以通过如下可行的实现方式在网关的内部缓存中获取处于发布状态的API的标识：网关获取主缓存和从缓存的处理状态，处理状态包括有效状态和无效状态；其中，在同一时刻，主缓存和从缓存中存在一个缓存的处理状态为有效状态，另一个缓存的处理状态为无效状态；网关在有效状态的缓存中获取处于发布状态的API的标识。

进一步的，网关在有效状态的缓存中获取处于发布状态的API的标识之前，网关还接收第一服务器发送的、处于发布状态的API的标识；网关在无效状态的缓存中存储处于发布状态的API的标识；网关更换主缓存和从缓存的处理状态。

例如，在第一发布步骤中，在主缓存和从缓存中分别写入处于发布状态的API的标识(假设为API1)，此时，主缓存和从缓存中均存储API1。将主缓存的处理状态设置为有效状态，使得在第一发布步骤中，网关从主缓存中进行数据读取，读取得到的处于发布状态的API的标识为API1。

在第一发布步骤执行结束之后，需要执行第二发布步骤时，假设第二发布步骤中处于发布状态的API为API2，则将API2写入从缓存，此时，主缓存中存储的是API1，从缓存中存储的是API2。将从缓存设置的处理状态设置为有效状态，使得在第二发布步骤中，网关从从缓存中进行数据读取，读取得到的处于发布状态的API的标识为API2。

在之后的步骤中重复执行上述过程。

S310、网关根据第一API的运行状态，确定目标服务实例。

需要说明的是，S310的执行过程可以参见S207，此时不再进行赘述。

S311、网关获取目标服务实例的路径信息。

需要说明的是，S311的执行过程可以参见S208，此时不再进行赘述。

S312、网关根据目标服务实例的路径信息，向目标服务实例发送请求消息。

S313、目标服务实例向网关发送响应消息。

S314、目标服务实例在响应消息中添加第一API的标识。

S315、目标服务实例向客户端发送包括第一API的标识的响应消息。

需要说明的是，若网关向客户端发送的响应消息中包括第一API的标识，则客户端在下一次发送请求消息时，在请求消息中携带第一API的标识。

通过图3所示的实施例，可以实现在不同的发布步骤中将不同的最新版本的API发布至对应的客户端，由于在一个发布步骤中仅发布一个API，这样，在服务发布的过程若出现故障，可以及时定位出现故障的API，进而提高服务发布的效率。

图4为本发明实施例提供的一种请求消息处理装置的结构示意图一。请参见图4该装置可以包括接收模块11、第一确定模块12、第二确定模块13、第三确定模块14和发送模块15，其中，

所述接收模块11用于，接收客户端发送的请求消息；

所述第一确定模块12用于，确定所述请求消息对应的第一应用程序编程接口API；

所述第二确定模块13用于，根据预设的发布方案中当前执行的发布步骤确定所述第一API的运行状态，所述运行状态包括发布状态和未发布状态，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；

所述第三确定模块14用于，根据所述第一API的运行状态，确定所述目标服务实例，其中，所述目标服务实例加载的API的版本与所述第一API的运行状态对应；

所述发送模块15用于，向所述目标服务实例发送所述请求消息，以使所述目标服务实例根据其加载的所述第一API处理所述请求消息。

本发明实施例提供的请求消息处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

在一种可能的实施方式中，所述第一确定模块12具体用于：

判断所述请求消息中是否包括API标识；

若是，则将所述API标识对应的API确定为所述第一API；

若否，则获取第一对应关系和所述请求消息的类型，并根据所述第一对应关系和所述请求消息的类型确定所述第一API，所述第一对应关系中包括至少一个API的标识、及每一个API的标识对应的请求消息的类型。

在另一种可能的实施方式中，第二确定模块13具体用于：

在所述网关的内部缓存中获取处于发布状态的API的标识；

判断所述第一API的标识和所述内部缓存中的API标识是否相同；

若是，则确定所述第一API的运行状态为发布状态；

若否，则确定所述第一API的运行状态为未发布状态。

在另一种可能的实施方式中，所述内部缓存包括主缓存和从缓存；第二确定模块13具体用于：

获取所述主缓存和所述从缓存的处理状态，所述处理状态包括有效状态和无效状态；其中，在同一时刻，所述主缓存和所述从缓存中存在一个缓存的处理状态为有效状态，另一个缓存的处理状态为无效状态；

在有效状态的缓存中获取所述处于发布状态的API的标识。

图5为本发明实施例提供的一种请求消息处理装置的结构示意图二。在图4所示实施例的基础上，请参见图5，所述装置还包括存储模块16和更换模块17，其中，

所述接收模块11还用于，在所述第二确定模块13在有效状态的缓存中获取所述处于发布状态的API的标识之前，接收第一服务器发送的、所述处于发布状态的API的标识；

所述存储模块16用于，在所述无效状态的缓存中存储所述处于发布状态的API的标识；

所述更换模块17用于，更换所述主缓存和所述从缓存的处理状态。

在另一种可能的实施方式中，第三确定模块14具体用于：

判断所述第一API的运行状态是否为发布状态；

若是，则根据外部缓存中的第二对应关系和所述第一API的标识，确定所述目标服务实例，所述第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识；

若否，则将默认服务实例确定为所述目标服务实例，所述默认服务实例为未加载最新版本API的服务实例。

在另一种可能的实施方式中，发送模块15具体用于：

若所述第一API为未发布状态，则在所述网关的内部缓存中获取默认路径信息，并根据所述默认路径信息，向所述目标服务实例发送所述请求消息，所述默认路径信息为默认服务实例的路径信息，所述默认服务实例为未加载最新版本API的服务实例；

若所述第一API为发布状态，则向注册中心请求获取所述目标服务实例的路径信息，并根据所述目标服务实例的路径信息，向所述目标服务实例发送所述请求消息。

在另一种可能的实施方式中，所述装置还包括添加模块18，其中，

所述接收模块11还用于，接收所述目标服务实例发送的响应消息；

所述添加模块18用于，在所述响应消息中添加所述第一API的标识；

所述发送模块15还用于，向所述客户端发送包括所述第一API的标识的响应消息，以使所述客户端在下一次发送请求消息时，携带所述第一API的标识。

本发明实施例提供的请求消息处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

图6为本发明实施例提供的另一种请求消息处理装置的结构示意图一，请参见图6，该装置可以包括第一确定模块21和发送模块22，其中，

所述第一确定模块21用于，确定发布方案中当前执行的第一发布步骤、在所述第一发布步骤中发布的应用程序编程接口API，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；

所述发送模块22用于，向网关发送所述API的标识，以使所述网关在所述网关的内部缓存中存储所述API的标识。

本发明实施例提供的请求消息处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

图7为本发明实施例提供的另一种请求消息处理装置的结构示意图二。在图6所示实施例的基础上，请参见图7，所述装置还包括第二确定模块23和存储模块24，其中，

所述第二确定模块23用于，根据所述发布方案确定第二对应关系，所述第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识；

所述存储模块24用于，在外部缓存中存储所述第二对应关系。

本发明实施例提供的请求消息处理装置可以执行上述方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。

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

最后应说明的是：以上各实施例仅用以说明本发明实施例的技术方案，而非对其限制；尽管参照前述各实施例对本发明实施例进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明实施例方案的范围。

Claims (12)

1.一种请求消息处理方法，其特征在于，包括：

网关接收客户端发送的请求消息；

所述网关确定所述请求消息对应的第一应用程序编程接口API；

所述网关根据预设的发布方案中当前执行的发布步骤确定第一API的运行状态，所述运行状态包括发布状态和未发布状态，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；

所述网关根据所述第一API的运行状态，确定目标服务实例，其中，所述目标服务实例加载的API的版本与所述第一API的运行状态对应；

所述网关向所述目标服务实例发送所述请求消息，以使所述目标服务实例根据其加载的所述第一API处理所述请求消息。

2.根据权利要求1所述的方法，其特征在于，所述网关确定所述请求消息对应的第一API，包括：

所述网关判断所述请求消息中是否包括API标识；

若是，则所述网关将所述API标识对应的API确定为所述第一API；

若否，则所述网关获取第一对应关系和所述请求消息的类型，并根据所述第一对应关系和所述请求消息的类型确定所述第一API，所述第一对应关系中包括至少一个API的标识、及每一个API的标识对应的请求消息的类型。

3.根据权利要求1或2所述的方法，其特征在于，所述网关根据预设的发布方案中当前执行的发布步骤确定所述第一API的运行状态，包括：

所述网关在所述网关的内部缓存中获取处于发布状态的API的标识；

所述网关判断所述第一API的标识和所述内部缓存中的API标识是否相同；

若是，则所述网关确定所述第一API的运行状态为发布状态；

若否，则所述网关确定所述第一API的运行状态为未发布状态。

4.根据权利要求3所述的方法，其特征在于，所述内部缓存包括主缓存和从缓存；所述网关在所述网关的内部缓存中获取处于发布状态的API的标识，包括：

所述网关获取所述主缓存和所述从缓存的处理状态，所述处理状态包括有效状态和无效状态；其中，在同一时刻，所述主缓存和所述从缓存中存在一个缓存的处理状态为有效状态，另一个缓存的处理状态为无效状态；

所述网关在有效状态的缓存中获取所述处于发布状态的API的标识。

5.根据权利要求4所述的方法，其特征在于，所述网关在有效状态的缓存中获取所述处于发布状态的API的标识之前，还包括：

所述网关接收第一服务器发送的、所述处于发布状态的API的标识；

所述网关在所述无效状态的缓存中存储所述处于发布状态的API的标识；

所述网关更换所述主缓存和所述从缓存的处理状态。

6.根据权利要求1或2所述的方法，其特征在于，所述网关根据所述第一API的运行状态，确定所述目标服务实例，包括：

所述网关判断所述第一API的运行状态是否为发布状态；

若是，则所述网关根据外部缓存中的第二对应关系和所述第一API的标识，确定所述目标服务实例，所述第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识；

若否，则所述网关将默认服务实例确定为所述目标服务实例，所述默认服务实例为未加载最新版本API的服务实例。

7.根据权利要求1或2所述的方法，其特征在于，所述网关向所述目标服务实例发送所述请求消息，包括：

若所述第一API为未发布状态，则在所述网关的内部缓存中获取默认路径信息，并根据所述默认路径信息，向所述目标服务实例发送所述请求消息，所述默认路径信息为默认服务实例的路径信息，所述默认服务实例为未加载最新版本API的服务实例；

若所述第一API为发布状态，则向注册中心请求获取所述目标服务实例的路径信息，并根据所述目标服务实例的路径信息，向所述目标服务实例发送所述请求消息。

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

所述网关接收所述目标服务实例发送的响应消息；

所述网关在所述响应消息中添加所述第一API的标识；

所述网关向所述客户端发送包括所述第一API的标识的响应消息，以使所述客户端在下一次发送请求消息时，携带所述第一API的标识。

9.一种请求消息处理方法，其特征在于，包括：

第一服务器确定发布方案中当前执行的第一发布步骤、在所述第一发布步骤中发布的应用程序编程接口API，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；以使网关根据预设的发布方案中当前执行的发布步骤确定第一API的运行状态，所述运行状态包括发布状态和未发布状态，所述网关根据所述第一API的运行状态，确定目标服务实例，其中，所述目标服务实例加载的API的版本与所述第一API的运行状态对应，以使所述目标服务实例根据其加载的所述第一API处理所述请求消息；

所述第一服务器向网关发送所述API的标识，以使所述网关在所述网关的内部缓存中存储所述API的标识。

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

所述第一服务器根据所述发布方案确定第二对应关系，所述第二对应关系中包括多个API的标识和每一个API的标识对应的目标服务实例的标识；

所述第一服务器在外部缓存中存储所述第二对应关系。

11.一种请求消息处理装置，其特征在于，包括接收模块、第一确定模块、第二确定模块、第三确定模块和发送模块，其中，

所述接收模块用于，接收客户端发送的请求消息；

所述第一确定模块用于，确定所述请求消息对应的第一应用程序编程接口API；

所述第二确定模块用于，根据预设的发布方案中当前执行的发布步骤确定第一API的运行状态，所述运行状态包括发布状态和未发布状态，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；

所述第三确定模块用于，根据所述第一API的运行状态，确定目标服务实例，其中，所述目标服务实例加载的API的版本与所述第一API的运行状态对应；

所述发送模块用于，向所述目标服务实例发送所述请求消息，以使所述目标服务实例根据其加载的所述第一API处理所述请求消息。

12.一种请求消息处理装置，其特征在于，包括第一确定模块和发送模块，其中，

所述第一确定模块用于，确定发布方案中当前执行的第一发布步骤、在所述第一发布步骤中发布的应用程序编程接口API，所述发布方案中包括多个发布步骤及其对应的处于发布状态的API的标识；以使网关根据预设的发布方案中当前执行的发布步骤确定第一API的运行状态，所述运行状态包括发布状态和未发布状态，所述网关根据所述第一API的运行状态，确定目标服务实例，其中，所述目标服务实例加载的API的版本与所述第一API的运行状态对应，以使所述目标服务实例根据其加载的所述第一API处理所述请求消息；

所述发送模块用于，向网关发送所述API的标识，以使所述网关在所述网关的内部缓存中存储所述API的标识。

Images