Service routing method, device, equipment and storage medium

Abstract

The present application proposes a service routing method, device, equipment and storage medium. The method can be applied to a service system. The service system includes a front end and a back end; the back end maintains the correspondence between scenario parameters and service routing information; the scenario parameters are used to characterize the demand scenario corresponding to the service request; the service routing information is used to guide the service process; the method may include: receiving a target service request corresponding to the target demand scenario initiated by the front end; in response to receiving the target service request, obtaining target scenario parameters related to the target demand scenario; determining the target service routing information according to the target scenario parameters and the correspondence; based on the target service routing information, routing the service process to the target service implementation method corresponding to the target service routing information to provide services, so as to achieve a flexible and lightweight routing method.

Description

Technical Field

[0001] The present application relates to computer technology, and in particular to a service routing method, apparatus, device and storage medium. Background Art

[0002] In the service industry, users will initiate different types of service requests to the service platform according to different demand scenarios. The service platform needs to route the service process to the corresponding service according to the demand scenario. For example, in the login scenario, the user initiates a face-scanning login request through the client, and the service platform needs to route the service process to the face-scanning login service.

[0003] However, there are many different user scenarios and types of service requests. For example, in a login scenario, a user can initiate a face recognition login request, a fingerprint login request, a one-click login request, an account and password login request, etc. Among them, the implementation methods of each service request are also various. For example, for a face recognition login request, it can include using the first APP to scan the face, using the second APP to scan the face, etc.

[0004] At present, service routing is performed by maintaining a corresponding interface for each implementation of each service for the front-end to call. Specifically, the front-end will determine the interface corresponding to the target implementation of the target service that the user needs to call based on the user's operation, and then the back-end will route to the target implementation to provide services based on the interface called by the front-end.

[0005] In this way, first, the front end needs to determine the interface to call based on user operations, and such judgment logic will make the front end heavier; second, as the service types and implementation methods of the back end increase, the number of interfaces will increase, and each time an interface is added, the front-end and back-end codes need to be modified, which is time-consuming and cumbersome; third, the more interfaces there are, the more cumbersome and redundant the work of managing the interfaces is, the greater the risk of the system being attacked from the outside, and the poorer the security. Summary of the invention

[0006] In view of this, the present application discloses at least one service routing method. The method can be applied to a service system; the service system includes a front end and a back end; the back end maintains a correspondence between scenario parameters and service routing information; the scenario parameters are used to characterize a demand scenario corresponding to a service request; the service routing information is used to guide a service process; the method may include: receiving a target service request corresponding to a target demand scenario initiated by the front end; in response to receiving the target service request, obtaining a target scenario parameter related to the target demand scenario; determining the target service routing information according to the target scenario parameter and the correspondence; and routing the service process to a target service implementation method corresponding to the target service routing information based on the target service routing information.

[0007] In some embodiments, the target scenario parameters are multi-dimensional parameters; the acquisition path for obtaining the multi-dimensional target scenario parameters related to the target demand scenario includes at least one of the following: the header of the tag definition document corresponding to the target service request; the address bar parameters corresponding to the target service request; the Cookie file corresponding to the target service request.

[0008] In some embodiments, the acquiring of multi-dimensional target scenario parameters related to the target demand scenario includes: in response to not acquiring all the scenario parameters from the first acquisition path in the acquisition path, acquiring the remaining scenario parameters using the second acquisition path; in response to not acquiring all the remaining scenario parameters using the second acquisition path, acquiring the remaining scenario parameters using the third acquisition path.

[0009] In some embodiments, the scene parameters are multi-dimensional parameters; the correspondence is maintained in a manner that the multi-dimensional scene parameters are stored as matching conditions and the service routing information is stored as an output result of hitting the matching conditions; determining the target service routing information based on the target scene parameters and the corresponding relationship includes: matching the multi-dimensional target scene parameters with each stored matching condition; determining the target service routing information based on the output result of the target matching condition that matches the multi-dimensional target scene parameters.

[0010] In some embodiments, the correspondence includes a first correspondence between the scenario parameters and the demand scenario, and a second correspondence between the demand scenario and the service routing information; the backend includes a routing layer; the routing layer stores the first correspondence and the second correspondence; determining the target service routing information according to the target scenario parameters and the correspondence includes: determining the target demand scenario according to the target scenario parameters and the first correspondence through the routing layer; determining the target service routing information according to the determined target demand scenario and the second correspondence.

[0011] In some embodiments, the dimensions of the scenario parameters include at least two of the following: account type; terminal type; platform channel; account source; login type.

[0012] In some embodiments, before receiving a target service request corresponding to a target demand scenario initiated by the front end, the method further includes: the front end generates a target service request corresponding to the target demand scenario in response to a user operation; and sends the target service request to a back end corresponding to the front end.

