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

Abstract

The application relates to a business system processing method and device, computer equipment, a storage medium and a computer program product. The method can be applied to the application scene of a vehicle terminal, a cloud server or other equipment interacting with a business system. The method comprises the following steps: in the case of a published business system, a business service request including interaction link information is received; when a target business service involved is sequentially called based on the interaction link information, a brake switch state of the target business service is read through a filter of the target business service; when the brake switch state is an enabled state, the business service request is intercepted through the filter, and an error response is returned based on the intercepted business service request; when the brake switch state is a disabled state, the business service request is processed according to the business logic of the target business service, and a response result corresponding to the business service request is returned. The method can effectively improve the processing efficiency of the business system.

Description

Technical Field

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

[0002] With the development of computer and internet technologies and the advent of the 5G era, the internet has brought great convenience to modern life. More and more users can process different business requests online through business systems, effectively improving the processing efficiency of different business requests. This has made the development and use of business systems play an increasingly important role in fields such as computer vision.

[0003] In current business system processing methods, especially during iterative development of business system versions, full verification of modified functionalities is required to ensure 100% code coverage in order to guarantee online business operation. When it comes to verifying various abnormal business scenarios, it is often necessary to manually construct scenarios of abnormal business services or parameters to ensure that the business system behaves as expected under abnormal scenarios, thereby ensuring the stability of the business system. This is achieved by manually taking some normal business services offline or changing correct configuration parameters to incorrect ones. However, this method can easily cause all normal business processes in the business system to malfunction, resulting in low processing efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a business system processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product to address the above-mentioned technical problems, which can effectively improve the processing efficiency of the business system.

[0005] Firstly, this application provides a business system processing method. The method includes: when the business system has been published, receiving a business service request including interaction link information; when sequentially calling relevant target business services based on the interaction link information, reading the braking switch state of the target business service through a filter of the target business service; when the braking switch state is active, intercepting the business service request through the filter and returning an error response based on the intercepted business service request; when the braking switch state is inactive, processing the business service request according to the business logic of the target business service and returning the response result corresponding to the business service request.

[0006] Secondly, this application also provides a business system processing apparatus. The apparatus includes: a receiving module, configured to receive a business service request including interaction link information when the business system has been published; a reading module, configured to read the braking switch state of the target business service through a filter of the target business service when sequentially calling the target business service based on the interaction link information; an interception module, configured to intercept the business service request through the filter when the braking switch state is in the activated state, and return an error response based on the intercepted business service request; and a processing module, configured to process the business service request according to the business logic of the target business service when the braking switch state is in the deactivated state, and return the response result corresponding to the business service request.

[0007] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor. The memory stores a computer program, and the processor, when executing the computer program, performs the following steps: In the case that the business system has been deployed, receiving a business service request including interaction link information; when sequentially calling the relevant target business services based on the interaction link information, reading the braking switch state of the target business service through a filter of the target business service; when the braking switch state is in the activated state, intercepting the business service request through the filter and returning an error response based on the intercepted business service request; when the braking switch state is in the deactivated state, processing the business service request according to the business logic of the target business service and returning the response result corresponding to the business service request.

[0008] 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: when the business system has been deployed, receiving a business service request including interaction link information; when sequentially invoking the relevant target business services based on the interaction link information, reading the braking switch state of the target business service through a filter of the target business service; when the braking switch state is in an activated state, intercepting the business service request through the filter and returning an error response based on the intercepted business service request; when the braking switch state is in a deactivated state, processing the business service request according to the business logic of the target business service and returning the response result corresponding to the business service request.

[0009] 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: when the business system has been deployed, receiving a business service request including interaction link information; when sequentially invoking the relevant target business services based on the interaction link information, reading the braking switch state of the target business service through a filter of the target business service; when the braking switch state is in an activated state, intercepting the business service request through the filter and returning an error response based on the intercepted business service request; when the braking switch state is in a deactivated state, processing the business service request according to the business logic of the target business service and returning the response result corresponding to the business service request.

[0010] The aforementioned business system processing method, apparatus, computer equipment, storage medium, and computer program product, in the case of a published business system, receive business service requests including interaction link information; when sequentially calling the relevant target business services based on the interaction link information, read the braking switch status of the target business service through a filter of the target business service; when the braking switch status is in the activated state, intercept the business service request through the filter and return an error response based on the intercepted business service request; when the braking switch status is in the deactivated state, process the business service request according to the business logic of the target business service and return the response result corresponding to the business service request. Since each target business service is configured with a filter, when the business system sequentially calls the relevant target business services based on the interaction link information carried in the business service request, it can read the braking switch status of each target business service through its filter and execute different processing flows according to the braking switch status. That is, when the braking switch status of the target business service is in the activated state, the business system intercepts the business service request through the filter of the target business service and returns an error response including a specific error code and error information identifier, so as to brake the normal business function of the target business service and construct the business scenario to be verified. In addition, when the braking switch status of the target business service is in the deactivated state, the business system can respond to the business service request according to the business logic of the target business service and return the response result corresponding to the business service request, so as to realize the normal business function of the target business service and ensure the normal operation of online business processing. In other words, by adjusting the activation and deactivation of different business service brake switches, it is possible to ensure rapid response to changes in business service behavior. It can quickly switch between two modes: "accepting requests and performing business logic normally" and "accepting requests but not performing business logic and returning a fixed exception." This effectively ensures the real-time performance and availability of the interaction link, effectively avoids direct modification of backend configuration files and database tables, reduces the risk of human error, and while ensuring the normal operation of the original business functions, it can also verify abnormal scenarios through the combination of brake switches of various business services, thereby effectively improving the processing efficiency of the business system. Attached Figure Description

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

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

[0013] Figure 3 This is a schematic diagram of the management interface for the backend service braking switch in one embodiment;

[0014] Figure 4This is a schematic diagram of the management interface of the modified backend service braking switch in one embodiment;

[0015] Figure 5 This is a schematic diagram of the brake switch change operation of a certain trading system in one embodiment;

[0016] Figure 6 This is a schematic diagram illustrating the update of the brake switch memory data in a certain trading system in one embodiment;

[0017] Figure 7 This is a schematic diagram of the overall transaction process after introducing the braking function in one embodiment;

[0018] Figure 8 This is a schematic diagram illustrating the reading of the brake switch state from memory data in one embodiment;

[0019] Figure 9 This is a flowchart illustrating the different states of the brake switch when the transaction execution service accepts a transaction order in one embodiment.

[0020] Figure 10 This is a schematic diagram illustrating how a filter is configured to intercept service requests in one embodiment.

[0021] Figure 11 This is a structural block diagram of a business system processing device in one embodiment;

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

[0023] 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.

[0024] Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.

[0025] Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. The services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to the system for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0026] Cloud storage is a new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together a large number of storage devices of various types (storage devices are also called storage nodes) in the network to work together through application software or application interfaces to provide data storage and business access functions to the outside world.

[0027] With the research and advancement of artificial intelligence (AI) technology, AI is being studied and applied in various fields, such as smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, autonomous driving, drones, robots, smart healthcare, smart customer service, vehicle networking, and intelligent transportation. It is believed that with the development of technology, AI will be applied in more fields and play an increasingly important role.

[0028] It should be noted that in the following description, the terms "first, second, and third" are used only to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, and third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0029] The business system processing method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with business system 104 via a network. A data storage system can store data that business system 104 needs to process. The data storage system can be integrated into business system 104 or placed in the cloud or on other network servers. With business system 104 already deployed, business system 104 receives a business service request triggered by terminal 102, including interaction link information. When business system 104 sequentially calls the relevant target business services based on the interaction link information, business system 104 reads the braking switch status of the target business service through the target business service's filter. When the braking switch status is active, business system 104 intercepts the business service request through the filter and returns an error response based on the intercepted business service request. When the braking switch status is inactive, business system 104 processes the business service request according to the business logic of the target business service and returns the corresponding response result.

[0030] The terminal 102 can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, IoT device, or portable wearable device. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices, etc.

[0031] Business system 104 can be an independent physical server or a service node in a blockchain system. The service nodes in the blockchain system form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol that runs on top of the Transmission Control Protocol (TCP).

[0032] In addition, business system 104 can also be a server cluster consisting of multiple physical servers, which can be cloud servers that provide 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, content delivery network (CDN), and big data and artificial intelligence platforms.

[0033] Terminal 102 and business system 104 can be connected via Bluetooth, USB (Universal Serial Bus) or network, etc., and this application does not impose any restrictions.

[0034] In one embodiment, such as Figure 2As shown, a business system processing method is provided. This method can be executed by the server or terminal alone, or by both the server and terminal. This method is applied to... Figure 1 Taking the business system in the example, the following steps are included:

[0035] Step 202: If a business system has been published, receive a business service request that includes interaction link information.

[0036] In this context, "business system" refers to a system used to provide business services. The business system in this application may include different types of business systems. For example, the business system in this application may be a resource interaction system. A resource interaction system is a system built to conduct different resource interactions. For example, the resource interaction system in this application may be a transaction system.

[0037] A published business system refers to a business system that has been published and launched. In this application, the business system can be published and launched using a canary release method. For example, a published business system can be a canary version of a published and launched business system. That is, when a business service in the business system is published and launched or when the business system version needs to be upgraded, a canary release method can be used.

[0038] Canary release (also known as gray-scale release) refers to a release method that allows for a smooth transition between black and white releases. During rapid iteration of business system versions, gray-scale versions and official versions can coexist. The gray-scale version is gradually rolled out to upgrade to the official version. In this way, the business system does not need to be shut down for a period of time when updating business service versions, and the transition process between different versions can be monitored. If a problem is found in the gray-scale version, it can be quickly rolled back to the original official version.

