Business request processing method and apparatus, computer device, and storage medium

Abstract

The application 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 a service validity check, acquiring a request parameter carried by the service data acquisition request, performing field analysis processing on the request parameter to obtain a service field, performing logical distribution processing and flow arrangement processing based on each service field, determining a service node to be called and a dependent calling relationship between each service node. Each service node is called in sequence according to the dependent calling relationship to acquire sub-service data fed back by the service node, a target protocol matched with the service data acquisition request is determined according to a service source attribute of the service data acquisition request, each sub-service data is subjected to protocol adaptation processing and data filling processing according to the target protocol, and target service data corresponding to the service data acquisition request is obtained. The method can obtain sub-service data and complete and accurate target service data that are suitable for an actual service scene.

Description

Technical Field

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

[0002] With the development of computer and network technologies, and the widespread application of various applications and platforms, e-commerce platforms, for example, have seen a surge in product data associated with various products as business processes continue to iterate. This includes basic product data, product review data, and product activity data (such as product promotions and marketing data). To provide high-quality services to platform users, it is necessary to manage this massive amount of product data in a timely manner and ensure the data acquisition capabilities in different scenarios (such as basic product data access scenarios, product review data viewing scenarios, and product activity promotion scenarios).

[0003] Traditionally, product data from different channels (including web access channels, application access channels, and desktop access channels) are typically accessed through a gateway, which then aggregates and manages product data dependencies.

[0004] However, traditional product data aggregation and management methods are too simplistic and lack scalability. As business continues to develop, the scenarios requiring the acquisition and application of product data will continue to grow, and different scenarios have different requirements for product data (such as needing to combine data from different business modules or fill in the values ​​of different fields in business data separately). Currently, gateways can only provide simple data acquisition and unified aggregation processing, which cannot distinguish between different business scenarios. As a result, the business data obtained in different business scenarios cannot match the actual application scenarios, and its accuracy still needs to be improved. Summary of the Invention

[0005] Therefore, 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 business data obtained and associated with different business scenarios, in response to the above-mentioned technical problems.

[0006] Firstly, this application provides a method for processing business requests. The method includes:

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

[0008] The request parameters are parsed to obtain the business fields that match the request parameters. Logical distribution and process orchestration are performed based on each business field to determine the service node to be called and the dependency call relationship between each service node.

[0009] According to the aforementioned dependency call relationship, each of the service nodes is called sequentially to obtain the sub-business data fed back by the service nodes;

[0010] Based on the business source attribute corresponding to the business data acquisition request, a target protocol matching the business data acquisition request is determined, and protocol adaptation 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] Secondly, this application also provides a business request processing apparatus. The apparatus includes:

[0012] The 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 verification, to acquire the request parameters carried by the business data acquisition request.

[0013] The field parsing module is used to parse the request parameters to obtain the business fields that match the request parameters, and to perform logical distribution and process orchestration based on each business field to determine the service node to be called and the dependency call relationship between each service node.

[0014] The service node invocation module is used to sequentially invoke each of the service nodes according to the dependency invocation relationship in order to obtain the sub-business data fed back by the service nodes;

[0015] The target business data acquisition module is used to determine the target protocol matching the business data acquisition request based on the business source attribute corresponding to the business data acquisition request, and to perform protocol adaptation processing and data filling processing 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.

[0016] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

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

[0018] The request parameters are parsed to obtain the business fields that match the request parameters. Logical distribution and process orchestration are performed based on each business field to determine the service node to be called and the dependency call relationship between each service node.

[0019] According to the aforementioned dependency call relationship, each of the service nodes is called sequentially to obtain the sub-business data fed back by the service nodes;

[0020] Based on the business source attribute corresponding to the business data acquisition request, a target protocol matching the business data acquisition request is determined, and protocol adaptation 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] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

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

[0023] The request parameters are parsed to obtain the business fields that match the request parameters. Logical distribution and process orchestration are performed based on each business field to determine the service node to be called and the dependency call relationship between each service node.

[0024] According to the aforementioned dependency call relationship, each of the service nodes is called sequentially to obtain the sub-business data fed back by the service nodes;

[0025] Based on the business source attribute corresponding to the business data acquisition request, a target protocol matching the business data acquisition request is determined, and protocol adaptation 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] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

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

[0028] The request parameters are parsed to obtain the business fields that match the request parameters. Logical distribution and process orchestration are performed based on each business field to determine the service node to be called and the dependency call relationship between each service node.

[0029] According to the aforementioned dependency call relationship, each of the service nodes is called sequentially to obtain the sub-business data fed back by the service nodes;

[0030] Based on the business source attribute corresponding to the business data acquisition request, a target protocol matching the business data acquisition request is determined, and protocol adaptation 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 aforementioned business request processing methods, apparatuses, computer devices, storage media, and computer program products, by receiving a business data acquisition request, determining that the business data acquisition request passes the business validity verification, obtaining the request parameters carried by the business data acquisition request, and performing field parsing processing on the request parameters 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 dependency call relationships between each service node. Thus, each service node can be called sequentially according to the dependency call relationships to quickly and accurately obtain the sub-business data fed back by each service node. This improves the efficiency of sub-business data acquisition while ensuring the relevance between each sub-business data and the business scenario to which the current business data acquisition request belongs, making the obtained sub-business data closely match the actual business scenario. Furthermore, based on 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 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 the sub-business data corresponding to different business fields, and further integrating and processing, complete and accurate target business data is obtained. Attached Figure Description

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

[0033] Figure 2 This is a flowchart illustrating a business request processing method in one embodiment;

[0034] Figure 3 This is a flowchart illustrating the business request processing method in another embodiment;

[0035] Figure 4This is a flowchart illustrating the business request processing method in yet another embodiment;

[0036] Figure 5 This is a flowchart illustrating the process of determining the service node to be invoked and the dependency invocation relationships between service nodes in one embodiment.

[0037] Figure 6 This is a schematic diagram illustrating the process of sequentially calling each service node according to the dependency call relationship in one embodiment;

[0038] Figure 7 This is a flowchart illustrating the business request processing method in another embodiment;

[0039] Figure 8 This is a schematic diagram of the complete process of a business request processing method in one embodiment;

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

[0041] Figure 10 This is a schematic diagram of the architecture of a business request processing system in one embodiment;

[0042] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] The business request processing method provided in this application embodiment can be applied to scenarios such as network media and intelligent transportation, and can be specifically applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on the cloud or other network servers. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, portable wearable devices, and aircraft. IoT devices can be smart speakers, smart in-vehicle devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be a standalone physical server, a server cluster consisting of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminal 102 and server 104 can be directly or indirectly connected via wired or wireless communication; this embodiment does not impose any limitations on this.

[0045] The server 104 receives a business data acquisition request triggered by the terminal 102. Upon confirming that the request passes the business validity check, the server obtains the request parameters carried in the request and performs field parsing to obtain the business fields matching the request parameters. Further, the server 104 performs logical distribution and process orchestration based on each business field to determine the service nodes to be called and the dependency relationships between them. It then sequentially calls each service node according to the dependency relationships to obtain the sub-business data returned by the service nodes. The server 104 can determine the target protocol matching the business data acquisition request based on the business source attribute corresponding to the request, and perform protocol adaptation and data filling processing on each sub-business data according to the target protocol to obtain the target business data corresponding to the request. After obtaining the target business data, the server 104 can return the target business data to the terminal 102 that triggered the request.

[0046] In one embodiment, such as Figure 2 As shown, a business request processing method is provided, which is applied to... Figure 1 Taking the server in the example, the following steps are included:

[0047] Step S202: Receive a business data acquisition request. If it is determined that the business data acquisition request passes the business validity verification, obtain the request parameters carried by the business data acquisition request.

[0048] Business data retrieval requests can be triggered through different access methods, including application (or application platform) access, mini-program access, and web page access (such as H5 pages, i.e., HTML5 pages). Different business data retrieval requests correspond to information retrieval in different business scenarios, and the information that can be retrieved specifically includes: product details, shopping cart information, product category information, product activity page information (including promotional activity pages, discount activity pages, etc.), and user points pages, etc.

[0049] Specifically, by receiving business data acquisition requests and parsing the business data requests, the system obtains the business scenario information carried by the business data requests and obtains preset standard attribute information that matches the business source attributes. Based on the preset standard attribute information that matches the business scenario information, the system performs business validity verification on the business scenario information.

[0050] Furthermore, once it is determined that the business data acquisition request passes the business validity verification, that is, the business data acquisition request is determined to be a valid data request, and the business party that triggered the business data acquisition request (such as a specific application, application platform, mini-program, and web page) is a valid business party, the request parameters carried by the business data acquisition request are obtained by parsing the parameters of the business data acquisition request.

[0051] Specifically, this involves acquiring different parameter information carried in the business data acquisition request, including business scenarios (such as product details, shopping cart information, product category information, product activity page information (including promotional activity pages, discount activity pages, etc.), and user points pages, etc.), and detailed information under specific business scenarios (such as product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details, etc., which need to be accessed and obtained in the product details acquisition scenario). This allows for parameter parsing of the business scenarios and detailed information under specific business scenarios to 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 points scenario, etc.) and scenario detail parameters (such as the current points of the user, used points, and points validity period, etc., in the user points scenario).

