Fine configuration method and system based on strategy mode

Abstract

The invention provides a fine configuration method and system based on a strategy mode, and the method comprises the steps: defining themes used for abstracting entrance traffic, order distribution and other events through a configuration system, and configuring a basic data source and a data processing rule for each theme, wherein the data processing rule supports a user to carry out code development implementation in a basic class of each service line according to service requirements; the system automatically stores theme data to middleware, matches a corresponding theme through a strategy mode after receiving a user request, performs secondary data processing according to a configuration rule and returns a result; the technical effects of flexible configuration mode, quasi-real-time index calculation, support of multi-source data access, high-concurrency scene adaptation and good expansibility in flow fine management are realized, and the service operation demand change can be quickly responded.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, and in particular to a fine-grained configuration method and system based on the strategy pattern. Background Technology

[0002] In internet business operations, service providers face the challenge of rationally allocating and managing user traffic. This requires comprehensive consideration of multiple dimensions, including user attention, purchase intention, merchant rights, blacklists and whitelists, and support for subsequent data analysis. Traditional solutions often employ strategies such as user segmentation, dynamic pricing, and on-demand allocation. However, existing technologies suffer from the following problems: high coupling between business rules and system architecture leads to low system iteration efficiency when business logic is complex and constantly changing; rule configuration lacks flexibility, making it difficult to customize settings for different traffic entry points; data synchronization latency is high, failing to respond to changes in operational metrics in near real-time; and scalability is limited, making it difficult to adapt to the needs of rapid business development. Therefore, there is an urgent need for a technical solution that can decouple business rules from the system, support fine-grained configuration, and possess high availability and scalability. Summary of the Invention

[0003] The purpose of this invention is to provide a fine-grained configuration method and system based on strategy patterns, thereby solving the aforementioned problems existing in the prior art.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0005] A fine-grained configuration method based on the strategy pattern includes:

[0006] Define topics in the configuration system. Topics are used to abstract ingress traffic, order assignment types of events or transactions.

[0007] Configure the basic data source and data processing rules for the theme. The data processing rules are implemented by users in the basic classes of their respective business lines according to their business needs.

[0008] Upon receiving a user request, the strategy pattern is used to match the corresponding topic;

[0009] The data on the topic is processed a second time according to the data processing rules, and the processing results are returned.

[0010] Furthermore, the types of topics include inbound traffic and order allocation, where inbound traffic represents whether access is allowed under a specified dimension, and order allocation represents the set of objects that can be allocated.

[0011] Furthermore, the basic data source is prepared through database and / or interface connection, and refreshed according to the configured automatic synchronization time or event triggering mechanism; the system automatically stores the topic data in the middleware, and refreshes the topic data in the middleware according to the configured automatic synchronization time.

[0012] Furthermore, the system is applied to refined traffic management, including one or more of the following: user segmentation strategy, dynamic pricing strategy, and on-demand allocation strategy. The user segmentation strategy divides users into different levels and allocates different resources to them. The dynamic pricing strategy adjusts service prices according to real-time business scenario needs. The on-demand allocation strategy increases resource allocation for high-quality customers and reduces resource allocation for system disruptors.

[0013] This invention also provides a fine-grained configuration system based on the strategy pattern, comprising:

[0014] The theme configuration module is used to define themes, set theme types, and configure basic data sources and data processing rules. Themes are used to abstract entry traffic, order allocation type events or transactions.

[0015] The strategy matching module is used to match the corresponding topic using strategy patterns after receiving a user request;

[0016] The data processing module is used to perform secondary processing on the data of the topic according to the data processing rules and return the processing results.

[0017] Furthermore, the system also includes a data synchronization module, used to refresh subject data in the underlying data source and / or middleware according to the configured automatic synchronization time or event-triggered mechanism.

[0018] Furthermore, the system also includes a middleware storage module for automatically storing topic data to support high-concurrency access.

[0019] Furthermore, the data processing rules are implemented by users in the basic classes of their respective business lines according to their business needs. The middleware storage module automatically stores the topic data in the middleware and refreshes it according to the configured automatic synchronization time.

[0020] Furthermore, the system is applied to refined traffic management, including one or more of user segmentation strategies, dynamic pricing strategies, and on-demand allocation strategies.

[0021] In another embodiment, a computer-readable storage medium stores a computer program that, when executed by a processor, implements the above-described method.

[0022] The beneficial effects of this invention are:

[0023] This invention employs a strategy pattern combined with a theme abstraction mechanism to unify heterogeneous business events into themes. By managing data sources and processing rules through configuration, it decouples business logic from system architecture, significantly improving configuration flexibility. Automatic synchronization and event triggering mechanisms support near real-time calculation and dynamic updates of operational metrics, enhancing business response timeliness. Middleware storage mechanisms effectively support data access performance in high-concurrency scenarios. Providing code development interfaces allows users to implement personalized business logic in base classes, balancing system flexibility with support for complex business scenarios. Theme-based configuration allows for customized settings for different traffic entry points, enabling accurate data statistics and operational decision support. This solution boasts high availability and good scalability, allowing for functional expansion and upgrades as business grows. It has practical application value in scenarios such as user segmentation, dynamic pricing, and on-demand allocation for refined traffic management. Attached Figure Description

[0024] Figure 1 This is a functional architecture diagram of the present invention;

[0025] Figure 2 This is the business process diagram of the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0027] Reference Figure 1 and Figure 2 The fine-grained configuration method based on the strategy pattern shown includes:

[0028] S1. Define topics in the configuration system. Topics are used to abstract ingress traffic, order assignment type events or transactions;

[0029] Specifically, this step involves the system administrator creating a topic object through a visual interface in the configuration system's management backend. This topic object serves as a unified abstraction carrier for heterogeneous business events. The definition process is not simply about naming business events, but rather about constructing a topic model with metadata description capabilities. This model includes four core dimensions: topic identifier, business type attributes, data contract specifications, and lifecycle status.

