CN117494374A

CN117494374A - Service policy verification method and device, electronic equipment and readable storage medium

Info

Publication number: CN117494374A
Application number: CN202310546162.4A
Authority: CN
Inventors: 李聪; 王思远; 周忠
Original assignee: Mashang Xiaofei Finance Co Ltd
Current assignee: Mashang Xiaofei Finance Co Ltd
Priority date: 2023-05-15
Filing date: 2023-05-15
Publication date: 2024-02-02

Abstract

The disclosure provides a service policy verification method, a service policy verification device, an electronic device and a readable storage medium, which are used for improving policy verification accuracy. The method comprises the following steps: acquiring a first execution result obtained after the service production module executes processing on the target service event based on a first service policy; the service production module is configured with a service production environment, and the first service strategy is a service strategy corresponding to a gray version; acquiring a second execution result obtained after the service simulation module executes the target service event based on a second service strategy; the service simulation module is configured with a service simulation environment, and the second service strategy is a service strategy corresponding to a production version; and comparing the first execution result with the second execution result, and verifying the validity of the first service policy according to the comparison result.

Description

Service policy verification method and device, electronic equipment and readable storage medium

Technical Field

The disclosure relates to the technical field of data processing, and in particular relates to a service policy verification method, a service policy verification device, electronic equipment and a readable storage medium.

Background

The business strategy is used for setting the execution logic and the execution mode of the business. For example, in a business scenario of page layout presentation, different users can be presented with different forms of page layout styles through different business strategies. In another example, in a business scenario of user resource allocation, different resources can be allocated to different users through different business policies. In summary, a service policy is used to define the manner in which a service is executed. As online traffic updates, traffic policies may change as well. For example, in some cases, it is necessary to update the traffic policy from an a-policy to a B-policy.

To ensure proper operation of the new policy, it needs to be validated prior to release. In the related art, in order to realize the comparison verification of the new policy and the old policy, two policies are required to be deployed into a service production system at the same time, and verification is performed in the service production system respectively.

However, the above approach has at least the following drawbacks: the verification process of the new strategy and the old strategy is realized in a service production system, and the service production system itself also needs to be in butt joint with the upstream and downstream service systems, so that the consumption of system resources is very large. On the basis, the business production system is easy to fail due to the influence of the upstream business system and the downstream business system, and the strategy verification result is abnormal.

Disclosure of Invention

The disclosure provides a service policy verification method, a service policy verification device, an electronic device and a readable storage medium, which are used for improving policy verification accuracy.

In a first aspect, the present disclosure provides a method for verifying a service policy, including the following steps:

acquiring a first execution result obtained after the service production module executes processing on the target service event based on a first service policy; the service production module is configured with a service production environment, and the first service strategy is a service strategy corresponding to a gray version;

acquiring a second execution result obtained after the service simulation module executes the target service event based on a second service strategy; the service simulation module is configured with a service simulation environment, the second service strategy is a service strategy corresponding to a production version, and the first service strategy and the second service strategy correspond to the same service scene;

and comparing the first execution result with the second execution result, and verifying the validity of the first service policy according to the comparison result.

In a second aspect, the present disclosure provides a service policy verification apparatus, including:

The first acquisition module is suitable for acquiring a first execution result obtained after the business production module executes processing on the target business event based on a first business strategy; the service production module is configured with a service production environment, and the first service strategy is a service strategy corresponding to a gray version;

the second acquisition module is suitable for acquiring a second execution result obtained after the service simulation module executes the target service event based on a second service strategy; the service simulation module is configured with a service simulation environment, the second service strategy is a service strategy corresponding to a production version, and the first service strategy and the second service strategy correspond to the same service scene;

and the verification module is suitable for comparing the first execution result with the second execution result and verifying the validity of the first service policy according to the comparison result.

In a third aspect, the present disclosure provides an electronic device comprising: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, one or more of the computer programs being executable by the at least one processor to enable the at least one processor to perform the above-described method.

In a fourth aspect, the present disclosure provides a computer readable storage medium having stored thereon a computer program, wherein the computer program when executed by a processor/processing core implements the above-described method.

In the embodiment provided by the disclosure, first, a first execution result obtained after a service production module executes processing on a target service event based on a first service policy is obtained; the service production module is configured with a service production environment, and the first service policy is a service policy corresponding to a gray version. Then, a second execution result obtained after the service simulation module executes the processing of the target service event based on a second service strategy is obtained, a service simulation environment is configured in the service simulation module, and the second service strategy is a service strategy corresponding to the production version; and finally, comparing the first execution result with the second execution result, and verifying the validity of the first service policy according to the comparison result. In this embodiment, when verifying a new policy (i.e., a service policy corresponding to a gray version), two execution results obtained by the same target service event based on two policies (i.e., a service policy corresponding to a gray version and a service policy corresponding to a production version) need to be obtained respectively, so as to verify whether the new policy is valid according to a comparison situation of the two execution results. In this embodiment, the verification process of the business strategy of the target business event based on the production version is transferred to the business simulation environment (instead of being directly implemented by the business production environment), so that the influence caused by the abnormality of the business production environment can be reduced to the minimum, and the accuracy of strategy verification is improved.

It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.

Drawings

The accompanying drawings are included to provide a further understanding of the disclosure, and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description serve to explain the disclosure, without limitation to the disclosure. The above and other features and advantages will become more readily apparent to those skilled in the art by describing in detail exemplary embodiments with reference to the attached drawings, in which:

fig. 1 is a flowchart of a method for verifying a service policy according to an embodiment of the present disclosure;

FIG. 2 is a flow diagram illustrating one specific example of a method of verifying a business policy of the present application;

FIG. 3 illustrates a system architecture diagram of the specific example of FIG. 2;

fig. 4 is a block diagram of a service policy verification device provided in an embodiment of the present disclosure;