[0039] Interaction link information refers to the path information for calling business services. In other words, a business service request needs to be configured with corresponding interaction link information according to the order in which services are called. Interaction link information can include the call link information between business services. For example, after a business system receives a business service request A sent by a client through a gateway, the server can call service A to process the request based on the interaction link information A carried in the request. During the processing of the request, service A may also need to call service B. That is, interaction link information A can be represented as: SvcA→SvcB, meaning the business system forwards the request to service A for processing, and service A, in processing request A, further needs to call service B.

[0040] A business service request refers to a request initiated by a user in different business systems based on different needs and corresponding to a business function. The business service requests in this application may include different types of business requests. For example, the business service requests in this application may be resource interaction requests, which may include transaction order requests.

[0041] Specifically, in the case of a deployed business system, the business system (i.e., the server) can receive business service requests sent by terminals, including interaction link information. For example, a user can log in to a specific scenario's business system by entering a username and password in a terminal application or browser webpage. A user can initiate specific business service requests through an app (application) client or a web client (i.e., a web browser). The business system can then receive business service requests, including interaction link information, sent by different users through their clients. Here, the client, also called the user terminal, refers to the program that provides local services to the client, corresponding to the server. Except for some applications that run only locally, it is generally installed on ordinary client machines and needs to work in conjunction with the server. Clients can include DNS clients, web clients, game clients, and mobile clients, etc. For example, a mobile client, taking a mobile phone as an example, is software that can run on a mobile terminal.

[0042] For example, if a gray-scale version of business system A has been released, this gray-scale version of business system A can receive resource interaction requests, including interaction link information, sent by different terminals. For instance, business system A can receive resource interaction request A sent by terminal A, which includes interaction link information A, and resource interaction request B sent by terminal B, which includes interaction link information B.

[0043] Step 204: When sequentially calling the target business services involved based on the interaction link information, read the braking switch status of the target business service through the filter of the target business service.

[0044] In this context, the target business service refers to one or more business services contained in the business system. For example, if business system A contains services A, B, and C, and the interaction link information carried in business service request A includes services A and B, then the target business service could refer to services A and B.

[0045] A filter is a pre-configured component used to filter business service requests. For example, the filter in this application can be implemented by pre-writing a piece of code. The filter is mainly used to filter information such as character encoding. For instance, the filter in this application is used to filter the brake switch status parameter of the business service. It can be understood that in this application, a corresponding filter can be pre-configured for each business service in the business system, that is, one filter corresponds to one business service.

[0046] The brake switch state refers to the state of the brake switch. For example, the brake switch state in this application may include an on state and a off state. When the brake switch state is on, it means that the service has enabled the braking function; when the brake switch state is off, it means that the service has disabled the braking function.

[0047] The braking function refers to a braking capability. For example, if service A has enabled the braking function, when the braking switch of service A is detected to be in the activated state, a filter will cause service A to stop its normal business logic response processing. In this application, the braking capability refers to the ability to intercept business functions, manifested as returning a specific error response. That is, the braking capability in this application can ensure that a certain business service module in the business system operates normally and accepts requests from upstream services, but does not perform its own business logic processing, directly returning a specific error response to interrupt the business system call chain and stop the normal processing of business service requests.

[0048] It is understood that when the braking function in this application is enabled, it does not affect the operation of the business service's own module. It only filters and intercepts requests, does not execute the business logic of the business service module itself, and can directly return a special response. For example, if the braking function of a certain business service is disabled, the business service can provide services normally; if the braking function of a certain business service is enabled, when the business service is called, the business service returns a fixed error response and does not provide its own module's business services.

[0049] Specifically, in the case of a published business system, after receiving a business service request including interaction link information, the business system can sequentially call the relevant target business services based on the interaction link information. During the process of the business system sequentially calling the relevant target business services based on the interaction link information, the business system can read the braking switch status of the target business service through the filter of the target business service. For example, the business system can read the braking switch status of its own service from memory data through the filter of the target business service. That is, the braking switch of each business service in this application can be configured separately, realizing fine-grained management of each business service in the interaction link. Moreover, by combining the braking switches of various business services, complex business scenarios can be quickly constructed. For example, when performing abnormal scenario verification on the online release of the gray-scale version of the business system, different abnormal call scenarios can be constructed for multiple target business services existing in the interaction link.

[0050] For example, let's take a business system as a resource interaction system for illustration. Assume that in a resource interaction system A that has already released a gray-scale version, after receiving a resource interaction request A from terminal A via a gateway, which includes interaction link information A, resource interaction system A can sequentially call the relevant target services based on the interaction link information A. Let's assume the interaction link information A is represented as: SvcA→SvcB. When resource interaction system A sequentially calls the relevant target services based on the interaction link information A, it processes the resource interaction request A by calling service A. During the processing of resource interaction request A by service A, service A also needs to call service B. That is, when resource interaction system A forwards the resource interaction request A to service A for processing, it first reads the braking / switching state of service A through service A's filter A. Similarly, when service A further calls service B, it reads the braking / switching state of service B through service B's filter B.

[0051] Step 206: When the brake switch is in the active state, the service request is intercepted by the filter, and an error response is returned based on the intercepted service request.

[0052] Here, an error response refers to a specific exception response returned. In some cases, the error response in this application can also be called an exception response. For example, the error response in this application can be a fixed exception response returned, or the error response in this application can include a specific error code and error message identifier.

[0053] Specifically, when a business system sequentially calls the relevant target business services based on the interaction link information, the business system reads the braking switch status of the target business service through the target business service's filter. When the braking switch status of the target business service is active, the business system can intercept the business service request through the target business service's filter and return an error response based on the intercepted business service request. That is, the business system intercepts the business service request through the target business service's filter and returns an error response including a specific error code and error information identifier, thereby braking the normal business function of the target business service and constructing the required verification business scenario. It can be understood that this application uses a configuration filter to intercept business service requests to complete targeted work, which has the advantages of being non-intrusive to the service core and easily extensible.

[0054] For example, let's take a business system as a resource interaction system for illustration. Assume that in a resource interaction system A that has already been released in a gray-scale version, after receiving a resource interaction request A from terminal A via a gateway, which includes interaction link information A, resource interaction system A can sequentially call the relevant target services based on the interaction link information A. Let's assume the interaction link information A is represented as: SvcA→SvcB. When resource interaction system A sequentially calls the relevant target services based on the interaction link information A, and when resource interaction system A calls service A to process the resource interaction request A, it first reads the braking switch status of service A through service A's filter A. When service A's filter A reads that the braking switch status of service A is in the activated state, resource interaction system A can intercept the resource interaction request A through filter A and return a specific error response based on the intercepted resource interaction request A. For example, resource interaction system A can intercept the resource interaction request A through filter A and return an error response carrying a specific error code A01 and error information identifier S22.

[0055] Step 208: When the brake switch is in the off state, process the business service request according to the business logic of the target business service and return the response result corresponding to the business service request.

[0056] Among them, business logic refers to the business logic executed to achieve the normal business functions of the target business service.

[0057] The response result refers to the result obtained after processing the business service request according to the business logic of the target business service. For example, the response result in this application may include two types of response results: success response and failure response.

[0058] Specifically, when a business system sequentially calls the relevant target business services based on the interaction link information, the business system reads the braking switch status of the target business service through its filter. When the braking switch of the target business service is off, the business system can process the business service request according to the business logic of the target business service and return the corresponding response result, thus realizing the normal business function of the target business service and ensuring the normal operation of online business processing. In other words, by adjusting the activation and deactivation of different business service braking switches, the system can ensure rapid response to changes in business service behavior, quickly switching between two modes: "accepting requests and performing normal business logic" and "accepting requests but not performing business logic and returning a fixed exception." This effectively ensures the real-time performance and availability of the interaction link, saving time.

[0059] For example, let's take a business system as a resource interaction system for illustration. Assume that in a resource interaction system A that has already been released in a gray-scale version, after receiving a resource interaction request A from terminal A via a gateway, which includes interaction link information A, resource interaction system A can sequentially call the relevant target services based on the interaction link information A. Let's assume the interaction link information A is represented as: SvcA→SvcB. When resource interaction system A calls service A to process the resource interaction request A, it first reads the braking switch status of service A through service A's filter A. When service A's filter A reads that the braking switch status of service A is active, resource interaction system A can intercept the resource interaction request A through filter A and return a specific error response based on the intercepted resource interaction request A. Furthermore, when service A calls service B to process the resource interaction request A, it first reads the braking switch status of service B through service B's filter B. When service B's filter B reads that the braking switch status of service B is closed, resource interaction system A responds to the resource interaction request A according to service B's business logic. That is, service B will respond to the resource interaction request A according to its own business logic and return the response result A corresponding to the resource interaction request A. For example, resource interaction system A responds to the resource interaction request A through service B and returns the response result A carrying the result parameters obtained from real-time processing.

[0060] In this embodiment, when a business system has been deployed, a business service request including interaction link information is received. When the target business services involved are called sequentially based on the interaction link information, the braking switch status of the target business service is read through the filter of the target business service. When the braking switch status is in the activated state, the business service request is intercepted through the filter, and an error response is returned based on the intercepted business service request. When the braking switch status is in the deactivated state, the business service request is processed according to the business logic of the target business service, and the response result corresponding to the business service request is returned. Since each target business service is configured with a filter, when the business system sequentially calls the relevant target business services based on the interaction link information carried in the business service request, it can read the braking switch status of each target business service through its filter and execute different processing flows according to the braking switch status. That is, when the braking switch status of the target business service is in the activated state, the business system intercepts the business service request through the filter of the target business service and returns an error response including a specific error code and error information identifier, so as to brake the normal business function of the target business service and construct the business scenario to be verified. In addition, when the braking switch status of the target business service is in the deactivated state, the business system can respond to the business service request according to the business logic of the target business service and return the corresponding response result of the business service request, so as to realize the normal business function of the target business service and ensure the normal operation of online business processing. In other words, by adjusting the activation and deactivation of different business service brake switches, it is possible to ensure rapid response to changes in business service behavior. It can quickly switch between two modes: "accepting requests and performing business logic normally" and "accepting requests but not performing business logic and returning a fixed exception." This effectively ensures the real-time performance and availability of the interaction link, effectively avoids direct modification of backend configuration files and database tables, reduces the risk of human error, and while ensuring the normal operation of the original business functions, it can also verify abnormal scenarios through the combination of brake switches of various business services, thereby effectively improving the processing efficiency of the business system.

