Service request processing method and device, equipment and medium

Abstract

The invention relates to the field of service processing, in particular to a service request processing method and device, equipment and a medium. According to the method, the service requests are distributed to the corresponding target servers according to the types, splitting processing of the services is achieved, the servers with different types of requests can independently carry out resource expansion, and the problem that resources cannot be independently expanded by a single framework is solved; secondly, different request types correspond to independent servers and resources, code decoupling between modules and single module modification do not need overall compilation deployment, the fault influence range is reduced, and the iteration efficiency is improved; then, the event bus serves as an asynchronous communication line and can be flexibly adapted to technical stacks of different servers, binding and fixing technologies are not needed, and the flexibility of the platform is improved; and finally, the event bus of asynchronous communication can realize efficient transmission of a processing result, so that request blockage is avoided, the operation performance of the platform is improved, and the service growth demand of the SaaS platform is adapted.

Description

Technical Field

[0001] This application relates to the field of business processing, specifically to a method, apparatus, device, and medium for processing business requests. Background Technology

[0002] Driven by the rapid popularization of cloud computing and big data technologies, SaaS platforms, with their characteristics of no local deployment, pay-as-you-go pricing, and rapid iteration, have become the core implementation method for enterprise information technology construction and are widely used in various business scenarios such as customer management, production scheduling, and financial management. As enterprises deepen their digital transformation, the scale of business carried by SaaS platforms continues to expand, the total amount, dimensions, and growth rate of business data are constantly increasing, and the complexity of business logic is also increasing accordingly.

[0003] Traditional monolithic architectures centralize all business modules, data processing, and service interfaces of a SaaS platform in a single codebase and runtime instance. While this offers advantages in the early stages of platform development, such as low development difficulty and simple deployment processes, it gradually reveals significant adaptation deficiencies as business scales up: all modules share computing and storage resources, making it impossible to independently expand resources for high-concurrency individual business modules, resulting in insufficient scalability; high code coupling means that modifications to a single module require recompiling and redeploying the entire system, which not only prolongs business iteration cycles but also increases the scope of failures, making it difficult to guarantee platform performance; furthermore, monolithic architectures are tied to a fixed technology stack, making it impossible to flexibly adapt the optimal technology solution to the needs of different business modules, resulting in a lack of flexibility and making it difficult to support the continuous development of the SaaS platform. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, device, and medium for processing business requests to solve the problems of traditional monolithic SaaS platforms, which cannot achieve independent resource expansion for business growth, have high code coupling leading to low iteration efficiency and a wide range of fault impacts, and lack flexibility in technology stack binding, making it difficult to meet the scalability, performance, and flexibility requirements of SaaS platforms.

[0005] Firstly, embodiments of this application provide a method for processing business requests, the method comprising: Obtain the business requests triggered by the user's client; Parse the business request to obtain the request type of the business request; The service request is sent to the target server corresponding to the request type, and the corresponding resources are invoked through the target server to process the service request and obtain the processing result; The event bus receives the processing result sent by the target server and sends the processing result corresponding to the service request to the user client to respond to the service request. The event bus is an asynchronous message communication line set up between the target server and the user client that processes the service request.

[0006] Furthermore, the step of sending the service request to the target server corresponding to the request type, and then using the target server to call the corresponding resources to process the service request and obtain the processing result includes: If the request type is a read type, then the query server corresponding to the read type is used as the target server, and the business request is sent to the query server; The query server reads the corresponding target data from the read database and uses the target data as the processing result.

[0007] Furthermore, the step of sending the service request to the target server corresponding to the request type, and then using the target server to call the corresponding resources to process the service request and obtain the processing result includes: If the request type is write, then the write server corresponding to the write type is used as the target server, and the business request is sent to the write server; The write server writes the target data carried in the request type into the write database according to the transaction management mechanism, and detects whether the target data has been written successfully to obtain the processing result.

[0008] Furthermore, sending the processing result corresponding to the service request to the user client includes: Obtain the context information associated with the business request; Dynamic routing is performed based on the context information to determine the network status and behavioral characteristics of the user client. Based on the sending strategy corresponding to the network status or the behavioral characteristics, the processing result is sent to the user client.

