Information processing method, electronic device, and storage medium

Abstract

An embodiment of the present disclosure provides an information processing method, comprising: obtaining configuration data, the configuration data containing parameter definition information and service identification information of a service instruction; reading the configuration data in response to a configuration update condition; dynamically generating a parameter verification object according to the parameter definition information in the configuration data; registering the parameter verification object to a service mapping table according to the service identification information; and performing parameter verification and routing processing on a service instruction request according to the service mapping table in response to the service instruction request.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to information processing methods, electronic devices, and storage media. Background Technology

[0002] In related technologies, distributed business systems primarily implement parameter validation logic for business commands using a static, fixed approach. One method is to directly embed the parameter validation rules into the business source code and fix them at compile time; another method is to store the validation rules as static configuration files in the local file system and load them all at once when the service process starts. Both methods statically bind the lifecycle of the validation rules to the service process.

[0003] However, the aforementioned static configuration method has significant technical drawbacks when the scale of business instructions expands. First, the validation rules are fixed in the form of source code or static configuration files, making it impossible to dynamically instantiate parameter validation objects at runtime based on external metadata. This results in redundant validation logic accumulated in the server's memory being difficult to unload as needed, and each new or changed business instruction requires modification of the source code and redeployment. Second, the configuration takes effect only after the service process is restarted, which leads to interruption of existing connections and blocking of request processing, as well as additional computational overhead from process context switching and reinitialization. Third, in distributed multi-instance deployment scenarios, each node independently loads its local static configuration, making it difficult to synchronously update the runtime validation status without interrupting service, easily leading to inconsistencies in processing logic between nodes and abnormal data routing. Summary of the Invention

[0004] This disclosure provides an information processing method and a computer-readable storage medium to at least partially solve the aforementioned problems existing in the related art.

[0005] According to one aspect of this disclosure, an information processing method is provided, the method comprising: acquiring configuration data, the configuration data including parameter definition information and service identification information of a business instruction; reading the configuration data in response to a configuration update condition; dynamically generating a parameter verification object based on the parameter definition information in the configuration data; registering the parameter verification object to a business mapping table based on the service identification information; and performing parameter verification and routing processing on the business instruction request based on the business mapping table in response to a business instruction request.

[0006] According to one aspect of this disclosure, a computer-readable storage medium is provided, which stores computer program instructions that, when executed by a processor, are used to implement any of the above information processing methods.

[0007] One embodiment of this disclosure provides an information processing method, including: acquiring configuration data, the configuration data including parameter definition information and business identification information of business instructions; reading the configuration data in response to a configuration update condition; dynamically generating a parameter verification object based on the parameter definition information in the configuration data; registering the parameter verification object to a business mapping table based on the business identification information; and performing parameter verification and routing processing on the business instruction request based on the business mapping table in response to a business instruction request. This method dynamically generates and registers parameter verification objects without modifying the source code, reducing development overhead and release time for configuration changes, reducing server-side code redundancy and system resource consumption, helping to avoid resource waste in request processing caused by service interruptions, improving the reliability of configuration synchronization in multi-instance deployment environments, and enhancing the processing efficiency of business instruction extensions and the flexibility of system operation and maintenance. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 A flowchart illustrating a method in one exemplary embodiment of this disclosure is shown. Detailed Implementation

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

[0011] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0012] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise expressly specified.

[0013] It should be noted that the information (including but not limited to: user input information, such as information entered by the user into an input box), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, service pressure corresponding to operations performed on all code of the current project, and code development status of the current project), and signals involved in the embodiments of this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, and the service pressure and code development status involved in the operations in the embodiments of this disclosure are all obtained under full authorization.

[0014] According to one embodiment of the information processing method of this disclosure, such as Figure 1 As shown, the method may include: Step S210: Obtain configuration data, which includes parameter definition information and service identification information of the service instructions; Step S230: In response to the configuration update condition, read the configuration data; Step S250: Dynamically generate parameter validation objects based on the parameter definition information in the configuration data; Step S270: Register the parameter verification object to the business mapping table according to the business identification information; Step S290: In response to the business instruction request, perform parameter validation and routing processing on the business instruction request according to the business mapping table.

[0015] According to one embodiment of this disclosure, the generation and registration of parameter verification objects can be completed dynamically without modifying the source code, reducing the development overhead and release time of configuration changes, reducing server-side code redundancy and system resource consumption, helping to avoid the waste of request processing resources caused by service interruption, improving the reliability of configuration synchronization in multi-instance deployment environments, and improving the processing efficiency of business instruction extensions and the flexibility of system operation and maintenance.

[0016] In another implementation, the client device displays a command configuration interface, which includes a basic information configuration area, a parameter field list configuration area, a batch push strategy configuration area, and a tracking injection strategy configuration area. In the basic information configuration area, operators input the business identifier, business command name, channel category, and command identifier. They then define the parameter names, field types, and default values ​​for the business command by adding or deleting rows in the parameter field list configuration area. Subsequently, in the batch push strategy configuration area, operators set whether to enable batch push, the maximum number of pushes, and the user identifier concatenation character. In the tracking injection strategy configuration area, they set whether to enable tracking, the target field, and the injection direction. The client responds to these configuration operations, generates a structured configuration document, and submits it to the server. This visual configuration method allows operators to register and modify push commands independently without needing coding skills, lowering the technical barrier to new command deployment and shortening the overall cycle from requirement submission to effective release.

[0017] The embodiments of this disclosure will now be further described.

[0018] In step S210, configuration data is obtained. The configuration data includes parameter definition information and service identification information of the service instructions. By pre-obtaining configuration data containing parameter definition information and service identification information, a unified structured input source can be provided for subsequent dynamic generation of parameter verification objects and route registration, thereby improving the standardization and processing efficiency of configuration parsing.

[0019] In one implementation, the system can query the configuration document of the push command from a document-based database to obtain configuration data. This configuration data is stored in a structured document format and includes parameter definition information and business identification information for the business command. Parameter definition information includes, for example, parameter field names, field types, and default values; business identification information includes, for example, application identifiers and command identifiers. When an operator adds or modifies a push command in the visual backend and saves it, the system automatically updates the timestamp attribute of the corresponding configuration document, enabling subsequent polling processes to recognize the changes in configuration data. The configuration data can further include extended attributes such as batch push strategies and event tracking injection strategies, thereby providing complete metadata support for the subsequent dynamic generation of parameter validation objects.

[0020] Optionally, configuration data is used to describe metadata of business instructions. It is stored in the database in the form of structured documents and can be generated and maintained through a visual interface.

[0021] Optionally, the configuration data can be structured data records stored in a document-oriented database, or binary or text format data read from a local configuration file or a remote configuration center. This configuration data is generated through a visual interface in the operations management backend, allowing operations personnel to create, edit, and save push commands simply by filling out a form. In addition to parameter definition information and business identification information, the configuration data can also include extended information such as batch push strategies, event tracking strategies, channel classifications, and update timestamps. This extended information further supports differentiated processing of push commands in different business scenarios, such as incremental change detection based on update timestamps and dynamic adjustment of the maximum number of users pushed per batch based on batch push strategies. It should be noted that the storage medium and document format of the configuration data are not limited to a specific implementation; any data object that can carry business command metadata in a structured form can be used.

[0022] Optionally, parameter definition information is used to define the attributes of each parameter field of a business instruction, and may include at least one of field identifier, field type, and default value. Optionally, parameter definition information may be a set of metadata that provides a structured description of the business parameter fields to be transmitted by the push instruction. In one possible implementation, each parameter field in the parameter definition information is organized in key-value pairs, with the key name being the parameter field identifier and the key value containing attributes such as the field's type identifier and default value. To improve configuration flexibility, in addition to basic parameter fields, the parameter definition information can dynamically add or remove field entries according to business needs. For example, for an in-app email push instruction, the parameter definition information may include a subject field, a content field, and an expiration time field, where the subject and content fields are configured as required fields, and the expiration time field is configured as an optional field with a default value. Considering the differentiated requirements of different business systems for the parameter structure of push instructions, the specific composition of the parameter definition information can be customized by operations personnel in the visual configuration interface according to the actual business scenario. This disclosure does not intend to limit the specific types and number of parameter fields.

[0023] Optionally, the business identification information is used to uniquely identify the business domain and instruction type to which the business instruction belongs, and may include an application identifier and a command identifier. Optionally, the business identification information may be a set of key identifiers used for routing and instance matching in a distributed push system. This business identification information includes at least an application identifier and a command identifier, where the application identifier can be used to distinguish different downstream game products or business systems, and the command identifier can be used to distinguish different push instruction types within the same application. For example, an application identifier might be a first game application number to represent the target game product, and the corresponding command identifier might be a character email command to represent the in-app email instruction type; another example is an application identifier might be a second social application number to represent the target social business system, and the corresponding command identifier might be a message broadcast command to represent the server-wide pop-up instruction type. Furthermore, in addition to the above basic identifiers, the business identification information may also include a server identifier field and a user identifier field. The server identifier field indicates the target game server instance, and the user identifier field indicates the target user attributes receiving the push notification. To avoid routing errors caused by identifier conflicts, the combination of application identifier and command identifier is usually kept to be mutually exclusive globally. The system generates a command alias by concatenating the application identifier and command identifier, and registers the alias in the channel routing table to achieve accurate distribution of business instruction requests.

[0024] In step S230, in response to the configuration update condition, configuration data is read. This enables timely triggering of the loading process when configuration changes occur, allowing the service process to accurately obtain the latest configuration data, improving the timeliness of configuration synchronization and reducing system resource overhead. In one implementation, when the operator completes the form editing of the push command in the management backend and clicks the save button, the update timestamp of the corresponding configuration document in the database is automatically refreshed; the daemon process compares the update timestamp with the local cache value in the subsequent polling cycle, determines that the configuration update condition is met, and then triggers the service process to read the entire updated configuration data set from the local configuration file for subsequent processing.

[0025] Optionally, configuration update conditions are designed to provide the service process with a trigger for configuration changes, so as to ensure that configuration data is reloaded at the appropriate time.

[0026] Optionally, configuration update conditions can be determined through various mechanisms. In some cases, the condition is triggered by a daemon polling the configuration database at predetermined intervals: the daemon queries the set of configuration data that is active and not deleted, reads the update timestamp of the document with the latest update timestamp, and compares it with the most recent update timestamp in the local cache; if the former is greater than the latter, the configuration update condition is deemed met. In other cases, configuration update conditions can also be triggered by the database's real-time change stream actively pushing to the daemon. When any configuration document is inserted, updated, or deleted, the database immediately pushes the change event to the subscribers, and the daemon directly determines that the configuration has changed. In addition, configuration update conditions can also be established based on file system event notifications, that is, the daemon monitors the modification time or file change events of the local configuration file directory, and once it detects that a new configuration file has been atomically written to disk, it is considered that the configuration update condition is met. The above triggering methods can be used independently or in combination to adapt to the requirements of different deployment environments regarding configuration activation delay and system overhead.