[0030] The system first receives a topic identifier input by the administrator. This identifier is unique within the global configuration space and uses a hierarchical naming mechanism, such as the format "business domain.scenario name.version number," to ensure that the topic can be accurately addressed in a distributed environment. Subsequently, the system prompts the administrator to select a business type attribute for the topic. This attribute is an enumerated metadata type. The system pre-configures two basic business templates: "entry traffic control" and "intelligent order allocation," and also supports adding custom business types through an extended registration mechanism.

[0031] The innovation of the topic model lies in its definition of data contract specifications: the system mandates that administrators declare the data entity structure, field dependencies, and data quality constraints for each topic. For inbound traffic topics, the contract specification includes mandatory fields such as user identity, access resource identifier, and permission verification level; for order allocation topics, the contract specification includes fields such as order attributes, target object characteristics, and matching priority algorithm identifier. This mandatory contract mechanism standardizes heterogeneous business events into a unified data structure before they enter the policy processing flow, eliminating the processing complexity caused by differences in business semantics.

[0032] In terms of lifecycle status, the system maintains four states for each topic: "Draft," "Published," "Offline," and "Archived," and establishes triggering conditions and approval processes for state transitions. When a topic is in the "Published" state, its configuration information is locked in read-only mode to prevent accidental modifications at runtime from causing policy execution anomalies. When business requirements change, administrators can create new versions of the topic, and the old version automatically transitions to the "Offline" state. The system uses a version routing mechanism to ensure that currently executing requests use the old version configuration, while new requests use the new version configuration, achieving smooth hot migration.

[0033] Furthermore, the system introduces the concept of a dynamic configuration context during the topic definition phase. This context stores the environment variables, external service dependency declarations, and resource quota limits required for the topic to run. For inbound traffic topics, the context includes the current system load threshold and degradation switch status; for order allocation topics, the context includes the capacity limit of available target objects and circuit breaker policy parameters. This mechanism of binding the runtime environment to topic definition enables the policy pattern to automatically perceive and adapt to its execution environment when handling different topics, avoiding the consistency maintenance difficulties caused by the separation of environment configuration and business rules in traditional rule engines.

[0034] Through the above definition process, a topic is no longer a simple business identifier, but a composite object with self-description capabilities, data contract constraints, lifecycle management, and environmental awareness. This abstraction mechanism, for the first time, migrates the concept of "topic" from message queues to the application context of the strategy pattern, and expands the capabilities of metadata description and contract specification. This allows rule processing modules, which originally needed to be developed independently for each type of business event, to be covered by a unified topic-strategy processing framework, achieving decoupling between business semantics and technical implementation. This lays a scalable architectural foundation for subsequent dynamic strategy matching and secondary data processing.

[0035] S2. Configure the basic data source and data processing rules for the theme. The data processing rules are developed and implemented by the user in the basic class of their respective business line according to their business needs.

[0036] Specifically, this step involves the system entering the data source and rule configuration phase after the topic definition is completed. The innovation of this phase lies in constructing a hybrid rule definition paradigm of "declarative configuration and imperative code development," breaking through the limitations of traditional rule engines that are purely configuration-based or purely script-based.

[0037] First, for configuring the basic data sources, the system employs a dynamic data source registration mechanism. Instead of directly entering database connection strings or interface addresses in the configuration interface, administrators encapsulate external data services as standardized data providers through data source proxy registration. The system pre-configures various data source connectors, including relational databases, non-relational databases, HTTP interfaces, and message queues, each implementing a unified data contract interface. When configuring a data source for a topic, the administrator only needs to select the data source type and enter the service discovery identifier. The system automatically resolves the actual data service address through the service registry and establishes a data access channel with circuit breaking, degradation, and rate limiting capabilities. More importantly, the system supports configuring multiple heterogeneous data sources for the same topic and allows administrators to declare the primary / backup relationship and fallback switching order between data sources. When the primary data source becomes unavailable, the system automatically switches to the backup data source, ensuring the availability of data for rule calculations. This dynamic registration and intelligent switching mechanism for multi-source heterogeneous data enables hot-swapping of data sources without restarting topic configuration, solving the pain point of traditional configuration systems requiring service restarts for data source changes.

[0038] In the data processing rule configuration phase, the system provides a two-layer configuration architecture. The first layer is the rule metadata configuration layer, where administrators define information such as rule name, rule version, trigger condition description, and input / output parameter structure through a visual interface. This metadata is persisted by the system and used for rule lifecycle management. The second layer is the rule logic implementation layer, which is the core of this invention: the system does not provide a graphical rule orchestration or script entry interface, but instead forces users to implement specific business logic in their own independently maintained base classes by inheriting the system's pre-defined abstract strategy base class, using a code engineering approach. This design may seem to increase the barrier to entry, but it actually solves the expressive limitations of purely configurable rule engines in complex business scenarios.

[0039] The abstract strategy base class is defined by the system, encapsulating cross-cutting concerns such as context management, exception handling, performance monitoring, and version compatibility detection for rule execution. Users only need to focus on the business logic itself, overriding the calculation methods in derived classes. The system dynamically scans the rule implementation classes provided by business lines at runtime using Java's SPI mechanism or .NET's plugin loading mechanism, binding them to rule metadata. Each business line's rule implementation class is independently packaged, deployed, and stored in a separate code repository. The system precisely controls the currently active rule version for each topic through a version mapping table in the configuration center. This physical isolation mechanism between business lines ensures the independence of rule development by different business teams while avoiding rule code conflicts.

