Request processing method and system, proxy server and service node

Abstract

The invention discloses a request processing method and system, a proxy server and a service node, and relates to the technical field of micro-services. A specific embodiment of the method comprises the following steps: acquiring a service request sent by a client; analyzing the service request to obtain an access source identifier, and determining a target service node corresponding to the service request; determining target version information of a target service node corresponding to the access source identifier according to the access source identifier and a pre-configured first mapping relationship; the first mapping relation indicates multiple pieces of version information and source identifiers corresponding to the version information respectively; setting a flow mark in the service request according to the target version information, and generating a target service request; and sending the target service request to the target service node according to the traffic mark, so that the target service node processes the target service request according to the traffic mark. According to the embodiment, the reconstruction cost of the client is reduced, and the parallel development efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of microservice technology, and in particular to a request processing method and system, a proxy server, and a service node. Background Art

[0002] With business expansion and technology upgrades, a large number of parallel development needs have emerged in the microservice architecture, and each microservice will deploy different branch versions based on the parallel development needs.

[0003] In the process of implementing the present invention, the inventors found that:

[0004] In order to adapt to multiple branch versions of the backend service node, the client needs to be modified accordingly, such as adding a marking function in the client so that the client sets the branch mark in the request, so that the request can be delivered to the backend service node of the corresponding branch. This increases the modification cost of the client's non-business functions and reduces the efficiency of parallel development. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a request processing method and system, a proxy server and a service node. After receiving a service request sent by a client, the proxy server can add a traffic tag to the service request according to a preconfigured first mapping relationship and an access source identifier in the service request to generate a target service request. The service request is then delivered to the target service node according to the traffic tag, so that the target service node can select the corresponding version to process the target service request according to the traffic tag. This achieves traffic tagging of service requests through a proxy server without the need to perform non-business function modifications on the client, so that the client is unaware of the traffic tag, thereby reducing the modification cost and facilitating the efficiency of parallel development.

[0006] To achieve the above object, according to one aspect of an embodiment of the present invention, a request processing method is provided, which is applied to a proxy server, and the method includes:

[0007] Get the service request sent by the client;

[0008] Parse the service request to obtain the access source identifier and determine the target service node corresponding to the service request;

[0009] Determine the target version information of the target service node corresponding to the access source identifier according to the access source identifier and the preconfigured first mapping relationship; the first mapping relationship indicates multiple version information and the source identifiers corresponding to each version information;

[0010] Set a traffic tag in the service request according to the target version information to generate a target service request;

[0011] The target service request is sent to the target service node according to the flow mark, so that the target service node processes the target service request according to the flow mark.

[0012] Optionally, the proxy server is also pre-configured with a second mapping relationship, which indicates multiple traffic tags and the running instance addresses of the service nodes corresponding to each traffic tag; the target service node is deployed with one or more versions of the first running instances corresponding to the branch services; the mapping relationship also indicates the running instance address corresponding to the source identifier; sending the target service request to the target service node according to the traffic tag, including: determining, according to the second mapping relationship, that the target version information corresponds to the target running instance address of the target service node; and sending the target service request to the target service node according to the target running instance address.

[0013] Optionally, the target service node includes a basic service environment and a branch service environment; first running instances corresponding to one or more versions of branch services are respectively deployed in the branch service environment, and a second running instance of a stable version is deployed in the basic service environment;

[0014] Sending the target service request to the target service node according to the target running instance address includes: determining whether there is a first running instance matching the target running instance address in the branch service environment;

[0015] If yes, delivering the target service request according to the address of the matched first running instance;

[0016] If not, the target service request is delivered according to the address of the second running instance of the basic service environment.

[0017] Optionally, a traffic tag is set in the service request according to the target version information, including:

[0018] In the case where the service request is an Http request, a traffic tag is added to the header field of the service request and / or the parameter field of the URL or the context of the RPC request to generate a target service request;

[0019] or,

[0020] In the case where the service request is an RPC request, a traffic tag is added to the context of the service request to generate a target service request.

[0021] To achieve the above object, according to a second aspect of an embodiment of the present invention, a request processing method is provided, which is applied to a service node. The method includes:

[0022] Obtain a target service request, where the target service request carries a traffic tag;

[0023] Determine the downstream service node to be called according to the target service request, and determine the target version information according to the traffic tag;

[0024] The target service request is processed according to the target version information, and the target service request is sent to a downstream service node, so that the downstream service node processes the target service request according to the target version information.

[0025] Optionally, sending the target service request to a downstream service node includes:

[0026] Obtain a list of running instances of downstream service nodes from a service registration center; the service registration center includes lists of running instances corresponding to multiple pre-registered service nodes;

[0027] According to the running instance address in the running instance list, the target service request is sent to the downstream node.

[0028] Optionally, the traffic tag indicates a target running instance address, and the running instance list of the downstream service node includes: a first running instance list of the branch service environment and a second running instance list of the basic service environment;

[0029] Sending the target service request to the downstream service node according to the running instance address in the running instance list includes:

[0030] Determine whether there is a target running instance address corresponding to the traffic mark in the first running instance list;

[0031] If yes, send the target service request according to the target running instance address;

[0032] If not, send the target service request according to the second running instance list.

[0033] To achieve the above object, according to a third aspect of an embodiment of the present invention, a proxy server is provided, which includes: a first request acquisition module, a parsing module, a tag setting module and a request sending module; wherein,

[0034] The first request acquisition module is configured to: acquire a service request sent by a client;

[0035] The parsing module is configured to: parse the service request to obtain an access source identifier, and determine a target service node corresponding to the service request;

[0036] The tag setting module is configured to: determine the target version information of the target service node corresponding to the access source identifier according to the access source identifier and the preconfigured first mapping relationship; the first mapping relationship indicates multiple version information and the source identifiers corresponding to each version information; set the flow tag in the service request according to the target version information, and generate a target service request;

