服务路由方法、装置、设备和存储介质与流程

1.本技术涉及计算机技术，具体涉及一种服务路由方法、装置、设备和存储介质。


背景技术：

2.服务行业中，用户会根据不同的需求场景向服务平台发起不同类型的服务请求，服务平台需要根据需求场景将服务流程路由至相应的服务。例如，在登录场景中，用户通过客户端发起刷脸登录请求，服务平台需要将服务流程路由至的刷脸登录服务。
3.然而，用户场景多种多样，服务请求的类型也多种多样，比如登录场景，用户可以发起刷脸登录请求，指纹登录请求，一键登录请求，账密登录请求等等，其中，每一种服务请求的实现方式也多种多样，比如针对刷脸登录请求，可以包括利用第一app刷脸，利用第二app刷脸等。
4.目前，通过为每一种服务的每一种实现方式维护相应接口给前端调用，来进行服务路由。具体来说，前端会根据用户操作，确定用户需要调用的目标服务的目标实现方式所对应的接口，然后后端会根据前端调用的接口，路由到所述目标实现方式来提供服务。
5.如此方式，第一，前端需要根据用户操作判断调用的接口，这样的判断逻辑会让前端变重；第二，后端在服务类型和实现方式增加的时候，接口会越来越多，并且每次增加接口，都需要修改前端和后端的代码，比较耗时且繁琐；第三，接口数量越多，管理接口的工作也比较繁琐且冗余，系统受到外部攻击的风险也越大，安全性较差。


技术实现要素：