[0040] Furthermore, the system provides hot-update capabilities for rule code development. When a business line submits a new rule version, the system uses bytecode enhancement technology to dynamically load the new rule implementation class into the runtime strategy factory without restarting the topic service. A dual-caching mechanism is used to smoothly remove the old version of the rule and implement a canary release of the new version. The new version of the rule initially only takes effect on test traffic; after verification, the traffic proportion is gradually increased until it completely replaces the old version. This hot-update and canary release mechanism for rule code enables changes to complex business logic to take effect almost in real time and provides rollback capabilities, greatly reducing the risk of business iteration.

[0041] The configuration of data processing rules also introduces a rule dependency declaration mechanism. In the rule metadata, users can declare other topic computation results or external service calls that the current rule depends on. Before executing a rule, the system automatically constructs a dependency graph and detects circular dependencies. If rule A depends on the computation result of rule B, the system will first trigger the execution of rule B and cache its result in the rule context for rule A to use. This dependency management mechanism makes rule reuse and combination possible, avoids redundant computation, and improves the efficiency of rule execution.

[0042] Furthermore, the system provides built-in auditing and tracing capabilities for rule code development. Each time a rule is executed, the system automatically records information such as the rule version, execution time, input / output snapshots, and exception stack traces, forming a rule execution trajectory. When operational results deviate from expectations, the execution path of a specific request can be replayed through a visual traceability interface to accurately pinpoint logical defects. This capability transforms the black-box execution of traditional rule engines into a white-box visibility, significantly reducing the operational and maintenance difficulty of complex rule systems.

[0043] Through the above configuration mechanism, this step elevates the definition of rules from static configuration files to versionable, independently deployable, hot-updateable, and dependency-manageable code assets. This results in a qualitative leap in the expressiveness, reusability, and governance capabilities of business rules, providing flexible and powerful rule support for the precise execution of strategy patterns.

[0044] S3. After receiving a user request, use the strategy pattern to match the corresponding topic;

[0045] This step specifically involves the system initiating a policy matching process after receiving a user request. The innovation of this process lies in the construction of an intelligent matching mechanism that is "request context aware and dynamic orchestration of policy instances," which breaks through the limitations of static policy mapping tables in traditional policy patterns.

[0046] When a request enters the system gateway, the request parsing engine first performs deep semantic deconstruction of the request. Instead of simply extracting the URL path or topic identifier from the message header, it constructs a contextual profile of the request using multi-dimensional feature vectors. These feature vectors include dynamic parameters such as the request's origin channel, user identity attributes, business scenario tags, real-time risk control score, and system load level. The system pre-defines matching rule expressions for each topic. These expressions are not hard-coded conditional statements but rather matching patterns described using a domain-specific language (DSL). For example, a topic matching rule can be described as: "When the request originates from a mobile app, the user's intent score is higher than a threshold, and the current system CPU load is below 80%, the request belongs to this topic." Upon receiving the request context profile, the system's built-in matching rule engine performs real-time calculations using the feature values ​​in the profile and the matching rules for all topics. Through rule dependency graph optimization and conditional short-circuiting algorithms, it completes topic determination within milliseconds.

[0047] More importantly, this invention introduces an elastic containerized management mechanism for policy instances in the implementation of the policy pattern. Traditional policy patterns load all policy classes into memory at application startup, forming a static policy mapping table, requiring an application restart for policy changes. This system, upon matching a target topic, does not directly call the policy instance in local memory, but instead initiates a scheduling request to the policy container orchestration service. This orchestration service maintains a pool of policy instances, deployed independently as microservice containers, with each topic corresponding to one or more policy container replicas. The orchestration service dynamically selects the optimal policy container instance based on current request characteristics and system resource status. For example, when it detects that the rule calculation logic for a certain topic consumes high CPU resources, the orchestration service automatically expands the number of container replicas for that topic and distributes requests using a load balancing algorithm; when a topic has not received requests for a long time, the orchestration service automatically reduces its container replicas to zero, releasing system resources. This "on-demand start / stop, elastic scaling" mechanism for policy instances allows for precise allocation of policy execution resources, avoiding the resource waste caused by all policies residing in memory in traditional solutions.

[0048] The policy matching process also incorporates version routing and traffic coloring capabilities. Each topic's configuration can maintain multiple policy versions, each associated with a policy container image. While matching topics, the system determines whether to route requests to a stable version of the policy container or a new version based on the traffic coloring markers (such as canary testing markers) carried in the request. For requests without coloring markers, the system defaults to a canary release strategy, automatically redirecting a small portion of traffic to the new version container. By monitoring metrics such as the new version's processing success rate and response time, the system automatically decides whether to increase the proportion of traffic to the new version. This canary release mechanism, built into the policy matching process, allows for seamless integration of business rule iterations and policy execution, without relying on an external release platform.

[0049] Furthermore, the policy matching process integrates intelligent degradation and circuit breaker protection. When the rule engine detects that the matching time for a topic exceeds a set threshold, or the error rate returned by the policy container exceeds the health threshold, the system automatically triggers a degradation strategy, temporarily switching the matching rules for that topic to a simplified mode: instead of executing complete rule condition calculations, it adopts a cached decision based on historical matching results. Simultaneously, the system sends a circuit breaker command to the policy orchestration service, suspending the distribution of policy containers to that topic to prevent the fault from spreading. The degradation and circuit breaker status are recorded in the topic's metadata in real time and highlighted in the management interface, allowing for manual restoration after intervention by operations personnel. This built-in fault tolerance mechanism at the policy matching layer ensures system availability when rules are abnormal or resources are scarce.

[0050] The policy matching process also features cross-topic policy orchestration capabilities. When the rule processing of a single topic cannot meet complex business needs, administrators can declare a "policy chain" in the topic configuration to chain multiple topics sequentially. When the system performs policy matching, if it recognizes that the current topic is configured with a policy chain, it automatically passes the request to each topic in the chain for processing. The output of the previous topic becomes the input of the next topic, forming a pipelined rule processing flow. For example, a user request first goes through the "Entry Flow Control" topic for access permission verification, then enters the "User Leveling" topic to calculate the level, and finally enters the "Resource Allocation" topic to determine the accessible content. The policy chain mechanism enables the combination and reuse of rules, with each topic focusing on a single responsibility, improving the maintainability of the rule system.