[0009] Furthermore, the step of sending the processing result to the user client according to the sending strategy corresponding to the network state or the behavioral characteristics includes: If the network status is weak, the event bus will call the data compression component to compress the processing result and send the compressed processing result to the user client. If the behavioral characteristic is that the user client has multiple consecutive business requests within a preset time window, the event bus will merge the processing results within the preset time window to obtain a merged processing result, and send the merged processing result and context information to the user client.

[0010] Furthermore, the method also includes: If the request type is a write type, then the event bus is used to listen for whether the write database generates a target event, wherein the target event is generated by the write database after the target data is written; If a target event is generated, the target event is passed to the read database, and the data change information in the target event is parsed through the read database to complete the corresponding data update operation.

[0011] Furthermore, the method also includes: If the target event is not generated, a compensation mechanism is triggered; Based on the compensation mechanism, the target data of the business request is compared and verified with the data currently stored in the write database to obtain the processing status. Based on the processing status, targeted processing is performed to obtain a confirmation result of data writing.

[0012] Secondly, embodiments of this application provide a service request processing apparatus, the apparatus comprising: The acquisition module is used to acquire business requests triggered by user clients; The parsing module is used to parse the business request and obtain the request type of the business request; The sending module is used to send the business request to the target server corresponding to the request type, and to call the corresponding resources through the target server to process the business request and obtain the processing result. The processing module is used to receive the processing result sent by the target server based on the event bus, and send the processing result corresponding to the business request to the user client in order to respond to the business request. The event bus is an asynchronous message communication line set between the target server and the user client that processes the business request.

[0013] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the method described in the first aspect or any corresponding embodiment.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment.

[0015] This application distributes business requests to corresponding target servers according to their types, enabling the splitting and processing of business requests. Servers with different request types can independently expand their resources, solving the problem that monolithic architectures cannot independently expand resources. Secondly, different request types correspond to independent servers and resources, decoupling code between modules. Modifications to a single module do not require overall compilation and deployment, reducing the impact of failures and improving iteration efficiency. Thirdly, the event bus, as an asynchronous communication line, can flexibly adapt to the technology stacks of different servers without being bound to fixed technology implementations, improving platform flexibility. Finally, the asynchronous communication event bus can achieve efficient transmission of processing results, avoiding request blocking, improving platform performance, and adapting to the business growth needs of SaaS platforms. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a method for processing business requests according to some embodiments of this application; Figure 2 This is a flowchart illustrating a method for processing another business request according to some embodiments of this application; Figure 3 This is a structural block diagram of a service request processing method apparatus according to an embodiment of this application; Figure 4 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] According to embodiments of this application, a method, apparatus, device, and medium for processing business requests are provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] This embodiment provides a method for processing business requests. Figure 1 This is a flowchart of a business request processing method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain the business request triggered by the user client.

[0021] In this embodiment, the system listens to the request sending port of the user client, captures the data packets initiated by the client, parses the transmission protocol identifier of the data packets, and after confirming that they conform to the access protocol specification of the API gateway, extracts the request header, request body, and request identifier information from the data packets. The request header is then validated for legality, verifying the validity of the request authentication field and request signature field. If the validation passes, the complete request data is stored in a temporary request queue according to the structure of "request identifier-request header-request body," awaiting subsequent parsing. If the validation fails, the data packet is discarded, a validation failure feedback identifier is generated, and the data is temporarily stored in the abnormal request record area.

[0022] Step S102: Parse the business request to obtain the request type of the business request.

[0023] In this embodiment, business request data in the temporary request queue is read, the operation type field in the request body is parsed, and a preset request type mapping rule is matched: if the operation type is an add, modify, or delete field, it is determined to be a write request; if the operation type is a query or get field, it is determined to be a read request; the identifier information of the request type is extracted, and the business parameters in the request body, such as the requested business module and data identifier, are parsed. The request type is associated with the business parameters to generate the associated data of "request type-business parameter-request identifier", which is stored in the request routing dataset and awaits routing distribution.

[0024] Step S103: Send the business request to the target server corresponding to the request type, and use the target server to call the corresponding resources to process the business request and obtain the processing result.