6.有鉴于此，本技术至少公开一种服务路由方法。该方法可以应用于服务系统；所述服务系统包括前端与后端；所述后端维护了场景参数与服务路由信息的对应关系；所述场景参数用于表征与服务请求对应的需求场景；所述服务路由信息用于引导服务流程；所述方法可以包括：接收所述前端发起的与目标需求场景对应的目标服务请求；响应于接收到所述目标服务请求，获取与所述目标需求场景相关的目标场景参数；根据所述目标场景参数以及所述对应关系，确定目标服务路由信息；基于所述目标服务路由信息，将服务流程路由至与所述目标服务路由信息对应的目标服务实现方式。
7.在一些实施例中，所述目标场景参数为多维度参数；获取与所述目标需求场景相关的多维度的目标场景参数的获取路径包括以下至少一种：与所述目标服务请求对应的标签定义文档的标头；与所述目标服务请求对应的地址栏参数；与所述目标服务请求对应的cookie文件。
8.在一些实施例中，所述获取与所述目标需求场景相关的多维度的目标场景参数，包括：响应于从所述获取路径中的第一获取路径并未获取到全部的场景参数，采用第二获取路径获取剩余场景参数；响应于采用所述第二获取路径并未获取到全部剩余场景参数，采用第三获取路径获取剩余场景参数。
9.在一些实施例中，所述场景参数为多维度的参数；以将多维度的所述场景参数存
储为匹配条件，将服务路由信息存储为命中所述匹配条件的输出结果的方式维护所述对应关系；所述根据所述目标场景参数以及所述对应关系，确定目标服务路由信息，包括：将多维度的所述目标场景参数，与存储的每一匹配条件进行匹配；根据与多维度的所述目标场景参数匹配的目标匹配条件的输出结果，确定所述目标服务路由信息。
10.在一些实施例中，所述对应关系包括所述场景参数与需求场景之间的第一对应关系，以及所述需求场景与所述服务路由信息之间的第二对应关系；所述后端包括路由层；所述路由层存储了所述第一对应关系与所述第二对应关系；所述根据所述目标场景参数以及所述对应关系，确定目标服务路由信息，包括：通过所述路由层，根据所述目标场景参数以及所述第一对应关系确定目标需求场景；根据确定的所述目标需求场景以及所述第二对应关系确定目标服务路由信息。
11.在一些实施例中，所述场景参数的维度包括以下至少两种：账号类型；端类型；平台渠道；账号来源；登录类型。
12.在一些实施例中，在接收所述前端发起的与目标需求场景对应的目标服务请求之前，所述方法还包括：所述前端响应于用户操作，生成与目标需求场景对应的目标服务请求；将所述目标服务请求发送至与所述前端对应的后端。
13.本技术还提出一种服务路由装置，应用于服务系统；所述服务系统包括前端与后端；所述后端维护了场景参数与服务路由信息的对应关系；所述场景参数用于表征与服务请求对应的需求场景；所述服务路由信息用于引导服务流程；所述装置包括：接收模块，接收所述前端发起的与目标需求场景对应的目标服务请求；获取模块，响应于接收到所述目标服务请求，获取与所述目标需求场景相关的目标场景参数；确定模块，根据所述目标场景参数以及所述对应关系，确定目标服务路由信息；路由模块，基于所述目标服务路由信息，将服务流程路由至与所述目标服务路由信息对应的目标服务实现方式。
14.本技术还提出一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如前述任一实施例示出的服务路由方法。
15.本技术还提出一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于使处理器执行如前述任一实施例示出的服务路由方法。
16.前述方案中，在前端利用与需求场景相关的场景参数来表征与目标服务请求对应的目标需求场景，在后端可以基于所述场景参数，以及根据维护的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息，并基于所述目标服务路由信息，将服务流程路由至目标服务实现方式以提供服务，以实现灵活轻量的路由方式。
17.与相关技术相比，第一，前端只需生成与目标需求场景对应的服务请求，无需根据用户操作判断需要调用的接口，即不存在判断逻辑，从而减轻了前端压力；第二，后端可以根据场景参数，以及根据维护的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息进行服务路由，在需求场景多种多样，服务请求的类型也多种多样，每一种服务请求也多种多样的情形下，只需通过场景参数来表征多种需求场景，并且以利用所述场景参数与所述对应关系来进行服务路由的方式代替接口路由的方式，从而减少接口数量，降低代码的修改与维护的难度和复杂度，提升系统安全性。
18.应当理解的是，以上所述的一般描述和后文的细节描述仅是示例性和解释性的，
并不能限制本技术。
附图说明
19.为了更清楚地说明本技术一个或多个实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术一个或多个实施例中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
20.图1为本技术实施例示出的一种服务路由方法的方法流程示意图；
21.图2为本技术实施例示出的一种目标场景参数获取方法的流程示意图；
22.图3为本技术实施例示出的一种服务路由场景示意图；
23.图4为本技术实施例示出的一种政务系统示意图；
24.图5为本技术实施例示出的一种服务路由流程示意图；
25.图6为本技术实施例示出的一种服务路由装置的结构示意图；
26.图7为本技术实施例示出的一种电子设备的硬件结构示意图。
具体实施方式
27.下面将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的设备和方法的例子。
28.在本技术使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本技术。在本技术和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在可以包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。还应当理解，本文中所使用的词语“如果”，取决于语境，可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
29.基于此，本技术提出一种服务路由方法。该方法可以应用于服务系统。所述服务系统包括前端与后端。所述后端维护了场景参数与服务路由信息的对应关系；所述场景参数用于表征与服务请求对应的需求场景；所述服务路由信息用于引导服务流程。所述方法可以包括：接收所述前端发起的与目标需求场景对应的目标服务请求；响应于接收到所述目标服务请求，获取与所述目标需求场景相关的目标场景参数；根据所述目标场景参数以及所述对应关系，确定目标服务路由信息；基于所述目标服务路由信息，将服务流程路由至与所述目标服务路由信息对应的目标服务实现方式。
30.前述方案中，在前端利用与需求场景相关的场景参数来表征与目标服务请求对应的目标需求场景，在后端可以基于所述场景参数，以及根据维护的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息，并基于所述目标服务路由信息，将服务流程路由至目标服务实现方式以提供服务，以实现灵活轻量的路由方式。
31.与相关技术相比，第一，前端只需生成与目标需求场景对应的服务请求，无需根据用户操作判断需要调用的接口，即不存在判断逻辑，从而减轻了前端压力；第二，后端可以根据场景参数，以及根据维护的场景参数与服务路由信息之间的对应关系，确定相应的目
标服务路由信息进行服务路由，在需求场景多种多样，服务请求的类型也多种多样，每一种服务请求也多种多样的情形下，只需通过场景参数来表征多种需求场景，并且以利用所述场景参数与所述对应关系来进行服务路由的方式代替接口路由的方式，从而减少接口数量，降低代码的修改与维护的难度和复杂度，提升系统安全性。
32.以下结合附图进行实施例说明。请参见图1，图1为本技术实施例示出的一种服务路由方法的方法流程示意图。
33.图1示出的服务路由方法(以下简称服务路由方法)可以应用于服务系统。
34.所述服务系统是指基于物理计算机，以及物理计算机搭载的软件装置所组成的系统。所述服务系统可以为用户提供服务。例如，在政务服务场景中，服务系统可以为用户提供登录服务，鉴权服务，账号查询服务，修改秘钥服务等。
35.所述服务系统包括前端与后端。
36.所述前端一般用于与用户交互，向后端反馈用户发起的请求，所述后端用于响应于所述请求向用户提供服务。
37.所述服务(service)是一种应用程序类型，它在后台运行。服务应用程序通常可以通过网络为用户提供一些功能，例如，账号登录功能，修改秘钥功能，鉴权服务等。
38.所述后端中一般会预先部署好各种服务，以及各种服务对应的实现方式，所述后端需要根据用户的需求场景，将服务路由到具体的实现方式，以基于所述实现方式提供相应服务。
39.所述需求场景用于指示用户需求。所述前端根据用户当前操作可以确定的用户当前的需求场景。
40.所述服务路由是指针对不同需求场景，将服务流程引导至合适的服务实现上的过程。在一些方式中，可以通过路由重定向的方式进行所述引导。例如，确定当前需求场景为刷脸登录场景，则可以将路由地址重定向至与刷脸登录对应的实现上去，以提供刷脸登录服务。
41.本技术中，所述后端可以预先维护场景参数与服务路由信息的对应关系。所述多维度的场景参数用于表征与服务请求对应的需求场景；所述服务路由信息用于引导服务流程。
42.在一些实施例中，所述场景参数的维度可以包括以下至少两种：账号类型；端类型；平台渠道；账号来源；登录类型。
43.通过所述账号类型可以描述需求场景中的用户的用户类型。即所述用户是个人、法人还是管理员等。
44.通过所述端类型可以描述需求场景中用户是在管理端还是客户端进行操作。
45.通过所述平台渠道可以描述需求场景中用户请求的来源，即用户是在pc端，移动端，一体机端，专用pad端发起的请求。
46.通过所述账号来源可以描述需求场景中的用户是外部账号还是内部账号。
47.通过所述登录类型可以描述需求场景中的用户请求的登录服务类型。即用户描述选择的是短信登录，刷脸登录，账密登录，一键授权登录还是单点登录等。
48.通过改变以上的场景参数可以描述不同的需求场景，也可以影响后续的服务路由。
49.后端在接收到所述服务请求后可以获取与目标需求场景相关的目标场景参数，以根据所述对应关系确定目标服务路由信息，完成服务路由。
50.如图1所示，所述方法可以包括s102-s108。除特别说明外，本技术不特别限定这些步骤的执行顺序。
51.s102，接收所述前端发起的与目标需求场景对应的目标服务请求。
52.所述前端可以根据用户当前操作确定的用户当前的目标需求场景。举例来说，所述前端可以向用户提供界面供用户进行操作，假设在登录界面，用户选择了刷脸登录操作，即所述前端可以响应于用户选择了刷脸登录操作，确定当前为用户刷脸登录场景。
53.所述前端可以响应于用户操作，生成与目标需求场景对应的目标服务请求；然后将所述目标服务请求发送至与所述前端对应的后端。
54.继续前面例子，前端在确定当前为用户刷脸登录场景之后，即可生成与用户刷脸登录场景对应的刷脸登录请求。
55.在一些方式中，前端可以先根据当前环境生成与目标需求场景相关的多维度的目标场景参数，然后基于这些目标场景参数，生成所述目标服务请求。
56.以前面例子为例，前端可以根据所述用户输入的用户账号，生成账号类型(比如是个人账户)和账号来源(比如是注册的外部账号)，根据当前运行环境生成端类型(比如是客户端)和平台渠道(比如是移动端)，以及根据用户触发的刷脸登录操作生成登录类型。生成的所述账号类型和账号来源，所述端类型和平台渠道以及所述登录类型即可描述来自移动端的外部个人账户通过客户端发起刷脸登录的需求场景，并可以根据这些场景参数生成刷脸登录服务请求。
57.在一些方式中，前端可以基于这些目标场景参数，以下至少一种方式，生成所述目标服务请求：
58.将这些目标场景参数添加到与所述目标服务请求对应的标签定义文档的标头(header)；
59.将这些目标场景参数添加到与所述目标服务请求对应的地址栏参数(url param)；
60.将这些目标场景参数添加到与所述目标服务请求对应的cookie文件。
61.具体添加方法可以参照相关技术在此不作详述。
62.s104，响应于接收到所述目标服务请求，获取与所述目标需求场景相关的目标场景参数。
63.在一些实施例中，所述目标场景参数是多维度的参数，与前端生成目标服务请求的方式相对应的，获取与所述目标需求场景相关的多维度的目标场景参数的获取路径包括以下至少一种：
64.与所述目标服务请求对应的标签定义文档的标头；与所述目标服务请求对应的地址栏参数；与所述目标服务请求对应的cookie文件。
65.例如，可以通过查询标签定义文档的标头，地址栏参数或cookie文件即可获取与所述目标需求场景相关的多维度的目标场景参数。
66.在一些实施例中，三种获取路径可以相互补充，避免由于某一种或某两种路径中缺少部分目标场景参数而导致无法获取完整的目标场景参数，进而无法准确进行服务路
由。
67.请参见图2，图2为本技术实施例示出的一种目标场景参数获取方法的流程示意图。图2示出的方法为对s104的补充说明。如图2所示，所述方法可以包括s202-s204。
68.s202，响应于从所述获取路径中的第一获取路径并未获取到全部的场景参数，采用第二获取路径获取剩余场景参数。
69.本技术为了对三种获取路径进行区分分别命名为第一获取路径，第二获取路径，以及第三获取路径。第一获取路径可以是前述三种获取路径中的任一种，第二获取路径可以是除第一获取路局以外的剩余两种中的任一种，第三获取路局为最后剩余的路径。例如，所述第一获取路径是从标签定义文档的标头获取目标场景参数，第二获取路径是从cookie文件获取目标场景参数，第三获取路径是从地址栏参数获取目标场景参数。
70.假设所述目标场景参数包括账号类型；端类型；平台渠道；账号来源；登录类型五种参数。本步骤中如果通过第一获取路径仅获取到其中两种参数，可以继续通过第二获取路径获取剩余三种参数。如果通过所述第二获取路径获取到剩余三种参数，则完成目标场景参数的获取。如果通过所述第二获取路径并未获取到剩余三种参数，则继续s204。
71.s204，响应于采用所述第二获取路径并未获取到全部剩余场景参数，采用第三获取路径获取剩余场景参数。
72.继续前面例子，本步骤中如果通过第二获取路径仅获取到所述剩余三种参数中的一种，则可以继续采用第三获取路径获取还未获取的两种参数。
73.通过s202-s204记载的获取方案，可以将三种获取路径相互补充，避免由于某一种或某两种路径中缺少部分目标场景参数而导致无法获取完整的目标场景参数，进而无法准确进行服务路由。
74.s106，根据所述目标场景参数以及所述对应关系，确定目标服务路由信息。
75.根据对应关系的维护方式不同可以有多种确定目标服务路由信息的方式。以下示例性示意两种情形。
76.第一种情形，所述对应关系包括所述多维度的场景参数与需求场景之间的第一对应关系，以及所述需求场景与所述服务路由信息之间的第二对应关系；所述后端包括路由层；所述路由层存储了所述第一对应关系与所述第二对应关系。
77.请参见图3，图3为本技术实施例示出的一种服务路由场景示意图。如图3所示，前端可以根据用户操作，生成携带与需求场景相关的多维度的目标场景参数的服务请求，并发送至后端。
78.后端可以包括路由层与服务层。其中，路由层中可以存储所述第一对应关系与所述第二对应关系，以及根据所述目标场景参数以及所述第一对应关系确定目标需求场景，然后根据确定的所述目标场景参数以及所述第二对应关系确定目标服务路由信息。服务层可以包括与多种服务实现方式分别对应的服务。路由层可以根据确定的目标服务路由信息，将服务流程路由至相应的服务中。
79.由此可以通过后端的路由层完成需求场景和服务实现的匹配完成服务路由，从而可以减轻前端压力。
80.不过第一种情形中，随着服务实现方式和需求场景的增多，代码维护复杂度会越来越大。由此可以引入第二种情形解决这个问题。
81.第二种情形，所述场景参数为多维度的参数；以将所述多维度的场景参数存储为匹配条件，将服务路由信息存储为命中所述匹配条件的输出结果的方式维护所述对应关系。
82.在一些方式，所述后端可以将匹配条件与其对应的输出结果以数组的形式进行存储。以参数包括前述五种参数为例，数组可以至少包括6个元素，其中的五个元素用于存储五种场景参数，剩余的一个元素用于维护对应的输出结果。
83.在第一种情形中，所述后端可以将多维度的所述目标场景参数，与存储的每一匹配条件进行匹配。具体地，可以将每一数组中与匹配条件对应的元素进行匹配。
84.然后，根据与多维度的所述目标场景参数匹配的目标匹配条件的输出结果，确定所述目标服务路由信息。具体地，可以那个匹配中的目标数组中与输出结果对应的元素，作为所述目标服务路由信息。
85.第二种情形中，通过匹配条件与输出结果这样的策略模式的方式来进行服务路由，在需求场景和服务实现方式增多或改变的情形下，通过重写匹配条件与输出结果的方式即可进行响应调整，维护起来更简单且难度低。
86.s108，基于所述目标服务路由信息，将服务流程路由至与所述目标服务路由信息对应的目标服务实现方式。
87.所述目标服务路由信息可以是目标服务实现方式对应的页面的地址信息(比如，url地址)，将所述页面的地址信息作为所述目标服务路由信息可以使前端向用户提供所述页面，使用户与所述页面交互完成服务。
88.前述方案中通过s102-s108记载的步骤，可以在前端利用与需求场景相关的场景参数来表征与目标服务请求对应的目标需求场景，在后端可以基于所述场景参数，以及根据维护的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息，并基于所述目标服务路由信息，将服务流程路由至目标服务实现方式以提供服务，以实现灵活轻量的路由方式。
89.与相关技术相比，第一，前端只需生成与目标需求场景对应的服务请求，无需根据用户操作判断需要调用的接口，即不存在判断逻辑，从而减轻了前端压力；第二，后端可以根据场景参数，以及根据维护的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息进行服务路由，在需求场景多种多样，服务请求的类型也多种多样，每一种服务请求也多种多样的情形下，只需通过场景参数来表征多种需求场景，并且以利用所述场景参数与所述对应关系来进行服务路由的方式代替接口路由的方式，从而减少接口数量，降低代码的修改与维护的难度和复杂度，提升系统安全性。
90.以下以政务系统为例进行实施例说明。
91.请参见图4，图4为本技术实施例示出的一种政务系统示意图。如图4所示，政务系统可以包括为与用户交互的前端，以及提供服务的用户中心(后端)。其中前端包括与管理员交互的管理端(g端)，以及与用户交互的客户端(c端)。g端和c端分别包括多种平台渠道。其中根据需求，app渠道和帮办pad确定需要通过无线网关连接至统一门户，再通过统一门户与用户中心进行交互，pc渠道和小程序渠道可以直接通过统一门户与用户中心进行交互。
92.所述用户中心可以数组形式维护多组场景参数与服务路由信息的对应关系。
93.本例中，假设需求场景为外部个人用户a通过c端中的pc渠道发起刷脸登录操作。
94.请参见图5，图5为本技术实施例示出的一种服务路由流程示意图。如图5所示，所述方法可以包括：
95.s501，前端响应于用户操作，获取与当前需求场景相关的目标场景参数。
96.本步骤中，pc端可以响应于用户a的刷脸登录操作，将账号类型设置为个人账户，将端类型设置为c端；将平台渠道设置为pc渠道，将账号来源设置为外部账号，将登录类型设置为刷脸登录，由此可以通过五个维度的目标场景参数描述外部个人用户a通过c端中的pc渠道发起刷脸登录操作这个需求场景。
97.s502，前端基于所述目标场景参数，生成登录服务请求。
98.本步骤中，前端可以将5个维度的目标场景参数添加至url参数、header以及cookie文件中，完成登录服务请求的生成。
99.s503，前端将所述登录服务请求发送至用户中心。
100.s504，用户中心响应于接收到所述登录服务请求，获取所述目标场景参数。
101.本步骤中，用户中心可以通过所述url参数、所述header以及所述cookie文件三种获取路径获取所述目标场景参数。其具体过程可以参见前述实施例，在此不做限定。
102.s505，用户中心根据所述目标场景参数与存储的各数组进行匹配，并将匹配中的目标数组维护的服务路由信息确定为目标服务路由信息。
103.本步骤中，可以将目标场景参数与存储的每一数据中的元素进行匹配，找到匹配中的目标数组，然后将所述目标数组中维护的服务路由信息确定为目标服务路由信息。
104.s506，用户中心根据所述目标服务路由信息将路由流程路由至目标页面完成服务。
105.本步骤中，可以将与利用第一app进行刷脸认证的服务页面的url地址作为所述目标服务路由信息，以基于所述url地址，向用户展示所述刷脸认证的服务页面，完成刷脸登录。
106.前述方案中，第一，c端只需生成刷脸登录服务请求，无需根据用户操作判断需要调用的接口，即不存在判断逻辑，实现了c端轻量化；
107.第二，后端可以根据五维度的场景参数，以及根据维护的五维度的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息进行服务路由，在需求场景多种多样，服务请求的类型也多种多样，每一种服务请求也多种多样的情形下，只需通过多维度的场景参数来表征多种需求场景，并且通过所述场景参数与所述对应关系来进行服务路由的方式代替接口路由的方式，从而减少接口数量，降低代码的修改与维护的难度和复杂度，提升系统安全性。
108.本技术还提出一种服务路由方法，应用于服务系统包括的前端。所述服务系统还包括与所述前端对应的后端；所述后端维护了多维度的场景参数与服务路由信息的对应关系，所述多维度的场景参数用于表征与服务请求对应的需求场景，所述服务路由信息用于引导服务流程；所述方法包括：
109.响应于用户操作，生成与目标需求场景对应的目标服务请求；
110.将所述目标服务请求发送至与所述前端对应的后端，以使所述后端响应于接收到所述目标服务请求，获取与所述目标需求场景相关的多维度的目标场景参数，根据多维度
的所述目标场景参数以及所述对应关系，确定目标服务路由信息，以及，基于所述目标服务路由信息，将服务流程路由至与所述目标服务路由信息对应的目标服务实现方式。
111.关于该方法的详细说明可以参照相关实施例，在此不做详述。
112.该方法中，第一，前端只需生成与目标需求场景对应的服务请求，无需根据用户操作判断需要调用的接口，即不存在判断逻辑，从而减轻了前端压力；第二，后端可以根据多维度的场景参数，以及根据维护的多维度的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息进行服务路由，在需求场景多种多样，服务请求的类型也多种多样，每一种服务请求也多种多样的情形下，只需通过多维度的场景参数来表征多种需求场景，并且以利用所述场景参数与所述对应关系来进行服务路由的方式代替接口路由的方式，从而减少接口数量，降低代码的修改与维护的难度和复杂度，提升系统安全性。
113.与所述任一实施例相对应的，本技术还提出一种服务路由装置。所述服务路由装置可以应用于服务系统；所述服务系统包括前端与后端；所述后端维护了多维度的场景参数与服务路由信息的对应关系；所述多维度的场景参数用于表征与服务请求对应的需求场景；所述服务路由信息用于引导服务流程。
114.请参见图6，图6为本技术实施例示出的一种服务路由装置的结构示意图。如图6所示，所示服务路由装置600可以包括：
115.接收模块610，接收所述前端发起的与目标需求场景对应的目标服务请求；
116.获取模块620，响应于接收到所述目标服务请求，获取与所述目标需求场景相关的目标场景参数；
117.确定模块630，根据所述目标场景参数以及所述对应关系，确定目标服务路由信息；
118.路由模块640，基于所述目标服务路由信息，将服务流程路由至与所述目标服务路由信息对应的目标服务实现方式。
119.在一些实施例中，所述目标场景参数为多维度参数；获取与所述目标需求场景相关的多维度的目标场景参数的获取路径包括以下至少一种：
120.与所述目标服务请求对应的标签定义文档的标头；与所述目标服务请求对应的地址栏参数；与所述目标服务请求对应的cookie文件。
121.在一些实施例中，获取模块620进一步：
122.响应于从所述获取路径中的第一获取路径并未获取到全部的场景参数，采用第二获取路径获取剩余场景参数；
123.响应于采用所述第二获取路径并未获取到全部剩余场景参数，采用第三获取路径获取剩余场景参数。
124.在一些实施例中，所述场景参数为多维度的参数；以将多维度的所述场景参数存储为匹配条件，将服务路由信息存储为命中所述匹配条件的输出结果的方式维护所述对应关系；
125.所述确定模块630进一步：
126.将多维度的所述目标场景参数，与存储的每一匹配条件进行匹配；
127.根据与多维度的所述目标场景参数匹配的目标匹配条件的输出结果，确定所述目标服务路由信息。
128.在一些实施例中，所述对应关系包括所述场景参数与需求场景之间的第一对应关系，以及所述需求场景与所述服务路由信息之间的第二对应关系；所述后端包括路由层；所述路由层存储了所述第一对应关系与所述第二对应关系；
129.所述确定模块630进一步：
130.通过所述路由层，根据所述目标场景参数以及所述第一对应关系确定目标需求场景；
131.根据确定的所述目标需求场景以及所述第二对应关系确定目标服务路由信息。
132.在一些实施例中，所述多维度的场景参数包括以下至少两种：
133.账号类型；端类型；平台渠道；账号来源；登录类型。
134.在一些实施例中，所述装置还包括：
135.生成模块，所述前端响应于用户操作，生成与目标需求场景对应的目标服务请求；
136.发送模块，将所述目标服务请求发送至与所述前端对应的后端。
137.前述方案中，在前端利用与需求场景相关的场景参数来表征与目标服务请求对应的目标需求场景，在后端可以基于所述场景参数，以及根据维护的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息，并基于所述目标服务路由信息，将服务流程路由至目标服务实现方式以提供服务，以实现灵活轻量的路由方式。
138.与相关技术相比，第一，前端只需生成与目标需求场景对应的服务请求，无需根据用户操作判断需要调用的接口，即不存在判断逻辑，从而减轻了前端压力；第二，后端可以根据场景参数，以及根据维护的场景参数与服务路由信息之间的对应关系，确定相应的目标服务路由信息进行服务路由，在需求场景多种多样，服务请求的类型也多种多样，每一种服务请求也多种多样的情形下，只需通过场景参数来表征多种需求场景，并且以利用所述场景参数与所述对应关系来进行服务路由的方式代替接口路由的方式，从而减少接口数量，降低代码的修改与维护的难度和复杂度，提升系统安全性。
139.本技术示出的服务路由装置的实施例可以应用于电子设备上。相应地，本技术公开了一种电子设备，该设备可以包括：处理器。
140.用于存储处理器可执行指令的存储器。
141.其中，所述处理器被配置为调用所述存储器中存储的可执行指令，实现前述任一实施例示出的服务路由方法。
142.请参见图7，图7为本技术实施例示出的一种电子设备的硬件结构示意图。
143.如图7所示，该电子设备可以包括用于执行指令的处理器，用于进行网络连接的网络接口，用于为处理器存储运行数据的内存，以及用于存储服务路由装置对应指令的非易失性存储器。
144.其中，所述装置的实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，除了图7所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。
145.可以理解的是，为了提升处理速度，所述服务路由装置对应指令也可以直接存储于内存中，在此不作限定。
146.本技术提出一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序可以用于使处理器执行前述任一实施例示出的服务路由方法。
147.本领域技术人员应明白，本技术一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本技术一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(可以包括但不限于磁盘存储器、cdrom、光学存储器等)上实施的计算机程序产品的形式。
148.本技术中的“和/或”表示至少具有两者中的其中一个，例如，“a和/或b”可以包括三种方案：a、b、以及“a和b”。
149.本技术中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于数据处理设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
150.以上对本技术特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的行为或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
151.本技术中描述的主题及功能路由的实施例可以在以下中实现：数字电子电路、有形体现的计算机软件或固件、可以包括本技术中公开的结构及其结构性等同物的计算机硬件、或者它们中的一个或多个的组合。本技术中描述的主题的实施例可以实现为一个或多个计算机程序，即编码在有形非暂时性程序载体上以被数据处理装置执行或控制数据处理装置的路由的计算机程序指令中的一个或多个模块。可替代地或附加地，程序指令可以被编码在人工生成的传播信号上，例如机器生成的电、光或电磁信号，该信号被生成以将信息编码并传输到合适的接收机装置以由数据处理装置执行。计算机存储介质可以是机器可读存储设备、机器可读存储基板、随机或串行存取存储器设备、或它们中的一个或多个的组合。
152.本技术中描述的处理及逻辑流程可以由执行一个或多个计算机程序的一个或多个可编程计算机执行，以通过根据输入数据进行路由并生成输出来执行相应的功能。所述处理及逻辑流程还可以由专用逻辑电路—例如fpga(现场可编程门阵列)或asic(专用集成电路)来执行，并且装置也可以实现为专用逻辑电路。
153.适合用于执行计算机程序的计算机可以包括，例如通用和/或专用微处理器，或任何其他类型的处理单元。通常，处理单元将从只读存储器和/或随机存取存储器接收指令和数据。计算机的基本组件可以包括用于实施或执行指令的处理单元以及用于存储指令和数据的一个或多个存储器设备。通常，计算机还将可以包括用于存储数据的一个或多个大容量存储设备，例如磁盘、磁光盘或光盘等，或者计算机将可路由地与此大容量存储设备耦接以从其接收数据或向其传送数据，抑或两种情况兼而有之。然而，计算机不是必须具有这样的设备。此外，计算机可以嵌入在另一设备中，例如移动电话、个人数字助理(pda)、移动音频或视频播放器、游戏操纵台、全球定位系统(gps)接收机、或例如通用串行总线(usb)闪存
驱动器的便携式存储设备，仅举几例。
154.适合于存储计算机程序指令和数据的计算机可读介质可以包括所有形式的非易失性存储器、媒介和存储器设备，例如可以包括半导体存储器设备(例如eprom、eeprom和闪存设备)、磁盘(例如内部硬盘或可移动盘)、磁光盘以及cd rom和dvdrom盘。处理器和存储器可由专用逻辑电路补充或并入专用逻辑电路中。
155.虽然本技术包含许多具体实施细节，但是这些不应被解释为限制任何公开的范围或所要求保护的范围，而是主要用于描述特定公开的具体实施例的特征。本技术内在多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面，在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外，虽然特征可以如所述在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除，并且所要求保护的组合可以指向子组合或子组合的变型。
156.类似地，虽然在附图中以特定顺序描绘了路由，但是这不应被理解为要求这些路由以所示的特定顺序执行或顺次执行、或者要求所有例示的路由被执行，以实现期望的结果。在某些情况下，多任务和并行处理可能是有利的。此外，所述实施例中的各种系统模块和组件的分离不应被理解为在所有实施例中均需要这样的分离，并且应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中，或者封装成多个软件产品。
157.由此，主题的特定实施例已被描述。其他实施例在所附权利要求书的范围以内。在某些情况下，权利要求书中记载的动作可以以不同的顺序执行并且仍实现期望的结果。此外，附图中描绘的处理并非必需所示的特定顺序或顺次顺序，以实现期望的结果。在某些实现中，多任务和并行处理可能是有利的。
158.以上仅为本技术一个或多个实施例的较佳实施例而已，并不用以限制本技术一个或多个实施例，凡在本技术一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本技术一个或多个实施例保护的范围之内。