[0061] In one embodiment, before receiving a service request including interaction link information, the method further includes:

[0062] In response to the triggering operation of the first control in the management interface of the brake switch, the business service for which the braking function has been created is displayed;

[0063] In response to the first service selection operation, the business service corresponding to the first service selection operation is deleted from the management interface.

[0064] The brake switch management interface refers to the interface used to manage the brake switches of various backend business services. This interface can contain different types of controls. For example... Figure 3 The diagram shown is a schematic of the management interface for the backend service brake switch. In this application, the management interface for the brake switch can be as follows: Figure 3 As shown, that is, in such Figure 3 The management interface for the brake switch shown can include controls for querying business services, deleting business services, and adding new business services.

[0065] The first control refers to the control included in the brake switch management interface for deleting business services that have created braking functions. For example, the first control can be displayed in the brake switch management interface in the form of a button.

[0066] The first service selection operation refers to the user-triggered operation to select a service. Users can filter the services with created braking functions displayed in the braking switch management interface to select the target service identifier. This identifier can be an icon, text, or a combination of both. For example... Figure 3 The image shown is a schematic diagram of the management interface for the backend service braking switch. The target business service identifier can be as follows: Figure 3 The “Transaction Risk Management Service” text label shown is used to identify the specific name of the target business service.

[0067] Specifically, in the case of a deployed business system, before the business system receives a service request including interaction link information from the terminal, users can interactively configure the braking functions of various backend business services to construct different abnormal call scenarios. For example, users can access the management interface of the backend service braking switch through a trigger operation. Furthermore, users can interactively configure the braking functions of various backend business services within the displayed backend service braking switch management interface. For instance, in response to the user's trigger operation on the first control in the backend service braking switch management interface, the business system displays the business services with created braking functions. Furthermore, users can interactively select a business service from the displayed business services with created braking functions. In response to the user's service selection operation, the business system deletes the corresponding business service from the displayed management interface. That is, the braking function settings of each business service can be directly and visually managed through the management interface. The braking function is only used for online abnormal scenario verification. Therefore, under normal circumstances, the braking switch status of each business service with created braking functions should remain in the off state.

[0068] For example, let's take a business system like a transaction system as an example for illustration. Figure 3 The diagram shows the management interface for the braking switch of a backend service in a trading system. After developers release a gray-scale version of the trading system with new features, they can configure the braking function of various business services within that gray-scale version to construct the required verification scenarios. For example, administrator A with setting permissions logs in via a triggered operation... Figure 3 In the management interface A of the service brake switch corresponding to a certain grayscale version of the transaction system A shown, administrator A can further, based on the verification scenario to be constructed, in such a way... Figure 3 In the management interface A shown, clicking the "Delete" control (highlighted by the elliptical dashed box) will cause the trading system A to respond to the user's click on the "Delete" control in the management interface A by displaying the business services with created braking functions in a secondary pop-up window. Assume that the business services with created braking functions displayed in the secondary pop-up window include: Transaction Risk Management Service, Transaction Order Service, Transaction Execution Service, and Exposure Management Service. Further, assuming that the user selects the "Exposure Management Service" service from the displayed business services with created braking functions through interactive operation, the business system will respond to the user's service selection operation by deleting the "Exposure Management Service" service corresponding to the selected service from the displayed business services with created braking functions. This will result in a schematic diagram of the management interface after deleting the "Exposure Management Service". For example, as shown... Figure 4 The image shown is a schematic diagram of the management interface for the modified backend service brake switch. Figure 4 The module with braking function shown in the image does not include the "Opening Management Service".

[0069] In traditional development, during version iterations, to ensure online business operations, all modified functionalities need to be fully verified to guarantee 100% code coverage. When verifying various abnormal logic branches, it's often necessary to manually construct service or parameter exception scenarios to ensure the business system behaves as expected under abnormal conditions, thus guaranteeing system stability. However, some extreme exception scenarios cannot be triggered by normal business logic. Therefore, traditional methods require manually taking some normal business services offline or changing correct configuration parameters to incorrect ones. This necessitates manual configuration modification or service shutdown, and online operations still need to follow release specifications, requiring significant time for modification and deployment. Furthermore, during verification, complex business scenarios may require multiple configuration file modifications and service deployments, which is prone to errors or omissions, leading to a time-consuming configuration modification process.

[0070] In this embodiment, by building braking capabilities for each business service in the backend service and setting permission restrictions, it is possible to change the braking status of each business service during verification, thereby braking the normal business functions of the business services and constructing the required verification scenario. Furthermore, the braking function settings of each business service can be directly managed visually through the management interface, effectively avoiding direct modification of backend configuration files and database table data, reducing the risk of human error, and effectively improving the accuracy of abnormal scenario verification.

[0071] In one embodiment, before receiving a service request including interaction link information, the method further includes:

[0072] In response to the triggering operation of the second control in the management interface, display the business services for which the braking function has not been created;

[0073] In response to the second service selection operation, the business service corresponding to the second service selection operation is added to the management interface.

[0074] The second control refers to the braking function control included in the brake switch management interface for adding new business services. For example, the second control can be displayed in the brake switch management interface as a button. It is understood that the first and second controls in this application are merely controls used to distinguish different functions.

[0075] The second service selection operation refers to the user-triggered operation for selecting a service. Specifically, the user can filter among the service providers without a braking function displayed in the brake switch's management interface to select the target service identifier corresponding to the desired service. It is understood that the first and second service selection operations in this application are merely used to distinguish service selection operations in different processes.

[0076] Specifically, in the case of a deployed business system, before the business system receives a service request from the terminal including interaction link information, users can interactively configure the braking functions of various backend business services to construct different abnormal call scenarios. For example, users can access the management interface of the backend service braking switch through a trigger operation. Furthermore, users can interactively configure the braking functions of various backend business services within the displayed backend service braking switch management interface. For instance, in response to the user's trigger operation on the second control in the backend service braking switch management interface, the business system displays business services for which braking functions have not been created. Further, users can interactively select a business service from the displayed services without braking functions. The business system, in response to the user's service selection operation, adds the corresponding business service to the management interface to complete the configuration of the braking function for that business service.

[0077] For example, let's take a business system like a transaction system as an example for illustration. Figure 3 The diagram shows the management interface for the braking switch of a backend service in a trading system. After developers release a gray-scale version of the trading system with new features, they can configure the braking functions for various business services within that gray-scale version to create the necessary verification scenarios. For example, administrator A with configuration permissions logs in via a triggered operation... Figure 3 In the management interface A of the service brake switch corresponding to a certain grayscale version of the transaction system A shown, administrator A can further, based on the verification scenario to be constructed, in such a way... Figure 3 In the management interface A shown, clicking the "Add" control (highlighted within the dashed rectangle) will cause the trading system A to respond to the user's click on the "Add" control in the management interface A by displaying the business services for which no braking function has been created in a secondary pop-up window. Assume that the business services for which no braking function has been created displayed in the secondary pop-up window include: Transaction Risk Management Service, Transaction Order Service, Transaction Execution Service, and Exposure Management Service. Furthermore, assuming that the user selects the "Transaction Risk Management Service" from the displayed business services for which no braking function has been created through interactive operation, the trading system will respond to the user's service selection operation by adding the "Transaction Risk Management Service" corresponding to that service selection to the management interface A. Figure 3 The management interface shown allows you to configure the braking function of the "Transaction Risk Management Service," for example... Figure 4 The image shown is a schematic diagram of the management interface for the modified backend service brake switch. Figure 4The module with braking functionality shown in the example includes the "Transaction Risk Management Service." This allows for direct, visual management of braking settings across various business services through the management interface, avoiding the need for developers to manually modify backend configuration files and database tables as in traditional methods, thus reducing the risk of human error.

[0078] In one embodiment, before receiving a service request including interaction link information, the method further includes:

[0079] In response to the modification operation in the brake switch management interface, the brake switch status of the business service corresponding to the modification operation is changed.

[0080] Store the changed brake switch status in the database;

[0081] The changed brake switch status is displayed in the management interface.

[0082] Here, "modification operation" refers to an operation triggered by a user to modify the state of a service's control switch. For example, in this application, the modification operation could be a click operation, meaning the user can click on a button to change the status of a service's control switch. Figure 3 The brake switch management interface shown allows users to modify the brake switch status of business services by clicking the control in the "Brake Status" column.

[0083] Specifically, in the case of a deployed business system, before the business system receives a service request including interaction link information from the terminal, users can modify the braking switch status of each business service with braking functionality created through interactive operations to construct different abnormal call scenarios. For example, users can access the backend service braking switch management interface through a trigger operation. Furthermore, users can modify the braking switch status of each backend business service through interactive operations within the displayed backend service braking switch management interface. For instance, in response to a user's trigger operation on the braking switch status of a certain business service in the backend service braking switch management interface, the business system changes the braking switch status of the business service corresponding to that trigger operation. Further, the business system can store the changed braking switch status in a database and display the changed braking switch status in the backend service braking switch management interface.