[0051] Through the above mechanism, this step upgrades the traditional static strategy lookup to an intelligent matching process with context awareness, elastic scheduling, canary release, fault tolerance and degradation, and chained orchestration capabilities. This enables the strategy pattern to be executed stably, efficiently, and flexibly in high-concurrency and dynamically changing business environments, providing key support for near real-time response to fine-grained configuration.

[0052] S4. Perform secondary processing on the data of the topic according to the data processing rules and return the processing results.

[0053] Specifically, this step involves the system entering the rule execution and data processing phase after policy matching is completed. The innovation of this step lies in the construction of a "context-enhanced pipeline-style rule execution engine," which enables data processing to leap from static computation to dynamic orchestration, and from single-point execution to end-to-end observation.

[0054] Once a policy instance for the target topic is activated, the system first constructs the processing context for this request. This context is not simply a collection of parameters, but a hierarchical runtime environment containing the original request data, topic configuration metadata, policy version information, dependency data snapshots, external service call handles, and a rule execution trajectory recorder. The context is implemented using immutable data structures, ensuring that intermediate results at each stage of rule execution are traceable but not accidentally tampered with. Crucially, the context has built-in data lineage tracking capabilities, automatically recording how each piece of data is transformed from its original data source by various rules, what numerical changes occur, and which dependent rules reference it, forming a complete lineage graph. When operational results are abnormal, this graph can be used to trace back to specific data sources or rule nodes for precise troubleshooting.

[0055] The rule execution engine employs a pipeline-filter architecture to decompose data processing rules. Traditional rule execution typically treats a rule as a single, monolithic function, completing the calculation all at once. This system breaks down the rule code developed by the business line into multiple logical stages: input validation, data completion, core calculation, result verification, and output formatting. Each stage is encapsulated as an independent filter, and context objects are passed between filters via pipelines. This architecture makes rule execution observable and manageable. System administrators can dynamically enable or disable filters; for example, temporarily skipping the result verification stage to improve response speed when the system load is too high; or adding log output to each filter in debug mode, achieving end-to-end tracing without modifying the business code.

[0056] During the core computation phase, the execution engine introduces intelligent caching and incremental calculation mechanisms. For computationally expensive rules, the engine does not recalculate the entire dataset every time; instead, it analyzes the change fingerprint of the input data. If the input data for the current request and the data in the historical cache have not changed in key fields, the engine directly returns the cached result; if only some fields have changed, the engine performs local recalculation only for the changed fields and their downstream dependencies, significantly reducing computational overhead. This mechanism tracks data dependencies through version vectors, automatically invalidating relevant cached entries when upstream data sources change, ensuring the real-time performance and accuracy of the computation results.

[0057] To support the canary release and A / B testing of rules, the execution engine supports parallel execution of multiple rule versions. When a new version of a rule exists for a given topic, the engine can route the same request to both the stable and new version's policy containers simultaneously, but only returns the stable version's result to the user. The execution result of the new version is recorded in a shadow database, and the system backend automatically compares the output differences, performance metrics, resource consumption, and other dimensions of the two versions to generate a version health report. Only when the new version consistently outperforms the stable version in multiple metrics and the differences are within acceptable thresholds will the system automatically increase the traffic proportion of the new version. This mechanism of parallel verification of rule versions in the production environment provides a scientific evaluation method for the iterative updates of business rules, avoiding the rollback risks associated with traditional direct version switching.

[0058] The rule execution process also incorporates adaptive circuit breaking and intelligent degradation mechanisms. The engine monitors real-time metrics for rule execution. When the response time of a rule exceeds a dynamic baseline (which is adaptively adjusted based on historical execution data) or the error rate suddenly increases, the circuit breaker is triggered. Subsequent requests skip the complex calculation logic of that rule and directly return the preset degradation result. Simultaneously, the engine initiates a degradation recovery probe for that rule, attempting to execute the complete rule with minimal traffic. If the success rate recovers, the circuit breaker is gradually closed. During the circuit breaker period, the system notifies operations and maintenance personnel to intervene and investigate through an alarm channel, and records the circuit breaker event in the topic's metadata as a basis for rule optimization.

[0059] Before returning the processing result, the execution engine dynamically desensitizes and personalizes the rendering. Based on the requester's identity attributes and permission level, the engine automatically removes sensitive fields from the result. For example, when the request comes from a regular user, the result does not include the internally calculated score; when the request comes from a senior administrator, the result includes detailed rule execution traces and data lineage information. Furthermore, the system supports configuring different output templates for requests from different channels, and the same calculation result can be rendered in multiple formats such as JSON, XML, and HTML cards, achieving "one calculation, multiple presentations."

[0060] Ultimately, the processing results are not returned all at once. For complex rule calculations that take a long time, the system employs a streaming response mechanism. The engine pushes intermediate states to the client via Server-Sent Events or WebSockets as it performs the calculations, allowing the client to monitor the calculation progress in real time and improving the user experience. After the calculations are complete, the final results are cached in multi-level storage: hot data is stored in Redis for high-frequency access, lukewarm data is stored in a time-series database for statistical analysis, and cold data is archived in object storage for auditing and traceability, maximizing the value of the calculation results.

[0061] Through the above mechanism, this step upgrades data processing from a simple function call to an intelligent processing flow with context awareness, incremental calculation, multi-version verification, circuit breaking and degradation, dynamic desensitization, and streaming return, so that rule execution meets the production-level fine requirements in four dimensions: performance, reliability, observability, and flexibility.