[0052] In one embodiment, before a specific business party (i.e., different business parties that trigger the business data acquisition request, such as specific applications, application platforms, mini-programs, and web pages) accesses the system, a business ID (i.e., APPid) and an authentication key (i.e., AppKey) are assigned to each accessing business party. The business ID and authentication key assigned to each business party can be understood as preset standard attribute information that matches the business source attributes of the corresponding business party.

[0053] Specifically, the business ID is encrypted using an encryption / decryption algorithm (such as symmetric encryption algorithm, asymmetric encryption algorithm, etc.). Then, the encrypted business ID is decrypted using the same encryption / decryption algorithm and authentication key. The decrypted business ID is then compared with the original business ID 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 assigning business IDs and authentication keys to specific business parties, upon receiving a business data acquisition request, the business scenario information carried in the request can be obtained. Based on the business scenario information, the corresponding business ID to be verified can be determined. Then, based on the preset standard attribute information matching the business source attribute, the business ID and authentication ID matching the business source attribute of the corresponding business party can be obtained. The business ID to be verified is then encrypted using an encryption / decryption algorithm (such as symmetric encryption algorithm, asymmetric encryption algorithm, etc.) to obtain the encrypted business ID to be verified. Finally, the encrypted business ID to be verified is decrypted using the same encryption / decryption algorithm and authentication key to determine whether the decrypted business ID to be verified is consistent with the business ID matching the business source attribute.

[0055] If it is determined whether the decrypted business ID to be verified is consistent with the business ID that matches the business source attribute, then the business data acquisition request is a valid data acquisition request, and the business party that triggered the business data acquisition request, such as a specific application, application platform, mini-program, or web page, is a valid business party.

[0056] Step S204: Perform field parsing processing on the request parameters to obtain the business fields that match the request parameters, and perform logical distribution processing and process orchestration processing based on each business field to determine the service nodes to be called and the dependency call relationships between each service node.

[0057] The request parameters specifically include business scenario parameters and scenario detail parameters. Business scenario parameters include product detail scenarios, shopping cart scenarios, product category scenarios, product promotion scenarios, product discount scenarios, and user points scenarios. Scenario detail parameters include: product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details in the product detail 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; discounted product name, discount level, product price, and product inventory in the product discount scenario; and user points current points, used points, and points validity period in the user points scenario.

[0058] Specifically, by parsing the request parameters, such as business scenario parameters and scenario detail parameters, the business fields that match the request parameters are obtained. Specifically, the actual business scenario fields are obtained (e.g., product detail information retrieval scenario, shopping cart product information retrieval scenario, promotional or discounted product detail retrieval scenario, object points usage detail retrieval scenario, etc.) and the scenario detail fields corresponding to the business scenario fields (e.g., in the product detail information retrieval scenario, it is necessary to obtain product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details).

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

[0060] The dependency relationships between service nodes specifically include serial calls, parallel calls, and logical gateway calls. Specifically, service nodes with serial call dependencies are those that need to be called sequentially according to the order of their calls, while those with parallel call dependencies are those that need to be called simultaneously. Service nodes with logical gateway call dependencies determine which target service node to select when specific conditions are met, through the execution of judgment logic. For example, when a user needs to redeem a product using points, it needs to determine whether the user's current points meet the requirements for redemption. If it is determined that the user's current points meet the requirements, then the target service node with points redemption functionality is called.

[0061] For example, obtaining product details first requires acquiring basic product information (product price, product inventory, buy-one-get-one-free offers, discounts, etc.). This involves calling service nodes with sequential call dependencies, passing the basic product information sequentially to the pricing service node. The pricing service then processes the product's basic information for pricing and returns a dynamic promotional price. After acquiring the basic product information, service nodes with parallel call dependencies can be called to retrieve product points (points earned after purchasing the product), reservation information, and shipping costs in parallel. Similarly, if a user needs to redeem a product using points, service nodes with logical gateway call dependencies need to be called to determine if the user's current points meet the redemption requirements. If the user's current points meet the requirements, the target service node with points redemption functionality is then called.

[0062] Step S206: Call each service node sequentially according to the dependency call relationship to obtain the sub-business data fed back by the service node.

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

[0064] For example, in a scenario where product details are retrieved, the process first involves calling service nodes with sequential dependency relationships to obtain basic product information (product price, product inventory, buy-one-get-one-free offers, discounts, etc.). This basic product information serves as sub-business data returned by the service nodes involved in the sequential calls. After obtaining the basic product information, it is sequentially passed to the pricing service node. The pricing service then performs product pricing processing on the basic information, returning a dynamic promotional price. This dynamic promotional price can also be used as sub-business data returned by the pricing service node.

[0065] After obtaining the basic information of the product, the system can obtain data such as product points (i.e., points obtained after purchasing the product), product reservation information, and product postage by calling service nodes with dependent call relationships that exist in parallel. The obtained product points, product reservation information, and product postage data are then used as sub-business data fed back by the service nodes that are called in parallel.

[0066] Similarly, if a user needs to redeem a product using points, a service node with a logical gateway call dependency relationship needs to be invoked to determine if the user's current points meet the requirements for product redemption. If it is determined that the user's current points meet the requirements, a target service node with points redemption functionality is further invoked. In the case of the user redeeming points, the user's total points are deducted according to the points required for product redemption, and the product is redeemed. The points required for product redemption, the user's total points, and the product redemption status reported by the target service node with points redemption functionality are all sub-business data that the target service node can report.

[0067] Step S208: Based on the business source attribute corresponding to the business data acquisition request, determine the target protocol that matches 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] Business data acquisition requests can be triggered through different access methods, corresponding to different business source attributes. These business source attributes can be understood as specific business parties, including: specific applications (such as shopping applications), application platforms (such as e-commerce platforms), mini-programs (such as shopping mini-programs loaded within social applications), and web pages (such as shopping website pages), etc. It is understandable that since different business parties typically support different protocols—that is, different business source attributes corresponding to business data acquisition requests employ different protocols—it is necessary to perform protocol adaptation and data population processing on the currently obtained sub-business data. This is to convert the sub-business data returned by different service nodes into target protocol formats that can be received or supported by the different business parties triggering the business data acquisition requests.

[0069] Specifically, by obtaining the business source attributes corresponding to the business data acquisition request, the business parties that triggered the business data acquisition request are identified, and the target protocols actually supported by each business party are obtained, thus determining the target protocols that match the business data acquisition request.

[0070] Furthermore, according to the target protocol, the sub-business data fed back by each service node undergoes protocol adaptation processing. This involves converting the sub-business data into the target protocol format supported by the respective business parties that triggered the business data acquisition request. The converted sub-business data then undergoes data population and data assembly processing to obtain complete target business data. By employing protocol adaptation and data population processing, the relevant business parties can easily receive and recognize the complete target business data in the target protocol format.

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

[0072] In this context, the fallback data cache can be understood as a cache that stores fallback data that is fed back to each business unit when one or more service nodes cannot be accessed normally. Specifically, for example, if the downstream pricing service is unavailable, all real-time requests will be unable to obtain product prices for a short period of time. If the current pricing service has not yet been restored, the previously stored fallback cache data should be used as the normal data to return, waiting for the downstream pricing service to be restored.

[0073] Furthermore, upon receiving a request to obtain business data, the process also includes: detecting the status of the fallback cache component; if the fallback cache component is determined to be in a running state, obtaining the fallback business data based on the fallback data cache, and feeding back the fallback business data to the terminal that triggered the request to obtain business data.

[0074] Specifically, by detecting the status of the fallback cache component, i.e. whether the fallback cache component switch is on, if it is determined that the fallback cache component is in a running state, i.e., the fallback cache component switch is on, the business fallback data is directly obtained based on the fallback data cache. That is, it is checked whether there is available data in the fallback cache, and the available business fallback data is obtained from the fallback data cache. The business fallback data is used as the target business data corresponding to the current business data retrieval request, and is fed back to the terminal that triggered the business data retrieval request for the user to view.

[0075] Understandably, if downstream services are unavailable, such as when even basic product information (including product name, product background image, product price, etc.) cannot be obtained, checking the fallback cache for available data and using the obtained available data as the target business data corresponding to the current business data retrieval request can prevent users from seeing error pages or blank pages, thus reducing the occurrence of impaired user experience.

[0076] In the aforementioned business request processing method, a business data retrieval request is received. After confirming the request passes business validity verification, the request parameters are obtained. These parameters are then parsed to identify matching business fields, thus accurately identifying different business scenarios associated with the request. Logical distribution and process orchestration are performed based on these business fields to determine the service nodes to be invoked and the dependency relationships between them. Service nodes are then invoked sequentially according to these dependency relationships to quickly and accurately retrieve sub-business data from each node. This improves the efficiency of sub-business data retrieval while ensuring the relevance between each sub-business data and the business scenario to which the current request belongs, ensuring the obtained sub-business data aligns with the actual business scenario. Furthermore, based on the business source attribute corresponding to the request, a target protocol is determined. Protocol adaptation and data filling are then performed on each sub-business data according to the target protocol to obtain the target business data corresponding to the 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.

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

[0078] Step S302: Receive a business data acquisition request and obtain the business source attribute corresponding to the business data acquisition request.