[0027] Optionally, the configuration data read operation is initiated in response to the fulfillment of configuration update conditions, and is used to load the latest effective configuration content.

[0028] Optionally, the reading of configuration data can be implemented in various ways depending on the trigger source and data carrier. In one scenario, when the daemon detects that the configuration update condition has been met, it serializes the entire set of queried configuration data into a single local configuration file and writes it to the local file system atomically. Subsequently, the service process reads the configuration data from this local configuration file in response to a reload signal. In another scenario, the service process can also attempt to read the local configuration file through an exception handling mechanism. If the file does not exist or parsing fails, the configuration data is rolled back to empty configuration data, while maintaining the normal operation of the preset static parameter validation object and static routes, thereby achieving silent degradation. In addition, in scenarios where the database connection is stable and the requirements for configuration activation latency are stringent, the service process can also be configured to load configuration data directly from the database without going through the local file intermediate layer, thereby reducing the additional latency caused by signal transmission and file parsing.

[0029] In an optional implementation, in response to a configuration update condition, configuration data is read, including: querying the configuration database at predetermined intervals for a set of configuration data that is active and marked as not deleted; obtaining the update timestamp corresponding to the configuration data with the latest update timestamp in the configuration data set as the current update timestamp; comparing the current update timestamp with the most recent update timestamp in the local cache to perform incremental change detection; if the current update timestamp is greater than the most recent update timestamp, determining that a configuration change has been detected, serializing the queried configuration data set into a local configuration file and persisting it to local storage, triggering the service process to reread the configuration data. By combining predetermined periodic polling with timestamp incremental detection, the resource waste caused by continuous scanning can be avoided, while timely detection of configuration changes can be achieved, balancing system overhead and response time.

[0030] In one implementation, a daemon deployed on the server connects to the configuration database every sixty seconds, querying a set of configuration documents that are active and not marked for deletion. It takes the largest update timestamp as the current update timestamp and compares it with the most recent update timestamp recorded locally. If the current timestamp is larger, the entire queried configuration is serialized into a local configuration file and written to disk, triggering a service process reload. This periodic polling mechanism avoids the connection resource consumption caused by real-time monitoring and enables changes to be detected and applied within a minute-level latency.

[0031] Optionally, a configuration database is used to store metadata documents for push commands, serving as the sole data source for the daemon process to perform polling queries. Optionally, the configuration database can be a non-relational database supporting massive document storage, such as a document-oriented database or a key-value store. Taking a document-oriented database as an example, each push command in the system corresponds to an independent document record, which completely stores metadata such as the command name, parameter field list, batch push strategy, data injection strategy, and server identifier field in a structured format. All service instance daemons pull configurations from this configuration database, ensuring that instances in a distributed environment can access a homogeneous and source-consistent data set. Furthermore, the configuration database records the time of each change using a millisecond-precision timestamp field, providing a unified and monotonically increasing comparison benchmark for incremental change detection. Considering that operations personnel may continuously modify multiple commands within a short period, the write capacity and descending query performance of the configuration database directly affect the lower limit of the hot-loading pipeline's response; therefore, the selection of the configuration database must balance high availability deployment and horizontal scaling capabilities.

[0032] Optionally, the effective status and deletion flag constitute the filtering conditions for configuration queries, used to distinguish between available configurations and those that have been deactivated or deleted.

[0033] Optionally, the active status indicates whether the currently pushed command is in an active state that can be loaded by the service process and provided to the outside world, while the deletion flag is used to implement a logical deletion mechanism to avoid the loss of historical configurations due to physical deletion. In implementation, when an operator temporarily suspends a command, the system sets its active status to an inactive value. The daemon process will no longer pull the configuration in the next query cycle, and the service process will not generate parameter verification objects for it, thereby immediately cutting off the processing capability of the command. When it is necessary to completely remove a command, the system updates the deletion flag to the deleted status, while retaining the underlying document data for subsequent auditing and traceability. By combining the active status and deletion flag for filtering, a subset of valid configurations can be accurately identified during the query phase, avoiding invalid or expired configurations from occupying the service process's memory space and computing resources.

[0034] Optionally, the predefined period specifies the time interval between two database queries by the daemon process, balancing the timeliness of configuration activation with system resource consumption. Optionally, the predefined period can be flexibly set based on the actual business's tolerance for configuration activation delays and the database's load capacity. For example, in operational scenarios with high timeliness requirements, the predefined period can be set to thirty seconds to shorten the waiting window between configuration submission and service process activation; while in environments with low configuration change frequency or high sensitivity to system resources, the predefined period can be extended to five minutes or even ten minutes, significantly reducing the number of database queries and network connection overhead. After completing the entire process of single polling, file write-to-disk, and signal sending, the daemon process enters a sleep state matching the predefined period until the next wake-up time. It should be noted that even if multiple database changes occur during the sleep period, the daemon process will capture all accumulated changes at once using the maximum update timestamp during the next poll, avoiding frequent triggering of service process reload.

[0035] Optionally, the update timestamp records the most recent change time of the configuration document, serving as a quantitative basis for determining whether the entire configuration set has changed. Optionally, the above update timestamp is generated with millisecond precision to ensure that it remains strictly monotonically increasing even in scenarios where operators edit frequently and continuously. During the polling query phase, the daemon process sorts the configuration data set in descending order and extracts the update timestamp of the first document, which represents the latest change time among all currently effective configurations. It then compares this timestamp with the most recent update timestamp cached locally. If the former is larger, it indicates that at least one configuration write operation has occurred between the two polls. Compared to comparing the differences in the content of the entire document line by line and field by field, the time complexity of change detection using update timestamps is reduced from being related to the total number of configurations to a constant order of magnitude, greatly reducing the computational overhead of the daemon process. Furthermore, the update timestamp is automatically written to the database by the management backend each time the configuration is saved, without the need for manual intervention by operators, thus eliminating the risk of detection failure due to manual setting errors or clock asynchrony.

[0036] Optionally, incremental change detection is used to determine whether an effective configuration has been added, modified, or switched with minimal overhead by comparing timestamp values.

[0037] Optionally, the core logic of the incremental change detection described above lies in comparing the latest update timestamp on the database side with the most recent update timestamp persisted locally by the daemon process, rather than traversing all the field contents of the configuration documents. Since update timestamps are designed to monotonically increase, any database write operation that causes a change in configuration status will refresh the timestamp. Therefore, the daemon process only needs to perform one maximum value check and one integer comparison to complete the change determination. This detection method effectively controls the computational complexity to a constant level independent of the number of configuration documents. Even if the system accumulates metadata for hundreds of push commands, it will not increase the performance burden of the polling phase. When a timestamp mismatch occurs, the daemon process considers a configuration change to have occurred and immediately starts the subsequent file serialization and service process reload process; if the timestamps match, it skips invalid operations and enters sleep mode, achieving zero additional overhead during periods without changes.

[0038] Optionally, considering clock drift or network latency between the database server and the daemon host server in extreme scenarios, the aforementioned incremental change detection mechanism can be supplemented with file content hash verification or document count as auxiliary verification methods. For example, if the update timestamps are equal but the daemon detects a missing or abnormal local cache file, it can force a full configuration re-fetch and disk write to fix potential inconsistencies between the local and database states. Furthermore, in database environments that support change streams, incremental change detection can be upgraded from passive polling to active listening. After the database detects a set change, it actively pushes the event to the daemon, which then skips timestamp comparison and directly performs file write to disk. This replaceable architecture of passive polling and active listening allows the system to select the optimal change awareness path in different deployment environments based on infrastructure capabilities.

[0039] Optionally, the local configuration file is used to persist the fully effective configuration to the local file system, serving as an intermediate buffer layer between the database and the service process.

[0040] Optionally, the aforementioned local configuration file is generated atomically by the daemon process after each configuration change is detected. Its content includes a set of all currently effective and undeleted configuration data. By maintaining a complete configuration snapshot at the file system level, even if the configuration database is temporarily unavailable due to network partitioning, master-slave switching, or planned maintenance, the service process can still load the most recent valid configuration from the local configuration file upon receiving a reload signal, avoiding cascading service interruptions caused by database dependencies. Furthermore, the atomic write mechanism ensures that the service process reads the complete configuration content at any given time, preventing file corruption or parsing errors due to concurrent writes. In operational troubleshooting scenarios, the local configuration file can also serve as an independent data copy for technical personnel to directly view, facilitating quick identification of configuration effectiveness issues. Further, this file can be used in conjunction with file system snapshots or version control tools to achieve easy tracking of change history.

[0041] In an optional implementation, the queried configuration data set is serialized into a local configuration file and persisted to local storage, triggering the service process to reread the configuration data. This includes: serializing the entire queried configuration data set into a single local configuration file and atomically writing it to the local file system; and, if the service process is confirmed to be running, sending a reload signal to the service process so that it responds to the reload signal, reads the configuration data from the local configuration file, and updates the most recent update timestamp in the local cache to the current update timestamp. Through the coordinated operation of the atomic disk persistence of the full configuration snapshot and the process reload signal, the risk of data corruption or service interruption during configuration loading is effectively avoided, ensuring that the new configuration takes effect safely and completely on the service process side.

[0042] In one specific approach, after detecting a configuration change, the daemon process first integrates all effective configuration documents retrieved into a complete structured text snapshot and saves it to a local disk file with a single, atomic write operation. Subsequently, the daemon process checks the reachability of the target service process's management interface. Only when it confirms that the process is running normally does it send a reload request signal, prompting the server to read the new configuration from the disk snapshot during graceful reload and synchronously update its locally maintained last-update timestamp to the latest value on the database side. Optionally, full serialization aims to integrate all effective configuration documents retrieved from the configuration database into a complete local snapshot file to ensure that the service process obtains a complete configuration view during the reload phase.