[0062] Furthermore, the types of topics include inbound traffic and order allocation, where inbound traffic represents whether access is allowed under a specified dimension, and order allocation represents the set of objects that can be allocated.

[0063] The system defines two topic types: the first is the "entry traffic" topic, used to control user access permissions, such as the "new car series traffic distribution" topic; the second is the "order allocation" topic, used to determine allocable targets, such as the "high-intent order allocation" topic. For the "high-intent order allocation" topic, the system determines the set of sales targets to which the order can be allocated based on the matching degree between order attributes and sales consultant capabilities. Both topic types use a unified strategy pattern matching mechanism, but the processing rules are customized according to the business type.

[0064] Furthermore, the basic data source is prepared through database and / or interface connection, and refreshed according to the configured automatic synchronization time or event triggering mechanism; the system automatically stores the topic data in the middleware, and refreshes the topic data in the middleware according to the configured automatic synchronization time.

[0065] In this embodiment, the basic data source is connected in two ways: user information is directly connected to a MySQL database, and merchant benefits data is obtained through an HTTP interface call. The system is configured to automatically synchronize user information in the database every hour, and an event trigger mechanism is set up: when the interface pushes a merchant benefits change event, data synchronization is immediately triggered. Thematic data is automatically stored in Redis middleware and configured to be refreshed every 30 minutes to ensure near real-time data performance.

[0066] Furthermore, the system is applied to refined traffic management, including one or more of the following: user segmentation strategy, dynamic pricing strategy, and on-demand allocation strategy. The user segmentation strategy divides users into different levels and allocates different resources to them. The dynamic pricing strategy adjusts service prices according to real-time business scenario needs. The on-demand allocation strategy increases resource allocation for high-quality customers and reduces resource allocation for system disruptors.

[0067] In this embodiment, the data processing rules are implemented by operations personnel through code development in the basic business line classes. The system is applied to a scenario of refined traffic management: when executing a user segmentation strategy, the code implements the logic for calculating user purchase intention scores, classifying users into high, medium, and low intention levels; when executing a dynamic pricing strategy, the code implements a price fluctuation algorithm to adjust service prices based on real-time supply and demand; when executing an on-demand allocation strategy, the code implements resource allocation weight calculation, increasing the allocation weight for high-quality customers and decreasing the allocation weight for malicious users.

[0068] This invention also provides a fine-grained configuration system based on the strategy pattern, comprising:

[0069] The theme configuration module is used to define themes, set theme types, and configure basic data sources and data processing rules. Themes are used to abstract entry traffic, order allocation type events or transactions.

[0070] The strategy matching module is used to match the corresponding topic using strategy patterns after receiving a user request;

[0071] The data processing module is used to perform secondary processing on the data of the topic according to the data processing rules and return the processing results.

[0072] Furthermore, the system also includes a data synchronization module, used to refresh subject data in the underlying data source and / or middleware according to the configured automatic synchronization time or event-triggered mechanism.

[0073] Furthermore, the system also includes a middleware storage module for automatically storing topic data to support high-concurrency access.

[0074] Furthermore, the data processing rules are implemented by users in the basic classes of their respective business lines according to their business needs. The middleware storage module automatically stores the topic data in the middleware and refreshes it according to the configured automatic synchronization time.

[0075] Furthermore, the system is applied to refined traffic management, including one or more of user segmentation strategies, dynamic pricing strategies, and on-demand allocation strategies.

[0076] In another embodiment, a computer-readable storage medium stores a computer program that, when executed by a processor, implements the above-described method.

[0077] In this embodiment, the system constructs a strategy platform architecture with "topics" as the atomic capability unit. Through the collaborative innovation of each module, it realizes the leap from static configuration to dynamic assetization of business rules.

[0078] The theme configuration module is not a traditional form-based configuration interface, but rather a theme factory with metadata-driven capabilities. When an administrator creates a theme, the system mandates the declaration of the theme's data contract specifications, including the field dependency graph of input entities, integrity constraints of output results, and data quality circuit breaker thresholds. For inbound traffic themes, the contract pre-defines user identity penetration verification rules to ensure that user identifiers in access requests are traceable. For order allocation themes, the contract mandates that the missing rate of key fields such as order amount and geographic location must not exceed a set value; otherwise, a data completion filter is automatically triggered. More importantly, the theme configuration module supports defining dependency networks between themes, allowing complex business logic to be broken down into multiple sub-themes, and declaring data flow paths to form a theme topology graph. This module has a built-in version timestamp mechanism, automatically generating a version snapshot with each configuration change. Older version themes remain read-only in runtime, new requests are routed to the latest version by default, and long-lived connection requests can continue to maintain the old version context, achieving smooth migration. Theme configurations are serialized into declarative configuration files and stored in a distributed configuration center. GitOps-style version management is supported. Configuration releases must undergo automated contract verification in the pre-release environment to ensure syntax correctness and data integrity.

[0079] In the request parsing phase, the strategy matching module innovatively constructs a request context enhancer. This enhancer not only extracts request parameters but also adds dynamic context tags to the request by calling user profiling services, real-time risk control services, and system capacity assessment services. For example, for a request regarding a user tiered strategy, the enhancer automatically injects a summary of the user's behavior sequence over the past 7 days, the current device fingerprint risk level, and the system load index of the region, forming a comprehensive request profile. The strategy matching engine performs bidirectional verification based on this profile and the topic contract specification. If the request features do not meet the topic contract, the matching engine does not directly reject the request but initiates a dynamic topic recommendation process: by calculating the similarity between the request features and each topic contract, it returns a list of the most likely matching topics and feature completion suggestions to the client, guiding the requester to correct the parameters. During the matching process, the engine uses an incremental matching algorithm, prioritizing the evaluation of the topic rules with the highest historical frequency. Only when high-frequency rules are not satisfied does it traverse the entire set of rules, reducing the average matching time to one-third of the traditional traversal method. Policy instances are obtained through the service registry rather than the local factory, ensuring that even if the policy container changes its IP or scales up or down, the matching engine can still dynamically discover available instances, eliminating the risk of call failures caused by static configuration.

