Service request processing method and device, computer equipment and storage medium

Abstract

The invention relates to a service request processing method and device, equipment and a storage medium. The method comprises the following steps: if it is determined that a service data acquisition request passes service validity verification, acquiring request parameters carried by the service data acquisition request, performing field analysis processing on the request parameters to obtain service fields, performing logic distribution processing and flow arrangement processing based on each service field, and sending the service fields to a server; and determining to-be-called service nodes and a dependency calling relationship among the service nodes. Calling the service nodes in sequence according to the dependency calling relationship to obtain sub-service data fed back by the service nodes, determining a target protocol matched with the service data acquisition request according to the service source attribute of the service data acquisition request, and performing protocol adaptation processing and data filling processing on the sub-service data according to the target protocol, and obtaining target business data corresponding to the business data obtaining request. By adopting the method, the sub-service data fitting an actual service scene and the complete and accurate target service data can be obtained.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, apparatus, computer equipment, storage medium and computer program product for processing a business request. Background Art

[0002] With the development of computer technology and network technology, as well as the promotion and application of various applications and application platforms, in the application process of e-commerce platforms, as the business continues to iterate, massive product data associated with various products have appeared on the e-commerce platforms, including product basic data, product review data, and product activity data (such as product promotion and product promotion data). In order to provide high-quality services to the users of the platform, it is necessary to manage the massive product data in a timely manner to ensure the data acquisition capabilities of product data in different scenarios (such as product basic data access scenarios, product review data viewing scenarios, and product activity promotion scenarios).

[0003] Traditionally, the product data from different channels (including web access channels, application access channels, and computer access channels, etc.) are usually connected to the gateway, and the gateway is used to complete the aggregation and dependency management of product data.

[0004] However, the traditional product data aggregation and management methods are too single in function and have low scalability. With the continuous development of the business, the scenarios that need to obtain and apply product data will continue to grow, and the requirements for product data in different scenarios are different (for example, the need to combine data from different business modules, or fill in the values ​​of different fields in the business data separately). Currently, the gateway can only provide simple data acquisition and unified aggregation processing, and cannot distinguish different business scenarios. As a result, the business data obtained in different business scenarios cannot fit the actual application scenarios, and its accuracy still needs to be improved. Summary of the invention

[0005] Based on this, it is necessary to provide a business request processing method, apparatus, computer equipment, computer-readable storage medium and computer program product that can improve the accuracy of the obtained business data associated with different business scenarios in response to the above technical problems.

[0006] In a first aspect, the present application provides a method for processing a service request. The method comprises:

[0007] Receive a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, obtain the request parameters carried by the business data acquisition request;

[0008] Performing field parsing processing on the request parameters to obtain business fields matching the request parameters, and performing logic distribution processing and process orchestration processing based on the business fields to determine the service nodes to be called and the dependent calling relationships between the service nodes;

[0009] Calling each of the service nodes in sequence according to the dependency calling relationship to obtain the sub-service data fed back by the service node;

[0010] According to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and protocol adaptation processing and data filling processing are performed on each of the sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

[0011] In a second aspect, the present application also provides a service request processing device. The device comprises:

[0012] A request parameter acquisition module is used to receive a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, obtain the request parameters carried by the business data acquisition request;

[0013] A field parsing module is used to perform field parsing processing on the request parameters, obtain business fields matching the request parameters, and perform logic distribution processing and process orchestration processing based on each of the business fields to determine the service nodes to be called and the dependent calling relationship between each of the service nodes;

[0014] A service node calling module, used to call each of the service nodes in sequence according to the dependency calling relationship to obtain the sub-service data fed back by the service node;

[0015] The target business data acquisition module is used to determine the target protocol that matches the business data acquisition request based on the business source attributes corresponding to the business data acquisition request, and perform protocol adaptation processing and data filling processing on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

[0016] In a third aspect, the present application further provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

[0017] Receive a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, obtain the request parameters carried by the business data acquisition request;

[0018] Performing field parsing processing on the request parameters to obtain business fields matching the request parameters, and performing logic distribution processing and process orchestration processing based on the business fields to determine the service nodes to be called and the dependent calling relationships between the service nodes;

[0019] Calling each of the service nodes in sequence according to the dependency calling relationship to obtain the sub-service data fed back by the service node;

[0020] According to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and protocol adaptation processing and data filling processing are performed on each of the sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

[0021] In a fourth aspect, the present application further provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0022] Receive a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, obtain the request parameters carried by the business data acquisition request;

[0023] Performing field parsing processing on the request parameters to obtain business fields matching the request parameters, and performing logic distribution processing and process orchestration processing based on the business fields to determine the service nodes to be called and the dependent calling relationships between the service nodes;

[0024] Calling each of the service nodes in sequence according to the dependency calling relationship to obtain the sub-service data fed back by the service node;

[0025] According to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and protocol adaptation processing and data filling processing are performed on each of the sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

[0026] In a fifth aspect, the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0027] Receive a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, obtain the request parameters carried by the business data acquisition request;

[0028] Performing field parsing processing on the request parameters to obtain business fields matching the request parameters, and performing logic distribution processing and process orchestration processing based on the business fields to determine the service nodes to be called and the dependent calling relationships between the service nodes;

[0029] Calling each of the service nodes in sequence according to the dependency calling relationship to obtain the sub-service data fed back by the service node;

[0030] According to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and protocol adaptation processing and data filling processing are performed on each of the sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

[0031] In the above-mentioned business request processing method, device, computer equipment, storage medium and computer program product, by receiving a business data acquisition request, after determining that the business data acquisition request passes the business validity check, the request parameters carried by the business data acquisition request are obtained, and the request parameters are subjected to field parsing processing to obtain the business fields that match the request parameters, thereby accurately obtaining different business scenarios associated with the business data acquisition request. Based on each business field, logical distribution processing and process orchestration processing are performed to determine the service nodes to be called and the dependent calling relationship between each service node, so that each service node can be called in turn according to the dependent calling relationship to quickly and accurately obtain the sub-business data fed back by each service node, improve the efficiency of sub-business data acquisition, and ensure the correlation between each sub-business data and the business scenario to which the current business data acquisition request belongs, so that each sub-business data obtained fits the actual business scenario. Furthermore, based on the business source attributes corresponding to the business data acquisition request, the target protocol that matches the business data acquisition request is determined, and protocol adaptation processing and data filling processing are performed on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request. By comprehensively considering different business fields, obtaining sub-business data corresponding to different business fields, and further integrating and processing, complete and accurate target business data is obtained. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 An application environment diagram of a business request processing method in an embodiment;

[0033] Figure 2 A schematic diagram of a process flow of a service request processing method in an embodiment;

[0034] Figure 3 A schematic diagram of a flow chart of a method for processing a business request in another embodiment;

[0035] Figure 4A flowchart of a method for processing a business request in another embodiment;

[0036] Figure 5 A schematic diagram of a process for determining a service node to be called and a dependent calling relationship between service nodes in one embodiment;

[0037] Figure 6 A schematic diagram of a process of calling each service node in sequence according to a dependent calling relationship in an embodiment;

[0038] Figure 7 A flowchart of a method for processing a business request in another embodiment;

[0039] Figure 8 A complete flowchart of a method for processing a business request in one embodiment;

[0040] Fig. 9 is a structural block diagram of a service request processing device in one embodiment;

[0041] Fig.10 A schematic diagram of the architecture of a business request processing system in one embodiment;

[0042] Fig.11 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0043] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0044] The service request processing method provided in the embodiment of the present application can be applied to network media, smart transportation and other scenarios, and can be specifically applied to the following: Figure 1In the application environment shown, the terminal 102 communicates with the server 104 through the network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or it can be placed on the cloud or other network servers. Among them, the terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices, portable wearable devices, and aircraft, etc. The Internet of Things devices can be smart speakers, smart car-mounted devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The server 104 can be an independent physical server, or a server cluster composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal 102 and the server 104 can be directly or indirectly connected by wired or wireless communication, which is not limited in the embodiments of the present application.

[0045] Among them, the server 104 receives the business data acquisition request triggered by the terminal 102, and when it is determined that the business data acquisition request passes the business validity check, it obtains the request parameters carried by the business data acquisition request, and performs field parsing processing on the request parameters to obtain the business fields matching the request parameters. Further, the server 104 performs logic distribution processing and process orchestration processing based on each business field, determines the service node to be called, and the dependent calling relationship between each service node, and calls each service node in turn according to the dependent calling relationship to obtain the sub-business data fed back by the service node. Among them, the server 104 can determine the target protocol matching the business data acquisition request according to the business source attribute corresponding to the business data acquisition request, and perform protocol adaptation processing and data filling processing on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request. Among them, after obtaining the target business data, the server 104 can feed back the target business data to the terminal 102 where the business data acquisition request is triggered.

[0046] In one embodiment, Figure 2 As shown, a business request processing method is provided, which is applied to Figure 1 The server in the example is used to illustrate the following steps:

[0047] Step S202: receiving a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, acquiring request parameters carried in the business data acquisition request.

[0048] Among them, business data acquisition requests can be triggered by different access methods, such as application (or application platform) access, mini-program access, and web page (such as H5 page, i.e. HTML5 page) access. Different business data acquisition requests can correspond to information acquisition in different business scenarios, and the information that can be obtained specifically includes: product details information, shopping cart information, product category information, product activity page information (including promotion activity page, discount activity page, etc.), and user point page, etc.

[0049] Specifically, by receiving a business data acquisition request and parsing the business data request, the business scenario information carried by the business data request is obtained, and the preset standard attribute information matching the business source attributes is obtained, so as to verify the business validity of the business scenario information based on the preset standard attribute information matching the business scenario information.

[0050] Furthermore, when it is determined that the business data acquisition request passes the business validity check, that is, when it is determined that the business data acquisition request is a valid data request, and the business party that triggers the business data acquisition request (such as a specific application, application platform, applet, and web page, etc.) is a valid business party, the business data request is parameter parsed to obtain the request parameters carried by the business data acquisition request.