[0025] In this embodiment, the request type identifier in the request routing dataset is read and matched against preset server routing rules: if it is a write request, the business request is forwarded to the target server corresponding to the command service; if it is a read request, the business request is forwarded to the target server corresponding to the query service. After receiving the request, the target server calls the corresponding business processing resources: the command service calls the transaction management component to start a database transaction, executes a write operation and writes to the write database; the query service calls the data reading component to read the corresponding data from the read database; after processing is completed, a processing result containing the request identifier, processing status, and business data is generated, a timestamp indicating the completion of processing is marked, and the result is sent to the message queue of the event bus.

[0026] Step S104: Receive the processing result sent by the target server based on the event bus, and send the processing result corresponding to the business request to the user client to respond to the business request. The event bus is an asynchronous message communication line set up between the target server and the user client that processes the business request.

[0027] In this embodiment of the application, a business request is sent to the target server corresponding to the request type, and the corresponding resources are called through the target server to process the business request and obtain the processing result. This includes: if the request type is a read type, the query server corresponding to the read type is used as the target server, and the business request is sent to the query server; the corresponding target data is read from the read database through the query server, and the target data is used as the processing result.

[0028] The system reads the request type identifier from the request routing dataset. If it's a read request, it matches the preset server mapping rules to determine the query server as the target server. It then calls the API gateway's routing and forwarding module to encapsulate the business request's request identifier, query parameters, and client identifier into a data packet conforming to the query server's communication protocol. This packet is sent to the query server's request receiving port via a dedicated communication link. Upon receiving the data packet, the query server parses the query parameters, generates a structured database query statement, and calls the read database access interface to execute the query operation. It then filters the target data from the specified data table in the read database that matches the query parameters, converts the target data to JSON format, adds a request identifier, query timestamp, and data verification code, marks the processed target data as the processing result, and stores it in the query server's result cache, awaiting subsequent transmission.

[0029] In this embodiment of the application, a business request is sent to the target server corresponding to the request type, and the corresponding resources are called through the target server to process the business request and obtain the processing result. This includes: if the request type is a write type, the write server corresponding to the write type is taken as the target server, and the business request is sent to the write server; the write server writes the target data carried in the request type into the write database according to the transaction management mechanism, and detects whether the target data has been successfully written to obtain the processing result.

[0030] The system reads the request type identifier from the request routing dataset. If it's a write type, it matches the preset server mapping rules and identifies the write server as the target server. It then calls the API gateway's routing and forwarding module to encapsulate the business request identifier, the target data to be written, and the client identifier into a data packet conforming to the write server's communication protocol. This packet is sent to the write server's request receiving port via a dedicated communication link. Upon receiving the data packet, the write server parses the target data to be written, initiates a transaction management mechanism, starts a database transaction, generates a structured database write statement, and calls the database write access interface to execute the write operation. After the write operation is complete, a transaction verification mechanism is triggered to check if the number of rows written and the integrity of the fields in the target data meet expectations. If they do, the transaction is committed; otherwise, it is rolled back. The transaction execution status, write result, and request identifier are integrated into a processing result, a write timestamp and data verification code are added, and the result is stored in the write server's result cache, awaiting subsequent transmission.

[0031] In this embodiment of the application, sending the processing result corresponding to the service request to the user client includes: Step A1: Obtain the context information associated with the business request.

[0032] The system monitors the request transmission link of the API gateway, captures business request data packets that have completed routing and distribution, parses the request header fields in the data packets, and extracts basic information such as request identifier, client IP, request initiation time, and business module identifier. It then calls the context information collection module, connects to the user client's status interface and the platform's user behavior database, and obtains data such as the client device model associated with the business request, current network access type, request frequency in the past 7 days, and business type of historical requests. The system then structurally integrates the basic information with the collected associated data, organizing it into a context information dataset according to the format of "request identifier - basic information - associated status - behavior data," and stores it in the context cache for subsequent routing analysis.

[0033] Step A2 involves dynamic routing based on contextual information to determine the network status and behavioral characteristics of the user client.

[0034] The system reads the context information dataset from the context cache, calls the dynamic routing algorithm, first parses the network access type, network latency, and packet loss rate data corresponding to the client IP to determine the network status of the user client, such as "low-latency stable network," "high-latency fluctuating network," or "weak signal disconnection risk network." Then, it parses the request frequency and historical request business type data of the past 7 days to extract user behavioral characteristics, such as "high-frequency query requests," "occasional write operation requests," and "concentrated period requests." The system associates and marks the network status with the behavioral characteristics, matches them with preset routing adjustment rules, adjusts the packet transmission priority of the route if the network status is high-latency fluctuating, and adjusts the cache hit strategy of the route if the behavioral characteristics are high-frequency queries. The dynamic routing analysis is completed, and the analyzed network status and behavioral characteristics are stored in the routing policy dataset.