[0043] Optionally, during the full serialization process, after detecting a configuration change, the daemon process will integrate all eligible configuration documents obtained in this polling into a single text-based configuration snapshot. This snapshot file not only contains metadata such as parameter field definitions for each push command, batch push strategy configuration, and tracking identifier injection strategy, but also fully retains the update timestamps and application identifier information of each document, enabling the service process to obtain a globally consistent configuration view without accessing the database again during the loading phase. It should be noted that the specific data organization format of the above snapshot file can be a key-value pair-based structured text format or a markup text format based on indentation levels; this disclosure is not limited to this. By aggregating multiple records scattered in the database into a single local file, the network connection overhead of the service process during reload is reduced, and the problem of inconsistent time bases of different configuration documents due to batch reading is avoided. Furthermore, the snapshot file adopts an overwrite full write strategy during the writing process, rather than a difference-based local patching, thereby ensuring that each file written to disk is a self-consistent and complete data source that can be directly used to reconstruct all parameter validation objects and routing mappings.

[0044] Optionally, the atomic file write method aims to generate a local configuration snapshot through a single complete disk write operation, avoiding the service process reading incomplete configuration data that has been corrupted due to write interruption.

[0045] Optionally, atomic file writing can be achieved through the operating system's file renaming mechanism. Specifically, the daemon process can first write the complete serialized configuration data to a temporary file. After all the content is successfully written to disk, the temporary file is overwritten with the target filename through an atomic renaming operation. Considering that in high-concurrency push scenarios, the service process may attempt to read the local configuration file at any time, if the writing process is abnormally interrupted, the old file content may be partially overwritten during the reading process, leading to parsing failure or loading incomplete verification rules. As a possible implementation, the aforementioned temporary file and the final target file are located in the same physical disk partition to ensure that the renaming operation has system-level atomicity. Through this mechanism, regardless of how long the writing process takes or whether disk buffer flushing occurs in between, when the service process opens the target file, it will either see the complete content of the old version or the complete content of the new version, thereby reducing the risk of data corruption caused by concurrent read and write. In addition, this local snapshot can also serve as a degradation basis when the database is temporarily unavailable, allowing the service process to still load the most recent valid configuration from the local database, ensuring that static routing continues to process normally, while only the dynamic registration part is temporarily unavailable.

[0046] Optionally, besides atomic write strategies based on file renaming, atomic file writes can also be implemented by pre-allocating disk space and writing checksum markers at the beginning and end. Specifically, the daemon process can first allocate a fixed-size file storage area in the local file system, and write the serialized configuration data and cyclic redundancy check (CRC) code at the beginning and end of this area. When the service process reads the file, it first verifies the integrity of the checksum markers and the checksum. The purpose of this is that even if the process crashes or the server loses power during the write process, the service process can identify that the file is in an incomplete state through the checksum markers, thereby refusing to load and rolling back to an empty configuration or retaining the old configuration. It should be noted that the specific implementation of the above atomic write is not limited to specific operating system functions or specific file formats; any write mechanism that can present a complete snapshot or not present a new snapshot from the reader's perspective is applicable. In this way, not only is service stability guaranteed during configuration changes, but also low-level file-level security is provided for configuration consistency in distributed multi-instance deployment scenarios.

[0047] Optionally, the reload signal is used to send a lightweight event notification to the service process after confirming that the local configuration snapshot has been safely written to disk, triggering the service process to reload the configuration without interrupting existing request processing. Optionally, the reload signal can be implemented using an operating system-level process signal, such as the HUP signal, sent by the daemon process to the service process through a process management tool. Upon receiving the signal, the service process executes a graceful reload process: first, it starts a new worker process to load the latest local configuration snapshot; after the new worker process completes initialization and has request processing capabilities, it gradually migrates and smoothly terminates existing connections on the old worker process. During this process, upstream push requests being processed are not lost, and newly arriving requests are directly handled by the worker process that has loaded the new configuration, thus eliminating any service interruption window during the entire configuration activation process. Considering that the signal mechanism itself only carries event notifications and not configuration data, its transmission overhead is extremely low and unaffected by the size of the configuration data; even if the number of configuration documents grows to hundreds, the signal triggering latency can still be maintained at the millisecond level. Furthermore, since each reload is based on a complete snapshot that has been atomically written to disk in the local file system, receiving signals repeatedly will not cause configuration confusion, thus exhibiting good idempotency.

[0048] Optionally, besides the reload triggering mechanism based on process signals, reload signals can also be transmitted through message brokers or inter-process communication channels. Specifically, after confirming that the configuration snapshot has been successfully written to disk, the daemon process can write an announcement message that the configuration has been updated to a shared message queue or publish it to the inter-process communication bus. Each service instance will then automatically complete the configuration reload after subscribing to the message. This implementation is particularly suitable for containerized deployments or cross-physical host deployments, as it removes the restriction that the daemon process and service processes must reside on the same host machine. It should be understood that whether direct signals or message announcements are used, the aim is to drive the service process to re-parse the configuration from the local file and rebuild the parameter verification object without changing the existing request processing path. To avoid anomalies caused by signal loss or duplicate message delivery, the service process can also compare the timestamp or checksum of the snapshot file before each reload, and only perform reconstruction when a change is detected, thereby further enhancing the reliability of the entire hot-loading pipeline.

[0049] Optionally, the running status is used to characterize whether the service process is currently alive and whether it has the conditions to receive reload signals, aiming to avoid sending invalid signals to processes that have not started or do not exist. Optionally, the running status can be determined by checking whether the socket file corresponding to the process management tool exists. Specifically, before sending a reload signal to the service process, the daemon process first checks whether a specific process management socket file exists in the local file system; if the file exists, it determines that the service process is in a running state and executes signal sending; if it does not exist, it skips this signal sending and waits for the next round of polling. The purpose of this is to prevent the daemon process from sending signals to the service process when it has not started, has crashed, or is restarting, thereby avoiding signal delivery errors at the operating system level and the resulting abnormal log storms. It should be noted that the above-mentioned running status detection methods are not limited to file system probing; they can also be implemented by initiating no-operation detection to the process identifier, querying the process management interface status, or listening to health check ports, etc., and this disclosure does not limit this. By adding a lightweight pre-check before signal sending, the fault tolerance and deployment flexibility of the daemon process and service process working together can be significantly improved without affecting the polling efficiency.

[0050] In an optional implementation, in response to a configuration update condition, configuration data is read, including: reading a local configuration file containing the configuration data through an exception handling mechanism; if the local configuration file does not exist or fails to be parsed, the configuration data is rolled back to empty configuration data, while maintaining the normal operation of the pre-set static parameter validation object and static routes. By rolling back to an empty configuration through exception handling when a local configuration error occurs, the pre-set static parameter validation object and static routes continue to run, avoiding overall service interruption and improving the robustness and availability of the system under abnormal scenarios.

[0051] In practical applications, if the local configuration file fails to be fully written due to insufficient disk space, or if the file is abnormally cleared when the service process restarts, the system reads the file through a preset exception capture structure. When the file is detected to be missing or the content parsing is incorrect, the configuration data is automatically downgraded to empty configuration data, so that the preset static parameter verification object and static route continue to carry out request processing, while the dynamic registration part is only temporarily silent and the overall service is not interrupted.

[0052] Optionally, the exception handling mechanism can be deployed at the entry point where the Web service process reads the local configuration file. Its coverage may include, but is not limited to, exceptions such as file non-existence, file permission errors, invalid content formats, and memory parsing errors. Considering that disk jitter or concurrent writes in a production environment may cause the configuration file to become unreadable, as a possible implementation, the above mechanism can be implemented through a hierarchical exception handling structure: the outer layer captures file system-level exceptions, and the inner layer captures data deserialization exceptions. For the processing logic after capture, in addition to rolling back to empty configuration data, it can also trigger alarm log recording or report the exception event to the monitoring platform; this disclosure is not limited to this. In one implementation, when a file permission error is captured, the system only loads the pre-set static parameter verification object and static routes, suspends dynamic configuration extension capabilities, and exposes a read-only status identifier; when an invalid content format error is captured, the system parses the location information of the exception, skips the single configuration entry that caused the invalidity, and loads the remaining valid configuration entries with valid formats; when a memory parsing error is captured, the system releases the allocated temporary parsing object and triggers a retry read; if the retry still fails, it rolls back to empty configuration data. Even in extreme scenarios of localized environmental failures, exceptions can be isolated during the configuration loading phase, preventing them from spreading to the main request processing chain.

[0053] Optionally, empty configuration data serves as a degradation baseline when local configuration files are missing or corrupted, allowing the system to maintain a minimal operating state. Optionally, empty configuration data can be represented as an empty dictionary, an empty list, or a default data structure containing only the base version number; its specific form can be set according to the initialization requirements of the upper-layer business mapping table. To prevent errors in subsequent traversal operations due to empty configuration, the system can initialize the default adapter container and empty route list required by the pre-defined static parameter validation object while rolling back to empty configuration data, ensuring that the main link query logic does not receive null reference exceptions. It should be noted that empty configuration data is not equivalent to system shutdown; rather, it selectively blocks dynamic configuration extension capabilities while retaining the hard-coded original push command processing capabilities. This design can provide maintenance personnel with a window of opportunity to repair without interrupting existing services in extreme disaster scenarios where both the database and local files are unavailable.

[0054] Optionally, the pre-configured static parameter verification object includes a hard-coded parameter verification object instance initially loaded by the system, which is used to continue providing parameter verification services for basic instructions when dynamic configuration fails.

[0055] Optionally, the pre-defined static parameter validation objects can be command parameter dictionary entries in the game adapter, which are determined during source code compilation. For example, they can be class instances of parameter validation objects pre-written for commonly used push commands. These static objects are loaded into memory when the system starts, and their lifecycle is independent of the subsequently dynamically generated configuration data. Therefore, during the period when the dynamic factory function rolls back to an empty configuration, the validation rules, instrumentation logic, and batch push strategies corresponding to the static objects remain effective. Even if the dynamic configuration pipeline is completely unavailable, push commands previously added or modified by operations personnel through the visual backend will be suspended, but the system's built-in original command push link will not be interrupted, prioritizing the continuity of core business.

[0056] Optionally, static routes include the system-pre-defined binding relationships between command aliases and channel processors, used to maintain the distribution capability of basic requests during dynamic route fallback. Optionally, static routes can refer to mapping entries from command aliases to processing functions explicitly registered in the system source code, such as fixed push command routes for member systems or third-party community notifications. These routes are written into the in-memory routing table during system initialization and do not depend on the dynamic loading process of local configuration files or databases. Therefore, after the configuration is downgraded to empty configuration data, the binding relationships in the static routing table are still fully preserved, allowing continued reception of upstream requests and scheduling to the corresponding channel processors. Furthermore, to enhance operational observability during degradation, the system can attach degradation marker information to the logs when processing static route requests, facilitating subsequent differentiation between normal traffic and degraded traffic; this disclosure does not limit this.