[0079] Specifically, by receiving business data acquisition requests and parsing them, the business source attribute corresponding to the business data acquisition request is obtained, that is, the business party that triggered the business data acquisition request is identified, including specific applications (such as shopping applications), application platforms (such as e-commerce platforms), mini-programs (such as shopping mini-programs loaded in social applications), and web pages (such as shopping website pages, etc.).

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

[0081] When connecting 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. That is, each access interface can support access from different business parties 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 an HTTP protocol interface (i.e., Hypertext Transfer Protocol) for mini programs, an internal protocol interface and a JCE protocol interface (i.e., a binary communication and data transmission protocol that supports dynamic field addition, automatic code generation, and cross-platform communication) for internal services (such as developers, testers, and operations personnel), and an internal protocol interface for accessing front-end H5 pages (i.e., the internal protocol interface for accessing front-end H5 pages). Therefore, it is necessary to determine the target protocol set for different business source attributes based on the different business source attributes, so as to perform protocol adaptation and conversion processing according to the target protocol.

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

[0084] Specifically, the business data retrieval request undergoes protocol adaptation processing based on the target protocol. This involves converting the business data retrieval request into a target protocol format supported by the access interface, thereby obtaining a standard business data retrieval request under the general request structure. For example, for a business data retrieval request triggered by a mini-program, the access interface provides the HTTP protocol for mini-programs. Therefore, it's necessary to determine whether the business data retrieval request triggered by the mini-program uses the HTTP protocol for transmission. If it does, no protocol adaptation processing is needed; otherwise, protocol adaptation processing is required based on the HTTP protocol, converting the business data retrieval request into an HTTP protocol format supported by the access interface to obtain a standard business data retrieval request under the general request structure.

[0085] Step S308: Obtain standard business data. The business scenario information carried in the acquisition request, as well as the preset standard attribute information that matches the business source attribute.

[0086] Specifically, the system obtains the business source attribute corresponding to the business data retrieval request, and acquires the preset standard attribute information for the business source attribute, i.e., the business party's pre-set standard attribute information, including the business ID and authentication key assigned to each business party. Specifically, the business ID can be encrypted using an encryption / decryption algorithm (such as symmetric encryption algorithm, asymmetric encryption algorithm, etc.), and then decrypted using the same encryption / decryption algorithm and authentication key. The system then determines whether the decrypted business ID matches the original business ID to ascertain whether the business party is a valid business party, i.e., whether the business data retrieval request triggered by the business party is a valid data retrieval request.

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

[0088] Specifically, upon receiving a business data retrieval request, the system acquires the business scenario information carried in the request and determines the corresponding business ID to be verified based on the business scenario information. Then, based on the preset standard attribute information matching the business source attribute, the system acquires the business ID and authentication ID that match the business source attribute of the corresponding business party. The system then encrypts the business ID to be verified using an encryption / decryption algorithm (such as symmetric encryption algorithm, asymmetric encryption algorithm, etc.) to obtain the encrypted business ID to be verified. Finally, the system decrypts the encrypted business ID to be verified using the same encryption / 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] If it is determined whether the decrypted business ID to be verified is consistent with the business ID that matches the business source attribute, then the business data acquisition request is a valid data acquisition request, and the business party that triggered the business data acquisition request, such as a specific application, application platform, mini-program, or web page, is a valid business party.

[0090] In the aforementioned business request processing method, a business data acquisition request is received, the corresponding business source attribute is obtained, and the access interface is determined based on the business source attribute. The target protocol corresponding to the access interface is then obtained. Further, the business data acquisition request undergoes protocol adaptation processing according to the target protocol to obtain a standard business data acquisition request under a general request structure. The business scenario information carried by the standard business data acquisition request, as well as preset standard attribute information matching the business source attribute, are then obtained. The business scenario information is then validated based on the preset standard attribute information to obtain the corresponding validity validation result, thus achieving the desired validation.

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

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

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

[0094] Business scenarios include product detail scenarios, shopping cart scenarios, product category scenarios, product promotion scenarios, product discount scenarios, and user points scenarios. The scenario request data for different business scenarios can be understood as the specific request data (i.e., specific business data) that needs to be returned in accordance with the business data acquisition request. Specifically, these include: product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and specific product content in the product detail 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; discounted product name, discount level, product price, and product inventory in the product discount scenario; and current user points, used points, and points validity period in the user points scenario.

[0095] Specifically, the system acquires scenario request data for different business scenarios within a preset time period, such as acquiring scenario request data for different business scenarios within a day or a week. This data is then stored sequentially in an asynchronous queue, and the asynchronous queue is used to report the scenario request data. The preset time period can be adjusted and set according to actual business needs and is not limited to a specific value.

[0096] The asynchronous queue approach can be understood as storing short-term, high-concurrency scenario request data in message queues asynchronously, without waiting for the previous scenario request data to finish being stored before storing the next. This allows for rapid retrieval, storage, and reporting of scenario request data. In scenarios such as product promotions, the proper use of message queues can effectively mitigate the service impact caused by a surge in access, data retrieval, and order placement operations at the beginning of the promotion.

[0097] Step S404: Based on the scenario request data reported by the asynchronous queue, perform hot data verification processing to determine the hot data requests.

[0098] Specifically, by invoking the inspection service node, scenario request data is sequentially read from the asynchronous queue, and the number of requests for each scenario request data within a preset time window is obtained. The inspection service node is used for hotspot data inspection and maintenance; that is, it identifies hotspot data from the scenario request data and pre-caches this hotspot data so that it can be directly fed back to the terminal later. The number of requests for scenario request data within the preset time window can be understood as the number of data acquisition requests for a specific business scenario within a time window.

[0099] Furthermore, the request count threshold corresponding to the hotspot data maintenance window associated with the inspection service node is obtained, and the request count threshold is compared with the number of requests. If the number of requests exceeds the request count threshold, the business data acquisition request corresponding to the current scenario request data is identified as a hotspot data request.

[0100] 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 includes information such as product number, request source, and activity entry point), that is, the time point of the business data acquisition request. By statistically analyzing the time information of all requests, a time window is constructed, which is used to count the number of requests within a certain period of time (such as 1 day, 3 days, 5 days, etc.). Conversely, if the number of requests is less than the request count threshold, the count in the hotspot data maintenance window is updated. For example, if the number of requests for a certain business scenario is counted as 20 in the hotspot data maintenance window, and the request count threshold is set to 50, it indicates that the number of requests for that business scenario has not reached the corresponding request count threshold in the hotspot data maintenance window. Therefore, the number of requests for that business scenario in the hotspot data maintenance window is updated, for example, from 20 to 21.

[0101] Step S406: Store the hot business data that matches the hot data request into the preset hot cache.

[0102] Specifically, a preset hotspot cache is set up in advance for hotspot business data to store hotspot business data that matches the identified hotspot data requests.

[0103] Specifically, hot business data can include scenario details under different business scenarios, such as product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin and specific product content in the product details scenario, as well as promotional product name, product price, product discount and product inventory in the product promotion scenario, and discounted product name, discount level, product price and product inventory in the product discount scenario.

[0104] Step S408: Compare the business data acquisition request with each hot data request to generate a comparison result.

[0105] Specifically, by acquiring business scenario information corresponding to business data acquisition requests and hot business scenarios (such as product promotion scenarios, product discount scenarios, etc.) corresponding to hot data requests, the business scenario information corresponding to business data acquisition requests is compared with the hot business scenarios corresponding to hot data requests to determine whether the business scenario information corresponding to business data acquisition requests belongs to hot business scenarios, thereby generating the corresponding comparison results.

[0106] The comparison results specifically include whether the business data retrieval request belongs to the category of hot data requests and whether the business data retrieval request does not belong to the category of hot data requests.

[0107] Step S410: If the business data acquisition request is determined to be a hot data request based on the comparison result, the hot business data matching the hot data request is obtained from the preset hot data cache, and the hot business data is determined as the target business data.

[0108] Specifically, if the comparison results determine that the business data retrieval request is a hot data request, a search is performed based on the preset hot data cache to identify the hot business data that matches the hot data request. This hot business data is then identified as the target business data and directly fed back to the terminal that triggered the hot data request. This allows the product service to return data quickly, 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 caused by intensive access to hot data.

[0109] In the aforementioned business request processing method, scenario request data under different business scenarios within a preset time period is reported via an asynchronous queue. Based on the scenario request data reported by the asynchronous queue, hot data verification is performed to identify hot data requests. Hot business data matching these requests is then stored in a preset hot data cache. Furthermore, by storing the hot business data matching the requests in the preset hot data cache, and comparing the business data retrieval request with each hot data request, if the business data retrieval request is determined to be a hot data request, the hot business data matching the request is retrieved from the preset hot data cache. This identifies the hot business data as the target business data, enabling real-time detection and retrieval of hot data during the service process. The hot data is also protected and pre-cached. In high-concurrency scenarios with concentrated access to hot data, the pre-cached hot data can be directly fed back to the terminal that triggered the business data retrieval request, preventing service breakdown due to concentrated access to hot data and improving data retrieval efficiency.