[0013] The present application also proposes a service routing device, which is applied to a service system; the service system includes a front end and a back end; the back end maintains the correspondence between scenario parameters and service routing information; the scenario parameters are used to characterize the demand scenario corresponding to the service request; the service routing information is used to guide the service process; the device includes: a receiving module, which receives a target service request initiated by the front end and corresponding to the target demand scenario; an acquisition module, which acquires target scenario parameters related to the target demand scenario in response to receiving the target service request; a determination module, which determines the target service routing information according to the target scenario parameters and the correspondence; and a routing module, which routes the service process to the target service implementation method corresponding to the target service routing information based on the target service routing information.

[0014] The present application also proposes an electronic device, comprising: a processor; and a memory for storing processor executable instructions; wherein the processor implements the service routing method as shown in any of the aforementioned embodiments by running the executable instructions.

[0015] The present application also proposes a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program is used to enable a processor to execute the service routing method shown in any of the aforementioned embodiments.

[0016] In the above-mentioned scheme, the scenario parameters related to the demand scenario are used at the front end to characterize the target demand scenario corresponding to the target service request. The back end can determine the corresponding target service routing information based on the scenario parameters and the correspondence between the maintained scenario parameters and the service routing information. Based on the target service routing information, the service process is routed to the target service implementation method to provide the service, so as to realize a flexible and lightweight routing method.

[0017] Compared with related technologies, first, the front end only needs to generate a service request corresponding to the target demand scenario, and there is no need to determine the interface that needs to be called according to the user operation, that is, there is no judgment logic, which reduces the pressure on the front end; second, the back end can determine the corresponding target service routing information for service routing based on the scenario parameters and the correspondence between the maintained scenario parameters and the service routing information. When there are various demand scenarios, various types of service requests, and each service request is also diverse, it is only necessary to characterize the various demand scenarios through scenario parameters, and replace the interface routing method with the method of using the scenario parameters and the correspondence to perform service routing, thereby reducing the number of interfaces, reducing the difficulty and complexity of code modification and maintenance, and improving system security.

[0018] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in one or more embodiments of the present application or related technologies, the drawings required for use in the embodiments or related technology descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in one or more embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0020] Figure 1 A schematic diagram of a method flow of a service routing method shown in an embodiment of the present application;

[0021] Figure 2 A schematic diagram of a process for obtaining target scene parameters shown in an embodiment of the present application;

[0022] Figure 3 A schematic diagram of a service routing scenario shown in an embodiment of the present application;

[0023] Figure 4 A schematic diagram of an e-government system shown in an embodiment of the present application;

[0024] Figure 5 A schematic diagram of a service routing process shown in an embodiment of the present application;

[0025] Figure 6 A schematic diagram of the structure of a service routing device shown in an embodiment of the present application;

[0026] Figure 7 A schematic diagram of the hardware structure of an electronic device shown in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The exemplary embodiments will be described in detail below, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0028] The terms used in this application are only for the purpose of describing specific embodiments, and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to and includes any or all possible combinations of one or more associated listed items. It should also be understood that the word "if" used in this article, depending on the context, can be interpreted as "at the time of" or "when" or "in response to determining".

[0029] Based on this, the present application proposes a service routing method. The method can be applied to a service system. The service system includes a front end and a back end. The back end maintains the correspondence between scenario parameters and service routing information; the scenario parameters are used to characterize the demand scenario corresponding to the service request; the service routing information is used to guide the service process. The method may include: receiving a target service request initiated by the front end corresponding to the target demand scenario; in response to receiving the target service request, obtaining target scenario parameters related to the target demand scenario; determining the target service routing information based on the target scenario parameters and the correspondence; based on the target service routing information, routing the service process to the target service implementation method corresponding to the target service routing information.

[0030] In the above-mentioned scheme, the scenario parameters related to the demand scenario are used at the front end to characterize the target demand scenario corresponding to the target service request. The back end can determine the corresponding target service routing information based on the scenario parameters and the correspondence between the maintained scenario parameters and the service routing information. Based on the target service routing information, the service process is routed to the target service implementation method to provide the service, so as to realize a flexible and lightweight routing method.

[0031] Compared with related technologies, first, the front end only needs to generate a service request corresponding to the target demand scenario, and there is no need to determine the interface that needs to be called according to the user operation, that is, there is no judgment logic, which reduces the pressure on the front end; second, the back end can determine the corresponding target service routing information for service routing based on the scenario parameters and the correspondence between the maintained scenario parameters and the service routing information. When there are various demand scenarios, various types of service requests, and each service request is also diverse, it is only necessary to characterize the various demand scenarios through scenario parameters, and replace the interface routing method with the method of using the scenario parameters and the correspondence to perform service routing, thereby reducing the number of interfaces, reducing the difficulty and complexity of code modification and maintenance, and improving system security.