[0037] The request sending module is configured to send the target service request to the target service node according to the flow mark, so that the target service node processes the target service request according to the flow mark.

[0038] To achieve the above object, according to a fourth aspect of an embodiment of the present invention, a service node is provided, which includes: a second request acquisition module, an environment determination module and a request processing module; wherein,

[0039] The second request acquisition module is configured to: acquire a target service request, the target service request carrying a flow mark;

[0040] The environment determination module is configured to: determine the target version information according to the traffic mark, and determine the downstream service node to be called;

[0041] The request processing module is configured to: process the target service request according to the target version information, and send the target service request to the downstream service node, so that the downstream service node processes the target service request according to the target version information.

[0042] To achieve the above object, according to a fifth aspect of an embodiment of the present invention, there is provided a request processing system, which includes: the proxy server provided by the third aspect, the service node provided by the fourth aspect, and a client;

[0043] The client is used to determine the access source identifier according to the user trigger, and send a service request to the proxy server according to the access source identifier.

[0044] Optionally, the client is deployed with multiple versions of branch applications, and the multiple branch applications are deployed on the same physical device or on multiple physical devices; the branch application matches the branch service deployed on the service node;

[0045] When multiple branch applications are deployed on the same physical device, the access source identifier is determined based on the access port;

[0046] In the case where multiple branch applications are deployed on multiple physical devices, the access source identifier is determined according to the access address and access port of the physical device.

[0047] To achieve the above-mentioned purpose, according to another aspect of an embodiment of the present invention, there is provided an electronic device for processing a request, the electronic device comprising: a processor; a memory for storing processor executable instructions, wherein the processor is configured to execute the instructions to implement a request processing method of an embodiment of the present invention.

[0048] To achieve the above-mentioned purpose, according to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided. When the instructions in the computer-readable storage medium are executed by a processor of a server that processes a request, the server that processes the request can execute a request processing method of an embodiment of the present invention.

[0049] To achieve the above objective, according to another aspect of an embodiment of the present invention, a computer program product is provided, including a computer program, which implements a request processing method of an embodiment of the present invention when executed by a processor.

[0050] One embodiment of the above invention has the following advantages or beneficial effects: after receiving the service request sent by the client, the proxy server can add a traffic tag to the service request according to the preconfigured first mapping relationship and the access source identifier in the service request to generate a target service request. Then the service request is delivered to the target service node according to the traffic tag, so that the target service node can select the corresponding version to process the target service request according to the traffic tag. In this way, the service request is traffic-tagged by the proxy server without the need to modify the client for non-business functions, so that the client is unaware of the traffic tag, thereby reducing the modification cost and facilitating the efficiency of parallel development.

[0051] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0053] FIG. 1( a ) is a schematic diagram of a process of a client initiating a service request in the prior art;

[0054] FIG1( b ) is a schematic diagram of another process of a client initiating a service request in the prior art;

[0055] Figure 2 It is a flowchart of a request processing method applied to a proxy server provided by an embodiment of the present invention;

[0056] Figure 3 is a flowchart of a request processing method applied to a service node provided by an embodiment of the present invention;

[0057] Figure 4 It is a schematic diagram of main modules of a proxy server provided by an embodiment of the present invention;

[0058] Figure 5 This is a schematic diagram of main modules of a service node provided by an embodiment of the present invention;

[0059] Figure 6 It is a schematic diagram of main modules of a request processing system provided by an embodiment of the present invention;

[0060] Figure 7 It is a schematic diagram of a service request flowing in a request processing system provided by an embodiment of the present invention;

[0061] Figure 8 It is a flowchart of an application method of a service request system provided by an embodiment of the present invention;

[0062] Fig. 9 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0063] Fig.10 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0064] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0065] In order to make those skilled in the art better understand the present disclosure, the following is a detailed description of various embodiments of the present invention in conjunction with the accompanying drawings and specific implementation methods. It should be noted that the embodiments of the present invention and the technical features in the embodiments can be combined with each other without conflict.

[0066] In a microservice architecture, multiple microservices are usually used to implement business functions that can be implemented by a single application. Different business functions are generally implemented by different microservices. As shown in Figure 1(a), microservice 1, microservice 2, microservice 3 and microservice 4 jointly implement business function A, and microservice 5, microservice 6 and microservice 7 jointly implement business function B. In the process of implementing business functions, upstream and downstream microservices are called in sequence to form a request processing link. For example, when implementing business function A, microservice 1, microservice 2, microservice 3 and microservice 4 are called in sequence to process the request and form a request processing link, finally realizing business function A.

[0067] With business expansion and technology upgrades, a large number of parallel development requirements have emerged in the microservice architecture. Therefore, each microservice will deploy different branch versions according to the parallel development requirements. For example, in addition to the stable trunk version 1, the backend service node 1 corresponding to microservice 1 also deploys branch versions 11 and 12. The backend service node 3 corresponding to microservice 3 deploys trunk version 3 and branch version 32. Among them, branch version 11 corresponds to development requirement 1, and branch versions 12 and 32 correspond to development requirement 2. In order to adapt to multiple branch versions of the backend service node, the client will also be modified accordingly, so that the client can set a branch tag in the request, so that the request can be delivered to the request processing link of the corresponding branch. For example, a request carrying branch tag 1 can be processed through the request processing link of microservice 1 branch version 11→microservice 2→microservice 3→microservice 4, and a request carrying branch tag 2 can be processed through the request processing link of microservice 1 branch version 12→microservice 2→microservice 3 branch version 32→microservice 4, as shown in Figure 1(b). However, adding a marking function to the client increases the cost of modifying the client's non-business functions. Once the branch version of the backend service node changes, multiple clients accessing the service node need to be modified accordingly, which not only increases the modification cost, but also reduces the efficiency of parallel development.