[0110] In one embodiment, such as Figure 5 As shown, the steps for determining the service nodes to be invoked and the dependency relationships between them, namely, the steps for logical distribution and process orchestration based on each business field to determine the service nodes to be invoked and the dependency relationships between them, specifically include the following steps:

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

[0112] This involves parsing the request parameters, such as business scenario parameters and scenario detail parameters, to obtain the business fields that match the request parameters. Specifically, this includes the actual business scenario fields (such as product detail information retrieval scenario, shopping cart product information retrieval scenario, promotional or discounted product detail retrieval scenario, and object points usage detail retrieval scenario, etc.) as well as the scenario detail fields corresponding to the business scenario fields (such as, in the product detail information retrieval scenario, specifically, it is necessary to obtain product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details).

[0113] Specifically, logical distribution processing is performed based on various business fields to determine the service nodes to be called. For example, based on business scenario fields such as product detail information acquisition scenario, shopping cart product information acquisition scenario, promotional or discounted product detail acquisition scenario, and user points acquisition scenario, logical distribution processing is performed. In the product detail information acquisition scenario, the service nodes to be called are determined based on detail information acquisition fields such as product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details. For example, the service nodes corresponding to the product detail information acquisition scenario and the service nodes corresponding to the promotional product detail acquisition scenario are determined.

[0114] For example, obtaining product details first requires acquiring basic product information (product price, product inventory, buy-one-get-one-free offers, discounts, etc.). This involves calling service nodes with sequential dependencies, passing the basic product information sequentially to the pricing service node. The pricing service then processes the product's pricing based on this information, returning a dynamic promotional price. After acquiring the basic product information, it's possible to concurrently retrieve data such as product points (points earned after purchasing the product), reservation information, and shipping costs by calling service nodes with parallel dependencies.

[0115] Similarly, if an object needs to redeem a product using points, it needs to call a service node with a logical gateway call dependency relationship to determine whether the object's current points meet the points required for product redemption. If it is determined that the object's current points meet the points required for product redemption, then the target service node with points redemption function is further called.

[0116] Step S504: Obtain the downstream dependency information corresponding to each business field, and determine the dependency relationship between each business field based on the downstream dependency information.

[0117] Each service node is responsible for performing different data acquisition, data processing, and data feedback operations. Each service node is configured with specific operations or tasks to perform, such as acquiring product points data, acquiring product discount levels, acquiring product buy-one-get-one-free configurations, and acquiring product minimum spend reduction configurations. Depending on the task to be performed, each service node is injected with the necessary downstream dependency information to ensure that it can correctly call downstream service nodes.

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

[0119] Step S506: Perform stream orchestration processing based on the dependencies between various business fields to determine the dependency call relationships between various service nodes.

[0120] Specifically, based on the dependencies between various business fields, such as fields related to the product details information acquisition scenario, such as product price, product inventory, product buy-one-get-one-free configuration, full-reduction configuration, product origin, and product details, the process is orchestrated to determine the service nodes used to acquire product price, product inventory, product buy-one-get-one-free configuration, full-reduction configuration, product origin, and product details, and the dependency call relationships between them and the service nodes corresponding to the fields in the product details information acquisition scenario.

[0121] For example, based on the service node corresponding to the scenario field of the product details information, determine the service nodes with dependent call relationships, obtain the basic information of the product (including product price, product inventory, product buy-one-get-one-free configuration, and full-reduction configuration, etc.), and call the service nodes with dependent call relationships that have serial calls with the service node that obtains the product details information. The basic information of the product is passed to the pricing service node in sequence, and the pricing service is called to perform product pricing processing on the basic information of the product, and return a dynamic activity price.

[0122] In one embodiment, such as Figure 6 As shown, this provides a schematic diagram of a process for sequentially invoking each service node according to the dependency invocation relationship. Figure 6It can be seen that there is a serial call dependency relationship between service node1 (such as the service node corresponding to the product details information acquisition scenario field), service node2 (such as the service node used to obtain the product price), and service node3 (such as the service node used to obtain the product discount configuration). That is, service node1, service node2, and service node3 form a serial task (i.e., ChainNode). Service node4 is an intermediate service node used to further analyze and process the output results of the serial task (such as to further analyze and price according to the product price and the product discount configuration to obtain the product price corresponding to the current product).

[0123] Furthermore, referring to Figure 6 As can be seen, service node5 and service node6 together form a logical gateway task (i.e., GatewayNode). By executing judgment logic, it determines the target service node to select when specific conditions are met (e.g., selecting service node5 if the conditions are met, and selecting service node6 if the conditions are not met). Specifically, for example, when a user needs to redeem a product using points, it needs to determine if the user's current points meet the requirements for redemption. If it is determined that the user's current points meet the requirements, then the target service node node5, which has the points redemption function, is invoked.

[0124] In this process, after calling the target service node node5, which has the function of redeeming points, it further calls the service nodes node7 and node8, which have a parallel calling relationship. That is, the service nodes node7 and node8 form a parallel task (i.e., ParallelNode). For example, through the service nodes node7 and node8, data such as product points, total points of the user object, and postage of the product can be obtained in parallel.

[0125] For example, the dependency relationships between service nodes and the call flow of each service node are represented in the following form:

[0126] Serial task (product static, product dynamic) -> Logical gateway task (Is the product removed from the shelves?) -> If not removed from the shelves, then parallel task (product points, product postage, product coupons, product reservation information) -> If removed from the shelves, then directly use the product dynamic data and static data to construct the basic product data and return it.

[0127] The serial tasks include service node A, which acquires static product data (such as product name and background image), and service node B, which acquires dynamic product data (such as product price, inventory, discounts, and buy-one-get-one-free offers). The logic gateway task is set to determine whether the product is no longer available. If the product is not no longer available, the target service node B is called. The parallel tasks include service nodes that acquire product points, shipping costs, coupons, and reservation information. Each service node can be called simultaneously to acquire these data for the product that is still available. If the product is no longer available, service node C is called to construct basic product data from the static and dynamic data and return it.

[0128] In this embodiment, logical distribution processing is performed based on each business field to determine the service node corresponding to each business field, obtain the downstream dependency information corresponding to each business field, determine the dependency relationship between each business field based on the downstream dependency information, and perform stream orchestration processing based on the dependency relationship between each business field to determine the dependency call relationship between each service node. This allows for accurate and comprehensive calling of each service node in the future, avoiding the omission of sub-business data and improving the efficiency and accuracy of sub-business data acquisition.

[0129] In one embodiment, a business request processing method is provided, specifically including: obtaining the status of a grayscale traffic component; if the grayscale traffic component status is running, performing grayscale traffic distribution confirmation processing based on the business data acquisition request; if it is determined that the business data acquisition request belongs to a grayscale traffic interface, allocating the target business data corresponding to the business data acquisition request to grayscale traffic; performing application development version verification based on grayscale traffic, and obtaining 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.

[0130] Based on the application development version iteration requirements, a canary traffic component is set up to control the traffic switching rate during application development or service upgrades. For example, when a new feature module is launched and needs to be verified, in order to ensure the stability of the online service, some traffic requests need to be switched to the new development version with the new feature module, while other traffic requests remain on the previous stable version. That is, the canary traffic component is introduced to effectively control the switching rate of traffic requests.

[0131] Specifically, by obtaining the status of the grayscale traffic component, i.e., the on / off status of the grayscale traffic switch, if the grayscale traffic component is in the running state, i.e. the grayscale traffic switch is in the on state, then 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 gray traffic interface, the target business data corresponding to the business data acquisition request will be divided into gray traffic, and the application development version will be verified based on the gray traffic to obtain the version verification result used to determine the development status of the application development version. The development status of the development version specifically includes development failure and development success.

[0133] In one embodiment, if it is determined that a business data retrieval request belongs to an online traffic interface, then the target business data corresponding to the business data retrieval request is allocated to online traffic. Furthermore, online traffic can be used to check and verify the current version of the application or service to determine if the current version is faulty, enabling real-time maintenance and handling in case of a fault.

[0134] In the above business request processing method, the status of the gray-scale traffic component is obtained. If the gray-scale traffic component is in a running state, gray-scale traffic distribution confirmation processing is performed based on the business data acquisition request. The target business data corresponding to the business data acquisition request belonging to the gray-scale traffic interface is divided into gray-scale traffic, and application development version verification is performed based on the gray-scale traffic to obtain the corresponding version verification result. The development status of the application development version is determined based on the version verification result, including development failure and development success. This realizes the gray-scale release of application development or service development, which completes the development of new service or application versions while ensuring the stability of the current application or service, improving the efficiency of application or service development, and without interrupting the currently provided application functions or service functions.

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

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

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

[0138] Specifically, the system acquires scenario request data for different business scenarios within a preset time period, such as acquiring scenario request data for different business scenarios within a day or a week. This data is then stored sequentially in an asynchronous queue, and the asynchronous queue is used to report the scenario request data. The preset time period can be adjusted and set according to actual business needs and is not limited to a specific value.

[0139] Furthermore, using asynchronous queues can be understood as storing scenario request data generated by high concurrency in a short period of time in message queues asynchronously, without waiting for the previous scenario request data to finish being stored before storing the next. This allows for rapid retrieval, storage, and reporting of scenario request data. In scenarios such as product promotion activities, the proper use of message queues can effectively mitigate the service impact caused by the large influx of access, data retrieval, and order placement operations at the beginning of the promotion.