[0032] The following is an example description with reference to the accompanying drawings. Figure 1 , Figure 1 A method flow chart of a service routing method shown in an embodiment of the present application.

[0033] Figure 1 The service routing method shown (hereinafter referred to as the service routing method) can be applied to the service system.

[0034] The service system refers to a system composed of a physical computer and a software device installed on the physical computer. The service system can provide services to users. For example, in a government service scenario, the service system can provide users with login services, authentication services, account query services, key modification services, etc.

[0035] The service system includes a front end and a back end.

[0036] The front end is generally used to interact with the user and to feed back the request initiated by the user to the back end, and the back end is used to provide services to the user in response to the request.

[0037] The service is a type of application that runs in the background. The service application can usually provide users with some functions through the network, such as account login function, key modification function, authentication service, etc.

[0038] The backend generally pre-deploys various services and corresponding implementation methods of the services. The backend needs to route the services to specific implementation methods according to the user's demand scenarios, so as to provide corresponding services based on the implementation methods.

[0039] The demand scenario is used to indicate the user's demand. The front end can determine the user's current demand scenario according to the user's current operation.

[0040] The service routing refers to the process of guiding the service process to the appropriate service implementation for different demand scenarios. In some methods, the guidance can be performed by routing redirection. For example, if the current demand scenario is determined to be a face-scanning login scenario, the routing address can be redirected to the implementation corresponding to the face-scanning login to provide the face-scanning login service.

[0041] In the present application, the backend may maintain in advance the correspondence between the scenario parameters and the service routing information. The multi-dimensional scenario parameters are used to characterize the demand scenario corresponding to the service request; and the service routing information is used to guide the service process.

[0042] In some embodiments, the dimensions of the scenario parameters may include at least two of the following: account type; terminal type; platform channel; account source; login type.

[0043] The account type can be used to describe the user type of the user in the required scenario, that is, whether the user is an individual, a legal person, or an administrator.

[0044] The terminal type can be used to describe whether the user is operating on the management terminal or the client terminal in the demand scenario.

[0045] The platform channel can be used to describe the source of user requests in the demand scenario, that is, whether the user initiates the request on the PC, mobile, all-in-one, or dedicated PAD.

[0046] The account source can be used to describe whether the user in the demand scenario is an external account or an internal account.

[0047] The login type can be used to describe the type of login service requested by the user in the required scenario, that is, the user describes whether to select SMS login, face recognition login, account and password login, one-click authorization login or single sign-on, etc.

[0048] By changing the above scenario parameters, different demand scenarios can be described and subsequent service routing can also be affected.

[0049] After receiving the service request, the backend can obtain target scenario parameters related to the target demand scenario to determine the target service routing information according to the corresponding relationship and complete the service routing.

[0050] like Figure 1 As shown, the method may include S102-S108. Unless otherwise specified, the present application does not specifically limit the execution order of these steps.

[0051] S102, receiving a target service request initiated by the front end corresponding to a target demand scenario.

[0052] The front end can determine the user's current target demand scenario based on the user's current operation. For example, the front end can provide an interface for the user to operate. Assuming that the user selects the face recognition login operation on the login interface, the front end can determine that the current user face recognition login scenario is in response to the user selecting the face recognition login operation.

[0053] The front end may generate a target service request corresponding to a target demand scenario in response to a user operation; and then send the target service request to a back end corresponding to the front end.

[0054] Continuing with the previous example, after the front end determines that the current scenario is user face recognition login, it can generate a face recognition login request corresponding to the user face recognition login scenario.

[0055] In some methods, the front end may first generate multi-dimensional target scenario parameters related to the target demand scenario according to the current environment, and then generate the target service request based on these target scenario parameters.

[0056] Taking the previous example as an example, the front end can generate the account type (such as a personal account) and account source (such as a registered external account) according to the user account input by the user, generate the terminal type (such as a client) and platform channel (such as a mobile terminal) according to the current operating environment, and generate the login type according to the face-scanning login operation triggered by the user. The generated account type and account source, terminal type and platform channel, and login type can describe the demand scenario of an external personal account from a mobile terminal initiating face-scanning login through the client, and can generate a face-scanning login service request based on these scenario parameters.

[0057] In some embodiments, the front end may generate the target service request based on the target scenario parameters in at least one of the following ways:

[0058] Adding these target scenario parameters to the header of the tag definition document corresponding to the target service request;

[0059] Add these target scene parameters to the address bar parameter (urlParam) corresponding to the target service request;

[0060] These target scenario parameters are added to the Cookie file corresponding to the target service request.