[0068] In order to solve the above problems, Figure 2 As shown, an embodiment of the present invention provides a request processing method. When the request processing method is applied to a proxy server, it mainly includes the following steps S201-S205:

[0069] Step S201: Obtain a service request sent by a client.

[0070] Step S202: Parse the service request to obtain an access source identifier, and determine a target service node corresponding to the service request.

[0071] Here, the target service node corresponding to the service request is determined by the access function corresponding to the service request, and the target service node is the most upstream service node in the request processing link corresponding to the access function. For example, microservice 1, microservice 2, microservice 3 and microservice 4 jointly implement business function A, and microservice 5, microservice 6 and microservice 7 jointly implement business function B. If the function to be accessed corresponding to the service request is business function A, the target service node is the backend service node 1 corresponding to microservice 1; if the function to be accessed corresponding to the service request is business function B, the target service node is the backend service node 5 corresponding to microservice 5. It should be understood that no matter which service node the target service node corresponding to the service request is, the process of setting the traffic mark for the service request according to the target version information by the proxy server is basically the same, the only difference is that different target version information corresponds to different branch versions, so the set traffic mark is different. For the convenience of description, the subsequent embodiments mainly take the request processing link of microservice 1→microservice 2→microservice 3→microservice 4 corresponding to business function A as an example for explanation. In this example, the target service node is the service node 1 corresponding to microservice 1.

[0072] Step S203: Determine the target version information of the target service node corresponding to the access source identifier according to the access source identifier and a preconfigured first mapping relationship; the first mapping relationship indicates multiple version information and the source identifiers corresponding to each version information.

[0073] According to the access source identifier of the service request initiated on the client, it can be determined from which branch application of the client the service request was initiated, and thus the target version information of the target service node can be determined accordingly. For example, if the service request is initiated from branch application 2, the target version information can be determined to be branch service 2 accordingly.

[0074] Step S204: Setting a flow mark in the service request according to the target version information to generate a target service request.

[0075] The target service request is the service request after the proxy server sets the flow mark. The proxy server can be an Nginx reverse proxy server. The reverse proxy server can modify the request when forwarding the request, so that the flow mark can be set in the service request. Exemplarily, the Nginx reverse proxy server can add a flow mark in the header field of the Http request, the parameter field of the URL (Uniform Resource Locator), or the context of the RPC (Remote Procedure Call Protocol) request to generate the target service request.

[0076] Step S205: sending the target service request to the target service node according to the traffic mark, so that the target service node processes the target service request according to the traffic mark.

[0077] According to the above embodiment, by adding the function of automatically setting the traffic mark in the proxy server, the traffic mark is set for the service request sent by the client according to the version information, so that the service request can be delivered to the target service node of the corresponding version information without the client being aware of the traffic mark, thereby reducing the transformation cost and improving the efficiency of parallel development.

[0078] In an embodiment of the present invention, to match the branch service deployed on the service node, multiple versions of branch applications are also deployed on the client accordingly. These branch applications can be deployed on the same physical device or on multiple physical devices. For example, business function A corresponds to two development requirements; corresponding to the two development requirements, the microservice is deployed with two branch versions, and two branch applications are deployed on the client accordingly. These branch applications can be deployed on the same physical device or on different physical devices respectively. Taking the two branch applications corresponding to business function A deployed on the client as an example, these two branch applications can be deployed on the same terminal device or the same front-end server, or on two different terminal devices or two different front-end servers. It can be understood that if there are more than two branch applications deployed on the client, one of these branch applications can be deployed on a physical device alone, some can be deployed on the same physical device, or all can be deployed on the same physical device, or each can be deployed on a different physical device, and the embodiment of the present invention does not limit this.

[0079] The client can initiate service requests through different branch applications according to the user's trigger. After receiving the service request, the proxy server can parse the access address and access port from the service request. The access address can be the address of the physical device where the branch application is deployed, and the access source port is the port exposed to the user by each branch application of the client. For example, if the service request is initiated by branch application 2, the proxy server can parse the address of the physical device where branch application 2 is located and the access port corresponding to branch application 2 from the service request.

[0080] Based on the different deployment methods of branch applications, when configuring the first mapping relationship on the proxy server, the access source identifier can also be configured in different ways. For example, when the branch application is deployed on the same physical device, the access port can be directly used as the source identifier in the first mapping relationship, that is, the first mapping relationship between the access port and the version information is configured on the proxy server. The mapping relationship in this case can be shown in Table 1:

[0081] Table 1

[0082] Source Identification Version Information Access Port 1 Branch Service A1 Access Port 2 Branch Service A2 Access Port 3 Backbone Services …… ……

[0083] If the branch application is deployed on different physical devices, the combination of the access address and the access port is used as the source identifier in the first mapping relationship, that is, the first mapping relationship of the access address, access port and version information is configured on the proxy server. In this case, the first mapping relationship can be shown in Table 2:

[0084] Table 2

[0085] Source Identification Version Information Access address 1+access port 1 Branch Service A1 Access address 2+access port 2 Branch Service A2 Access address 2 + access port 1 Backbone Services …… ……

[0086] Therefore, after receiving the service request, the proxy server can determine the target version information corresponding to the access source identifier according to the access source identifier corresponding to the service request and the pre-configured first mapping relationship. For example, when the branch applications of the client are deployed on the same physical device, if the service request is initiated from the branch application 2 of the client (corresponding to source port 2), the proxy server can determine that the target version information is the version information of the branch service A2 based on Table 1 above. It can be understood that the access source identifier is the source identifier included in this service request, and the version information corresponding to the source identifier that is the same as the access source identifier in the first mapping relationship is the target version information. In addition, it should be understood that the different source identifier representation methods in Table 1 and Table 2 are only different in the basis for identifying different versions, and the corresponding traffic tag setting process is basically the same. Therefore, for the convenience of expression, the subsequent embodiments mainly take the source identifier representation method shown in Table 1 as an example.

