Traffic steering rule generation method and apparatus, terminal, and storage medium

Abstract

The application relates to the technical field of information processing, and discloses a shunting rule generation method and device, a terminal and a storage medium. The method comprises the following steps: acquiring interface definition information of each service interface in a distributed system, and screening out a data source type interface used for data collection based on the interface definition information and in combination with a preset semantic identifier; writing the interface definition information into a cache storage unit, and updating the interface definition information in the cache storage unit in real time by listening to a change event when detecting that the interface definition is changed; performing structural processing on parameters of the stored interface definition information, so as to obtain a plurality of candidate rule fields, and determining a corresponding rule operation representation set according to a data type in each candidate rule field; and when generating a shunting rule, generating the shunting rule containing at least one rule condition in response to a target field selected by a user based on the candidate rule fields, a rule operation representation selected from the corresponding rule operation representation set, and an input rule threshold value.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to a method, apparatus, terminal and storage medium for generating traffic splitting rules. Background Technology

[0002] In existing technologies, rules are typically configured through hard-coding or static files, requiring redevelopment and deployment with each change. This fails to meet the demands of high-frequency, iterative business needs, and configuration is difficult for non-technical personnel to participate in. Furthermore, due to the lack of automatic detection of interface definition changes, existing rules are prone to field invalidation or type errors when service interfaces add, delete, or adjust fields, leading to runtime exceptions. In addition, the system cannot respond to interface metadata changes in real time, resulting in inconsistencies between rule logic and the actual data structure. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method, apparatus, terminal device, and computer-readable storage medium for generating traffic splitting rules.

[0004] In a first aspect, embodiments of this application provide a method for generating traffic splitting rules, including: Obtain the interface definition information of each service interface in the distributed system, and filter out the data source class interface for data collection based on the interface definition information and preset semantic identifiers. The interface definition information of the data source class interface is written into the cache storage unit, and when an interface definition change is detected, the interface definition information in the cache storage unit is updated in real time by listening to the change event published by the metadata center. The parameters of the interface definition information stored in the cache storage unit are processed in a structured manner to obtain multiple candidate rule fields, and the corresponding rule operation representation set is determined according to the data type in each candidate rule field; When generating traffic splitting rules, in response to the target field selected by the user based on the candidate rule field, the rule operation representation selected from the corresponding rule operation representation set, and the input rule threshold, a traffic splitting rule containing at least one rule condition is generated.

[0005] In an optional implementation, before generating the traffic splitting rule containing at least one rule condition, the method further includes: The target field, the rule operation representation, and the rule threshold are subjected to integrity verification, and the traffic splitting rule is generated after the verification passes. The integrity verification includes at least one of type compatibility verification, logical consistency check, duplicate detection, and semantic reasonableness judgment.

[0006] In an optional implementation, the step of obtaining the interface definition information of each service interface in the distributed system, and filtering out the data source class interfaces for data collection based on the interface definition information and a preset semantic identifier, includes: Obtain the identifiers of all registered service interfaces in the distributed system through the metadata query interface; For each of the aforementioned service interface identifiers, the metadata service is invoked to obtain the corresponding interface definition information; If, based on the interface definition information, it is detected that the corresponding service interface is configured with a preset semantic identifier annotation, then the corresponding service interface is determined as the data source class interface used for data collection.

[0007] In an optional implementation, the step of updating the interface definition information in the cache storage unit in real time by listening to change events published by the metadata center when an interface definition change is detected includes: When a change in the interface definition information is detected, a change event published by the metadata center is received; wherein, the change event includes the changed service interface identifier and the changed interface definition information; The modified interface definition information is compared with the historical interface definition information stored in the cache storage unit to identify the modified parameters; If the service interface in the change event is the data source type interface, then the corresponding cache update strategy is executed according to the interface type; If the interface type of the service interface in the change event is a non-core data interface, then the corresponding historical interface definition information is directly replaced with the changed interface definition information. If the interface type of the service interface in the change event is a core data interface, then the associated traffic splitting rule is marked as invalid and the interface definition information in the cache storage unit is updated.

[0008] In an optional implementation, the parameters of the interface definition information stored in the cache storage unit are structured to obtain multiple candidate rule fields, including: Each parameter in the interface definition information is parsed one by one to obtain the field name, field description and data type of each parameter; If at least one of the field name, the field description, and the data type satisfies the corresponding preset filtering condition, then the corresponding parameter will be used as a candidate rule field.

[0009] In an optional implementation, each rule condition of the traffic splitting rule further includes the rule execution order and the traffic application ratio; The rule execution order is used to determine the matching priority among multiple rule conditions; the traffic application ratio is used to indicate that, for the current rule condition, a portion of the received request traffic is randomly selected according to a preset probability to perform the matching judgment of the current rule condition.