[0051] Specifically, different parameter information carried in the business data acquisition request is obtained by obtaining different parameter information, including business scenarios (such as product details information, shopping cart information, product category information, product activity page information (including promotion activity page, discount activity page, etc.) and user point page and other scenarios), details information in specific business scenarios (such as product price, product inventory, product gift configuration, full reduction configuration, product origin and product specific content and other details that need to be accessed and obtained in the product details information acquisition scenario), so as to perform parameter parsing on the business scenario and the details information in the specific business scenario, and obtain the request parameters carried in the business data acquisition request, such as business scenario parameters (product details scenario, shopping cart scenario, product category scenario, product promotion scenario, product discount scenario, user point scenario, etc.), scenario details parameters, etc. (such as the user's current points, used points, and points validity period in the user point scenario).

[0052] In one embodiment, before a specific business party (i.e., a different business party that triggers a business data acquisition request, such as a specific application, application platform, applet, web page, etc.) accesses, a business ID (i.e., APPid) is assigned to each business party that accesses, and an authentication key (i.e., AppKey) is also assigned. The business ID and authentication key assigned to each business party can be understood as preset standard attribute information that matches the business source attribute of the corresponding business party.

[0053] Specifically, after the business ID is encrypted using an encryption and decryption algorithm (such as a symmetric encryption algorithm, an asymmetric encryption algorithm, etc.), the encrypted business ID is decrypted according to the same encryption and decryption algorithm and authentication key, and a judgment is made as to whether the decrypted business ID is consistent with the business ID before encryption, so as to determine whether the business party is a valid business party, that is, whether the business data acquisition request triggered by the business party is a valid data acquisition request.

[0054] Furthermore, by adopting a method of assigning a business ID and an authentication key to a specific business party, when a business data acquisition request is received, the business scenario information carried by the business data acquisition request can be obtained, and the corresponding business ID to be verified can be determined based on the business scenario information, and then the preset standard attribute information that matches the business source attribute can be used to obtain the business ID and authentication ID that match the business source attribute of the corresponding business party, so as to encrypt the business ID to be verified according to an encryption and decryption algorithm (such as a symmetric encryption algorithm, an asymmetric encryption algorithm, etc.) to obtain the encrypted business ID to be verified, and then decrypt the encrypted business ID to be verified according to the same encryption and decryption algorithm and authentication key to determine whether the decrypted business ID to be verified is consistent with the business ID that matches the business source attribute.

[0055] Among them, if it is determined whether the decrypted business ID to be verified is consistent with the business ID matching the business source attribute, it indicates that the business data acquisition request is a valid data acquisition request, and the business party that triggers the business data acquisition request, such as a specific application, application platform, applet, and web page, is a valid business party.

[0056] Step S204, performing field parsing processing on the request parameters to obtain business fields matching the request parameters, and performing logic distribution processing and process orchestration processing based on each business field to determine the service nodes to be called and the dependent calling relationship between each service node.

[0057] Among them, the request parameters specifically include business scenario parameters and scenario detail parameters, etc. The business scenario parameters specifically include product details scenarios, shopping cart scenarios, product category scenarios, product promotion scenarios, product discount scenarios, user point scenarios, etc., and the scenario detail parameters include: product price, product inventory, product gift configuration, full discount configuration, product origin and product specific content in the product details scenario, product name, product price and product quantity in the shopping cart scenario, promotional product name, product price, product discount and product inventory in the product promotion scenario, discount product name, discount strength, product price and product inventory in the product discount scenario, current points of the user, used points, points validity period, etc. in the user point scenario.

[0058] Specifically, by performing field parsing on the request parameters, such as performing field parsing on the business scenario parameters and the scenario details parameters, the business fields that match the request parameters are obtained, specifically the actual business scenario fields (such as the product details information acquisition scenario, the shopping cart product information product acquisition scenario, the promotional product or discount product details acquisition scenario, the usage object points details acquisition scenario, etc.), and the scenario details fields corresponding to the business scenario fields (for example, in the product details information acquisition scenario, it is specifically necessary to obtain the product price, product inventory, product gift configuration, full reduction configuration, product origin, and product specific content and other details fields).

[0059] Furthermore, logical distribution processing is performed based on each business field to determine the service node to be called, and according to the dependency calling relationship between each business field (i.e., the downstream dependency information of each business field), the service node to be called is orchestrated to obtain the dependency calling relationship between each service node.

[0060] Among them, the dependency calling relationship between service nodes specifically includes serial calling, parallel calling and logical gateway calling. Specifically, service nodes with a dependency calling relationship of serial calling indicate service nodes that need to be called in sequence according to the order of the previous and next calls, while service nodes with a dependency calling relationship of parallel calling indicate service nodes that need to be called at the same time. Among them, service nodes with a dependency calling relationship of logical gateway calling indicate that by executing the judgment logic, it is determined to select the target service node when specific conditions are met. For example, when the user needs to use points to redeem a product, it is necessary to determine whether the current points of the user have reached the points required for product redemption. If it is determined that the current points of the user meet the points required for product redemption, the target service node with the points redemption function is called.

[0061] For example, to obtain product details, you first need to obtain the basic information of the product (product price, product inventory, product gift configuration, full discount configuration, etc.), call the service node with a serial call dependency call relationship, pass the basic information of the product to the pricing service node in turn, and perform product pricing on the basic information of the product by calling the pricing service, and return a dynamic activity price. Among them, after obtaining the basic information of the product, you can call each service node with a parallel call dependency call relationship to obtain the product points (i.e., points obtained after purchasing the product), product reservation information, and product postage data in parallel. Similarly, if the user needs to use points to redeem products, it is necessary to call the service node with a logical gateway call dependency call relationship to determine whether the current points of the user have reached the points required for product redemption. If it is determined that the current points of the user meet the points required for product redemption, the target service node with point redemption function is further called.

[0062] Step S206: calling each service node in sequence according to the dependent calling relationship to obtain the sub-service data fed back by the service node.

[0063] Specifically, each service node is called in sequence according to dependent calling relationships such as serial calling, parallel calling, and logical gateway calling, and the sub-business data fed back by each called service node is obtained.

[0064] For example, for the scenario of obtaining product details, you first need to call the service node with a serial call dependency relationship to obtain the basic information of the product (product price, product inventory, product purchase and gift configuration, full discount configuration, etc.), where the basic information of the product obtained can be used as the sub-business data fed back by the basic information acquisition service node of the serial call. After obtaining the basic information of the product, the basic information of the product is passed to the pricing service node in turn, and the basic information of the product is processed by calling the pricing service, and a dynamic activity price is returned. The returned dynamic activity price can be used as the sub-business data fed back by the pricing service node.

[0065] Among them, after obtaining the basic information of the product, the product points (i.e., points obtained after purchasing the product), product reservation information, product postage and other data can be obtained in parallel by calling each service node that has a dependent calling relationship with parallel calls, and the obtained product points, product reservation information, product postage data, etc. are used as sub-business data fed back by each service node called in parallel.

[0066] Similarly, if the user needs to redeem points for products, it is necessary to call a service node with a dependent call relationship with the logical gateway call to determine whether the current points of the user have reached the points required for product redemption. If it is determined that the current points of the user meet the points required for product redemption, the target service node with point redemption function is further called. In the point redemption scenario of the user, the total points of the user are deducted according to the points required for product redemption, and the product is redeemed. Among them, the points required for product redemption, the total points of the user, and the product redemption status fed back by the target service node with point redemption function are all sub-business data that can be fed back by the target service node.

[0067] Step S208, determine the target protocol that matches the business data acquisition request based on the business source attribute corresponding to the business data acquisition request, and perform protocol adaptation processing and data filling processing on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

[0068] Among them, the business data acquisition request can be triggered by different access methods, that is, corresponding to different business source attributes, where the business source attribute can be specifically understood as a specific business party, including: a specific application (such as a shopping application), an application platform (such as an e-commerce platform), a small program (such as a shopping small program loaded by a social application) and a web page (such as a shopping website page, etc.). It can be understood that since different business parties usually support different protocols, that is, the business source attributes corresponding to the business data acquisition request are different, the protocols used are different, and then the currently obtained sub-business data needs to be processed by protocol adaptation and data filling, so as to convert the sub-business data fed back by different service nodes into the target protocol format that can be received or supported by the different business parties that trigger the business data acquisition request.

[0069] Specifically, by obtaining the business source attribute corresponding to the business data acquisition request, the business parties that trigger the business data acquisition request are determined, and the target protocols actually supported by each business party are obtained, that is, the target protocol that matches the business data acquisition request is determined.

[0070] Furthermore, according to the target protocol, protocol adaptation processing is performed on each sub-service data fed back by each service node, that is, each sub-service data is converted into the target protocol format supported by each service party that triggers the service data acquisition request, and data filling processing and data assembly processing are further performed on the converted sub-service data to obtain complete target service data. Among them, by adopting the protocol adaptation processing and data filling processing, it is convenient for the corresponding service party to receive and identify the complete target service data in the target protocol format.

[0071] In one embodiment, after obtaining the target business data corresponding to the business data acquisition request, the method further includes: caching the target business data in a backup data cache.

[0072] Among them, the backup data cache can be understood as a cache that stores backup data that is fed back to each business party when one or some service nodes cannot be called normally. Specifically, for example, when the downstream pricing service is unavailable, all real-time requests will not be able to obtain product prices for a short period of time. If the current pricing service is not restored, the last stored backup cache data should be used as normal data to return, waiting for the downstream pricing service to be restored.

[0073] Furthermore, when a request for obtaining business data is received, it also includes: detecting the status of the backup cache component. If it is determined that the status of the backup cache component is in the running state, obtaining business backup data based on the backup data cache, and feeding back the business backup data to the terminal where the business data acquisition request is triggered.

[0074] Specifically, by detecting the status of the fallback cache component, that is, detecting whether the fallback cache component switch is turned on, if it is determined that the fallback cache component status is in the running state, that is, it is determined that the fallback cache component switch is turned on, the business fallback data is obtained directly based on the fallback data cache, that is, checking whether there is available data in the fallback cache, and obtaining the available business fallback data from the fallback data cache, using the business fallback data as the target business data corresponding to the current business data acquisition request, and feeding back to the terminal where the business data acquisition request is triggered, for the user to view.

[0075] It is understandable that if all downstream services are unavailable, for example, even the basic product information (including product name, product background image, product price, etc.) cannot be obtained, the method is to check whether there is available data in the backup cache, and the obtained available data is used as the target business data corresponding to the current business data acquisition request, and returned to the user object. This can avoid the user object from seeing an error page or a blank page, so as to reduce the occurrence of impaired user experience.

[0076] In the above-mentioned business request processing method, by receiving a business data acquisition request, after determining that the business data acquisition request passes the business validity check, the request parameters carried by the business data acquisition request are obtained, and the request parameters are subjected to field parsing processing to obtain the business fields matching the request parameters, thereby accurately obtaining different business scenarios associated with the business data acquisition request. Based on each business field, logical distribution processing and process orchestration processing are performed to determine the service nodes to be called and the dependent calling relationship between each service node, so that each service node can be called in sequence according to the dependent calling relationship to quickly and accurately obtain the sub-business data fed back by each service node, improve the efficiency of sub-business data acquisition, and ensure the correlation between each sub-business data and the business scenario to which the current business data acquisition request belongs, so that each sub-business data obtained fits the actual business scenario. Further, according to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and the protocol adaptation processing and data filling processing are performed on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request, and the sub-business data corresponding to the different business fields are obtained by comprehensively considering different business fields, and further integrating and processing to obtain complete and accurate target business data.

[0077] In one embodiment, Figure 3 As shown, a service request processing method is provided, which specifically includes the following steps:

[0078] Step S302: receiving a business data acquisition request, and acquiring a business source attribute corresponding to the business data acquisition request.

[0079] Specifically, by receiving a business data acquisition request and parsing the business data acquisition request to obtain the business source attributes corresponding to the business data acquisition request, that is, to determine the business party that triggers the business data acquisition request, including specific applications (such as shopping applications), application platforms (such as e-commerce platforms), applets (such as shopping applets loaded by social applications) and web pages (such as shopping website pages, etc.).

[0080] Step S304: determine the access interface based on the service source attribute, and obtain the target protocol corresponding to the access interface.

[0081] Among them, when accessing different business parties, one or more business parties can be connected to the same access interface to reduce the number of access interfaces that need to be set up, that is, each access interface can support different business party access and different request protocols, and thus it is necessary to obtain the target protocol provided by the access interface for different business parties.

[0082] Specifically, the access interface provides http protocol interface (i.e. hypertext transfer protocol) for mini programs, internal protocol interface and jce protocol interface (i.e. binary support for dynamic field addition, automatic code generation, and cross-platform communication data transmission protocol) for internal services (such as developers, testers, and operators), and internal protocol interface for front-end H5 page access (i.e. internal protocol interface for accessing front-end H5 pages). Furthermore, it is necessary to determine the target protocol set for different business source attributes of the access interface based on the different business source attributes (i.e. business parties), so as to perform protocol adaptation and conversion processing according to the target protocol.

[0083] Step S306: Perform protocol adaptation processing on the service data acquisition request according to the target protocol to obtain a standard service data acquisition request under a general request structure.

[0084] Specifically, the business data acquisition request is subjected to protocol adaptation processing according to the target protocol, that is, by converting the business data acquisition request into the target protocol format supported by the access interface, a standard business data acquisition request under the general request structure is obtained. For example, for the business data acquisition request triggered by the mini program, the access interface provides the http protocol for the mini program, that is, it is necessary to determine whether the business data acquisition request triggered by the mini program is transmitted in the http protocol mode. If so, no protocol adaptation conversion processing is required. If not, the business data acquisition request needs to be subjected to protocol adaptation processing according to the http protocol, and the business data acquisition request is converted into the http protocol format supported by the access interface, so as to obtain a standard business data acquisition request under the general request structure.

[0085] Step S308, obtaining the business scenario information carried in the standard business data acquisition request and the preset standard attribute information matching the business source attribute.

[0086] Specifically, by obtaining the business source attribute corresponding to the business data acquisition request, and obtaining the preset standard attribute information for the business source attribute, that is, the business party pre-set, including the business ID and authentication key assigned to each business party. Specifically, the business ID can be encrypted using an encryption and decryption algorithm (such as a symmetric encryption algorithm, an asymmetric encryption algorithm, etc.), and then the encrypted business ID is decrypted according to the same encryption and decryption algorithm and authentication key, and it is determined whether the decrypted business ID is consistent with the business ID before encryption, so as to determine whether the business party is a valid business party, that is, whether the business data acquisition request triggered by the business party is a valid data acquisition request.

[0087] Step S310, performing business validity verification on the business scenario information according to preset standard attribute information to obtain a corresponding validity verification result.

[0088] Specifically, when a business data acquisition request is received, the business scenario information carried by the business data acquisition request is obtained, and the corresponding business ID to be verified is determined based on the business scenario information, and then the preset standard attribute information that matches the business source attribute is matched, that is, the business ID and authentication ID that match the business source attribute of the corresponding business party are obtained, and the business ID to be verified is encrypted according to the encryption and decryption algorithm (such as symmetric encryption algorithm, asymmetric encryption algorithm, etc.) to obtain the encrypted business ID to be verified, and then the encrypted business ID to be verified is decrypted according to the same encryption and decryption algorithm and authentication key to determine whether the decrypted business ID to be verified is consistent with the business ID that matches the business source attribute.

[0089] Among them, if it is determined whether the decrypted business ID to be verified is consistent with the business ID matching the business source attribute, it indicates that the business data acquisition request is a valid data acquisition request, and the business party that triggers the business data acquisition request, such as a specific application, application platform, applet, and web page, is a valid business party.

[0090] In the above-mentioned business request processing method, by receiving a business data acquisition request, obtaining the business source attribute corresponding to the business data acquisition request, and determining the access interface based on the business source attribute, obtaining the target protocol corresponding to the access interface. Further, the business data acquisition request is subjected to protocol adaptation processing according to the target protocol, a standard business data acquisition request under a general request structure is obtained, and the business scenario information carried by the standard business data acquisition request and the preset standard attribute information matching the business source attribute are obtained, so as to perform a business validity check on the business scenario information according to the preset standard attribute information, obtain the corresponding validity check result, and realize the basis.

[0091] In one embodiment, Figure 4 As shown, a service request processing method is provided, which specifically includes the following steps:

[0092] Step S402: reporting the scenario request data under different business scenarios within a preset time period through an asynchronous queue.

[0093] Among them, in order to avoid the problem of service breakdown caused by intensive access to hotspot data, it is necessary to detect and obtain hotspot data in real time during the service process, and protect and pre-cache the hotspot data, so that when intensive access to hotspot data occurs in high-concurrency scenarios, the pre-cached hotspot data can be directly fed back to the terminal where the business data acquisition request is triggered.

[0094] Business scenarios include product details scenarios, shopping cart scenarios, product category scenarios, product promotion scenarios, product discount scenarios, user points scenarios, etc., and the scenario request data of different business scenarios can be understood as the specific request data (i.e., specific business data) that needs to be fed back and corresponds to the business data acquisition request, including: product price, product inventory, product gift configuration, full discount configuration, product origin and specific product content in the product details scenario, product name, product price and product quantity in the shopping cart scenario, promotional product name, product price, product discount and product inventory in the product promotion scenario, discount product name, discount strength, product price and product inventory in the product discount scenario, current points of the user, used points, points validity period, etc. in the user points scenario.

[0095] Specifically, by obtaining scenario request data under different business scenarios within a preset time period, such as obtaining scenario request data under different business scenarios within a day or a week, and storing the scenario request data under different business scenarios within the preset time period in an asynchronous queue in sequence, the asynchronous queue is used to report the scenario request data. Among them, the preset time period can be adjusted and set according to actual business needs, and is not limited to one or some specific values.

[0096] Among them, the use of asynchronous queues can be understood as storing the scene request data generated by short-term high concurrency in the message queue through asynchronous processing, without waiting for the previous scene request data to be stored before storing the next one, so that the request data of each scene can be quickly obtained, stored and reported. Among them, in scenarios such as product promotion activities, the reasonable use of message queues can effectively resist the service impact caused by the influx of access, data acquisition, and order placement at the beginning of the promotion activities.

[0097] Step S404: perform hotspot data verification processing based on the request data of each scenario reported by the asynchronous queue to determine the hotspot data request.

[0098] Specifically, by calling the inspection service node, the scene request data is read from the asynchronous queue in sequence, and the number of requests for each scene request data within the preset time window is obtained. Among them, the inspection service node is used to perform hot spot data inspection and maintenance, that is, to determine the hot spot data from the scene request data, and cache the hot spot data in advance, so that the hot spot data can be directly fed back to the terminal later. Among them, the number of requests for scene request data within the preset time window can be understood as the number of requests for data acquisition requests for a certain business scenario within a time window.

[0099] Furthermore, by obtaining a request count threshold corresponding to the hotspot data maintenance window associated with the inspection service node, and comparing the request count threshold with the request count, if the request count is greater than the request count threshold, the business data acquisition request corresponding to the current scene request data is determined as a hotspot data request.

[0100] Among them, the hot data maintenance window associated with the inspection service node can be understood as the request information of the data key (this data key contains information such as product number, request source and activity entry), that is, the time point of the business data acquisition request. By counting the time information of all requests, a time window is constructed, that is, the hot data maintenance window is obtained, which is used to count the number of requests within a certain period of time (such as 1 day, 3 days, 5 days, etc.). On the contrary, if the number of requests is less than the request number threshold, the statistical number of the hot data maintenance window is updated. For example, if the number of requests for a certain business scenario in the hot data maintenance window is 20 times, if the request number threshold is set to 50 times, it means that the number of requests for the business scenario has not reached the request number threshold corresponding to the hot data maintenance window, and then the number of requests for the business scenario in the hot data maintenance window is updated, such as from 20 times to 21 times.

[0101] Step S406: storing the hotspot service data matching the hotspot data request in a preset hotspot cache.

[0102] Specifically, a preset hotspot cache is set in advance for the hotspot service data, and is used to store the hotspot service data matching the determined hotspot data request.

[0103] Among them, hot business data may specifically include scenario detail data under different business scenarios, such as product price, product inventory, product purchase and gift configuration, full-discount configuration, product origin and specific product content in product detail scenarios, as well as promotional product name, product price, product discount and product inventory in product promotion scenarios, and discount product name, discount strength, product price and product inventory in product discount scenarios.

[0104] Step S408, comparing the business data acquisition request with each hotspot data request to generate a comparison result.

[0105] Specifically, by obtaining the business scenario information corresponding to the business data acquisition request and the hot business scenarios corresponding to the hot data request (such as product promotion scenarios, product discount scenarios, etc.), and comparing the business scenario information corresponding to the business data acquisition request with the hot business scenarios corresponding to the hot data request, it is determined whether the business scenario information corresponding to the business data acquisition request belongs to the hot business scenario, thereby generating the corresponding comparison result.

[0106] The comparison result specifically includes whether the business data acquisition request belongs to a hot data request, and whether the business data acquisition request does not belong to a hot data request.

[0107] Step S410: If it is determined according to the comparison result that the service data acquisition request is a hot data request, hot service data matching the hot data request is acquired from a preset hot cache, and the hot service data is determined as target service data.

[0108] Specifically, if it is determined according to the comparison result that the business data acquisition request is a hot data request, a search is performed based on the preset hot data cache to determine the hot business data that matches the hot data request, and the hot business data is determined as the target business data, so that the target business data can be directly fed back to the terminal that triggered the hot data request, so that the product service can return quickly when acquiring data, reducing the request pressure on downstream services in high-concurrency activity scenarios (such as product discount scenarios, product promotion scenarios, etc.), and avoiding service breakdown due to intensive access to hot data.

[0109] In the above-mentioned service request processing method, the scenario request data under different service scenarios within a preset time period is reported through an asynchronous queue, and based on the scenario request data reported by the asynchronous queue, hot data verification processing is performed to determine the hot data request, and the hot business data matching the hot data request is stored in a preset hotspot cache. Furthermore, by storing the hot business data matching the hot data request in a preset hotspot cache, and comparing the service data acquisition request with each hot data request, if it is determined that the service data acquisition request is a hot data request, the hot business data matching the hot data request is obtained from the preset hotspot cache to determine the hot business data as the target service data, and the real-time detection and acquisition of hot data in the service process is realized, and the hot data is protected and pre-cached, so that when there is intensive access to hot data in a high-concurrency scenario, the pre-cached hot data can be directly fed back to the terminal where the trigger service data acquisition request is located, avoiding the problem of service breakdown due to intensive access to hot data, and improving data acquisition efficiency.

[0110] In one embodiment, Figure 5 As shown, the step of determining the service nodes to be called and the dependent calling relationship between the service nodes, that is, performing logic distribution processing and process orchestration processing based on each business field, determining the service nodes to be called and the dependent calling relationship between the service nodes, specifically includes the following steps:

[0111] Step S502: Perform logic distribution processing based on each business field to determine the service node corresponding to each business field.

[0112] Among them, field parsing is performed on the request parameters, such as field parsing of business scenario parameters and scenario detail parameters, to obtain business fields that match the request parameters, specifically including actual business scenario fields (such as product detail information acquisition scenarios, shopping cart product information product acquisition scenarios, promotional product or discount product detail acquisition scenarios, object point detail acquisition scenarios, etc.), and scenario detail fields corresponding to the business scenario fields (for example, in the product detail information acquisition scenario, it is specifically necessary to obtain product price, product inventory, product gift configuration, full reduction configuration, product origin, and product specific content and other detail fields).

[0113] Specifically, logical distribution processing is performed based on each business field to determine the service nodes to be called, such as business scenario fields such as product details information acquisition scenarios, shopping cart product information product acquisition scenarios, promotional product or discount product details acquisition scenarios, and object points details acquisition scenarios, as well as logical distribution processing, product price, product inventory, product gift configuration, full reduction configuration, product origin, and product specific content in the product details information acquisition scenario, to determine the service nodes to be called, such as determining the service nodes corresponding to the product details information acquisition scenario, and the service nodes corresponding to the promotional product details acquisition scenario.

[0114] For example, to obtain product details, you first need to obtain the basic information of the product (product price, product inventory, product gift configuration, full discount configuration, etc.), call the service node with a serial call dependency call relationship, pass the basic information of the product to the pricing service node in turn, and perform product pricing on the basic information of the product by calling the pricing service, and return a dynamic activity price. After obtaining the basic information of the product, you can call each service node with a parallel call dependency call relationship to obtain the product points (i.e. points obtained after purchasing the product), product reservation information, product postage and other data in parallel.

[0115] Similarly, if the user needs to use points to redeem products, it is necessary to call the service node that has a dependent call relationship with the logical gateway call to determine whether the current points of the user have reached the points required for product redemption. If it is determined that the current points of the user meet the points required for product redemption, the target service node with points redemption function is further called.

[0116] Step S504: Acquire downstream dependency information corresponding to each business field, and determine the dependency relationship between the business fields according to the downstream dependency information.

[0117] Each service node is used to perform different operations such as data acquisition, data processing, and data feedback. Each service node is set with its own operations or tasks, such as obtaining product points data, obtaining product discounts, obtaining product purchase and gift configurations, and obtaining product full discount configurations. According to the different tasks to be performed, each service node is injected with the downstream dependency information it needs to use, so as to ensure that the downstream service nodes can be called normally.

[0118] Specifically, by obtaining the downstream dependency information corresponding to each business field, such as the fields of the product details information acquisition scenario, the fields with dependency relationships include product price, product inventory, product gift configuration, full-reduction configuration, product origin, and product specific content, that is, the downstream dependency information of the product details information acquisition scenario fields includes product price, product inventory, product gift configuration, full-reduction configuration, product origin, and product specific content, etc., which means that there is a dependency call relationship between the service nodes used to obtain product price, product inventory, product gift configuration, full-reduction configuration, product origin, and product specific content, and the service nodes corresponding to the product details information acquisition scenario fields.

[0119] Step S506: Perform flow arrangement processing according to the dependency relationship between the service fields to determine the dependency calling relationship between the service nodes.

[0120] Specifically, according to the dependency relationship between various business fields, such as the fields of the product details information acquisition scenario, and the fields of product price, product inventory, product gift configuration, full-discount configuration, product origin and product specific content that have dependency relationships, process orchestration processing is performed, that is, the dependency calling relationship between the service nodes used to obtain product price, product inventory, product gift configuration, full-discount configuration, product origin and product specific content, and the service nodes corresponding to the product details information acquisition scenario fields is determined.

[0121] For example, based on the service nodes corresponding to the scene fields for obtaining product details information, determine the service nodes with dependent calling relationships, obtain the basic information of the product (including product price, product inventory, product gift configuration, and full-discount configuration, etc.), and call the service nodes with serial calling dependent calling relationships between the service nodes that obtain product details information, pass the basic information of the product to the pricing service node in turn, perform product pricing on the basic information of the product by calling the pricing service, and return a dynamic activity price.

[0122] In one embodiment, Figure 6 As shown, a schematic diagram of the process of calling each service node in sequence according to the dependent calling relationship is provided. Figure 6It can be seen that there is a serial call dependency relationship between service node node1 (for example, the service node corresponding to the product details information acquisition scenario field), service node node2 (for example, the service node for obtaining product prices), and service node node3 (for example, the service node for obtaining product full-reduction configuration), that is, service node node1, service node node2, and service node node3 constitute a serial task (that is, ChainNode), and service node 4 is an intermediate service node, which is used to further analyze and process the output results of the serial task (for example, it is used to further analyze and price according to the product price and product full-reduction configuration to obtain the product price corresponding to the current product).

[0123] Further, refer to Figure 6 It can be seen that service node node5 and service node node6 constitute a logical gateway task (i.e., GateWayNode). By executing the judgment logic, it is determined to select the target service node when specific conditions are met, such as selecting service node node5 when the specific conditions are met, and selecting service node node6 when the specific conditions are not met. Specifically, for example, when the user needs to use points to redeem a product, it is necessary to determine whether the current points of the user have reached the points required for product redemption. If it is determined that the current points of the user meet the points required for product redemption, the target service node node5 with the points redemption function is called.

[0124] Among them, after calling the target service node node5 with the point redemption function, the service node node7 and the service node node8 with a parallel calling relationship are further called, that is, the service node node7 and the service node node8 constitute a parallel task (i.e. ParallelNode). For example, through the service node node7 and the service node node8, the product points, the total points of the user, and the product postage data can be obtained in parallel.

[0125] For example, the dependent calling relationship between each service node and the calling process of each service node are reflected in the following forms:

[0126] Serial tasks (product static, product dynamic) -> logical gateway tasks (is the product off the shelves?) -> if it is not off the shelves, parallel tasks (product points, product postage, product coupons, product reservation information) -> if it is off the shelves, directly use the product dynamic data and static data to construct the basic product data return.

[0127] Among them, the serial tasks include service node A for obtaining product static data (such as product name, product background image, etc.), and service node B for obtaining product dynamic data (such as product price, product inventory, product full reduction configuration, product purchase and gift configuration, etc.). The judgment logic set by the logical gateway task is "Is the product off the shelf?" If the product is not off the shelf, the target service node B is called. Among them, the parallel tasks include service nodes for obtaining product points, product postage, product coupons, and product reservation information. Each service node can be called at the same time to obtain product points, product postage, product coupons, product reservation information and other data of the product that has not been off the shelf. Among them, if the product is off the shelf, service node C is called to construct basic product data with the static data and dynamic data of the product and return it.

[0128] In this embodiment, logical distribution processing is performed based on each business field, the service node corresponding to each business field is determined, the downstream dependency information corresponding to each business field is obtained, the dependency relationship between each business field is determined based on the downstream dependency information, and flow orchestration processing is performed based on the dependency relationship between each business field to determine the dependency calling relationship between each service node, so that each service node can be accurately called based on an accurate and comprehensive dependency calling relationship in the future, thereby avoiding the omission of sub-business data and improving the acquisition efficiency and data accuracy of sub-business data.

[0129] In one embodiment, a business request processing method is provided, which specifically includes: obtaining the status of a grayscale traffic component, and if the grayscale traffic component status is in a running state, performing grayscale traffic distribution confirmation processing based on a business data acquisition request; if it is determined that the business data acquisition request belongs to a grayscale traffic interface, dividing the target business data corresponding to the business data acquisition request into the grayscale traffic; performing application development version verification based on the grayscale traffic to obtain a corresponding version verification result; the version verification result is used to determine the development status of the application development version, and the development status includes development failure and development success.

[0130] Among them, according to the iteration requirements of application development versions, a grayscale traffic component is set up to control the traffic switching rate during application development or service upgrades. For example, when a new functional module is launched and needs to be verified, in order to ensure the stability of the online service, part of the traffic requests need to be switched to the new development version with the new functional module, while the other part of the traffic requests remain in the previous stable version, that is, the grayscale traffic component is introduced to effectively control the switching rate of traffic requests.

[0131] Specifically, by obtaining the status of the grayscale traffic component, that is, obtaining the on status of the grayscale traffic switch, if the grayscale traffic component status is in the running state, that is, the grayscale traffic switch is in the on state, then the grayscale traffic distribution confirmation processing is performed based on the business data acquisition request.

[0132] Furthermore, if it is determined that the business data acquisition request belongs to the grayscale traffic interface, the target business data corresponding to the business data acquisition request will be divided into the grayscale traffic, and the application development version verification will be performed based on the grayscale traffic to obtain a version verification result for determining the development status of the application development version, where the development status of the development version specifically includes development failure and development success.

[0133] In one embodiment, if it is determined that the business data acquisition request belongs to the online traffic interface, the target business data corresponding to the business data acquisition request is classified into the online traffic. Based on the online traffic, the current version of the application or service can be checked and verified to determine whether the current version has a fault, so as to perform maintenance and processing in real time when a fault occurs.

[0134] In the above-mentioned business request processing method, by obtaining the status of the grayscale traffic component, if the grayscale traffic component status is in the running state, the grayscale traffic distribution confirmation processing is performed based on the business data acquisition request, and the target business data corresponding to the business data acquisition request belonging to the grayscale traffic interface is divided into the grayscale traffic, and the application development version is verified based on the grayscale traffic to obtain the corresponding version verification result, and the development status of the application development version is determined according to the version verification result, including development failure and development success, thereby realizing the grayscale release of application development or service development, completing the version development of new services or applications while ensuring the stability of the current application or service, and improving the efficiency of application or service development without interrupting the currently provided application functions or service functions.

[0135] In one embodiment, Figure 7 As shown, a service request processing method is provided, which specifically includes the following steps:

[0136] Step S701: reporting the scenario request data under different business scenarios within a preset time period through an asynchronous queue.

[0137] Among them, in order to avoid the problem of service breakdown caused by intensive access to hotspot data, it is necessary to detect and obtain hotspot data in real time during the service process, and protect and pre-cache the hotspot data, so that when intensive access to hotspot data occurs in high-concurrency scenarios, the pre-cached hotspot data can be directly fed back to the terminal where the business data acquisition request is triggered.

[0138] Specifically, by obtaining scenario request data under different business scenarios within a preset time period, such as obtaining scenario request data under different business scenarios within a day or a week, and storing the scenario request data under different business scenarios within the preset time period in an asynchronous queue in sequence, the asynchronous queue is used to report the scenario request data. Among them, the preset time period can be adjusted and set according to actual business needs, and is not limited to one or some specific values.

[0139] Furthermore, the use of asynchronous queues can be understood as storing the scene request data generated by short-term high concurrency in the message queue through asynchronous processing, without waiting for the previous scene request data to be stored before storing the next one, so that the request data of each scene can be quickly acquired, stored and reported. In scenarios such as product promotion activities, the reasonable use of message queues can effectively resist the service impact caused by the influx of access, data acquisition, and order placement operations at the beginning of the promotion activities.

[0140] Step S702: calling the inspection service node, reading the scene request data from the asynchronous queue in sequence, and obtaining the request times of each scene request data within a preset time window.

[0141] Among them, the inspection service node is used to inspect and maintain hot data, that is, the inspection service node is used to determine the hot data from the scene request data and cache the hot data in advance so that the hot data can be directly fed back to the terminal later. Among them, the number of requests for scene request data within a preset time window can be understood as the number of requests for data acquisition requests for a certain business scene within a time window.

[0142] Step S703: Obtain a request count threshold corresponding to the hotspot data maintenance window associated with the inspection service node, and compare the request count threshold with the request count.

[0143] Specifically, a request number threshold corresponding to the hotspot data maintenance window associated with the inspection service node is obtained, and the request number threshold is compared with the request number.

[0144] Among them, the hotspot data maintenance window associated with the inspection service node can be understood as the request information of the data key (this data key contains information such as the product number, request source, and activity entry), that is, the time point of the business data acquisition request. By counting the time information of all requests, a time window is constructed, that is, the hotspot data maintenance window is obtained, which is used to count the number of requests within a certain period of time (such as 1 day, 3 days, 5 days, etc.).

[0145] Step S704, if the number of requests is greater than the request number threshold, the business data acquisition request corresponding to the current scene request data is determined as a hotspot data request, and the hotspot business data matching the hotspot data request is stored in a preset hotspot cache.

[0146] Specifically, if the number of requests is greater than the request number threshold, the business data acquisition request corresponding to the current scene request data is determined to be a hot data request. A preset hotspot cache is set in advance for the hotspot business data to store the hotspot business data that matches the determined hotspot data request. When it is determined that the business data acquisition request corresponding to the current scene request data is a hotspot data request, the hotspot business data that matches the hotspot data request is stored in the preset hotspot cache.

[0147] Among them, hot business data may specifically include scenario detail data under different business scenarios, such as product price, product inventory, product purchase and gift configuration, full-discount configuration, product origin and specific product content in product detail scenarios, as well as promotional product name, product price, product discount and product inventory in product promotion scenarios, and discount product name, discount strength, product price and product inventory in product discount scenarios.

[0148] In one embodiment, if the number of requests is less than the request number threshold, the statistical number of the hotspot data maintenance window is updated. For example, the number of requests for a certain business scenario in the hotspot data maintenance window is counted as 20 times. If the request number threshold is set to 50 times, it means that the number of requests for the business scenario has not reached the request number threshold corresponding to the hotspot data maintenance window, and then the number of requests for the business scenario in the hotspot data maintenance window is updated, for example, from 20 times to 21 times.

[0149] Step S705: compare the business data acquisition request with each hotspot data request to generate a comparison result.

[0150] Specifically, by obtaining the business scenario information corresponding to the business data acquisition request and the hot business scenarios corresponding to the hot data request (such as product promotion scenarios, product discount scenarios, etc.), and comparing the business scenario information corresponding to the business data acquisition request with the hot business scenarios corresponding to the hot data request, it is determined whether the business scenario information corresponding to the business data acquisition request belongs to the hot business scenario, thereby generating the corresponding comparison result.

[0151] The comparison result specifically includes whether the business data acquisition request belongs to a hot data request, and whether the business data acquisition request does not belong to a hot data request.

[0152] Step S706: if it is determined according to the comparison result that the service data acquisition request is a hot data request, hot service data matching the hot data request is acquired from a preset hot cache, and the hot service data is determined as target service data.

[0153] Specifically, if it is determined according to the comparison result that the business data acquisition request is a hot data request, a search is performed based on the preset hot data cache to determine the hot business data that matches the hot data request, and the hot business data is determined as the target business data, so that the target business data can be directly fed back to the terminal that triggered the hot data request, so that the product service can return quickly when acquiring data, reducing the request pressure on downstream services in high-concurrency activity scenarios (such as product discount scenarios, product promotion scenarios, etc.), and avoiding service breakdown due to intensive access to hot data.

[0154] Step S707, if the business data acquisition request is determined to be a non-hotspot data request according to the comparison result, obtain the business source attribute corresponding to the business data acquisition request, determine the access interface based on the business source attribute, and obtain the target protocol corresponding to the access interface.

[0155] Specifically, if it is determined according to the comparison results that the business data acquisition request does not belong to a hot data request, the business data acquisition request is parsed to obtain the business source attributes corresponding to the business data acquisition request, that is, the business party that triggers the business data acquisition request is determined, including specific applications (such as shopping applications), application platforms (such as e-commerce platforms), applets (such as shopping applets loaded by social applications) and web pages (such as shopping website pages, etc.).

[0156] Furthermore, when accessing different business parties, one or more business parties can be connected to the same access interface to reduce the number of access interfaces that need to be set up, that is, each access interface can support access by different business parties and different request protocols, and thus it is necessary to determine the access interface based on the business source attributes, and further obtain the target protocol provided by the access interface for different business parties.

[0157] Specifically, the access interface provides http protocol interface (i.e. hypertext transfer protocol) for mini programs, internal protocol interface and jce protocol interface (i.e. binary support for dynamic field addition, automatic code generation, and cross-platform communication data transmission protocol) for internal services (such as developers, testers, and operators), and internal protocol interface for front-end H5 page access (i.e. internal protocol interface for accessing front-end H5 pages). Furthermore, it is necessary to determine the target protocol set for different business source attributes of the access interface based on the different business source attributes (i.e. business parties), so as to perform protocol adaptation and conversion processing according to the target protocol.

[0158] Step S708: Perform protocol adaptation processing on the service data acquisition request according to the target protocol to obtain a standard service data acquisition request under a general request structure.

[0159] Specifically, the business data acquisition request is subjected to protocol adaptation processing according to the target protocol, that is, by converting the business data acquisition request into the target protocol format supported by the access interface, a standard business data acquisition request under the general request structure is obtained. For example, for the business data acquisition request triggered by the mini program, the access interface provides the http protocol for the mini program, that is, it is necessary to determine whether the business data acquisition request triggered by the mini program is transmitted in the http protocol mode. If so, no protocol adaptation conversion processing is required. If not, the business data acquisition request needs to be subjected to protocol adaptation processing according to the http protocol, and the business data acquisition request is converted into the http protocol format supported by the access interface, so as to obtain a standard business data acquisition request under the general request structure.

[0160] Step S709: Acquire the business scenario information carried in the standard business data acquisition request and preset standard attribute information matching the business source attribute.

[0161] Specifically, by obtaining the business source attribute corresponding to the business data acquisition request, and obtaining the preset standard attribute information for the business source attribute, that is, the business party pre-set, including the business ID and authentication key assigned to each business party. Specifically, the business ID can be encrypted using an encryption and decryption algorithm (such as a symmetric encryption algorithm, an asymmetric encryption algorithm, etc.), and then the encrypted business ID is decrypted according to the same encryption and decryption algorithm and authentication key, and it is determined whether the decrypted business ID is consistent with the business ID before encryption, so as to determine whether the business party is a valid business party, that is, whether the business data acquisition request triggered by the business party is a valid data acquisition request.

[0162] Step S710, performing business validity verification on the business scenario information according to preset standard attribute information to obtain a corresponding validity verification result.

[0163] Specifically, when a business data acquisition request is received, the business scenario information carried by the business data acquisition request is obtained, and the corresponding business ID to be verified is determined based on the business scenario information, and then the preset standard attribute information that matches the business source attribute is matched, that is, the business ID and authentication ID that match the business source attribute of the corresponding business party are obtained, and the business ID to be verified is encrypted according to the encryption and decryption algorithm (such as symmetric encryption algorithm, asymmetric encryption algorithm, etc.) to obtain the encrypted business ID to be verified, and then the encrypted business ID to be verified is decrypted according to the same encryption and decryption algorithm and authentication key to determine whether the decrypted business ID to be verified is consistent with the business ID that matches the business source attribute.

[0164] Among them, if it is determined whether the decrypted business ID to be verified is consistent with the business ID matching the business source attribute, it indicates that the business data acquisition request is a valid data acquisition request, and the business party that triggers the business data acquisition request, such as a specific application, application platform, applet, and web page, is a valid business party.

[0165] Step S711: If it is determined that the business data acquisition request passes the business validity check, the request parameters carried in the business data acquisition request are acquired.

[0166] Specifically, if it is determined that the business data acquisition request passes the business validity check, that is, it is determined that the business data acquisition request is a valid data request, and the business party that triggers the business data acquisition request (such as a specific application, application platform, applet, and web page, etc.) is a valid business party, the business data request is parsed by parameters to obtain the request parameters carried by the business data acquisition request.

[0167] Specifically, different parameter information carried in the business data acquisition request is obtained by obtaining different parameter information, including business scenarios (such as product details information, shopping cart information, product category information, product activity page information (including promotion activity page, discount activity page, etc.) and user point page and other scenarios), details information in specific business scenarios (such as product price, product inventory, product gift configuration, full reduction configuration, product origin and product specific content and other details that need to be accessed and obtained in the product details information acquisition scenario), so as to perform parameter parsing on the business scenario and the details information in the specific business scenario, and obtain the request parameters carried in the business data acquisition request, such as business scenario parameters (product details scenario, shopping cart scenario, product category scenario, product promotion scenario, product discount scenario, user point scenario, etc.), scenario details parameters, etc. (such as the user's current points, used points, and points validity period in the user point scenario).

[0168] Step S712: Perform field parsing on the request parameters to obtain business fields that match the request parameters.

[0169] Among them, the request parameters specifically include business scenario parameters and scenario detail parameters, etc. The business scenario parameters specifically include product details scenarios, shopping cart scenarios, product category scenarios, product promotion scenarios, product discount scenarios, user point scenarios, etc., and the scenario detail parameters include: product price, product inventory, product gift configuration, full discount configuration, product origin and product specific content in the product details scenario, product name, product price and product quantity in the shopping cart scenario, promotional product name, product price, product discount and product inventory in the product promotion scenario, discount product name, discount strength, product price and product inventory in the product discount scenario, current points of the user, used points, points validity period, etc. in the user point scenario.

[0170] Specifically, by performing field parsing on the request parameters, such as performing field parsing on the business scenario parameters and the scenario details parameters, the business fields that match the request parameters are obtained, specifically the actual business scenario fields (such as the product details information acquisition scenario, the shopping cart product information product acquisition scenario, the promotional product or discount product details acquisition scenario, the usage object points details acquisition scenario, etc.), and the scenario details fields corresponding to the business scenario fields (for example, in the product details information acquisition scenario, it is specifically necessary to obtain the product price, product inventory, product gift configuration, full reduction configuration, product origin, and product specific content and other details fields).

[0171] Step S713: Perform logic distribution processing based on each business field to determine the service node corresponding to each business field.

[0172] Specifically, logical distribution processing is performed based on each business field to determine the service nodes to be called, such as business scenario fields such as product details information acquisition scenarios, shopping cart product information product acquisition scenarios, promotional product or discount product details acquisition scenarios, and object points details acquisition scenarios, as well as logical distribution processing, product price, product inventory, product gift configuration, full reduction configuration, product origin, and product specific content in the product details information acquisition scenario, to determine the service nodes to be called, such as determining the service nodes corresponding to the product details information acquisition scenario, and the service nodes corresponding to the promotional product details acquisition scenario.

[0173] For example, to obtain product details, you first need to obtain the basic information of the product (product price, product inventory, product gift configuration, full discount configuration, etc.), call the service node with a serial call dependency call relationship, pass the basic information of the product to the pricing service node in turn, and perform product pricing on the basic information of the product by calling the pricing service, and return a dynamic activity price. After obtaining the basic information of the product, you can call each service node with a parallel call dependency call relationship to obtain the product points (i.e. points obtained after purchasing the product), product reservation information, product postage and other data in parallel.

[0174] Similarly, if the user needs to use points to redeem products, it is necessary to call the service node that has a dependent call relationship with the logical gateway call to determine whether the current points of the user have reached the points required for product redemption. If it is determined that the current points of the user meet the points required for product redemption, the target service node with points redemption function is further called.

[0175] Step S714, acquiring downstream dependency information corresponding to each business field, and determining the dependency relationship between the business fields according to the downstream dependency information.

[0176] Each service node is used to perform different operations such as data acquisition, data processing, and data feedback. Each service node is set with its own operations or tasks, such as obtaining product points data, obtaining product discounts, obtaining product purchase and gift configurations, and obtaining product full discount configurations. According to the different tasks to be performed, each service node is injected with the downstream dependency information it needs to use, so as to ensure that the downstream service nodes can be called normally.

[0177] Specifically, by obtaining the downstream dependency information corresponding to each business field, such as the fields of the product details information acquisition scenario, the fields with dependency relationships include product price, product inventory, product gift configuration, full-reduction configuration, product origin, and product specific content, that is, the downstream dependency information of the product details information acquisition scenario fields includes product price, product inventory, product gift configuration, full-reduction configuration, product origin, and product specific content, etc., which means that there is a dependency call relationship between the service nodes used to obtain product price, product inventory, product gift configuration, full-reduction configuration, product origin, and product specific content, and the service nodes corresponding to the product details information acquisition scenario fields.

[0178] Step S715, perform flow orchestration processing according to the dependency relationship between each business field, determine the dependency calling relationship between each service node, and the dependency calling relationship between the service nodes includes serial calling, parallel calling and logical gateway calling.

[0179] Among them, the dependency calling relationship between service nodes specifically includes serial calling, parallel calling and logical gateway calling. Specifically, service nodes with a dependency calling relationship of serial calling indicate service nodes that need to be called in sequence according to the order of the previous and next calls, while service nodes with a dependency calling relationship of parallel calling indicate service nodes that need to be called at the same time. Among them, service nodes with a dependency calling relationship of logical gateway calling indicate that by executing the judgment logic, it is determined to select the target service node when specific conditions are met. For example, when the user needs to use points to redeem a product, it is necessary to determine whether the current points of the user have reached the points required for product redemption. If it is determined that the current points of the user meet the points required for product redemption, the target service node with the points redemption function is called.

[0180] Specifically, according to the dependency relationship between each business field, such as the fields in the product details information acquisition scenario, the fields with dependency relationships such as product price, product inventory, product gift configuration, full reduction configuration, product origin, and product specific content, the process orchestration processing is performed, that is, the dependency call relationship between the service nodes for obtaining product price, product inventory, product gift configuration, full reduction configuration, product origin, and product specific content, and the service nodes corresponding to the product details information acquisition scenario fields is determined. For example, according to the service nodes corresponding to the product details information acquisition scenario fields, each service node with a dependency call relationship is determined, the basic information of the product (including product price, product inventory, product gift configuration, and full reduction configuration, etc.) is obtained, and each service node with a serial call dependency call relationship between the service node that obtains the product details information is called, and the basic information of the product is passed to the pricing service node in turn, and the product pricing processing is performed on the basic information of the product by calling the pricing service, and a dynamic activity price is returned.

[0181] Step S716: Call each service node in sequence according to the dependent calling relationship to obtain the sub-service data fed back by the service node.

[0182] Specifically, each service node is called in sequence according to dependent calling relationships such as serial calling, parallel calling, and logical gateway calling, and the sub-business data fed back by each called service node is obtained.

[0183] For example, for the scenario of obtaining product details, you first need to call the service node with a serial call dependency relationship to obtain the basic information of the product (product price, product inventory, product purchase and gift configuration, full discount configuration, etc.), where the basic information of the product obtained can be used as the sub-business data fed back by the basic information acquisition service node of the serial call. After obtaining the basic information of the product, the basic information of the product is passed to the pricing service node in turn, and the basic information of the product is processed by calling the pricing service, and a dynamic activity price is returned. The returned dynamic activity price can be used as the sub-business data fed back by the pricing service node.

[0184] Among them, after obtaining the basic information of the product, the product points (i.e., points obtained after purchasing the product), product reservation information, product postage and other data can be obtained in parallel by calling each service node that has a dependent calling relationship with parallel calls, and the obtained product points, product reservation information, product postage data, etc. are used as sub-business data fed back by each service node called in parallel.

[0185] Similarly, if the user needs to redeem points for products, it is necessary to call a service node with a dependent call relationship with the logical gateway call to determine whether the current points of the user have reached the points required for product redemption. If it is determined that the current points of the user meet the points required for product redemption, the target service node with point redemption function is further called. In the point redemption scenario of the user, the total points of the user are deducted according to the points required for product redemption, and the product is redeemed. Among them, the points required for product redemption, the total points of the user, and the product redemption status fed back by the target service node with point redemption function are all sub-business data that can be fed back by the target service node.

[0186] Step S717, determine the target protocol that matches the business data acquisition request based on the business source attribute corresponding to the business data acquisition request, and perform protocol adaptation processing and data filling processing on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

[0187] Among them, the business data acquisition request can be triggered by different access methods, that is, corresponding to different business source attributes, where the business source attribute can be specifically understood as a specific business party, including: a specific application (such as a shopping application), an application platform (such as an e-commerce platform), a small program (such as a shopping small program loaded by a social application) and a web page (such as a shopping website page, etc.). It can be understood that since different business parties usually support different protocols, that is, the business source attributes corresponding to the business data acquisition request are different, the protocols used are different, and then the currently obtained sub-business data needs to be processed by protocol adaptation and data filling, so as to convert the sub-business data fed back by different service nodes into the target protocol format that can be received or supported by the different business parties that trigger the business data acquisition request.

[0188] Specifically, by obtaining the business source attribute corresponding to the business data acquisition request, the business parties that trigger the business data acquisition request are determined, and the target protocols actually supported by each business party are obtained, that is, the target protocol that matches the business data acquisition request is determined.

[0189] Furthermore, according to the target protocol, protocol adaptation processing is performed on each sub-service data fed back by each service node, that is, each sub-service data is converted into the target protocol format supported by each service party that triggers the service data acquisition request, and data filling processing and data assembly processing are further performed on the converted sub-service data to obtain complete target service data. Among them, by adopting the protocol adaptation processing and data filling processing, it is convenient for the corresponding service party to receive and identify the complete target service data in the target protocol format.

[0190] Step S718, cache the target business data into the backup data cache.

[0191] Among them, the backup data cache can be understood as a cache that stores backup data that is fed back to each business party when one or some service nodes cannot be called normally. Specifically, for example, when the downstream pricing service is unavailable, all real-time requests will not be able to obtain product prices for a short period of time. If the current pricing service is not restored, the last stored backup cache data should be used as normal data to return, waiting for the downstream pricing service to be restored.

[0192] Step S719, detecting the state of the backup cache component, if it is determined that the state of the backup cache component is in the running state, obtaining the business backup data based on the backup data cache, and feeding back the business backup data to the terminal where the business data acquisition request is triggered.

[0193] Specifically, by detecting the status of the fallback cache component, that is, detecting whether the fallback cache component switch is turned on, if it is determined that the fallback cache component status is in the running state, that is, it is determined that the fallback cache component switch is turned on, the business fallback data is obtained directly based on the fallback data cache, that is, checking whether there is available data in the fallback cache, and obtaining the available business fallback data from the fallback data cache, using the business fallback data as the target business data corresponding to the current business data acquisition request, and feeding back to the terminal where the business data acquisition request is triggered, for the user to view.

[0194] It is understandable that if all downstream services are unavailable, for example, even the basic product information (including product name, product background image, product price, etc.) cannot be obtained, the method is to check whether there is available data in the backup cache, and the obtained available data is used as the target business data corresponding to the current business data acquisition request, and returned to the user object. This can avoid the user object from seeing an error page or a blank page, so as to reduce the occurrence of impaired user experience.

[0195] In the above-mentioned business request processing method, by receiving a business data acquisition request, after determining that the business data acquisition request passes the business validity check, the request parameters carried by the business data acquisition request are obtained, and the request parameters are subjected to field parsing processing to obtain the business fields matching the request parameters, thereby accurately obtaining different business scenarios associated with the business data acquisition request. Based on each business field, logical distribution processing and process orchestration processing are performed to determine the service nodes to be called and the dependent calling relationship between each service node, so that each service node can be called in sequence according to the dependent calling relationship to quickly and accurately obtain the sub-business data fed back by each service node, improve the efficiency of sub-business data acquisition, and ensure the correlation between each sub-business data and the business scenario to which the current business data acquisition request belongs, so that each sub-business data obtained fits the actual business scenario. Further, according to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and the protocol adaptation processing and data filling processing are performed on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request, and the sub-business data corresponding to the different business fields are obtained by comprehensively considering different business fields, and further integrating and processing to obtain complete and accurate target business data.

[0196] In one embodiment, Figure 8 As shown, a service request processing method is provided, which specifically includes the following steps:

[0197] Step S801, determine the operating status of the grayscale flow component status.

[0198] Step S802: If the grayscale traffic component state is in the running state and the business data acquisition request hits the grayscale traffic, the business data acquisition request is divided into the grayscale traffic interface.

[0199] Step S803: If the grayscale traffic component state is in the running state and the business data acquisition request hits the online traffic, the business data acquisition request is divided into the online interface.

[0200] After executing step S802 or step S803, step S804 is executed to perform a business validity check based on the business data acquisition request.

[0201] Step S805: If it is determined that the business data acquisition request passes the business validity check, then it is determined that the current access interface is valid.

[0202] Step S806: If it is determined that the business data acquisition request does not pass the business validity check, it is determined that the current access interface is invalid.

[0203] After executing step S805, step S807 is executed to determine whether the current business data acquisition request can successfully match the business scenario.

[0204] Step S808: If it is determined that the business scenario is successfully matched, the scenario information corresponding to the current business data acquisition request is determined to be a valid scenario.

[0205] Step S809: If it is determined that the business scenario is not successfully matched, it is determined that the scenario information corresponding to the current business data acquisition request is an invalid scenario.

[0206] After executing step S808, execute step S810 to determine the status of the backup cache component.

[0207] Step S811: If the state of the backup cache component is the running state, the business backup data is obtained based on the backup data cache, and the business backup data is fed back to the terminal where the business data acquisition request is triggered.

[0208] After executing step S810, execute step S812. If the state of the backup cache component is stopped, perform logic distribution processing based on each business field to determine the service node corresponding to each business field.

[0209] Step S813, acquiring downstream dependency information corresponding to each business field, and determining the dependency relationship between the business fields according to the downstream dependency information.

[0210] Step S814: perform flow arrangement processing according to the dependency relationship between the business fields to determine the dependency calling relationship between the service nodes.

[0211] Step S815: Call each service node in sequence according to the dependent calling relationship to obtain the sub-service data fed back by the service node.

[0212] Step S816: Determine a target protocol that matches the business data acquisition request based on the business source attribute corresponding to the business data acquisition request.

[0213] Step S817, performing protocol adaptation processing and data filling processing on each sub-service data according to the target protocol, and obtaining the target service data corresponding to the service data acquisition request.

[0214] Step S818, cache the target business data into the backup data cache.

[0215] Step S819: reporting the scenario request data under different business scenarios within a preset time period through an asynchronous queue.

[0216] Step S820, based on the request data of each scenario reported by the asynchronous queue, hotspot data verification processing is performed to determine the hotspot data request, and the hotspot service data matching the hotspot data request is stored in a preset hotspot cache.

[0217] Step S821: If it is determined that the service data acquisition request is a hotspot data request, hotspot service data matching the hotspot data request is acquired from a preset hotspot cache, and the hotspot service data is determined as target service data.

[0218] Step S822, determine whether the current business data acquisition request fails.

[0219] Step S823: If the request fails, a failure event is reported.

[0220] Step S824: If the request is successful, a normal response is made and the determined target service data is fed back to the terminal.

[0221] After executing step S806 or executing step S809, execute step S822.

[0222] In the above-mentioned business request processing method, by receiving a business data acquisition request, after determining that the business data acquisition request passes the business validity check, the request parameters carried by the business data acquisition request are obtained, and the request parameters are subjected to field parsing processing to obtain the business fields matching the request parameters, thereby accurately obtaining different business scenarios associated with the business data acquisition request. Based on each business field, logical distribution processing and process orchestration processing are performed to determine the service nodes to be called and the dependent calling relationship between each service node, so that each service node can be called in sequence according to the dependent calling relationship to quickly and accurately obtain the sub-business data fed back by each service node, improve the efficiency of sub-business data acquisition, and ensure the correlation between each sub-business data and the business scenario to which the current business data acquisition request belongs, so that each sub-business data obtained fits the actual business scenario. Further, according to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and the protocol adaptation processing and data filling processing are performed on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request, and the sub-business data corresponding to the different business fields are obtained by comprehensively considering different business fields, and further integrating and processing to obtain complete and accurate target business data.

[0223] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0224] Based on the same inventive concept, the embodiment of the present application also provides a service request processing device for implementing the service request processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the one or more service request processing device embodiments provided below can refer to the limitations on the service request processing method above, and will not be repeated here.

[0225] In one embodiment, Fig. 9 As shown, a service request processing device is provided, including: a request parameter acquisition module 902, a field parsing module 904, a service node calling module 906 and a target service data acquisition module 908, wherein:

[0226] The request parameter acquisition module 902 is used to receive a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, obtain the request parameters carried by the business data acquisition request;

[0227] The field parsing module 904 is used to perform field parsing on the request parameters, obtain the business fields that match the request parameters, and perform logic distribution and process orchestration based on the business fields to determine the service nodes to be called and the dependent calling relationships between the service nodes.

[0228] The service node calling module 906 is used to call each service node in turn according to the dependent calling relationship to obtain the sub-service data fed back by the service node;

[0229] The target business data acquisition module 908 is used to determine the target protocol that matches the business data acquisition request based on the business source attributes corresponding to the business data acquisition request, and perform protocol adaptation processing and data filling processing on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

[0230] In the above-mentioned business request processing device, by receiving a business data acquisition request, after determining that the business data acquisition request passes the business validity check, the request parameters carried by the business data acquisition request are obtained, and the request parameters are subjected to field parsing processing to obtain the business fields matching the request parameters, thereby accurately obtaining different business scenarios associated with the business data acquisition request. Based on each business field, logic distribution processing and process arrangement processing are performed to determine the service nodes to be called and the dependent calling relationship between each service node, so that each service node can be called in sequence according to the dependent calling relationship, so as to quickly and accurately obtain the sub-business data fed back by each service node, improve the efficiency of sub-business data acquisition, and ensure the correlation between each sub-business data and the business scenario to which the current business data acquisition request belongs, so that each sub-business data obtained fits the actual business scenario. Further, according to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and the protocol adaptation processing and data filling processing are performed on each sub-business data according to the target protocol, and the target business data corresponding to the business data acquisition request is obtained, and the sub-business data corresponding to the different business fields are obtained by comprehensively considering different business fields, and further integrating and processing to obtain complete and accurate target business data.

[0231] In one embodiment, a business request processing device is provided, which also includes a protocol adaptation processing module, which is used to: obtain a business source attribute corresponding to a business data acquisition request; determine an access interface based on the business source attribute, and obtain a target protocol corresponding to the access interface; perform protocol adaptation processing on the business data acquisition request according to the target protocol to obtain a standard business data acquisition request under a general request structure.

[0232] In one embodiment, a business request processing device is provided, which also includes a validity verification module, which is used to: obtain business scenario information carried by a standard business data acquisition request, and preset standard attribute information matching the business source attribute; perform business validity verification on the business scenario information according to the preset standard attribute information to obtain a corresponding validity verification result.

[0233] In one embodiment, a service request processing device is provided, which also includes a hotspot service data caching module, which is used to: report the scenario request data under different service scenarios within a preset time period through an asynchronous queue; perform hotspot data verification processing based on the scenario request data reported by the asynchronous queue to determine the hotspot data request; and store the hotspot service data matching the hotspot data request in a preset hotspot cache.

[0234] In one embodiment, the hotspot business data cache module is also used to: call the inspection service node, read the scene request data from the asynchronous queue in sequence, and obtain the number of requests for each scene request data within a preset time window; obtain the request number threshold corresponding to the hotspot data maintenance window associated with the inspection service node, and compare the request number threshold with the request number; if the request number is greater than the request number threshold, the business data acquisition request corresponding to the current scene request data is determined as a hotspot data request.

[0235] In one embodiment, the target business data acquisition module is also used to: compare the business data acquisition request with each hotspot data request to generate a comparison result; if the business data acquisition request is determined to be a hotspot data request based on the comparison result, obtain the hotspot business data that matches the hotspot data request from the preset hotspot cache, and determine the hotspot business data as the target business data.

[0236] In one embodiment, the service node calling module is also used to: perform logic distribution processing based on each business field to determine the service node corresponding to each business field; obtain downstream dependency information corresponding to each business field, and determine the dependency relationship between each business field based on the downstream dependency information; perform flow orchestration processing based on the dependency relationship between each business field to determine the dependency calling relationship between each service node; the dependency calling relationship between service nodes includes serial calling, parallel calling and logical gateway calling.

[0237] In one embodiment, a service request processing device is provided, further comprising:

[0238] The backup data cache module is used to cache the target business data into the backup data cache; the business backup data feedback module is used to detect the status of the backup cache component. If the status of the backup cache component is determined to be in the running state, the business backup data is obtained based on the backup data cache, and the business backup data is fed back to the terminal where the business data acquisition request is triggered.

[0239] In one embodiment, a business request processing device is provided, which also includes an application development version verification module, which is used to: obtain the status of the grayscale traffic component, and if the grayscale traffic component status is in the running state, perform grayscale traffic distribution confirmation processing based on the business data acquisition request; if it is determined that the business data acquisition request belongs to the grayscale traffic interface, divide the target business data corresponding to the business data acquisition request into the grayscale traffic; perform application development version verification based on the grayscale traffic to obtain the corresponding version verification result; the version verification result is used to determine the development status of the application development version, and the development status includes development failure and development success.

[0240] Each module in the above-mentioned service request processing device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module above.

[0241] In one embodiment, Fig.10 As shown, a business request processing system is provided, which specifically includes a service access layer, a business verification layer, a component link layer, a data acquisition layer and a business optimization layer. Among them, the business request processing system call scenarios (or access methods) specifically include: applet access, h5 page access, internal service access (such as developers, testers and operators access, etc.), external service access (including the use of object points services and promotional activity pages, etc.). Among them, the service access layer mainly completes the adaptation and conversion of the protocol, and the grayscale control of the traffic. The access layer is designed to support requests from multiple different protocols, such as HTTP protocol, internal communication protocol protocol, etc. The business verification layer mainly completes the verification of the legitimacy of the requested business, and the component link layer is used to provide a bottom-up cache capability, hot data detection capability and process orchestration capability. Among them, the data acquisition layer is used to provide core service protection strategies and complete efficient service dependency management, while the business optimization layer is used to complete error degradation, cache write-back and failure event reporting. Specifically, refer to Fig.10 It can be seen that each component is used to implement the following functions:

[0242] P1, service access layer

[0243] Specifically, the service access layer is used to access different business parties (including mini-program access, h5 page access, internal service access, external service access, etc.), obtain business data acquisition requests triggered by different business parties, and determine the access interface based on the business source attributes of different business data acquisition requests. At the same time, it obtains the target protocol corresponding to the access interface, performs protocol adaptation processing on the business data acquisition request according to the target protocol, and obtains the standard business data acquisition request under the general request structure.

[0244] Among them, the service access layer is equipped with a traffic grayscale component to achieve grayscale control of traffic. Specifically, according to the iteration requirements of the application development version, a grayscale traffic component is set up to control the traffic switching rate during application development or service upgrades. For example, when a new functional module is launched and needs to be verified, in order to ensure the stability of the online service, part of the traffic requests need to be switched to the new development version with the new functional module, while the other part of the traffic requests remain in the previous stable version, that is, in order to effectively control the switching rate of traffic requests, a grayscale traffic component is introduced.

[0245] Reference Fig.10 It can be seen that the service access layer can also be used to obtain the basic product information required for business data acquisition requests, including product prices, product inventory, product discount configurations, and product purchase and gift configurations. Among them, the service access layer also provides product batch capabilities, which can batch copy the basic information of different products and view them at the same time, which can reduce the number of views and improve data access efficiency.

[0246] P2, business verification layer

[0247] Specifically, the business verification layer is used to perform business validity verification on business data acquisition requests, and also provides a variety of business scenarios, including general scenarios (product details information acquisition scenarios, shopping cart product information product acquisition scenarios, promotional product or discount product details acquisition scenarios, usage object points details acquisition scenarios, etc.), Feiliu activity scenarios (scenarios for batch acquisition of details information of a large number of products), and external scenarios (including access channels, i.e. cooperative business party scenarios, usage object points scenarios, promotion activity scenarios, and discount activity scenarios, etc.), etc., to perform scenario adaptation processing according to different business scenarios.

[0248] P3, component link layer

[0249] Specifically, the component link layer provides a backup cache capability, hot data reporting capability, and a process orchestration module. Among them, by setting a backup cache component and setting the backup cache component to a running state, the business backup data is obtained based on the backup data cache, and the business backup data is fed back to the terminal where the business data acquisition request is triggered.

[0250] Similarly, by reporting the scene request data under different business scenarios within a preset time period through an asynchronous queue, and setting an inspection service node to call the inspection service node based on the scene request data reported by the asynchronous queue, perform hotspot data verification processing, determine the hotspot data request, and store the hotspot business data matching the hotspot data request in a preset hotspot cache. Among them, by comparing the business data acquisition request with each hotspot data request, after determining that the business data acquisition request is a hotspot data request, obtain the hotspot business data matching the hotspot data request from the preset hotspot cache, and determine the hotspot business data as the target business data.

[0251] Among them, by performing field parsing processing on the request parameters of the business data acquisition request, the business fields matching the request parameters are obtained, and logical distribution processing is performed based on each business field to determine the service node corresponding to each business field. Further, by obtaining the downstream dependency information corresponding to each business field, and determining the dependency relationship between each business field according to the downstream dependency information, the flow orchestration processing is performed according to the dependency relationship between each business field, and the dependency calling relationship between each service node is determined, and then each service node can be called in turn according to the dependency calling relationship to obtain the sub-business data fed back by the service node.

[0252] P4, data acquisition layer

[0253] The data acquisition layer provides core service protection and service dependency management. The core service protection includes product postage acquisition service, product points acquisition service, product static data acquisition service, product dynamic data acquisition service, etc. Service dependency management is used to manage the dependency calls of product management coupon services, product reservation services, and product category services, so as to provide each service node with the required sub-business data, including product postage, product reservation information, product points, product coupons, and other sub-business data.

[0254] P5, Business Optimization Layer

[0255] Specifically, the business optimization layer is used to implement error downgrade, cache writeback, and failure event reporting. Among them, the downgrade optimization strategy is used to implement error downgrade, that is, when there are multiple requests, if some of the multiple requests have errors, the product structure can be filled with some of the data that has been obtained to avoid the user seeing an error page or a blank page.

[0256] Among them, by setting a fallback cache component, the target business data is cached in the fallback data cache. Among them, by detecting the fallback cache component status, if it is determined that the fallback cache component status is in the running state, the business fallback data is obtained based on the fallback data cache, and the business fallback data is fed back to the terminal where the business data acquisition request is triggered. Further, by judging whether the current business data acquisition request fails, if the request fails, a failure event is reported. If the request is successful, a normal response is made, and the determined target business data is fed back to the terminal.

[0257] In the above-mentioned business request processing system, multiple components such as service access layer, business verification layer, component link layer, data acquisition layer and business optimization layer are set up, and different components can be flexibly selected according to actual scenarios. For personalized requests in different business scenarios, the interdependence between underlying services is effectively solved by combining the process orchestration engine, making business expansion more scalable. For high-concurrency activity scenarios, by setting data backup and degradation strategies, as well as conducting inspections and data analysis, hot data is actively discovered and protected to avoid service breakdown caused by intensive access to hot data, thus ensuring the reliability and stability of product data acquisition and management capabilities in high-concurrency activity scenarios.

[0258] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.11 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as business data acquisition requests, request parameters carried by business data acquisition requests, business fields matching request parameters, service nodes to be called, dependent call relationships between service nodes, business source attributes corresponding to business data acquisition requests, target protocols, and target business data. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a business request processing method is implemented.

[0259] Those skilled in the art will understand that Fig.11The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0260] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.