[0061] The specific adding method can be referred to the relevant technology and will not be described in detail here.

[0062] S104: In response to receiving the target service request, obtaining target scenario parameters related to the target demand scenario.

[0063] In some embodiments, the target scenario parameter is a multi-dimensional parameter. Corresponding to the way in which the front end generates a target service request, the acquisition path of the multi-dimensional target scenario parameter related to the target demand scenario includes at least one of the following:

[0064] The header of the tag definition document corresponding to the target service request; the address bar parameter corresponding to the target service request; and the Cookie file corresponding to the target service request.

[0065] For example, the multi-dimensional target scenario parameters related to the target demand scenario can be obtained by querying the header of the tag definition document, the address bar parameters or the Cookie file.

[0066] In some embodiments, the three acquisition paths can complement each other to avoid the inability to acquire complete target scene parameters due to the lack of some target scene parameters in one or two paths, thereby preventing accurate service routing.

[0067] See also Figure 2 , Figure 2 A flowchart of a method for acquiring target scene parameters shown in an embodiment of the present application. Figure 2 The method shown is a supplementary description of S104. Figure 2 As shown, the method may include S202-S204.

[0068] S202: In response to not acquiring all the scene parameters through the first acquisition path in the acquisition paths, acquiring remaining scene parameters through the second acquisition path.

[0069] In order to distinguish the three acquisition paths, the present application names them as the first acquisition path, the second acquisition path, and the third acquisition path. The first acquisition path can be any of the three acquisition paths mentioned above, the second acquisition path can be any of the remaining two except the first acquisition path, and the third acquisition path is the last remaining path. For example, the first acquisition path is to obtain the target scene parameters from the header of the tag definition document, the second acquisition path is to obtain the target scene parameters from the Cookie file, and the third acquisition path is to obtain the target scene parameters from the address bar parameters.

[0070] Assume that the target scenario parameters include five parameters: account type; terminal type; platform channel; account source; and login type. In this step, if only two of the parameters are obtained through the first acquisition path, the remaining three parameters can be obtained through the second acquisition path. If the remaining three parameters are obtained through the second acquisition path, the acquisition of the target scenario parameters is completed. If the remaining three parameters are not obtained through the second acquisition path, continue to S204.

[0071] S204: In response to not acquiring all remaining scene parameters by adopting the second acquisition path, acquiring remaining scene parameters by adopting a third acquisition path.

[0072] Continuing with the previous example, in this step, if only one of the remaining three parameters is obtained through the second acquisition path, the third acquisition path can be continued to be used to obtain the two parameters that have not been obtained.

[0073] Through the acquisition scheme recorded in S202-S204, the three acquisition paths can complement each other to avoid the inability to obtain complete target scene parameters due to the lack of some target scene parameters in one or two paths, thereby preventing accurate service routing.

[0074] S106: Determine target service routing information according to the target scenario parameters and the corresponding relationship.

[0075] There are multiple ways to determine the target service routing information according to different ways of maintaining the corresponding relationship. The following examples illustrate two situations.

[0076] In the first case, the correspondence includes a first correspondence between the multi-dimensional scenario parameters and the demand scenario, and a second correspondence between the demand scenario and the service routing information; the backend includes a routing layer; the routing layer stores the first correspondence and the second correspondence.

[0077] See also Figure 3 , Figure 3 A schematic diagram of a service routing scenario shown in an embodiment of the present application. Figure 3 As shown, the front end can generate a service request carrying multi-dimensional target scenario parameters related to the demand scenario based on user operations and send it to the back end.

[0078] The backend may include a routing layer and a service layer. The first correspondence and the second correspondence may be stored in the routing layer, and the target demand scenario may be determined according to the target scenario parameters and the first correspondence, and then the target service routing information may be determined according to the determined target scenario parameters and the second correspondence. The service layer may include services corresponding to a plurality of service implementation methods. The routing layer may route the service process to the corresponding service according to the determined target service routing information.

[0079] In this way, the demand scenario and service implementation can be matched through the back-end routing layer to complete service routing, thereby reducing the pressure on the front-end.

[0080] However, in the first case, as the number of service implementation methods and demand scenarios increases, the complexity of code maintenance will increase. Therefore, the second case can be introduced to solve this problem.

[0081] In the second case, the scenario parameters are multi-dimensional parameters; the corresponding relationship is maintained in a manner of storing the multi-dimensional scenario parameters as matching conditions and storing the service routing information as output results that hit the matching conditions.

[0082] In some ways, the backend can store the matching conditions and the corresponding output results in the form of an array. Taking the example that the parameters include the above five parameters, the array can include at least 6 elements, five of which are used to store the five scene parameters, and the remaining element is used to maintain the corresponding output results.