[0057] In step S250, parameter validation objects are dynamically generated based on the parameter definition information in the configuration data. By dynamically generating parameter validation objects, the repetitive work of writing validation classes independently for each business instruction is avoided, significantly shortening the deployment cycle and effectively alleviating code bloat and maintenance burden.

[0058] In practical applications, after the Web service process completes the configuration reading, it constructs parameter validation objects one by one based on the parameter definition information. Specifically, the factory function parses the type identifier and default value attributes of each parameter field in the configuration document, matches them with the corresponding validation field class (e.g., string type is mapped to string validation class, integer type is mapped to integer validation class), and then combines the field identifier, validation rules, and default value filling strategy into a field rule set. Through the runtime class creation mechanism, this is dynamically encapsulated into a parameter validation object with complete deserialization and validation capabilities, so that new business instructions can be put into operation without writing any hard-coded validation classes.

[0059] Optionally, the parameter validation object is used to carry validation rules and default value strategies to achieve runtime validation and conversion of request data. Optionally, the parameter validation object is designed to carry type validation rules and default value filling strategies for each parameter field, and can be dynamically created at runtime as a functional entity with complete deserialization and validation capabilities through metaprogramming mechanisms. As one implementation, this object includes at least custom parameter fields, online detection fields, instruction identifier constant fields, and server identifier fields, thus eliminating the need to write hard-coded validation classes for each business instruction and effectively reducing code redundancy. Furthermore, the parameter validation object can also embed a tracing identifier function field, automatically concatenating the tracing identifier before or after the target parameter field during the validation phase to achieve declarative instrumentation. It should be noted that its field composition is driven by configuration data and can be flexibly expanded according to the interaction protocol of downstream business systems; this disclosure does not intend to limit the number of its internal fields or naming rules.

[0060] In an optional implementation, parameter validation objects are dynamically generated based on parameter definition information in the configuration data. This includes: parsing the parameter definition information to obtain the field attributes of each parameter field; matching corresponding parameter validation rules for each parameter field based on the field attributes; constructing a set of parameter validation rules based on the identifier of each parameter field and its matching parameter validation rules; and dynamically creating parameter validation objects based on the set of parameter validation rules. By parsing parameter definition information into field attributes and matching them with validation rules, the regularized and automated construction of parameter validation objects is achieved, avoiding the need to manually write validation code one by one, and significantly improving the generation efficiency and accuracy of parameter validation in configuration scenarios.

[0061] For example, in one implementation, an operator configures two parameter fields for a new push notification for a game product in the management backend: a title field and an expiration date field. The title field is a string with no default value, while the expiration date field is an integer with a default value of thirty. After parsing the parameter definition information, the system obtains the field attributes of the two parameter fields, matches string validation rules to the title field, and matches integer validation rules and a default value filling strategy to the expiration date field. Subsequently, the system constructs a parameter validation rule set based on the identifiers of the title and expiration fields and their matching validation rules, and dynamically creates a parameter validation object with both string and integer validation capabilities based on this set.

[0062] Optionally, the field attributes of each parameter field may include a type identifier and a default value, used to characterize the data characteristics and constraints of the parameter field. Optionally, the above field attributes can be parsed and extracted from the structured field definitions of the configuration document. Taking the configuration metadata stored in the database as an example, parameter definition information usually exists in the form of a set of key-value pairs, where each parameter field corresponds to a sub-document, which at least records a type identifier and a default value. During the parsing process, the system can traverse the set of key-value pairs, read the sub-document corresponding to each parameter field in turn, and thus extract the type identifier, default value, and other additional attributes of the field. It should be noted that the above parsing method is only an example. In actual implementation, parsing can also be completed by recursive traversal, pattern matching, or calling the structured query interface, etc., and this disclosure does not limit this. Considering that in actual operation scenarios, the requirements for parameter types of push instructions of different game products are different, the above field attribute parsing steps can provide a unified and standardized data input for subsequent verification rule matching, so that the same parsing logic can be adapted to multiple different business instruction configurations without writing differentiated parsing code for different instructions.

[0063] Optionally, parameter validation rules can be differentiated based on field attributes to perform compliance validation and preprocessing of input data.

[0064] Optionally, the aforementioned parameter validation rules can be pre-defined in a one-to-one type mapping relationship, or they can be dynamically selected based on the combination of field attributes. Specifically, when the type identifier in the field attribute is a string, the system automatically matches the string validation rule, which can force the input value to be a character sequence and perform encoding standardization processing; when the type identifier is an integer, the system matches the integer validation rule, performing numerical range checks and type casting on the input value. Furthermore, if the field attribute also contains a default value, the matched validation rule can also integrate a default value filling strategy, so that a preset value is automatically used as a substitute when the input is missing. This mechanism of automatically matching validation rules based on field attributes avoids the repetitive work of writing validation logic separately for each business instruction, and ensures that different instructions have a consistent technical implementation basis at the parameter validation level.

[0065] Optionally, the parameter validation rule set can be assembled from the identifiers of each parameter field and their matching validation rules, serving as the basis for dynamically creating parameter validation objects.

[0066] Optionally, the construction process of the above parameter validation rule set can be represented as follows: using the identifier of the parameter field as the key and the parameter validation rule instance matching that field as the value, each rule is written into a dictionary structure until all parameter fields are traversed. This dictionary structure logically constitutes a complete validation blueprint. The system can further inject validation rules corresponding to fixed control fields into it, such as online detection fields and instruction identifier constant fields, thereby forming a more complete rule set. Based on this rule set, the system uses a metaprogramming mechanism to dynamically create parameter validation objects at runtime, enabling these objects to automatically possess the same data validation, type conversion, and default value filling capabilities as hard-coded validation classes. It should be noted that the above dictionary structure is only an exemplary organizational form; in actual implementation, it can also be a list, ordered mapping, or other equivalent data structure, which this disclosure does not limit.

[0067] In an optional implementation, parameter validation objects are dynamically created based on a set of parameter validation rules. This includes: traversing each parameter field in the parameter definition information; determining the corresponding validation field class based on the type identifier of each parameter field using a pre-defined type mapping relationship; constructing a field mapping dictionary based on the identifier of each parameter field and its corresponding validation field class; and dynamically creating parameter validation objects based on the field mapping dictionary. By converting type identifiers to validation field classes and constructing a field mapping dictionary using pre-defined type mapping, hard-coding validation logic for each parameter field is avoided. When adding a new type, only the mapping relationship needs to be extended to take effect, significantly improving the flexibility and maintainability of parameter validation.

[0068] For example, suppose the configuration document defines three parameter fields: a string field identified as the first title, an integer field identified as the expiration duration, and a string field identified as the reward list. During the dynamic generation of parameter validation objects, the system first iterates through these three parameter fields, extracting their respective type identifiers. Then, it queries the pre-defined type mapping relationship, mapping the string type identifiers to string validation field classes with default value filling capabilities, and mapping the integer type identifiers to integer validation field classes with numerical range validation capabilities. Next, it constructs a field mapping dictionary using each field identifier as the key and the corresponding validation field class instance as the value. Finally, it dynamically creates parameter validation objects capable of parameter validation and type conversion based on this field mapping dictionary. In this way, new types can be added without modifying the main code of the factory function. For example, if boolean types need to be supported later, only the corresponding validation field class mapping entry needs to be added to the pre-defined type mapping relationship, and it will be automatically recognized and effective in the next round of configuration loading.

[0069] The aforementioned type identifier is used to specify the data type category required for the corresponding parameter field in the configuration data, so that it can be parsed into specific validation capabilities through mapping relationships later. Optionally, the type identifier can take various forms and is not limited to simple string naming rules. In one implementation, the type identifier can be a combination of lowercase English letters, such as a type identifier named string, integer, boolean, or float, to ensure precise matching with the pre-defined type mapping relationships in the factory function. In another implementation, the type identifier can also adopt a composite string structure with namespace hierarchy or version suffix, such as a string type identifier with a version prefix or a custom email format type identifier, thereby distinguishing the validation strategies of basic types and extended types within the same system. It should be noted that the specific writing of the above type identifier can be adjusted according to the naming conventions or configuration specifications of the actual programming language, and this disclosure is not intended to limit it. When an operations staff member selects a type for a parameter field in the visualization backend, the management backend serializes the selection result into a type identifier field in the configuration document. Subsequently, the validation pattern factory deserializes the field at runtime and determines the specific validation field class accordingly, thereby decoupling the configuration layer from the runtime.

[0070] The aforementioned pre-defined type mapping relationship is used to associate abstract type identifiers with executable validation field classes, and is a key mapping structure that supports automatic type resolution at runtime.

[0071] Optionally, the pre-defined type mapping relationship can be represented as a statically initialized dictionary structure or as a dynamic mapping table loaded from an external configuration file or database during the startup phase. This disclosure does not limit its specific storage medium. In one implementation, the pre-defined type mapping relationship can include basic mapping entries between string type identifiers and string validation field classes, integer type identifiers and integer validation field classes, and boolean type identifiers and boolean validation field classes. Furthermore, to avoid frequent modifications to the main logic of the factory function due to the addition of new business field types, the entries in the mapping relationship should support horizontal expansion. For example, when subsequent business needs to support date and time types, only the mapping pair between date and time type identifiers and date and time validation field classes needs to be added to the mapping relationship, without adjusting the core process of traversing parameter fields or building a field mapping dictionary. In other words, the design purpose of the pre-defined type mapping relationship is to decouple the type resolution logic from the main process, so that a good decoupling boundary is formed between the evolution of the type system and the stability of the factory function.

[0072] Optionally, the pre-defined type mapping relationship can include not only direct mappings of basic data types, but also indirect mapping strategies for composite types or custom types. For example, for parameter fields with multi-level nested structures, the mapping relationship can point the type identifier to a nested validation pattern factory function, which recursively generates sub-validation objects based on the nested configuration, thereby supporting complex parameter validation of object or array types. As another implementation, if the system receives an unknown type identifier that is not defined in the configuration file or mapping relationship, it can perform degradation processing: uniformly mapping the unknown type to a string validation field class and performing weak validation, or triggering a log alarm to notify the operations personnel to supplement the mapping entry, to ensure that the system does not interrupt the normal configuration loading process due to type recognition failure. It should be understood that the above exception handling strategies can be flexibly configured according to the specific business requirements for data strictness, and this disclosure embodiment does not specifically limit them.