[0080] The data processing module's execution engine innovatively introduces a computing resource quota and priority preemption mechanism. The system allocates a dynamic computing quota to each topic, calculated based on the topic's recent request volume, rule complexity, and business priority. When a request arrives from a high-priority topic (such as the order allocation topic for paid merchants), even if the engine is processing rule calculations for a low-priority topic, preemptive scheduling can be triggered, pausing intermediate calculations for the low-priority topic and transferring CPU time slices to the high-priority topic, ensuring timely response for critical business operations. Rule execution employs a multi-level pipeline filter architecture, with each filter assigned an independent timeout quota and retry strategy. The input validation filter uses a fail-fast strategy, terminating the pipeline immediately upon detecting illegal input; the core computation filter allows a limited number of retries and uses an exponential backoff algorithm to avoid retry storms; the output formatting filter has degradation capabilities, directly returning the serialized original result when formatting times out, ensuring an eventual response. The engine has a built-in rule performance profiler that automatically records the execution time distribution, peak memory usage, and number of external calls for each rule, generating a rule health report. When the execution time of a rule exceeds two standard deviations from its historical baseline, it is automatically marked as "performance degradation" and triggers a rule optimization prompt.

[0081] The data synchronization module supports federated queries and automatic construction of materialized views for multi-source heterogeneous data. For topics configured with multiple data sources, the synchronization module does not simply pull and merge all data from each source. Instead, it constructs a data source capability matrix, analyzes the query latency, data freshness, and field coverage of each source, and automatically generates the optimal query plan. For fields with high real-time requirements, it prioritizes querying the API service; for historical statistical data, it prioritizes querying the data warehouse; and for dimensional attribute data, it prioritizes querying the cache. Query results are materialized into a unified format intermediate dataset, stored in the middleware, and each field's source and synchronization timestamp are annotated in the dataset metadata. When a data source changes, the synchronization module only invalidates the field caches that depend on that source, rather than refreshing the entire dataset, significantly reducing unnecessary computation. The module has a built-in data quality probe that periodically detects the field missing rate and outlier rate of the intermediate dataset. When quality indicators fall below the threshold, it automatically triggers data source switching or degradation and sends an anomaly alert. The data source configuration supports environment variable injection, allowing the same theme configuration to be reused in development, testing, and production environments. Data source migration can be completed simply by switching environment variables, avoiding release incidents caused by inconsistent configurations across multiple environments.

[0082] The middleware storage module employs a multi-level caching and data-driven tiered storage architecture. Hot data (data accessed within the last 5 minutes) is placed in off-heap memory on the application node's local machine. A consistent hashing algorithm ensures that data on the same topic is processed by the same node as much as possible, improving local cache hit rate. Warm data (data from the last hour) is stored in a Redis cluster, with independent expiration policies and eviction algorithms set for each topic's dataset. Cold data (historical archived data) is automatically transferred to distributed object storage, but its index is still retained in Redis. When rare requests access cold data, the system recovers the data from object storage through an asynchronous loading mechanism and briefly increases its popularity flag. If accessed again, it is promoted to the warm data layer. The module has a built-in data lineage tracker that automatically records which topics and rule versions read, computed, and output each piece of data. When data changes, it can trace the scope of impact backward and the computation process backward, providing a panoramic view for data governance. Storage capacity management employs an elastic scaling strategy. When the data volume of a topic suddenly increases, more Redis shards are automatically allocated to that topic; when the data volume shrinks, resources are automatically reduced to release resources, achieving fine-grained control over storage costs.

[0083] In scenarios of refined traffic management, the user tiering strategy's execution engine innovatively introduces user value prediction and resource pre-allocation mechanisms. The system not only calculates a user's current tier based on historical behavior but also estimates the user's potential value over the next 30 days using a time-series prediction model, increasing resource allocation for high-potential users in advance. The dynamic pricing strategy's rule container embeds a competitor price crawler and a price elasticity analyzer, crawling competitor prices every 5 minutes and dynamically calculating the price elasticity coefficient based on the platform's historical order data. When the elasticity coefficient exceeds a threshold, the system automatically widens the lower limit of price fluctuations, enhancing price competitiveness. In the on-demand allocation strategy, the system maintains a real-time health score for each resource unit (such as a customer service agent). This score comprehensively considers current session volume, response time, and user satisfaction. When a resource unit's health score falls below 60, even if it is idle, the allocation strategy automatically removes it from the available list, preventing users from being assigned to tired customer service agents and thus ensuring service quality at the resource allocation level.

[0084] The implementation of computer-readable storage media is not limited to traditional disks or solid-state drives, but extends to image layers of cloud-native immutable infrastructure. Rule code and topic configurations are compiled and packaged into lightweight container images. Each layer of the image records complete information about the topic version, rule version, and dependency library versions, ensuring the image's immutability through content-addressable storage. When the system starts, the container orchestration platform pulls the image and verifies the hash values ​​of each layer; any unauthorized image modifications will fail verification. Digital signatures are embedded in the image layers, and the signer's identity is bound to the topic's business affiliation, ensuring that only developers from specific business lines can publish rule images for the corresponding topic. Runtime rule execution logs, performance metrics, and exception stacks are collected and injected back into the image metadata, forming an "image-log-performance" correlation for easy auditing and backtracking. This storage model endows rule assets with immutability and verifiability, meeting financial-grade security and compliance requirements.

[0085] Example 1: Multi-topic collaborative processing in e-commerce platform promotion scenarios