fig. 5 is a block diagram of an electronic device according to an embodiment of the present disclosure.

Detailed Description

For a better understanding of the technical solutions of the present disclosure, exemplary embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which various details of the embodiments of the present disclosure are included to facilitate understanding, and they should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Embodiments of the disclosure and features of embodiments may be combined with each other without conflict.

As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The terms "connected" or "connected," and the like, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

The verification method of the service policy according to the embodiments of the present disclosure may be performed by an electronic device such as a terminal device or a server, where the terminal device may be a vehicle-mounted device, a User Equipment (UE), a mobile device, a User terminal, a cellular phone, a cordless phone, a personal digital assistant (Personal Digital Assistant, PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, or the like; the server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud computing service. The method may in particular be implemented by means of a processor calling a computer program stored in a memory.

In the related art, in order to realize the comparison verification of the new policy and the old policy, two policies are required to be deployed into a service production system at the same time, and verification is performed in the service production system respectively. However, the above approach has at least the following drawbacks: the verification process of the new strategy and the old strategy is realized in a service production system, and the service production system itself also needs to be in butt joint with the upstream and downstream service systems, so that the consumption of system resources is very large. On the basis, the business production system is easy to fail due to the influence of the upstream business system and the downstream business system, and the strategy verification result is abnormal. In order to solve the above problems, the present application proposes a method for verifying a service policy, by transferring a verification process of a service policy of a target service event based on a production version to a service simulation environment (instead of directly being implemented by the service production environment), thereby minimizing an influence caused by an abnormality of the service production environment itself and improving accuracy of policy verification.

Fig. 1 is a flowchart of a method for verifying a service policy according to an embodiment of the present disclosure. Referring to fig. 1, the method includes:

step S110: acquiring a first execution result obtained after the service production module executes processing on the target service event based on a first service policy; the service production module is configured with a service production environment, and the first service strategy is a service strategy corresponding to a gray version.

The service production module is provided with a service production environment. The business production environment is an environment facing to external users, and is a formal environment accessible by connecting to the Internet. Accordingly, service policies corresponding to the production version are typically deployed in the service production module for most users. In addition, in order to facilitate evaluation test on the new service policy, in this embodiment, a first service policy corresponding to the gray scale version is further deployed in the service production module.

Since the first traffic policy is for greyscale versions, it is typically only open for part of the users, or only for handling part of the traffic functions. Correspondingly, under the condition that the service event is detected by the service production module, whether the service event needs to be processed through a first service strategy or not is judged according to a user identifier or a service function identifier corresponding to the service event, if yes, the service event is determined to be a target service event, and the target service event is processed based on the first service strategy, so that a first execution result is obtained. The first service policy may be implemented by a first policy model, etc., and is used to obtain an event parameter of a target service event, and obtain an execution result corresponding to the event parameter by the first policy model. Wherein, the execution result includes: the present application is not limited to the specific type and meaning of the execution result in various cases such as approval passing, approval failing, and event abnormality.

Step S120: acquiring a second execution result obtained after the service simulation module executes the target service event based on a second service strategy; the service simulation module is configured with a service simulation environment, the second service strategy is a service strategy corresponding to the production version, and the first service strategy and the second service strategy correspond to the same service scene.

The business simulation module can monitor target business events in the modes of flow replication, event monitoring and the like. And the business simulation module executes processing on the target business event based on the second business strategy under the condition that the target business event is monitored, so as to obtain a second execution result. The service simulation module is provided with a service simulation environment. The business simulation environment is defined as the same environment as the production environment actually used, and therefore, all the configuration situations in the business simulation environment are the same as the business production environment. A second business strategy corresponding to the production version is configured in the business simulation module. It follows that the second business strategy corresponds to the production version, unlike the first business strategy corresponding to the greyscale version. And, the first service policy and the second service policy both correspond to the same service scenario. Correspondingly, by means of the service simulation module, the target service event can be processed based on the second service strategy, and a second execution result is obtained.

Therefore, in this step, the target traffic event in step S110 can be processed by the second traffic policy. The second service policy may be implemented by a second policy model, etc., and is used to obtain an event parameter of the target service event, and obtain an execution result corresponding to the event parameter by using the second policy model. It can be seen that, since the target service event in step S110 and step S120 is the same service event, the corresponding event parameters are the same or similar, and the main difference between step S110 and step S120 is that: the business strategy for handling the targeted business event is different. Therefore, the embodiment can respectively obtain the execution results corresponding to the two different business strategies aiming at the same business event so as to verify through the difference between the two execution results.

Step S130: and comparing the first execution result with the second execution result, and verifying the validity of the first service policy according to the comparison result.

The execution body of the embodiment may be a detection module. The detection module can be independent of the business production module and the business simulation module; alternatively, the detection module may be integrated inside the service production module or the service simulation module, which is not limited to specific implementation details in this application.

Specifically, the first execution result and the second execution result are compared to analyze the same point and different points between the first execution result and the second execution result, so as to verify whether the first service policy is valid according to the comparison result. For example, if the first execution result and the second execution result are both approved, the first business strategy is indicated to be effective, and the first business strategy corresponding to the gray version can be formally issued to the production environment.

It can be seen that, in this embodiment, when verifying a new policy (i.e., a service policy corresponding to a gray version), two execution results obtained by the same target service event based on two policies (i.e., a service policy corresponding to a gray version and a service policy corresponding to a production version) need to be obtained respectively, so as to verify whether the new policy is valid according to a comparison situation of the two execution results. In this embodiment, the verification process of the business strategy of the target business event based on the production version is transferred to the business simulation environment (instead of being directly implemented by the business production environment), so that the influence caused by the abnormality of the business production environment can be reduced to the minimum, and the accuracy of strategy verification is improved.

Various modifications and alterations to the above described embodiments will be apparent to those skilled in the art, and the specific implementation details of the above described embodiments are not intended to be limiting.

In an alternative implementation manner, the event attribute of the target service event to be verified can be configured according to the local service function or the local service characteristic to be verified, so that the targeted policy verification is performed only for the specific type of target service event, and unnecessary system overhead caused by verification for all service events is avoided. Accordingly, the target business event includes: the event attribute information is matched with a pre-configured target attribute of the event to be monitored; the target attribute of the pre-configured event to be monitored comprises: a business channel attribute of a business event, and/or a business function attribute of a business event. It can be seen that, in this manner, before the second execution result obtained after the service simulation module executes the processing on the target service event based on the second service policy is obtained, the target service event is further monitored according to the target attribute of the pre-configured event to be monitored. And under the condition that the target business event is monitored, the business simulation module executes processing on the target business event based on the second business strategy. For example, in this embodiment, a target attribute of an event to be monitored may be configured in advance through a configuration interface, for example, a business channel attribute is configured to designate a business event of a business channel as the target business event to be monitored; as another example, a business function attribute is configured to designate a business event of a business function (e.g., a newly added business function corresponding to a new product) as a target business event to be monitored. Accordingly, the service production module needs to screen specific types of target service events to execute the processing according to the event attribute of the monitored service events. In the mode, all business events processed by the business production module based on the first business strategy are not required to be verified in a business simulation environment, and only business events of specific business types are required to be copied to the business simulation module for processing in a flow copying mode, so that the pertinence of simulation verification can be improved.

In yet another alternative implementation manner, when comparing the first execution result with the second execution result, verifying the validity of the first service policy according to the comparison result, the method is specifically implemented by the following steps: first, a first result index included in a first execution result is obtained. The first result index is used for representing the execution condition of the target business event based on the first business strategy. For example, the first result indicator may include: and various indexes such as approval passing rate, user cancellation rate or rejection rate and the like are obtained based on the first business strategy. Then, a second result index included in the second execution result is acquired. The second result indicator may include: and various indexes such as approval passing rate, user cancellation rate or rejection rate and the like are obtained based on the second business strategy. And finally, comparing the first result index with the second result index, and determining whether the first business strategy is effective according to the matching relation between the difference value between the first result index and the second result index and the preset threshold value. For example, the difference between the approval passing rate obtained based on the first business strategy and the approval passing rate obtained based on the second business strategy is compared with a preset approval passing rate threshold, and if the difference is not greater than the approval passing rate threshold, the first business strategy is indicated to be effective (no significant fluctuation of the approval passing rate is caused).

In yet another alternative implementation, in the case that the target attribute in the event to be monitored is a plurality of target attributes, the preset threshold may further include a plurality of preset target thresholds respectively corresponding to different target attributes. Correspondingly, when the first result index is compared with the second result index, and whether the first business strategy is effective or not is determined according to the matching relation between the difference value between the first result index and the second result index and the preset threshold value, the first target result index corresponding to the target attribute can be extracted from the first result index, and the second target result index corresponding to the target attribute can be extracted from the second result index for each target attribute; and determining whether strategy content corresponding to the target attribute in the first service strategy is effective or not according to the matching relation between the difference value between the first target result index and the second target result index and the preset target threshold value. It can be seen that, when the service policy is executed, the target result index corresponding to each target attribute is obtained, so that validity verification is performed for each target result index. For example, assume that the target attribute includes a plurality of attributes corresponding to different business functions, such as a payment function attribute, a preview function attribute, and the like. Correspondingly, for the payment function attribute, determining a first payment result index corresponding to the payment function attribute according to the first service policy, and determining a second payment result index corresponding to the payment function attribute according to the second service policy, thereby determining whether policy content corresponding to the payment function attribute in the first service policy is valid according to a matching relationship between a difference value between the first payment result index and the second payment result index and a preset payment threshold value.

In yet another alternative implementation, verification is performed by way of a chart visualization in order to facilitate the effect of a quick comparison. Correspondingly, the matching relation between the difference value between the first target result index and the second target result index and the preset target threshold value is determined by the following modes: firstly, displaying a first target result index in a first display area of a result display interface in a visual chart mode; secondly, displaying a second target result index in a second display area of a result display interface in a visual chart mode; and determining and displaying a matching relation between the difference value between the first target result index and the second target result index and a preset target threshold value in a visual chart mode. Because the visual display mode of the chart is more visual, the efficiency and the accuracy of comparison can be improved by means of the chart display mode.

In yet another alternative implementation, the business simulation module monitors the targeted business events in the business production module with the aid of an event listener. The event monitor can be realized in various modes such as callback function, hooking function and the like. In addition, the event parameters of the events to be monitored in the event monitor can be configured, so that the event monitor monitors only the business events with event attributes represented by the event parameters and matched with the target attributes, and the types and the numbers of the business events needing to be verified through the simulation environment can be flexibly set through the configuration of the event monitor. In addition, event synchronization between the service production module and the service simulation module can be realized by means of the event message queue. Correspondingly, an event monitor is configured in the service production module and is used for writing event input data corresponding to the target service event into the event message queue under the condition that the target service event is monitored. Wherein the event input data includes: event parameters, event variables, and/or event data sources. The event parameters are used to characterize the nature or kind of the business event. Event variables refer to variables associated with business events, for example, the event variables may be: it can be seen that the variable values of the event variables dynamically change over time, as a result of the number of user accesses in the last 6 months, the number of user logins in the last 3 months, etc. The event data source refers to: the data source according to the event, such as the event data source, may be a data table of a third party, etc. It follows that event input data refers to data contents required for executing policy processing. The event input data corresponding to each business event is written into the event message queue in turn in the form of event message. Therefore, when the service simulation module performs processing on the target service event based on the second service policy, the service simulation module is specifically implemented by the following modes: first, event input data corresponding to a target business event is acquired from a preset event message queue. And then, a strategy model contained in the second service strategy is called to process the event input data. Wherein, the policy model refers to: the data model is used for running the specified business strategy, for example, the strategy model is used for inputting data according to the input event, executing the preset type of processing and obtaining the output result. It can be seen that in the business process, a plurality of complex data processing processes are involved, and accordingly, a corresponding policy model can be set for each data processing process. The policy model is required to execute corresponding processing according to the plurality of data sources and the plurality of event variables in the input event input data to obtain an output result. Additionally, in some cases, the policy model may need to perform multiple iterative processes to obtain the final output result. For example, after the policy model executes the ith operation process for a plurality of data sources and a plurality of event variables in the event input data, determining whether the result of the ith operation process meets a preset end condition, if not, executing the (i+1) th operation process iteratively until the result of the operation process meets the preset end condition. The preset ending condition may be various model convergence conditions such as that the result of the operation processing is smaller than a preset first threshold or larger than a preset second threshold, and the preset ending condition may be specifically set according to the actual service condition.

In yet another optional implementation manner, a second service policy is further configured in the service production module, and then the service production module determines that the service event is processed by the first service policy or the second service policy according to a preset event distribution policy under the condition that the service event is received; wherein the event diversion policy comprises at least one of: proportional splitting strategy, event type splitting strategy. It can be seen that in this manner, the service production module is simultaneously configured with a first service policy corresponding to the gray scale version and a second service policy corresponding to the production version, and accordingly, in the case of detecting a service event, determines what service policy the current service event is handled by according to the event splitting policy. The proportional splitting policy may be configured to process a first proportion (e.g., 70%) of the traffic events through the second traffic policy and a second proportion (e.g., 30%) of the traffic events through the first traffic policy. The per-event type splitting policy may be configured to process business events of a first function type (e.g., a payment function type) through a second business policy and process business events of a second function type (e.g., a preview function type) through the first business policy.

In yet another alternative implementation, after verifying the validity of the first service policy according to the comparison result, the following operations are further performed: in the event that the first business strategy is determined to be valid, the first business strategy is published in the business production environment. In addition, in order to avoid the abnormal situation after the first service policy is issued, the policy may be further monitored according to a preset index, an index result corresponding to the preset index is extracted from the service operation result after the first service policy is issued, and the first service policy is closed when the index result is monitored to be abnormal. The index monitoring strategy is used for evaluating whether the operation result is normal or not after the first service strategy is issued. By the method, the first service strategy can be rapidly closed under the condition that the index result is abnormal, and a large number of service problems on line are avoided. And if the condition that the index result is abnormal is not monitored within a preset period, the first service strategy is issued in full quantity.

In summary, in this embodiment, the verification process of the business strategy of the target business event based on the production version is converted to be implemented by the business simulation environment (instead of being directly implemented by the business production environment), so that the influence caused by the abnormality of the business production environment can be reduced to the minimum, and the accuracy of the strategy verification can be improved. In addition, the method can flexibly configure the event type or the event proportion of the service event requiring execution of the first service policy in the service production module, and can flexibly set the service type of the service event requiring verification in the service simulation module. In addition, by means of a visual chart, verification efficiency and accuracy can be improved.

For ease of understanding, specific implementation details of the service policy verification method in the present application will be described in detail below by taking a specific example as an example.

With the development of the internet, the conventional business functions handled in an offline manner can be handled in an online manner. When a user transacts a service in an online manner, various service flows such as user identity verification, service application flow, service approval flow, service processing flow and the like need to be completed online. The processing efficiency can be greatly improved by handling the business online. However, in the business approval link, approval verification is required through a preset business strategy. And, with iterative updating of service functions, the service policies also need to be updated continuously to meet the user demands. For example, in a wind-controlled scenario, a user risk level needs to be evaluated according to various information of the user, so as to reduce business risk. In this scenario, it is necessary to extract multidimensional data information of the user, and comprehensively evaluate whether the user is a secure user. In order to accurately identify the security level of a user, a complete wind control approval system needs to set a complex risk decision process (i.e. business strategy), wherein the risk decision process comprises a plurality of decision rounds, and each decision round usually comprises a plurality of links such as data preparation, variable calling, model analysis and the like. Accordingly, how to perform validity verification for a new set of service policies becomes a technical problem to be solved urgently.

In the related art, policy verification is mainly performed in the following two ways:

in a first approach, the release of a grey scale version of a business strategy is performed in a production environment. Correspondingly, a new version service strategy (namely a gray version) and an original version service strategy (namely a production version) are simultaneously set in the production environment, and part of traffic in the production environment is cut into the gray version for verification by setting gray scale. And if the gray level version verification is passed, performing full release of the new version. However, the above approach has at least the following drawbacks: since the verification process of the new version policy is implemented in the production environment, there are interference terms when locating abnormal problems: if the new version strategy is released, the approval result shows abnormality, and the problem caused by the new version strategy or the abnormality of the system self resources or the upstream and downstream system resources cannot be accurately and quickly positioned. The specific reasons are as follows: when verifying the new version strategy, comparing the execution result of the new version strategy with the execution result of the old version strategy, and judging whether the new version strategy is normal or not according to the comparison result. However, the old version policy may be subjected to the problem of abnormality of the system itself resource or the upstream and downstream system resource in the operation process, so that the approval state of the old version policy is abnormal, and further the comparison result is abnormal, so that the verification of the new version policy is abnormal.

In the second approach, an additional simulation environment is required, and gray scale distribution is performed in the simulation environment. Correspondingly, only original version business strategies are deployed in the production environment, new version business strategies are deployed in the simulation environment, and after the test result of the simulation environment reaches the expected effect, the new version business strategies are deployed in the production environment. The verification mode for the new version business strategy can be realized by adopting modes such as manual log, SQL analysis and the like. However, this approach has at least the following drawbacks: after the new version service policy passes the verification, the new version service policy needs to be synchronously updated to the production environment, and in the synchronous updating process, the new version service policy which is finally updated to the production environment may be different from the new version service policy which passes the verification in the simulation environment due to misoperation and other reasons, so that an abnormal problem is caused. For example, when a new version policy package is updated synchronously into a production environment, the gray scale version verified by the simulation environment is inconsistent with the version finally deployed in the production environment due to manual misoperation or network abnormality. Therefore, if the new version is verified to be in line with the expectations in the simulation environment, the new version strategy needs to be automatically or manually synchronized to the production environment, and the synchronization process may be abnormal, if the abnormal discovery is not timely, the production environment has fully released the new version, a large amount of abnormal approval sheets will appear in a short time, and if the system adopts an abnormal compensation or retry mechanism, the system will have overlarge upstream and downstream pressure load under extreme conditions, so that the service loss is serious. In addition, if the new version policy update in the production environment fails, the rollback operation also has a failure risk. And when the rolled-back new version is released again to the production environment, approval verification and index verification are required to be performed again, so that the time consumption for releasing verification is increased, and the risk probability is improved. Moreover, if the new version is verified to be not in accordance with the expectation in the simulation environment, data analysis is required to be performed on the new version in the simulation environment. In actual situations, a new version policy may be correct, but due to manual misoperation or network abnormality, the update of the policy package of the simulation environment fails, so that the approval state in the simulation environment is abnormal, and the time consumption of policy verification is increased. Therefore, since the policy verification process for the new version is implemented in the simulation environment, and the simulation environment is different from the production environment, a synchronization process from the simulation environment to the production environment needs to be additionally added, and the synchronization process may cause errors, so that a series of problems of low policy verification efficiency, low accident problem positioning and the like of the new version are caused.

In order to solve the above problems, to improve the verification efficiency of policy issuing and to quickly locate accident problem points on the line, the present example establishes a set of simulation environments for simulating the production environment (instead of the gray scale environment) for implementing verification of new version policies. The method effectively reduces the release risk of the business strategy and improves the verification efficiency by constructing the simulation environment to assist in gray level verification. The specific scheme is as follows: before releasing the new version strategy, two sets of strategies of an original version (namely a production version) and a gray version are simultaneously set in a production environment; the simulation environment runs the master policy. The simulation environment acquires bill of lading details of the production environment in the gray scale release period in real time in a flow replication mode, performs flow approval, rapidly verifies connectivity of the new version strategy by comparing approval results of the production version operation strategy and the new iteration version (gray scale version) operation strategy, can rapidly locate accident problem points in the new version strategy release period, rapidly verifies new version business requirements through the generated comparison report, and provides data quality analysis of data service.

This example has at least the following advantages:

First, the disturbance caused by the abnormality of the production environment can be avoided. By constructing the simulation environment, the interference to version verification caused by system resource bottleneck or upstream and downstream system abnormality when verifying the production version is effectively avoided. For example, if a simulation environment is not adopted, when a new version policy is released, if the approval result shows abnormality, whether the problem caused by the new version policy is a problem caused by the new version policy cannot be accurately and quickly located, and the problem of the system itself resources or upstream and downstream systems is also possible.

Secondly, aiming at the same application form (namely a business event), verification can be carried out through different strategy versions, so that comparison verification between a gray version and an original edition is realized, and further, new edition strategy abnormal verification and business requirement verification are rapidly realized. Specifically, the same application form is approved by adopting a gray version (new version) strategy in a production environment, and is approved by adopting an original version strategy in a simulation environment. The following problems can be solved thereby: on one hand, by avoiding the interference of the production environment, the rapid exception verification of the new version strategy can be realized: the same application form is compared with the approval state of the application form of the production environment (gray version) and the application form of the simulation environment (original edition), and if the approval of the production environment (gray version) is abnormal, the abnormal of the gray version can be responded and processed rapidly. On the other hand, by means of a chart visualization mode, the quick verification of the new version business requirement can be realized: because a complete wind control approval system can go through a complex risk decision process, and one decision round may comprise a plurality of links such as data preparation, variable calling, model analysis and the like. Meanwhile, a perfect wind control system needs to be continuously and iteratively upgraded aiming at a company operation strategy and technical indexes. A policy change may involve modification of a large number of data services (a complex approval system has thousands of data services), such as access parameter modification of the data services, access parameter modification of the policy, and so on. The policy change for each link is effective, which often results in too long verification time. The comparison report can be automatically exported through the visualization operation and the index configuration operation, and the method is beneficial to realizing the quick verification of the strategy change point.

Again, the risk of anomalies due to the secondary synchronization update strategy can also be circumvented: the method ensures that the production environment has synchronized the latest verified strategy version in the stage of gray level verification of the production environment by directly gray level release of the production environment, and does not need to execute synchronous operation from the simulation environment to the production environment. The method has the advantages that through a direct gray level release mode of the production environment, the risk of an abnormal single is controllable, the gray level version adopts a flow control mode in a pre-release verification stage, although the gray level version application form is approved abnormally, only the gray level is closed in time, the version rollback operation is not needed, and the risk of the rollback operation and the impact of an abnormal single compensation or retry mechanism on an approval system are effectively reduced.

Specific implementation details of this example are described in detail below:

in this example, two sets of application environments are involved in total: production environment and simulation environment. Wherein, the production environment has the following characteristics: when the new version strategy is not released, the running strategy package is consistent with the simulation environment, and the strategy package is an old version strategy (namely a second service strategy) and is expressed by an online version regulation; when a new version strategy is released, the strategy is released in a gray scale mode, and the gray scale version strategy (namely a first service strategy) is expressed in a garyversion regulation; at this point the production environment runs two sets of strategies, one for the online version regulation and one for the garyversion regulation, respectively. When the new version strategy release verification is passed, the production environment operation strategy package Online version Regulation is disconnected, and the gray version strategy package formally produces and operates GaryVersionRegulation- > Online version Regulation. The simulation environment has the following characteristics: and the produced application system and the wind control strategy (OnlineVersionRegular) are consistent; and acquiring bill of lading details of the production environment in the gray level release period in real time in a flow replication mode, and executing flow approval through an old version strategy. By comparing the approval results of the production operation strategy online version regulation and the new iteration version strategy garyversion regulation, the connectivity of the new version strategy can be rapidly verified, and accident problem points during the release of the new version strategy can be rapidly located. And through the generated comparison report, the data quality analysis of the data service can be provided for a business party.

Fig. 2 shows a flow diagram of a method for verifying a service policy provided by this specific example. Fig. 3 shows a system architecture diagram of this example, as shown in fig. 3, in which two sets of environments, a production environment and a simulation environment, are configured independently of each other. The system comprises a service production module, a service simulation module, a verification module and a release module, wherein the production environment is realized by the service production module, the simulation environment is realized by the service simulation module, and the system also comprises the verification module and the release module. The verification module is used for verifying the validity of the first business strategy (also called new business strategy), and the release module is used for formally releasing the first business strategy into the production environment under the condition that the first business strategy is valid.

As shown in fig. 2, the method specifically includes the following steps:

step S201: the new version of the policy is run in grayscale in the production environment.

Specifically, in this step, it is necessary to turn on the gradation and perform gradation arrangement. Specifically, a new version of policy flow package is issued in a gray scale mode, the policy flow package is mainly used for arranging the flow of data services (such as three-party data sources, variables, models, rule packages and the like), and an approval system executes approval call according to the flow package. In addition, before gradation distribution, it is necessary to perform a gradation configuration operation, which may be, for example, setting gradation ratios. For example, the gray scale configuration may be configured in terms of a split ratio, i.e.: the proportion of flow packages in the production environment that need to be shunted to the gray scale version in real time is configured. Further, the operation of turning on and off the gradation can be performed. For example, 20% of the business events are handled by gray-scale versions of the business policies (i.e., new versions of the business policies).

In addition, the flow replication function is required to be started, and the flow replication function can be specifically configured to shunt the business flows with different dimensions to the simulation environment for verification. Wherein, the specific dimension can be characterized by a service channel identifier or a service product identifier. For example, the configuration can be performed through the product and channel dimensions, and the tangential flow proportion (such as 92%) and/or tangential flow quantity can be also configured, so that the service flow which needs to be shunted to the simulation environment for verification through the flow replication mode is flexibly configured.

Step S202: and configuring monitoring indexes in the system for realizing index verification after gray level release.

The monitoring index is mainly used for monitoring the participation of the decision data service. Specifically, the reason for monitoring the participation of the decision data service is that: the final influence on the approval result in the wind control strategy is decision output, and the decision input directly determines the decision output, so that the participation of the monitoring decision data service can monitor abnormal conditions more directly. Wherein the decision input is made up of a multidimensional data service, e.g. comprising: three-party data sources, internal variables, user data, etc. Therefore, the influence condition of the strategy on the result can be more directly determined by monitoring the mode of analyzing the data service call and the arrangement by the decision input.

Step S203: processing the business event based on the new version strategy in the production environment, and sending the event input data of the business event to the message middleware.

When processing a business event based on a new version policy in a production environment, the business event needs to be subjected to approval, verification and other processing based on the new version policy. The message middleware is used for storing event input data of service events, and can be realized in a mode of event message queues. Wherein the event input data is available via a bill of lading message.

Step S204: event input data of business events are obtained from the message middleware and are processed in the simulation environment through the old version strategy.

The old version policy is the second business policy corresponding to the production version. In particular, event input data is obtained from message middleware in a simulation environment, and approval is performed based on an old version policy.

Step S205: and comparing a processing result obtained by processing the business event based on the new version strategy in the production environment with a processing result obtained by processing the business event through the old version strategy in the simulation environment.

The visual comparison tool can be used for comparing, and the visual comparison tool can analyze the approval result, the approval data service call flow, the data service access parameters and the like respectively and generate a comparison report. Specifically, whether an abnormal cancel list exists when the new version strategy gray level is released is checked through a visual interface. The abnormal cancellation list can be detected through indexes such as the passing rate, rejection rate, cancellation rate and the like of the service order.

Step S206: and judging whether the new version strategy passes verification or not according to the comparison result.

In this step, the following operations may be implemented: for example, the monitoring end monitors the gray level list approval result of the production environment in real time, and if a large number of cancellation lists occur, a monitoring alarm is sent to be processed by research personnel and service parties. In another example, in the process of quick verification of the new version service requirement, the comparison report automatically derived through analysis is beneficial to quick verification of the strategy change point. The specific verification process can be realized by the following steps:

if the approval sheet flow of the simulation environment is normal and the gray sheet flow of the production environment is abnormal, the gray is closed in time.

If the gray scale approval process of the simulation environment and the production environment is normal, further checking whether the index data of the new demand change index (i.e. the monitoring index) configured in step S202 meets the expectations by comparing the report: if the index data of the configured monitoring index does not accord with the expectation, temporarily turning off the gray scale; and if the index data of the configured monitoring index accords with the expectation, realizing full release of the new version on line.

Specifically, in this example, in order to improve the verification efficiency, the comparison verification is performed by a visual chart mode, and specifically, the approval result comparison of the new version policy (garyversionregulation-online environment) and the online formal operation version policy (online version regulation-simulation environment) can be checked. For example, in the visual interface, indexes such as the total number of approval, the consistent number, and the consistent rate in the approval result may be displayed for each dimension to be verified, the consistent number and the consistent rate in the decision input may be displayed, the consistent number and the consistent rate in the decision output may be displayed, and the total number, the consistent number, and the consistent rate in the flow trace may be displayed. Wherein, the coincidence number and coincidence rate refer to: whether the approval result of the new version strategy is the same as the approval result of the old version strategy or not, and if so, the approval result is consistent; if they are different, they are not identical. Therefore, the comparison situation of new and old versions can be visually presented by respectively displaying the consistent number and consistent rate of the dimensions such as approval results, decision input, decision output, flow tracks and the like.

In a word, through the visual interface, a comparison report between the decision-making entry of the gray version strategy (namely, the new version strategy) and the decision-making entry of the version strategy (namely, the old version strategy) formally operated on line can be automatically derived, so that verification analysis can be conveniently carried out on the change point of the new version; meanwhile, an additional comparison report is generated for displaying the data of the monitoring variables. In the comparison report, detailed description information such as date, approval round, variable name, application number, product number, channel number, inconsistent type, data service name, gray version value (production environment), production version value (simulation environment) and the like can be listed in a data table mode.

In summary, the example improves the release efficiency by a configurable strategy gray level release mode, and can close the new version strategy in time so as to avoid the production risk. This example enables at least the following benefits to be achieved:

first, the effect of multi-dimensional configuration tangential flow verification can be achieved. The service flow which needs to be cut into the simulation environment for verification in the production environment can be flexibly configured. Specifically, the influence of the new strategy in different dimensions (such as product dimension or channel dimension) can be analyzed pertinently; for example, the new version strategy is only changed for a specific product or a specific channel, and when the new version strategy is configured, the application form with the tangential related dimension can be reconfigured to verify a specific requirement function point.

Secondly, the exception verification of the new version policy can be realized quickly. The application form of the production environment and the application form approval state of the simulation environment can be checked in real time through the approval result visualization interface, and if the approval of the production environment (gray version) is abnormal and the approval of the simulation environment (production version) is normal, the judgment and the processing of abnormal response can be timely made.

Again, new version business requirements can be quickly verified. Because a complete wind control approval system can undergo complex risk decisions, one decision round may comprise a plurality of links of data preparation, variable calling and model analysis. Meanwhile, a perfect wind control system needs to be continuously and iteratively upgraded aiming at an operation strategy and technical indexes. A change of the policy may involve a large number of data service modifications, such as access parameter modification of the data service, access parameter modification of the policy, and so on. In order to verify that the policy change of each link is effective, the verification time is often longer. The comparison report between the gray version strategy decision entry and the on-line formal operation version strategy entry can be automatically derived through the visualization operation and the index configuration operation, so that the rapid verification of the strategy change point is facilitated.

Finally, this example can circumvent the risk of anomalies caused by the secondary synchronization update strategy. The method ensures that the production environment gray level verification is finished in a direct gray level release mode, and the production environment synchronizes the latest verified strategy version. The method has the advantages that through a direct gray level release mode of the production environment, the risk of an abnormal single is controllable, the gray level version adopts a flow control mode in a pre-release verification stage, although the gray level version application form is approved abnormally, only the gray level is closed in time, the version rollback operation is not needed, and the risk of the rollback operation and the impact of an abnormal single compensation or retry mechanism on an approval system are effectively reduced. In summary, by this example, not only risk verification but also verification of functional requirements (newly added service function points) can be performed, and both of the above-described verification can be achieved at the same time.

Fig. 4 shows a block diagram of a service policy verification device provided by an embodiment of the present disclosure.

Referring to fig. 4, an embodiment of the present disclosure provides a service policy verification apparatus 30, where the service policy verification apparatus 30 includes:

the first obtaining module 31 is adapted to obtain a first execution result obtained after the service production module executes processing on the target service event based on the first service policy; the service production module is configured with a service production environment, and the first service strategy is a service strategy corresponding to a gray version;

The second obtaining module 32 is adapted to obtain a second execution result obtained after the service simulation module executes the processing on the target service event based on a second service policy; the service simulation module is configured with a service simulation environment, the second service strategy is a service strategy corresponding to a production version, and the first service strategy and the second service strategy correspond to the same service scene;

and the verification module 33 is adapted to compare the first execution result with the second execution result, and verify the validity of the first service policy according to the comparison result.

In an alternative implementation, the target business event includes: business event with event attribute matched with pre-configured target attribute of event to be monitored;

wherein, the target attribute of the pre-configured event to be monitored comprises: a business channel attribute of a business event, and/or a business function attribute of a business event.

In an alternative implementation, the verification module 33 is specifically adapted to:

acquiring a first result index contained in the first execution result;

acquiring a second result index contained in the second execution result;

And comparing the first result index with the second result index, and determining whether the first business strategy is effective according to a matching relation between a difference value between the first result index and the second result index and a preset threshold value.

In an optional implementation manner, in a case that the target attributes in the event to be monitored are multiple, the preset threshold includes multiple preset target thresholds corresponding to different target attributes respectively;

the verification module 33 is specifically adapted to:

for each target attribute, extracting a first target result index corresponding to the target attribute from the first result index, and extracting a second target result index corresponding to the target attribute from the second result index;

and determining whether strategy content corresponding to the target attribute in the first service strategy is effective or not according to a matching relation between a difference value between the first target result index and the second target result index and a preset target threshold value.

In an alternative implementation, the matching relationship between the difference between the first target result index and the second target result index and the preset target threshold is determined by:

Displaying the first target result index in a first display area of a result display interface in a visual chart mode;

displaying the second target result index in a second display area of a result display interface in a visual chart mode;

and determining and displaying a matching relation between the difference value between the first target result index and the second target result index and a preset target threshold value in a visual chart mode.

In an alternative implementation, the second obtaining module 32 is specifically adapted to:

acquiring event input data corresponding to the target business event from a preset event message queue;

invoking a strategy model contained in the second service strategy to process the event input data; wherein the event input data includes: event data sources and/or event variables;

the service production module is configured with an event monitor, and is used for writing the event input data corresponding to the target service event into the event message queue under the condition that the target service event is monitored.

In an optional implementation manner, the service production module is further configured with the second service policy, and if a service event is received, the service production module determines that the service event is processed by the first service policy or the second service policy according to a preset event splitting policy;

Wherein the event diversion policy includes at least one of: proportional splitting strategy, event type splitting strategy.

In an alternative implementation, the verification module 33 is further adapted to:

issuing the first business strategy in the business production environment under the condition that the first business strategy is determined to be effective;

and extracting an index result corresponding to a preset index from service operation results issued by the first service strategy according to a preset index monitoring strategy, and closing the first service strategy under the condition that the index result is monitored to be abnormal.

An embodiment of the present disclosure provides an electronic device with reference to fig. 5, including: at least one processor 501; at least one memory 502, and one or more I/O interfaces 503, coupled between the processor 501 and the memory 502; wherein the memory 502 stores one or more computer programs executable by the at least one processor 501, the one or more computer programs being executed by the at least one processor 501 to perform the above-described method of verifying traffic policies.

The disclosed embodiments also provide a computer readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor/processing core, implements the above-described method of verifying a traffic policy. The computer readable storage medium may be a volatile or nonvolatile computer readable storage medium.

Embodiments of the present disclosure also provide a computer program product comprising computer readable code, or a non-transitory computer readable storage medium carrying computer readable code, which when executed in a processor of an electronic device, performs the above-described method of verifying a business policy.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, functional modules/units in the apparatus, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between the functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed cooperatively by several physical components. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer-readable storage media, which may include computer storage media (or non-transitory media) and communication media (or transitory media).

The term computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable program instructions, data structures, program modules or other data, as known to those skilled in the art. Computer storage media includes, but is not limited to, random Access Memory (RAM), read Only Memory (ROM), erasable Programmable Read Only Memory (EPROM), static Random Access Memory (SRAM), flash memory or other memory technology, portable compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Furthermore, as is well known to those of ordinary skill in the art, communication media typically embodies computer readable program instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and may include any information delivery media.

The computer readable program instructions described herein may be downloaded from a computer readable storage medium to a respective computing/processing device or to an external computer or external storage device over a network, such as the internet, a local area network, a wide area network, and/or a wireless network. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers and/or edge servers. The network interface card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium in the respective computing/processing device.

Computer program instructions for performing the operations of the present disclosure can be assembly instructions, instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, c++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider). In some embodiments, aspects of the present disclosure are implemented by personalizing electronic circuitry, such as programmable logic circuitry, field Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), with state information of computer readable program instructions, which can execute the computer readable program instructions.