[0140] Step S702: Invoke the inspection service node to read scene request data sequentially from the asynchronous queue, and obtain the number of requests for each scene request data within a preset time window.

[0141] The inspection service node is used for hotspot data inspection and maintenance. Specifically, it identifies hotspot data from scenario request data and pre-caches this data so it can be directly fed back to the terminal later. The number of requests for scenario request data within a preset time window can be understood as the number of data acquisition requests for a specific business scenario within a given time window.

[0142] Step S703: Obtain the 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, the request count threshold corresponding to the hotspot data maintenance window associated with the inspection service node is obtained, and the request count threshold and the request count are compared.

[0144] 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 includes information such as product number, request source and activity entry), that is, the time point of the business data acquisition request. By statistically analyzing the time information of all requests, a time window is constructed, which is used to count the number of requests within a certain period of time (such as within 1 day, 3 days, 5 days, etc.).

[0145] Step S704: If the number of requests exceeds the request count threshold, the business data acquisition request corresponding to the current scenario request data is identified as a hot data request, and the hot business data matching the hot data request is stored in the preset hot cache.

[0146] Specifically, if the number of requests exceeds a threshold, the business data retrieval request corresponding to the current scenario's request data will be identified as a hot data request. A pre-set hot data cache is configured to store hot data that matches the identified hot data requests. Therefore, when a business data retrieval request corresponding to the current scenario's request data is determined to be a hot data request, the hot data matching the hot data request will be stored in the pre-set hot data cache.

[0147] Specifically, hot business data can include scenario details under different business scenarios, such as product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin and specific product content in the product details scenario, as well as promotional product name, product price, product discount and product inventory in the product promotion scenario, and discounted product name, discount level, product price and product inventory in the product discount scenario.

[0148] In one embodiment, if the number of requests is less than the request count threshold, the count in the hot data maintenance window is updated. For example, if the number of requests for a certain business scenario is 20 in the hot data maintenance window, and the request count threshold is set to 50, it indicates that the number of requests for that business scenario has not reached the request count threshold corresponding to the hot data maintenance window. Therefore, the number of requests for that business scenario in the hot data maintenance window is updated, for example, from 20 to 21.

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

[0150] Specifically, by acquiring business scenario information corresponding to business data acquisition requests and hot business scenarios (such as product promotion scenarios, product discount scenarios, etc.) corresponding to hot data requests, the business scenario information corresponding to business data acquisition requests is compared with the hot business scenarios corresponding to hot data requests to determine whether the business scenario information corresponding to business data acquisition requests belongs to hot business scenarios, thereby generating the corresponding comparison results.

[0151] The comparison results specifically include whether the business data retrieval request belongs to the category of hot data requests and whether the business data retrieval request does not belong to the category of hot data requests.

[0152] Step S706: If the business data acquisition request is determined to be a hot data request based on the comparison result, the hot business data matching the hot data request is obtained from the preset hot data cache, and the hot business data is determined as the target business data.

[0153] Specifically, if the comparison results determine that the business data retrieval request is a hot data request, a search is performed based on the preset hot data cache to identify the hot business data that matches the hot data request. This hot business data is then identified as the target business data and directly fed back to the terminal that triggered the hot data request. This allows the product service to return data quickly, 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 caused by intensive access to hot data.

[0154] Step S707: If the comparison result determines that the business data acquisition request is not a hot data request, 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 the comparison results determine that the business data acquisition request is not a hot data request, the business data acquisition request is parsed to obtain the business source attribute corresponding to the business data acquisition request, that is, to determine the business party that triggered the business data acquisition request, including specific applications (such as shopping applications), application platforms (such as e-commerce platforms), mini-programs (such as shopping mini-programs loaded in social applications), and web pages (such as shopping website pages, etc.).

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

[0157] Specifically, the access interface provides an HTTP protocol interface (i.e., Hypertext Transfer Protocol) for mini programs, an internal protocol interface and a JCE protocol interface (i.e., a binary communication and data transmission protocol that supports dynamic field addition, automatic code generation, and cross-platform communication) for internal services (such as developers, testers, and operations personnel), and an internal protocol interface for accessing front-end H5 pages (i.e., the internal protocol interface for accessing front-end H5 pages). Therefore, it is necessary to determine the target protocol set for different business source attributes based on the different business source attributes, so as to perform protocol adaptation and conversion processing according to the target protocol.

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

[0159] Specifically, the business data retrieval request undergoes protocol adaptation processing based on the target protocol. This involves converting the business data retrieval request into a target protocol format supported by the access interface, thereby obtaining a standard business data retrieval request under the general request structure. For example, for a business data retrieval request triggered by a mini-program, the access interface provides the HTTP protocol for mini-programs. Therefore, it's necessary to determine whether the business data retrieval request triggered by the mini-program uses the HTTP protocol for transmission. If it does, no protocol adaptation processing is needed; otherwise, protocol adaptation processing is required based on the HTTP protocol, converting the business data retrieval request into an HTTP protocol format supported by the access interface to obtain a standard business data retrieval request under the general request structure.

[0160] Step S709: Obtain standard business data. The business scenario information carried in the acquisition request, as well as the preset standard attribute information that matches the business source attribute.

[0161] Specifically, the system obtains the business source attribute corresponding to the business data retrieval request, and acquires the preset standard attribute information for the business source attribute, i.e., the business party's pre-set standard attribute information, including the business ID and authentication key assigned to each business party. Specifically, the business ID can be encrypted using an encryption / decryption algorithm (such as symmetric encryption algorithm, asymmetric encryption algorithm, etc.), and then decrypted using the same encryption / decryption algorithm and authentication key. The system then determines whether the decrypted business ID matches the original business ID to ascertain whether the business party is a valid business party, i.e., whether the business data retrieval request triggered by the business party is a valid data retrieval request.

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

[0163] Specifically, upon receiving a business data retrieval request, the system acquires the business scenario information carried in the request and determines the corresponding business ID to be verified based on the business scenario information. Then, based on the preset standard attribute information matching the business source attribute, the system acquires the business ID and authentication ID that match the business source attribute of the corresponding business party. The system then encrypts the business ID to be verified using an encryption / decryption algorithm (such as symmetric encryption algorithm, asymmetric encryption algorithm, etc.) to obtain the encrypted business ID to be verified. Finally, the system decrypts the encrypted business ID to be verified using the same encryption / 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] If it is determined whether the decrypted business ID to be verified is consistent with the business ID that matches the business source attribute, then the business data acquisition request is a valid data acquisition request, and the business party that triggered the business data acquisition request, such as a specific application, application platform, mini-program, or web page, is a valid business party.

[0165] Step S711: If it is determined that the business data acquisition request passes the business validity verification, obtain the request parameters carried by the business data acquisition request.

[0166] Specifically, if the business data retrieval request is determined to pass the business validity verification, that is, if the business data retrieval request is determined to be a valid data request, and the business party that triggered the business data retrieval request (such as a specific application, application platform, mini-program, or web page) is a valid business party, the request parameters carried by the business data retrieval request are obtained by parsing the parameters of the business data retrieval request.

[0167] Specifically, this involves acquiring different parameter information carried in the business data acquisition request, including business scenarios (such as product details, shopping cart information, product category information, product activity page information (including promotional activity pages, discount activity pages, etc.), and user points pages, etc.), and detailed information under specific business scenarios (such as product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details, etc., which need to be accessed and obtained in the product details acquisition scenario). This allows for parameter parsing of the business scenarios and detailed information under specific business scenarios to 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 points scenario, etc.) and scenario detail parameters (such as the current points of the user, used points, and points validity period, etc., in the user points scenario).

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

[0169] The request parameters specifically include business scenario parameters and scenario detail parameters. Business scenario parameters include product detail scenarios, shopping cart scenarios, product category scenarios, product promotion scenarios, product discount scenarios, and user points scenarios. Scenario detail parameters include: product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details in the product detail 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; discounted product name, discount level, product price, and product inventory in the product discount scenario; and user points current points, used points, and points validity period in the user points scenario.

[0170] Specifically, by parsing the request parameters, such as business scenario parameters and scenario detail parameters, the business fields that match the request parameters are obtained. Specifically, the actual business scenario fields are obtained (e.g., product detail information retrieval scenario, shopping cart product information retrieval scenario, promotional or discounted product detail retrieval scenario, object points usage detail retrieval scenario, etc.) and the scenario detail fields corresponding to the business scenario fields (e.g., in the product detail information retrieval scenario, it is necessary to obtain product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details).

[0171] Step S713: Perform logical 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 various business fields to determine the service nodes to be called. For example, based on business scenario fields such as product detail information acquisition scenario, shopping cart product information acquisition scenario, promotional or discounted product detail acquisition scenario, and user points acquisition scenario, logical distribution processing is performed. In the product detail information acquisition scenario, the service nodes to be called are determined based on detail information acquisition fields such as product price, product inventory, product buy-one-get-one-free configuration, full reduction configuration, product origin, and product details. For example, the service nodes corresponding to the product detail information acquisition scenario and the service nodes corresponding to the promotional product detail acquisition scenario are determined.