[0084] For example, let's take a business system like a transaction system as an example for illustration. Figure 3The diagram shows the management interface for the braking switch of a backend service in a trading system. After developers release a gray-scale version of the trading system with new features, they can modify the braking switch status of various business services with braking functionality already implemented in that gray-scale version to create different abnormal call scenarios. For example, administrator A with setting permissions logs in via a triggered operation... Figure 3 In the management interface A of the service brake switch corresponding to a certain grayscale version of the transaction system A shown, administrator A can further, based on the verification scenario to be constructed, in such a way... Figure 3 In the management interface A shown, clicking the "Enable" control for the braking status of "Transaction Execution Service" (number 3) in the management interface A will cause the trading system A to respond to this click by changing the braking switch status of the "Transaction Execution Service" service to "Closed". Furthermore, the trading system A can store this changed braking switch status (closed) in a database and display it in the backend service braking switch management interface, for example, as shown. Figure 4 The image shown is a schematic diagram of the management interface for the modified backend service brake switch. Figure 4 The module with braking functionality shown in the image includes a "Transaction Execution Service," and... Figure 4 The braking switch for service number 3, "Transaction Execution Service," is displayed as "Off." This allows for direct visual management of the braking functions of various business services through the management interface, avoiding the need for developers to manually modify backend configuration files and database tables as in traditional methods, thus reducing the risk of human error.

[0085] In one embodiment, the method further includes:

[0086] Based on the changed brake switch status, generate the first alarm message;

[0087] The first alarm message is sent to the management device to indicate that the brake switch status has changed.

[0088] The first alarm information refers to information used to indicate a change in the status of the brake switch. For example, the first alarm information in this application can be sent to the management device used by the administrator in the form of a notification message to inform the administrator that the status of the brake switch for the business service has changed.

[0089] Specifically, in the case of a deployed business system, before the business system receives a service request including interaction link information from the terminal, users can modify the braking switch status of each business service with a braking function through interactive operations to construct different abnormal call scenarios. For example, users can access the management interface of the backend service braking switch through a trigger operation. Furthermore, users can modify the braking switch status of each backend business service through interactive operations in the displayed backend service braking switch management interface. For instance, in response to the user's trigger operation on the braking switch status of a certain business service in the backend service braking switch management interface, the business system changes the braking switch status of the business service corresponding to the trigger operation. Furthermore, the business system can generate a first alarm message based on the changed braking switch status of the business service and send the first alarm message to the management device to prompt the administrator using the management device to promptly obtain relevant information that the braking switch status has changed. This allows for the restriction of permissions to modify the braking function of each business service, ensuring that the braking status of each business service module can be changed during verification. This brakes the normal business functions of the business service modules to construct the abnormal scenarios required for verification. Furthermore, by automatically triggering alarm information, malicious tampering can be prevented, ensuring the rapid response of the original business functions and minimizing the impact of introducing the braking function on business time consumption.

[0090] In one embodiment, the step of storing the changed brake switch state in the database includes:

[0091] Call the operation and maintenance management service so that the operation and maintenance management service updates the brake switch status in the brake switch database table based on the changed brake switch status.

[0092] Among them, operation and maintenance management service refers to one of the services in the business system. For example, the operation and maintenance management service in this application is used to manage and update data in various tables in the database.

[0093] The brake switch database table refers to a database table used to store the status of brake switches. For example, the brake switch database table can be preset to 001. Multiple database tables can be created in the database to facilitate the search of different types of data.

[0094] Specifically, in the case of a deployed business system, before the business system receives a service request including interaction link information from the terminal, users can modify the braking switch status of each business service with braking functionality through interactive operations to construct different abnormal call scenarios. For example, users can access the backend service braking switch management interface through a trigger operation. Furthermore, users can modify the braking switch status of each backend business service through interactive operations in the displayed backend service braking switch management interface. For instance, the frontend of the business system responds to the user's trigger operation on the braking switch status of a certain business service in the backend service braking switch management interface and changes the braking switch status of the business service corresponding to the trigger operation. Furthermore, the business system can call the backend operation and maintenance management service so that the operation and maintenance management service updates the braking switch status of a certain business service in the braking switch database table based on the changed braking switch status in the frontend management interface.

[0095] For example, let's take a transaction system as an example. In a transaction system A that has already been released in a gray-scale version, before transaction system A receives a business service request from a terminal containing interaction link information, users can modify the braking switch status of various business services that have already created braking functions through interactive operations, thereby constructing different abnormal call scenarios. For example... Figure 5 The diagram shown illustrates the braking switch change operation of a certain trading system. Figure 5 The processing flow shown is a schematic diagram of the interaction between the front end and the back end of the trading system. That is, the back end operation and maintenance management service updates the data in the database table used to store the brake switch status based on the user's change operation on the brake switch status recorded by the front end.

[0096] For example, administrator A, who has setting permissions, logs in by triggering an action such as... Figure 3 In the management interface A of the service brake switch corresponding to a certain grayscale version of the transaction system A shown, administrator A can further, based on the verification scenario to be constructed, in such a way... Figure 3In the management interface A (web frontend), clicking the "Enable" control for the braking status of "Transaction Execution Service" (number 3) triggers a change in the braking status of the "Transaction Execution Service" service. The frontend responds to this click by updating the braking status of the service to "Closed." Furthermore, the frontend calls the backend operation and maintenance management service to update the braking status of the "Transaction Execution Service" service in the braking switch table 001 of the database to "Closed." This allows for the visual management of adding, modifying, and querying the braking capabilities of various business service modules within the business system. Modifications to the braking status can be made via buttons on the frontend, avoiding direct modification of backend configuration files and database tables. This reduces the risk of human error and effectively improves the accuracy of abnormal scenario verification.

[0097] In one embodiment, after changing the state of the brake switch for the business service corresponding to the modification operation in response to a modification operation in the management interface of the brake switch, the method further includes:

[0098] Send a notification message to the first filter of the business service corresponding to the modification operation, so that the first filter updates the brake switch state in the memory data; or...

[0099] Based on a preset scheduled task, the braking switch status of the business service is periodically retrieved from the database; when it is determined that the braking switch status has changed, the braking switch status in the memory data is updated through the second filter; the second filter is the filter for the business service corresponding to the changed braking switch status.

[0100] In this embodiment, the first filter refers to the filter of the business service corresponding to the modification operation, and the second filter refers to the filter of the business service corresponding to the changed brake switch state. That is, in this embodiment, each business service corresponds to a filter. For example, the filter corresponding to service A is filter A, and the filter corresponding to service B is filter B. When it is determined that the brake switch state of service A in the database has changed, the brake switch state in the memory data is updated through filter A of service A. Filter A is the second filter.

[0101] Specifically, in the case of a deployed business system, before the business system receives a service request including interaction link information from the terminal, users can modify the braking switch status of each business service with a braking function created through interactive operations to construct different abnormal call scenarios. For example, users can access the backend service braking switch management interface through a trigger operation. Furthermore, users can modify the braking switch status of each backend business service through interactive operations in the displayed backend service braking switch management interface. For instance, in response to a user's trigger operation on the braking switch status of business service A in the backend service braking switch management interface, after the business system changes the braking switch status of business service A corresponding to the trigger operation, the business system can send a notification message to filter A of business service A corresponding to the modification operation, so that filter A can synchronously update the braking switch status in the memory data.

[0102] Alternatively, the business system can periodically retrieve the braking switch status of each business service from the database based on a preset scheduled task. For example, when the business system determines that the braking switch status of business service A has changed, the business system can update the braking switch status in the memory data through a second filter, i.e., filter A for business service A. In other words, this application can synchronously update the braking switch status of changed business services in the database to the memory data in different ways, thereby achieving the acquisition of the braking status of each business service by reading the memory data, effectively avoiding time-consuming operations such as reading the database.

[0103] For example, let's take a transaction system as an example. For instance, administrator A, who has setting permissions, logs in to a system like this by triggering an action. Figure 3 In the management interface A of the service brake switch corresponding to a certain grayscale version of the transaction system A shown, administrator A can further, based on the verification scenario to be constructed, in such a way... Figure 3When the user clicks the "Enable" control for the "Trade Execution Service" (number 3) in the management interface A (web frontend), the frontend of trading system A responds to this click by updating the braking switch status of the "Trade Execution Service" to "Closed". Furthermore, trading system A can send a notification message to the filter A of the "Trade Execution Service" corresponding to this click, causing filter A to synchronously update the braking switch status in its memory data to "Closed". This ensures that when the "Trade Execution Service" is subsequently invoked, filter A can directly read the "Closed" braking switch status from the memory data.

[0104] like Figure 6 The diagram shown illustrates the memory data update process of the brake switch in a certain trading system. Figure 6 The processing flow shown involves periodically reading data reflecting the brake switch status from the database using a scheduled task. For example, the data reflecting the brake switch status in this application can be a brake switch value. For instance, a brake switch value of 1 indicates that the brake switch is in a closed state, and a brake switch value of 0 indicates that the brake switch is in an open state. That is, in the case of a trading system A that has already released a gray-scale version, trading system A can, based on a preset scheduled task (assuming the period of the scheduled task is every 1 second), periodically read the brake switch values ​​of each business service in the database every 1 second and determine whether the brake switch values ​​of each business service have changed, i.e., whether the brake switch values ​​of each business service have been updated. If so, trading system A can synchronously update the brake switch values ​​in the memory data through a second filter.

[0105] In this embodiment, the braking switch status of the business services that have changed in the database is synchronously updated to the memory data in different ways. This allows the braking status of each business service to be obtained by reading the memory data, effectively avoiding time-consuming operations such as reading the database, and thus effectively improving the processing efficiency of the business system.

[0106] In one embodiment, the method further includes:

[0107] If an exception occurs while retrieving the brake switch status of a business service from the database, the brake switch status in the memory data will be set to the off state through the filter of the business service.

[0108] In this application, the abnormalities that may occur during the process of reading the braking switch status of the business service from the database include, but are not limited to: failure to read data from the database, error in reading data, database abnormality, and other abnormal situations.