[0035] Step A3: Based on the sending strategy corresponding to the network status or behavioral characteristics, send the processing result to the user client.

[0036] In this embodiment of the application, the processing result is sent to the user client according to the sending strategy corresponding to the network status or behavioral characteristics. This includes: if the network status is a weak network status, the event bus will call the data compression component to compress the processing result and send the compressed processing result to the user client; if the behavioral characteristics are that the user client has multiple consecutive service requests within a preset time window, the event bus will merge the processing results within the preset time window to obtain a merged processing result and send the merged processing result and context information to the user client.

[0037] If the network is determined to be weak, the built-in data compression component of the event bus is invoked, the configuration parameters of the LZMA compression algorithm are loaded, and the structured data of the processing result (including request identifier, business data, and status code) is losslessly compressed. During the compression process, redundant spaces and duplicate identifier fields in the data are removed to generate compressed binary data packets. A compression checksum, decompression key, and data length identifier are added to the data packets, marking them as dedicated transmission packets for weak networks. The weak network transmission link of the event bus is invoked, and a fragmentation transmission mechanism is used to split the data packets into data fragments of up to 128KB. Each fragment is given a fragment sequence number and a total fragment count identifier, and they are sent to the receiving port of the user client in fragment order. At the same time, a fragment retransmission mechanism is initiated. If a fragment is detected to be lost, the corresponding fragment is retransmitted.

[0038] Read the behavioral feature data obtained from the routing analysis. If it is determined that there are multiple consecutive business requests within a preset time window (e.g., 5 minutes), call the result merging component of the event bus to extract the valid business data segments of all processing results within the time window, remove duplicate request headers, validation fields, and status code fields, and structurally concatenate all business data according to the time order of the requests to generate the merged processing result. Read the context information dataset to extract the client network status and historical request frequency information, and add the context information to the extended fields of the merged processing result. Encapsulate the merged processing result into a JSON format data packet, add a merging identifier and request count statistics, and send it to the receiving port of the user client through the regular transmission link of the event bus, while recording the size of the merged data packet and the sending time.

[0039] As an example, such as Figure 2 As shown, when a user initiates a request to modify personal information, the API gateway receives the request, determines it to be a write request, and forwards it to the write service. The write service writes the modified personal information to the write database through transaction management, and the write database generates a data change event. The event bus captures this event and synchronizes it to the read database. During the synchronization process, the data is verified, and if a transmission failure occurs, a retry mechanism is triggered until synchronization is successful. If the user subsequently initiates a request to query personal information, the API gateway determines it to be a read request and forwards it to the query service. The query service reads the latest personal information data from the synchronized read database and returns the query result. Finally, the API gateway returns the processing results of the two requests to the user respectively, completing the entire process.

[0040] In this embodiment of the application, the method further includes: if the request type is a write type, then listening to whether the write database generates a target event through the event bus, wherein the target event is generated by the write database after the target data is written; if a target event is generated, the target event is passed to the read database, and the data change information in the target event is parsed through the read database to complete the update operation of the corresponding data.

[0041] For write requests, after the write server submits the database transaction and completes the target data write operation, the event listening thread of the event bus is started, and the event output node of the write database is bound. The listening rule is set to only capture target events that carry the unique identifier of the current write request and whose event type is "data write completed". The listening thread scans the event buffer of the write database at 50ms intervals. If a target event that meets the rule is detected, the signature information of the event is first verified. After confirming that the event has not been tampered with, the event ID, request identifier, and data change timestamp of the event are extracted. The event is marked as "pending delivery" and stored in the event forwarding queue of the event bus.

[0042] The system reads the target event to be transmitted from the event forwarding queue of the event bus, calls the event encapsulation component, and encrypts and encapsulates the core data of the event (data change information, request identifier, event ID) according to the event receiving protocol of the read database. It also adds the transmission priority identifier of the event (the priority of write request events is set to the highest). The encapsulated event data packet is sent to the event receiving port of the read database through the dedicated low-latency transmission link of the event bus. At the same time, the event sending time and link status are recorded. If packet loss occurs during transmission, the retry mechanism of the event bus is triggered, and the retry is performed up to 3 times until the data packet is successfully sent.

