A message processing method, apparatus, device, and medium
Patent Information
- Application Number
- CN202611114141.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-24
- Publication Date
- 2026-10-27
AI Technical Summary
[0004](3)、语义映射复杂:不同协议中对同一业务概念的字段命名、编码方式(如状态码枚举值)、单位(如公里/英里)不同,需要进行复杂的转换
[0029]本发明根据待处理消息特征确定待处理消息对应的帧结构模板ID,基于预先构建的全局注册表确定帧结构模板ID对应的帧解析器实例;全局注册表为用于存储模板ID与解析器/转换器实例的映射关系的表;通过调用帧解析器实例的parse方法提取消息ID,确定消息ID对应的预设的正文格式模板,基于预设的全局注册表确定预设的正文格式模板对应的正文解析器实例;通过调用正文解析器实例的parse方法得到相应的源消息实体,基于预设的转换映射模板以及源消息实体确定目标消息实体;通过正文解析器实例调用编码方法对目标消息实体进行编码,输出相应的编码后数据,以完成消息处理。
Smart Images

Figure CN122994136A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of information processing technology, and in particular to a message processing method, apparatus, device, and medium. Background Technology
[0002] With the surge in demand for system interconnection, a system (such as a central platform) often needs to interact with many different types of terminals or subsystems. The message formats (protocols) used by these interacting parties vary widely, mainly in the following ways: (1) Differences in frame structure: byte order (big endian / little endian), bit order, start / end identifier, length field definition, check algorithm (CRC (Cyclic redundancy check), summation, etc.) are different.
[0003] (2) Differences in message body structure: The data elements have different types (integers, floating-point numbers, strings), lengths (fixed-length / variable-length), order of arrangement, nesting relationships, appearance of conditions (optional fields), and rules for repetition (sets).
[0004] (3) Complex semantic mapping: Different protocols have different field names, encoding methods (such as status code enumeration values), and units (such as kilometers / miles) for the same business concept, which require complex conversion.
[0005] Currently, the industry's solutions to the above problems can be mainly divided into the following categories, but all of them have shortcomings: (1) Hard-coding method: Dedicated parsing and conversion code (Java classes, C structs, etc.) is written for each message format that needs to be processed. The disadvantages are as follows: Development efficiency is extremely low: every time a new protocol is added, a new set of code needs to be developed, tested, and deployed, which takes a long time.
[0006] High maintenance costs: Once the protocol format changes, the corresponding code must be found, modified, recompiled, and deployed, which is prone to errors.
[0007] Poor flexibility: Unable to dynamically support new protocols at runtime, resulting in a rigid system.
[0008] Technology stack binding: The code is deeply coupled with a specific programming language, making it difficult to port.
[0009] (2) Parsing methods based on XML / XSD (eXtensible Markup Language) / (XML Schema Definition) or custom description files: The message format is described using XML Schema (XSD) or a custom text file, and the parsing process is driven by a generic parser reading the description file. The disadvantages are as follows: Low expression efficiency: For scenarios with complex condition fields, variable-length field groups, and dynamic lengths that depend on other fields, a large number of redundant XML Schema definitions need to be written, which is cumbersome, has poor readability, and is difficult to maintain.
[0010] Performance bottleneck: XML parsing itself is costly, and the runtime interpretation and execution of the description logic (not compiled execution) is inefficient and cannot meet the processing needs of high-frequency trading or massive IoT data.
[0011] Weak conversion support: Such solutions typically focus on parsing and lack sufficient support for complex, configurable message format conversions, often requiring the conversion logic to be implemented through coding.
[0012] (3) General serialization framework: Examples include Protocol Buffers, Apache Thrift, and Avro. They provide IDL (Interface Description Language), which can automatically generate multi-language code for serialization / deserialization. However, they have the following drawbacks: Highly intrusive: Requires both communicating parties to use the same IDL and generated code, making it unsuitable for scenarios that need to interface with a large number of existing, unchangeable third-party proprietary protocols.
[0013] Insufficient dynamism: Although the generated code has high performance, changes to the protocol still require the code to be regenerated and deployed, and it does not have the ability to dynamically update at runtime.
[0014] Non-core functions: These functions primarily address the encoding and decoding of structured data, rather than focusing on mapping and conversion between heterogeneous formats.
[0015] (4) ETL (Extraction Transformation Loading) tools based on rule engines: Some enterprise-level integration platforms or ETL tools provide graphical configuration interfaces, allowing users to configure data mapping and transformation rules through drag-and-drop. However, this approach has the following drawbacks: Bulky and complex: Often part of a large suite, with high deployment and maintenance costs.
[0016] Performance is generally not suitable for the communication layer: the design goals are mostly batch processing or enterprise application integration, which makes it difficult to meet the low latency and high concurrency requirements of communication protocol processing.
[0017] Poor support for binary protocols: It is better at handling text (such as CSV (Comma-Separated Values), XML, JSON (JavaScript Object Notation, a lightweight data interchange format) or semi-structured data, and has weak support for binary protocols that operate at the byte level.
[0018] It is evident that how to achieve a unified message parsing and conversion that balances flexibility, high performance, strong descriptive capabilities, and dynamic update capabilities is a problem that needs to be solved by those skilled in the art. Summary of the Invention
[0019] The purpose of this invention is to provide a message processing method, apparatus, device, and medium that enables zero-reflection invocation for the parsing and transformation of each message, achieving powerful descriptive capabilities and supporting flexible and efficient message conversion. The specific solution is as follows: In a first aspect, the present invention discloses a message processing method, comprising: The frame structure template ID corresponding to the message to be processed is determined based on the characteristics of the message to be processed, and the frame parser instance corresponding to the frame structure template ID is determined based on the pre-built global registry; the global registry is a table used to store the mapping relationship between template IDs and parser / converter instances; The message ID is extracted by calling the parse method of the frame parser instance, the preset text format template corresponding to the message ID is determined, and the text parser instance corresponding to the preset text format template is determined based on the preset global registry. The corresponding source message entity is obtained by calling the parse method of the text parser instance, and the target message entity is determined based on the preset transformation mapping template and the source message entity. The target message entity is encoded by calling the encoding method through the text parser instance, and the corresponding encoded data is output to complete the message processing.
[0020] Optionally, before determining the frame parser instance corresponding to the frame structure template ID based on a pre-built global registry, the following steps are also included: When the listener detects the existence of a template file in the target directory, it reads the template file and sends a target notification to the preset template compilation manager. The template file is a JSON file pre-created by the operations and maintenance personnel. The template file includes a frame structure template for describing the message header, a body format template for describing the message body, a conversion rule template for describing the mapping rules between message formats, and a conversion mapping template for describing the message ID that needs to be converted. The preset template compiler reads each field in the template file based on the target notification and generates Java source code based on the corresponding fields. The default compiler is invoked to compile Java source code into bytecode. Create a target class loader for loading bytecode, and send the bytecode to the target class loader through a preset template compiler manager so that the target class loader can automatically instantiate a parser / converter instance; The global registry is constructed by registering the parser / converter instance and the corresponding template ID of the parser / converter instance to the global registry through the preset template compilation manager.
[0021] Optional message processing methods also include: Persistently store template files in the preset template repository.
[0022] Optional message processing methods also include: If the template change listener detects a change in the template file in the preset template repository, it reads the changed template content and sends the corresponding new template ID and new template content to the preset template compilation manager. The new template ID and the corresponding Java source code are compiled using a preset template compilation manager to obtain new bytecode. Create a new class loader to load new bytecode. Send the bytecode to the new class loader via a preset template compiler manager so that the new class loader can automatically instantiate a new parser / converter instance. The new parser / converter instance is registered to the global registry through the preset template compilation manager, and the currently used instance mapping in the global registry is updated to the parser / converter instance through atomic operations.
[0023] Optionally, the target message entity is determined based on a preset transformation mapping template and the source message entity, including: Determine whether the source message entity needs to be converted to the target format based on the conversion mapping template; If so, the corresponding target converter instance is obtained from the global registry based on the conversion mapping template; The target message entity is obtained by calling the convert method of the target converter instance based on the source message entity.
[0024] Optional message processing methods also include: If the old instance and old class loader are not invoked by any thread within the target time period, the old instance and old class loader will be directly recycled and cleaned up.
[0025] Optionally, the target message entity can be encoded by calling the encoding method through the text parser instance, and the corresponding encoded data can be output, including: The payload byte array is obtained by calling the encoding method based on the target message entity through the text parser instance; The encoding method corresponding to the frame parser instance writes the start flag, length, and check information into the payload byte array to obtain the encoded data.
[0026] Secondly, the present invention discloses a message processing apparatus, comprising: The frame parser instance determination module is used to determine the frame structure template ID corresponding to the message to be processed based on the characteristics of the message to be processed, and to determine the frame parser instance corresponding to the frame structure template ID based on a pre-built global registry; the global registry is a table used to store the mapping relationship between template IDs and parser / converter instances; The text parser instance determination module is used to extract the message ID by calling the parse method of the frame parser instance, determine the preset text format template corresponding to the message ID, and determine the text parser instance corresponding to the preset text format template based on the preset global registry. The target message entity determination module is used to obtain the corresponding source message entity by calling the parse method of the text parser instance, and determine the target message entity based on the preset transformation mapping template and the source message entity. The encoding module is used to encode the target message entity by calling the encoding method through the text parser instance, and output the corresponding encoded data to complete message processing.
[0027] Thirdly, the present invention discloses an electronic device, comprising: Memory, used to store computer programs; A processor is used to execute computer programs to implement the steps of the message processing method described above.
[0028] Fourthly, the present invention discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned message processing method.
[0029] This invention determines the frame structure template ID corresponding to the message to be processed based on the characteristics of the message to be processed, and determines the frame parser instance corresponding to the frame structure template ID based on a pre-built global registry. The global registry is a table used to store the mapping relationship between template IDs and parser / converter instances. The message ID is extracted by calling the parse method of the frame parser instance, and the preset text format template corresponding to the message ID is determined. The text parser instance corresponding to the preset text format template is determined based on the preset global registry. The corresponding source message entity is obtained by calling the parse method of the text parser instance, and the target message entity is determined based on the preset conversion mapping template and the source message entity. The target message entity is encoded by calling the encoding method of the text parser instance, and the corresponding encoded data is output to complete the message processing.
[0030] Beneficial effects: As can be seen, this invention declaratively defines the message frame structure, text format, and conversion rules between formats using templates. The system dynamically compiles these templates into standard bytecode at runtime. This achieves zero-reflection calls for the parsing and conversion of each message, completely eliminating the interpretation and reflection overhead in the message processing hot path of traditional configuration schemes. Attached Figure Description
[0031] To more clearly illustrate the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0032] Figure 1 A flowchart of a message processing method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a message processing system structure provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a message processing device structure provided in an embodiment of the present invention; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.
[0034] The terms "comprising" and "having," and any variations thereof, in the specification and accompanying drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.
[0035] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0036] In some technologies, a custom configuration file, similar to JSON or XML, describes the protocol's frame header, field sequence, length, type, etc. The system reads this configuration file at startup, dynamically constructs the internal data structure using Java reflection, and parses the data field by field according to the configuration upon receiving it. The drawback of this technology is: (1) Severe performance issues: Existing solutions require multiple accesses and settings of fields via reflection APIs (such as Field.set() and Method.invoke()) when parsing each message. Each reflection operation involves significant overhead such as method lookup, access permission checks, and parameter wrapping / unwrapping, and is difficult to optimize by JIT (Just-In-Time) compilers. Its performance is typically 1-2 orders of magnitude lower than direct method calls.
[0037] (2) Lack of efficient conversion mechanism: Usually only the "parsing" problem is solved, converting binary or text streams into internal objects. However, the "conversion" (i.e., mapping from one internal object to an object of another protocol format) lacks the same flexible and efficient templated description support, and the conversion logic still needs to be hard-coded.
[0038] (3) Weak dynamic update capability: After the configuration file is updated, the application usually needs to be restarted or the module needs to be reloaded for it to take effect, making it difficult to achieve "hot activation" without the business being aware of it.
[0039] (4) Description capabilities need to be strengthened: The description of complex conditional logic and dependencies such as "whether to parse field B is determined by the value of field A" and "the length of field C is dynamically determined by the value of field D" is not intuitive or powerful enough.
[0040] (5) Missing code generation: There is no step to compile high-level descriptions (templates) into high-performance executable code, which makes it impossible to balance flexibility and performance.
[0041] In summary, these technologies either sacrifice flexibility (hard-coding) or performance (interpreted execution + reflection), and generally have shortcomings in message conversion and dynamic updates. To address these technical problems, this invention discloses a message processing method, apparatus, device, and medium that can achieve zero-reflection invocation for parsing and converting each message, providing powerful descriptive capabilities and supporting flexible and efficient message conversion.
[0042] See Figure 1 As shown, an embodiment of the present invention provides a message processing method, including: Step S11: Determine the frame structure template ID corresponding to the message to be processed based on the characteristics of the message to be processed, and determine the frame parser instance corresponding to the frame structure template ID based on the pre-built global registry; the global registry is a table used to store the mapping relationship between template IDs and parser / converter instances.
[0043] In this embodiment of the invention, before determining the frame parser instance value corresponding to the frame structure template ID based on the pre-built global registry, the template file is first read when the existence of the template file in the target directory is detected by the change listener, and a target notification is sent to the preset template compilation manager. The template file is a JSON file pre-created by the operations and maintenance personnel. The template file includes a frame structure template for describing the message header, a body format template for describing the message body, a conversion rule template for describing the mapping rules between message formats, and a conversion mapping template for describing the message ID that needs to be converted. The preset template compilation manager reads each field in the template file based on the target notification and generates Java source code based on the corresponding fields. The preset compiler is called to compile the Java source code into bytecode. A target class loader for loading bytecode is created, and the bytecode is sent to the target class loader through the preset template compilation manager so that the target class loader can automatically instantiate the parser / converter instance. The parser / converter instance and the template ID corresponding to the parser / converter instance are registered to the global registry through the preset template compilation manager to complete the construction of the global registry.
[0044] Specifically, operations and maintenance personnel place the written JSON templates in a specific directory: Frame structure templates (describing how the message header is split, supporting frame-level characteristics such as byte order, validation algorithms, length fields, and message identifiers); Body format templates (describing the position, type, and length of each field in the message body, supporting complex data structures such as variable-length fields, conditional field groups, and repeating field groups); Conversion rule templates (describing how fields are mapped and calculated, supporting conversion logic such as direct mapping, expression evaluation, and conditional branching); and Conversion mapping templates (describing which message IDs need to be converted, managing the routing relationship for message format conversion, supporting one-to-many and many-to-one mappings). The data structures of these four types of JSON templates and their interrelationship mechanisms, especially the use of fields such as role, condition, lengthRef, and countRef to implement declarative descriptions of complex protocol structures (variable-length, conditional, repeating, and nested), are all used. The "change listener" in the template management service detects template files in the directory, reads all template content, and notifies the dynamic compilation service. The "template code generator" in the dynamic compilation service begins its work: it reads each field of the JSON template. For a field like "speed," it thinks: this is a UINT16 type, so it needs to read two bytes starting from the second position of the byte array and then multiply by 0.1. It then concatenates these "ideas" directly into a Java source code string. Simultaneously, it generates a "registration class," which contains a static block (a piece of code that executes automatically when the class is first used) that says, "Create a new parser instance and add it to the global registry." The code generator then hands the Java source code to the standard Java compiler. The compiler outputs .class bytecode files. The dynamic compilation service creates a brand new "HotSwapClassLoader." This class loader is specifically designed to load these newly generated .class files. It doesn't look for classes already in the system; instead, it prioritizes using its own. When the class loader loads the "registered class," its static block executes automatically. This static block contains only one line: `new some resolver instance()`. Once this instance is created, the global registry's `register` method is immediately called to store the mapping from "template ID to this instance." The entire process involves no reflection calls (because `new` and `register` are known at compile time). Now, all the resolver and converter instances corresponding to templates in the system are stored in the global registry and can be accessed at any time.
[0045] In this embodiment of the invention, upon receiving a message to be processed, the corresponding frame structure template ID is found based on the message's characteristics (e.g., the first two bytes are AA55). Then, the frame parser instance is retrieved from the global registry using this ID. In other words, the frame parser instance corresponding to the frame structure template ID is determined based on a pre-built global registry.
[0046] In addition, this invention persistently stores template files in a preset template repository. The template repository persistently stores four types of JSON templates (frame structure, text format, conversion rules, and conversion mapping), providing a definition source for dynamic compilation.
[0047] If the template change listener detects a change in a template file in the preset template repository, it reads the changed template content and sends the corresponding new template ID and new template content to the preset template compilation manager. The preset template compilation manager then compiles the Java source code corresponding to the new template ID and new template content to obtain new bytecode. A new class loader is created to load the new bytecode, and the preset template compilation manager sends the bytecode to the new class loader so that the new class loader automatically instantiates a new parser / converter instance. The preset template compilation manager registers the new parser / converter instance to the global registry, and an atomic operation updates the currently used instance mapping in the global registry to the parser / converter instance.
[0048] Step S12: Extract the message ID by calling the parse method of the frame parser instance, determine the preset text format template corresponding to the message ID, and determine the text parser instance corresponding to the preset text format template based on the preset global registry.
[0049] In this embodiment of the invention, after obtaining the frame parser instance, its `parse` method is directly called (via an interface call, not reflection). This method involves hard-coded byte operations: reading the start flag, reading the length field, reading the message ID and checksum. After execution, it returns a "frame information object" containing the message ID and the start position of the payload. Based on the message ID (e.g., 0x1001) in the frame information, the system finds the corresponding text format template ID and then retrieves the text parser instance from the global registry.
[0050] Step S13: Obtain the corresponding source message entity by calling the parse method of the text parser instance, and determine the target message entity based on the preset transformation mapping template and the source message entity.
[0051] In this embodiment of the invention, the `parse` method of the text parser is directly called, passing in the original byte array and offset. Zero-reflection is used to call `MessageParser.parse` to generate the source message entity. The template supports complex structures such as variable length, conditional, and repetitive structures, and the generated code directly implements efficient byte operations. In one specific embodiment, 7 bytes are read and converted to a string (vehicleId), 2 bytes are read and converted to an integer and multiplied by 0.1 (speed), 1 byte is read to determine if there is extended information (conditional field), if the condition is true, the extended field is read, 1 byte is read to obtain the number of obstacles, and then this process is repeated to read all sets of obstacle data, finally returning a complete message entity object (with all fields filled in). The final result is the source message entity.
[0052] In this embodiment of the invention, the source message entity needs to be converted to the target format based on the conversion mapping template. If so, the corresponding target converter instance is obtained from the global registry based on the conversion mapping template. The convert method of the target converter instance is called based on the source message entity to obtain the target message entity. The conversion mapping template is queried to determine if conversion to the target format is required. If conversion is required, the corresponding converter instance is obtained (from the global registry), and MessageConverter.convert is called to complete the mapping, calculation, conditional branching, and other logic to generate the target message entity. In one specific embodiment, the conversion mapping template is queried to see if the message 0x1001 needs to be converted to another format. If so, the converter instance is obtained from the global registry according to the conversion rule template ID specified in the mapping. Then, the convert method of the converter is directly called, passing in the source message entity obtained in the previous step. In one specific embodiment, direct mapping: target.licensePlate=source.vehicleId, expression calculation: target.speedKph=source.speed 0.1 Conditional Branch: Based on the speed value, different if-else statements are executed to set different traffic status strings, and finally the target message entity is returned.
[0053] Step S14: Encode the target message entity by calling the encoding method through the text parser instance, and output the corresponding encoded data to complete message processing.
[0054] In this embodiment of the invention, when a target message entity needs to be sent to a target system, a corresponding parser instance (within the same instance) is obtained through a factory. The MessageParser.encode method is called to encode the message entity into binary data, and frame header padding, checksum calculation, and other operations are performed according to the frame structure template to output a complete binary data packet. This invention uses a text parser instance to call an encoding method based on the target message entity to obtain a payload byte array; based on the encoding method corresponding to the frame parser instance, a start flag, length, and checksum information are written into the payload byte array to obtain the encoded data.
[0055] Additionally, if the old instance and old class loader are not invoked by any thread within the target time period, the old instance and old class loader will be directly recycled and cleaned up.
[0056] Beneficial effects: As can be seen, this invention declaratively defines the message frame structure, text format, and conversion rules between formats using templates. The system dynamically compiles these templates into standard bytecode at runtime. This achieves zero-reflection calls for the parsing and conversion of each message, completely eliminating the interpretation and reflection overhead in the message processing hot path of traditional configuration schemes.
[0057] As can be seen from the previous embodiment, the core innovation of this invention lies in dynamically compiling declarative templates into high-performance executable code at runtime, and completely eliminating reflection overhead on the message processing hot path through the design of "predefined interface contract + dynamically generated factory code". Specific implementation includes: Convert the JSON template into Java source code that implements a predefined interface, and compile it into bytecode using the Java compiler API; When the system starts or the template is updated, the newly generated classes are dynamically compiled and loaded, including the implementation classes of the parser / converter and their corresponding factory registration classes (such as TemplateFactory_BF_V2X_BSM). When the factory registration class is loaded, its static block executes automatically, instantiating the resolver / converter and registering it with the template execution engine's global registry. This process is completed during class loading and executes only once. When a message needs to be parsed or transformed, the application layer calls the parser / converter factory in the template execution engine. The factory obtains an instance through the global registry (a simple Map.get operation). After obtaining an instance of the MessageParser or MessageConverter interface, the application layer directly calls its parse(), encode(), or convert() methods to actually execute the dynamically generated hard-coded logic.
[0058] Throughout the process, reflection operations are restricted to the cold path of template loading and updating (static block execution during class loading), while reflection calls are completely eliminated in the hot path of message processing (parsing, encoding, and conversion of each message), thus achieving near-hard-coded execution performance.
[0059] Next, we will describe the process principle of achieving zero reflection by combining the complete processing flow from the raw byte stream to the final delivery of the message entity, including the three core stages of decoding, conversion, and encoding.
[0060] Frame decoding phase: Select the corresponding frame structure template based on message characteristics (such as start flags). If the frame parser is not loaded, the dynamic compilation service generates and registers it based on the frame structure template. Subsequently, the application layer obtains a frame parser instance (from the global registry) through the parser / converter factory, completes frame header decoding, verifies length and checksum, and extracts message ID through predefined interface calls.
[0061] In the message decoding stage: the message format template is looked up based on the message ID. Similarly, a message parser instance is obtained through a factory, and MessageParser.parse is called with zero reflection to generate the source message entity. The template supports complex structures such as variable length, conditional, and repetitive structures, and the generated code directly implements efficient byte operations.
[0062] Conversion Phase: Query the conversion mapping template to determine if conversion to the target format is necessary. If conversion is required, obtain the corresponding converter instance (from the global registry), call MessageConverter.convert to complete mapping, calculation, conditional branching, and other logic, and generate the target message entity.
[0063] Encoding stage: When it is necessary to send the target message entity to the target system, the corresponding parser instance (same instance) is obtained through the factory, the MessageParser.encode method is called to encode the message entity into binary data, and the frame header filling, checksum calculation and other operations are completed according to the frame structure template to output a complete binary data packet.
[0064] This restricts reflection operations to the cold path of template loading and updating, while completely eliminating reflection on the hot path of each message processing, achieving a completely reflection-free call.
[0065] Furthermore, this invention enables hot template activation without restarting the service, and supports dynamic updates of protocols and conversion rules without restarting the service. Specifically, it includes: Template change detection: The template change listener in the template management service monitors changes to template files in the template repository. Upon detecting a change, it reads the latest template content and passes the template ID and content to the template compilation manager in the dynamic compilation service.
[0066] Incremental compilation: The template compilation manager only initiates compilation requests for the changed templates, calls the template code generator to generate Java source code, and then compiles it into bytecode by the Java compiler.
[0067] Isolated loading: Use the new HotSwapClassLoader in the dynamic compilation service to load newly generated classes, avoiding conflicts with older versions.
[0068] Automatic registration: When a new factory class is loaded, its static block executes, automatically registering the new parser and converter instances to the template execution engine's global registry and overwriting the old mappings.
[0069] Atomic Switching: After the new instance is registered, the template compilation manager sends the new instance reference and corresponding template ID to the global registry. The global registry then updates the currently used instance mapping to the new instance through atomic operations (such as AtomicReference), ensuring that subsequent message processing immediately uses the new logic. Old requests that are currently being processed are unaffected (they still hold references to the old instance).
[0070] In this way, the present invention achieves seamless hot activation without the business being aware of it by isolating compilation and atomic switching, while avoiding version conflicts and memory leaks. Old class loaders and old instances that are no longer referenced are automatically reclaimed by GC (Garbage Collection) after they are no longer referenced, without blocking message processing.
[0071] The specific architecture of the message processing system of this invention is as follows: Figure 2 As shown, in the application layer, business systems call the template execution engine through a unified API, without needing to worry about underlying protocol differences. After obtaining instance references from the parser / converter factory, the application layer directly calls instance methods through predefined interfaces, achieving zero reflection in hot paths.
[0072] Template execution engine: The core execution module of the message processing hot path, responsible for managing compiled instances and providing zero-reflection invocation capabilities. Internally includes: Global Registry: Maintains the mapping relationship between template IDs and parser / converter instances, supports O(1) time complexity to obtain instances, and supports atomic update of instance references (for hot switching).
[0073] Parser / Converter Factory: The application layer call entry point, which retrieves a compiled instance from the global registry based on the message type and returns it.
[0074] Parser / Converter Instances: Dynamically generated concrete implementation class instances that implement the predefined MessageParser or MessageConverter interfaces. Each instance is automatically created and registered in the global registry via a static block when the factory class is loaded, without any reflection.
[0075] Old instance and old ClassLoader: The old version instance and its associated class loader that are replaced during the hot swapping process are no longer referenced and are waiting for GC to reclaim.
[0076] Dynamic compilation service: The core compilation engine, responsible for dynamically compiling JSON templates into high-performance executable code and coordinating the entire compilation and hot-swapping process. Internally includes: Template code generator: This module parses and concatenates JSON templates to generate complete Java source code (including parser / converter implementation classes and corresponding factory registration classes). It compiles field definitions, type mappings, conditional logic, loop structures, etc., in the template into direct and efficient bytecode manipulation code.
[0077] Java compiler: Invokes a standard Java compiler (such as Javac) to compile the generated source code into bytecode (.class files).
[0078] Template Compiler Manager: Coordinates the compilation process, manages the class loader lifecycle, and triggers hot switching. Specific responsibilities include: receiving template change notifications, invoking the template code generator and Java compiler, passing bytecode to HotSwapClassLoader, and notifying the global registry to atomically switch instance references.
[0079] HotSwapClassLoader: A custom class loader used to isolate the loading of newly generated bytecode. Each new version uses an independent class loader instance, breaking the parent delegation model, prioritizing the loading of new bytecode, avoiding conflicts with older versions, and supporting the garbage collection of older versions.
[0080] Template Management Service: Responsible for persistent storage, version management, change detection, and notification of JSON templates. Internally includes: Template repository: Persistently stores four types of JSON templates (frame structure, body format, conversion rules, and conversion mapping), providing a definition source for dynamic compilation.
[0081] Template Change Listener: Continuously monitors changes to template files in the template repository. Once a change is detected, it immediately reads the latest template content and passes the template ID and content to the dynamic compilation service, triggering the incremental compilation and hot-apply process.
[0082] The key interaction flow between the above modules is as follows: Template change trigger: The template change listener detects a template change in the template repository, reads the latest template content, and passes the template ID and content to the template compilation manager.
[0083] Dynamic compilation: The template compilation manager calls the template code generator to generate Java source code, which is then compiled into bytecode by the Java compiler.
[0084] Isolation loading and automatic registration: The template compiler manager passes bytecode to the HotSwapClassLoader to load the factory class. The static block of the factory class automatically instantiates the resolver / converter instance and registers it to the global registry.
[0085] Atomic Switching: After the new instance is registered, the template compilation manager sends the new instance reference and corresponding template ID to the global registry. The global registry then updates the mapping of the currently used instance to the new instance through atomic operations, ensuring that subsequent message processing immediately uses the new instance. Old requests that are currently being processed are unaffected.
[0086] Zero-reflection invocation: The business system obtains instance references from the resolver / converter factory and directly invokes instance methods through predefined interfaces, without any reflection throughout the process.
[0087] Resource reclamation (asynchronous): Old instances and old HotSwapClassLoaders are automatically reclaimed by the GC after they are no longer referenced by any thread, without blocking message processing.
[0088] In this way, the present invention declaratively defines the message frame structure, text format, and conversion rules between formats using JSON templates. At runtime, the system dynamically compiles these templates into standard Java bytecode (.class files), supporting incremental compilation and hot reloading. Simultaneously, through innovative "predefined interface contracts" and "dynamic factory code generation" technologies, it achieves zero-reflection calls on the message processing hot path, thereby obtaining extreme performance. Dynamically generated parser / converter instances are created and registered in the global registry when the factory class is loaded, ensuring permanent reuse and avoiding the overhead of repeated instantiation.
[0089] See Figure 3 As shown, an embodiment of the present invention provides a message processing apparatus, including: The frame parser instance determination module 11 is used to determine the frame structure template ID corresponding to the message to be processed based on the characteristics of the message to be processed, and to determine the frame parser instance corresponding to the frame structure template ID based on a pre-built global registry; the global registry is a table used to store the mapping relationship between template IDs and parser / converter instances; The text parser instance determination module 12 is used to extract the message ID by calling the parse method of the frame parser instance, determine the preset text format template corresponding to the message ID, and determine the text parser instance corresponding to the preset text format template based on the preset global registry. The target message entity determination module 13 is used to obtain the corresponding source message entity by calling the parse method of the text parser instance, and determine the target message entity based on the preset transformation mapping template and the source message entity. Encoding module 14 is used to encode the target message entity by calling the encoding method through the text parser instance and output the corresponding encoded data to complete message processing.
[0090] Since the embodiments of the device part correspond to the embodiments described above, please refer to the embodiments described in the method part for the embodiments of the device part, and will not be repeated here.
[0091] Beneficial effects: As can be seen, this invention declaratively defines the message frame structure, text format, and conversion rules between formats using templates. The system dynamically compiles these templates into standard bytecode at runtime. This achieves zero-reflection calls for the parsing and conversion of each message, completely eliminating the interpretation and reflection overhead in the message processing hot path of traditional configuration schemes.
[0092] Furthermore, embodiments of this application also disclose an electronic device, Figure 4 This is a structural diagram of an electronic device according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. Specifically, the electronic device may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the message processing method disclosed in any of the foregoing embodiments. Furthermore, the electronic device in this embodiment may specifically be an electronic computer.
[0093] In this embodiment, the power supply 23 is used to provide operating voltage for various hardware devices on the electronic device; the communication interface 24 can create a data transmission channel between the electronic device and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.
[0094] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.
[0095] The operating system 221 is used to manage and control the various hardware devices on the electronic device and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the message processing method executed by the electronic device as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.
[0096] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned message processing method. The specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.
[0097] Furthermore, this application also discloses a computer program product, including a computer program / instructions; wherein, when the computer program / instructions are executed by a processor, they implement the aforementioned disclosed message processing method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.
[0098] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.
[0099] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0100] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0101] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0102] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A message processing method, characterized in that, include: The frame structure template ID corresponding to the message to be processed is determined based on the characteristics of the message to be processed, and the frame parser instance corresponding to the frame structure template ID is determined based on the pre-built global registry. The global registry is a table used to store the mapping relationship between template IDs and parser / converter instances; The message ID is extracted by calling the parse method of the frame parser instance, the preset text format template corresponding to the message ID is determined, and the text parser instance corresponding to the preset text format template is determined based on the preset global registry. The corresponding source message entity is obtained by calling the parse method of the text parser instance, and the target message entity is determined based on the preset transformation mapping template and the source message entity. The target message entity is encoded by calling the encoding method through the text parser instance, and the corresponding encoded data is output to complete the message processing.
2. The message processing method according to claim 1, characterized in that, Before determining the frame parser instance corresponding to the frame structure template ID based on the pre-built global registry, the method further includes: When the listener detects the existence of a template file in the target directory, it reads the template file and sends a target notification to the preset template compilation manager. The template file is a JSON file pre-created by the operations and maintenance personnel. The template file includes a frame structure template for describing the message header, a body format template for describing the message body, a conversion rule template for describing the mapping rules between message formats, and a conversion mapping template for describing the message ID that needs to be converted. The preset template compilation manager reads each field in the template file based on the target notification and generates Java source code based on the corresponding fields. The default compiler is invoked to compile the Java source code into bytecode. Create a target class loader for loading the bytecode, and send the bytecode to the target class loader through the preset template compiler manager so that the target class loader can automatically instantiate a parser / converter instance; The preset template compilation manager registers the parser / converter instance and the template ID corresponding to the parser / converter instance to the global registry to complete the construction of the global registry.
3. The message processing method according to claim 2, characterized in that, Also includes: The template file is persistently stored in a preset template repository.
4. The message processing method according to claim 3, characterized in that, Also includes: If the template change listener detects a change in the template file in the preset template repository, it reads the changed template content and sends the corresponding new template ID and new template content to the preset template compilation manager. The preset template compilation manager compiles the Java source code corresponding to the new template ID and the new template content to obtain new bytecode. A new class loader is created to load the new bytecode. The bytecode is sent to the new class loader via the preset template compiler manager so that the new class loader can automatically instantiate a new parser / converter instance. The new parser / converter instance is registered to the global registry through the preset template compilation manager, and the currently used instance mapping in the global registry is updated to the parser / converter instance through atomic operations.
5. The message processing method according to claim 1, characterized in that, The determination of the target message entity based on the preset transformation mapping template and the source message entity includes: Based on the transformation mapping template, determine whether the source message entity needs to be converted to the target format; If so, then obtain the corresponding target converter instance from the global registry based on the conversion mapping template; The target message entity is obtained by calling the convert method of the target converter instance based on the source message entity.
6. The message processing method according to claim 1, characterized in that, Also includes: If the old instance and old class loader are not invoked by any thread within the target time period, the old instance and old class loader will be directly recycled and cleaned up.
7. The message processing method according to any one of claims 1 to 6, characterized in that, The step of encoding the target message entity by calling the encoding method through the text parser instance and outputting the corresponding encoded data includes: The text parser instance invokes an encoding method based on the target message entity to obtain a payload byte array; The encoding method corresponding to the frame parser instance writes the start flag, length, and check information into the payload byte array to obtain the encoded data.
8. A message processing device, characterized in that, include: The frame parser instance determination module is used to determine the frame structure template ID corresponding to the message to be processed based on the characteristics of the message to be processed, and to determine the frame parser instance corresponding to the frame structure template ID based on a pre-built global registry. The global registry is a table used to store the mapping relationship between template IDs and parser / converter instances; The text parser instance determination module is used to extract the message ID by calling the parse method of the frame parser instance, determine the preset text format template corresponding to the message ID, and determine the text parser instance corresponding to the preset text format template based on the preset global registry. The target message entity determination module is used to obtain the corresponding source message entity by calling the parse method of the text parser instance, and determine the target message entity based on the preset transformation mapping template and the source message entity. The encoding module is used to encode the target message entity by calling the encoding method through the text parser instance, and output the corresponding encoded data to complete message processing.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the message processing method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the message processing method as described in any one of claims 1 to 7.