[0109] Specifically, let's take a business system, specifically a transaction system, as an example for explanation. Figure 6 The diagram shown illustrates the memory data update process of the brake switch in a certain trading system. Figure 6 The processing flow shown involves periodically reading data reflecting the brake switch status from the database using a scheduled task. For example, in the case of a trading system A that has already released a gray-scale version, trading system A can, based on a preset scheduled task, periodically read the brake switch values ​​of each business service from the database every 10 seconds and determine whether the brake switch values ​​of each business service have changed, i.e., whether the brake switch values ​​of each business service have been updated. If so, trading system A can synchronously update the brake switch values ​​in the memory data through a second filter. Figure 6 As shown, if an anomaly occurs during the periodic reading of the braking switch status of business service A from the database based on a preset scheduled task—for example, if an anomaly occurs while reading the database—trading system A can use filter A of business service A to set the braking switch status of that business service A in the memory data to the off state. For instance, trading system A can use filter A of business service A to set the braking switch value of that business service A in the memory data to 1, meaning that when the braking switch value is 1, the braking switch status is off. This ensures that if other unknown or abnormal states occur during data processing in the business system, the business system can automatically disable the braking function of the business service to ensure the normal operation of the original business functions in the business system, thus guaranteeing the real-time performance and availability of the transaction chain within the trading system.

[0110] In one embodiment, the business system is a grayscale version of the business system; the method further includes:

[0111] Once the verification of abnormal business scenarios is completed based on the error response, the gray-scale version of the business system will be fully released.

[0112] In this context, a gray-scale version of a business system refers to a version of a business system that is released in a gray-scale manner. For example, if business service A in the A1.1 version of the business system is optimized and the A1.2 version of the business system is released in a gray-scale manner, then the A1.2 version of the business system is the gray-scale version of the business system. In other words, during the rapid iteration of service versions, gray-scale versions and official versions can coexist. The gray-scale version is gradually rolled out to upgrade to the official version. In this way, the service does not need to be shut down for a period of time during the service update process, and the transition process between different versions can be monitored. If a problem is found in the gray-scale version, it can be quickly rolled back to the original official version.

[0113] Abnormal business scenarios refer to constructing different abnormal call scenarios by setting different braking switch states for each business service. That is, the abnormal business scenarios in this application can include abnormal call scenarios, and the call abnormality corresponds to the business abnormality.

[0114] Full release refers to releasing a system to all users at once. For example, in the iterative development of a business system version, in order to ensure the operation of online business, this application can first adopt a canary release method. Once the canary release version A of the business system passes verification, the canary release version A of the business system can be released as the official version for full release.

[0115] Specifically, in the case of a business system that has already released a gray-scale version, this gray-scale version of the business system can receive business service requests that include interaction link information. When the gray-scale version of the business system sequentially calls the relevant target business services based on the interaction link information, it can read the braking switch status of the target business service through the filter of the target business service. When the braking switch status is active, the gray-scale version of the business system can intercept the business service request through the filter and return an error response based on the intercepted business service request. Furthermore, the gray-scale version of the business system can verify abnormal business scenarios based on the returned error response. For example, the gray-scale version of the business system can compare the parameter values ​​carried in the returned error response with preset parameter values, obtain the comparison result, and determine whether the verification of the abnormal business scenario passes based on the comparison result. If the gray-scale version of the business system completes the verification of the abnormal business scenario based on the error response, then the gray-scale version of the business system is fully released and launched, that is, the gray-scale version of the business system is fully released and launched as the official version, so that all users can use the official version of the business system. Therefore, by providing braking capabilities to each backend service, the braked modules implement the braking function through filter configuration. While processing upstream requests normally, each backend service can return a specified response, achieving the advantages of non-intrusion into core business logic and easy scalability. Simultaneously, a fixed pattern for combining braking switches of various modules can be implemented, reducing the complexity of the verification process, eliminating barriers caused by varying levels of business understanding among developers, improving development quality, and effectively reducing testing costs before full release.

[0116] In one embodiment, the braking switch states of the first service and the second service in the business system are different; the method further includes:

[0117] Based on the braking switch status of the first service and the braking switch status of the second service, automated test cases are generated and executed to obtain service response results.

[0118] When the verification of the abnormal business scenario is completed based on the error response, the gray-scale version of the business system is fully released, including:

[0119] When the verification of abnormal business scenarios is completed based on the business response results, the gray-scale version of the business system will be fully released; the business response results are determined based on the error responses returned by the target business services involved in the call.

[0120] The first business service and the second business service are used to distinguish different business services. For example, the first business service is "transaction order service" and the second business service is "transaction execution service". The brake switch states of the first business service and the second business service are different, including: the brake switch state of "transaction order service" is closed and the brake switch state of "transaction execution service" is open; or the brake switch state of "transaction order service" is open and the brake switch state of "transaction execution service" is closed.

[0121] A test case is a description of a testing task for a specific software product, reflecting the test plan, methods, techniques, and strategies. Its content includes test objectives, test environment, input data, test steps, expected results, and test scripts, ultimately forming a document. In essence, a test case is a set of test inputs, execution conditions, and expected results compiled for a specific goal to verify whether a particular software requirement is met. For example, a test case can contain four elements: test case title, preconditions, test steps, and expected results. The test case title primarily describes the function being tested; the preconditions are the conditions that the test case title requires to be met; the test steps primarily describe the operational steps of the test case; and the expected results refer to whether the test case meets the expected requirements (development specifications, requirements documents, user requirements, etc.).

[0122] The business response result refers to the actual execution result obtained from executing automated test cases. For example, an automated test case may include the following execution steps: calling service A to process business request A. During the process of service A processing business request A, service A needs to call service B. Suppose that the administrator has set the brake switch of service B to the on state to construct an abnormal scenario for calling service B. Therefore, during the process of service A processing business request A, when service A calls service B, it will return an error response. Based on the error response returned by calling service B, service A obtains the corresponding business execution result as a failure response. This failure response result is the business response result obtained from executing the automated test case.

[0123] Specifically, in the case of a business system that has already released a gray-scale version, since this gray-scale version of the business system includes different types of business services, different abnormal call scenarios can be constructed by combining the braking switch states of each business service. For example, if the braking switch states of the first business service and the second business service in the business system are different (combining braking switch states), the business system can generate automated test cases based on the braking switch states of the first and second business services, execute the automated test cases, and obtain the business response result. This business response result is the actual execution result obtained from the execution of the automated test cases. Furthermore, the business system can determine whether the verification of abnormal business scenarios has been completed based on the actual business response result obtained from executing the automated test cases. For example, suppose the business system executes the automated test case and receives a failed response. If this failed response matches the expected execution result of the test case, the business system can determine that the verification of the abnormal business scenario has been completed based on the failed response. If the business system executes the automated test case and receives a successful response, but this successful response does not match the expected execution result of the test case, the business system can determine that the verification of the abnormal business scenario has not been completed based on the successful response. Furthermore, when the business system completes the verification of the abnormal business scenario based on the actual business response obtained from executing the automated test case, the business system can release the gray-scale version of the business system to the full deployment.

[0124] For example, let's take a business system like a transaction system as an example for illustration. Figure 7 The diagram shown is an overall schematic of the transaction process after the introduction of the braking function. Figure 7 The flowchart shown is a schematic diagram of the processing flow for a specific transaction order after the introduction of the braking function. Figure 7 In a trading system, the target business services involved in processing a single trading order include, but are not limited to, trading order service, trading execution service, trading engine, trading risk control service, and exposure management service. Users can combine the on / off states of these various business services through the front-end management interface to construct different abnormal call scenarios. For example, in a released gray-scale version of the trading system, if the on / off states of the first business service and the second business service are different (combining on / off state combinations), assuming the first business service's on / off state is "on" and the second business service's on / off state is "off," then the first business service... Figure 7 The second business service is the "Transaction Execution Service". Figure 7 The "transaction order service" in the text refers to... Figure 7The trading system shown responds to user modification operations in the brake switch management interface by setting the brake switch state of the corresponding "Trade Execution Service" to the "On" state and the brake switch state of the "Trade Order Service" to the "Off" state, and storing the changed brake switch states in the database. Furthermore, the trading system can generate automated test case A based on the brake switch states (On) of the "Trade Execution Service" and (Off) of the "Trade Order Service." Assume that automated test case A includes the following execution steps: When the trading system receives a trade order request, the trading system calls... Figure 7 The "Transaction Order Service" shown here processes transaction orders, such as... Figure 7 As shown, during the processing of transaction orders by the "Transaction Order Service," it needs to call the "Transaction Execution Service." Since the administrator has set the "Transaction Execution Service" to the "on" state to create an abnormal call scenario, when the "Transaction Order Service" calls the "Transaction Execution Service," it will return an error response. Based on the error response returned by the "Transaction Execution Service," the "Transaction Order Service" obtains a failure response, which is the business response result obtained from executing the automated test case. In other words, after the transaction system automatically executes the automated test case A, the resulting business response is a failure. Since this failure response matches the expected response, the transaction system determines that it has completed the verification of the abnormal business scenario based on this failure response. That is, when the transaction system has successfully verified the abnormal business scenario based on the actual business response result (failure response) obtained from executing the automated test case, it can release the gray-scale version of the transaction system to the full release. In other words, the transaction system releases this gray-scale version of the business system as the official version, allowing all users to use the official version. Thus, by providing braking capabilities to the backend services, the braked modules implement the braking function through configured filters. Under normal circumstances, the backend services can return specified responses, achieving the advantages of non-intrusion into core business logic and easy expansion. Simultaneously, a fixed pattern for the combined use of braking switches for various modules can be implemented, reducing the complexity of the verification process, eliminating barriers caused by different levels of business understanding among developers, improving development quality, and effectively reducing testing costs before full release.