[0073] The aforementioned validation field class encapsulates the type checking, conversion rules, and default value fallback behavior required for a single parameter field, and is the smallest functional unit of the parameter validation object. Optionally, the validation field class can originate from various parameter validation frameworks, and is not limited to the implementation of a specific library. In one implementation, the validation field class can be a basic type validation class such as a string validation class, integer validation class, floating-point number validation class, or enumeration validation class. During initialization, each instance can receive configuration items such as missing value parameters, default value parameters, and validation rule parameters, thereby performing mandatory field checks, default value fallback, or regular expression matching while completing type conversion. In another implementation, the validation field class can also be a custom composite validation class, which internally encapsulates multiple sub-validation stages, such as performing type conversion first, then numerical range validation, and finally business rule validation. It should be noted that the relationship between validation field classes and type identifiers is generally one-to-one, but in some business scenarios, it can also be a many-to-one or one-to-many mapping relationship. For example, the same string type identifier can be mapped to a regular string validation class or a large text length limit validation class based on the semantic differences of the field, thereby achieving more refined parameter control.

[0074] The aforementioned field mapping dictionary uses parameter field identifiers as keys and validation field class instances as values, serving as structured input for dynamically generating parameter validation objects. Optionally, in addition to business parameter fields directly mapped from configuration data, the field mapping dictionary can further include fixed control fields injected uniformly by the system, thereby aggregating business parameters and system parameters within the same dictionary. In one implementation, fixed control fields may include online detection fields, instruction identifier constant fields, default batch size fields, and server identifier fields. The key names and value types of these fields in the dictionary are preset by the system and do not change with changes in configuration data. Furthermore, considering that the field mapping dictionary may have a large number of common structures among different instructions, the system can maintain a basic template dictionary before constructing a specific dictionary. This template dictionary pre-sets all fixed control fields and their default instances. Subsequently, the business parameter fields parsed from the configuration data are merged into the template dictionary through updates or appends, thereby avoiding the repeated construction of the same basic structure. This design not only reduces runtime object creation overhead but also ensures that different parameter validation objects have consistent behavior on system-level control fields.

[0075] In an optional implementation, parameter validation objects are dynamically created based on a field mapping dictionary. This includes: injecting fixed control fields into the field mapping dictionary, whereby the fixed control fields include an online detection field, an instruction identifier constant field, a default batch size field, and a server identifier field; and using a metaprogramming mechanism to dynamically create parameter validation objects based on the field mapping dictionary. Unified injection of fixed control fields combined with the metaprogramming mechanism to dynamically create parameter validation objects enables the validation objects to possess complete basic control capabilities and aggregates scattered fields into a complete class structure, thereby improving the flexibility of configuration-driven instruction expansion and runtime reliability.

[0076] In one implementation, after traversing the custom parameter fields and initializing the field mapping dictionary, the parameter validation module of the push gateway adds several sets of fixed control fields to the dictionary: First, the field with the key name "check_online" (online detection) is set to an integer validation class with a default value of 0; second, the field with the key name "cmd" (command identifier) ​​is set to a constant validation class with the value being the command name recorded in the configuration document; next, the field with the key name "max_push_size" (maximum push size) is set to a constant validation class with a default value of 1; subsequently, the server identifier field (such as the key name "hostnum") is set to a string validation class and the value is specified to be loaded from the "_hostnum" key of the input parameter. Further, the parameter validation module utilizes metaprogramming, using the validation base class as the parent class and the field mapping dictionary containing all the above fields as the class attribute, to dynamically create a new validation class named "Cmd{application identifier}{command name}" using the built-in "type()" function and immediately instantiate it, thereby obtaining a parameter validation object with the same capabilities as the hard-coded validation class.

[0077] Optionally, fixed control fields are designed to supplement various business instructions with unified basic control information such as online detection, command identifier, batch default value, and server identifier.

[0078] Optionally, fixed control fields may include, but are not limited to, online detection fields, command identifier constant fields, default batch size fields, and server identifier fields. The online detection field is used to determine whether to verify the target user's current online status during the deserialization stage. Its key name can be set to `check_online` (online detection), its type is integer, and its default value is 0. The command identifier constant field is used to fix the command name of the current business command, preventing the command identifier in the request body from being tampered with. Its key name can be set to `cmd` (command identifier), its type is constant, and its value is the command name recorded in the configuration document. The default batch size field is used to limit the maximum number of users pushed in a single push when there is no batch push strategy. Its key name can be set to `max_push_size` (maximum push size), and its default value is 1, indicating that batch merging is not performed by default. The server identifier field is used to extract the server number to which the target user belongs from the request parameters. Its key name can be set to `hostnum` (server number) or `server_id`, etc., according to the configuration document. Its type is string, and the field value can be loaded from the `_hostnum` key in the input parameters. It should be noted that the number and naming convention of the above-mentioned fixed control fields are only one example. In actual implementation, the default values ​​can be added, deleted, or adjusted according to business needs. For example, a version number field, a time zone field, or a client type field can be added. This disclosure is not intended to limit the composition of the above-mentioned fixed control fields.

[0079] Optionally, the metaprogramming mechanism aims to dynamically generate and instantiate parameter validation classes at runtime based on the field mapping dictionary, in order to replace statically encoded validation classes.

[0080] Optionally, the metaprogramming mechanism can be implemented using the dynamic class creation interface built into the programming language. Specifically, taking interpreted languages ​​as an example, the built-in `type()` function (type creation function) takes three parameters and receives a class name string, a parent class tuple, and a class attribute dictionary at runtime, returning a newly created class object. In one implementation, the parameter validation module first concatenates a dynamic class name based on the application identifier and instruction name, for example, according to the rule "Cmd{application identifier}{instruction name}Schema"; then, it uses a field mapping dictionary containing all custom parameter fields and fixed control fields as the class attribute dictionary, and specifies a unified validation base class `Schema` (validation pattern base class) as the parent class; finally, it calls the `type()` function to create the class object in memory and immediately performs instantiation to obtain a parameter validation object that can be directly used for deserialization and parameter validation. By generating fully functional validation classes in memory on demand through the metaprogramming mechanism, the code bloat problem caused by maintaining independent static code files for each business instruction is avoided. Furthermore, the validation capability of new instructions is entirely driven by configuration data in the database, taking effect without restarting the service.

[0081] Optionally, besides using the `type()` function for metaprogramming creation, other runtime class generation techniques can be employed to construct parameter validation objects. For example, in languages ​​supporting metaclass mechanisms, a metaclass can be predefined. The `new` method of this metaclass is configured to, upon receiving field description information, iterate through the key-value pairs in the field mapping dictionary, writing the keys as class attribute names and the corresponding validation field class objects to the class namespace, and automatically inheriting the validation base class `Schema` to complete class assembly. Alternatively, in environments supporting code generation and just-in-time (JIT) compilation, the field mapping dictionary can be serialized into an intermediate code representation based on an abstract syntax tree, where each dictionary key-value pair is converted into a class attribute declaration statement. This intermediate code is then compiled into an executable validation class in memory by the JIT compiler. It should be noted that regardless of the specific metaprogramming implementation method used, the common goal is to converge the class definition logic, originally scattered across multiple static files, into a unified factory function, making the generation process of parameter validation objects entirely driven by configuration data. Furthermore, during dynamic creation, if there are invalid field type identifiers or conflicting field attributes in the field mapping dictionary, the factory function can perform pre-validation and throw a clear exception message before class creation, thereby avoiding potential errors caused by generating invalid classes at runtime and ensuring the reliability of dynamic registration.

[0082] In an optional implementation, a parameter validation object is dynamically generated based on the parameter definition information in the configuration data. This also includes: parsing the event tracking injection strategy to determine the target field and injection direction; and binding a tracking identifier deserialization function to the target field based on the injection direction. This declarative configuration automatically completes the accurate injection of event tracking identifiers, avoiding the tedious process of manually writing event tracking code for each instruction, significantly improving the flexibility of operational configuration and the consistency of event tracking management.

[0083] In one implementation, operators fill in the event tracking injection strategy for a specific push notification in a database form storing configuration data: setting the target field as a message body field (e.g., "body" or "question"), and selecting "insert before" as the injection direction. When the system dynamically generates parameter validation objects, it parses the event tracking injection strategy and binds the insert before tracking identifier deserialization function (insert_before) to the target field. When the actual request arrives, this function automatically appends a preset formatted operation tracking identifier to the front of the original field value, eliminating the need for developers to repeatedly write event tracking logic for each notification.

[0084] Optionally, the event tracking injection strategy is used to declaratively specify the target field and injection direction so that the event tracking binding is automatically completed when the validation object is generated.

[0085] Optionally, the information included in the above-mentioned event tracking injection strategy may not be limited to the activation flag, target field name, and injection direction. It may also include the template format of the tracking identifier, business dimension tags, or other extended attributes. This disclosure is not intended to limit this. Considering that in large-scale operation platforms, if developers write event tracking injection code separately for each push instruction, it will not only cause a lot of repetitive work, but also easily lead to inconsistencies in the tracking identifier format between different instructions due to human error. As a possible implementation, the activation flag in the above-mentioned event tracking injection strategy is used to control whether the current instruction enables automatic event tracking, the target field name is used to indicate in which parameter field the tracking identifier needs to be inserted, and the injection direction is used to determine whether the identifier is appended before or after the original value of the field. In a specific scenario, when the activation flag is set to "true" and the injection direction is configured as "before", the system will automatically append the scheduling task identifier to the front of the value corresponding to the target field during the deserialization stage of the parameter validation object, thereby realizing the configurable management and unified management of event tracking logic.

[0086] Optionally, besides injecting tracking identifiers before or after the target field via string concatenation, the event tracking injection strategy can also support more diverse identifier injection forms. For example, in another implementation, the system can bind a tracking identifier wrapping function to the target field based on the configuration parsing result. This function encapsulates the original field value and the tracking identifier into a structured object during the deserialization stage (e.g., mapping the original value and the identifier to two keys of the object respectively), so that downstream systems can more precisely parse the event tracking information when consuming push data. Furthermore, to avoid the same field being injected multiple times due to repeated sending of configuration change signals, the aforementioned tracking identifier deserialization function can be designed to be idempotent, meaning that when a field value that has already undergone identifier concatenation is executed again, no new tracking identifier will be appended, thereby ensuring the consistency and traceability of the event tracking data.