[0043] After receiving the event data packet from the database, the system first decrypts the data change information in the packet, parsing it to obtain the table name, primary key ID, changed field name, and field value corresponding to the target data. It then calls the database update component, using the primary key ID as the search condition, to locate the corresponding target data entry in the database. The parsed changed field values ​​are overwritten with the original field values, and the last synchronization timestamp of the data entry is updated. After the update is complete, the database verification mechanism is triggered, comparing the updated data with the core fields of the target data in the database. Once the data is confirmed to be consistent, a confirmation message indicating that the data update is complete is generated and stored in the database's synchronization log, thus completing the entire data update operation.

[0044] In this embodiment of the application, the method further includes: if no target event is generated, triggering a compensation mechanism; comparing and verifying the target data of the business request with the data currently stored in the write database based on the compensation mechanism to obtain the processing status; and performing targeted processing according to the processing status to obtain a confirmation result of data writing.

[0045] The event bus listener timeout judgment rule is started. If the listening time exceeds the preset event generation threshold (e.g., 500ms) and no target event generated by writing to the database is detected, the compensation mechanism is triggered. The initialization module of the compensation mechanism is called to extract the request identifier of the write type request, the target data to be written, and the access address of the write database. A compensation verification task is generated, the trigger time and request association information of the task are marked, and the task is stored in the compensation task queue. At the same time, the result feedback process of the write request is paused, and the processing status of the compensation verification is returned.

[0046] The system reads compensation verification tasks from the compensation task queue, calls the database access component to obtain the target data carried in the business request and the currently stored data of the corresponding data table in the database. Based on the unique identifier field of the data (such as primary key ID), the system compares the field values, data format, and integrity of the two types of data item by item: if all field values ​​match completely, the processing status is determined to be "data written, event not generated"; if there are field value mismatches or missing data, the processing status is determined to be "data write failed"; if there is no corresponding data in the database, the processing status is determined to be "data not written". The processing status is associated with the compared field difference information and data identifier and stored in the compensation result dataset.

[0047] The system reads the processing status from the compensation result dataset and performs targeted processing. If the processing status is "data written, event not generated," it manually generates a target event carrying data change information and sends it to the read database to complete synchronization. If the processing status is "data write failed," it re-triggers the write transaction in the write database and performs a second write operation on the target data. If the processing status is "data not written," it calls the transaction rollback mechanism to clear residual invalid data in the write database and then re-executes the write operation. After processing, the final write status and event synchronization status are integrated into a data write confirmation result, and a timestamp and checksum of the compensation processing are added. This result is then sent to the message queue of the event bus for feedback to the user client.

[0048] This embodiment also provides a service request processing apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0049] This embodiment provides a service request processing device, such as... Figure 3 As shown, it includes: Module 301 is used to acquire business requests triggered by the user client; Parsing module 302 is used to parse business requests and obtain the request type of the business request; The sending module 303 is used to send business requests to the target server corresponding to the request type, and to call the corresponding resources through the target server to process the business requests and obtain the processing results; The processing module 304 is used to receive the processing result sent by the target server based on the event bus, and send the processing result corresponding to the business request to the user client to respond to the business request. The event bus is an asynchronous message communication line set up between the target server and the user client that processes the business request.

[0050] In this embodiment of the application, the sending module 303 is used to, if the request type is a read type, take the query server corresponding to the read type as the target server and send the business request to the query server; read the corresponding target data from the read database through the query server and use the target data as the processing result.

[0051] In this embodiment of the application, the sending module 303 is used to, if the request type is a write type, take the write server corresponding to the write type as the target server and send the business request to the write server; the write server writes the target data carried in the request type into the write database according to the transaction management mechanism, and detects whether the target data is successfully written to obtain the processing result.

[0052] In this embodiment of the application, the processing module 304 is used to obtain the context information associated with the service request; perform dynamic routing based on the context information to determine the network status and behavioral characteristics of the user client; and send the processing result to the user client according to the sending strategy corresponding to the network status or behavioral characteristics.

