Data communication protocol system, construction method thereof and distributed context awareness system

Abstract

The invention discloses a data communication protocol system, a construction method thereof and a distributed context awareness system. According to the data communication protocol system, the data communication protocol system is applied to a distributed system, the data communication protocol system stores standardized data of a communication context, and the standardized data and service data are bound and synchronously transmitted among all components of the distributed system together. The data communication protocol system comprises: an identity metadata layer, which is used for determining the semantic identity of service data in a distributed system; the control metadata layer is used for defining a life cycle and a processing rule of the service data in the distributed system; the security situation metadata layer is used for determining security policies and compliance requirements related to service data; and the observation metadata layer is used for providing link tracking and associated information of the service data in the distributed system. According to the technical scheme, the safety, the compliance and the observability in the distributed system can be effectively improved, and effective cooperative operation of the distributed system is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of computer technology, specifically to a data communication protocol system and its construction method, and a distributed context-aware system. Background Technology

[0002] In distributed system communication scenarios, business data transmission often focuses solely on the transmission of the data itself. Key context related to the business data is either scattered across different system modules, unable to flow synchronously with the business data, or transmitted through non-standardized additional methods, resulting in chaotic formats and poor compatibility, making unified parsing and utilization across components and scenarios difficult. This often leads to problems in distributed systems such as unclear business data sources, inconsistent processing rules, inadequate security policy enforcement, and broken tracing links, severely impacting the security, compliance, and observability of system communication, and hindering the collaborative operation of distributed systems. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a data communication protocol system that can effectively improve security, compliance, and observability in distributed systems, ensuring the effective collaborative operation of distributed systems.

[0004] This application provides a data communication protocol system applied to a distributed system. The system stores standardized data of the communication context, which is bound to business data and synchronously transmitted among the components of the distributed system. The data communication protocol system includes:

[0005] The identity metadata layer is used to define the semantic identity of the business data in the distributed system;

[0006] The control metadata layer is used to define the lifecycle and processing rules of the business data in the distributed system;

[0007] The security posture metadata layer is used to determine the security policies and compliance requirements related to the business data.

[0008] The observable metadata layer is used to provide link tracing and correlation information of the business data in the distributed system.

[0009] In one aspect, the identity metadata includes at least a globally unique identifier, message type, publisher identity information, and target receiving address;

[0010] The control metadata layer includes at least message priority, valid lifetime, and processing deadline.

[0011] The security situation metadata layer includes at least data classification labels, data processing instructions, and data traceability information;

[0012] The observable metadata layer includes at least a distributed tracking identifier and a precise timestamp.

[0013] In one aspect, the standardized data is represented in a serialized form based on a preset structured format.

[0014] Furthermore, to address the aforementioned problems, this application also provides a method for constructing a data communication protocol, the method comprising:

[0015] When the distributed system sends business data, it triggers a protocol generation command;

[0016] According to the generation instructions, combined with the predefined policy template and the business context corresponding to the business data, data is loaded into the identity metadata layer, control metadata layer, security status metadata layer and observation metadata layer of the data communication protocol system as described above, to form a data communication protocol.

[0017] In one aspect, the step of loading data into the identity metadata layer includes:

[0018] Based on preset identifier generation rules, a globally unique identifier is generated and filled into the globally unique identifier field of the identity metadata layer;

[0019] Based on the business operation attributes corresponding to the business data, a preset message type classification standard is matched to determine the message type, and the message type is filled into the corresponding message class field;

[0020] Extract the service name, service version number, and instance identifier from the service instance configuration information that sends business data, and combine them to form publisher identity information. Fill the publisher identity information into the corresponding identity field.

[0021] Based on the message receiving object in the business process, the target receiving address is parsed and filled into the target receiving address field. The target receiving address includes at least one of the following: service name, message bus topic name, or service instance network address.

[0022] In one aspect, the step of loading data into the control metadata layer includes:

[0023] Based on the business importance and processing priority corresponding to the business data, a preset priority classification standard is matched to determine the message priority, and the message priority is filled into the message classification field.

[0024] Based on the effective processing cycle of the business data, the system data flow efficiency, and the storage resource constraints, the effective lifetime is determined and filled into the effective lifetime field.

[0025] Based on the response time limit and processing requirements of the service level agreement for the business data, calculate the processing deadline for the business data and fill the processing deadline into the processing deadline field.

[0026] In one aspect, the step of loading data into the security posture metadata layer includes:

[0027] Analyze the content sensitivity attributes, data usage, and associated compliance requirements of the business data, match them with preset data classification standards, generate corresponding data classification tags, and fill the data classification tags into the corresponding fields;

[0028] Based on the security control policy corresponding to the data classification label, determine the data processing instruction and fill the data processing instruction into the corresponding field. The data processing instruction includes encryption requirement identifier, encryption algorithm type, integrity protection algorithm type, list of permitted uses and list of geographical scope restrictions.

[0029] Record the source information of the business data, the initial processing node and the preset flow path to form complete data traceability information, and fill the data traceability information into the corresponding fields;

[0030] Based on the compliance audit requirements corresponding to the business scenario, determine whether the audit needs to be tampered with, set the corresponding audit identifier, and fill the audit identifier into the field.

[0031] In one aspect, the step of loading data into the security posture metadata layer further includes:

[0032] Based on the real-time flow status of the aforementioned business data, dynamically adjust data processing instructions:

[0033] If the business data is detected to be transmitted from a domestic node to an overseas node, and the geographical restriction list prohibits cross-border transmission, the encryption algorithm type will be automatically upgraded to an asymmetric encryption algorithm, and the blockchain audit layer will be triggered to record cross-border transmission alarms and encryption change logs in real time.

[0034] If the receiver's permission level is lower than the preset threshold, a permission verification pre-signal will be added to the data processing instruction, requiring the receiver to complete a second permission verification in order to decrypt the data.

[0035] If the network transmission environment has a low security level, a dual encryption mechanism will be automatically enabled, and the effective data lifespan will be shortened to half of the original duration.

[0036] The differences between the adjusted data processing instructions and the original instructions are synchronously written into the data traceability information field.

[0037] In one aspect, the step of loading data into the observable metadata layer includes:

[0038] Extract existing distributed tracing identifiers from the context information of the current execution link in the distributed system. If there are no tracing identifiers in the previous execution link, automatically create tracing identifiers according to the preset tracing identifier generation rules and fill the created tracing identifiers into the distributed tracing identifier field.

[0039] Identify the preceding associated business link corresponding to the business data, obtain the association identifier of the business link and reuse it; if there is no reusable association identifier, generate a new global association identifier and fill the association identifier field with the global association identifier.

[0040] Based on the moment when the data communication protocol was first established, a timestamp accurate to the millisecond level is recorded, and the timestamp is filled into the precise timestamp field.

[0041] In one aspect, the predefined strategy template is loaded when business data is started, and the strategy template predefines the required fields, default values ​​and field filling rules for each metadata layer;

[0042] The business context corresponding to the business data includes the business data type, business operation priority, service instance identifier, and the current execution chain information of the system.

[0043] Furthermore, to address the aforementioned problems, this application also provides a distributed context-aware system, the context-aware system comprising:

[0044] A communication unit, comprising a data communication protocol system as described above, and the communication unit being associated with a message bus subscription;

[0045] A monitoring and analysis module is associated with the communication unit. The monitoring and analysis module extracts feature information from the data communication protocol system and performs real-time analysis.

[0046] The response execution module is used to receive the analysis results from the monitoring and analysis module, and trigger hierarchical response actions based on the analysis results. The hierarchical response actions include generating alarm information, performing rate limiting, and implementing service isolation.

[0047] In one aspect, the context-aware system further includes:

[0048] The blockchain audit layer is used to set up a time-series blockchain and store key information hashes and audit-related data of a data communication protocol system that meets preset conditions.

[0049] In one aspect, the time-series blockchain is based on a preset proof-of-stake algorithm and stores audit data in shards according to the time dimension;

[0050] Alternatively, all nodes of the time-series blockchain may deploy a time synchronization module, which periodically obtains world time from an authoritative time source and calibrates the local clock of the nodes based on that time.

[0051] In one aspect, the feature information includes service identifier, message type, priority, data classification label, and time sequence information;

[0052] The business data is encrypted according to the security status metadata layer of the data communication protocol system.

[0053] In one aspect, the context-aware system further includes:

[0054] The rule management module is used to maintain the rule system, which includes data compliance rules, access control rules, behavior anomaly rules, and security posture rules. Among them, the data compliance rules are used to check the compliance of data classification and labeling, encryption requirements, and geographical restrictions, and the behavior anomaly rules are used to detect deviations from message frequency, data volume change trends, and historical benchmarks.

[0055] The beneficial effects of this invention are as follows: First, by constructing a communication protocol system that stores standardized data of communication context and transmits it synchronously with business data, and setting up four metadata layers—identity, control, security posture, and observation—the problem of scattered storage or non-standardized transmission of communication context in distributed systems is reduced. The four metadata layers integrate key contexts such as semantic identity, lifecycle rules, security compliance requirements, and link tracing information of business data into standardized data, which flows synchronously with business data, avoiding misunderstandings caused by missing context or chaotic formats among components of the distributed system, and ensuring unified understanding of business data across the entire link. Second, the security posture metadata layer clarifies the security policies and compliance requirements of business data, providing targeted security control basis for business data throughout the transmission process, avoiding risks caused by missing security rules. At the same time, the identity metadata layer clarifies the data source and target, providing a basis for accountability. The observation metadata layer provides link tracing and correlation information, facilitating real-time location of business data flow nodes and troubleshooting of transmission problems by operation and maintenance personnel. Controlling the lifecycle and processing rules defined by the metadata layer ensures that business data is processed efficiently as expected, avoiding waste of system resources or business delays caused by disordered processing, and achieving efficient collaborative, secure, and compliant communication among components of the distributed system. Attached Figure Description

[0056] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0057] Figure 1 This is a schematic diagram of the functional structure of the data communication protocol system in this application;

[0058] Figure 2 This is a schematic diagram illustrating the process steps for constructing the data communication protocol in this application;

[0059] Figure 3 This is a schematic diagram of the functional structure of the context-aware system in this application. Detailed Implementation

[0060] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. These embodiments are merely illustrative of the technical solution of the present invention and are therefore intended to limit the scope of protection of the present invention.

[0061] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application should have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0062] like Figure 1 As shown, this application provides a data communication protocol system 10, which is applied to a distributed system. The data communication protocol system 10 stores standardized data of the communication context. This standardized data is bound to business data and is synchronously transmitted among the components of the distributed system. Business data is the data carrier in the distributed system that carries specific business information. The data communication protocol system 10 includes: an identity metadata layer 110, a control metadata layer 120, a security status metadata layer 130, and an observation metadata layer 140. The data communication protocol system 10 of this application is adapted to a distributed system. A distributed system can be understood as a collaborative working system formed by multiple geographically dispersed or logically independent computing nodes connected through a network. Although these nodes each have independent hardware resources and operating systems, they can work collaboratively through the data communication protocol system 10 of this application, presenting a logically complete and functionally unified system.

[0063] The identity metadata layer 110 is used to clarify the semantic identity of business data in the distributed system. The identity metadata layer 110 is used in the data communication protocol system 10 to define the rights and responsibilities of business data, so that business data has a clear and unique semantic identity in the multi-component interaction of the distributed system, avoiding interaction confusion caused by unclear data source and ambiguous target.

[0064] Specifically, in a distributed system, business data needs to flow between different service instances, message buses, and processing nodes. The identity metadata layer 110 defines the core semantic attributes of business data through standardized fields to avoid confusion with other data. All aspects of the distributed system form a unified understanding of the identity information of business data, laying the foundation for subsequent processing rule execution and security verification.

[0065] The control metadata layer 120 is used to define the lifecycle and processing rules of business data in the distributed system. The control metadata layer 120 sets the full lifecycle operation rules for business data, avoiding waste of system resources or business delays caused by disordered processing or timeouts. In a distributed system, the entire process of business data from generation, transmission, processing to failure must follow specific rules to achieve controllable and efficient flow of business data within the distributed system.

[0066] The security posture metadata layer 130 is used to determine the security policies and compliance requirements related to business data; it is also used for the secure transmission and compliant processing of business data in the distributed system. It transforms the security management requirements of business data into standardized policies, ensuring that security rules flow synchronously with business data, avoiding the blind spots caused by the separation of security policies and data in traditional architectures. This allows business data to have its own built-in security policies and be fully compliant and controllable throughout the distributed system.

[0067] The observable metadata layer 140 provides link tracing and correlation information for business data in a distributed system. It enables the traceability and analyzability of business data within the distributed system. The observable metadata layer 140 assigns a full-link observable identifier to business data, resolving the issues of fragmented link tracing data and business data, and low efficiency in problem localization in traditional distributed systems. In multi-service collaboration scenarios within a distributed system, business data needs to flow across multiple service instances. The observable metadata layer 140 constructs a full-link observation system for business data. Operations personnel can quickly locate abnormal nodes in the business link and reconstruct the business flow process without parsing the business data itself, significantly improving the efficiency of fault diagnosis and the convenience of operation and maintenance in distributed systems.

[0068] In this embodiment, a communication protocol system is constructed that stores standardized data of communication context and transmits it synchronously with business data. Four metadata layers—identity, control, security posture, and observation—are set up to reduce the problem of scattered storage or non-standardized transmission of communication context in distributed systems. These four metadata layers integrate key contexts such as semantic identity, lifecycle rules, security compliance requirements, and link tracing information of business data into standardized data, which flows synchronously with the business data. This avoids misunderstandings caused by missing context or inconsistent formats among components of the distributed system, ensuring a unified understanding of business data across the entire chain. Secondly, the security posture metadata layer 130... Clearly define security policies and compliance requirements for business data, providing targeted security control for business data throughout the entire transmission process to avoid risks caused by missing security rules. Meanwhile, the identity metadata layer 110 clarifies the data source and target, providing a basis for accountability. The observation metadata layer 140 provides link tracing and correlation information, facilitating real-time location of business data flow nodes and troubleshooting of transmission problems by operations and maintenance personnel. Controlling the lifecycle and processing rules defined by the metadata layer 120 ensures that business data is processed efficiently as expected, avoiding waste of system resources or business delays caused by disordered processing, and achieving efficient, secure, and compliant communication between components of the distributed system.

[0069] In one embodiment of this application, the identity metadata includes at least a globally unique identifier, message type, publisher identity information, and target receiving address; the globally unique identifier, message type, publisher identity information, and target receiving address of the identity metadata layer 110 ensure that business data is identifiable, traceable, and targeted in the distributed system.

[0070] Globally unique identifiers can be generated using standardized generation rules. They serve as digital identity cards for business data throughout the system, uniquely distinguishing each piece of business data. Even order data with the same content can avoid confusion through different globally unique identifiers.

[0071] The message type can be matched with a preset classification standard based on the business operation attributes. For example, order creation corresponds to the event class, payment instruction corresponds to the command class, and inventory query corresponds to the query class. The receiving end can quickly determine the interaction intent of the business data through this field and directly call the corresponding processing logic without parsing the complete business data.