[0173] For example, obtaining product details first requires acquiring basic product information (product price, product inventory, buy-one-get-one-free offers, discounts, etc.). This involves calling service nodes with sequential dependencies, passing the basic product information sequentially to the pricing service node. The pricing service then processes the product's pricing based on this information, returning a dynamic promotional price. After acquiring the basic product information, it's possible to concurrently retrieve data such as product points (points earned after purchasing the product), reservation information, and shipping costs by calling service nodes with parallel dependencies.

[0174] Similarly, if an object needs to redeem a product using points, it needs to call a service node with a logical gateway call dependency relationship to determine whether the object's current points meet the points required for product redemption. If it is determined that the object's current points meet the points required for product redemption, then the target service node with points redemption function is further called.

[0175] Step S714: Obtain the downstream dependency information corresponding to each business field, and determine the dependency relationship between each business field based on the downstream dependency information.

[0176] Each service node is responsible for performing different data acquisition, data processing, and data feedback operations. Each service node is configured with specific operations or tasks to perform, such as acquiring product points data, acquiring product discount levels, acquiring product buy-one-get-one-free configurations, and acquiring product minimum spend reduction configurations. Depending on the task to be performed, each service node is injected with the necessary downstream dependency information to ensure that it can correctly call downstream service nodes.

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

[0178] Step S715: Perform stream orchestration processing based on the dependencies between various business fields to determine the dependency call relationships between service nodes. The dependency call relationships between service nodes include serial calls, parallel calls, and logical gateway calls.

[0179] The dependency relationships between service nodes specifically include serial calls, parallel calls, and logical gateway calls. Specifically, service nodes with serial call dependencies are those that need to be called sequentially according to the order of their calls, while those with parallel call dependencies are those that need to be called simultaneously. Service nodes with logical gateway call dependencies determine which target service node to select when specific conditions are met, through the execution of judgment logic. For example, when a user needs to redeem a product using points, it needs to determine whether the user's current points meet the requirements for redemption. If it is determined that the user's current points meet the requirements, then the target service node with points redemption functionality is called.

[0180] Specifically, based on the dependencies between various business fields, such as fields related to the product details information retrieval scenario (e.g., product price, product inventory, buy-one-get-one-free configuration, discount configuration, product origin, and product details), process orchestration is performed. This involves determining the service nodes used to retrieve product price, inventory, buy-one-get-one-free configuration, discount configuration, origin, and details, and the dependency call relationships between these service nodes and the service nodes corresponding to the product details information retrieval scenario fields. For example, based on the service nodes corresponding to the product details information retrieval scenario fields, each service node with a dependency call relationship is identified. This node retrieves basic product information (including product price, inventory, buy-one-get-one-free configuration, and discount configuration), and calls each service node with a serial call relationship to the service node retrieving product details information. The basic product information is then passed to the pricing service node, which performs product pricing processing on the basic product information and returns a dynamic promotional price.

[0181] Step S716: Call each service node sequentially according to the dependency call relationship to obtain the sub-business data fed back by the service node.

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

[0183] For example, in a scenario where product details are retrieved, the process first involves calling service nodes with sequential dependency relationships to obtain basic product information (product price, product inventory, buy-one-get-one-free offers, discounts, etc.). This basic product information serves as sub-business data returned by the service nodes involved in the sequential calls. After obtaining the basic product information, it is sequentially passed to the pricing service node. The pricing service then performs product pricing processing on the basic information, returning a dynamic promotional price. This dynamic promotional price can also be used as sub-business data returned by the pricing service node.

[0184] After obtaining the basic information of the product, the system can obtain data such as product points (i.e., points obtained after purchasing the product), product reservation information, and product postage by calling service nodes with dependent call relationships that exist in parallel. The obtained product points, product reservation information, and product postage data are then used as sub-business data fed back by the service nodes that are called in parallel.

[0185] Similarly, if a user needs to redeem a product using points, a service node with a logical gateway call dependency relationship needs to be invoked to determine if the user's current points meet the requirements for product redemption. If it is determined that the user's current points meet the requirements, a target service node with points redemption functionality is further invoked. In the case of the user redeeming points, the user's total points are deducted according to the points required for product redemption, and the product is redeemed. The points required for product redemption, the user's total points, and the product redemption status reported by the target service node with points redemption functionality are all sub-business data that the target service node can report.

[0186] Step S717: Based on the business source attribute corresponding to the business data acquisition request, determine the target protocol that matches 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] Business data acquisition requests can be triggered through different access methods, corresponding to different business source attributes. These business source attributes can be understood as specific business parties, including: specific applications (such as shopping applications), application platforms (such as e-commerce platforms), mini-programs (such as shopping mini-programs loaded within social applications), and web pages (such as shopping website pages), etc. It is understandable that since different business parties typically support different protocols—that is, different business source attributes corresponding to business data acquisition requests employ different protocols—it is necessary to perform protocol adaptation and data population processing on the currently obtained sub-business data. This is to convert the sub-business data returned by different service nodes into target protocol formats that can be received or supported by the different business parties triggering the business data acquisition requests.

[0188] Specifically, by obtaining the business source attributes corresponding to the business data acquisition request, the business parties that triggered the business data acquisition request are identified, and the target protocols actually supported by each business party are obtained, thus determining the target protocols that match the business data acquisition request.

[0189] Furthermore, according to the target protocol, the sub-business data fed back by each service node undergoes protocol adaptation processing. This involves converting the sub-business data into the target protocol format supported by the respective business parties that triggered the business data acquisition request. The converted sub-business data then undergoes data population and data assembly processing to obtain complete target business data. By employing protocol adaptation and data population processing, the relevant business parties can easily receive and recognize the complete target business data in the target protocol format.

[0190] Step S718: Cache the target business data into the fallback data cache.

[0191] In this context, the fallback data cache can be understood as a cache that stores fallback data that is fed back to each business unit when one or more service nodes cannot be accessed normally. Specifically, for example, if the downstream pricing service is unavailable, all real-time requests will be unable to obtain product prices for a short period of time. If the current pricing service has not yet been restored, the previously stored fallback cache data should be used as the normal data to return, waiting for the downstream pricing service to be restored.

[0192] Step S719: Detect the status of the fallback cache component. If the fallback cache component is determined to be in the running state, obtain the business fallback data based on the fallback data cache and feed back the business fallback data to the terminal that triggered the business data acquisition request.

[0193] Specifically, by detecting the status of the fallback cache component, i.e. whether the fallback cache component switch is on, if it is determined that the fallback cache component is in a running state, i.e., the fallback cache component switch is on, the business fallback data is directly obtained based on the fallback data cache. That is, it is checked whether there is available data in the fallback cache, and the available business fallback data is obtained from the fallback data cache. The business fallback data is used as the target business data corresponding to the current business data retrieval request, and is fed back to the terminal that triggered the business data retrieval request for the user to view.

[0194] Understandably, if downstream services are unavailable, such as when even basic product information (including product name, product background image, product price, etc.) cannot be obtained, checking the fallback cache for available data and using the obtained available data as the target business data corresponding to the current business data retrieval request can prevent users from seeing error pages or blank pages, thus reducing the occurrence of impaired user experience.

[0195] In the aforementioned business request processing method, a business data retrieval request is received. After confirming the request passes business validity verification, the request parameters are obtained. These parameters are then parsed to identify matching business fields, thus accurately identifying different business scenarios associated with the request. Logical distribution and process orchestration are performed based on these business fields to determine the service nodes to be invoked and the dependency relationships between them. Service nodes are then invoked sequentially according to these dependency relationships to quickly and accurately retrieve sub-business data from each node. This improves the efficiency of sub-business data retrieval while ensuring the relevance between each sub-business data and the business scenario to which the current request belongs, ensuring the obtained sub-business data aligns with the actual business scenario. Furthermore, based on the business source attribute corresponding to the request, a target protocol is determined. Protocol adaptation and data filling are then performed on each sub-business data according to the target protocol to obtain the target business data corresponding to the 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.

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

[0197] Step S801: Determine the operating status of the grayscale traffic component.

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

[0199] Step S803: If the grayscale traffic component is in the running state and the business data acquisition request hits the online traffic, then the business data acquisition request will be assigned to the online interface.

[0200] After executing step S802 or step S803, execute step S804 to perform business validity verification based on the business data acquisition request.

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

[0202] Step S806: If it is determined that the business data acquisition request has failed the business validity verification, then the current access interface is determined to be invalid.

[0203] After executing step S805, execute step S807 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, then 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 was not successfully matched, then the scenario information corresponding to the current business data acquisition request is determined to be an invalid scenario.

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

[0207] Step S811: If the fallback cache component is in the running state, obtain the business fallback data based on the fallback data cache, and feed back the business fallback data to the terminal that triggered the business data acquisition request.

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

[0209] Step S813: Obtain the downstream dependency information corresponding to each business field, and determine the dependency relationship between each business field based on the downstream dependency information.

[0210] Step S814: Perform stream orchestration processing based on the dependencies between various business fields to determine the dependency call relationships between various service nodes.

[0211] Step S815: Call each service node sequentially according to the dependency call relationship to obtain the sub-business data fed back by the service node.

[0212] Step S816: Determine the 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: Perform protocol adaptation 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.