[0053] In this embodiment of the application, the processing module 304 is used to, if the network status is weak, call the data compression component to compress the processing result and send the compressed processing result to the user client; if the behavior characteristics are that the user client has multiple consecutive service requests within a preset time window, the event bus will merge the processing results within the preset time window to obtain the merged processing result and send the merged processing result and context information to the user client.

[0054] In this embodiment of the application, the device further includes: a listening module, configured to, if the request type is write type, listen through the event bus to whether the write database generates a target event, wherein the target event is generated by the write database after the target data is written; if a target event is generated, pass the target event to the read database, and parse the data change information in the target event through the read database to complete the update operation of the corresponding data.

[0055] In this embodiment of the application, the device further includes: a compensation module, used to trigger a compensation mechanism if no target event is generated; to compare and verify the target data of the business request with the data currently stored in the write database based on the compensation mechanism to obtain a processing status; and to perform targeted processing according to the processing status to obtain a confirmation result of data writing.

[0056] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of this application, such as... Figure 4As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0057] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0058] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0059] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0060] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0061] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0062] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0063] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for processing business requests, characterized in that, The method includes: Obtain the business requests triggered by the user's client; Parse the business request to obtain the request type of the business request; The service request is sent to the target server corresponding to the request type, and the corresponding resources are invoked through the target server to process the service request and obtain the processing result. The event bus receives the processing result sent by the target server and sends the processing result corresponding to the service request to the user client to respond to the service request. The event bus is an asynchronous message communication line set up between the target server and the user client that processes the service request.

2. The method according to claim 1, characterized in that, The process of sending the service request to the target server corresponding to the request type, and then using the target server to call the corresponding resources to process the service request and obtain the processing result includes: If the request type is a read type, then the query server corresponding to the read type is used as the target server, and the business request is sent to the query server; The query server reads the corresponding target data from the read database and uses the target data as the processing result.

3. The method according to claim 1, characterized in that, The process of sending the service request to the target server corresponding to the request type, and then using the target server to call the corresponding resources to process the service request and obtain the processing result includes: If the request type is write, then the write server corresponding to the write type is used as the target server, and the business request is sent to the write server; The write server writes the target data carried in the request type into the write database according to the transaction management mechanism, and detects whether the target data has been written successfully to obtain the processing result.

4. The method according to claim 1, characterized in that, Sending the processing result corresponding to the service request to the user client includes: Obtain the context information associated with the business request; Dynamic routing is performed based on the context information to determine the network status and behavioral characteristics of the user client. Based on the sending strategy corresponding to the network status or the behavioral characteristics, the processing result is sent to the user client.

5. The method according to claim 4, characterized in that, The step of sending the processing result to the user client according to the sending strategy corresponding to the network state or the behavioral characteristics includes: If the network status is weak, the event bus will call the data compression component to compress the processing result and send the compressed processing result to the user client. If the behavioral characteristic is that the user client has multiple consecutive business requests within a preset time window, the event bus will merge the processing results within the preset time window to obtain a merged processing result, and send the merged processing result and context information to the user client.

6. The method according to claim 1, characterized in that, The method further includes: If the request type is a write type, then the event bus is used to listen for whether the write database generates a target event, wherein the target event is generated by the write database after the target data is written; If a target event is generated, the target event is passed to the read database, and the data change information in the target event is parsed through the read database to complete the corresponding data update operation.

7. The method according to claim 6, characterized in that, The method further includes: If the target event is not generated, a compensation mechanism is triggered; Based on the compensation mechanism, the target data of the business request is compared and verified with the data currently stored in the write database to obtain the processing status. Based on the processing status, targeted processing is performed to obtain a confirmation result of data writing.

8. A service request processing apparatus, characterized in that, The device includes: The acquisition module is used to acquire business requests triggered by user clients; The parsing module is used to parse the business request and obtain the request type of the business request; The sending module is used to send the business request to the target server corresponding to the request type, and to call the corresponding resources through the target server to process the business request and obtain the processing result. The processing module is used to receive the processing result sent by the target server based on the event bus, and send the processing result corresponding to the business request to the user client in order to respond to the business request. The event bus is an asynchronous message communication line set between the target server and the user client that processes the business request.

9. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1 to 7.

Images