[0086] During the "Double Eleven" shopping festival, an e-commerce platform simultaneously ran three business processes: "bestselling product flow control," "high-value order allocation," and "intelligent coupon distribution." Traditional solutions required developing separate rule systems for each business. With this invention, operations personnel define three themes in the configuration system: a "flow control theme" abstracts entry traffic events and configures data sources such as user visits and inventory balance; an "order allocation theme" abstracts order allocation events and configures data sources such as order amount, membership level, and customer service online status; and a "coupon distribution theme" abstracts marketing events and configures data sources such as user historical spending and coupon pool balance. The three themes implement their respective business logic through independent base classes but share the same strategy matching framework. When a user simultaneously triggers purchase, order placement, and coupon redemption actions, the system uses a strategy pattern to match the three themes in parallel, retrieving pre-set data from Redis and performing secondary processing. Ultimately, within the same request cycle, it returns the flow control result, the order allocation customer service ID, and the coupon distribution eligibility. This theme abstraction mechanism unifies the management of heterogeneous businesses, allowing new businesses to integrate without modifying the underlying architecture; only the theme definition needs to be added, significantly improving system scalability.

[0087] Example 2: Code-level implementation and hot update of dynamic pricing strategy

[0088] A car dealership platform needs to adjust service pricing in real time based on over 20 factors, including user purchase intentions, competitor prices, and inventory pressure. Traditional rule engines cannot support such a complex pricing model. After adopting this invention, the business line's data scientists developed a pricing algorithm within a base class, encapsulated as the "DynamicPricingRule" class. By inheriting from the system's abstract strategy base class, it implements complex logic such as factor weight calculation, price fluctuation boundary verification, and competitor price retrieval. This rule class is deployed independently in a rule container and managed via version number. Operations personnel bind the data processing rules for the "pricing theme" to this class in the configuration interface and set the rule version to v2.1. When a user inquires about a price in the app, the strategy matching module locates the pricing theme, triggers the execution of the "DynamicPricingRule" instance, retrieves preprocessed data such as user intention score, regional inventory, and competitor average price from the Redis cache, and completes millisecond-level pricing calculations. When the algorithm needs optimization, data scientists submit the v2.2 version rule class. The system then uses a canary release mechanism to switch 10% of traffic to the new version without downtime. By comparing the pricing conversion rate and average order value of the two versions, and confirming that v2.2 is more effective, a full rollout is gradually implemented. This code-level rule implementation overcomes the expression bottleneck of configuration engines, while the hot update mechanism ensures business continuity.

[0089] Example 3: Middleware caching and data source circuit breaking work together to ensure high availability

[0090] During peak concert ticket-buying periods, a ticketing platform experienced sudden surges in traffic, causing timeouts in the user information system's interface. Traditional solutions would directly trigger the failure of the entire flow control rule. This invention configures the "ticket-buying flow control topic" with a primary data source (real-time user information interface) and a backup data source (local cache snapshot). When performing secondary processing, the system prioritizes calling the real-time interface. If the interface times out three times consecutively, the built-in circuit breaker automatically triggers, marking the data source as "degraded." Subsequent requests automatically switch to the user information snapshot data stored in Redis. Simultaneously, the system switches the flow control rule for this topic from "real-time verification mode" to "cached decision mode," meaning rapid verification based on snapshot data, with the probability of allowing requests dynamically adjusted according to the freshness of the cached data. Once the interface recovers, the circuit breaker enters a half-open state, tentatively sending a small number of requests to verify the interface's health. Upon successful verification, the primary data source is gradually restored. The entire switching process is seamless for users, and the flow control service remains available at all times. This mechanism, through the linkage of middleware caching and circuit breaker strategies, elevates system availability from reliance on a single data source to a self-healing, resilient architecture.

[0091] Example 4: Rapid onboarding of new business themes within minutes

[0092] A financial platform planned to launch a "Credit Card Installment Eligibility Pre-screening" service, which would typically take two weeks to develop using traditional methods. Using this invention, the business product manager created a "Installment Pre-screening" topic in the configuration system backend, selected "Entry Traffic" as the business type, and checked three existing data sources—"User Credit Interface," "Consumer Behavior Database," and "Risk List Service"—through the data source registration interface. The system automatically completed the initialization and connection testing of the data source proxy. Subsequently, the risk control development team created the "InstallmentPrequalificationRule" class in a separate code repository, implementing logic such as credit score calculation, debt ratio verification, and risk list collision detection. After compilation and packaging, it was uploaded to the rules repository. On the topic configuration page, operations personnel bound the rule implementation class to the "Installment Pre-screening" topic, set the rule version to v1.0, and enabled the gray-scale switch (only effective for internal employee IDs). The system completed topic registration, data preheating, and rule loading within two minutes. After passing internal testing, the gray-scale scope was expanded to 1% of real user traffic. Full deployment was completed after monitoring showed no anomalies. From the initial business requirement to the launch, it only took a little over four hours, with code development taking three hours and configuration and deployment taking less than an hour, fully demonstrating the agility value brought by the theme abstraction and configuration mechanism.

[0093] Example 5: Rule Dependency Chains and Calculation Result Reuse

[0094] A food delivery platform needs to execute three rule steps sequentially in the "rider order dispatch" scenario: "regional capacity assessment," "order priority calculation," and "rider matching ranking." Traditional solutions require repeatedly querying capacity data. With this invention, the system supports configuring a "strategy chain" for each topic. Operations personnel chain the three sub-topics—"capacity assessment," "priority calculation," and "rider matching"—into a dependency chain for the main dispatch topic, declaring data transmission relationships: the output field of capacity assessment, "number of available riders in the region," serves as the input for priority calculation, and the output field of priority calculation, "order urgency score," serves as the weighting factor for rider matching ranking. When an order dispatch request arrives, the strategy engine automatically executes the three sub-topic rules in sequence, with the output of the previous sub-topic automatically injected into the context of the next sub-topic. The entire process requires only one query of the capacity database, and subsequent rules reuse cached results. The system records a complete data lineage graph, and when the capacity assessment rule logic changes, it automatically alerts users to potential impacts on downstream priority calculation rules, assisting in regression testing. The dependency chain mechanism avoids redundant calculations, reducing the overall order dispatch time by 40% and improving the maintainability of the rule system.