[0261] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0262] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0263] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0264] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0265] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0266] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be construed as limiting the scope of the present application. It should be noted that, for a person of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for processing a business request, characterized in that: The method comprises: Receive a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, obtain the request parameters carried by the business data acquisition request; Performing field parsing processing on the request parameters to obtain business fields matching the request parameters, and performing logic distribution processing and process orchestration processing based on the business fields to determine the service nodes to be called and the dependent calling relationships between the service nodes; Calling each of the service nodes in sequence according to the dependency calling relationship to obtain the sub-service data fed back by the service node; According to the business source attribute corresponding to the business data acquisition request, the target protocol matching the business data acquisition request is determined, and protocol adaptation processing and data filling processing are performed on each of the sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

2. The method according to claim 1, characterized in that After receiving the business data acquisition request, it also includes: Obtaining the business source attribute corresponding to the business data acquisition request; Determine an access interface based on the service source attribute, and obtain a target protocol corresponding to the access interface; The service data acquisition request is subjected to protocol adaptation processing according to the target protocol to obtain a standard service data acquisition request under a general request structure.

3. The method according to claim 2, characterized in that The method of performing business validity verification on the standard business data acquisition request under the general request structure includes: Acquire the business scenario information carried in the standard business data acquisition request, and preset standard attribute information matching the business source attribute; The business scenario information is subjected to a business validity check according to the preset standard attribute information to obtain a corresponding validity check result.