[0072] The publisher identity information is extracted from the service instance configuration that sends the business data, and is composed of the service name, service version number, and instance identifier. It clearly marks the source of the data generation. When business data is abnormal, such as format errors or content violations, this field can be used to accurately locate the specific service instance and achieve accountability.

[0073] The target receiving address is generated by parsing the preset receiving object in the business process. The format includes the service name, message bus topic name or service instance network address, ensuring that business data can be accurately routed to the target component and avoiding data flow errors caused by ambiguous addresses.

[0074] The control metadata layer 120 includes at least message priority, valid lifetime, and processing deadline; the message priority, valid lifetime, and processing deadline of the control metadata layer 120 are the main rules to ensure that business data is processed in an orderly manner and resources are controllable in a distributed system.

[0075] Message priority can be matched with preset hierarchical standards based on the importance of business data. Resources can be scheduled based on this field, with high-priority data entering the processing queue first to avoid being blocked by low-priority data and ensure the real-time performance of core business.

[0076] The effective lifespan can be set by combining the effective processing cycle of business data, system data flow efficiency, and storage resource limitations. If business data is not received or processed within this time, the system will automatically discard it. For example, order data that has not been paid within the time limit does not need to be retained after the effective lifespan expires, which can release storage and transmission resources and avoid the accumulation of invalid data.

[0077] The processing deadline is calculated based on the response time limit agreed upon in the business service level agreement and the dependencies of subsequent business processes. It specifies the latest time node when business data needs to be processed. If the data is not processed within this time, an alarm can be triggered or an automatic retry can be performed to prevent business process interruption due to processing delays.

[0078] The security status metadata layer 130 includes at least data classification labels, data processing instructions, and data traceability information; the data classification labels, data processing instructions, and data traceability information of the security status metadata layer 130 ensure the secure transmission, compliant processing, and full traceability of business data.

[0079] Data classification tags are generated by analyzing the content sensitivity attributes, data usage, and associated compliance requirements of business data and matching them with preset classification standards. These preset classification standards include financial sensitive data, personal privacy data, and general business data, providing a basis for subsequent differentiated security management. For example, financial sensitive data requires high-strength encryption, while general business data can adopt basic protection strategies.

[0080] Data processing instructions are generated based on the security control policies corresponding to the data classification tags, clarifying the security processing requirements for business data, including whether encryption is required, what encryption algorithm to use, integrity protection algorithm, permitted use scenarios, and geographical restrictions, to ensure that business data complies with security rules during transmission and processing, and to avoid unauthorized use or illegal transmission.

[0081] The data traceability information fully records the source of business data generation, initial processing nodes, and preset flow paths, forming a traceability chain throughout the entire lifecycle. In the event of security incidents such as data leakage or content tampering, the data flow trajectory can be traced back through this field to locate the link where the problem occurred, while also meeting the industry's compliance audit requirements for data traceability.

[0082] The observable metadata layer 140 includes at least a distributed trace identifier and a precise timestamp. The distributed trace identifier and precise timestamp of the observable metadata layer 140 enable business data to be traceable and problems to be investigated within the distributed system.

[0083] Distributed tracing identifiers are extracted from the context information of the current execution chain of the system. They are the main tracing thread that runs through the entire business data chain. In multi-service collaboration scenarios, all links of the same business process use the same distributed tracing identifier. Operation and maintenance personnel can use this identifier to connect the processing logs of each service, quickly reconstruct the flow path of business data, and locate the delay nodes in the chain.

[0084] The precise timestamp is based on the moment when the data communication protocol system 10 corresponding to the business data begins to be built. It records time information accurate to the millisecond level, covering the time of key nodes such as data generation, transmission to various services, and completion of processing. The processing time of each link can be calculated through the timestamp, the performance bottleneck in the link can be analyzed, and an accurate time basis can be provided for the time series analysis of business data.

[0085] In one embodiment of this application, standardized data is represented in serialized form based on a preset structured format. The preset structured format and serialized representation of standardized data ensure efficient and compatible transmission between components of a distributed system.

[0086] On the one hand, the predefined structured format refers to clarifying the organizational logic of the four layers of metadata through a predefined fixed hierarchical structure and field constraints. For example, based on the JSON format, the main body of the data communication protocol system 10 is used as the top-level field, which is directly divided into four second-level fields: identity metadata layer 110, control metadata layer 120, security status metadata layer 130, and observation metadata layer 140. Each second-level field further defines fixed core sub-fields, such as the identity metadata layer 110 containing globally unique identifiers and publisher identity information, etc., and the format and value range of the fields are fixed through predefined rules. This structured design makes standardized data machine-readable and component-decipherable. Regardless of the development language or technology stack used by service instances, message buses, and monitoring modules in the distributed system, they can quickly parse context information according to a unified structure, avoiding parsing failures caused by format chaos.

[0087] On the other hand, serialization is a standardized data transmission format, referring to the conversion of the aforementioned structured data into a binary or text format that can be transmitted across networks. In distributed systems, communication between different components relies on network transmission. However, structured data cannot be directly transmitted over the network and needs to be compressed into a compact, transmittable data stream through a serialization process. For example, converting structured JSON, which includes four layers of metadata, into a string format, or encoding structured data into a binary stream using Protocol Buffers, reduces data volume and improves transmission efficiency. Simultaneously, the serialization process ensures data format consistency during transmission. Regardless of the differences in the underlying technical architecture between the sender and receiver, the receiver can use corresponding deserialization operations to restore the transmitted data stream to the original structured, standardized data, ensuring the complete and accurate transmission of context information and enabling a unified understanding and collaborative utilization of the communication context by various components of the distributed system.

[0088] See Figure 2 As shown, this application also provides a method for constructing a data communication protocol, the method comprising:

[0089] Step S10: When the distributed system sends business data, a protocol generation command is triggered. In a distributed system, the sending of business data usually originates from the business operations of service instances. When a service instance performs the operation of sending business data, a preset protocol generation command is automatically triggered. The protocol generation command does not require manual intervention; it is automatically detected and executed by the client SDK (Software Development Kit) or the underlying communication framework integrated with the service. For example, when the payment service finishes processing a user's payment request and needs to send the successful payment business data to the order service, the SDK will recognize the business data sending event the moment it calls the message bus's send interface, and then trigger the protocol generation command. This ensures that the generation of business data and the communication protocol starts synchronously, avoiding a disconnect where business data has been transmitted but the context protocol has not been generated.

[0090] Step S20: Based on the generation instruction, and in conjunction with the predefined policy template and the business context corresponding to the business data, data is loaded into the identity metadata layer 110, control metadata layer 120, security status metadata layer 130, and observation metadata layer 140 of the data communication protocol system 10 to form a data communication protocol. Through the dual basis of the policy template and the business context, automated and standardized data loading of the four metadata layers is achieved, forming a complete communication protocol. The predefined policy template is a data loading rule base pre-configured in the system. The policy template clearly defines the required fields, default values, and field filling logic for each metadata layer, providing a unified standard for data loading. The business context corresponding to the business data is real-time information strongly related to the current business data, including business data type, business operation priority, service instance identifier, and the system's current execution link information, providing a business-specific basis for data loading. After the protocol generation instruction is triggered, the policy template is first loaded to obtain basic rules, and then real-time information is extracted in conjunction with the business context to fill data into the four metadata layers respectively.

[0091] In addition, the construction method of this application also includes: real-time collection of the operating status parameters of the distributed system, including link load rate, node health, and network transmission latency; based on the operating status parameters, automatically adjusting the effective lifetime and processing deadline of the control metadata layer 120, as well as the encryption algorithm type of the security status metadata layer 130: if the link load rate exceeds a preset threshold, such as 80%, the encryption algorithm type of the security status metadata layer 130 is switched from a high-strength algorithm to a lightweight algorithm, and the effective lifetime of the control metadata layer 120 is shortened by a preset proportion, such as 20%; if the node health is lower than a preset threshold, the processing deadline of the control metadata layer 120 is extended by a preset duration, such as 10 seconds, to avoid data timeout due to decreased node processing capacity; and the adjusted parameters are re-filled into the corresponding metadata layer fields to complete the dynamic optimization of the metadata layer.