[0095] Example 6: Streaming response improves user experience for long-running tasks

[0096] A certain insurance platform's "intelligent underwriting" function requires calls to multiple external credit reporting interfaces, with each calculation taking 3-5 seconds. Traditional synchronous waiting methods cause page lag for users. With this invention, when the rule engine executes underwriting rules, it immediately pushes an intermediate status to the user's client via WebSocket after completing the calculation of a sub-rule (e.g., identity verification). The user's client page displays a progress bar and the current processing stage in real time. When all rules are executed, the final underwriting result (approved / rejected / transferred to human agent) is pushed through the same long connection. If an exception occurs during execution, the system pushes error details and automatically triggers a fallback rule, returning a simplified underwriting conclusion. This streaming response mechanism transforms the user's perceived waiting anxiety into visual progress feedback, increasing user satisfaction by 35% and avoiding the problem of repeated submissions due to timeouts. Calculation results are cached in Redis (hot data) and a time-series database (warm data), allowing for second-level conclusions when the same user applies for insurance again.

[0097] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are obtained:

[0098] This system achieves fundamental improvements in three dimensions: agility in rule configuration, intelligence in system operation, and efficiency in resource utilization, through innovative architectural design and module collaboration. First, the hybrid paradigm of topic abstraction mechanism and code-level rule development compresses the business iteration cycle from the traditional weekly "code development-testing-release" process to minute-level configuration effectiveness. New business scenarios do not require modification of the underlying architecture; only defining the theme, binding the data source, and uploading the rule code are needed for deployment, significantly improving business response speed and the reusability of technical assets. Second, the elastic orchestration and multi-version canary release mechanism of the policy container eliminates the need for downtime deployment when changing rules. Version switching has automated health assessment and traffic management capabilities, upgrading system availability from post-event emergency repair to pre-event preventative disaster recovery, ensuring business continuity. Third, the middleware's tiered caching and data-driven storage strategy intelligently allocates hot, warm, and cold data to different levels such as off-heap memory, Redis clusters, and object storage, supporting tens of thousands of concurrent accesses while reducing storage costs to less than one-third of the all-in-memory solution, achieving an optimal balance between performance and cost. Furthermore, the pipeline-filter architecture and incremental computation mechanism for rule execution enable fine-grained observation and dynamic optimization of rule performance. The preemption mechanism for computing resource quotas ensures deterministic guarantees for high-priority services even during peak system loads, avoiding the drawbacks of traditional architectures where critical services are blocked by low-priority tasks. Finally, data lineage tracing and context enhancement technologies transform the black-box process of rule execution into a white-box visibility, allowing for precise location of specific rule versions or data sources within minutes when operational results are abnormal, significantly improving troubleshooting efficiency. The system has been validated in scenarios such as refined traffic management, intelligent order allocation, and dynamic pricing, demonstrating high scalability, high availability, and high intelligence, providing a solid technical foundation for refined business operations.

[0099] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A fine-grained configuration method based on the strategy pattern, characterized in that, include: Define topics in the configuration system; these topics are used to abstract ingress traffic, order assignment type events, or transactions. Configure the basic data source and data processing rules for the topic, wherein the data processing rules are developed and implemented by the user in the basic class of their respective business line according to business needs; Upon receiving a user request, the strategy pattern is used to match the corresponding topic; The data on the topic is processed a second time according to the data processing rules, and the processing result is returned.

2. The method according to claim 1, characterized in that, The types of topics include inbound traffic and order allocation, where inbound traffic represents whether access is allowed under a specified dimension, and order allocation represents the set of objects that can be allocated.

3. The method according to claim 1, characterized in that, The basic data source is prepared through database and / or interface connection, and refreshed according to the configured automatic synchronization time or event triggering mechanism; the system automatically stores the data of the topic in the middleware, and refreshes the topic data in the middleware according to the configured automatic synchronization time.

4. The method according to claim 1, characterized in that, The system is applied to the fine-grained management of traffic, including one or more of the following: user segmentation strategy, dynamic pricing strategy, and on-demand allocation strategy. The user segmentation strategy divides users into different levels and allocates different resources to them. The dynamic pricing strategy adjusts service prices according to real-time business scenario needs. The on-demand allocation strategy increases resource allocation for high-quality customers and reduces resource allocation for system disruptors.

5. A fine-grained configuration system based on the strategy pattern, characterized in that, include: The theme configuration module is used to define themes, set theme types, and configure basic data sources and data processing rules. Themes are used to abstract entry traffic, order allocation type events or transactions. The strategy matching module is used to match the corresponding topic using strategy patterns after receiving a user request; The data processing module is used to perform secondary processing on the data of the topic according to the data processing rules and return the processing results.

6. The system according to claim 5, characterized in that, The system also includes a data synchronization module, used to refresh the subject data in the underlying data source and / or middleware according to the configured automatic synchronization time or event triggering mechanism.

7. The system according to claim 5, characterized in that, The system also includes a middleware storage module for automatically storing topic data to support high-concurrency access.

8. The system according to claim 6, characterized in that, The data processing rules are implemented by users in the basic classes of their respective business lines according to their business needs. The middleware storage module automatically stores the topic data in the middleware and refreshes it according to the configured automatic synchronization time.

9. The system according to claim 5, characterized in that, The system is applied to the fine-grained management of traffic, including one or more of the following: user segmentation strategy, dynamic pricing strategy, and on-demand allocation strategy.

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

Images