[0083] In the first case, the backend may match the multi-dimensional target scene parameters with each stored matching condition. Specifically, the elements corresponding to the matching condition in each array may be matched.

[0084] Then, the target service routing information is determined according to the output result of the target matching condition that matches the multi-dimensional target scene parameters. Specifically, the element corresponding to the output result in the target array in the match can be used as the target service routing information.

[0085] In the second case, service routing is performed through a strategy pattern such as matching conditions and output results. When the demand scenarios and service implementation methods increase or change, responsive adjustments can be made by rewriting the matching conditions and output results, which is simpler and less difficult to maintain.

[0086] S108: Based on the target service routing information, route the service process to a target service implementation method corresponding to the target service routing information.

[0087] The target service routing information may be the address information (eg, URL address) of a page corresponding to the target service implementation method. Using the address information of the page as the target service routing information may enable the front end to provide the page to the user, allowing the user to interact with the page to complete the service.

[0088] Through the steps S102-S108 recorded in the aforementioned scheme, the target demand scenario corresponding to the target service request can be characterized at the front end using scenario parameters related to the demand scenario, and the corresponding target service routing information can be determined at the back end based on the scenario parameters and the correspondence between the maintained scenario parameters and the service routing information, and based on the target service routing information, the service process can be routed to the target service implementation method to provide the service, thereby realizing a flexible and lightweight routing method.

[0089] Compared with related technologies, first, the front end only needs to generate a service request corresponding to the target demand scenario, and there is no need to determine the interface that needs to be called according to the user operation, that is, there is no judgment logic, which reduces the pressure on the front end; second, the back end can determine the corresponding target service routing information for service routing based on the scenario parameters and the correspondence between the maintained scenario parameters and the service routing information. When there are various demand scenarios, various types of service requests, and each service request is also diverse, it is only necessary to characterize the various demand scenarios through scenario parameters, and replace the interface routing method with the method of using the scenario parameters and the correspondence to perform service routing, thereby reducing the number of interfaces, reducing the difficulty and complexity of code modification and maintenance, and improving system security.

[0090] The following is an explanation of the embodiment using a government affairs system as an example.

[0091] See also Figure 4 , Figure 4 This is a schematic diagram of a government affairs system shown in an embodiment of the present application. Figure 4 As shown, the government affairs system may include a front end for interacting with users, and a user center (back end) that provides services. The front end includes a management end (G end) that interacts with administrators, and a client end (C end) that interacts with users. The G end and the C end include a variety of platform channels. According to the needs, the APP channel and the assistant PAD determine that they need to be connected to the unified portal through a wireless gateway, and then interact with the user center through the unified portal. The PC channel and the mini program channel can directly interact with the user center through the unified portal.

[0092] The user center may maintain the correspondence between multiple sets of scene parameters and service routing information in an array form.

[0093] In this example, it is assumed that the demand scenario is that an external individual user A initiates a face recognition login operation through the PC channel on the C-end.

[0094] See also Figure 5 , Figure 5 A schematic diagram of a service routing process shown in an embodiment of the present application. Figure 5 As shown, the method may include:

[0095] S501, the front end responds to the user operation and obtains the target scenario parameters related to the current demand scenario.

[0096] In this step, the PC side can respond to the face recognition login operation of user A by setting the account type to personal account and the terminal type to C-side; setting the platform channel to PC channel, setting the account source to external account, and setting the login type to face recognition login. In this way, the target scenario parameters of five dimensions can be used to describe the demand scenario in which external individual user A initiates a face recognition login operation through the PC channel in the C-side.

[0097] S502: The front end generates a login service request based on the target scenario parameters.

[0098] In this step, the front end can add the target scenario parameters of the five dimensions to the URL parameters, Header and Cookie files to complete the generation of the login service request.

[0099] S503, the front end sends the login service request to the user center.

[0100] S504: In response to receiving the login service request, the user center obtains the target scene parameters.

[0101] In this step, the user center can obtain the target scene parameters through three acquisition paths: the URL parameter, the Header, and the Cookie file. The specific process can be referred to in the above embodiment and is not limited here.

[0102] S505: The user center matches the target scenario parameters with the stored arrays, and determines the service routing information maintained by the target array in the matching as the target service routing information.

[0103] In this step, the target scenario parameters may be matched with the elements in each stored data to find the matching target array, and then the service routing information maintained in the target array may be determined as the target service routing information.

[0104] S506, the user center routes the routing process to the target page to complete the service according to the target service routing information.

[0105] In this step, the URL address of the service page for face recognition authentication using the first APP can be used as the target service routing information, so as to display the face recognition authentication service page to the user based on the URL address to complete face recognition login.

[0106] In the above solution, first, the C-end only needs to generate a face-scanning login service request, and does not need to determine the interface to be called based on the user operation. That is, there is no judgment logic, which makes the C-end lightweight.