[0010] In an optional implementation, the semantic reasonableness judgment includes: The rule operation representation and the corresponding rule threshold are converted into a problem description in natural language. The question description is processed using a question-answering model based on an integrated enterprise knowledge base, and the reasonableness of the corresponding rule conditions is determined based on the processing results.

[0011] Secondly, embodiments of this application provide a traffic splitting rule generation apparatus, comprising: The filtering module is used to obtain the interface definition information of each service interface in the distributed system, and filter out the data source class interfaces for data collection based on the interface definition information and the preset semantic identifier. The update module is used to write the interface definition information of the data source class interface into the cache storage unit, and when an interface definition change is detected, to update the interface definition information in the cache storage unit in real time by listening to the change event published by the metadata center; The determination module is used to perform structured processing on the parameters of the interface definition information stored in the cache storage unit to obtain multiple candidate rule fields, and determine the corresponding rule operation representation set according to the data type in each candidate rule field; The generation module is used to generate a traffic splitting rule containing at least one rule condition in response to the target field selected by the user based on the candidate rule field, the rule operation representation selected from the corresponding rule operation representation set, and the input rule threshold when generating traffic splitting rules.

[0012] Thirdly, embodiments of this application provide a terminal device, the terminal device including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the above-described method for generating traffic splitting rules.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed on a processor, implements the above-described method for generating traffic splitting rules.

[0014] The embodiments of this application have the following beneficial effects: This application achieves accurate identification and classification management of high-value interfaces by acquiring the interface definition information of various service interfaces in a distributed system and automatically filtering data source interfaces for data collection using preset semantic identifiers, thus avoiding errors and delays caused by manual configuration. The interface definition information of data source interfaces is written into a cache storage unit, improving the efficiency of metadata access. Simultaneously, by listening to change events published by the metadata center, the information in the cache is updated in real time when the interface definition changes, ensuring that the metadata on which rule generation depends is always consistent with the actual service definition. Through structured processing of interface parameters in the cache, multiple candidate rule fields are extracted, and the corresponding rule operation representation set is determined according to the data type of each field, providing a clear and semantically explicit basic input for subsequent rule configuration. When generating traffic splitting rules, in response to the user's selection of target fields, rule operation representations, and rule thresholds, traffic splitting rules containing at least one rule condition are automatically generated, thereby achieving efficient conversion from metadata to executable rules. This method significantly improves the automation level of rule generation, reduces reliance on developer coding, enhances the system's adaptability to service evolution, and effectively solves problems such as rule failure due to interface changes, long configuration cycles, and high maintenance costs in traditional rule configuration. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This paper illustrates a first flowchart of the traffic splitting rule generation method according to an embodiment of the present application. Figure 2 This paper illustrates a second flowchart of the traffic splitting rule generation method according to an embodiment of the present application. Figure 3 A schematic diagram of the third process of the traffic splitting rule generation method according to an embodiment of this application is shown; Figure 4 The diagram illustrates the fourth process flow of the traffic splitting rule generation method according to an embodiment of this application; Figure 5 A schematic diagram of a traffic splitting rule generation device according to an embodiment of this application is shown. Detailed Implementation

[0017] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0018] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0020] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0021] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0022] In current distributed system architectures, especially in microservice-based development models, the inter-service call relationships are becoming increasingly complex, and the number of interfaces is growing exponentially. To achieve fine-grained control over request traffic, a dedicated rule engine is typically required to execute the judgment logic. Traditional traffic splitting rule configuration schemes mainly adopt a hard-coded approach, where developers write the specific condition judgments and branch processing through coding. This approach not only has a lengthy development cycle, but each rule change also requires a complete process of recompiling, testing, and deploying, resulting in significantly reduced iteration efficiency and difficulty in adapting to rapidly evolving business needs. Furthermore, while some systems use static rule configuration files based on XML or JSON formats, achieving a certain degree of decoupling between rules and code, problems such as cumbersome configuration processes and poor readability still exist. Especially when facing dynamic logic combination requirements, they exhibit significant limitations in expressive power, making it difficult for non-technical personnel to independently complete rule maintenance. More importantly, due to the lack of an automated awareness mechanism for service interface metadata, rule configuration usually relies on manually maintained interface documents or database table structure information. When interfaces change (such as adding, deleting, or adjusting fields), the relevant rules cannot be updated synchronously, easily leading to runtime anomalies such as invalid field references and type mismatches, severely impacting system stability and reliability. Furthermore, existing technical solutions generally lack real-time response capabilities to interface definition changes. In a microservice architecture, service providers may frequently upgrade interface definitions; if consumers cannot detect these changes in a timely manner, it will result in a severe disconnect between rule logic and the actual data structure. Although some platforms have introduced metadata management modules, most remain at the passive query level, failing to proactively refresh metadata and adaptively adjust rules in conjunction with change events. Moreover, during rule configuration, there is a general lack of intelligent verification mechanisms for the semantic rationality of rules; complex rules are prone to logical conflicts or redundancy, currently relying mainly on manual checks, which is not only inefficient but also prone to oversights.