[0087] Optionally, the tracking identifier deserialization function extracts the operational tracking identifier from the context dictionary of the parameter validation object during field deserialization. This identifier is then used to perform string encoding and concatenation operations with the original value of the target field according to a predetermined injection direction. The result is used as the final deserialized value of the target field. Optionally, the aforementioned tracking identifier deserialization function may include a pre-insertion function (e.g., insert_before) or a post-insertion function (e.g., insert_after). Its specific function is to automatically concatenate the operational tracking identifier before or after the original value of a specified field when the parameter validation object deserializes the request data. For example, the insert_before function receives the original field value and a context dictionary, reads the tracking identifier with the key compass_task_id from the context dictionary, and if the original field value is a non-empty string, concatenates the tracking identifier to the beginning of the string and returns the concatenation result; if the original field value is empty or missing, it directly returns the tracking identifier itself or an empty string to skip the instrumentation injection. It should be noted that the naming and implementation of the function described above are only one example. In actual deployment, a higher-order function factory can be used to dynamically generate specific concatenation logic based on the configuration, or the generation rules of tracking identifiers can be externalized into template strings and dynamically rendered by the function. This disclosure is not limited to these. Considering that the push gateway needs to process tens of millions of requests daily, if each hard-coded class independently maintains the tracking logic, it is very easy for tracking identifiers to be missed or formatted incorrectly. By converging the tracking logic into a unified deserialization function and binding it through configuration, on the one hand, the maintenance difficulties caused by scattered code can be avoided, and on the other hand, it allows operators to directly adjust the tracking target fields and injection direction on the visual interface, changing the tracking behavior without the intervention of developers.

[0088] In an optional implementation, parameter validation objects are dynamically generated based on parameter definition information in the configuration data. This also includes: parsing the batch push strategy; when batch push is enabled, overriding the default batch size parameter with a configuration value, and configuring a user identifier processing strategy. Configuring the user identifier processing strategy includes: generating a user identifier concatenation function based on the concatenation type and concatenation characters in the batch push strategy and binding it to the corresponding user identifier processing strategy. This configuration-based approach enables flexible injection of batch push parameters, allowing adjustment of batch size and user identifier assembly rules without code modification, significantly improving operational response efficiency and reducing maintenance costs.

[0089] In one implementation, the configuration data includes a batch push strategy, specifically comprising an indicator of whether batch push is enabled, the maximum number of pushes, and user identifier concatenation rules. When dynamically generating a parameter validation object, the system first parses the batch push strategy; if the batch push indicator is enabled, the original default batch size parameter (e.g., a fixed value of 1) in the parameter validation object is replaced with the configuration value specified in the configuration document (e.g., 50). Simultaneously, based on the user identifier processing method recorded in the batch push strategy, the system identifies the concatenation type (e.g., string concatenation mode) and concatenation characters (e.g., standard commas), and dynamically generates a user identifier concatenation function accordingly. This function receives a sequence of multiple user identifiers and concatenates them into a string according to specified characters. Subsequently, the system binds this user identifier concatenation function to the user identifier processing strategy of the corresponding instruction, so that when processing batch push business instruction requests, it can correctly format and assemble multiple user identifiers according to this strategy.

[0090] Optionally, the batch push strategy controls the maximum number of pushes for a single business instruction and the method of assembling user identifiers. It may include information such as whether batch push is enabled, the maximum push value, and user identifier concatenation rules. Optionally, as an important component of the configuration data, the batch push strategy may include, but is not limited to, a batch push switch flag, a maximum push threshold, and user identifier concatenation rule definitions. In actual deployment, extended information such as retry counts or timeout periods can be added based on the network environment. When the batch push switch flag in this strategy is enabled, the batch parameter injection process will be automatically triggered during the dynamic generation of parameter validation objects. When the switch is disabled, the system maintains the default order-by-order push mode and does not adjust the batch parameters. This differentiated switch control mechanism aims to allow operations personnel to flexibly control the batch behavior of downstream push instructions through simple form operations in the management backend, without requiring developers to modify any code logic, thereby significantly shortening the response cycle for business changes.

[0091] Optionally, the configuration of the maximum push quantity threshold in the batch push strategy directly affects the upper limit of the number of user identifiers that can be carried in a single network request. This threshold can be set differently according to the server processing capacity, network bandwidth, and actual needs of the downstream game product and business scenario. For example, for character email notifications, it can be set to 20 user identifiers per batch; while for system announcement broadcasts, it can be appropriately relaxed to 100 user identifiers per batch. Furthermore, the definition of the user identifier concatenation rules in this strategy can be further distinguished into different concatenation types and corresponding concatenation characters, thereby providing adaptive data assembly capabilities for different downstream systems. It should be noted that the above description of the quantity threshold is only one example, and this disclosure is not intended to limit the specific values.

[0092] Optionally, the default batch size parameter represents the system's preset per-order processing quantity when batch push is not enabled. It is typically embedded as a constant in the parameter validation object. Optionally, the default batch size parameter plays a basic quantity control role in the parameter validation object. Its initial value is usually set to a constant 1, indicating that the system processes business instruction requests using a per-order push method by default. When the configuration value recorded in the batch push strategy is activated, this default value will be dynamically overridden to the value specified in the configuration document, thus enabling the parameter validation object to adapt to different batch sizes. It should be noted that this parameter is not limited to representing the number of pushes; in practical applications, it can also be extended to control related metrics such as the number of concurrent threads, buffer capacity, or retries. This disclosure does not limit this. Through this overriding mechanism, the system can achieve elastic scaling of batch processing capabilities by adjusting the configuration level without changing the underlying code.

[0093] Optionally, the user identifier processing strategy is used to define the assembly logic of multiple user identifiers in a batch push scenario. It dynamically determines the formatting method of the identifier data based on the splicing type and splicing characters.

[0094] Optionally, the user identifier processing strategy is a key intermediate logic connecting upstream user data and downstream push gateways. Its specific implementation can be a strategy object containing processing functions and their metadata, or a set of predefined rule templates. In batch push scenarios, when the system receives a business instruction request containing multiple user identifiers, it will perform pre-formatting operations on these identifiers according to the processing functions bound to the strategy. In non-batch scenarios, the strategy can be configured in pass-through mode, that is, the received user identifiers are passed to the downstream processor as is. Furthermore, the generation process of this strategy is entirely driven by configuration data. Operations personnel only need to select the splicing mode and enter the delimiter in the visual interface, and the system can automatically complete the construction and binding of the strategy object at runtime, without requiring developers to manually write any identifier processing code.

[0095] Optionally, the user identifier processing strategy can also nest multiple levels of conditional logic to address complex business scenarios. For example, when the number of users pushed to in batches exceeds a preset threshold, the strategy can automatically trigger a segmentation mechanism, dividing the large user list into several groups and assembling them separately. When the user identifier itself contains special characters, the strategy can automatically call an escape function to prevent the concatenated string from violating the syntax rules of the downstream parser. Furthermore, this strategy can be linked with user grouping rules and sending time window rules to append channel tags or timestamp information while formatting user identifiers, thereby achieving more refined batch push control. This highly flexible strategy configuration effectively avoids the maintenance difficulties of frequently modifying source code due to changes in business rules under the traditional hard-coded model.

[0096] Optionally, the splicing type is used to characterize the combination method between multiple user identifiers, which may include direct splicing, structured encapsulation, or splicing mode with escaping processing.

[0097] Optionally, the concatenation type plays a crucial role in differentiating assembly patterns within the user identifier processing strategy. As one possible implementation, the concatenation type can be configured as a concatenation mode, where multiple user identifiers are chained together using string concatenation. Alternatively, it can be configured as a structured encapsulation mode, encapsulating multiple user identifiers into a standard data structure format. For example, the user identifier sequence can be converted into a JSON array object, where each element is an object entry containing user identifier fields and their corresponding values. In this mode, the system generates a serialization function based on the data structure template declared in the configuration. This function iterates through the user identifier sequence and fills each identifier into the corresponding field position in the template, ultimately outputting a structured data message that conforms to the downstream interface protocol requirements. In practical applications, the specific value of the concatenation type can be dynamically selected based on the requirements of the downstream game product interface protocol. For example, for interfaces that support native batch parameter input, direct string concatenation is sufficient; while for interfaces requiring strict data formats, the structured encapsulation mode can be selected. It should be noted that the above list of splicing types is only a partial example, and this disclosure is not intended to exhaustively limit it. Any pattern that can achieve reasonable assembly of multiple identifiers can be included in the protection scope of this disclosure.

[0098] Optionally, concatenation characters are used to define the separators between adjacent user identifiers in string concatenation mode; these characters can be visible characters, invisible characters, or a combination thereof.

[0099] Optionally, the concatenation character serves as a parameter accompanying the concatenation type, and its specific value can be flexibly configured according to the parsing habits of downstream systems and business readability requirements. For example, in conventional scenarios, a standard comma can be used as the concatenation character, resulting in a clearly readable list of user identifier strings. In scenarios involving complex data structures, special symbols (such as vertical bars or custom delimiter strings) can be used as concatenation characters to avoid conflicts with the regular characters contained in the user identifier itself. If the downstream interface requires transmission in binary or fixed-length field format, the concatenation character can also be extended to padding bytes or alignment codes. This mechanism of specifying delimiters through configuration rather than encoding allows operations personnel to adapt simply by modifying the character configuration in the management backend when the interface protocol changes, without needing to redeploy the service process.

[0100] Optionally, the user identifier concatenation function is used to perform a formatted assembly operation on multiple discrete user identifiers at runtime. It is bound to the user identifier processing strategy as a function object for batch push process to call.

[0101] Optionally, the user identifier concatenation function can be dynamically generated using a higher-order function design pattern. Specifically, the system first reads the concatenation character parameters from the configuration data, then uses a basic concatenation function as a template, injecting the concatenation characters as closure variables into it, and finally returns a dedicated concatenation function with a specific delimiter. This function, after receiving a sequence of multiple user identifiers, iterates through the sequence and inserts the concatenation characters stored in the closure between adjacent elements, thereby generating a formatted string that meets the requirements of the downstream interface. As another possible implementation, if the concatenation type requires more complex assembly logic (e.g., adding prefix tags or suffix checksums), the system can also construct a concatenation function with composite processing capabilities through multi-level nested higher-order function chains. This mechanism of dynamically generating function objects at runtime avoids hard-coding each concatenation rule, effectively reducing code redundancy.

[0102] Optionally, when the user identifier concatenation function is bound to a user identifier processing strategy, exception handling logic and fault tolerance mechanisms can be added. For example, when there are null values ​​or data items with abnormal formats in the input user identifier sequence, the function can automatically perform filtering operations or insert placeholders in the output to ensure that the downstream parser does not report errors due to missing data. Furthermore, the function can also be integrated with log tracking logic to record performance metrics such as the amount of input data, the execution time, and the length of the output string each time a concatenation operation is performed, providing data support for subsequent operational monitoring and capacity planning. Considering that different business instructions may target game products that use completely different user identifier systems (such as numeric accounts, letter-based character names, or composite tokens), the function can also integrate polymorphic distribution logic to automatically call the corresponding format validation submodule based on the instruction's affiliation, ensuring the legality and compatibility of the concatenation result.