[0107] Second, the backend can determine the corresponding target service routing information for service routing based on the five-dimensional scenario parameters and the correspondence between the maintained five-dimensional scenario parameters and the service routing information. When there are various demand scenarios, various types of service requests, and various types of each service request, it is only necessary to characterize the various demand scenarios through multi-dimensional scenario parameters, and use the scenario parameters and the correspondence to perform service routing instead of interface routing, thereby reducing the number of interfaces, reducing the difficulty and complexity of code modification and maintenance, and improving system security.

[0108] The present application also proposes a service routing method, which is applied to a front end included in a service system. The service system also includes a back end corresponding to the front end; the back end maintains a correspondence between multi-dimensional scenario parameters and service routing information, the multi-dimensional scenario parameters are used to characterize the demand scenario corresponding to the service request, and the service routing information is used to guide the service process; the method includes:

[0109] In response to the user operation, generating a target service request corresponding to the target demand scenario;

[0110] The target service request is sent to the back end corresponding to the front end, so that the back end obtains multi-dimensional target scenario parameters related to the target demand scenario in response to receiving the target service request, determines the target service routing information according to the multi-dimensional target scenario parameters and the corresponding relationship, and, based on the target service routing information, routes the service process to the target service implementation method corresponding to the target service routing information.

[0111] For detailed description of this method, please refer to the relevant embodiments and will not be described in detail here.

[0112] In the method, first, the front end only needs to generate a service request corresponding to the target demand scenario, and there is no need to determine the interface to be called according to the user operation, that is, there is no judgment logic, thereby reducing the pressure on the front end; second, the back end can determine the corresponding target service routing information for service routing according to the multi-dimensional scenario parameters and the correspondence between the maintained multi-dimensional scenario parameters and the service routing information. In the case where there are various demand scenarios, various types of service requests, and each service request is also various, it is only necessary to characterize the various demand scenarios through multi-dimensional scenario parameters, and replace the interface routing method with the method of using the scenario parameters and the correspondence to perform service routing, thereby reducing the number of interfaces, reducing the difficulty and complexity of code modification and maintenance, and improving system security.

[0113] Corresponding to any of the embodiments, the present application also proposes a service routing device. The service routing device can be applied to a service system; the service system includes a front end and a back end; the back end maintains a correspondence between multi-dimensional scenario parameters and service routing information; the multi-dimensional scenario parameters are used to characterize the demand scenario corresponding to the service request; the service routing information is used to guide the service process.

[0114] See also Figure 6 , Figure 6 FIG. 1 is a schematic diagram of a service routing device according to an embodiment of the present application. Figure 6 As shown, the service routing device 600 may include:

[0115] The receiving module 610 receives a target service request corresponding to a target demand scenario initiated by the front end;

[0116] The acquisition module 620 acquires target scenario parameters related to the target demand scenario in response to receiving the target service request;

[0117] A determination module 630 determines target service routing information according to the target scenario parameters and the corresponding relationship;

[0118] The routing module 640 routes the service flow to the target service implementation method corresponding to the target service routing information based on the target service routing information.

[0119] In some embodiments, the target scenario parameter is a multi-dimensional parameter; and the acquisition path of the multi-dimensional target scenario parameter related to the target demand scenario includes at least one of the following:

[0120] The header of the tag definition document corresponding to the target service request; the address bar parameter corresponding to the target service request; and the Cookie file corresponding to the target service request.

[0121] In some embodiments, the acquisition module 620 further:

[0122] In response to not acquiring all the scene parameters from the first acquisition path in the acquisition paths, acquiring the remaining scene parameters using the second acquisition path;

[0123] In response to not acquiring all remaining scene parameters by adopting the second acquisition path, acquiring remaining scene parameters by adopting a third acquisition path.

[0124] In some embodiments, the scenario parameters are multi-dimensional parameters; the corresponding relationship is maintained in a manner of storing the multi-dimensional scenario parameters as matching conditions and storing the service routing information as output results that hit the matching conditions;

[0125] The determination module 630 further:

[0126] Matching the multi-dimensional target scene parameters with each stored matching condition;

[0127] The target service routing information is determined according to the output result of the target matching condition that matches the multi-dimensional target scenario parameters.

[0128] In some embodiments, the correspondence includes a first correspondence between the scenario parameter and the demand scenario, and a second correspondence between the demand scenario and the service routing information; the backend includes a routing layer; the routing layer stores the first correspondence and the second correspondence;

[0129] The determination module 630 further:

[0130] Determining a target demand scenario through the routing layer according to the target scenario parameter and the first corresponding relationship;

[0131] The target service routing information is determined according to the determined target demand scenario and the second corresponding relationship.