[0023] Based on this, this application proposes a method, device, terminal, and storage medium for generating traffic splitting rules. By automatically acquiring and continuously monitoring the metadata of service interfaces, combining semantic identifiers to filter out data source class interfaces that can be used for rule configuration, and dynamically generating candidate rule fields and their available operations based on structured parsing, the method achieves automated preparation and real-time synchronization of basic rule configuration information, thereby solving the technical problems of low rule configuration efficiency, easy error, and difficult maintenance.

[0024] The following examples illustrate the method for generating traffic splitting rules.

[0025] Figure 1A schematic flowchart of a traffic splitting rule generation method according to an embodiment of this application is shown. Exemplarily, the traffic splitting rule generation method includes steps S100-S400: Step S100: Obtain the interface definition information of each service interface in the distributed system, and filter out the data source class interface for data collection based on the interface definition information and preset semantic identifiers.

[0026] For example, in order to achieve automated identification and classification management of service interface metadata, it is first necessary to obtain the interface definition information of each service interface from the operating environment of the distributed system, and then filter out the data source class interfaces for data collection based on the interface definition information and preset semantic identifiers.

[0027] Interface definition information refers to the access contract information provided by the service to the outside world, including but not limited to key attributes such as interface name, corresponding parameter structure, request parameter structure, and the service instance to which it belongs. This information is automatically generated and maintained by the distributed framework during the service registration process.

[0028] Data source interfaces refer to service interfaces whose primary function is to query and return core business entity data. They are typically connected to persistent storage media such as databases or caches to support the data retrieval needs of upper-layer applications. Examples include enterprise basic information query interfaces, legal representative information query interfaces, and customer file query interfaces. Interfaces used only for executing operations or triggering processes, such as transaction order placement, payment notifications, and status updates, are not data source interfaces and do not participate in subsequent rule configuration processes. To accurately distinguish between these two types of interfaces, this embodiment uses an automatic identification method based on preset semantic identifier annotations. By adding tags to specific interfaces at the code level, the system can automatically identify which interfaces belong to the data source category during the initialization phase or periodic scanning, thereby avoiding errors and delays caused by relying on manual configuration.

[0029] In some implementations, such as Figure 2 As shown, step S100 includes steps S110-S130: Step S110: Obtain the identifiers of all registered service interfaces in the distributed system through the metadata query interface.

[0030] In a microservice architecture, each service registers its provided interface information with the service registry after startup. In this embodiment, the metadata query interface (such as the MetadataService interface) provided by the distributed framework is used to obtain the set of all registered service interface identifiers in the current system.

[0031] The service interface identifier is a string that uniquely identifies a service interface, typically consisting of the fully qualified name of the interface, its version number, and its service group. The system retrieves a complete list of service interface identifiers at once by calling the metadata query interface, serving as the basic input for subsequent individual parsing. This operation can be triggered at system startup or synchronized periodically via a periodic task to ensure the integrity and timeliness of the interface information. The retrieved service interface identifiers will be used to retrieve detailed information in the next step.

[0032] Step S120: For each service interface identifier, call the metadata service to obtain the corresponding interface definition information.

[0033] As an example, after obtaining the service interface identifier, the system initiates a call for each service interface identifier, requesting the complete definition information of that service interface from the metadata service. The metadata service looks up the corresponding interface description model based on the interface identifier and returns detailed structured data, including request parameters, response parameters, transport protocol, serialization method, etc. Among these, the response parameters directly determine the source of the subsequently configurable rule fields. Each response parameter contains a field name, field type, nesting hierarchy, and field description information. This information together constitutes the metadata view of the interface, providing the foundation for subsequent rule generation.

[0034] All acquired interface definition information will be temporarily stored in memory for later use. This process is entirely automated and requires no manual intervention, ensuring the comprehensiveness and consistency of metadata collection.

[0035] Step S130: If the corresponding service interface is detected to be configured with a preset semantic identifier annotation based on the interface definition information, then the corresponding service interface is determined as a data source class interface for data collection.

[0036] As an example, the key criterion for determining whether an interface is a data source interface is whether it is configured with a specific pre-defined semantic identifier annotation (such as the @MyMetadata annotation). This annotation is a programming language-level metadata marker. When defining a service interface, developers will proactively add this annotation if they believe that the interface is mainly used for data querying and has value for rule configuration.