[0092] In one embodiment of this application, the step of loading data into the identity metadata layer 110 includes:

[0093] Step S210: Based on preset identifier generation rules, generate a globally unique identifier and fill it into the globally unique identifier field of the identity metadata layer 110. The identifier generation rules ensure that the identifier of each piece of business data is unique and distinguishable. The preset identifier generation rules are pre-defined unified identifier generation standards that can generate globally unique strings or numeric sequences, avoiding confusion of business data due to duplicate identifiers. After generation, it is directly filled into the globally unique identifier field of the identity metadata layer 110. Regardless of which component of the distributed system the business data flows through, the globally unique identifier can serve as its exclusive ID, ensuring that maintenance personnel can accurately locate specific business data using this globally unique identifier when troubleshooting, avoiding confusion with other data.

[0094] Step S211: Based on the business operation attributes corresponding to the business data, match the preset message type classification standard to determine the message type, and fill the message type into the corresponding message class field. The business operation attributes corresponding to the business data refer to the specific business behaviors associated with the business data, while the preset message type classification standard is a pre-defined category of message usage. Different categories correspond to different interaction logics, such as command classes for initiating operation instructions, event classes for notifying changes in business status, and query classes for requesting data queries. After receiving the data, the receiving end can directly identify the payment instruction that needs to be executed through this field, greatly improving data processing efficiency, avoiding the need to parse the business data content to determine the usage, and reducing latency.

[0095] Step S212: Extract the service name, service version number, and instance identifier from the service instance configuration information that sends business data, and combine them to form publisher identity information. Fill the publisher identity information into the corresponding identity field. This clarifies the data generation source, ensuring accurate location of the specific service instance in case of problems. The service instance configuration information that sends business data is the self-identification information loaded when the service instance starts, including the service name, service version number, and instance identifier. These three items are automatically extracted from this configuration information, combined according to a preset format to form publisher identity information, and then filled into the publisher identity information field of the identity metadata layer 110. When business data is abnormal, the receiving end or monitoring module can quickly locate the service instance that generated the data through this field, facilitating maintenance personnel to troubleshoot the root cause of the problem and providing a basis for tracing responsibility in the distributed system.

[0096] Step S213: Based on the message receiving object in the business process, the target receiving address is parsed and filled into the target receiving address field. The target receiving address includes at least one of the following: service name, message bus topic name, or service instance network address. The message receiving object in the business process refers to the component that the business pre-defined needs to receive the business data. According to the type of the receiving object, the corresponding target receiving address is generated. If the receiving object is a specific service, the address is the service name; if the receiving object is a specific topic of the message bus, the address is the message bus topic name; if the receiving object is a specific service instance, the address is the service instance network address. For example, if the receiving object in the business process is an order service and a message bus topic, the parsed target receiving address is "order service," which is filled into the target receiving address field of the identity metadata layer 110. After receiving the data, the message bus transmits the business data to the target component based on this address, ensuring the accuracy and effectiveness of business data flow in the distributed system.

[0097] In one embodiment of this application, the step of loading data into the control metadata layer 120 includes:

[0098] Step S220: Based on the business importance and processing priority of the business data, match the preset priority grading standard to determine the message priority, and fill the message priority into the message grading field. The business importance of the business data is determined by the business scenario attributes. For example, financial transaction data and order payment data are core business data, while log statistics data and user behavior tracking data are non-core business data. The processing priority is a resource scheduling priority derived from the business importance. Core business data must be processed first, while non-core data can be processed later. The preset priority grading standard is a predefined unified priority system, such as three levels (high / medium / low) or four levels (P0 / P1 / P2 / P3). Different levels correspond to different resource occupancy weights. For example, high-priority data can preempt the processing resources of medium / low-priority data. For instance, if the business data is user payment confirmation information, its business importance is high and its processing priority is high. After matching the grading standard, the message priority is determined to be high, and then high is filled into the message grading field of the control metadata layer 120. When the data enters the system processing queue, resources such as CPU and memory are allocated preferentially according to the priority field to ensure that core business data such as payment confirmation is processed quickly and to avoid a decline in user transaction experience due to queuing delays.

[0099] Step S221: Based on the effective processing cycle of business data, system data flow efficiency, and storage resource constraints, determine the effective lifetime and fill it into the effective lifetime field. This prevents invalid data from occupying system storage and transmission resources for extended periods, ensuring the efficient utilization of distributed system resources. The effective processing cycle of business data is the time range within which the data has processing value, determined by business logic. For example, real-time order data needs to be processed within 10 minutes; if it is not processed within 10 minutes, the order becomes invalid. Real-time monitoring data needs to be analyzed within 5 minutes; otherwise, it loses its real-time warning significance. System data flow efficiency is the system's own processing capacity indicator, determining how much time should be reserved for data transmission and queuing. Storage resource constraints are the system's capacity constraints on data storage; for example, temporary storage only supports retaining non-core data within 24 hours. The effective lifetime is calculated by combining these three factors. When data exceeds the effective lifetime without being processed or received, a cleanup mechanism is automatically triggered to release the storage and queue resources occupied by the data, preventing the accumulation of invalid data from causing system performance degradation.

[0100] Step S222: Based on the response time limit and processing requirements stipulated in the service level agreement for the business data, calculate the processing deadline for the business data and fill in the processing deadline field. This ensures that the business process proceeds according to the service level agreement and avoids business link interruptions due to data processing delays. The response time limit stipulated in the service level agreement for business data is the maximum time agreed upon by the system and the business party or user for data to complete a response; the processing requirements are the specific time constraints imposed by the business on data processing. The system will calculate the processing deadline based on the data generation time, combined with the time redundancy of the response time limit and processing requirements. After receiving the data, the system monitors the processing progress in real time. If the processing is not completed by the deadline, an early warning mechanism or automatic retry strategy will be triggered to ensure that the data is processed within the agreed time limit, guaranteeing smooth business process continuity and avoiding user complaints due to timeouts.

[0101] In one embodiment of this application, the step of loading data into the security situation metadata layer 130 includes:

[0102] Step S230 involves analyzing the content sensitivity attributes, data usage, and associated compliance requirements of business data, matching it with preset data classification standards, generating corresponding data classification tags, and filling these tags into the corresponding fields. This multi-dimensional analysis clarifies the sensitivity and compliance attributes of the data. The content sensitivity attributes of business data refer to whether the data itself contains sensitive information; for example, payment data containing user ID numbers or bank card numbers is highly sensitive, while product data containing only product names is low-sensitive. Data usage refers to the business application scenarios of the data, such as core data used for transaction verification and non-core data used for statistical analysis. Associated compliance requirements refer to the industry or regulatory standards that the data must meet, such as personal information complying with the Personal Information Protection Law. The preset data classification standards are a pre-defined hierarchical system. Based on the results of the above three-dimensional analysis, corresponding classification standards are matched to generate data classification tags. This quickly identifies the security level of the data.