[0103] In step S270, the parameter validation object is registered to the service mapping table based on the service identification information. By registering the parameter validation object to the service mapping table, the dynamic association between validation logic and distribution routing is realized, enabling new service instructions to obtain complete parameter validation and addressing capabilities without code changes, significantly improving the system's scalability and maintenance efficiency.

[0104] In one example, after the parameter validation object is generated by the factory function, the system extracts the business identification information (such as the application number) corresponding to the object, and uses the business identification information as the index key to register the parameter validation object instance into the instruction processor instance corresponding to the application number in the business mapping table. This allows subsequent business instruction requests with the same business identification information to directly retrieve the corresponding parameter validation object through the business mapping table, thereby performing field type checks, default value filling, and format conversion operations on the request message without requiring developers to write separate validation class code for new instructions.

[0105] Optionally, the business mapping table stores the instruction processor instances corresponding to each business identifier and their bound parameter validation objects to achieve fast mapping between dynamic configuration and runtime routing. Optionally, the business mapping table can be a global dictionary structure or a hash mapping container, using business identifier information (such as application number, channel code, or product identifier) ​​as the primary key index, with each primary key index corresponding to an instruction processor instance. This instruction processor instance internally maintains an instruction parameter dictionary to carry the mapping relationship between different command aliases and parameter validation objects. In actual deployment, the business mapping table can reside in the memory space of the Web service process, allowing parameter validation objects to be retrieved and invoked with constant time complexity after registration, thereby avoiding performance loss caused by frequent disk I / O or remote queries. Furthermore, the instruction processor instances in the business mapping table can be pre-configured through static code during system initialization or dynamically created through metaprogramming during runtime; this disclosure does not limit this. When a new business instruction configuration is loaded, simply binding the dynamically generated parameter validation object to the instruction parameter dictionary under the corresponding business identifier is sufficient to give the business instruction complete request validity verification capabilities without restarting the service or modifying the source code.

[0106] In an optional implementation, the parameter validation object is registered to the business mapping table based on the business identification information. This includes: checking if an instruction processor instance corresponding to the application identifier exists in the business mapping table; if not, creating an instruction processor instance corresponding to the application identifier and registering it in the business mapping table; if it exists, obtaining the existing instruction processor instance corresponding to the application identifier; and binding the parameter validation object to the instruction parameter dictionary of the instruction processor instance. By dynamically detecting and creating instruction processor instances on demand, seamless dynamic access for both new and old game products is achieved. This avoids code bloat from pre-writing adapter classes for each application and ensures accurate binding between the parameter validation object and the business processing logic.

[0107] In another optional implementation, for business instructions with globally unique command aliases, the system can directly register the parameter validation object to the global validation object table using the command alias as the index key, without going through the distribution layer of the intermediate instruction processor instance. When a business instruction request arrives, the gateway directly retrieves the corresponding parameter validation object from the global validation object table by extracting the command alias from the request, performs parameter validation, and then locates the target channel processor to complete the routing distribution. By skipping the instance detection and creation stage at the application identifier level, the nesting depth of the mapping table can be further reduced, and the number of memory objects in the registration stage can be reduced, making it suitable for scenarios with rapid access to lightweight business instructions.

[0108] In one implementation, after the Web service process reloads its configuration, the system iterates through the set of configuration data to be registered. For an application identifier (such as "app01") in a configuration document, the system checks whether an existing instruction processor instance with that application identifier as the key exists in the global business mapping table. If the application identifier appears for the first time, it indicates that the corresponding game product has not been connected before. The system immediately uses metaprogramming to dynamically create a new instruction processor instance, sets its class name to the uppercase form of the application identifier, and inherits from the base adapter class. Then, it registers the instance in the business mapping table. If a corresponding instance already exists in the business mapping table, the existing instruction processor instance is directly retrieved. Regardless of whether a new instance is created or reused, the system binds the previously dynamically generated parameter validation object to the instruction parameter dictionary inside the instruction processor instance to complete the closed-loop registration from parameter validation to business processing.

[0109] Optionally, the aforementioned application identifier is used to uniquely identify downstream business products and can serve as a key-value pair for retrieving instruction processor instances in the business mapping table. Optionally, the application identifier can be represented as a product code, application number, or channel package identifier for the downstream game product. In the dynamic registration process, this application identifier not only serves as an index key for querying the business mapping table but is also used to dynamically generate the class name of the instruction processor instance, thereby establishing a one-to-one mapping relationship between configuration data and runtime objects. It should be noted that the same application identifier remains globally unique across different configuration documents to avoid conflicts between instructions from different game products in the business mapping table. In one specific implementation, the application identifier can be recorded in the identifier field of the configuration document, for example, with a value such as "app01" or "app02". When the daemon loads the configuration, it reads this field line by line and determines whether the current configuration belongs to a new instruction extension for an existing game product or requires creating a corresponding instruction processor instance for a completely new game product, thus deciding whether to execute the branch logic of instance reuse or dynamic creation via metaprogramming.

[0110] Optionally, the above instruction processor instances are designed to encapsulate instruction verification and forwarding logic, and can be dynamically created and registered through metaprogramming mechanisms.

[0111] Optionally, the aforementioned instruction processor instance can be a dynamic class instance inherited from the base adapter class. Its class name is typically derived from the application identifier, for example, mapping the application identifier "app01" to the class name "APP01". Considering that pre-hardcoding the adapter class for each downstream game product would lead to a linear increase in code size with the number of products, as a possible implementation, this embodiment utilizes the metaprogramming mechanism of programming languages ​​to dynamically create the instance at runtime: using the base adapter class as the parent class and an empty attribute dictionary or a dictionary containing specific class attributes as the namespace, a new instruction processor class is generated in memory through the built-in type constructor and immediately instantiated. After creation, this class automatically possesses the capabilities provided by the parent class, such as general parameter extraction, channel routing query, and batch push preprocessing. Furthermore, the system registers this instance to the global business mapping table with the application identifier as the key, allowing different business instructions for the same game product to reuse this instance. Only a new parameter validation object needs to be added to its instruction parameter dictionary, thus supporting the rapid integration of a massive number of game products with extremely low runtime overhead.

[0112] Optionally, in addition to dynamically creating instruction processor instances for new game products, the system will directly extract and reuse existing instances of application identifiers already existing in the business mapping table, avoiding memory redundancy and state inconsistency risks caused by repeated creation. It should be noted that the instruction processor instance maintains at least two core mapping structures: one is an instruction parameter dictionary, used to store the mapping relationship between each command alias and parameter verification objects; the other is a user identifier processing policy dictionary, used to record player identity resolution rules under different commands. In practical applications, if a game product has been offline or has had no active configurations for a long time, the system can also periodically scan the business mapping table and clean up idle instances that are not referenced by any effective configurations to release server memory resources. In other words, the lifecycle of the instruction processor instance is linked to the existence and state of the configuration data, enabling it to be created in seconds when a new game is integrated and safely reclaimed after the configuration expires, forming a complete instance governance closed loop.

[0113] Optionally, the aforementioned instruction parameter dictionary is used to store the mapping relationship between command aliases and parameter verification objects, and can be dynamically updated according to configuration data. Optionally, the aforementioned instruction parameter dictionary can be represented as a hash map table or object attribute container within the instruction processor instance, with the command alias as the key and the dynamically generated parameter verification object instance as the value. During the registration phase, the system first generates a unique command alias for the current configuration data, for example, concatenating "cmd_{application identifier}_{instruction name}" to obtain "cmd_app01_example_cmd". Then, this command alias is used as the key, and the parameter verification object generated by the factory function is used as the value, written to the instruction parameter dictionary. When a business instruction request arrives, the instruction processor instance retrieves the dictionary based on the command alias in the request, quickly obtaining the corresponding parameter verification object to perform deserialization and field verification operations. It should be noted that this dictionary supports mounting multiple command aliases under the same instruction processor instance, thereby achieving centralized parameter verification management for multiple instructions under the same game product. Furthermore, when adding or updating instructions, only specific key-value pairs in the dictionary need to be modified, without altering the structure of the instruction processor instance itself.

[0114] In an optional implementation, registering the parameter validation object to the service mapping table further includes: determining the corresponding target channel processor based on channel classification; binding the command alias of the service instruction to the target channel processor and appending it to the corresponding route list in the channel routing table. Binding command aliases to target channel processors and appending them to the route list through channel classification enables dynamic route registration, allowing instructions from different channels to be automatically distributed to the corresponding processors. This supports flexible expansion and unified management of multiple push channels, avoiding the maintenance costs and deployment delays associated with hard-coded routes.

[0115] In one implementation, after the system completes the registration of parameter verification objects and business mapping tables for the game product, it reads the channel classification field (e.g., with a value of "user operation") from the corresponding configuration document, determines the target channel processor as the user operation processor, generates a command alias cmd_demo_app_demo_cmd and binds it to the processor, and appends it to the user operation channel routing list. When the gateway receives a business instruction request containing the command alias from the upstream system, it directly queries the channel routing table to obtain the corresponding user operation processor instance and distributes the request, thereby completing the push processing after parameter verification and data entry injection.

[0116] Optionally, channel classification is used to identify the type of push channel to which the business instruction belongs, so as to determine the corresponding target processing strategy based on the channel category.

[0117] Optionally, channel classification can be category information that identifies the business channel to which the push command belongs, such as "user operation," "popup in game," or "sprite." Besides being directly recorded in the `channel` field of the configuration document, these channel classifications can also be dynamically derived based on application identifiers, command types, or operational scenarios. Considering that different push channels often correspond to drastically different downstream processing logic and parameter validation rules, by configuring a clear channel classification for each command, the system can accurately identify which processing pipeline the command should enter at runtime, thereby avoiding potential errors such as misrouting popup-type commands to the email processor. It should be noted that the above enumeration of channel classifications is only one example, and this disclosure does not intend to limit the way channel categories are divided. In actual implementation, channels can be divided into more granular secondary channels based on business scale or product form, or multiple similar channels can be merged into the same category.

[0118] Optionally, the target channel processor is the execution unit responsible for specific push logic. Different channel categories correspond to different processor instances to achieve differentiated processing. Optionally, the target channel processor can be a business processor instance responsible for executing specific push command issuance logic, such as a user operation processor, an in-game pop-up processor, or a notification processor. In addition to forwarding commands to downstream game servers, this target channel processor can also include functional modules such as parameter secondary encapsulation, event tracking and triggering, and collection of sending result feedback. To avoid requests not being responded to correctly due to missing processors, the system can pre-check whether the processor instance is loaded and ready before determining the target channel processor according to the channel category; if missing, the system can fall back to the default processor or record abnormal alarm information. Furthermore, the same target channel processor instance can be shared by multiple different command aliases, thereby reducing the overhead of repeated instantiation in push scenarios with the same or similar processing logic.