[0087] After the proxy server determines the target version information, it can set the flow mark in the service request according to the target version information to generate a target service request, and the target service request is the service request with the flow mark added. Among them, the correspondence between the flow mark and the target version information can also be pre-configured in the reverse proxy server. Exemplarily, the correspondence between the flow mark and the target version information can be shown in Table 3 below:

[0088] Table 3

[0089]

[0090]

[0091] Of course, the corresponding relationship between the flow mark and the target version information in Table 3 and the first mapping relationship between the source identifier and the version information in Table 2 or Table 1 can be stored in combination, that is, the contents in Table 1 and Table 3 can be combined into a data table for storage, and the contents in Table 2 and Table 3 can also be combined into a data table for storage. As shown in Table 3, if the proxy server determines that the target version information corresponding to the service request is the information of the branch service A2, then the mark a2 can be added to the service request according to the corresponding relationship in Table 3, such as adding the mark a2 to the header field of the Http request, the parameter field of the URL or the context of the RPC request to obtain the target service request. For another example, if the proxy server determines that the target version information corresponding to the service request is the information corresponding to the trunk service, then according to the corresponding relationship shown in Table 3, the added flow mark is empty, that is, the service request can be directly used as the target service request. Alternatively, a unique identifier can also be used as the flow mark of the trunk service. After determining the target version information corresponding to the trunk service, the proxy server adds the unique identifier to the service request to generate the target service request. In addition, in addition to the branch service and traffic marking method stored in Table 3, the embodiment of the present invention can also generate a target service request by generating a traffic mark according to a pre-configured marking strategy, and the marking strategy is pre-configured in the reverse proxy server and each service node. After the proxy server determines the target version information, it can generate a traffic mark corresponding to the target version information according to the marking strategy, and then the proxy server sets the traffic mark in the service request to generate a target service request. After receiving the target service request, the service node can parse the traffic mark therefrom and reversely determine the target version information according to the marking strategy, so that each service node can also process the target service request according to the target version information.

[0092] In an embodiment of the present invention, in order to facilitate the provision of branch services, service requests can be processed through different running instances. Specifically, one or more versions of the branch service corresponding to the first running instances are deployed on the target service node, and a second mapping relationship is also preconfigured in the proxy server, and the second mapping relationship indicates multiple traffic tags and the running instance addresses of the service nodes corresponding to each traffic tag. When the proxy server sends the target service request to the target service node, it can determine the target running instance address corresponding to the traffic tag based on the second mapping relationship, and then send the target service request to the target service node according to the target running instance address.

[0093] Taking service node 1 as an example, it is deployed with two branch services, which correspond to the first running instance 11 and the first running instance 12 respectively. The correspondence between each running instance address and the traffic tag is configured in the second mapping relationship. Exemplarily, the second mapping relationship can be shown in Table 4 below when the access port is used as the source identifier. When the proxy server sends a target service request corresponding to branch service A2 to service node 1, it can determine the first running instance address 12 (target running instance address) from the mapping relationship shown in Table 4, and then deliver the target service request according to the target running instance address. In addition, it should be understood that the second mapping relationship in Table 4 and the correspondence between the traffic mark and the target version information in Table 3, as well as the first mapping relationship in Table 1 or Table 2 can be stored in combination, that is, the contents of Table 1, Table 3 and Table 4 can be combined into a data table for storage, and the first mapping relationship and the second mapping relationship can also be combined into a mapping relationship - the correspondence between access port, version information, traffic mark, service node, and running instance address; or the contents of Table 2, Table 3 and Table 4 can be combined into a data table for storage, and the first mapping relationship and the second mapping relationship can also be combined into a mapping relationship - the correspondence between access address + access port, version information, traffic mark, service node, and running instance address.

[0094] Table 4

[0095]

[0096] Furthermore, in an embodiment of the present invention, the service node deploys the trunk service and the branch service respectively through different environments to ensure that the branch service will not affect the operation of the trunk service during the development process. Specifically, the target service node includes a basic service environment and a branch service environment, and the first running instances corresponding to one or more versions of the branch service are deployed in the branch service environment, and the basic service environment is deployed with a stable version of the second running instance, that is, the second running instance corresponding to the trunk service. When delivering the target service request, the proxy server can first determine whether there is a first running instance matching the address of the target running instance in the branch service environment of the target service node. If so, the target service request is delivered according to the matched first running instance address; if the first running instance corresponding to the target service instance is not matched in the target service node, the target service request is delivered according to the address of the second running instance of the basic service environment.

[0097] Exemplarily, for the service request initiated by the above-mentioned client from branch application 2, the proxy server can determine the first running instance that matches the target running instance from the branch service environment of service node 1, and then the proxy server can deliver the target service request according to the matched first running instance address 12. For another example, if the client also deploys branch application 3, it initiates a service request through branch application 3, and service node 1 has not deployed branch service 3, that is, the proxy server cannot determine the first running instance that matches the target running instance from the branch service environment of service node 1. In this case, the proxy server delivers the target service request according to the address of the second running instance of the basic service environment. Therefore, deploying branch services and stable versions of trunk services respectively through the basic service environment and the branch service environment is not only conducive to the isolation of branch services from trunk services, so that the stable version of trunk services is not affected, but also conducive to the cross-service delivery of service requests according to the target version information and the corresponding service environment.

[0098] According to the above embodiment, by deploying a proxy server between the client and the backend service node, after receiving the service request sent by the client, the proxy server can add a traffic tag to the service request according to the preconfigured mapping relationship and the access source identifier in the service request to generate a target service request. The service request is then delivered to the target service node according to the traffic tag, so that the target service node can select the corresponding version to process the target service request according to the traffic tag. In this way, the service request is traffic-tagged by the proxy server without the need to modify the client for non-business functions, so that the client is unaware of the traffic tag, thereby reducing the modification cost and facilitating the efficiency of parallel development.