The computer program product described herein may be embodied in hardware, software, or a combination thereof. In an alternative embodiment, the computer program product is embodied as a computer storage medium, and in another alternative embodiment, the computer program product is embodied as a software product, such as a software development kit (Software Development Kit, SDK), or the like.

Various aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable medium having the instructions stored therein includes an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus or other devices implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted in a generic and descriptive sense only and not for purpose of limitation. In some instances, it will be apparent to one skilled in the art that features, characteristics, and/or elements described in connection with a particular embodiment may be used alone or in combination with other embodiments unless explicitly stated otherwise. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the disclosure as set forth in the appended claims.

Claims

1. A method for verifying a service policy, comprising:

2. The method of claim 1, wherein the acquiring the second execution result obtained after the service simulation module executes the processing on the target service event based on the second service policy, further comprises:

monitoring a target business event according to a target attribute of a pre-configured event to be monitored; wherein, under the condition that the target business event is monitored, the business simulation module executes processing on the target business event based on a second business strategy;

wherein the target business event comprises: business event with event attribute matched with pre-configured target attribute of event to be monitored; wherein, the target attribute of the pre-configured event to be monitored comprises: a business channel attribute of a business event, and/or a business function attribute of a business event.

3. The method of claim 2, wherein comparing the first execution result with the second execution result, and verifying the validity of the first service policy according to the comparison result comprises:

Acquiring a first result index contained in the first execution result;

acquiring a second result index contained in the second execution result;

4. A method according to claim 3, wherein in case the target attribute in the event to be monitored is a plurality of, the preset threshold value comprises a plurality of preset target threshold values respectively corresponding to different target attributes;

comparing the first result index with the second result index, and determining whether the first service policy is valid according to a matching relationship between a difference value between the first result index and the second result index and a preset threshold value comprises:

5. The method of claim 4, wherein the matching relationship between the difference between the first target result index and the second target result index and a preset target threshold is determined by:

6. The method of claim 1, wherein the performing processing of the target business event based on the second business policy comprises:

7. The method according to claim 1, wherein the service production module is further configured with the second service policy, and if a service event is received, the service production module determines that the service event is processed by the first service policy or the second service policy according to a preset event splitting policy;

8. The method according to any one of claims 1-7, wherein after verifying the validity of the first service policy according to the comparison result, further comprising:

extracting an index result corresponding to a preset index from service operation results issued by the first service strategy according to a preset index monitoring strategy;

and closing the first business strategy under the condition that the index result is abnormal.

9. A service policy verification apparatus, comprising:

10. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores one or more computer programs executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

11. A computer readable storage medium, on which a computer program is stored, which, when being executed by a processor, implements the method according to any of claims 1-8.