[0119] Optionally, a command alias is a unique identifier string for a business instruction at the routing layer, used to establish a mapping relationship with the target channel processor in the channel routing table. Optionally, the command alias can be a unique routing identifier string automatically generated by the system for each business instruction during the registration phase, such as cmd_demo_app_cmd01, cmd_demo_app_cmd02, or cmd_demo_app_cmd03, etc., typically composed of an instruction prefix, application identifier, and the original instruction name. Besides serving as a primary key for lookup in the channel routing table, this command alias can also be used as an association identifier for log tracing, traffic monitoring, and permission verification. Considering the potential for naming conflicts in multi-application, multi-instruction scenarios, the above command alias generation rules can combine the application identifier and the original instruction name, and append hash fragments or timestamps when necessary to ensure global uniqueness. In other words, the specific structure of the command alias is not limited to a fixed format, as long as it uniquely points to the corresponding target channel processor during the routing lookup phase.

[0120] Optionally, the channel routing table is a data structure that stores the mapping relationship between command aliases and target channel processors, and supports dynamic appending and querying to implement request routing.

[0121] Optionally, the channel routing table can be a data structure that stores the mapping relationship between command aliases and target channel processors, such as a dictionary structure or a hash mapping structure with command aliases as keys and processor instances as values. In addition to dynamically registered mapping entries, this channel routing table can also retain statically hard-coded routing entries, allowing new and old commands to run together in the same routing table. To avoid dirty data or memory leaks during dynamic registration, the system can perform idempotency checks or update / replace existing entries for the same command alias before adding new mapping relationships. That is, even if the daemon process repeatedly sends reload signals due to an anomaly, the routing table content written by the Web service process after reloading the configuration remains consistent, without causing duplicate registration or side effects.

[0122] Optionally, the channel routing table can be physically deployed as a centralized single-table structure, a sharded structure partitioned by channel dimension, or a replicated table synchronized across multiple service instances using a distributed consistency protocol. To avoid single-point query performance bottlenecks, the aforementioned channel routing table, in addition to residing in the memory space of the Web service process, can also be deployed in a near-end cache layer, significantly reducing routing resolution overhead during peak request periods. When a channel processor instance undergoes hot updates or goes offline, the system can compare the differences between the old and new routing tables and perform incremental replacement only on the changed key-value pairs, without needing to clear and rebuild the entire routing table. It should be understood that the above description of the channel routing table storage medium is only one example and is not intended to limit its deployment method.

[0123] Optionally, the routing list is a collection of command aliases aggregated by channel category, used to dynamically register commands within the same channel to the channel routing table in batches. Optionally, the routing list can be a collection of command aliases aggregated by channel category, such as a list of command aliases belonging to the user operation channel, a list of command aliases belonging to the in-game pop-up channel, or a list of command aliases belonging to the sprite message channel. Besides being used for batch registration of command aliases within the same channel, this routing list can also serve as the index basis for channel-level canary releases, traffic circuit breaking, or batch permission control. In other words, when the system needs to perform a unified policy adjustment for all commands in a certain channel, it only needs to traverse the routing list corresponding to that channel to quickly locate all affected command aliases, without having to traverse the entire channel routing table. It should be noted that the storage format of the routing list mentioned above can be an array, linked list, or collection container; its specific data structure can be flexibly chosen according to the search frequency and memory usage requirements.

[0124] In step S290, in response to a business instruction request, parameter validation and routing are performed on the request based on the business mapping table. When accepting a business instruction request, the dynamically registered validation object and routing mapping can be directly invoked to complete the validation and forwarding, achieving a seamless connection between configuration application and request processing, and improving the accuracy and automation level of instruction distribution.

[0125] In one implementation, the upstream system sends a business instruction request to the push gateway. This request carries a command alias, an application identifier, and encapsulated parameter fields. Upon receiving the request, the server-side worker process queries the business mapping table based on the command alias in the request, locating the parameter validation object and its corresponding channel processor, which were previously dynamically registered using configuration data. The parameter validation object performs validation operations on the parameter fields in the request, including type conversion, default value filling, and tracking identifier injection. Subsequently, the channel processor pushes the processed message to the downstream game server based on the routing results. Through this process, newly configured instructions can be processed normally in the production environment without restarting the service, ensuring the continuity and consistency of business instruction processing.

[0126] Optionally, the business instruction request is intended to carry the instruction content initiated by the external system to the push gateway, used to trigger subsequent parameter validation and routing distribution processes. Optionally, the business instruction request is a structured data message sent by the upstream operation system or the upstream service of the message gateway. In addition to the command alias (e.g., cmd_demo_app_cmd01) and application identifier (e.g., app_id is demo_app) used for routing location, this message also carries custom parameter fields that need to be validated by the parameter validation object. To avoid processing anomalies caused by inconsistent request formats, the data format of this business instruction request can be a key-value pair structure conforming to a common object representation protocol (e.g., JSON, a textual data representation structure), where the key names are consistent with the parameter field identifiers defined in the management backend during the visual configuration phase. After the gateway receives the request, it first indexes the corresponding parameter validation object and channel processor from the business mapping table based on the command alias, and then hands it over to the parameter validation object to perform default value filling, type conversion, and instrumentation identifier injection on the parameter fields in the request. By matching the metadata in the request with the verification and routing rules generated during the dynamic registration phase, newly configured push commands can be correctly identified and processed in production traffic without modifying the source code.

[0127] Optionally, routing processing is used to direct verified requests to target channel processors based on instruction identifiers, thereby enabling downstream forwarding of push instructions. Optionally, routing processing relies on a channel routing table (such as a push processor mapping table) dynamically built during the configuration hot-loading phase to complete request distribution. In one possible implementation, when the server-side worker process receives a business instruction request, it first extracts the command alias from the request, and then retrieves the target channel processor instance bound to that alias from the channel routing table. This processor instance can be a user operation processor for game sprite messages, or a pop-up in-game processor for pop-up notifications, specifically determined by the channel classification field selected during the visual configuration phase. Simultaneously, the system utilizes the game adapter instance registered in the game business mapping table to perform concatenation and conversion on the user identifier in batch push scenarios, and calls the interface of the downstream game server to complete message delivery. It should be noted that the above routing processing and parameter verification processes are executed sequentially within the same request processing chain. Furthermore, since all routing relationships are dynamically generated based on database configuration, operators can adjust the push target channel of the instruction without releasing a new version, making the distribution path of the business instruction highly flexible and configurable.

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

[0129] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

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

Claims

1. An information processing method, characterized in that, The method includes: Obtain configuration data, which includes parameter definition information and service identification information of service instructions; In response to a configuration update condition, read the configuration data; Based on the parameter definition information in the configuration data, a parameter validation object is dynamically generated; Based on the business identification information, the parameter verification object is registered to the business mapping table; In response to a business instruction request, the business instruction request is processed for parameter validation and routing according to the business mapping table.

2. The method according to claim 1, characterized in that, The step of reading the configuration data in response to a configuration update condition includes: Query the configuration data set in the configuration database at predetermined intervals that is in effect and marked as not deleted, and obtain the update timestamp corresponding to the configuration data with the latest update timestamp in the configuration data set as the current update timestamp; The current update timestamp is compared with the most recent update timestamp in the local cache to perform incremental change detection; If the current update timestamp is greater than the most recent update timestamp, it is determined that a configuration change has been detected. The queried configuration data set is serialized into a local configuration file and persisted to local storage, triggering the service process to reread the configuration data.

3. The method according to claim 2, characterized in that, The step of serializing the retrieved configuration data set into a local configuration file and persisting it to local storage, triggering the service process to reread the configuration data, includes: The entire set of configuration data retrieved is serialized into a single local configuration file and written to the local file system in an atomic file writing manner; If it is determined that the service process is running, a reload signal is sent to the service process so that the service process responds to the reload signal, reads the configuration data from the local configuration file, and updates the most recent update timestamp in the local cache to the current update timestamp.

4. The method according to claim 1, characterized in that, The step of dynamically generating a parameter validation object based on the parameter definition information in the configuration data includes: Parse the parameter definition information to obtain the field attributes of each parameter field; Based on the field attributes, match the corresponding parameter validation rules for each parameter field; Based on the identifiers of each parameter field and their matching parameter validation rules, a parameter validation rule set is constructed, and the parameter validation object is dynamically created based on the parameter validation rule set.

5. The method according to claim 4, characterized in that, The step of dynamically creating the parameter validation object based on the parameter validation rule set includes: Iterate through each parameter field in the parameter definition information; Based on the type identifier of each parameter field, the corresponding validation field class is determined through a pre-defined type mapping relationship; Construct a field mapping dictionary based on the identifier of each parameter field and the corresponding validation field class; The parameter validation object is dynamically created based on the field mapping dictionary.

6. The method according to claim 1, characterized in that, The step of dynamically generating a parameter validation object based on the parameter definition information in the configuration data further includes: Analyze the aforementioned data entry injection strategy to determine the target fields and injection direction; Based on the injection direction, a tracking identifier deserialization function is bound to the target field.

7. The method according to claim 1, characterized in that, The step of dynamically generating a parameter validation object based on the parameter definition information in the configuration data further includes: Analyze the batch push strategy; When batch push is enabled, override the default batch size parameter with the configured value, and configure the user identifier processing strategy. The configured user identifier processing strategy includes: generating a user identifier concatenation function and binding it to the corresponding user identifier processing strategy based on the concatenation type and concatenation characters in the batch push strategy.

8. The method according to claim 1, characterized in that, The step of registering the parameter verification object to the business mapping table according to the business identifier information includes: Check if an instruction processor instance corresponding to the application identifier exists in the service mapping table; If the application does not exist, create an instruction processor instance corresponding to the application identifier and register it to the service mapping table; If it exists, obtain the existing instruction processor instance corresponding to the application identifier; The parameter verification object is bound to the instruction parameter dictionary of the instruction processor instance.

9. The method according to claim 8, characterized in that, The step of registering the parameter validation object to the business mapping table further includes: The corresponding target channel processor is determined based on the channel classification. The command alias of the service instruction is bound to the target channel processor and appended to the corresponding route list in the channel routing table.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, are used to implement the information processing method as described in any one of claims 1 to 9.

Images