[0099] After the proxy server sends the target service request with the traffic mark to the target service node, the target service request can be transmitted between the service nodes corresponding to the request processing link based on the traffic mark. In other words, each service node in the request processing link can call the downstream microservice according to the traffic mark. Figure 3 As shown, an embodiment of the present invention also provides a request processing method applied to a service node, wherein the service node can be any service node in the request processing link. Taking the request processing link composed of microservice 1→microservice 2→microservice 3→microservice 4 as an example, the service node can be service node 1, service node 2, and service node 3 corresponding to each microservice. As the most downstream node in the request processing link, service node 4 corresponding to microservice 4 no longer calls downstream service nodes, and only processes target service requests according to target version information. Specifically, the method mainly includes the following steps:

[0100] Step S301: Obtain a target service request, where the target service request carries a traffic tag.

[0101] Step S302: Determine the downstream service node to be called according to the target service request, and determine the target version information according to the traffic tag.

[0102] Taking service node 1 as an example, the target service request it obtains is the service request with a traffic mark added and forwarded by the proxy server. In the process of service node 1 processing the target request, it needs to call the downstream microservice 2, then the service node 2 corresponding to microservice 2 can also receive the target service request with a traffic mark sent by service node 1. Among them, service node 2 is the downstream service node of service node 1. After determining the business function to be accessed by the target service request, the request processing link corresponding to the business function can be determined, and thus the downstream service node of the current service node can be determined according to the request processing link. Still taking the service request initiated by the branch application 2 of the client as an example, the traffic mark carried in the target service request is mark a2, then the service node can reversely determine the target version information as branch service A2 based on the traffic mark.

[0103] Step S303: Process the target service request according to the target version information, and send the target service request to the downstream service node, so that the downstream service node processes the target service request according to the target version information.

[0104] Still taking service node 1 as an example, after determining that the target version information is branch service A2, it can use the first running instance corresponding to branch service A2 deployed in the branch service environment to process the target service request. Since microservice 1 depends on downstream microservice 2, service node 1 continues to deliver the target service request to the first running instance corresponding to service node 2 according to the traffic tag. And so on, until the target service request is processed by the most downstream service node 4.

[0105] In one embodiment of the present invention, in order to facilitate the calling of services, services in the branch service environment and the basic service environment can be registered to the same service registration center, and the registered meta information includes the branch version information corresponding to the service running example. When a service node calls a downstream service node, it can obtain the running instance list of the downstream service node from the service registration center, which includes the running instance lists corresponding to multiple pre-registered service nodes; then, according to the running instance address in the running instance list, the target service request is sent to the downstream node.

[0106] Specifically, the running instance list of the downstream service node includes the first running instance list of its branch service environment and the second running instance list of the basic service environment. When the service node sends a target service request to the downstream service node, it can first determine whether there is a target running instance address corresponding to the traffic mark in the first running instance list. If so, send the target service request according to the target running instance address; if not, send the target service request according to the second running instance list. Still taking the target service request carrying the traffic mark a2 as an example, its corresponding target running instance is the running instance that implements development requirement 2 (corresponding to branch service A2). When service node 2 calls microservice 3 on service node 3, it obtains the running instance list of service node 3 through the service registration center, that is, the running instance list corresponding to trunk service 3 and branch service A2, wherein the second running instance of trunk service 3 of service node 3 is deployed in the basic service environment, and the first running instance of branch service A2 is deployed in the branch service environment. Since the target running instance address corresponding to the traffic mark exists in the running instance list of service node 3 (the first running instance corresponding to branch service A2), service node 2 sends the target service request according to the first running instance address, so that service node 3 processes the target service request through the running instance of the branch service environment. For another example, in the process of service node 3 calling service node 4, since service node 4 only has the second running instance corresponding to the trunk service deployed through the basic service environment, that is, the target running instance address does not exist in the running instance address list of service node 4, service node 3 sends the target service request according to the second running instance corresponding to the trunk service, so that the downstream service node 4 processes the target service request based on the second running instance in the basic service environment.

[0107] It can be seen that in the embodiment of the present invention, the basic service environment and the branch service environment are deployed on demand at each service node, and the first running instance corresponding to the branch service is deployed in the branch service environment, and the second running instance corresponding to the stable version of the trunk service is deployed in the basic service environment. In the service call process, the traffic mark in the target service request is used as a mark to distinguish the branch service, and is passed to the downstream service along with the target service request at each call, and takes effect in the entire request processing link, ensuring the mutual isolation between service requests corresponding to different development needs in the branch service environment. And the upstream and downstream services and their branch service environments and the basic service environment are associated together through traffic marks, giving full play to the independence of each branch service in the branch service environment and the reusability of the trunk service in the basic service environment. Compared with the prior art that deploys each branch service in the same operating environment, the embodiment of the present invention can reduce resource waste. For example, referring to Figure 1 (b), the prior art deploys the branch version 11 of microservice 1, microservice 2, microservice 3 and microservice 4 in the same operating environment, and deploys the branch version 12 of microservice 1, microservice 2, branch version 32 of microservice 3 and microservice 4 in another operating environment. In other words, in the prior art, each operating environment deploys a branch version corresponding to the development requirements. In this process, microservices 2 and 4 that do not involve task changes are repeatedly deployed, which causes a waste of resources. However, the embodiment of the present invention generates a target service request by setting a traffic tag in the service request, and transmits the target service request in the process of calling the microservice, so as to transmit the branch version information in the whole link during the calling process, and realizes cross-service and cross-environment calls through traffic tags, so that multiple branches can be deployed in parallel in one environment. Microservices that do not involve task changes only need to deploy a stable version of the trunk service without repeated deployment, thereby improving the utilization and reuse rate of resources and reducing resource waste.