[0037] When processing each service interface, the system checks whether the corresponding class definition contains the specified annotation. This check is implemented using reflection, dynamically reading the annotation information of the interface class at runtime. If the interface is found to have a preset semantic identifier annotation, it is classified as a data source interface; otherwise, it is considered a non-data source interface and filtered out. In this way, the system can accurately identify data source interfaces that can be used for rule configuration, excluding purely operational interfaces used only for business process control, thereby ensuring the data quality and applicability of subsequent rule generation.

[0038] It should be noted that the definition and application of this annotation are completed by the service provider; the consumer only needs to identify it according to the unified specification. The entire process does not rely on external configuration tables or manual input.

[0039] In addition, this method is not limited to a specific development language or framework; it can be adapted to any technical system that supports metadata annotation capabilities.

[0040] Step S200: Write the interface definition information of the data source class interface into the cache storage unit, and when an interface definition change is detected, update the interface definition information in the cache storage unit in real time by listening to the change event published by the metadata center.

[0041] In some implementations, such as Figure 3 As shown, step S200 includes steps S210-S250: Step S210: When a change in interface definition information is detected, a change event published by the metadata center is received.

[0042] The change event includes the changed service interface identifier and the interface definition information after the change.

[0043] In this step, if the service provider modifies the definition of an interface (such as adding request parameters, deleting response fields, or changing field types), the relevant change information will be published to the metadata center. The metadata center is an independent component in a distributed architecture used to centrally manage non-core metadata (such as interface configuration and method signatures), and it can provide unified metadata access and notification capabilities.

[0044] The service consumers deployed in the system pre-register a metadata change listener. This listener implements the metadata report callback interface and is configured in the local runtime environment. Once the metadata center detects a change in the definition of a service interface, it generates a change event and pushes it to all consumers that have registered listeners via a message channel.

[0045] The change event includes at least two types of information: first, the service interface identifier that has changed, which is used to locate the specific interface; and second, the complete interface definition information after the change, including the latest parameter structure and type definition. After receiving the event, the consumer immediately triggers the local metadata update process.

[0046] Step S220: Compare the changed interface definition information with the historical interface definition information stored in the cache storage unit to identify the changed parameters.