[0132] In some embodiments, the multi-dimensional scene parameters include at least two of the following:

[0133] Account type; terminal type; platform channel; account source; login type.

[0134] In some embodiments, the apparatus further comprises:

[0135] A generation module, wherein the front end generates a target service request corresponding to a target demand scenario in response to a user operation;

[0136] A sending module sends the target service request to a back end corresponding to the front end.

[0137] In the above-mentioned scheme, the scenario parameters related to the demand scenario are used at the front end to characterize the target demand scenario corresponding to the target service request. The back end can determine the corresponding target service routing information based on the scenario parameters and the correspondence between the maintained scenario parameters and the service routing information. Based on the target service routing information, the service process is routed to the target service implementation method to provide the service, so as to realize a flexible and lightweight routing method.

[0138] Compared with related technologies, first, the front end only needs to generate a service request corresponding to the target demand scenario, and there is no need to determine the interface that needs to be called according to the user operation, that is, there is no judgment logic, which reduces the pressure on the front end; second, the back end can determine the corresponding target service routing information for service routing based on the scenario parameters and the correspondence between the maintained scenario parameters and the service routing information. When there are various demand scenarios, various types of service requests, and each service request is also diverse, it is only necessary to characterize the various demand scenarios through scenario parameters, and replace the interface routing method with the method of using the scenario parameters and the correspondence to perform service routing, thereby reducing the number of interfaces, reducing the difficulty and complexity of code modification and maintenance, and improving system security.

[0139] The embodiment of the service routing device shown in the present application can be applied to an electronic device. Accordingly, the present application discloses an electronic device, which may include: a processor.

[0140] Memory used to store processor-executable instructions.

[0141] The processor is configured to call the executable instructions stored in the memory to implement the service routing method shown in any of the aforementioned embodiments.

[0142] See also Figure 7 , Figure 7 A schematic diagram of the hardware structure of an electronic device shown in an embodiment of the present application.

[0143] like Figure 7 As shown, the electronic device may include a processor for executing instructions, a network interface for network connection, a memory for storing operation data for the processor, and a non-volatile memory for storing instructions corresponding to the service routing device.

[0144] The embodiments of the device can be implemented by software, hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the electronic device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, in addition to Figure 7 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device in the embodiment is located may also include other hardware according to the actual function of the electronic device, which will not be described in detail.

[0145] It is understandable that, in order to improve the processing speed, the corresponding instructions of the service routing device can also be directly stored in the memory, which is not limited here.

[0146] The present application proposes a computer-readable storage medium, which stores a computer program. The computer program can be used to enable a processor to execute the service routing method shown in any of the aforementioned embodiments.

[0147] Those skilled in the art will appreciate that one or more embodiments of the present application may be provided as a method, system or computer program product. Therefore, one or more embodiments of the present application may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, one or more embodiments of the present application may take the form of a computer program product implemented on one or more computer-usable storage media (which may include but are not limited to disk storage, CDROM, optical storage, etc.) containing computer-usable program code.

[0148] The term "and / or" in the present application means at least one of the two. For example, "A and / or B" may include three options: A, B, and "A and B".

[0149] Each embodiment in the present application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the data processing device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0150] The above describes a specific embodiment of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0151] The subject matter and functional routing embodiments described in this application can be implemented in the following: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware that may include the structures disclosed in this application and their structural equivalents, or a combination of one or more of them. The embodiments of the subject matter described in this application can be implemented as one or more computer programs, that is, one or more modules of computer program instructions encoded on a tangible non-transitory program carrier to be executed by a data processing device or control the routing of the data processing device. Alternatively or additionally, the program instructions can be encoded on an artificially generated propagation signal, such as a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information and transmit it to a suitable receiver device for execution by a data processing device. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

[0152] The processes and logic flows described in this application can be performed by one or more programmable computers executing one or more computer programs to perform corresponding functions by routing according to input data and generating output. The processes and logic flows can also be performed by special purpose logic circuits, such as FPGAs (field programmable gate arrays) or ASICs (application specific integrated circuits), and the apparatus can also be implemented as special purpose logic circuits.

[0153] A computer suitable for executing a computer program may include, for example, a general and / or special purpose microprocessor, or any other type of processing unit. Typically, the processing unit will receive instructions and data from a read-only memory and / or a random access memory. The basic components of a computer may include a processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more large-capacity storage devices for storing data, such as a disk, a magneto-optical disk, or an optical disk, or the computer will be routable and coupled to this large-capacity storage device to receive data from it or to transmit data to it, or both. However, a computer does not necessarily have such a device. In addition, a computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0154] Computer readable media suitable for storing computer program instructions and data may include all forms of non-volatile memory, media and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD ROM and DVD ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuits.