[0103] Step S231: Based on the security control strategy corresponding to the data classification label, determine the data processing instructions and fill them into the corresponding fields. The data processing instructions include encryption requirement identifier, encryption algorithm type, integrity protection algorithm type, permitted usage list, and geographical restriction list. Standardized instructions ensure that business data follows security control requirements throughout the entire transmission and processing process. The security control strategy corresponding to the data classification label is a security rule preset by the system for different classification labels. Based on the generated data classification label, the corresponding security control strategy is invoked, and specific data processing instructions are formed. The encryption requirement identifier clarifies whether encryption is required; the encryption algorithm type specifies the algorithm used for encryption, such as A256GCM for highly sensitive data and AES-128 for ordinary data; the integrity protection algorithm type ensures that the data is not tampered with during transmission, such as ES256 and SHA-256; the permitted usage list limits the data's usage scenarios, such as only for payment verification and prohibiting its use for statistical analysis; the geographical restriction list defines the geographical area where the data can be transmitted, such as only within China and prohibiting transmission to overseas nodes.

[0104] Step S232: Record the source information, initial processing node, and preset flow path of business data to form complete data traceability information. Fill the corresponding fields with the data traceability information; construct a full lifecycle traceability chain for business data to ensure that the data source is traceable and the flow is trackable. The source information of business data includes the service instance that generated the data, the generation time, and the business operation that triggered the generation; the initial processing node refers to the system component that processes the data for the first time after it is generated; the preset flow path refers to the data flow direction planned by the business logic. Integrate the above information into structured traceability information.

[0105] Step S233: Based on the compliance audit requirements corresponding to the business scenario, determine whether tampering audit is required, set the corresponding audit flag, and fill the audit flag into the field. The audit flag clarifies whether data tampering behavior needs to be specifically recorded and verified. The compliance audit requirements corresponding to the business scenario are determined by industry regulations or internal company policies. Based on the current business data scenario, match the corresponding compliance audit requirements to determine whether tampering audit needs to be enabled. If enabled, set the audit flag to "Yes" to perform real-time verification of the integrity of data transmission and processing, and record any possible tampering behavior; if not enabled, set the audit flag to "No," only perform basic security protection, and do not need to record tampering-related information. Then, fill the audit flag into the corresponding field of the security posture metadata layer 130 to ensure that audit operations are performed differently according to compliance requirements, satisfying regulatory needs while avoiding unnecessary resource consumption.

[0106] In one embodiment of this application, the step of loading data into the security situation metadata layer further includes:

[0107] Step S234: Based on the real-time flow status of business data, dynamically adjust data processing instructions. According to the real-time changes in the flow of business data in the distributed system, flexibly adjust security control instructions to ensure that security policies always match actual risks. The real-time flow status of business data is not a single-dimensional piece of information, but a collection of dynamic variables including data transmission paths, receiver attributes, and transmission environments. By continuously collecting this status information in real time and comparing it with the data processing instructions initially generated by the security posture metadata layer, if a deviation is found between the real-time status and the initial policy adaptation conditions, a dynamic adjustment process for data processing instructions is triggered to avoid security vulnerabilities caused by static policies failing to cover dynamic risks.

[0108] Step S235: If business data is detected being transmitted from a domestic node to an overseas node, and the geographical restriction list prohibits cross-border transmission, the encryption algorithm type is automatically upgraded to an asymmetric encryption algorithm, and the blockchain audit layer is triggered to record cross-border transmission alarms and encryption change logs in real time. Through technologies such as node IP address identification and routing path tracing, the location changes of the transmission nodes for business data are detected in real time. When data is found to be flowing from a domestic node to an overseas node, and the geographical restriction list in the initial data processing instructions of the security status metadata layer explicitly prohibits cross-border transmission, the encryption algorithm upgrade is immediately initiated. The initially possible symmetric encryption algorithm is upgraded to an asymmetric encryption algorithm, and the increased algorithm strength offsets the additional security risks in cross-border transmission. Simultaneously, to meet compliance audit requirements, a trigger instruction is automatically sent to the blockchain audit layer, synchronously writing cross-border transmission alarm information and encryption algorithm change records into the time-series blockchain. The immutability of the blockchain is used to retain evidence of violations, facilitating subsequent tracing and accountability, and compliance checks.

[0109] Step S236: If the receiving end's permission level is lower than a preset threshold, a permission verification pre-entry flag is added to the data processing instruction, requiring the receiving end to complete a second permission verification to decrypt the data. This pre-entry permission verification mechanism builds an additional security barrier to prevent highly sensitive data from being illegally obtained by low-privileged receiving ends. Before business data is transmitted to the receiving end, the actual permission level of the receiving end is queried by connecting to the permission management center of the distributed system and compared with the initial receiving end permission threshold set in the security posture metadata layer. If the receiving end's permission level is detected to be lower than the preset threshold, transmission is not directly rejected. Instead, a permission verification pre-entry flag is added to the data processing instruction. This flag triggers the receiving end's second permission verification process. Only after the receiving end successfully passes the second verification and reports the permission verification result to the sending end will the sending end transmit the data decryption key, allowing the receiving end to decrypt and process the business data normally. This design balances business continuity while plugging the vulnerability of low-privileged receiving ends illegally obtaining data through additional permission verification.

[0110] Step S237: If the network transmission environment security level is low, a dual encryption mechanism is automatically enabled, and the effective data lifespan is shortened to half of its original duration. Through a dual strategy of encryption enhancement and lifespan compression, the risk of data exposure in low-security networks is reduced. The built-in network security level detection component performs a security rating on the transmission environment of business data. When a low network transmission environment security level is detected, two adjustments are executed simultaneously: First, a dual encryption mechanism is enabled, adding an independent encryption layer on top of the initial encryption to enhance data resistance to cracking through dual-layer protection; second, the effective data lifespan is shortened, reducing the initial effective lifespan set by the control metadata layer to 50% of its original duration. For example, if the initial TTL is 300 seconds, it is adjusted to 150 seconds. By compressing the data's lifespan in insecure networks, the window time for data interception and cracking is reduced. Even if the data is illegally obtained, it will quickly expire and lose its usability.

[0111] Step S238: The differences between the adjusted data processing instructions and the original instructions are synchronously written into the data traceability information field. By fully recording the instruction change process, the entire security policy adjustment process is ensured to be traceable and auditable, while providing a basis for subsequent problem investigation. The differences between the adjusted data processing instructions and the original instructions are not simply recorded as the final instructions, but rather presented in a structured comparison before and after the change, including key information such as the change triggering conditions, specific change content, change timestamp, and system components that performed the change. This difference information is automatically written into the data traceability information field of the security posture metadata layer, integrating it with the initial data traceability information to form a complete traceability chain. When a data security incident occurs subsequently, operations and maintenance personnel can query this field to quickly reconstruct the adjustment process of the data processing instructions, determine whether the problem was caused by improper instruction changes, and also meet the industry compliance requirements for the retention of security policy change records.

[0112] In one embodiment of this application, the step of loading data into the observable metadata layer 140 includes:

[0113] Step S240: Extract existing distributed trace identifiers from the context information of the current execution link in the distributed system. If there are no trace identifiers in the previous execution link, automatically create trace identifiers according to preset trace identifier generation rules and fill the created trace identifiers into the distributed trace identifier field. This constructs a full-link tracing mainline for business data, ensuring that cross-service business processes in the distributed system can be completely connected, solving the problems of broken links and difficulty in problem localization in traditional architectures. The context information of the current execution link in the distributed system refers to the link association information automatically retained when the business process flows between multiple services, where the distributed trace identifier is a unique identifier that runs through the entire link. When business data is ready to be sent, first attempt to extract existing Trace IDs (distributed trace identifiers) from the context information of the current execution link. If the current execution link is a brand new startup and there are no existing Trace IDs in the context, automatically generate new Trace IDs according to preset rules, and then fill the reused or newly generated Trace IDs into the distributed trace identifier field of the observable metadata layer 140. Therefore, regardless of how many services are involved in the business process, the processing logs of each link can be linked through a unified Trace ID, and operations and maintenance personnel can quickly locate the delayed nodes or abnormal services in the link.