[0047] Upon receiving a change event, the system first reads the historical interface definition information currently stored in the cache storage unit as a comparison benchmark. Then, it compares the interface definition information before and after the change field by field to analyze the specific changes. The comparison mainly includes the response parameters, specifically identifying newly added fields (parameters that exist after the change but not in the historical data), deleted fields (parameters that existed in the historical data but have been removed after the change), type changes (the field type corresponding to the same field name changes (e.g., from String to int), and description or default value modifications (information changes that do not affect the structure but may affect semantic understanding). Through comparative analysis, the system generates a list of changed parameters to clearly indicate the specific fields involved in this change and their change types. This list can be used to subsequently determine whether it affects the execution logic of existing traffic splitting rules.

[0048] Step S230: If the service interface in the change event is a data source interface, then execute the corresponding cache update strategy according to the interface type.

[0049] If the service interface in the change event is a non-core data interface, then step S240 is executed to directly replace the corresponding historical interface definition information with the changed interface definition information.

[0050] If the interface type of the service interface in the change event is a core data interface, then step S250 is executed to mark the associated traffic splitting rule as invalid and then update the interface definition information in the cache storage unit.

[0051] As an example, after confirming the time of the change, the system first verifies whether the service interface belongs to the data source class interface identified in step S100. Only changes to data source class interfaces need to proceed to the next processing step; changes to other non-data source class interfaces are ignored.

[0052] For changes to data source interfaces, the system further implements differentiated update strategies based on their importance level. Interface importance is divided into two categories: core data interfaces and non-core data interfaces. This classification can be configured through a preset list of core interfaces. For example, interfaces that directly affect risk control decisions, such as enterprise information queries and legal representative information queries, are classified as core data interfaces, while other auxiliary query interfaces are considered non-core data interfaces.

[0053] Different interface types have different cache update methods.

[0054] For changes to non-core data interfaces, since the associated traffic distribution rules have a minimal impact on the overall system, the system is allowed to automatically complete the update operation. The system directly overwrites the corresponding entries in the cache storage unit with the changed interface definition information, ensuring that the metadata status is consistent with the latest version. Simultaneously, if a traffic distribution rule configured based on this interface references a deleted or changed field, the system will automatically flag an exception during the rule validation phase, without interrupting the metadata update process itself. This strategy balances flexibility and stability, making it suitable for scenarios with frequent changes but low risk.

[0055] Changes to core data interfaces, especially those involving field deletion or type changes, may directly cause existing traffic splitting rules to malfunction or even result in misjudgments. Therefore, the system adopts a more conservative processing strategy.

[0056] Before updating the cache, the system first queries the rule configuration database to find all traffic splitting rules that reference the interface. For each matching rule, its status field is updated to invalid or pending review, and a reminder notification is sent to the operations or configuration personnel through the management interface, prompting them to re-evaluate and configure the new rule logic.

[0057] After completing the status field marking operations, the system writes the modified interface definition information to the cache storage unit, completing the synchronous update of metadata. This ensures that outdated rules will not be used for traffic control when there are significant changes in the interface structure, effectively preventing business anomalies caused by rule failure.

[0058] In addition, the system also needs to record a complete snapshot of the interface definition information before and after each change and store it in the audit log for subsequent traceability and rollback operations.

[0059] Step S300: The parameters of the interface definition information stored in the cache storage unit are processed in a structured manner to obtain multiple candidate rule fields, and the corresponding rule operation representation set is determined according to the data type in each candidate rule field.

[0060] This step involves extracting suitable fields from the interface definition information and matching them with appropriate operation methods to construct a configurable set of rule elements. This allows non-technical personnel to configure traffic splitting rules through a visual interface. Specifically, the system first parses the interface definition information of the data source interfaces stored in the cache storage unit, focusing on analyzing their response parameters, as these parameters represent the actual business data returned by the service and are the main basis for rule judgment. Through structured parsing of the parameters, fields with business judgment value are identified as candidate rule fields, and applicable rule operation representations are recommended based on the data type of each field, forming a complete rule configuration option library.

[0061] In some implementations, such as Figure 4 As shown, the parameters of the interface definition information stored in the cache storage unit are structured to obtain multiple candidate rule fields, including steps S310-S320: Step S310: Parse each parameter in the interface definition information one by one to obtain the field name, field description and data type of each parameter.

[0062] In this step, the complete interface definition information of each data source class interface is read from the cache storage unit, and its response parameter list is traversed. For each response parameter, the extracted information includes, but is not limited to, field name, field description, and data type. The field name refers to the identifier of the parameter in the data structure, usually in English, such as age, riskLevel, area, etc.; the field description is a Chinese or readable explanation of the field's semantics, used to help users understand its meaning, such as age, risk level, or region; the data type is the specific type information of the field, including basic types (such as integer, floating-point, boolean) and composite types (such as string, enumeration value, array, etc.). These three types of information together constitute a basic metadata view of a parameter, providing a basis for subsequent filtering. It can be understood that all parameters are parsed one by one in this way, thus forming a set of parameters to be evaluated.

[0063] Step S320: If at least one of the field name, field description, and data type meets the corresponding preset filtering conditions, then the corresponding parameter is used as a candidate rule field.

[0064] In this embodiment, a set of preset filtering conditions are set to automatically identify high-quality fields, thereby ensuring that the generated candidate rule fields have practical business judgment significance and avoiding the inclusion of technical fields (such as timestamps, unique numbers, signature values, etc.) in the configuration scope.

[0065] The field name, field description, and data type each correspond to different preset filtering conditions.

[0066] For field names, if a field name contains specific keywords, it is considered to have potential business meaning. The keyword set includes, but is not limited to, common business dimension identifiers such as name, type, status, level, amount, age, gender, area, risk, and category. As long as the field name contains any of these keywords, it is considered to meet the filtering criteria.

[0067] For field descriptions, if the field description contains clear semantic information and is related to business decisions (such as customer risk level or certificate validity period), it can be included in the candidate scope even if the field name is relatively common.

[0068] Regarding data types, this embodiment can specify some suitable data types for use as rule-based judgment conditions. For example, integer and floating-point types can be used for numerical comparisons (such as...). , , , Boolean types are suitable for true / false judgments, while string types are suitable for inclusion or matching operations if their values ​​are limited (e.g., high / medium / low). Fields such as UUID, timestamps, and encrypted strings, because they are not enumerable or lack explicit comparison logic, usually do not meet this condition.

[0069] When a parameter satisfies any of the above preset filtering conditions in at least one of the field name, field description, or data type, the system marks it as a candidate rule field and adds it to the candidate set for display in the subsequent rule configuration interface.

[0070] After parsing and filtering all parameters, a high-quality list of candidate rule fields can be obtained. Each candidate rule field carries its field name, field description, and data type information, which can be used for front-end rendering.

[0071] Furthermore, the system determines the corresponding set of rule operation representations based on the data type of each candidate rule field. This rule operation representation refers to the operator format that the user can choose when configuring rules, such as greater than, less than or equal to, contain, and regular expression matching.

[0072] Specific mapping relationships include, for example, for numeric fields such as integers and floating-point numbers, the supported rule operations include, but are not limited to, those expressed as follows: , , , , , For string fields, if they are multi-value enumerations, `in` (containing a set) is supported; if pattern matching is allowed, `match` (regular expression matching) is supported; for boolean fields, only "" is supported. The operation is used to determine whether it is true or false; other complex types such as dates and nested objects can determine the supported operation representations according to preset mapping relationships.

[0073] It is understandable that this mapping relationship can be pre-configured in the operator mapping table inside the system, and the available operation options for each candidate rule field can be quickly generated by looking up the table.

[0074] The above process not only automates the extraction of rule fields, but also ensures the quality of fields through multiple filtering mechanisms, effectively preventing invalid or low-value fields from entering the configuration process.

[0075] In step S400, when generating the traffic splitting rule, in response to the target field selected by the user based on the candidate rule field, the rule operation representation selected from the corresponding rule operation representation set, and the input rule threshold, a traffic splitting rule containing at least one rule condition is generated.

[0076] In this embodiment, the system provides a visual configuration interface to support users in creating traffic splitting rules through graphical operations. This process is based on the candidate rule fields generated in step S300, allowing users to select fields for judgment and combine them with operators and thresholds to construct specific rule conditions.

[0077] Specifically, when a user enters the rule configuration page, the system first displays a list of candidate rule fields corresponding to the currently selected data source interface. Each field displays its name and description to help the user understand its business meaning. For each candidate rule field, the system further lists its corresponding set of rule operations; for example, numeric fields can be selected... , , For comparison operators, string fields can choose between operations such as IN (inclusive) or MATCH (match).

[0078] Users can select a target field from the candidate list based on their actual business needs, then choose the required rule operation representation from the recommended operation representation set, and fill in the specific rule threshold in the input box. For example, a user can select "age" as the target field and choose... As a representation of the rule operation, and with 60 as the rule threshold, a complete rule condition is formed: .

[0079] A traffic splitting rule can be composed of one or more rule conditions, which can be linked together using logical connectors (such as AND and OR) to form a composite judgment logic. In addition, each rule also needs to be configured with other control attributes, including rule name, application scenario identifier, and remarks, which ultimately form a complete rule entity.

[0080] In some implementations, before generating a traffic splitting rule containing at least one rule condition, the implementation further includes integrity verification of the target field, rule operation representation, and rule threshold, and generates the traffic splitting rule after the verification passes; wherein, integrity verification includes at least one of type compatibility verification, logical consistency check, duplicate detection, and semantic reasonableness judgment, thereby ensuring the technical correctness and business reasonableness of the configured rule.

[0081] The type compatibility validation checks whether the user-input rule threshold matches the data type of the selected target field. For example, if the target field is an integer (int), the rule threshold must be a valid integer and cannot contain non-numeric characters; if the target field is a boolean, the rule threshold can only be true or false; if the target field is a string using the 'in' operator, the rule threshold should be a comma-separated list of multiple values ​​(e.g., Guangdong, Zhejiang); if the target field is a date, the rule threshold must conform to a preset time format standard. If a type mismatch is detected, the system immediately displays an error message and blocks submission to prevent runtime exceptions due to format errors.

[0082] Logical consistency checks are used to identify contradictions or redundant logic within a rule. For example: when there are two mutually exclusive conditions in the same rule (such as...) and Furthermore, when a condition is joined with another condition, the system determines that the combination can never be true and prompts the user to adjust it; or when multiple conditions have significantly overlapping coverage, potentially leading to low execution efficiency, it provides optimization suggestions. This kind of check helps improve the quality and execution efficiency of rules, avoiding the deployment of invalid or inefficient rules.

[0083] Duplicate detection refers to the system querying stored rule configuration records before submission to determine whether rule configurations with the same interface, fields, operation representations, and thresholds already exist in the same application scenario. If identical rule entries exist, it is determined to be a duplicate configuration, and the system refuses to save it, notifying the user that the rule already exists to prevent the accumulation of redundant rules.

[0084] Semantic rationality judgment includes: converting the rule operation representation and the corresponding rule threshold into a question description in natural language; processing the question description based on a question-answering model integrated with an enterprise knowledge base; and judging whether the corresponding rule conditions are reasonable based on the processing results.

[0085] Specifically, the system converts the current rule condition into a problem form that can be described in natural language, that is, it splices the target field, the rule operation representation, and the rule threshold into a complete sentence according to a preset template. For example, the original rule condition could be "gender in male", and the converted problem description could be "Is it reasonable that the gender includes male? Please return true or false". Subsequently, the system calls the Q&A model integrating the enterprise knowledge base through an internal interface and sends the above problem description as input to the model. The Q&A model has been trained and embeds the enterprise's business rules, data enumeration range, and industry knowledge, and can make intelligent judgments on the problem. For example, in the enterprise data specification, the legal values of the gender field are only male and female. Therefore, for the condition "gender in male", the model returns true; if the user configures "gender in unknown" and unknown is not within the legal enumeration range, the model returns false.

[0086] The system receives the boolean judgment result returned by the Q&A model; if the result is true, it considers that the rule condition is semantically reasonable and continues with the subsequent process; if the result is false, it determines that the rule may have a semantic error, the system interrupts the submission process, and prompts the user at the front end that "the configured rule does not conform to the business specification, please verify and re-enter". In this way, the system can not only verify the syntactic legality of the rule, but also achieve an automatic review of its business semantic reasonableness, thereby reducing the risk of rule errors caused by human misconfiguration.

[0087] It should be noted that the Q&A model is deployed in the enterprise internal environment, and its call process is completed through a secure communication protocol, without involving external public large model services, ensuring data security and compliance.

[0088] In some embodiments, each rule condition of the shunt rule further includes a rule execution order and a traffic application ratio; among them, the rule execution order is used to determine the matching priority between multiple rule conditions; the traffic application ratio is used to indicate that for the current rule condition, in the received request traffic, a part of the traffic is randomly selected according to a preset probability to perform the matching judgment of the current rule condition.

[0089] It can be understood that the rule execution order can be an integer greater than zero. The system sorts multiple conditions within the same rule in ascending order according to this value and performs matching judgments in sequence to ensure the certainty and predictability of the rule logic.

[0090] The traffic application ratio, a value between 0 and 1, retained to a maximum of four decimal places, represents the proportion of requests that are matched against this rule condition. The system uses a consistent hashing algorithm to sample incoming requests, and only selected requests are evaluated according to the rule condition; the remaining requests skip this condition and continue processing. For example, when the traffic application ratio for a certain rule condition is set to 0.3, the system will use approximately 30% of requests to test the validity of this condition, while the remaining 70% of requests will remain unaffected. This mechanism supports small-volume validation and smooth deployment of new rules, effectively reducing the production environment risks caused by configuration errors.

[0091] This embodiment automatically acquires the interface definition information of service interfaces in a distributed system and intelligently classifies the interfaces using preset semantic identifiers, effectively distinguishing data source interfaces used for data collection. This enables automated identification and precise filtering of metadata. The embodiment writes the interface definition information into a cache storage unit and monitors change events published by the metadata center in real time to detect interface changes, ensuring consistency between the metadata status and the actual service definition. Through structured processing of interface parameters, candidate rule fields with business judgment value are extracted, and adaptive rule operation representation sets are dynamically generated based on field types, providing a high-quality input foundation for rule configuration. When generating traffic splitting rules, users can flexibly configure based on target fields, rule operation representations, and rule thresholds. Before submission, type compatibility verification, logical consistency checks, duplicate detection, and semantic rationality judgment based on a question-and-answer model integrated with an enterprise knowledge base are completed, significantly improving the accuracy and security of rule configuration. This embodiment eliminates the need for manual maintenance of configuration tables, reducing reliance on developers. Non-technical personnel can independently complete most rule configuration tasks, greatly improving configuration efficiency and system maintainability.

[0092] Figure 5 A schematic diagram of a traffic splitting rule generation apparatus according to an embodiment of this application is shown. Exemplarily, the traffic splitting rule generation apparatus includes: The filtering module 100 is used to obtain the interface definition information of each service interface in the distributed system, and filter out the data source class interfaces for data collection based on the interface definition information and preset semantic identifiers.

[0093] The update module 200 is used to write the interface definition information of the data source class interface into the cache storage unit, and when an interface definition change is detected, it updates the interface definition information in the cache storage unit in real time by listening to the change event published by the metadata center.

[0094] The determination module 300 is used to perform structured processing on the parameters of the interface definition information stored in the cache storage unit to obtain multiple candidate rule fields, and determine the corresponding rule operation representation set according to the data type in each candidate rule field.

[0095] The generation module 400 is used to generate a traffic splitting rule containing at least one rule condition in response to the target field selected by the user based on the candidate rule field, the rule operation representation selected from the corresponding rule operation representation set, and the input rule threshold when generating the traffic splitting rule.

[0096] It is understood that the apparatus in this embodiment corresponds to the traffic splitting rule generation method in the above embodiments, and the options in the above embodiments are also applicable to this embodiment, so they will not be described again here.

[0097] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the above-described traffic splitting rule generation method or the above-described traffic splitting rule generation apparatus.

[0098] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0099] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0100] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned terminal device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0101] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0102] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0103] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0104] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for generating traffic splitting rules, characterized in that, include: Obtain the interface definition information of each service interface in the distributed system, and filter out the data source class interface for data collection based on the interface definition information and preset semantic identifiers. The interface definition information of the data source class interface is written into the cache storage unit, and when an interface definition change is detected, the interface definition information in the cache storage unit is updated in real time by listening to the change event published by the metadata center. The parameters of the interface definition information stored in the cache storage unit are processed in a structured manner to obtain multiple candidate rule fields, and the corresponding rule operation representation set is determined according to the data type in each candidate rule field; When generating traffic splitting rules, in response to the target field selected by the user based on the candidate rule field, the rule operation representation selected from the corresponding rule operation representation set, and the input rule threshold, a traffic splitting rule containing at least one rule condition is generated.