[0214] Step S818: Cache the target business data into the fallback data cache.

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

[0216] Step S820: Based on the scenario request data reported by the asynchronous queue, perform hot data verification processing, determine the hot data requests, and store the hot business data that matches the hot data requests in the preset hot cache.

[0217] Step S821: If it is determined that the business data acquisition request is a hot data request, retrieve the hot business data that matches the hot data request from the preset hot data cache, and determine the hot business data as the target business data.

[0218] Step S822: Determine whether the current business data retrieval request has failed.

[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 business data is fed back to the terminal.

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

[0222] In the aforementioned business request processing method, a business data retrieval request is received. After confirming the request passes business validity verification, the request parameters are obtained. These parameters are then parsed to identify matching business fields, thus accurately identifying different business scenarios associated with the request. Logical distribution and process orchestration are performed based on these business fields to determine the service nodes to be invoked and the dependency relationships between them. Service nodes are then invoked sequentially according to these dependency relationships to quickly and accurately retrieve sub-business data from each node. This improves the efficiency of sub-business data retrieval while ensuring the relevance between each sub-business data and the business scenario to which the current request belongs, ensuring the obtained sub-business data aligns with the actual business scenario. Furthermore, based on the business source attribute corresponding to the request, a target protocol is determined. Protocol adaptation and data filling are then performed on each sub-business data according to the target protocol to obtain the target business data corresponding to the 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.

[0223] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0224] Based on the same inventive concept, this application also provides a business request processing apparatus for implementing the business request processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more business request processing apparatus embodiments provided below can be found in the limitations of the business request processing method described above, and will not be repeated here.

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

[0226] The request parameter acquisition module 902 is used to receive business data acquisition requests. If it is determined that the business data acquisition request passes the business validity verification, the request parameters carried by the business data acquisition request are acquired.

[0227] The field parsing module 904 is used to parse the request parameters, obtain the business fields that match the request parameters, and perform logical distribution and process orchestration based on each business field to determine the service node to be called and the dependency call relationship between each service node.

[0228] Service node invocation module 906 is used to invoke each service node sequentially according to the dependency invocation relationship in order to obtain the sub-business 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 attribute corresponding to the business data acquisition request, and to 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 aforementioned business request processing device, a business data acquisition request is received. After confirming that the request passes business validity verification, the request parameters are obtained. These parameters are then parsed to obtain the business fields matching the request parameters, thus accurately identifying different business scenarios associated with the request. Based on each business field, logical distribution and process orchestration are performed to determine the service nodes to be invoked and the dependency relationships between them. This allows for sequential invocation of each service node according to the dependency relationships, enabling rapid and accurate acquisition of sub-business data from each service node. This improves the efficiency of sub-business data acquisition while ensuring the relevance between each sub-business data and the business scenario to which the current business data acquisition request belongs, ensuring that the acquired sub-business data closely matches the actual business scenario. Furthermore, based on the business source attribute corresponding to the business data acquisition request, a target protocol matching the request is determined. Protocol adaptation and data filling are then performed on each sub-business data according to the target protocol to obtain the target business data corresponding to the request. By comprehensively considering different business fields, acquiring the sub-business data corresponding to different business fields, and further integrating and processing, complete and accurate target business data is obtained.

[0231] In one embodiment, a business request processing apparatus is provided, further comprising a protocol adaptation processing module, configured to: 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; 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 apparatus is provided, further comprising a validity verification module, configured to: obtain business scenario information carried in 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 based on the preset standard attribute information, and obtain the corresponding validity verification result.

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

[0234] In one embodiment, the hot business data caching module is further configured to: call the inspection service node, sequentially read scene request data from the asynchronous queue, and obtain the number of requests for each scene request data within a preset time window; obtain the request count threshold corresponding to the hot data maintenance window associated with the inspection service node, and compare the request count threshold with the request count; if the request count is greater than the request count threshold, determine the business data acquisition request corresponding to the current scene request data as a hot data request.

[0235] In one embodiment, the target business data acquisition module is further configured to: compare the business data acquisition request with each hot data request and generate a comparison result; if the comparison result determines that the business data acquisition request is a hot data request, retrieve the hot business data that matches the hot data request from the preset hot data cache, and determine the hot business data as the target business data.

[0236] In one embodiment, the service node invocation module is further configured to: perform logical 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 stream orchestration processing based on the dependency relationship between each business field to determine the dependency invocation relationship between each service node; the dependency invocation relationship between service nodes includes serial invocation, parallel invocation, and logical gateway invocation.

[0237] In one embodiment, a business request processing apparatus is provided, further comprising:

[0238] The fallback data caching module is used to cache target business data in the fallback data cache; the business fallback data feedback module is used to detect the status of the fallback cache component. If the fallback cache component is determined to be running, the fallback business data is obtained based on the fallback data cache and fed back to the terminal that triggered the business data retrieval request.

[0239] In one embodiment, a business request processing apparatus is provided, further comprising an application development version verification module, configured to: obtain the status of a grayscale traffic component; if the grayscale traffic component status is running, 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 a grayscale traffic interface, allocate the target business data corresponding to the business data acquisition request to grayscale traffic; perform application development version verification based on grayscale traffic, and obtain the corresponding version verification result; the version verification result is used to determine the development status of the application development version, including development failure and development success.

[0240] Each module in the aforementioned service request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0241] In one embodiment, such as Figure 10 As shown, a business request processing system is provided, specifically including a service access layer, a business verification layer, a component link layer, a data acquisition layer, and a business optimization layer. The system's call scenarios (or access methods) specifically include: mini-program access, H5 page access, internal service access (such as access by developers, testers, and operations personnel), and external service access (including access via object points services and promotional activity pages). The service access layer primarily handles protocol adaptation and conversion, and traffic canary control. This layer is designed to support requests using various protocols, such as HTTP and internal communication protocols. The business verification layer primarily verifies the legality of the requested business, while the component link layer provides fallback caching capabilities, hotspot data detection capabilities, and process orchestration capabilities. The data acquisition layer provides core service protection strategies and performs efficient service dependency management, while the business optimization layer handles error degradation, cache write-back, and failure event reporting. Specifically, refer to... Figure 10 It can be seen that each component is used to achieve 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, determine the access interface based on the business source attributes of different business data acquisition requests, and obtain the target protocol corresponding to the access interface, so as to perform protocol adaptation processing on the business data acquisition request according to the target protocol and obtain the standard business data acquisition request under the general request structure.

[0244] The service access layer includes a traffic canary component to implement canary traffic control. Specifically, based on the application development version iteration requirements, a canary traffic component is set up to control the traffic switching rate during application development or service upgrades. For example, when a new feature module is launched and needs verification, to ensure the stability of the online service, some traffic requests need to be switched to the new development version with the new feature module, while other traffic requests remain on the previous stable version. This is how the canary traffic component is introduced to effectively control the switching rate of traffic requests.

[0245] Reference Figure 10 As can be seen, the service access layer can also be used to obtain the basic product information required for business data retrieval requests, including product price, product inventory, product discount configurations, and product buy-one-get-one-free configurations. Furthermore, the service access layer provides batch product capabilities, allowing for the simultaneous viewing of basic information from different products in batches, reducing the number of views and improving data access efficiency.

[0246] P2, Business Verification Layer

[0247] Specifically, the business validation layer is used to validate the validity of business data retrieval requests. It also provides a variety of business scenarios, including general scenarios (product details retrieval scenario, shopping cart product information retrieval scenario, promotional or discounted product details retrieval scenario, user points retrieval scenario, etc.), Feiliu activity scenario (representing the scenario of retrieving details of a large number of products in batches), and external scenarios (including access channels, i.e., partner business scenarios, user points scenarios, promotional activity scenarios, and discount activity scenarios, etc.), to adapt to different business scenarios.

[0248] P3, Component Link Layer

[0249] Specifically, the component link layer provides fallback caching capabilities, hotspot data reporting capabilities, and process orchestration modules. Specifically, by setting up a fallback caching component and ensuring it is in a running state, fallback business data is retrieved based on the fallback data cache, and this fallback business data is then fed back to the terminal that triggered the business data retrieval request.

[0250] Similarly, by reporting scenario request data from different business scenarios within a preset time period through an asynchronous queue, and setting up inspection service nodes, the system performs hotspot data verification processing on the scenario request data reported by the inspection service nodes based on the asynchronous queue. This identifies hotspot data requests and stores the hotspot business data matching the hotspot data requests in a preset hotspot cache. Specifically, by comparing business data retrieval requests with each hotspot data request, if a business data retrieval request is determined to be a hotspot data request, the system retrieves the hotspot business data matching the hotspot data request from the preset hotspot cache and identifies this hotspot business data as the target business data.

[0251] Specifically, the process involves parsing the request parameters of business data retrieval requests to obtain the business fields that match the request parameters. Logical distribution is then performed based on each business field to determine the corresponding service node. Further, downstream dependency information corresponding to each business field is obtained, and the dependencies between these business fields are determined based on this information. Stream orchestration is then performed according to these dependencies to determine the dependency call relationships between service nodes. Finally, each service node is called sequentially according to these dependency call relationships to obtain the sub-business data returned by the service nodes.

[0252] P4, Data Acquisition Layer

