一种微服务请求处理方法、装置、设备及介质与流程

1.本发明涉及微服务架构技术领域，特别涉及一种微服务请求处理方法、装置、设备及介质。


背景技术：

2.微服务是一种架构风格，由一系列微小的服务共同组成，将原先复杂而庞大的单体服务拆分为一系列更细粒度的微服务，每个服务负责单一职责的业务，服务间使用轻量级的机制进行通讯。每个微服务的运行都需要配置信息，通常情况下，微服务使用分布式配置中心来管理微服务共用的配置信息。当前，基于微服务的分布式配置中心的原理如图1所示，由服务端和客户端两个部分组成，用户首先需要将配置信息上传至第三方的代码托管库，如github，分布式配置中心的服务端从中读取到配置信息，每个微服务中集成了客户端，客户端再从服务端读取配置信息到微服务。配置信息更新时，需要首先更新第三方代码托管库中的配置文件，手动运行服务端中的配置更新程序，重新从代码托管库中读取配置信息，然后将新的配置信息推送给各个客户端完成更新。虽然该分布式配置中心能完成基本的配置信息的管理功能，但是该架构依然比较简陋，在可靠性方面存在着缺陷，配置文件的管理也不够精细，且仅能作为配置中心使用。并且，服务端为单点部署，难以实现高可用性，一旦存在单点故障，整个配置中心则不可用。
3.综上，如何实现服务端的高可用性，并增强可靠性是目前有待解决的问题。


技术实现要素：