[0125] In one embodiment, the interaction link information includes a first business service and a second business service; when sequentially invoking the business services involved in resource interaction based on the interaction link information, the step of reading the braking switch state of the business service through the filter of the business service includes:

[0126] When calling the first business service involved in resource interaction based on the interaction link information, the braking switch status of the first business service is read through the filter of the first business service.

[0127] When calling the second business service involved in resource interaction based on the interaction link information, the braking switch status of the second business service is read through the filter of the second business service.

[0128] Specifically, in the case of a business system that has already released a grayscale version, the grayscale version of the business system can receive business service requests that include interaction link information. When the grayscale version of the business system sequentially calls the target business services involved based on the interaction link information, the grayscale version of the business system can read the braking switch status of the target business services through the filter of the target business services. That is, when the grayscale version of the business system calls the first business service involved in the resource interaction based on the interaction link information, the grayscale version of the business system reads the braking switch status of the first business service through the filter of the first business service; similarly, when the grayscale version of the business system calls the second business service involved in the resource interaction based on the interaction link information, the grayscale version of the business system reads the braking switch status of the second business service through the filter of the second business service.

[0129] For example, let's take a business system like a transaction system as an example for illustration. Figure 7 The diagram shown is an overall schematic of the transaction process after the introduction of the braking function. Figure 7 The flowchart shown is a schematic diagram of the processing flow for a specific transaction order after the introduction of the braking function. Figure 7 In a trading system, the target business services involved in processing a trading order include, but are not limited to, trading order service, trading execution service, trading engine, trading risk control service, and exposure management service. Users can combine the on / off states of these various business services through the front-end management interface to construct different abnormal call scenarios. For example, in... Figure 7 The grayscale version of the trading system shown below, such as Figure 7The transaction system shown responds to user modification operations in the brake switch management interface by setting the brake switch status of the corresponding "Transaction Execution Service" to the "On" state and the brake switch status of the "Transaction Order Service" to the "Off" state, and stores the changed brake switch statuses in the database. Furthermore, this grayscale version of the transaction system can receive transaction order requests including interaction link information. When the grayscale version of the transaction system sequentially calls the relevant target business services based on the interaction link information, it can read the brake switch status of the target business service through the target business service's filter. That is, when the grayscale version of the transaction system calls the "Transaction Order Service" involved in resource interaction based on the interaction link information, it reads the brake switch status of the target business service through the "Transaction Order Service" filter. Figure 7 The "Transaction Order Service Switch" shown is in the "Off" state. Furthermore, during the processing of transaction orders by the "Transaction Order Service," when the "Transaction Order Service" calls the "Transaction Execution Service," this grayscale version of the transaction system reads data through the "Transaction Execution Service's" filter, such as... Figure 7 The status of the "Transaction Execution Service Switch" shown is: On.

[0130] In this embodiment, the braking switch for each business service is configured individually, enabling fine-grained management of each business service in the interaction chain. Furthermore, by combining the braking switches of each business service, complex business scenarios can be quickly constructed. For example, when verifying abnormal scenarios online for a released gray-scale version of the business system, different abnormal call scenarios can be constructed for multiple target business services in the interaction chain. This reduces the complexity of the verification process, eliminates barriers caused by developers' varying levels of understanding of the business, improves development quality, and effectively reduces testing costs before full release.

[0131] In one embodiment, the method further includes:

[0132] The parameter values ​​carried in the error response are compared with the preset parameter values ​​to obtain the comparison result;

[0133] When the verification of the abnormal business scenario is completed based on the error response, the gray-scale version of the business system is fully released, including:

[0134] When the comparison result indicates that the parameter value is consistent with the preset parameter value, the grayscale version of the business system will be fully released.

[0135] In this context, "parameter value is the same as preset parameter value" means that the parameter value is identical to the preset parameter value. For example, if the parameter value carried in the error response is 001 and the preset parameter value is also 001, then the parameter value 001 carried in the error response is the same as the preset parameter value 001.

[0136] Specifically, in the case of a business system that has already released a gray-scale version, this gray-scale version of the business system can receive business service requests that include interaction link information. When the gray-scale version of the business system sequentially calls the relevant target business services based on the interaction link information, it can read the braking switch status of the target business service through the filter of the target business service. When the braking switch status is in the activated state, the gray-scale version of the business system can intercept the business service request through the filter and return an error response based on the intercepted business service request. Furthermore, the gray-scale version of the business system can verify abnormal business scenarios based on the returned error response. That is, the gray-scale version of the business system can compare the parameter value 001 carried in the returned error response with the preset parameter value 001, obtain the comparison result, and determine whether the verification of the abnormal business scenario has passed based on the comparison result. For example, when the comparison result indicates that the parameter value 001 is consistent with the preset parameter value 001, the verification of the abnormal business scenario has passed, and the business system can release the gray-scale version of the business system as the official version for full release.

[0137] Furthermore, if the comparison result indicates that parameter value 021 is inconsistent (different) with the preset parameter value 001, it means that the verification of the abnormal business scenario has failed (not completed). In this case, the business system will not release this gray-scale version of the business system as the official version. Therefore, by providing braking capabilities to each backend service, the braked service modules implement the braking function through filter configuration, ensuring that each backend service returns a specified response when normally accepting upstream requests. This achieves the advantages of non-intrusion into core business logic and easy expansion. Simultaneously, a fixed mode for combining braking switches of various backend service modules can be implemented, reducing the complexity of the verification process, eliminating barriers caused by different levels of business understanding among developers, and maintaining automated test cases for a fixed verification process as a checkpoint before version iteration and release, thereby improving development quality and reducing testing costs.

[0138] In one embodiment, the interaction link information includes the service name of the target service; the step of reading the brake switch status of the service through the service service's filter includes:

[0139] When the target business service is invoked, the brake switch status corresponding to the service name is queried in the memory data through the filter of the target business service.

[0140] The method further includes: when the brake switch of the target service is in the on state and the time in the on state exceeds a preset time threshold, outputting a second alarm message.

[0141] The service name refers to the name of the target business service. For example, if the target business service is "Transaction Order Service", then the service name of the "Transaction Order Service" is "Transaction Order".

[0142] Specifically, such as Figure 8 The diagram shown illustrates the process of reading the brake switch status from memory data. Figure 8 The processing flow shown, in the case of a published business system, after receiving a business service request including interaction link information, the business system can sequentially call the relevant target business services based on the interaction link information. During this process, the business system can read the braking / switching status of the target business service through its filter. For example, when target business service A is called, the business system queries the memory data for the braking / switching status corresponding to the service name of target business service A through filter A. Figure 8 As shown, when the brake switch of this service is in the enabled state, the business system intercepts the business service request through filter A and returns an error response; when the brake switch of this service is in the disabled state, the business system responds to the business service request according to the normal business logic of the target business service A and returns the corresponding response result; furthermore, when the brake switch of the target business service A is in the enabled state and the time in the enabled state exceeds a preset time threshold, the business system outputs a second alarm message. For example, the second alarm message is used to remind the administrator that the brake switch of a certain backend service has been in the enabled state for too long, which may indicate an anomaly and requires manual maintenance of the brake switch status of the backend service.

[0143] For example, let's take a business system like a transaction system as an example for illustration. Figure 7 The diagram shown is an overall schematic of the transaction process after the introduction of the braking function. Figure 7 The flowchart shown is a schematic diagram of the processing flow for a specific transaction order after the introduction of the braking function. Figure 7 In a trading system, the target business services involved in processing a trading order include, but are not limited to, trading order service, trading execution service, trading engine, trading risk control service, and exposure management service. Users can combine the on / off states of these various business services through the front-end management interface to construct different abnormal call scenarios. For example, in... Figure 7 The grayscale version of the trading system shown below, such as Figure 7 The transaction system shown responds to user modification operations in the brake switch management interface by setting the brake switch status of the corresponding "Transaction Execution Service" to the "On" state and the brake switch status of the "Transaction Order Service" to the "Off" state, and stores the changed brake switch statuses in the database. Furthermore, this grayscale version of the transaction system can receive transaction order requests including interaction link information. When this grayscale version of the transaction system sequentially calls the relevant target business services based on the interaction link information, it can read the brake switch status of the target business service through the target business service's filter. For example, when this grayscale version of the transaction system calls, for example, ... Figure 7 When referring to the "Trade Execution Service" shown, this grayscale version of the trading system can use the "Trade Execution Service" filter to query the memory data for the brake switch status corresponding to the service name of the "Trade Execution Service" and find it to be in the "On" state; furthermore, as... Figure 6 The diagram shown illustrates the memory data update process of the brake switch in a certain trading system. Figure 6 The processing flow shown involves periodically retrieving data reflecting the brake switch status from the database using a scheduled task. Assuming that when the grayscale version of the trading system detects, based on the scheduled task, that the brake switch status of the "Trade Execution Service" is in the "on" state, and the time spent in the "on" state exceeds a preset time threshold (30 minutes), the grayscale version of the trading system will automatically output a second alarm message to prompt the user that the "Trade Execution Service" brake switch status has been in the "on" state for too long, which may affect the normal operation of the trading system, and whether the user needs to manually change the "Trade Execution Service" brake switch status to the "off" state.

[0144] In this embodiment, the braking switch for each business service is configured individually, enabling fine-grained management of each business service in the interaction chain. Furthermore, by combining the braking switches of each business service, complex business scenarios can be quickly constructed. For example, when verifying abnormal scenarios online for a released gray-scale version of the business system, different abnormal call scenarios can be constructed for multiple target business services in the interaction chain. This reduces the complexity of the verification process, eliminates barriers caused by developers' varying levels of understanding of the business, improves development quality, and effectively reduces testing costs before full release.

[0145] This application also provides an application scenario in which the above-described business system processing method is applied. Specifically, the application of the business system processing method in this scenario is as follows:

[0146] In the iterative development of business system versions, to ensure online business operation, it is necessary to perform full verification of modified functionalities to guarantee 100% code coverage. When verifying various abnormal business scenarios in a canary release business system, the above-mentioned business system processing method can be adopted. For example, when a canary version of a business system has been released, the business system can receive business service requests, including interaction link information, sent by the terminal through the gateway. When the business system sequentially calls the relevant target business services based on the interaction link information, the business system can read the braking switch status of the target business service through the filter. When the braking switch status is in the activated state, the business system can intercept the business service request through the filter and return an error response based on the intercepted business service request to complete the verification of various abnormal business scenarios in the canary release business system. In addition, when the braking switch status is in the deactivated state, the business system can respond to the business service request according to the business logic of the target business service and return the corresponding response result to ensure that the original business functions in the business system still operate normally. This enables the rapid and effective verification of different abnormal business scenarios in the canary release business system while ensuring the normal operation of the online business system, thereby effectively improving the processing efficiency of the business system.

[0147] The method provided in this application can be applied to various business system usage scenarios. The following uses a foreign exchange trading system as an example to illustrate the business system processing method provided in this application.

[0148] Foreign exchange trading refers to the simultaneous purchase of one currency in a currency pair while selling the other, which can involve exchanging one country's currency for another. Unlike other financial markets, the foreign exchange market has no physical location or central exchange; instead, transactions are conducted through an electronic network between banks, businesses, and individuals.

[0149] A forex trading system is a system built to support traders or automated position closing in forex trading. It consists of multiple modules and related infrastructure. For example, modules in a forex trading system include: web front-end services, order services, order execution services, risk management services, trading engine services, and exposure management services. Infrastructure in a forex trading system includes: databases, message queues, etc.

[0150] Braking capability: Ensures the normal operation of this module and accepts requests from upstream services, but does not perform business logic processing within this module. Instead, it directly returns a specific error response, thereby interrupting the foreign exchange trading system call chain and stopping the normal trading process.

[0151] In traditional development, during version iterations, to ensure online business operations, all modified functionalities need to be fully verified to guarantee 100% code coverage. When dealing with various abnormal logic branches, it's often necessary to manually construct service or parameter exception scenarios to ensure the program behaves as expected under abnormal conditions, thus ensuring program robustness. Extreme exception scenarios often cannot be triggered by normal business logic. Traditional solutions involve manually taking some normal business services offline or changing correct configuration parameters to incorrect ones, causing all normal business processes to fail.

[0152] Disadvantages of traditional solutions:

[0153] (1) During the verification process, it is necessary to manually modify the configuration or take the service offline. Online operations must follow the release specification process, which wastes time.

[0154] (2) During the verification process, for complex business scenarios, it may be necessary to modify the configuration file and go online or offline the service multiple times, which may easily lead to errors or omissions in some operations.

[0155] (3) During the verification process, if the system configuration and business scenario are not well understood, and the parameters that need to be modified are not understood, there will be a barrier to the verification operation.

[0156] Therefore, to address the aforementioned issues, this application provides a method for improving the efficiency of foreign exchange trading system deployment based on module braking capabilities. This method enables the backend service to implement braking capabilities for various business functions. By restricting permissions, it ensures that the braking state of each module can be changed during verification, braking the normal business functions of the modules and constructing the required verification scenario. Key technical points include:

[0157] (1) The addition, modification and query of braking capacity switches of each module are managed visually through the interface, and there are restrictions on the permission to modify the configuration.

[0158] (2) The construction of braking capabilities of each module does not affect the operation of the module when braking is activated. It only filters and intercepts requests, does not execute the business logic of the module, and directly returns a special response.

[0159] (3) To ensure the normal operation of online business, the braking status of each module is monitored;

[0160] The method provided in this application mainly solves the following problems:

[0161] (1) By starting and stopping the brake switch, the module can quickly respond to changes in service business behavior and quickly switch between two modes: "accepting requests and performing business logic normally" and "accepting requests but not performing business logic and returning a fixed exception", saving time.

[0162] (2) The modification of the brake switch is carried out through the front-end interface via a button, which avoids direct modification of the back-end configuration file and database table data, and reduces the risk of human error.

[0163] (3) Each module’s brake switch is configured separately, enabling refined management of each module in the transaction chain. Furthermore, by combining the switches of each module, more complex business scenarios can be quickly constructed.

[0164] (4) For common verification scenarios, the combination of braking switches of each module is fixed. By accumulating and refining the combination mode and verification operation into an instruction guide, the complexity of verification is reduced. The process is maintained as an automated test case through code, which serves as a checkpoint for release and online, ensuring the quality and stability of system version iteration, while reducing manpower costs.

[0165] On the product side, such as Figure 3 The image shown is a schematic diagram of the management interface for the backend service braking switch. After a user opens the game application, the specific steps include:

[0166] (1) Provide a management interface for the brake switches of each backend service, and realize the functions of adding, deleting, querying the brake switch information of each module and modifying the brake switch status;

[0167] (2) The backend module selects whether to execute normal business logic based on the on / off state of the braking switch of this module. If the braking function is off, the service is provided normally; if the braking function is on, a fixed error response is returned (specific error codes and error messages indicate that the service is not interrupted because the braking switch is on).

[0168] On the technical side, when verifying abnormal scenarios online, the traditional approach requires constructing different abnormal call scenarios for multiple modules in the transaction chain. This necessitates modifying the environment configuration to construct the abnormal handling for each module, which is time-consuming and carries high risks associated with configuration modifications.

[0169] Therefore, this application proposes a scheme to set separate switches for each module, constructing different service acceptance anomaly scenarios for online verification, specifically including:

[0170] (1) Brake switch on / off: This function allows modification of the switches for each module; the modification process for the brake switch in the forex trading system is as follows: Figure 5 As shown;

[0171] Add switch maintenance functions;

[0172] b. Switch information is stored in a database table;

[0173] c. When the state of the brake switch changes, the foreign exchange trading system automatically sends an alarm message.

[0174] (2) Braking switch operation: Each module needs to determine whether to brake based on the state of the switch during operation; the transaction process after introducing the braking function is as follows: Figure 7 As shown;

[0175] How is the braking function integrated into each module?

[0176] Braking capability: The ability to intercept business functions, which is manifested by returning specific error responses.

[0177] For example, such as Figure 9 The diagram shows the flow of the brake switch in different states when the transaction execution service accepts a transaction order. Specifically, it illustrates the opening and closing state flow of the brake switch when the transaction execution service accepts a transaction order. Figure 9 As shown, in the foreign exchange trading system, when the "Trading Order Service" accepts a trading order, it needs to call the "Trading Execution Service" to perform the order acceptance function. When the "Trading Execution Service's" brake switch is in the off state, the "Trading Order Service" can normally call the "Trading Execution Service" to perform the order acceptance function and return a success response to the "Trading Order Service". When the "Trading Execution Service's" brake switch is in the on state, the "Trading Order Service" cannot perform the order acceptance function and will return a failure response to the "Trading Order Service".

[0178] like Figure 10 The diagram illustrates how service requests can be intercepted by configuring filters. In this embodiment, multiple service modules require the addition of read and brake switch capabilities, such as... Figure 10 The foreign exchange trading system shown can intercept service requests through configuration filters to perform targeted tasks, achieving non-intrusiveness to the core service and easy scalability. Furthermore, when entering the braking logic, if the braking switch is set to the on state, a failure response is returned directly, skipping the execution of the original business logic.

[0179] The specific execution logic of the braking function:

[0180] The braking function introduced into each module of the foreign exchange trading system in this application embodiment will affect the real-time trading link. In addition to the basic business functions, the real-time performance and availability of the trading link still need to be guaranteed.

[0181] Among them, real-time performance refers to ensuring the rapid response of the original business functions. After the module introduces the braking function, the impact on business time consumption is minimized. At the same time, the foreign exchange trading system reads the braking switch value by reading data from memory, avoiding time-consuming operations such as reading the database.

[0182] Availability: This refers to ensuring that the original business functions remain normal even if the module's braking function malfunctions; that is, in the method provided in this application embodiment, the foreign exchange trading system will only execute the braking logic when it is certain that the value of the module's braking switch is in the "on" state.

[0183] In addition, the foreign exchange trading system will automatically shut down the braking function in the event of any other unknown or abnormal conditions to ensure the normal operation of the original business functions.

[0184] Brake switch monitoring function:

[0185] The braking function is only used for online verification. Therefore, under normal circumstances, the braking switch value must be kept in the closed state. In this embodiment, the foreign exchange trading system introduces a braking switch monitoring function. The foreign exchange trading system needs to judge the braking status value in the memory of each module. When the braking switch value is in the open state for more than half an hour, the foreign exchange trading system will automatically trigger an alarm to prevent the braking switch from being accidentally activated and affecting the normal operation of online business.

[0186] In addition, in this embodiment of the application, the data reading of the brake switch can be done not only by reading the database through a timed task, but also by synchronizing the change of the brake switch state through event triggering. For example, when the user modifies the state of the brake switch, a notification message is automatically sent to the corresponding module to synchronize the switch state in the memory data.

[0187] The beneficial effects of the technical solution in this application include:

[0188] The braking switch management capability provided in this application embodiment changes the braking switch state through button controls on the interface, shielding complex backend business data and greatly reducing the risk of human error. Simultaneously, the technical solution of this application provides braking capabilities to various backend services. The braked module implements the braking function by configuring filters, returning a specified response when normally accepting upstream requests, achieving the advantages of non-intrusion into core business logic and easy expansion. Furthermore, the technical solution of this application can implement a fixed pattern for the combined use of braking switches for various modules, reducing the complexity of the verification process, eliminating barriers caused by varying levels of business understanding among developers, and maintaining automated test cases for a fixed verification process as a checkpoint before version iteration and deployment, effectively improving the development quality of business system version iterations and reducing testing costs.