[0155] Although the application includes many specific implementation details, these should not be interpreted as limiting any disclosed scope or the scope of protection claimed, but are mainly used to describe the features of specific disclosed specific embodiments. Certain features described in multiple embodiments in the application can also be implemented in combination in a single embodiment. On the other hand, the various features described in a single embodiment can also be implemented separately in multiple embodiments or implemented with any suitable sub-combination. In addition, although the feature can work in some combinations as described and even initially claim protection, one or more features from the claimed combination can be removed from the combination in some cases, and the claimed combination can point to a variation of a sub-combination or a sub-combination.

[0156] Similarly, although routes are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that the routes be executed in the particular order shown or executed sequentially, or that all illustrated routes be executed to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product, or packaged into multiple software products.

[0157] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the particular order or sequential order shown to achieve the desired results. In some implementations, multitasking and parallel processing may be advantageous.

[0158] The above are only preferred embodiments of one or more embodiments of the present application and are not intended to limit one or more embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present application should be included in the scope of protection of one or more embodiments of the present application.

Claims

1. A service routing method, applied to a service system; characterized in that: The service system includes a front end and a back end; the back end maintains the correspondence between scene parameters and service routing information; The scenario parameter is used to characterize the demand scenario corresponding to the service request; The service routing information is used to guide the service process; the method comprises: Receiving a target service request corresponding to a target demand scenario initiated by the front end; In response to receiving the target service request, and not obtaining all the scenario parameters from the first acquisition path of at least one acquisition path for obtaining the multi-dimensional target scenario parameters related to the target demand scenario, using the second acquisition path to obtain the remaining scenario parameters; in response to not obtaining all the remaining scenario parameters by using the second acquisition path, using the third acquisition path to obtain the remaining scenario parameters; determining the target service routing information according to the target scenario parameters and the corresponding relationship; wherein the dimensions of the scenario parameters include at least two of the following: account type; terminal type; platform channel; account source; login type; Based on the target service routing information, the service process is routed to a target service implementation method corresponding to the target service routing information.

2. The method according to claim 1, characterized in that The target scenario parameter is a multi-dimensional parameter; the acquisition path of the multi-dimensional target scenario parameter related to the target demand scenario includes at least one of the following: The header of the tag definition document corresponding to the target service request; the address bar parameter corresponding to the target service request; and the Cookie file corresponding to the target service request.

3. The method according to claim 1, characterized in that The scenario parameters are multi-dimensional parameters; the corresponding relationship is maintained in a manner of storing the multi-dimensional scenario parameters as matching conditions and storing the service routing information as output results that hit the matching conditions; The determining target service routing information according to the target scenario parameter and the corresponding relationship includes: Matching the multi-dimensional target scene parameters with each stored matching condition; The target service routing information is determined according to the output result of the target matching condition that matches the multi-dimensional target scenario parameters.

4. The method according to claim 1, characterized in that: The corresponding relationship includes a first corresponding relationship between the scenario parameter and the demand scenario, and a second corresponding relationship between the demand scenario and the service routing information; the backend includes a routing layer; the routing layer stores the first corresponding relationship and the second corresponding relationship; The determining target service routing information according to the target scenario parameter and the corresponding relationship includes: Determining a target demand scenario through the routing layer according to the target scenario parameter and the first corresponding relationship; The target service routing information is determined according to the determined target demand scenario and the second corresponding relationship.

5. The method according to claim 1, characterized in that Before receiving the target service request corresponding to the target demand scenario initiated by the front end, the method further includes: The front end generates a target service request corresponding to the target demand scenario in response to the user operation; The target service request is sent to a back end corresponding to the front end.

6. A service routing device, applied to a service system; characterized in that: The service system includes a front end and a back end; the back end maintains the correspondence between scene parameters and service routing information; The scenario parameter is used to characterize the demand scenario corresponding to the service request; The service routing information is used to guide the service process; the device includes: A receiving module receives a target service request corresponding to a target demand scenario initiated by the front end; The acquisition module, in response to receiving the target service request and failing to acquire all the scenario parameters from a first acquisition path of at least one acquisition path for acquiring multi-dimensional target scenario parameters related to the target demand scenario, adopts a second acquisition path to acquire the remaining scenario parameters; in response to failing to acquire all the remaining scenario parameters from the second acquisition path, adopts a third acquisition path to acquire the remaining scenario parameters; wherein the dimensions of the scenario parameters include at least two of the following: account type; terminal type; platform channel; account source; login type; A determination module, which determines target service routing information according to the target scenario parameters and the corresponding relationship; The routing module routes the service flow to the target service implementation method corresponding to the target service routing information based on the target service routing information.

7. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor implements the service routing method as described in any one of claims 1-5 by running the executable instructions.

Images