4.有鉴于此，本发明的目的在于提供一种微服务请求处理方法、装置、设备及介质，能够实现服务端的高可用性，并增强可靠性。其具体方案如下：
5.第一方面，本技术公开了一种微服务请求处理方法，应用于网关入口，包括：
6.获取客户端通过预先注册的目标微服务发送的目标请求；
7.基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序；
8.获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端。
9.可选的，所述微服务请求处理方法，还包括：
10.获取目标用户通过页面控制台发送的目标请求。
11.可选的，所述获取客户端通过预先注册的目标微服务发送的目标请求，包括：
12.获取客户端通过预先注册的目标微服务发送的微服务注册请求；
13.相应的，所述获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端，包括：
14.通过所述目标服务端程序对所述微服务注册请求进行解析得到对应的微服务注册信息，并将所述微服务注册信息保存至本地数据库；其中，所述微服务注册信息包括微服
务名称、主机ip地址、运行端口、运行状态、实例数中的任意一种或几种信息；
15.获取所述目标服务端程序返回的用于表征与所述微服务注册请求对应的微服务注册成功的第一应答信息，并将所述第一应答信息发送至所述客户端。
16.可选的，所述获取客户端通过预先注册的目标微服务发送的目标请求，包括：
17.获取客户端通过预先注册的目标微服务发送的配置文件管理请求；
18.相应的，所述获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端，包括：
19.通过所述目标服务端程序对所述配置文件管理请求进行解析得到相应的配置文件管理操作信息，并执行相应的配置文件管理操作得到处理后配置文件，然后将所述处理后配置文件保存至本地数据库；其中，所述配置文件管理操作包括在所述目标服务端程序增加新的配置文件、更新所述目标服务端程序的当前配置文件、删除所述目标服务端程序的当前配置文件中的任意一种操作；
20.获取所述目标服务端程序返回的针对所述处理后配置文件的第二应答信息，并将所述第二应答信息发送至所述客户端，以便所述客户端基于所述第二应答信息对所述目标微服务进行处理。
21.可选的，所述微服务请求处理方法，还包括：
22.若所述配置文件管理操作为更新所述目标服务端程序的当前配置文件或删除所述目标服务端程序的当前配置文件，则将未执行相应配置文件管理操作前的所述当前配置文件保存至预设的历史版本列表。
23.可选的，所述微服务请求处理方法，还包括：
24.获取每一服务端程序每隔第一预设时间间隔发送的针对自身服务状态检查的状态检查结果；
25.若所述状态检查结果为健康状态，则将相应的所述服务端程序保存至预设的服务可用列表；
26.相应的，所述基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，包括：
27.利用预设路由规则从所述服务可用列表中确定出目标服务端程序。
28.可选的，所述微服务请求处理方法，还包括：
29.若在第二预设时间间隔内连续预设次数未获取到所述状态检查结果或在所述第二预设时间间隔内所述状态检查结果连续预设次数为非健康状态，则从所述服务可用列表中移除相应的服务端程序。
30.第二方面，本技术公开了一种微服务请求处理装置，应用于网关入口，包括：
31.请求获取模块，用于获取客户端通过预先注册的目标微服务发送的目标请求；
32.请求转发模块，用于基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序；
33.结果发送模块，用于获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端。
34.第三方面，本技术公开了一种电子设备，包括：
35.存储器，用于保存计算机程序；
36.处理器，用于执行所述计算机程序，以实现前述公开的微服务请求处理方法的步骤。
37.第四方面，本技术公开了一种计算机可读存储介质，用于存储计算机程序；其中，所述计算机程序被处理器执行时实现前述公开的微服务请求处理方法的步骤。
38.可见，本技术获取客户端通过预先注册的目标微服务发送的目标请求；基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序；获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端。由此可见，本技术通过网关入口统一获取客户端通过预先注册的目标微服务发送的目标请求，并根据预设路由规则从所有服务端程序中确定出目标服务端程序，以便将目标请求转发至目标服务端程序进行处理，最后获取目标服务端程序返回相应的处理结果，并将处理结果发送至客户端。如此一来，通过在服务器端部署多个服务端程序对请求进行处理，实现了服务端的高可用性，也增强了可靠性。
附图说明
39.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
40.图1为本技术公开的一种现有的基于微服务的分布式配置中心示意图；
41.图2为本技术公开的一种微服务请求处理方法流程图；
42.图3为本技术公开的一种适用于微服务请求处理方法的架构图；
43.图4为本技术公开的一种服务路由运行原理图；
44.图5为本技术公开的一种具体的微服务请求处理方法流程图；
45.图6为本技术公开的一种具体的用于服务注册和配置管理的架构示意图；
46.图7为本技术公开的一种具体的微服务请求处理方法流程图；
47.图8为本技术公开的一种具体的配置文件示意图；
48.图9为本技术公开的一种微服务请求处理装置结构示意图；
49.图10为本技术公开的一种电子设备结构图。
具体实施方式
50.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
51.当前分布式配置中心的架构比较简陋，在可靠性方面存在着缺陷，配置文件的管理也不够精细，且仅能作为配置中心使用。并且，服务端为单点部署，难以实现高可用性，一旦存在单点故障，整个配置中心则不可用。为此，本技术实施例公开了一种微服务请求处理方法、装置、设备及介质，能够实现服务端的高可用性，并增强可靠性。
52.参见图2所示，本技术实施例公开了一种微服务请求处理方法，应用于网关入口，
该方法包括：
53.步骤s11：获取客户端通过预先注册的目标微服务发送的目标请求。
54.本实施例中，通过网关入口统一获取客户端通过预先注册的目标微服务发送的目标请求。在另一种具体实施例中，也可以通过网关入口获取目标用户通过页面控制台发送的目标请求。可以理解的是，目标用户可以在微服务中通过客户端以代码的方式访问服务端，也可以登录页面控制台，在可视化界面上进行操作，使用页面控制台的方式更加方便，用户点击界面即可进行微服务的注册，添加配置文件信息，更新配置文件的操作。但无论目标请求来自于客户端还是页面控制台，都会先抵达网关入口。图3为本技术公开的一种适用于微服务请求处理方法的架构图，架构上也是分为客户端和服务端两个部分，将原来的单点部署改为了多份服务端程序的集群部署，增加了网关入口、页面控制台、本地数据库。客户端或页面控制台把目标请求发送至网关入口，由网关入口自动路由至服务端的某一服务端程序，数据不再托管至第三方的代码库，而是由本地的数据库存储。
55.步骤s12：基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序。
56.本实施例中，网关入口在获取到目标请求后，则基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，再由网关入口将目标请求转发至目标服务端程序。
57.需要指出的是，本技术的微服务请求处理方法还包括：获取每一服务端程序每隔第一预设时间间隔发送的针对自身服务状态检查的状态检查结果；若所述状态检查结果为健康状态，则将相应的所述服务端程序保存至预设的服务可用列表。也即，服务器的每一个服务端程序定期会运行一次服务状态检查，并将自身服务状态检查的状态检查结果上报至网关入口中的服务路由，服务路由中包括预设的服务可用列表和路由规则配置，参见图4所示，图4为本技术公开的一种服务路由运行原理图。若网关入口获取到了服务端程序发送的状态检查结果，并且显示为健康状态，则将相应的服务端程序保存至预设的服务可用列表。上述第一预设时间间隔可以设为30秒，则每隔30秒运行依次服务状态检查。进一步的，还包括：若在第二预设时间间隔内连续预设次数未获取到所述状态检查结果或在所述第二预设时间间隔内所述状态检查结果连续预设次数为非健康状态，则从所述服务可用列表中移除相应的服务端程序。上述第二预设时间间隔可以设为5分钟，预设次数可以设为3次，也即若可用服务列表在5分钟内连续3次均未收到状态检查结果或连续3次状态检查结果都为非健康状态，则将相应的服务端程序从服务可用列表中移除。可以理解的是，若偶尔一次出现上述情况，可能是网络延迟或检查过程出现故障等原因，但连续多次都出现上述情况，则很大可能是服务端程序已处于非健康状态，也即异常状态。
58.相应的，所述基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，包括：利用预设路由规则从所述服务可用列表中确定出目标服务端程序。也即，根据预设路由规则从服务可用列表中确定出目标服务端程序。预设路由规则可以是轮询负载、权重负载、ip负载或根据响应时间选择目标服务端程序，轮询负载也即顺序遍历可用服务列表，在可用服务列表里预先为所有的服务端程序编号，如服务端程序1、服务端程序2等等，然后按照编号从小到大或从大大小的顺序依次选择服务端程序作为目标服务端程序；权重负载是随机对服务端程序进行选择，为每个服务端程序配置权重，权重大的被选中的
概率高，权重小的被选中的概率低；ip负载通过对ip地址进行取模运算，根据取模运算结果将ip分组，每组对应某1个服务端程序；响应时间则根据最短的服务端程序响应时间进行选择。
59.步骤s13：获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端。
60.本实施例中，获取目标服务端程序在对目标请求进行处理后返回的相应的处理结果，并将处理结果发送至客户端。也即，服务端程序在完成对目标请求的处理后，会主动向客户单推送消息，以提示客户端相应的请求处理已完成或者回复相应的处理结果。
61.可见，本技术获取客户端通过预先注册的目标微服务发送的目标请求；基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序；获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端。由此可见，本技术通过网关入口统一获取客户端通过预先注册的目标微服务发送的目标请求，并根据预设路由规则从所有服务端程序中确定出目标服务端程序，以便将目标请求转发至目标服务端程序进行处理，最后获取目标服务端程序返回相应的处理结果，并将处理结果发送至客户端。如此一来，通过在服务器端部署多个服务端程序对请求进行处理，实现了服务端的高可用性，也增强了可靠性。
62.参见图5所示，本技术实施例公开了一种具体的微服务请求处理方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。具体包括：
63.步骤s21：获取客户端通过预先注册的目标微服务发送的微服务注册请求。
64.本实施例中，目标请求具体可以为微服务注册请求，此外可以获取客户端发送的微服务注册请求，也可以获取页面控制台发送的微服务注册请求。相比于现有技术中配置中心和服务注册中心是两个独立的架构，本技术将两者进行结合，参见图6所示，图6为本技术公开的一种具体的用于服务注册和配置管理的架构示意图，其中本地数据库采用本地高可用的数据库集群。服务端提供服务管理和配置管理两种类型的服务，服务管理用于微服务的注册和发现，配置管理用于管理各个微服务的公共配置信息。那么本技术的技术方案不仅能适用于配置中心也能适用于服务注册中心，也即不仅能获取与配置中心相应的配置文件管理请求，也能获取与服务注册中心相应的微服务注册请求。
65.步骤s22：基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序。
66.步骤s23：通过所述目标服务端程序对所述微服务注册请求进行解析得到对应的微服务注册信息，并将所述微服务注册信息保存至本地数据库；其中，所述微服务注册信息包括微服务名称、主机ip地址、运行端口、运行状态、实例数中的任意一种或几种信息。
67.本实施例中，在目标服务端程序获取到微服务注册请求后，则对微服务注册请求进行解析得到对应的微服务注册信息，并保存至本地数据库，以完成微服务的注册。通过将相关数据信息直接保存至本地数据库，而非现有技术中的第三方代码托管库，增加了数据存储的可靠性和可维护性，同时省去了原先与第三方代码托管库的通讯时间。其中，微服务注册信息具体可以包括但不限于微服务名称、主机ip地址、运行端口、运行状态、实例数。图6中的服务发现功能用于微服务调用时的服务查询，根据微服务名称查询出微服务的ip、运行端口、运行状态。
68.步骤s24：获取所述目标服务端程序返回的用于表征与所述微服务注册请求对应的微服务注册成功的第一应答信息，并将所述第一应答信息发送至所述客户端。
69.本实施例中，当目标服务端程序完成相应的微服务注册请求处理后，需要获取目标服务端程序返回的用于表征与该微服务注册请求对应的微服务注册成功的第一应答信息，并将该第一应答信息发送至客户端，以提示客户端，微服务已经注册成功。
70.其中，关于上述步骤s22更加具体的处理过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
71.可见，本技术实施例获取客户端通过预先注册的目标微服务发送的微服务注册请求，并在确定出目标服务端程序后，通过目标服务端程序对微服务注册请求进行解析得到对应的微服务注册信息，并将微服务注册信息保存至本地数据库；其中，微服务注册信息包括微服务名称、主机ip地址、运行端口、运行状态、实例数中的任意一种或几种信息；然后获取目标服务端程序返回的用于表征与微服务注册请求对应的微服务注册成功的第一应答信息，并将第一应答信息发送至所述客户端。由此可见，本技术的技术方案可用于微服务注册，当获取到微服务注册请求后，则对微服务注册请求进行解析得到相应的微服务注册信息，并保存至本地数据库以完成微服务的注册，然后向客户端提示注册成功的消息。
72.参见图7所示，本技术实施例公开了一种具体的微服务请求处理方法，相对于上一实施例，本实施例对技术方案作了进一步的说明和优化。具体包括：
73.步骤s31：获取客户端通过预先注册的目标微服务发送的配置文件管理请求。
74.本实施例中，目标请求具体可以为配置文件管理请求。此外可以获取客户端发送的配置文件管理请求，也可以获取页面控制台发送的配置文件管理请求。对于页面控制台，用户可通过页面控制台上传配置文件、查看、编辑修改等。
75.步骤s32：基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序。
76.步骤s33：通过所述目标服务端程序对所述配置文件管理请求进行解析得到相应的配置文件管理操作信息，并执行相应的配置文件管理操作得到处理后配置文件，然后将所述处理后配置文件保存至本地数据库；其中，所述配置文件管理操作包括在所述目标服务端程序增加新的配置文件、更新所述目标服务端程序的当前配置文件、删除所述目标服务端程序的当前配置文件中的任意一种操作。
77.本实施例中，在目标服务端程序获取到配置文件管理请求后，则对配置文件管理请求进行解析得到相应的配置文件管理操作信息，并执行相应的配置文件管理操作得到处理后配置文件，然后将处理后配置文件保存至本地数据库。其中，配置文件管理操作包括但不限于在目标服务端程序增加新的配置文件、更新目标服务端程序的当前配置文件、删除目标服务端程序的当前配置文件中的任意一种操作，也即用于微服务配置文件的增删改查。在存储到本地数据库时，配置文件可以按照配置模式进行分类，图8为本技术公开的一种具体的配置文件示意图，其中，配置id一般为配置文件的名称，分组可用来区分不同的业务环境，如开发环境、测试环境、生产环境等，命名空间可用来隔离物理环境，如多机房部署。如此一来，可以区分不同的业务分组和隔离环境。此外，还包括配置格式，如text格式、json格式、xml格式等。
78.需要注意的是，本技术的微服务请求处理方法还包括：若所述配置文件管理操作
为更新所述目标服务端程序的当前配置文件或删除所述目标服务端程序的当前配置文件，则将未执行相应配置文件管理操作前的所述当前配置文件保存至预设的历史版本列表。也即对于每个配置文件的每次修改，均记录历史版本，保存至历史版本列表，用户可进行当前配置文件和历史版本的对比，也可以将当前的配置文件回退至某一历史版本。
79.步骤s34：获取所述目标服务端程序返回的针对所述处理后配置文件的第二应答信息，并将所述第二应答信息发送至所述客户端，以便所述客户端基于所述第二应答信息对所述目标微服务进行处理。
80.本实施例中，当目标服务端程序完成相应的配置文件管理请求处理后，需要获取目标服务端程序返回的针对处理后配置文件的第二应答信息，并将第二应答信息发送至客户端，以便客户端基于第二应答信息对目标微服务进行处理。例如，假设对配置文件管理请求解析后，相应的配置文件管理操作是更新目标服务端程序的当前配置文件，那么在服务端程序执行对应的更新操作并将更新后的配置文件保存至数据库，且将更新前的配置文件保存至预设的历史版本列表后，还需主动向客户端推送更新后的配置文件的配置信息，也即第二应答信息则为更新后的配置文件的配置信息，以便客户端根据该配置信息对目标微服务进行更新。
81.其中，关于上述步骤s23更加具体的处理过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
82.可见，本技术实施例获取客户端通过预先注册的目标微服务发送的配置文件管理请求，并在确定出目标服务端程序后，通过目标服务端程序对配置文件管理请求进行解析得到相应的配置文件管理操作信息，并执行相应的配置文件管理操作得到处理后配置文件，然后将处理后配置文件保存至本地数据库；其中，所述配置文件管理操作包括在目标服务端程序增加新的配置文件、更新目标服务端程序的当前配置文件、删除目标服务端程序的当前配置文件中的任意一种操作，然后获取目标服务端程序返回的针对处理后配置文件的第二应答信息，并将第二应答信息发送至客户端，以便客户端基于第二应答信息对目标微服务进行处理。由此可见，本技术的技术方案可用于配置文件管理，当获取到配置文件管理请求后，则对请求进行解析得到相应的配置文件管理操作，并执行对应的操作，然后将相关的配置文件保存至本地数据库，以及提示客户端对目标微服务进行更新。
83.参见图9所示，本技术实施例公开了一种微服务请求处理装置，应用于网关入口，该装置包括：
84.请求获取模块11，用于获取客户端通过预先注册的目标微服务发送的目标请求；
85.请求转发模块12，用于基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序；
86.结果发送模块13，用于获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端。
87.可见，本技术获取客户端通过预先注册的目标微服务发送的目标请求；基于预设路由规则从服务器的所有服务端程序中确定出目标服务端程序，并将所述目标请求转发至所述目标服务端程序；获取所述目标服务端程序在对所述目标请求进行处理后返回的相应的处理结果，并将所述处理结果发送至所述客户端。由此可见，本技术通过网关入口统一获取客户端通过预先注册的目标微服务发送的目标请求，并根据预设路由规则从所有服务端
程序中确定出目标服务端程序，以便将目标请求转发至目标服务端程序进行处理，最后获取目标服务端程序返回相应的处理结果，并将处理结果发送至客户端。如此一来，通过在服务器端部署多个服务端程序对请求进行处理，实现了服务端的高可用性，也增强了可靠性。
88.图10为本技术实施例提供的一种电子设备的结构示意图。具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的由电子设备执行的微服务请求处理方法中的相关步骤。
89.本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本技术技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。
90.其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用dsp(digital signal processing，数字信号处理)、fpga(field－programmable gate array，现场可编程门阵列)、pla(programmable logic array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称cpu(central processing unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以在集成有gpu(graphics processing unit，图像处理器)，gpu用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括ai(artificial intelligence，人工智能)处理器，该ai处理器用于处理有关机器学习的计算操作。
91.另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源包括操作系统221、计算机程序222及数据223等，存储方式可以是短暂存储或者永久存储。
92.其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，以实现处理器21对存储器22中海量数据223的运算与处理，其可以是windows、unix、linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的微服务请求处理方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。数据223除了可以包括电子设备接收到的由外部设备传输进来的数据，也可以包括由自身输入输出接口25采集到的数据等。
93.进一步的，本技术实施例还公开了一种计算机可读存储介质，所述存储介质中存储有计算机程序，所述计算机程序被处理器加载并执行时，实现前述任一实施例公开的由微服务请求处理过程中执行的方法步骤。
94.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
95.专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元
及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
96.结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
97.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
98.以上对本发明所提供的一种微服务请求处理方法、装置、设备及存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。