2. The method for generating traffic splitting rules according to claim 1, characterized in that, Before generating the traffic splitting rule containing at least one rule condition, the process further includes: The target field, the rule operation representation, and the rule threshold are subjected to integrity verification, and the traffic splitting rule is generated after the verification passes. The integrity verification includes at least one of type compatibility verification, logical consistency check, duplicate detection, and semantic reasonableness judgment.

3. The method for generating traffic splitting rules according to claim 1, characterized in that, The process of obtaining the interface definition information of each service interface in the distributed system, and filtering out data source class interfaces for data collection based on the interface definition information and preset semantic identifiers, includes: Obtain the identifiers of all registered service interfaces in the distributed system through the metadata query interface; For each of the aforementioned service interface identifiers, the metadata service is invoked to obtain the corresponding interface definition information; If, based on the interface definition information, a corresponding service interface is detected to be configured with a preset semantic identifier annotation, then the corresponding service interface is determined to be the data source class interface used for data collection.

4. The method for generating traffic splitting rules according to claim 1, characterized in that, The step of updating the interface definition information in the cache storage unit in real time by listening to change events published by the metadata center when an interface definition change is detected includes: When a change in the interface definition information is detected, a change event published by the metadata center is received; wherein, the change event includes the changed service interface identifier and the changed interface definition information; The modified interface definition information is compared with the historical interface definition information stored in the cache storage unit to identify the modified parameters; If the service interface in the change event is the data source type interface, then the corresponding cache update strategy is executed according to the interface type; If the interface type of the service interface in the change event is a non-core data interface, then the corresponding historical interface definition information is directly replaced with the changed interface definition information. If the interface type of the service interface in the change event is a core data interface, then the associated traffic splitting rule is marked as invalid and the interface definition information in the cache storage unit is updated.