4. The method according to claim 1, characterized in that: In the receiving of the service data acquisition request, if it is determined that the service data acquisition request passes the service validity check, before acquiring the request parameters carried by the service data acquisition request, the method further includes: Report the scenario request data under different business scenarios within the preset time period through the asynchronous queue; Based on the request data of each scenario reported by the asynchronous queue, hotspot data verification processing is performed to determine the hotspot data request; The hotspot service data matching the hotspot data request is stored in a preset hotspot cache.

5. The method according to claim 4, characterized in that The hotspot data verification process is performed based on the scenario request data reported by the asynchronous queue to determine the hotspot data request, including: Calling the inspection service node, reading the scene request data from the asynchronous queue in sequence, and obtaining the number of requests for each scene request data within a preset time window; Obtaining a request count threshold corresponding to a hotspot data maintenance window associated with the inspection service node, and comparing the request count threshold with the request count; If the number of requests is greater than the request number threshold, the business data acquisition request corresponding to the current scene request data is determined as a hot data request.

6. The method according to claim 4 or 5, characterized in that: When receiving a request for obtaining business data, it also includes: Compare the business data acquisition request with each of the hot data requests to generate a comparison result; If it is determined according to the comparison result that the service data acquisition request is a hot data request, hot service data matching the hot data request is acquired from the preset hot cache, and the hot service data is determined as the target service data.