[0253] The data acquisition layer provides core service protection and service dependency management. Core service protection includes services for acquiring product shipping fees, product points, static product data, and dynamic product data. Service dependency management manages the dependency calls to services such as coupons, reservations, and product categories, providing each service node with the necessary sub-business data, including product shipping fees, reservation information, points, and coupons.

[0254] P5, Business Optimization Layer

[0255] Specifically, the business optimization layer is used to implement error degradation, cache write-back, and failure event reporting. Among them, the degradation optimization strategy is used to implement error degradation, that is, when there are multiple requests, if an error occurs in some of the requests, the product structure can be populated with the already obtained partial data to avoid users seeing error pages or blank pages.

[0256] Specifically, a fallback caching component is set up, and the target business data is cached in the fallback data cache. The fallback caching component's status is monitored; if it is running, the fallback business data is retrieved from the fallback data cache and sent back to the terminal that triggered the data retrieval request. Furthermore, the system determines whether the data retrieval request failed; if it fails, a failure event is reported. If the request succeeds, a normal response is provided, and the identified target business data is sent back to the terminal.

[0257] The aforementioned business request processing system comprises multiple components, including a service access layer, a business verification layer, a component link layer, a data acquisition layer, and a business optimization layer. These components can be flexibly selected based on actual scenarios. For personalized requests in different business scenarios, the system effectively resolves interdependencies between underlying services by combining with a process orchestration engine, making business expansion more scalable. For high-concurrency event scenarios, data fallback and degradation strategies are implemented, along with inspections and data analysis to proactively identify and protect hot data, preventing service breakdowns caused by intensive access to hot data. This ensures the reliability and stability of product data acquisition and management capabilities under high-concurrency event scenarios.

[0258] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 11 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as business data retrieval requests, request parameters carried in the business data retrieval requests, business fields matching the request parameters, service nodes to be invoked, dependency relationships between service nodes, business source attributes corresponding to the business data retrieval requests, target protocols, and target business data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a business request processing method.

[0259] Those skilled in the art will understand that Figure 11The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0260] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0261] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

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

[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, data stored, data displayed, 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 related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0264] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this 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), magnetic 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. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0265] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A business request processing method, characterized in that, The method includes: Receive a business data acquisition request and acquire the business source attribute corresponding to the business data acquisition request; Based on the business source attribute, the access interface is determined, the target protocol corresponding to the access interface is obtained, and the business data acquisition request is adapted according to the target protocol to obtain a standard business data acquisition request under a general request structure. Obtain the business scenario information carried in the standard business data acquisition request, as well as the preset standard attribute information that matches the business source attribute, and perform business validity verification on the business scenario information according to the preset standard attribute information to obtain the corresponding validity verification result; If it is determined that the standard business data acquisition request passes the business validity verification, the request parameters carried by the standard business data acquisition request are obtained; The request parameters are parsed to obtain the business fields that match the request parameters, and logical distribution is performed based on each business field to determine the service node corresponding to each business field. Obtain downstream dependency information corresponding to each of the aforementioned business fields, determine the dependency relationships between the aforementioned business fields based on the downstream dependency information, and perform process orchestration based on the dependency relationships between the aforementioned business fields to determine the dependency call relationships between the aforementioned service nodes; the dependency call relationships between the service nodes include serial calls, parallel calls, and logical gateway calls; According to the aforementioned dependency call relationship, each of the aforementioned service nodes is called sequentially to obtain the sub-business data fed back by the service nodes; Based on the business source attribute corresponding to the business data acquisition request, the business party that triggered the business data acquisition request is determined, and the target protocol supported by the business party is obtained. The target protocol matching the business data acquisition request is obtained, and the sub-business data is processed for protocol adaptation and data filling according to the target protocol to obtain the target business data corresponding to the business data acquisition request. The target business data is then cached in the fallback data cache.

2. The method according to claim 1, characterized in that, Before receiving the business data acquisition request and acquiring the business source attribute corresponding to the business data acquisition request, the method further includes: Request data from different business scenarios within a preset time period will be reported via an asynchronous queue. Based on the scenario request data reported by the asynchronous queue, hot data verification processing is performed to determine the hot data requests. Hot business data that matches the hot data request will be stored in a preset hot data cache.

3. The method according to claim 2, characterized in that, The process of performing hotspot data verification on the scenario request data reported by the asynchronous queue to determine hotspot data requests includes: The inspection service node is invoked to read the scene request data sequentially from the asynchronous queue, and the number of requests for each scene request data within a preset time window is obtained. Obtain the 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; If the number of requests exceeds the request count threshold, the business data acquisition request corresponding to the current scenario request data will be identified as a hot data request.

4. The method according to claim 2 or 3, characterized in that, When receiving a business data retrieval request, it also includes: The business data acquisition request is compared with each of the hot data requests to generate a comparison result; If the comparison result determines that the business data acquisition request is a hot data request, the hot business data matching the hot data request is obtained from the preset hot data cache, and the hot business data is determined as the target business data.

5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The status of the fallback cache component is detected. If the fallback cache component is determined to be in a running state, the fallback business data is obtained based on the fallback data cache, and the fallback business data is fed back to the terminal that triggered the business data acquisition request.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Obtain the status of the grayscale traffic component. If the grayscale traffic component is in the running state, perform grayscale traffic distribution confirmation processing based on the standard business data acquisition request. If it is determined that the standard business data acquisition request belongs to the gray traffic interface, the target business data corresponding to the standard business data acquisition request will be allocated to the gray traffic. Application development version verification is performed 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, which includes development failure and development success.

7. The method according to any one of claims 1 to 3, characterized in that, Before obtaining the downstream dependency information corresponding to each of the aforementioned business fields, the process includes: For each service node corresponding to a business field, downstream dependency information corresponding to the execution task is injected into the service node according to the execution task corresponding to the service node, so that the service node calls the downstream service node according to the downstream dependency information.

8. A service request processing apparatus, characterized in that, The device includes: The request parameter acquisition module is used to receive a business data acquisition request, acquire the business source attribute corresponding to the business data acquisition request; determine the access interface based on the business source attribute, acquire the target protocol corresponding to the access interface, and 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; acquire the business scenario information carried by the standard business data acquisition request and the preset standard attribute information matching the business source attribute, and perform business validity verification on the business scenario information according to the preset standard attribute information to obtain the corresponding validity verification result; if it is determined that the standard business data acquisition request passes the business validity verification, acquire the request parameters carried by the standard business data acquisition request. The field parsing module is used to parse the request parameters to obtain business fields that match the request parameters, and to perform logical distribution processing based on each business field to determine the service node corresponding to each business field; to obtain downstream dependency information corresponding to each business field, to determine the dependency relationship between each business field based on the downstream dependency information, and to perform process orchestration processing based on the dependency relationship between each business field to determine the dependency call relationship between each service node; the dependency call relationship between service nodes includes serial call, parallel call, and logical gateway call; The service node invocation module is used to sequentially invoke each of the service nodes according to the dependency invocation relationship in order to obtain the sub-business data fed back by the service nodes; The target business data acquisition module is used to determine the business party that triggered the business data acquisition request based on the business source attribute corresponding to the business data acquisition request, obtain the target protocol supported by the business party, obtain the target protocol that matches the business data acquisition request, and perform protocol adaptation processing and data filling processing 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, and cache the target business data in the fallback data cache.

9. The apparatus according to claim 8, characterized in that, The device also includes a hotspot service data caching module, used for: Scenario request data under different business scenarios within a preset time period are reported through an asynchronous queue; based on the scenario request data reported by the asynchronous queue, hot data verification processing is performed to determine hot data requests; hot business data matching the hot data requests are stored in a preset hot data cache.

10. The apparatus according to claim 9, characterized in that, The hot-spot service data caching module is also used for: The inspection service node is invoked to read the scene request data sequentially from the asynchronous queue, and the number of requests for each scene request data within a preset time window is obtained. Obtain the 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; if the request count is greater than the request count threshold, determine the business data acquisition request corresponding to the current scenario request data as a hotspot data request.

11. The apparatus according to claim 9 or 10, characterized in that, The target business data acquisition module is also used for: The business data acquisition request is compared with each of the hot data requests to generate a comparison result; if the business data acquisition request is determined to be a hot data request based on the comparison result, hot business data matching the hot data request is obtained from the preset hot data cache, and the hot business data is determined as the target business data.

12. The apparatus according to any one of claims 8 to 10, characterized in that, The device also includes a business backup data feedback module, used for: The status of the fallback cache component is detected. If the fallback cache component is determined to be in a running state, the fallback business data is obtained based on the fallback data cache, and the fallback business data is fed back to the terminal that triggered the business data acquisition request.

13. The apparatus according to any one of claims 8 to 10, characterized in that, The device further includes an application development version verification module, used for: Obtain the status of the grayscale traffic component. If the grayscale traffic component is in the running state, perform grayscale traffic distribution confirmation processing based on the standard business data acquisition request. If it is determined that the standard business data acquisition request belongs to the grayscale traffic interface, allocate the target business data corresponding to the standard business data acquisition request to the grayscale traffic. Based on the grayscale traffic, the application development version is verified to obtain the corresponding version verification result. The version verification result is used to determine the development status of the application development version, which includes development failure and development success.

14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images