5. The method for generating traffic splitting rules according to claim 1, characterized in that, The parameters of the interface definition information stored in the cache storage unit are structured to obtain multiple candidate rule fields, including: Each parameter in the interface definition information is parsed one by one to obtain the field name, field description and data type of each parameter; If at least one of the field name, the field description, and the data type satisfies the corresponding preset filtering condition, then the corresponding parameter will be used as a candidate rule field.

6. The method for generating traffic splitting rules according to claim 1, characterized in that, Each rule condition of the traffic splitting rule also includes the rule execution order and the traffic application ratio; The rule execution order is used to determine the matching priority among multiple rule conditions; the traffic application ratio is used to indicate that, for the current rule condition, a portion of the received request traffic is randomly selected according to a preset probability to perform the matching judgment of the current rule condition.

7. The method for generating traffic splitting rules according to claim 2, characterized in that, The semantic rationality judgment includes: The rule operation representation and the corresponding rule threshold are converted into a problem description in natural language. The question description is processed using a question-answering model based on an integrated enterprise knowledge base, and the reasonableness of the corresponding rule conditions is determined based on the processing results.

8. A diversion rule generation device, characterized in that, include: The filtering module is used to obtain the interface definition information of each service interface in the distributed system, and filter out the data source class interfaces for data collection based on the interface definition information and preset semantic identifiers. The update module is used to write the interface definition information of the data source class interface into the cache storage unit, and when an interface definition change is detected, to update the interface definition information in the cache storage unit in real time by listening to the change event published by the metadata center; The determination module is used to perform structured processing on the parameters of the interface definition information stored in the cache storage unit to obtain multiple candidate rule fields, and determine the corresponding rule operation representation set according to the data type in each candidate rule field; The generation module is used to generate a traffic splitting rule containing at least one rule condition in response to the target field selected by the user based on the candidate rule field, the rule operation representation selected from the corresponding rule operation representation set, and the input rule threshold when generating traffic splitting rules.

9. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the traffic splitting rule generation method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed on a processor, implements the method for generating traffic splitting rules according to any one of claims 1-7.

Images