7. The method according to any one of claims 1 to 5, characterized in that: Performing logic distribution processing and flow orchestration processing based on each of the business fields to determine the service nodes to be called and the dependent calling relationship between the service nodes, including: Performing logic distribution processing based on each of the business fields, and determining a service node corresponding to each of the business fields; Acquire downstream dependency information corresponding to each of the business fields, and determine the dependency relationship between the business fields according to the downstream dependency information; Stream orchestration is performed according to the dependency relationship between the business fields to determine the dependency calling relationship between the service nodes; the dependency calling relationship between the service nodes includes serial calling, parallel calling and logical gateway calling.

8. The method according to any one of claims 1 to 5, characterized in that: After obtaining the target business data corresponding to the business data acquisition request, the method further includes: caching the target business data in a backup data cache; The method further comprises: The state of the backup cache component is detected. If it is determined that the state of the backup cache component is in the running state, the business backup data is obtained based on the backup data cache, and the business backup data is fed back to the terminal where the business data acquisition request is triggered.

9. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Obtain the state of the grayscale traffic component, and if the grayscale traffic component state is in the running state, perform grayscale traffic distribution confirmation processing based on the business data acquisition request; If it is determined that the business data acquisition request belongs to the grayscale traffic interface, the target business data corresponding to the business data acquisition request is classified into the grayscale traffic; The application development version is verified based on the grayscale traffic to obtain a corresponding version verification result; the version verification result is used to determine the development status of the application development version, and the development status includes development failure and development success.

10. A service request processing device, characterized in that: The device comprises: A request parameter acquisition module is used to receive a business data acquisition request, and if it is determined that the business data acquisition request passes the business validity check, obtain the request parameters carried by the business data acquisition request; A field parsing module is used to perform field parsing processing on the request parameters, obtain business fields matching the request parameters, and perform logic distribution processing and process orchestration processing based on each of the business fields to determine the service nodes to be called and the dependent calling relationship between each of the service nodes; A service node calling module, used to call each of the service nodes in sequence according to the dependency calling relationship to obtain the sub-service data fed back by the service node; The target business data acquisition module is used to determine the target protocol that matches the business data acquisition request based on the business source attributes corresponding to the business data acquisition request, and perform protocol adaptation processing and data filling processing on each sub-business data according to the target protocol to obtain the target business data corresponding to the business data acquisition request.

11. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 9 are implemented.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

13. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

Images