[0189] It should be understood that although the steps in the flowcharts of the embodiments described above 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 embodiments described above 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.

[0190] Based on the same inventive concept, this application also provides a business system processing apparatus for implementing the business system 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 system processing apparatus embodiments provided below can be found in the limitations of the business system processing method described above, and will not be repeated here.

[0191] In one embodiment, such as Figure 11 As shown, a business system processing device is provided, including: a receiving module 1102, a reading module 1104, an interception module 1106, and a processing module 1108, wherein:

[0192] The receiving module 1102 is used to receive business service requests, including interaction link information, in the case of a published business system.

[0193] The reading module 1104 is used to read the brake switch status of the target business service through the filter of the target business service when the target business service is called sequentially based on the interaction link information.

[0194] The interception module 1106 is used to intercept business service requests through a filter when the brake switch is in the activated state, and return an error response based on the intercepted business service requests.

[0195] The processing module 1108 is used to process the business service request according to the business logic of the target business service when the brake switch is in the closed state, and return the response result corresponding to the business service request.

[0196] In one embodiment, the apparatus further includes a display module and a deletion module. The display module is configured to display the business service for which a braking function has been created in response to a trigger operation of the first control in the management interface of the brake switch. The deletion module is configured to delete the business service corresponding to the first service selection operation from the management interface in response to a first service selection operation.

[0197] In one embodiment, the apparatus further includes: an adding module, wherein the display module is further configured to display business services for which no braking function has been created in response to a trigger operation on the second control in the management interface; and an adding module configured to add the business service corresponding to the second service selection operation to the management interface in response to a second service selection operation.

[0198] In one embodiment, the device further includes: a modification module and a storage module. The modification module is used to modify the state of the brake switch of the business service corresponding to the modification operation in response to the modification operation in the management interface of the brake switch. The storage module is used to store the modified brake switch state in a database. The display module is also used to display the modified brake switch state in the management interface.

[0199] In one embodiment, the apparatus further includes a generation module and a sending module. The generation module is configured to generate a first alarm message based on the changed brake switch state. The sending module is configured to send the first alarm message to a management device to indicate that the brake switch state has changed.

[0200] In one embodiment, the apparatus further includes: a calling module, configured to call an operation and maintenance management service, so that the operation and maintenance management service updates the brake switch status in the brake switch database table based on the changed brake switch status.

[0201] In one embodiment, the apparatus further includes: an acquisition module and an update module; the sending module is further configured to send a notification message to a first filter of the business service corresponding to the modification operation, so that the first filter updates the brake switch state in the memory data; the acquisition module is configured to periodically acquire the brake switch state of the business service from the database based on a preset timed task; the update module is configured to update the brake switch state in the memory data through a second filter when it is determined that the brake switch state has changed; the second filter is a filter of the business service corresponding to the brake switch state that has changed.

[0202] In one embodiment, the apparatus further includes: a setting module, configured to, when an anomaly occurs during the process of reading the brake switch state of the business service from the database, set the brake switch state in the memory data to the off state through the filter of the business service.

[0203] In one embodiment, the business system is a gray-scale version of the business system; the apparatus further includes: a release module, used to release the gray-scale version of the business system in full when the verification of the abnormal business scenario is completed based on the error response.

[0204] In one embodiment, the braking switch states of the first business service and the second business service in the business system are different; the generation module is further configured to generate automated test cases based on the braking switch states of the first business service and the second business service, and execute the automated test cases to obtain business response results; the release module is further configured to fully release the grayscale version of the business system when the verification of the abnormal business scenario is completed based on the business response results; wherein, the business response results are determined based on the error responses returned by the target business services involved in the call.

[0205] In one embodiment, the apparatus further includes: a comparison module, configured to compare the parameter value carried in the error response with a preset parameter value to obtain a comparison result; and a release module, configured to release the grayscale version of the business system in full when the comparison result indicates that the parameter value is consistent with the preset parameter value.

[0206] In one embodiment, the interaction link information includes the service name of the target business service; the device further includes: a query module and an output module, the query module being used to query the brake switch status corresponding to the service name in memory data through the filter of the target business service when the target business service is invoked; the output module being used to output a second alarm message when the brake switch status of the target business service is in the on state and the time in the on state exceeds a preset time threshold.

[0207] Each module in the aforementioned business system processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0208] In one embodiment, a computer device is provided, which may be a terminal or a server. In this embodiment, the computer device is described as a server, and its internal structure diagram is as follows. Figure 12 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 operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data processed by the business system. 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 system processing method.

[0209] Those skilled in the art will understand that Figure 12 The 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.

[0210] In one embodiment, a computer device is 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-described method embodiments.

[0211] 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.

[0212] 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.

[0213] 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 the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0214] Those skilled in the art will understand that all or part of the processes in the methods of 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, and when executed, it can include the processes of the embodiments of the above methods. 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.

[0215] 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.

[0216] 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 system processing method, characterized in that, The method includes: In the case of a business system that has already released a gray-scale version, receive business service requests that include interaction link information; the interaction link information includes the call link between business services. When sequentially calling the target business services involved based on the interaction link information, the braking switch status of the target business service is read through the filter of the target business service; wherein, the braking switch of each target business service is configured separately, so that different abnormal calling scenarios can be constructed in the calling link by combining the braking switches of each target business service; the braking switch status is used to reflect whether the braking function of the target business service is enabled; When the brake switch is in the active state, the service request is intercepted by the filter, and an error response including a specific error code and error information identifier is returned based on the intercepted service request. When the brake switch is in the off state, the service request is processed according to the business logic of the target service, and the response result corresponding to the service request is returned.

2. The method according to claim 1, characterized in that, Before receiving the service request including interaction link information, the method further includes: In response to the triggering operation of the first control in the management interface of the brake switch, the business service for which the braking function has been created is displayed; In response to the first service selection operation, the business service corresponding to the first service selection operation is deleted from the management interface.

3. The method according to claim 2, characterized in that, Before receiving the service request including interaction link information, the method further includes: In response to the triggering operation of the second control in the management interface, the business service for which the braking function has not been created is displayed; In response to the second service selection operation, the business service corresponding to the second service selection operation is added to the management interface.

4. The method according to claim 1, characterized in that, Before receiving the service request including interaction link information, the method further includes: In response to a modification operation in the management interface of the brake switch, the brake switch status of the business service corresponding to the modification operation is changed. The modified brake switch status is stored in the database; The changed brake switch status is displayed in the management interface shown.

5. The method according to claim 4, characterized in that, The method further includes: Based on the changed brake switch state, a first alarm message is generated; The first alarm message is sent to the management device to indicate that the brake switch status has changed.

6. The method according to claim 4, characterized in that, The step of storing the modified brake switch state in the database includes: The operation and maintenance management service is invoked so that the operation and maintenance management service updates the brake switch status in the brake switch database table based on the changed brake switch status.

7. The method according to claim 4, characterized in that, After responding to a modification operation in the management interface of the brake switch and changing the state of the brake switch for the service corresponding to the modification operation, the method further includes: Send a notification message to the first filter of the business service corresponding to the modification operation, so that the first filter updates the brake switch state in the memory data; or... Based on a preset scheduled task, the braking switch status of the business service is periodically retrieved from the database; when it is determined that the braking switch status has changed, the braking switch status in the memory data is updated through a second filter; the second filter is a filter for the business service corresponding to the changed braking switch status.

8. The method according to claim 7, characterized in that, The method further includes: If an exception occurs during the process of reading the brake switch status of the business service from the database, the brake switch status in the memory data is set to the off state through the filter of the business service.

9. The method according to claim 1, characterized in that, The business system is a gray-scale version of the business system; the method further includes: When the verification of the abnormal business scenario is completed based on the error response, the gray-scale version of the business system will be fully released.

10. The method according to claim 9, characterized in that, The braking switch states of the first service and the second service in the business system are different; the method further includes: Based on the braking switch status of the first service and the braking switch status of the second service, automated test cases are generated and executed to obtain service response results. When the verification of the abnormal business scenario is completed based on the error response, the gray-scale version of the business system is fully released, including: When the verification of the abnormal business scenario is completed based on the business response result, the gray-scale version of the business system is fully released; wherein, the business response result is determined based on the error response returned by the target business service involved in the call.

11. The method according to claim 9, characterized in that, The method further includes: The parameter values ​​carried in the error response are compared with preset parameter values ​​to obtain a comparison result; When the verification of the abnormal business scenario is completed based on the error response, the gray-scale version of the business system is fully released, including: When the comparison result indicates that the parameter value is consistent with the preset parameter value, the grayscale version of the business system is fully released.

12. The method according to any one of claims 1 to 11, characterized in that, The interaction link information includes the service name of the target business service; The step of reading the brake switch status of the service through the filter of the service includes: When the target business service is invoked, the brake switch status corresponding to the service name is queried in the memory data through the filter of the target business service; The method further includes: when the brake switch of the target service is in the on state and the time in the on state exceeds a preset time threshold, outputting a second alarm message.

13. A business system processing apparatus, characterized in that, The device includes: The receiving module is used to receive business service requests, including interaction link information, in the case of a business system that has released a gray-scale version; the interaction link information includes the call link between business services. The reading module is used to read the braking switch status of the target business service through the filter of the target business service when the target business service is called sequentially based on the interaction link information; wherein, the braking switch of each target business service is configured separately, so that different abnormal call scenarios can be constructed in the call link by combining the braking switches of the target business services; the braking switch status is used to reflect whether the braking function of the target business service is enabled. The interception module is used to intercept the service request through the filter when the brake switch is in the activated state, and return an error response including a specific error code and error information identifier based on the intercepted service request. The processing module is used to process the business service request according to the business logic of the target business service when the brake switch is in the off state, and return the response result corresponding to the business service request.

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 12.

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 12.

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 12.

Images