[0108] Based on the inventive concept of the above request processing method, the embodiment of the present invention also provides a proxy server, such as Figure 4 As shown, the proxy server 400 includes a first request acquisition module 401, a parsing module 402, a tag setting module 403 and a request sending module 404; wherein,

[0109] The first request acquisition module 401 is configured to: acquire a service request sent by a client;

[0110] The parsing module 402 is configured to: parse the service request to obtain an access source identifier, and determine a target service node corresponding to the service request;

[0111] The tag setting module 403 is configured to: determine the target version information of the target service node corresponding to the access source identifier according to the access source identifier and the preconfigured first mapping relationship, wherein the first mapping relationship indicates multiple version information and the source identifiers corresponding to each version information; set the flow tag in the service request according to the target version information, and generate a target service request;

[0112] The request sending module 404 is configured to send the target service request to the target service node according to the traffic mark, so that the target service node processes the target service request according to the traffic mark.

[0113] In one embodiment of the present invention, the target service node is deployed with one or more versions of the first running instances corresponding to the branch services respectively; the proxy server is also pre-configured with a second mapping relationship, the second mapping relationship indicates multiple traffic tags and the running instance addresses of the service nodes corresponding to each traffic tag respectively; the request sending module 404 is configured to: determine, according to the second mapping relationship, the target version information corresponding to the target running instance address of the target service node; according to the target running instance address, send the target service request to the target service node.

[0114] In one embodiment of the present invention, the target service node includes a basic service environment and a branch service environment; first running instances corresponding to one or more versions of branch services are deployed in the branch service environment, and the basic service environment is deployed with a second running instance of a stable version; the request sending module 404 is configured to: determine whether there is a first running instance in the branch service environment that matches the address of the target running instance; if so, deliver the target service request according to the address of the matching first running instance; if not, deliver the target service request according to the address of the second running instance of the basic service environment.

[0115] In one embodiment of the present invention, the tag setting module 403 is configured to add a traffic tag to the header field of an Http request, the parameter field of a URL, or the context of an RPC request to generate a target service request.

[0116] According to the above embodiment, by deploying a proxy server between the client and the backend service node, after receiving the service request sent by the client, the proxy server can add a traffic tag to the service request according to the preconfigured mapping relationship and the access source identifier in the service request to generate a target service request. The service request is then delivered to the target service node according to the traffic tag, so that the target service node can select the corresponding version to process the target service request according to the traffic tag. In this way, the service request is traffic-tagged by the proxy server without the need to modify the client for non-business functions, so that the client is unaware of the traffic tag, thereby reducing the modification cost and facilitating the efficiency of parallel development.

[0117] Based on the inventive concept of the above request processing method, the embodiment of the present invention further provides a service node 500, such as Figure 5 As shown, the service node 500 includes a second request acquisition module 501, an environment determination module 502 and a request processing module 503; wherein,

[0118] The second request acquisition module 501 is configured to: acquire a target service request, the target service request carrying a flow mark;

[0119] The environment determination module 502 is configured to: determine the target version information according to the traffic mark, and determine the downstream service node to be called;

[0120] The request processing module 503 is configured to: process the target service request according to the target version information, and send the target service request to the downstream service node, so that the downstream service node processes the target service request according to the target version information.

[0121] In one embodiment of the present invention, the request processing module 503 is configured as follows: obtaining a list of running instances of a downstream service node from a service registration center; the service registration center includes a list of running instances corresponding to a plurality of pre-registered service nodes; and sending a target service request to a downstream node according to the running instance address in the running instance list.

[0122] In one embodiment of the present invention, the traffic mark indicates the target running instance address, and the running instance list of the downstream service node includes: a first running instance list of the branch service environment and a second running instance list of the basic service environment; the request processing module 503 is configured to: determine whether there is a target running instance address corresponding to the traffic mark in the first running instance list; if so, send a target service request according to the target running instance address; if not, send a target service request according to the second running instance list.

[0123] According to the above embodiment, during the service call process, the traffic mark in the target service request is used as a mark to distinguish the branch service, and is passed to the downstream service along with the target service request at each call, and takes effect in the entire request processing link, ensuring the mutual isolation between service requests corresponding to different development requirements in the branch service environment. In addition, the upstream and downstream services and their branch service environments and the basic service environment are associated together through traffic marks, giving full play to the independence of each branch service in the branch service environment and the reusability of the trunk service in the basic service environment, improving the utilization and reuse rate of resources, and reducing resource waste.

[0124] In addition, according to another aspect of the embodiment of the present invention, Figure 6As shown, a request processing system 600 is provided, comprising a proxy server 400 provided by any of the above embodiments, a service node 500 provided by any of the above embodiments, and a client 601; wherein,

[0125] Client 601 is used to determine the access source identifier according to the user trigger, and send a service request to the proxy server 400 according to the access source identifier, so that the proxy server 400 sets the traffic tag corresponding to the access source identifier in the service request, generates a target service request, and sends the target service request to the target service node in the service node 500.

[0126] In one embodiment of the present invention, the client 601 is deployed with multiple versions of branch applications, and the multiple branch applications are deployed on the same physical device or on multiple physical devices; the branch application matches the branch service deployed on the service node; when multiple branch applications are deployed on the same physical device, the access source identifier is determined based on the access port; when multiple branch applications are deployed on multiple physical devices, the access source identifier is determined based on the access address and access port of the physical device.

[0127] The following takes processing the service request corresponding to development requirement 2 in the request processing system as an example to further illustrate the request processing method provided by the embodiment of the present invention. Among them, each service node deploys a branch service environment and a basic service environment as needed. A stable version of the backbone service is deployed in the basic service environment, which can provide the full service of the corresponding microservice and can remain unchanged. The branch service environment is deployed with branch services of the corresponding microservices as needed. Matching the service node, the client also has multiple versions of branch applications deployed accordingly. In this embodiment, taking the initiation of a service request through a branch application as an example, the transmission process of the service request in the request processing system can be referred to. Figure 7 , the request processing methods mainly include: Figure 8 Steps shown:

[0128] Step S801: Based on the triggering by the user through the access port, the branch application 2 of the client initiates a service request and sends the service request to the proxy server.

[0129] The access port is the port exposed by the client to the user.

[0130] Step S802: The proxy server determines that the target service node to be accessed is service node 1 according to the service request, and parses the access source port from the service request.

[0131] Step S803: the proxy server determines that the target version information of the target service node is branch service A2 according to the access source port and the preconfigured mapping relationship, and sets the flow mark a2 in the service request according to the target version information to generate a target service request.

[0132] Here, the mapping relationship may be the first mapping relationship in the above embodiment, or may be a combination of the first mapping relationship and the second mapping relationship.

[0133] Step S804: the proxy server determines the target running instance address corresponding to the branch service 12 according to the mapping relationship, and sends the target service request to the service node 1 according to the target instance address.

[0134] The mapping relationship may indicate the version information corresponding to the multiple service nodes, the source identifier corresponding to the version information, and the running instance address corresponding to the source identifier. Figure 7 The branch service environment shown has a first running instance of the corresponding branch service deployed therein, and the proxy server may send the target service request to the first running instance of the corresponding branch service according to the determined target instance address.

[0135] Step S805: Service node 1 processes the target service request through the branch service environment, during which service node 2 is called. Service node 1 obtains the running instance list of service node 2 from the service registration center, and determines based on the running instance list that service node 2 does not have the first running instance corresponding to branch service A2. Then, based on the second running instance in the basic service environment of service node 2, the target service request is sent to service node 2, so that service node 2 processes the target service request through the second running instance in the basic service environment.

[0136] Step S806: the service node 2 processes the target service request through the backbone service in the basic service environment, and calls the downstream service node 3 during the process.

[0137] Here, since branch service A2 is deployed on service node 3, the process of service node 2 sending the target service request to service node 3 is basically the same as the process of the proxy server sending the target service request to service node 1, which will not be repeated here.

[0138] Step S807 : service node 3 processes the target service request through the branch service environment, during which service node 4 is called and the target service request is sent to service node 4 .

[0139] Since service node 4 has only deployed backbone services in the basic service environment, the process by which service node 3 sends the target service request to service node 4 is substantially the same as the process by which service node 1 sends the target service request to service node 2, and will not be described in detail herein.

[0140] According to the above embodiments, by setting the flow marking logic in the proxy server, after receiving the service request sent by the client, the proxy server can add a flow mark to the service request according to the preconfigured mapping relationship and the access source identifier in the service request to generate a target service request. Then the service request is delivered to the target service node according to the flow mark, so that the target service node can select the corresponding version to process the target service request according to the flow mark. Thus, the function of flow marking the service request through the proxy server and accurately routing the service request to each branch service of the server is realized, without the need to transform the client for non-business functions, so that the client is not aware of the flow mark, thereby reducing the transformation cost and facilitating the improvement of parallel development efficiency. Moreover, in the calling process of each service node in the back end, the flow mark is passed to the downstream service along with the target service request, and takes effect in the entire request processing link, ensuring the mutual isolation between the service requests corresponding to different development requirements in the branch service environment. And the upstream and downstream services and their branch service environments and the basic service environment are associated together through the flow mark, giving full play to the independence of each branch service in the branch service environment and the reusability of the trunk service in the basic service environment. Therefore, the utilization rate and reuse rate of resources are improved, and the waste of resources is reduced.

[0141] Fig. 9 An exemplary system architecture 900 is shown to which a request processing method or a request processing device according to an embodiment of the present invention can be applied.

[0142] like Fig. 9 As shown, the system architecture 900 may include terminal devices 901, 902, 903, a network 904 and servers 905, 906, 907. The network 904 is used to provide a medium for communication links between the terminal devices 901, 902, 903 and the servers 905, 906, 907. The network 904 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc. The servers 905, 906, 907 may include proxy servers 905 and backend service nodes 906, 907. Users may use the terminal devices 901, 902, 903 to interact with the server 905 through the network 904 to initiate a request, and the server 905 may forward the request to the backend service nodes 906, 907 through the network.

[0143] Various client applications may be installed on the terminal devices 701, 702, and 703, such as shopping applications, payment applications, instant messaging tools, social platform software, etc. The terminal devices 701, 702, and 703 may be various electronic devices with display screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers, etc.

[0144] It should be understood that Fig. 9 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0145] Reference below Fig.10 , which shows a schematic diagram of the structure of a computer system 1000 of a terminal device suitable for implementing an embodiment of the present invention. Fig.10 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0146] like Fig.10 As shown, the computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage part 1008 into a random access memory (RAM) 1003. In the RAM 1003, various programs and data required for the operation of the system 1000 are also stored. The CPU 1001, the ROM 1002, and the RAM 1003 are connected to each other via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0147] The following components are connected to the I / O interface 1005: an input section 1006 including a keyboard, a mouse, etc.; an output section 1007 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a LAN card, a modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the I / O interface 1005 as needed. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1010 as needed, so that a computer program read therefrom is installed into the storage section 1008 as needed.

[0148] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1009, and / or installed from the removable medium 1011. When the computer program is executed by the central processing unit (CPU) 1001, the above-mentioned functions defined in the system of the present invention are executed.

[0149] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0150] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0151] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The described system may also be set in a processor. For example, it may be described as: a processor includes a first request acquisition module, a parsing module, a tag setting module, and a request sending module. The names of these modules do not constitute a limitation on the system itself in some cases. For example, the tag setting module may also be described as a "module for setting traffic tags".