[0114] Step S241: Identify the preceding related business links corresponding to the business data, obtain the association identifier of the business link and reuse it; if there is no reusable association identifier, generate a new global association identifier and fill it into the association identifier field; establish the association relationship between business links to solve the problem of difficulty in identifying data correlation when multiple business processes are running in parallel. The preceding related business links corresponding to the business data refer to the historical business processes that the current business data depends on or is related to. Identify the preceding related links through business semantics, and then obtain the association identifier (Correlation ID) of the link and reuse it directly. If the current business data has no preceding dependencies and there is no reusable association identifier, create a new association identifier according to the globally unique rule and fill it into the corresponding field. Through the association identifier, operation and maintenance personnel can quickly associate relevant data of different business links, clearly restore the whole picture of the business, and improve the efficiency of troubleshooting complex business scenarios.

[0115] Step S242: Based on the moment when the data communication protocol begins construction, record a timestamp accurate to the millisecond level and fill the timestamp into the precise timestamp field. The moment when the data communication protocol begins construction is the initial time point when the four-layer metadata layer data loading is officially started after the protocol generation command is triggered. This moment is directly related to the starting point of the communication protocol construction and more accurately reflects the timeliness of the entire process from protocol creation to transmission. Based on this moment, a timestamp accurate to the millisecond level is recorded through a high-precision time component to ensure the accuracy and consistency of time information. Even if there are slight deviations in the clocks of various service instances in the distributed system, the time sequence disorder problem can be avoided through the unified timestamp of the protocol construction moment. Subsequently, this timestamp is filled into the precise timestamp field of the observable metadata layer 140. Operation and maintenance personnel can calculate the protocol construction time, analyze the time distribution of each link based on this timestamp, and also sort the protocols generated by multiple services in time sequence to restore the actual execution order of the business process.

[0116] In one embodiment of this application, a predefined policy template is loaded when business data is started. The policy template predefines the required fields, default values, and field filling rules for each metadata layer. The predefined policy template is the standardized rule foundation for building the data communication protocol, and its loading timing is deeply bound to the lifecycle of the business data. It is automatically loaded into the system configuration module or memory during the business data startup phase, rather than being temporarily called during protocol generation, avoiding efficiency losses caused by repeatedly reading rules and ensuring that subsequent protocol construction can directly reuse the policy template, thus improving response speed. The policy template unifies the construction standards of the four metadata layers by pre-fixing rules. The required fields of each metadata layer clarify the basic conditions for the protocol to take effect. For example, the identity metadata layer 110 must include a globally unique identifier to ensure that the data can be uniquely distinguished, and the security posture metadata layer 130 must include data classification tags to support the execution of security policies, avoiding the invalidation of the protocol due to the absence of key fields. The default values ​​provide general configurations for fields without special business requirements. For example, the message priority is set to medium by default, the effective lifetime is set to 300 seconds by default, and the encryption algorithm is AES-128 by default, reducing the cost of repeated configuration for business users. The field filling rules define the generation logic of the field content. For example, the globally unique identifier must be generated according to the UUIDv4 specification, and the distributed tracing identifier is extracted from the link context first, ensuring the consistency and compliance of field values. This fundamentally avoids protocol format confusion caused by differences in manual configuration and provides a unified language for the protocol parsing of various components in the distributed system.

[0117] The business context corresponding to business data includes business data type, business operation priority, service instance identifier, and system current execution link information. This business context serves as the basis for adapting data communication protocols to specific business scenarios. It is a set of real-time scenario information strongly related to the current business data, automatically collected during data generation and flow to ensure the protocol conforms to global standards while meeting personalized business needs. Specifically, the business data type describes the core attributes and uses of the data, determining the classification labels and handling instructions in the security status metadata layer 130; the business operation priority reflects the urgency of the business behind the data and serves as the configuration basis for controlling the message priority field in the metadata layer 120, ensuring high-priority businesses can preempt system resources for priority processing; the service instance identifier includes the service name, version number, and instance ID that generated the data, directly providing the identity information of the publisher in the identity metadata layer 110, facilitating tracing the source of responsibility in case of data anomalies; and the current execution link information records the full-link association information to which the data belongs, used for the reuse or creation of distributed tracing identifiers in the observation metadata layer 140, ensuring the continuity of cross-service link tracing. In short, the business context is a scenario-based supplement to the strategy template. The combination of the two allows the generated communication protocol to be both standardized and business-adaptable.

[0118] See Figure 3 As shown, this application also provides a distributed context awareness system 20, which includes a communication unit 210, a monitoring and analysis module 220, and a response execution module 230.

[0119] Communication unit 210 includes a data communication protocol system 10 and is associated with a message bus subscription. Communication unit 210 is a component connecting the data communication protocol system 10 and the message bus, binding the data communication protocol system 10 with the business data payload to form a complete and transmittable communication unit 210. Simultaneously, through its subscription association with the message bus, it enables efficient flow of context and business data. On one hand, the communication unit 210 has a built-in data communication protocol system 10, which automatically integrates the constructed four-layer metadata and business data payload into a unified structure. On the other hand, the communication unit 210 accesses the message bus through a subscription association mechanism. The sending end's communication unit 210 publishes itself to a specified topic on the message bus according to business requirements, while the receiving end's communication unit 210 subscribes to the corresponding topic, obtaining communication units 210 on the bus in real time and parsing the protocol context and business data. This association method makes the message bus a context propagation channel. Regardless of where service instances are deployed in the distributed system, they can obtain context information in a unified format through the interaction between the communication unit 210 and the message bus, avoiding communication obstacles caused by protocol incompatibility.

[0120] The monitoring and analysis module 220 subscribes to and associates with the communication unit 210. The monitoring and analysis module 220 extracts feature information from the data communication protocol system 10 and performs real-time analysis. The monitoring and analysis module 220 is used for distributed system context awareness. Through its subscription association with the communication unit 210, it can obtain the entire communication context in real time without intruding on business processes, and perform dynamic analysis in security, compliance, and performance dimensions based on the extracted feature information. The subscription association adopts a bypass listening mode. The monitoring and analysis module 220 subscribes to all or specified topics of communication units 210 on the message bus, synchronously acquiring information about the data communication protocol system 10 from the communication unit 210 without interfering with the normal flow of business data. Subsequently, it extracts key feature information from the protocol system, such as service identifiers, message types, data classification tags, priorities, and timing information. This information can be obtained without parsing the business data payload, ensuring analysis efficiency while avoiding the leakage of sensitive business data. In the analysis phase, multi-dimensional real-time analysis is performed based on feature information. The security dimension verifies the consistency between data classification labels and encryption instructions. The compliance dimension checks the implementation of compliance requirements such as geographical scope restrictions. The performance dimension analyzes link congestion risks through time-series information and priority. The behavior dimension compares message frequency with historical baselines to identify anomalies, forming structured analysis results.

[0121] The response execution module 230 receives the analysis results from the monitoring and analysis module 220 and triggers tiered response actions based on these results. These tiered response actions include generating alarm information, performing rate limiting, and implementing service isolation. The response execution module 230 triggers precise and tiered response actions based on the risk level and anomaly type output by the monitoring and analysis module 220, enabling rapid handling of security threats and operational anomalies in the distributed system. The response execution module 230 first receives the structured analysis results from the monitoring and analysis module 220 and, based on a preset response rule mapping table, matches the corresponding tiered response actions. For high-risk anomalies, it triggers service isolation, temporarily blocking the interaction between the abnormal service instance and the message bus to prevent risk propagation. For medium-risk anomalies, it performs rate limiting, restricting the message sending rate of the abnormal service to protect business link resources. For low-risk anomalies, it only generates alarm information and notifies administrators via SMS, logs, or the operation and maintenance platform, without interrupting business operations. This tiered response mechanism avoids business interruptions caused by a one-size-fits-all approach and enables rapid implementation of control measures for different risk levels, ensuring the stable operation of the distributed system under the premise of security and compliance.