[0152] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes: obtaining a service request sent by a client; parsing the service request to obtain an access source identifier, and determining a target service node corresponding to the service request; determining the target version information of the target service node corresponding to the access source identifier according to the access source identifier and a preconfigured mapping relationship; the mapping relationship indicates the version information corresponding to multiple service nodes and the source identifier corresponding to the version information; setting a traffic mark in the service request according to the target version information to generate a target service request; sending the target service request to the target service node according to the traffic mark, so that the target service node processes the target service request according to the traffic mark.

[0153] According to the technical solution of the embodiment of the present invention, after receiving the service request sent by the client, the proxy server can add a traffic tag to the service request according to the preconfigured mapping relationship and the access source identifier in the service request to generate a target service request. The service request is then delivered to the target service node according to the traffic tag, so that the target service node can select the corresponding version to process the target service request according to the traffic tag. This achieves traffic tagging of service requests through the proxy server without the need to perform non-business functional modifications on the client, making the client unaware of the traffic tag, thereby reducing the modification cost and facilitating the efficiency of parallel development.

[0154] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A request processing method, characterized in that: Applicable to proxy servers, including: Get the service request sent by the client; Parsing the service request to obtain an access source identifier, and determining a target service node corresponding to the service request; Determine the target version information corresponding to the access source identifier according to the access source identifier and a preconfigured first mapping relationship; the first mapping relationship indicates a plurality of version information and a source identifier corresponding to each of the version information; Setting a flow mark in the service request according to the target version information to generate a target service request; The target service request is sent to the target service node according to the traffic mark, so that the target service node processes the target service request according to the traffic mark.

2. The method according to claim 1, characterized in that The proxy server is also pre-configured with a second mapping relationship, which indicates a plurality of flow tags and the running instance addresses of the service nodes corresponding to the respective flow tags; the target service node is deployed with the first running instances corresponding to the branch services of one or more versions; The sending the target service request to the target service node according to the traffic mark includes: Determining, according to the second mapping relationship, that the target version information corresponds to a target running instance address of the target service node; The target service request is sent to the target service node according to the target running instance address.

3. The method according to claim 2, characterized in that The target service node includes a basic service environment and a branch service environment; the first running instances corresponding to the one or more versions of the branch service are respectively deployed in the branch service environment, and the basic service environment is deployed with a second running instance of a stable version; The sending the target service request to the target service node according to the target running instance address includes: Determine whether there is a first running instance matching the target running instance address in the branch service environment; If yes, delivering the target service request according to the address of the matched first running instance; If not, the target service request is delivered according to the address of the second running instance of the basic service environment.

4. The method according to claim 1, characterized in that: The step of setting a flow mark in the service request according to the target version information includes: The traffic mark is added in the header field of the Http request, the parameter field of the URL or the context of the RPC request to generate the target service request.

5. A request processing method, characterized in that: Applicable to service nodes; includes: Obtaining a target service request, where the target service request carries a flow mark; Determine the downstream service node to be called according to the target service request, and determine the target version information according to the traffic tag; The target service request is processed according to the target version information, and the target service request is sent to a downstream service node, so that the downstream service node processes the target service request according to the target version information.

6. The method according to claim 5, characterized in that The sending the target service request to the downstream service node includes: Obtaining a running instance list of the downstream service node from a service registration center; the service registration center includes a running instance list corresponding to a plurality of pre-registered service nodes; The target service request is sent to the downstream node according to the running instance address in the running instance list.

7. The method according to claim 6, characterized in that The traffic mark indicates the target running instance address, and the running instance list of the downstream service node includes: a first running instance list of the branch service environment and a second running instance list of the basic service environment; The sending the target service request to the downstream service node according to the running instance address in the running instance list includes: Determine whether there is a target running instance address corresponding to the traffic mark in the first running instance list; If yes, sending the target service request according to the target running instance address; If not, send the target service request according to the second running instance list.

8. A proxy server, characterized in that: include: The first request acquisition module, the parsing module, the tag setting module and the request sending module; wherein, The first request acquisition module is configured to: acquire a service request sent by a client; The parsing module is configured to: parse the service request to obtain an access source identifier, and determine a target service node corresponding to the service request; The tag setting module is configured to: determine the target version information of the target service node corresponding to the access source identifier according to the access source identifier and a preconfigured first mapping relationship; the first mapping relationship indicates multiple version information and the source identifiers corresponding to each of the version information; set a traffic tag in the service request according to the target version information to generate a target service request; The request sending module is configured to send the target service request to a target service node according to the traffic mark, so that the target service node processes the target service request according to the traffic mark.

9. A service node, characterized in that: include: The second request acquisition module, the environment determination module and the request processing module; wherein, The second request acquisition module is configured to: acquire a target service request, wherein the target service request carries a flow mark; The environment determination module is configured to: determine the target version information according to the traffic mark, and determine the downstream service node to be called; The request processing module is configured to: process the target service request according to the target version information, and send the target service request to a downstream service node, so that the downstream service node processes the target service request according to the target version information.

10. A request processing system, characterized in that: include: The proxy server as claimed in claim 8, the service node and the client as claimed in claim 9; The client is used to determine the access source identifier according to the user trigger, and send a service request to the proxy server according to the access source identifier.

11. The system according to claim 10, characterized in that The client is deployed with multiple versions of branch applications, and the multiple branch applications are deployed on the same physical device or on multiple physical devices; the branch applications match the branch services deployed on the service node; In the case where the multiple branch applications are deployed on the same physical device, determining the access source identifier according to the access port; In the case where the multiple branch applications are deployed on multiple physical devices, the access source identifier is determined according to the access address and access port of the physical device.

12. An electronic device for processing information, characterized in that: include: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the request processing method as described in any one of claims 1-4 or 5-7.

13. A computer-readable storage medium, when the instructions in the computer-readable storage medium are executed by a processor of a server for processing requests, the server for processing requests can execute the request processing method according to any one of claims 1-4 or 5-7.

Images