[0122] In one embodiment of this application, the context-aware system 20 further includes a blockchain audit layer 240. The blockchain audit layer 240 is used to set up a time-series blockchain and store hashes of key information of the data communication protocol system 10 and audit-related data that meet preset conditions. The blockchain audit layer 240 is added to meet the high-level audit requirements of distributed systems and to ensure the traceability and trustworthiness of communication contexts. Built around the time-series blockchain, it securely stores and audits key information of the data communication protocol system 10, and only performs recording operations on communication units 210 that meet preset conditions, thus balancing audit security and system performance.

[0123] From a technical architecture perspective, the time-series blockchain serves as the storage medium for the blockchain audit layer 240, organizing audit data according to the time dimension. Based on the precise timestamps generated by the data communication protocol system 10, the audit data is segmented and stored in chronological order. This design not only conforms to the time-series flow characteristics of the communication unit 210 in the distributed system but also significantly improves the efficiency of querying audit records by time range, avoiding the query delays caused by the disordered storage of data in traditional blockchains.

[0124] In terms of data storage logic, the blockchain audit layer 240 does not store complete protocol information for all communication units 210. Instead, it extracts key information hashes and audit-related data from the data communication protocol system 10. The key information hash is a digest value obtained by hashing core fields in the protocol system, ensuring the integrity of key information while avoiding blockchain data bloat caused by directly storing sensitive context. Audit-related data includes the reason for triggering the audit, the timestamp of the audit record generation, and associated distributed tracking identifiers, providing necessary scenario information for audit tracing.

[0125] Meanwhile, the blockchain audit layer 240 achieves precise screening of audit data through preset conditions. The blockchain recording process will only be triggered when the data communication protocol system 10 meets specific conditions, avoiding the waste of resources caused by indiscriminate storage of all communication units 210. While ensuring that the audit data is tamper-proof and traceable, it achieves a balance between system performance and audit security, providing a basis for compliance audit and security event tracing for the distributed scenario awareness system 20.

[0126] In one embodiment of this application, the time-series blockchain uses a preset proof-of-stake algorithm to shard and store audit data according to the time dimension. In this embodiment, the time-series blockchain, through the collaborative design of the preset proof-of-stake algorithm and time-dimensional sharded storage, ensures both the security and reliability of audit data storage and the efficiency of audit operations in a distributed system. The preset proof-of-stake algorithm serves as the consensus mechanism of the time-series blockchain, selecting consensus nodes by evaluating the stake held by each node. Nodes with higher stakes are more likely to obtain the right to verify and record audit data, which reduces resource consumption in the consensus process and ensures compliance of node behavior through stake constraints, thereby guaranteeing the immutability of the audit data stored in the blockchain.

[0127] Sharding audit data by time dimension is a storage strategy optimized for the time-series attributes of audit data. Using the precise timestamps generated by the data communication protocol system 10 as a benchmark, audit data is divided into independent data shards according to preset time periods. Each shard corresponds to audit records within a specific time window. This sharding method not only significantly improves the query efficiency of audit data but also enables elastic expansion of audit data, reducing the problems of slow queries and difficult expansion in large-scale time-series audit scenarios while ensuring audit security.

[0128] In another embodiment of this application, all nodes in the time-series blockchain deploy a time synchronization module. This module periodically obtains world time from an authoritative time source and calibrates the node's local clock accordingly. The time synchronization module establishes communication connections with highly reliable and accurate time providers such as BeiDou time servers, GPS time terminals, and network time services provided by the National Time Service Center to obtain a unified world time and dynamically calibrate the node's local clock based on this authoritative world time. Specifically, the time synchronization module proactively initiates time requests to the authoritative time source at preset intervals. After receiving the returned standard time signal, it compares the time deviation of the node's current local clock and automatically adjusts the local clock to be perfectly aligned with the authoritative world time, ensuring that the local clock deviation of all blockchain nodes in the network is controlled within an extremely low range, such as within milliseconds. This design eliminates the time inconsistency problem caused by node clock drift at the physical level by introducing an external authoritative time benchmark. It provides a precise and unified time basis for time-series blockchains to store audit data in shards according to the time dimension, sort blocks by timestamp, and achieve time alignment between audit data and business data. At the same time, it avoids the security risk of malicious nodes forging the time sequence of audit records by tampering with local time.

[0129] In one embodiment of this application, the feature information includes service identifier, message type, priority, data classification label and time sequence information; the feature information is the decision basis for realizing distributed system context awareness extracted by the monitoring and analysis module 220 from the data communication protocol system 10. The five types of information it covers correspond to the key dimensions of the communication context. Without parsing business data, it can fully reflect the identity, priority, security attributes and time characteristics of the communication unit 210. Among them, the service identifier originates from the publisher identity information of the identity metadata layer 110, which can accurately locate the source of business data generation and is a key identifier for tracing abnormal services; the message type comes from the identity metadata layer 110 and is divided into command, event, and query types according to business operation attributes, quickly identifying the data interaction intent; the priority is taken from the control metadata layer 120 and divided into high / medium / low to determine the urgency of business data; the data classification label comes from the security posture metadata layer 130 and is classified according to sensitivity and compliance attributes, serving as the basis for verifying the implementation of security policies; and the time sequence information is based on the precise timestamps of the observation metadata layer 140, recording the generation and transmission time of the communication unit 210, used to analyze link latency or identify abnormal behavior in the time dimension. These five types of feature information complement each other and jointly support the monitoring and analysis module 220 in completing security compliance checks, abnormal behavior identification, and performance risk assessment, providing a comprehensive and accurate judgment basis for subsequent graded response.

[0130] Business data is encrypted according to the security status metadata layer 130 of the data communication protocol system 10. The encryption process of business data is deeply integrated with the security status metadata layer 130 of the data communication protocol system 10, forming an inherent security mechanism that guides encryption through policies. This ensures that the encryption operation accurately matches the security requirements of the business data, avoiding performance degradation due to over-encryption or security risks caused by insufficient encryption. The security status metadata layer 130 first generates data classification tags based on the sensitive attributes and compliance requirements of the business data, and then matches the corresponding security control policies according to the tags, clarifying specific encryption-related instructions, including whether encryption is required, what encryption algorithm to use, and the management rules for encryption keys. In actual encryption operations, the business data generating end reads the encryption instructions from the security status metadata layer 130 and automatically executes the corresponding encryption process. At the same time, information such as the encryption algorithm type and key identifier is synchronously recorded in the security status metadata layer 130 for the receiving end to refer to during decryption. This protocol-guided encryption model eliminates the need for manual configuration or independent encryption tools. Instead, it seamlessly integrates with the construction and transmission of communication protocols, ensuring that business data is protected with a unified security strategy throughout the entire process from generation to transmission. This adapts to the secure communication needs across components and scenarios in distributed systems.

[0131] In one embodiment of this application, the context-aware system 20 further includes a rule management module 250 for maintaining a rule system, which includes data compliance rules, access control rules, behavior anomaly rules, and security posture rules. Data compliance rules are used to check the compliance of data classification and labeling, encryption requirements, and geographical restrictions. Behavior anomaly rules are used to detect deviations in message frequency, data volume trends, and historical benchmarks. The rule management module 250 not only undertakes the functions of rule creation, editing, version control, and distribution, but also records rule execution logs to support subsequent optimization. Operations personnel can easily adjust rules through the rule management module 250 and ensure that monitoring analysis, response execution, and other components obtain consistent, up-to-date rules in real time, avoiding monitoring deviations caused by rule inconsistencies. The maintained rule system covers four core types, ensuring system security compliance and anomaly detectability from multiple dimensions. Data compliance rules focus on verifying the compliance of data classification and labeling, encryption requirements, and geographical restrictions to ensure that data processing complies with laws and regulations. Access control rules verify the legality of data access permissions and uses, preventing unauthorized access. Abnormal behavior rules detect anomalies in message frequency and data volume by comparing real-time and historical benchmarks, promptly identifying potential faults or malicious behavior. Security posture rules verify the implementation of security policies, ensuring the overall security and stability of the system. These four types of rules work together, especially data compliance rules and abnormal behavior rules, which complement each other to jointly build a comprehensive protection and awareness network for distributed systems.

[0132] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A data communication protocol system, characterized in that, The data communication protocol system is applied to a distributed system. This system stores standardized data of the communication context, which is bound to business data and synchronously transmitted among the components of the distributed system. The data communication protocol system includes: The identity metadata layer is used to define the semantic identity of the business data in the distributed system; The control metadata layer is used to define the lifecycle and processing rules of the business data in the distributed system; The security posture metadata layer is used to determine the security policies and compliance requirements related to the business data. The observable metadata layer is used to provide link tracing and correlation information of the business data in the distributed system.

2. The data communication protocol system according to claim 1, characterized in that, The identity metadata includes at least a globally unique identifier, message type, publisher identity information, and target receiving address; The control metadata layer includes at least message priority, valid lifetime, and processing deadline. The security situation metadata layer includes at least data classification labels, data processing instructions, and data traceability information; The observable metadata layer includes at least a distributed tracking identifier and a precise timestamp.

3. The data communication protocol system according to claim 1, characterized in that, The standardized data is based on a preset structured format and represented in a serialized form.

4. A method for constructing a data communication protocol, characterized in that, The construction method includes: When the distributed system sends business data, it triggers a protocol generation command; According to the generation instructions, combined with the predefined policy template and the business context corresponding to the business data, data is loaded into the identity metadata layer, control metadata layer, security status metadata layer and observation metadata layer of the data communication protocol system as described in any one of claims 1 to 3, respectively, to form a data communication protocol.

5. The construction method according to claim 4, characterized in that, The steps of loading data into the identity metadata layer include: Based on preset identifier generation rules, a globally unique identifier is generated and filled into the globally unique identifier field of the identity metadata layer; Based on the business operation attributes corresponding to the business data, a preset message type classification standard is matched to determine the message type, and the message type is filled into the corresponding message class field; Extract the service name, service version number, and instance identifier from the service instance configuration information that sends business data, and combine them to form publisher identity information. Fill the publisher identity information into the corresponding identity field. Based on the message receiving object in the business process, the target receiving address is parsed and filled into the target receiving address field. The target receiving address includes at least one of the following: service name, message bus topic name, or service instance network address.

6. The construction method according to claim 4, characterized in that, The step of loading data into the control metadata layer includes: Based on the business importance and processing priority corresponding to the business data, a preset priority classification standard is matched to determine the message priority, and the message priority is filled into the message classification field. Based on the effective processing cycle of the business data, the system data flow efficiency, and the storage resource constraints, the effective lifetime is determined and filled into the effective lifetime field. Based on the response time limit and processing requirements of the service level agreement for the business data, calculate the processing deadline for the business data and fill the processing deadline into the processing deadline field.

7. The construction method according to claim 4, characterized in that, The steps of loading data into the security posture metadata layer include: Analyze the content sensitivity attributes, data usage, and associated compliance requirements of the business data, match them with preset data classification standards, generate corresponding data classification tags, and fill the data classification tags into the corresponding fields; Based on the security control policy corresponding to the data classification label, determine the data disposal instruction and fill the data disposal instruction into the corresponding field. The data disposal instruction includes encryption requirement identifier, encryption algorithm type, integrity protection algorithm type, list of permitted uses and list of geographical scope restrictions. Record the source information of the business data, the initial processing node and the preset flow path to form complete data traceability information, and fill the data traceability information into the corresponding fields; Based on the compliance audit requirements corresponding to the business scenario, determine whether the audit needs to be tampered with, set the corresponding audit identifier, and fill the audit identifier into the field.

8. The construction method according to claim 7, characterized in that, The step of loading data into the security situation metadata layer further includes: Based on the real-time flow status of the aforementioned business data, dynamically adjust data processing instructions: If the business data is detected to be transmitted from a domestic node to an overseas node, and the geographical restriction list prohibits cross-border transmission, the encryption algorithm type will be automatically upgraded to an asymmetric encryption algorithm, and the blockchain audit layer will be triggered to record cross-border transmission alarms and encryption change logs in real time. If the receiver's permission level is lower than the preset threshold, a permission verification pre-signal will be added to the data processing instruction, requiring the receiver to complete a second permission verification in order to decrypt the data. If the network transmission environment has a low security level, a dual encryption mechanism will be automatically enabled, and the effective data lifespan will be shortened to half of the original duration. The differences between the adjusted data processing instructions and the original instructions are synchronously written into the data traceability information field.

9. The construction method according to claim 4, characterized in that, The step of loading data into the observable metadata layer includes: Extract existing distributed tracing identifiers from the context information of the current execution link in the distributed system. If there are no tracing identifiers in the previous execution link, automatically create tracing identifiers according to the preset tracing identifier generation rules and fill the created tracing identifiers into the distributed tracing identifier field. Identify the preceding associated business link corresponding to the business data, obtain the association identifier of the business link and reuse it; if there is no reusable association identifier, generate a new global association identifier and fill the association identifier field with the global association identifier. Based on the moment when the data communication protocol was first established, a timestamp accurate to the millisecond level is recorded, and the timestamp is filled into the precise timestamp field.

10. The construction method according to claim 4, characterized in that, The predefined strategy template is loaded when business data is started. The strategy template predefines the required fields, default values ​​and field filling rules for each metadata layer. The business context corresponding to the business data includes the business data type, business operation priority, service instance identifier, and the current execution chain information of the system.

11. A distributed context-aware system, characterized in that, The context-aware system includes: A communication unit, comprising a data communication protocol system as described in any one of claims 1-3, wherein the communication unit is associated with a message bus subscription; A monitoring and analysis module is associated with the communication unit. The monitoring and analysis module extracts feature information from the data communication protocol system and performs real-time analysis. The response execution module is used to receive the analysis results from the monitoring and analysis module, and trigger hierarchical response actions based on the analysis results. The hierarchical response actions include generating alarm information, performing rate limiting, and implementing service isolation.

12. The context-aware system according to claim 11, characterized in that, The context-aware system also includes: The blockchain audit layer is used to set up a time-series blockchain and store key information hashes and audit-related data of a data communication protocol system that meets preset conditions.

13. The context-aware system according to claim 12, characterized in that, The time-series blockchain is based on a preset proof-of-stake algorithm and stores audit data in segments according to the time dimension; Alternatively, all nodes of the time-series blockchain may deploy a time synchronization module, which periodically obtains world time from an authoritative time source and calibrates the local clock of the nodes based on that time.

14. The context-aware system according to claim 11, characterized in that, The feature information includes service identifier, message type, priority, data classification label, and time sequence information; The business data is encrypted according to the security status metadata layer of the data communication protocol system.

15. The context-aware system according to claim 11, characterized in that, The context-aware system also includes: The rule management module is used to maintain the rule system, which includes data compliance rules, access control rules, behavior anomaly rules, and security posture rules. Among them, the data compliance rules are used to check the compliance of data classification and labeling, encryption requirements, and geographical restrictions, and the behavior anomaly rules are used to detect deviations from message frequency, data volume change trends, and historical benchmarks.

Images