Multi-protocol adaptive service processing method and system

Abstract

The invention discloses a multi-protocol adaptive service processing method and system, and a server side method comprises the steps: receiving a service processing request sent by a client side where a first system is deployed, wherein the service processing request carries to-be-sent service data; when the data format of the to-be-sent service data is not the preset default data format, converting the data format of the to-be-sent service data into the preset default data format according to a stored multi-protocol adapter to obtain first service data; identifying a second system of the flow direction required by the to-be-sent service data; when the data request format of the second system is not the preset default data format, converting the data format of the first service data into the data request format according to the multi-protocol adapter to obtain second service data; and pushing the second service data to the client deployed with the second system. Therefore, by adopting the embodiment of the invention, the development work of point-to-point docking can be avoided, and meanwhile, a service scene with a high real-time requirement can be met.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular, to a service processing method and system for multi-protocol adaptation. Background Art

[0002] With the diversification of business and the acceleration of digital transformation, enterprises need to integrate various types of application systems for business processing. Since different systems use different protocols and data formats, such as the financial system using the WebService protocol, the IoT system relying on the MQTT message queue, and the production system only opening RESTful APIs, it is difficult for data to flow smoothly between these systems. In order to achieve efficient business process management, efficient data interaction and information sharing are required between these systems.

[0003] In related technologies, enterprises usually adopt a point-to-point integration method to achieve data interaction between different systems. However, point-to-point connections all need to be maintained separately. When the interface or protocol of one of the systems changes, all related connections need to be re-adjusted and tested, bringing a heavy burden to the enterprise's IT department. At the same time, the point-to-point integration method usually relies on the message push of the polling mechanism and is difficult to meet the business scenarios with high real-time requirements. Summary of the Invention

[0004] Embodiments of this application provide a service processing method and system for multi-protocol adaptation. To provide a basic understanding of some aspects of the disclosed embodiments, a simple summary is given below. This summary part is not a general review, nor is it intended to identify key / important constituent elements or delineate the protection scope of these embodiments. Its sole purpose is to present some concepts in a simple form as a preamble to the subsequent detailed description.

[0005] In a first aspect, embodiments of this application provide a service processing method for multi-protocol adaptation, which is applied to a server. The method includes: Receiving a service processing request sent by a client deploying a first system, where the service processing request is used to request a client deploying a second system to perform collaborative service process processing, and the service processing request carries service data to be sent; In the case where the data format of the service data to be sent is not the preset default data format, converting the data format of the service data to be sent into the preset default data format according to a multi-protocol adapter stored in a preset main service node or a pre-configured service node to obtain first service data; the multi-protocol adapter includes data bidirectional conversion scripts between the data formats of different data protocols and the preset default data format; Identifying the second system to which the service data to be sent needs to flow; In the case where the data request format of the second system is not the preset default data format, convert the data format of the first service data into the data request format according to the multi-protocol adapter to obtain the second service data; Push the second service data to the client where the second system is deployed through the HTTP protocol.

[0006] Optionally, the method further includes: Receive the service processing result sent by the client where the second system is deployed; According to the multi-protocol adapter, convert the data format of the service processing result into the data request format of the first system to obtain the final service processing result of the service processing request; Send the final service processing result to the client where the first system is deployed.

[0007] Optionally, the method further includes: Monitor the service status of the preset main service node through a preset health detection mechanism; In the case where a node outage occurs in the service status, switch the traffic to the pre-configured service node through the Kubernetes cluster.

[0008] Optionally, feature templates are preset for different data protocols; Converting the data format of the service data to be sent into the preset default data format to obtain the first service data includes: Extract the fixed fields of the message header of the service data to be sent; Establish a pattern fingerprint according to the fixed fields of the message header; Perform pattern matching between the pattern fingerprint and the feature templates set for different data protocols to obtain a matching result; In the case where the matching result indicates a successful match, obtain the target feature template that matches the pattern fingerprint successfully; Determine the target data protocol corresponding to the target feature template; From the data bidirectional conversion scripts between the data formats of different data protocols included in the multi-protocol adapter and the preset default data format, obtain the target data bidirectional conversion script between the data format of the target data protocol and the preset default data format; Convert the data format of the service data to be sent into the preset default data format through the target data bidirectional conversion script to obtain the first service data.

[0009] Optionally, establishing a pattern fingerprint according to the fixed fields of the message header includes: Convert the fixed fields of the message header into a hexadecimal string to obtain the original byte encoding; Encode the text fields in the fixed fields of the message header to obtain a semantic hash encoding; Encode the field length value of the fixed fields in the message header to obtain a structure feature encoding; Combine the original byte encoding, semantic hash encoding, and structure feature encoding to obtain a field feature triple; Use the field feature triple as the original parameter of the compression algorithm and execute the compression algorithm to compress the field feature triple to generate a 256-bit fixed-length pattern fingerprint.

[0010] Optionally, the method further includes: In the case where the matching result indicates a match failure, analyze the payload nested structure of the service data to be sent to determine the dispersion of JSON key-value pairs and the periodic characteristics of device data as structural entropy features; Classify the structural entropy features according to a pre-trained lightweight classification model to obtain a classification result; Perform fuzzy matching between the classification result and the fields of each original protocol in the preset original protocol library to find the original protocol that matches the fixed fields of the message header; Create a field value conversion script between the fields in the data format of the original protocol and the fields in the preset default data format to obtain a two-way data conversion script between the data format of the original protocol and the preset default data format; Store the two-way data conversion script between the data format of the original protocol and the preset default data format in the multi-protocol adapter.

[0011] Optionally, classifying the structural entropy features to obtain a classification result includes: Quantify the structural entropy features to obtain the dispersion value of JSON key-value pairs and the periodic intensity of device data time series; Scale the dispersion value and the periodic intensity of device data time series to the standardized range that can be processed by the model to obtain a standardized feature vector; Input the standardized feature vector into the pre-trained lightweight classification model to output the predicted probability distribution corresponding to each original protocol of the structural entropy features; Obtain the protocol label corresponding to the highest probability from the predicted probability distribution; Use the protocol label corresponding to the highest probability as the classification result.

[0012] Optionally, generate a pre-trained lightweight classification model according to the following steps, including: Extract protocol conversion logs from the multi-protocol adapter logs, and the protocol conversion logs include dispersion values, periodic intensities, and protocol type labels; Construct an initial training set according to the protocol conversion logs; Obtain the business system label associated with the protocol of the initial training set; Perform business scenario weighting on the initial training set and business system tags to obtain a set of feature vectors weighted by business scenarios; Group the set of feature vectors weighted by business scenarios according to protocol types, calculate the mean and standard deviation of each group of features, and perform within-group Z-score normalization to obtain a set of normalized feature vectors grouped by protocol clusters; Create a lightweight classification model that can output a multi-protocol probability distribution. The lightweight classification model includes an input layer and an output layer. Two nodes in the input layer correspond to the dispersion degree and the periodic intensity, and the output layer includes a Softmax probability distribution; Input the set of normalized feature vectors grouped by protocol clusters into the lightweight classification model for model training, and output the model loss value; Generate a pre-trained lightweight classification model when the model loss value reaches the minimum.

[0013] In a second aspect, an embodiment of the present application provides a business processing method for multi-protocol adaptation, which is applied to a client. The method includes: Receive second service data sent by the server; the second service data is obtained by the server converting the data format of the to-be-sent service data sent by the client deploying the first system according to a multi-protocol adapter; the multi-protocol adapter includes data bidirectional conversion scripts between the data formats of different data protocols and a preset default data format; Generate a business process collaborative processing request according to the second service data; Store the business process collaborative processing request in a preset distributed message queue to asynchronously process the business process collaborative processing request to obtain a business processing result; the preset distributed message queue is a Kafka queue designed using a distributed architecture; Send the business processing result to the server.

[0014] In a third aspect, an embodiment of the present application provides a business processing system for multi-protocol adaptation. The system includes: A receiving module, configured to receive a business processing request sent by a client deploying a first system. The business processing request is used to request a client deploying a second system to perform business process collaborative processing, and the business processing request carries to-be-sent service data; A first conversion module, configured to, when the data format of the to-be-sent service data is not the preset default data format, convert the data format of the to-be-sent service data into the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-configured service node to obtain first service data; the multi-protocol adapter includes data bidirectional conversion scripts between the data formats of different data protocols and the preset default data format; An identification module, configured to identify the second system to which the to-be-sent service data needs to flow; A second conversion module, configured to convert the data format of the first service data into a data request format according to a multi-protocol adapter to obtain second service data when the data request format of the second system is not the preset default data format; A push module, configured to push the second service data to a client where the second system is deployed through the HTTP protocol.

[0015] The technical solution provided by the embodiments of the present application may include the following beneficial effects: In the embodiments of the present application, on the one hand, the multi-protocol adapter includes data bidirectional conversion scripts between the data formats of different data protocols and the preset default data format. As an intermediate layer, the multi-protocol adapter uniformly processes protocol conversion. When a new system is accessed, only the adapter script needs to be configured, and there is no need to rewrite any code in the system, which greatly reduces the development workload, can avoid the development work of point-to-point docking, and can meet the business scenarios with high real-time requirements. On the other hand, the protocol is dynamically recognized through a pre-trained lightweight classification model, enabling the model to adaptively recognize new protocols, automatically generate new data conversion scripts and store them, and continuously enrich and optimize the functions of the multi-protocol adapter.

[0016] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0018] Figure 1 is a schematic flowchart of a method for processing services with multi-protocol adaptation provided by the embodiments of the present application; Figure 2 is a schematic diagram of a scenario for interaction between a client and a server provided by the embodiments of the present application; Figure 3 is a schematic flowchart of another method for processing services with multi-protocol adaptation provided by the embodiments of the present application; Figure 4 is a schematic flowchart of a method for training a lightweight classification model provided by the embodiments of the present application; Figure 5 is a schematic diagram of the model architecture of a lightweight classification model provided by the embodiments of the present application; Figure 6 is a schematic diagram of the structure of a service processing system with multi-protocol adaptation provided by the present application; Figure 7 is a schematic diagram of the structure of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0019] The following description and the accompanying drawings fully illustrate specific embodiments of the present application, enabling those skilled in the art to practice them.

[0020] It should be clear that the described embodiments are only some embodiments of the present application, not all of them. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in the present application without creative efforts fall within the scope of protection of the present application.

[0021] When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of systems and methods consistent with some aspects of the present application as detailed in the appended claims.

[0022] In the description of the present application, it should be understood that terms such as "first", "second", etc. are used only for descriptive purposes and cannot be construed as indicating or implying relative importance. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood according to specific circumstances. In addition, in the description of the present application, unless otherwise specified, "a plurality" means two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after.

[0023] Currently, enterprises usually adopt a point-to-point integration method to achieve data interaction between different systems.

[0024] The inventors have realized that point-to-point connections all need to be maintained separately. When the interface or protocol of one of the systems changes, all relevant connections need to be readjusted and tested, bringing a heavy burden to the enterprise's IT department. At the same time, the point-to-point integration method usually relies on the message push of the polling mechanism and is difficult to meet the business scenarios with high real-time requirements.

[0025] To solve the above problems, the present application provides a service processing method and system for multi - protocol adaptation to solve the problems existing in the above - mentioned related technical problems. In an embodiment of the present application, on the one hand, the multi - protocol adapter includes a data bidirectional conversion script between the data formats of different data protocols and a preset default data format. As an intermediate layer, the multi - protocol adapter uniformly processes protocol conversion. When a new system is accessed, only the adapter script needs to be configured, and there is no need to rewrite any code in the system, which greatly reduces the development workload, avoids the development work of point - to - point docking, and can meet the business scenarios with high real - time requirements. On the other hand, the protocol is dynamically recognized through a pre - trained lightweight classification model, enabling the model to adaptively recognize new protocols, automatically generate new data conversion scripts and store them, and continuously enrich and optimize the functions of the multi - protocol adapter. The following uses exemplary embodiments for detailed description.

[0026] The following will combine with the Figure 1 - attached Figure 5 drawings to introduce in detail the service processing method for multi - protocol adaptation provided by the embodiments of the present application. This method can be implemented depending on a computer program and can run on a service processing system for multi - protocol adaptation based on the von Neumann architecture. This computer program can be integrated into an application or run as an independent utility - type application.

[0027] Please refer to Figure 1 , which is a schematic flowchart of a service processing method for multi - protocol adaptation provided by an embodiment of the present application and is applied to the server. As Figure 1 shown, the method of the embodiment of the present application may include the following steps: S101, Receive a service processing request sent by a client deploying a first system. The service processing request is used to request a client deploying a second system to perform collaborative processing of a service process, and the service processing request carries service data to be sent; Among them, the first system is the source system that initiates the service request (such as the financial system using the WebService protocol). The second system is the target system that needs to collaboratively process the service (such as the production system using the RESTful API). The service processing request includes a communication message containing service data and operation instructions (such as a payment request, a work order issuance). The service data to be sent is the actual service information to be transmitted in the request (such as order details in JSON format).

[0028] In some embodiments of the present application, the first system client sends a service processing request to the server. The server listens for service processing requests from the first system through the HTTP / HTTPS port, separates the service data and metadata from the message carried in the service processing request, that is, locates the data payload (JSON in the HTTP request body, tags in the SOAP message), strips the protocol encapsulation (such as removing the HTTP header, MQTT Fixed Header), and obtains the pure service data (such as {"orderId": "123", "amount": 100.00}), obtaining the service data to be sent.

[0029] Further, it is detected whether the service data to be sent conforms to a preset default format (such as JSON). For example, an attempt is made to parse the service data to be sent using the preset default data format, and the parsing result is captured (such as an error when attempting to parse XML data as JSON), obtaining a boolean flag isDefaultFormat (True / False).

[0030] Further, in the case where the boolean flag is True, it is determined that the data format of the service data to be sent is the preset default data format. In the case where the boolean flag is False, it is determined that the data format of the service data to be sent is not the preset default data format.

[0031] S102, in the case where the data format of the service data to be sent is not the preset default data format, convert the data format of the service data to be sent to the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-device service node, obtaining the first service data; the multi-protocol adapter includes data bidirectional conversion scripts between the data formats of different data protocols and the preset default data format; Among them, the preset default data format is an intermediate data format uniformly used within the system (such as JSON). The main service node is the main service instance currently undertaking the protocol conversion task. The standby service node is a standby service instance in a hot standby state, which takes over the work when the main node fails. The multi-protocol adapter contains a component library with conversion logic for various protocols and the default format. The data bidirectional conversion script is an executable forward (protocol → default) and reverse (default → protocol) conversion program.

[0032] In some embodiments of the present application, in the case where the data format of the service data to be sent is the preset default data format, step S103 is executed.

[0033] In some other embodiments of the present application, in the case where the data format of the service data to be sent is not the preset default data format, monitor the service status of the preset main service node through the preset health detection mechanism. In the case where the service status is normal, obtain the multi-protocol adapter stored in the main service node.

[0034] Alternatively, in the case of a node outage in the service status, the traffic is switched to the pre-configured service node through the Kubernetes cluster, and the multi-protocol adapter stored in the standby service node is obtained.

[0035] In the embodiments of the present application, through the health detection mechanism and the traffic switching mechanism of the Kubernetes cluster, the high availability and stability of the service are ensured, and the impact on the business caused by node failures is reduced.

[0036] Among them, feature templates are preset for different data protocols.

[0037] Specifically, the process of converting the data format of the service data to be sent into a preset default data format to obtain the first service data includes: extracting the fixed fields of the message header of the service data to be sent; establishing a pattern fingerprint according to the fixed fields of the message header; performing pattern matching between the pattern fingerprint and the feature templates set for different data protocols to obtain a matching result; in the case where the matching result indicates a successful match, obtaining the target feature template that matches the pattern fingerprint; determining the target data protocol corresponding to the target feature template; obtaining the target data bi-directional conversion script between the data format of the target data protocol and the preset default data format from the data bi-directional conversion scripts between the data formats of different data protocols included in the multi-protocol adapter; and converting the data format of the service data to be sent into the preset default data format through the target data bi-directional conversion script to obtain the first service data.

[0038] For example, extract the fixed fields of the message header of the service data to be sent. The fixed fields of the message header include fields such as protocol version number, message type, and data length. Assume the received message header is: Protocol Version: 1.0, Message Type: 0x01, Data Length: 128. Convert these fields into a pattern fingerprint. The finally generated pattern fingerprint is a fixed-length string, such as: Mode Fingerprint: “0x312e30|0x01|hash(128)”. Match the generated pattern fingerprint with the preset feature templates. The feature templates are preset for different data protocols. For example: Modbus: “0x312e30|0x01|hash(128)”, OPC UA: “0x322e30|0x02|hash(256)”, Custom Protocol: “0x332e30|0x03|hash(64)”. It can be seen that the pattern fingerprint matches successfully with the feature template of Modbus. After successful matching, obtain the target feature template that matches the pattern fingerprint, that is, the template of Modbus. Determine that the target data protocol corresponding to this template is Modbus. Obtain the data bidirectional conversion script between the Modbus protocol and the preset default data format (JSON) from the multi-protocol adapter. The conversion script is as follows: function modbusToJson(data) { return { "device_id": data.deviceId, "sensor_value": data.value, "timestamp": data.timestamp }; }。

[0039] Use the above conversion script to convert the Modbus format data sent by the client deploying the first system into JSON format. Assume the original Modbus data is: { "deviceId": 101, "value": 25.5, "timestamp": 1678000000 }。

[0040] The converted first service data in JSON format is: { "device_id": 101, "sensor_value": 25.5, "timestamp": 1678000000 }。

[0041] In the embodiments of the present application, by extracting the fixed fields of the message header and establishing a pattern fingerprint, and combining with a preset feature template for pattern matching, it is possible to quickly and accurately identify the data protocol used by the service data to be sent. Furthermore, the corresponding data bi-directional conversion script is obtained to convert the data format into a preset default format. This process not only improves the automation degree and efficiency of data processing, but also enhances the flexibility and scalability of the system, can easily handle the data interaction requirements of multiple different protocols, and reduces the complexity and cost of system integration.

[0042] In some embodiments of the present application, the specific process of establishing a pattern fingerprint according to the fixed fields of the message header includes: converting the fixed fields of the message header into a hexadecimal string to obtain the original byte encoding; encoding the text fields in the fixed fields of the message header to obtain the semantic hash encoding; encoding the field length value of the fixed fields of the message header to obtain the structural feature encoding; combining the original byte encoding, the semantic hash encoding, and the structural feature encoding to obtain a field feature triple; using the field feature triple as the original parameter of the compression algorithm and executing the compression algorithm to compress the field feature triple to generate a 256-bit fixed-length pattern fingerprint.

[0043] For example, the fixed fields of the message header are protocol version number: 1.0, message type: 0x01, data length: 128. The protocol version number: 1.0 is converted into a hexadecimal string as "31 2e 30", the message type: 0x01 is already in hexadecimal and remains unchanged as "01", the data length: 128 is converted into hexadecimal as "80", and after combination, the original byte encoding "31 2e 30 01 80" is obtained, thus obtaining the original byte encoding.

[0044] For example, the protocol version number: 1.0 is encoded using a hash algorithm (such as SHA-256), and the first 8 bits are taken as the semantic hash encoding: "a94a8fe5", thus obtaining the semantic hash encoding.

[0045] For example, encoding the field length value of the fixed fields of the message header to obtain the structural feature encoding, protocol version number length: 3 (the character length of 1.0), message type length: 1 (the byte length of 0x01), data length length: 1 (the byte length of 128), using a certain encoding method (such as simple numerical encoding): "03 01 01", thus obtaining the structural feature encoding.

[0046] For example, combine the above three encodings into a field feature triple ("31 2e 30 01 80", "a94a8fe5", "03 01 01").

[0047] For example, use a compression algorithm (such as SHA-256) to compress the field feature triple to generate a 256-bit fixed-length pattern fingerprint: SHA-256("31 2e 30 01 80" + "a94a8fe5" + "03 01 01") = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855".

[0048] In the embodiments of the present application, by combining and compressing multiple features (raw byte encoding, semantic hash encoding, and structural feature encoding) of the fixed fields of the message header into a fixed-length pattern fingerprint, the features of the data message can be represented efficiently and accurately. This method can not only quickly identify and distinguish data messages of different protocols, but also significantly reduce the complexity of data storage and processing. At the same time, the fixed-length pattern fingerprint is convenient for subsequent pattern matching and classification processing, improving the overall performance and scalability of the system, and is applicable to fast protocol identification and adaptation in large-scale data processing and complex protocol environments.

[0049] In some other embodiments of the present application, in the case where the matching result indicates a match failure, analyze the payload nested structure of the service data to be sent to determine the dispersion of JSON key-value pairs and the periodic characteristics of device data as structural entropy features; classify the structural entropy features according to a pre-trained lightweight classification model to obtain a classification result; perform fuzzy matching on the classification result with the fields of each original protocol in the preset original protocol library to find the original protocol that matches the fixed fields of the message header; create a field value conversion script between the fields in the data format of the original protocol and the fields in the preset default data format to obtain a two-way data conversion script between the data format of the original protocol and the preset default data format; store the two-way data conversion script between the data format of the original protocol and the preset default data format in the multi-protocol adapter.

[0050] For example, the payload part of the service data to be sent is as follows: { "device_id": "sensor_001", "timestamp": 1678000000, "readings": {"value": 25.5, "unit": "Celsius"}, {"value": 60.0, "unit": "Humidity"} , "status": { "code": 200, "message": "OK" } }。

[0051] Among them, the dispersion is calculated by analyzing the distribution of key-value pairs in the payload part of the service data to be sent. For example, count the number and distribution of keys at different levels. The root level has 3 keys (device_id, timestamp, readings, status), readings is an array containing 2 objects, each object has 2 keys (value and unit), and the status object has 2 keys (code and message). The distribution of these keys can be calculated. For example, the key distribution at the root level is relatively uniform, while the object structure in the readings array is relatively consistent. This distribution can be used to quantify the dispersion.

[0052] Use the sliding window technique to analyze its periodicity. The timestamp field represents the timestamp of data collection. By calculating the difference between adjacent timestamps, the periodicity of data collection can be detected. For example, if the differences between timestamps are roughly the same, it indicates that the data collection has periodic characteristics.

[0053] This application has pre-trained a lightweight classification model that can classify data packets according to structural entropy features (dispersion and periodicity features). Using the calculated dispersion and periodicity features as inputs, the model outputs a classification result. For example, the model may classify this data packet as a "sensor data packet".

[0054] Perform fuzzy matching between the classification result and the fields in the preset original protocol library. Assume there are multiple protocols in the original protocol library, and each protocol has its characteristic fields. Through fuzzy matching, find the original protocol that is most similar to the structure of this data packet. For example, the matching result may indicate that this data packet conforms to the characteristics of the "Modbus TCP" protocol.

[0055] According to the matched original protocol (Modbus TCP) and the preset default data format (assumed to be JSON format), create a field value conversion script. For example, the script may be as follows: function modbusToJson(data) { return { "device_id": data.device_id, "timestamp": data.timestamp, "sensor_readings": data.readings.map(reading =>({ "value": reading.value, "unit": reading.unit })), "status_code": data.status.code, "status_message": data.status.message }; }.

[0056] Store the conversion script created above in the multi - protocol adapter so that it can be directly used when processing similar data packets subsequently.

[0057] In the embodiments of the present application, even in the case of failed pattern matching, the type of data can be determined by analyzing the structural characteristics of the data (such as the dispersion of JSON key - value pairs and the periodic characteristics of device data), and a lightweight classification model is used for classification. Further, the corresponding original protocol is found through fuzzy matching, and the corresponding data conversion script is created. This method not only improves the fault - tolerance ability of the system, but also enhances the adaptability and scalability of the system, can effectively process unknown or non - standard data formats, ensure that data can be smoothly converted and transmitted between different protocols, and improve the overall stability and reliability of the system.

[0058] In some embodiments of the present application, the specific process of classifying the structural entropy features to obtain the classification result includes: quantifying the structural entropy features to obtain the dispersion value of JSON key - value pairs and the periodic intensity of device data time series; scaling the dispersion value and the periodic intensity of device data time series to the standardized range that can be processed by the model to obtain the standardized feature vector; inputting the standardized feature vector into the pre - trained lightweight classification model, and outputting the predicted probability distribution corresponding to each original protocol of the structural entropy features; obtaining the protocol label corresponding to the highest probability from the predicted probability distribution; using the protocol label corresponding to the highest probability as the classification result.

[0059] S103. Identify the second system to which the service data to be sent needs to flow; Wherein, in the business process, the second system is the target system that receives and processes the service data to be sent. It corresponds to the "first system" that sends data and conducts business collaborative processing.

[0060] In the embodiments of the present application, the second system for which the flow direction of the service data to be recognized and sent is required can ensure that the data is sent to the correct processing node, thereby realizing efficient collaborative work between different systems.

[0061] S104. When the data request format of the second system is not the preset default data format, convert the data format of the first service data into the data request format according to the multi-protocol adapter to obtain the second service data; In some embodiments of the present application, when the data request format of the second system is the preset default data format, it indicates that the data format of the data protocol used by the second system for business collaboration with the first system is the preset default data format. At this time, the first service data can be directly pushed to the client where the second system is deployed through the HTTP protocol.

[0062] In other embodiments of the present application, when the data request format of the second system is the preset default data format, it indicates that the data format of the data protocol used by the second system for business collaboration with the first system is not the preset default data format. At this time, it is necessary to convert the data format of the first service data into the data request format according to the multi-protocol adapter to obtain the second service data.

[0063] It should be noted that the conversion process is the same as the logic of converting the data format of the service data to be sent into the preset default data format in step S102, which will not be elaborated here. For the specific implementation logic, reference can be made to the specific implementation logic in step S102.

[0064] S105. Push the second service data to the client where the second system is deployed through the HTTP protocol.

[0065] Among them, the HTTP protocol is the HyperText Transfer Protocol, which is an application layer communication protocol used for data exchange between the client and the server. The second service data refers to the data that has been processed and converted and is ready to be sent to the second system. These data have been adapted to the data format required by the second system.

[0066] In some embodiments of the present application, the converted XML data (second service data) is sent to the client of the second system using the HTTP protocol. After receiving the HTTP request, the client of the second system parses the XML data, performs business collaboration, obtains the business processing result, and finally feeds back the business processing result to the server.

[0067] Further, the server receives the business processing result sent by the client that has deployed the second system; converts the data format of the business processing result into the data request format of the first system according to the multi-protocol adapter to obtain the final business processing result of the business processing request; and sends the final business processing result to the client that has deployed the first system.

[0068] For example, a businessperson creates a purchase order on the client that has deployed the first system, triggering an approval process. At this time, protocol adaptation is first performed: the integration engine receives data through the WebService protocol adapter and automatically parses the fields (such as order number, amount, supplier). Then data standardization: convert the format into the unified JSON Schema of the platform and extract the key fields (such as order_id, amount, supplier). Rule engine matching: according to the preset approval rules (such as multi-level approval is required when the amount > 100,000), call the process engine to generate approval nodes (Finance Department → Purchasing Director → General Manager), convert the JSON data into the RESTful API request format of the second system corresponding to the approval nodes (such as POST / approval), and push it to the client that has deployed the second system through the HTTP protocol.

[0069] For example Figure 2 as shown Figure 2 is a schematic diagram of the interaction scenario between the client and the server provided by this application. The client that has deployed the first system sends a business processing request to the server; the server receives the business processing request sent by the client that has deployed the first system. The business processing request is used to request the client that has deployed the second system to perform business process collaborative processing, and the business processing request carries the business data to be sent; in the case where the data format of the business data to be sent is not the preset default data format, the server converts the data format of the business data to be sent into the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-set auxiliary service node to obtain the first business data. The multi-protocol adapter includes data bidirectional conversion scripts between the data formats of different data protocols and the preset default data format; the server identifies the second system to which the business data to be sent needs to flow; in the case where the data request format of the second system is not the preset default data format, the server converts the data format of the first business data into the data request format according to the multi-protocol adapter to obtain the second business data; the server pushes the second business data to the client that has deployed the second system through the HTTP protocol.

[0070] In an embodiment of the present application, on the one hand, the multi - protocol adapter includes a data two - way conversion script between the data formats of different data protocols and a preset default data format. As an intermediate layer, the multi - protocol adapter uniformly processes protocol conversion. When a new system is accessed, only the adapter script needs to be configured, and there is no need to rewrite any code in the system, which greatly reduces the development workload, can avoid the development work of point - to - point docking, and can meet the business scenarios with high real - time requirements at the same time. On the other hand, the protocol is dynamically identified through a pre - trained lightweight classification model, enabling the model to adaptively identify new protocols, automatically generate new data conversion scripts and store them, and continuously enrich and optimize the functions of the multi - protocol adapter.

[0071] Please refer to Figure 3 , which is a schematic flowchart of a service processing method for multi - protocol adaptation provided by an embodiment of the present application, and is applied to a client. As Figure 3 shown, the method of the embodiment of the present application may include the following steps: S201, receive the second service data sent by the server; the second service data is obtained by the server converting the data format of the to - be - sent service data sent by the client deploying the first system according to the multi - protocol adapter; the multi - protocol adapter includes a data two - way conversion script between the data formats of different data protocols and a preset default data format; S202, generate a service process collaborative processing request according to the second service data; S203, store the service process collaborative processing request in a preset distributed message queue to asynchronously process the service process collaborative processing request and obtain a service processing result; the preset distributed message queue is a Kafka queue designed with a distributed architecture; S204, send the service processing result to the server.

[0072] In some embodiments, the service process collaborative processing request is asynchronously processed through the Kafka queue to obtain a service processing result, and the partitioning strategy ensures that high - priority orders (such as urgent purchases) are processed first. Status write - back: After the second system returns the approval result (approved / rejected), the engine converts the result format and writes it back to the server, and updates the transaction status in the Redis cluster.

[0073] In an embodiment of the present application, the message processing layer of the second system is designed with a distributed architecture, and a high - concurrency and low - latency message queue is built based on Apache Kafka to achieve the asynchronous processing ability of millions of messages per second, effectively coping with the scenario of massive data reporting from Internet of Things devices. Through the partitioning strategy and the dynamic load - balancing algorithm, it is ensured that the message processing delay is stable at the millisecond level.

[0074] In the embodiments of the present application, on the one hand, the multi - protocol adapter includes a data two - way conversion script between the data formats of different data protocols and a preset default data format. As an intermediate layer, the multi - protocol adapter uniformly processes protocol conversion. When a new system is accessed, only the adapter script needs to be configured, and there is no need to rewrite any code in the system, which greatly reduces the development workload, can avoid the development work of point - to - point docking, and can meet the business scenarios with high real - time requirements. On the other hand, the protocol is dynamically recognized through a pre - trained lightweight classification model, enabling the model to adaptively recognize new protocols, automatically generate new data conversion scripts and store them, and continuously enrich and optimize the functions of the multi - protocol adapter.

[0075] Please refer to Figure 4 , which is a schematic flowchart of a method for training a lightweight classification model provided by the embodiments of the present application. As Figure 4 shown, the method of the embodiments of the present application may include the following steps: S301, Extract protocol conversion logs from the multi - protocol adapter logs. The protocol conversion logs include discreteness values, periodicity intensities, and protocol type labels; In some embodiments of the present application, when the multi - protocol adapter processes data, it will record the detailed information of each protocol conversion into the multi - protocol adapter log file. These logs include discreteness values, periodicity intensities, and protocol type labels. When performing model training, extract protocol conversion logs from the multi - protocol adapter logs. The protocol conversion logs include discreteness values, periodicity intensities, and protocol type labels. Among them, the log content is, for example: 2024 - 12 - 16 10:00:00, Discreteness: 0.85, Periodicity: 0.92, Protocol:Modbus; 2024 - 12 - 16 10:01:00, Discreteness: 0.78, Periodicity: 0.88, Protocol:OPC UA; S302, Construct an initial training set according to the protocol conversion logs; In some embodiments of the present application, each sample in the initial training set includes a discreteness value, a periodicity intensity, and a protocol type label. For example: {"discreteness": 0.85, "periodicity": 0.92, "protocol": "Modbus"}, {"discreteness": 0.78, "periodicity": 0.88, "protocol": "OPC UA"}​ .

[0076] S303. Obtain the business system tags associated with the protocol of the initial training set; In some embodiments of the present application, for example, each protocol type is associated with a specific business system. For example, the Modbus protocol is commonly used in industrial automation systems, and OPC UA is used for enterprise-level industrial communication. Add these business system tags to the training set, for example: {"discreteness": 0.85, "periodicity": 0.92, "protocol": "Modbus", "business_system": "Industrial Automation"}, {"discreteness": 0.78, "periodicity": 0.88, "protocol": "OPC UA", "business_system": "Enterprise Communication"} .

[0077] S304. Perform business scenario weighting on the initial training set and the business system tags to obtain a set of feature vectors weighted by the business scenario; In some embodiments of the present application, assign weights to each sample according to the importance of the business scenario. For example, the industrial automation system may be more important than the enterprise-level communication system, so a higher weight is assigned to it, for example: {"discreteness": 0.85, "periodicity": 0.92, "protocol": "Modbus", "business_system": "Industrial Automation", "weight": 1.5}, {"discreteness": 0.78, "periodicity": 0.88, "protocol": "OPC UA", "business_system": "Enterprise Communication", "weight": 1.0} .

[0078] ​​S305. Group the feature vector sets weighted for the service scenario by protocol type, calculate the mean and standard deviation of each group, and perform within-group Z-score normalization to obtain the normalized feature vectors for the protocol cluster grouping. In some embodiments of the present application, group by protocol type, calculate the mean and standard deviation of each group, and perform Z-score normalization on the feature vectors. For example, for the Modbus protocol group, it is as follows: Mean Discreteness: 0.85, Mean Periodicity: 0.92; Std Discreteness: 0.05, Std Periodicity: 0.03.

[0079] The normalized feature vectors are: {"discreteness": 1.0, "periodicity": 1.0, "protocol": "Modbus"} .

[0080] S306. Create a lightweight classification model that can output the probability distribution of multiple protocols. The lightweight classification model includes an input layer and an output layer. The two nodes of the input layer correspond to the discreteness and periodicity intensity, and the output layer includes a Softmax probability distribution. For example Figure 5 As shown, the lightweight classification model includes an input layer with two nodes (corresponding to the discreteness and periodicity intensity), and the output layer uses the Softmax function to output the probability distribution of multiple protocols.

[0081] S307. Input the normalized feature vectors of the protocol cluster grouping into the lightweight classification model for model training, and output the model loss value. S308. Generate a pre-trained lightweight classification model when the model loss value reaches the minimum.

[0082] In some embodiments of the present application, when the model loss value does not reach the minimum, continue to perform the step of inputting the normalized feature vectors of the protocol cluster grouping into the lightweight classification model for model training until the model loss value reaches the minimum.

[0083] In the embodiments of the present application, the protocol is dynamically identified through the pre-trained lightweight classification model, enabling the model to adaptively identify new protocols, automatically generate new data conversion scripts and store them, and continuously enrich and optimize the functions of the multi-protocol adapter.

[0084] ​The following is an embodiment of the system of the present application, which can be used to execute the method embodiment of the present application. For details not disclosed in the system embodiment of the present application, please refer to the method embodiment of the present application.

[0085] Please refer to Figure 6 , which shows a schematic structural diagram of a multi-protocol adaptation service processing system provided by an exemplary embodiment of the present application. The multi-protocol adaptation service processing system can be implemented as all or part of an electronic device through software, hardware, or a combination of both. The system 1 includes a receiving module 10, a first conversion module 20, an identification module 30, a second conversion module 40, and a pushing module 50.

[0086] The receiving module 10 is configured to receive a service processing request sent by a client deploying a first system, where the service processing request is used to request a client deploying a second system to perform collaborative processing of a service process, and the service processing request carries service data to be sent; The first conversion module 20 is configured to, when the data format of the service data to be sent is not the preset default data format, convert the data format of the service data to be sent into the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-device service node, to obtain first service data; the multi-protocol adapter includes a data two-way conversion script between the data formats of different data protocols and the preset default data format; The identification module 30 is configured to identify the second system to which the service data to be sent needs to flow; The second conversion module 40 is configured to, when the data request format of the second system is not the preset default data format, convert the data format of the first service data into the data request format according to the multi-protocol adapter, to obtain second service data; The pushing module 50 is configured to push the second service data to the client deploying the second system through the HTTP protocol.

[0087] It should be noted that when the above-mentioned multi-protocol adaptation service processing system provided in the embodiment executes the multi-protocol adaptation service processing method, only the above-mentioned division of each functional module is used for illustration. In actual application, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the above-mentioned multi-protocol adaptation service processing system provided in the embodiment and the method embodiment of the multi-protocol adaptation service processing belong to the same concept, and the implementation process thereof is detailed in the method embodiment, which will not be elaborated here.

[0088] The serial numbers of the above embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments.

[0089] In an embodiment of the present application, on the one hand, the multi-protocol adapter includes a data bidirectional conversion script between the data formats of different data protocols and a preset default data format. As an intermediate layer, the multi-protocol adapter uniformly processes protocol conversion. When a new system is accessed, only the adapter script needs to be configured, and there is no need to rewrite any code in the system, which greatly reduces the development workload, can avoid the development work of point-to-point docking, and can meet the business scenarios with high real-time requirements at the same time. On the other hand, the protocol is dynamically identified through a pre-trained lightweight classification model, enabling the model to adaptively identify new protocols, automatically generate new data conversion scripts and store them, and continuously enrich and optimize the functions of the multi-protocol adapter.

[0090] The present application also provides a computer-readable medium, on which program instructions are stored. When the program instructions are executed by a processor, the business processing method of multi-protocol adaptation provided by each of the above method embodiments is implemented.

[0091] The present application also provides a computer program product containing instructions. When it runs on a computer, it causes the computer to execute the business processing method of multi-protocol adaptation provided by each of the above method embodiments.

[0092] Please refer to Figure 7 , which is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As Figure 7 shown, the electronic device 1000 may include: at least one processor 1001, at least one network interface 1004, a user interface 1003, a memory 1005, and at least one communication bus 1002.

[0093] Among them, the communication bus 1002 is used to realize the connection and communication between these components.

[0094] Among them, the user interface 1003 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 1003 may further include a standard wired interface and a wireless interface.

[0095] Among them, the network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).

[0096] Among them, the processor 1001 may include one or more processing cores. The processor 1001 connects various parts within the entire electronic device 1000 through various interfaces and lines. By running or executing instructions, programs, code sets, or instruction sets stored in the memory 1005, and by invoking data stored in the memory 1005, it performs various functions of the electronic device 1000 and processes data. Optionally, the processor 1001 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 1001 may integrate a combination of one or several of a central processing unit (CPU), a graphics processing unit (GPU), and a modem, etc. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 1001 and may be implemented separately by a single chip.

[0097] Among them, the memory 1005 may include random access memory (RAM) and may also include read-only memory. Optionally, the memory 1005 includes a non-transitory computer-readable storage medium. The memory 1005 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 1005 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store the data involved in the above-mentioned various method embodiments. Optionally, the memory 1005 may also be at least one storage system located far from the aforementioned processor 1001. As Figure 7 shown, the memory 1005, as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a service processing application program with multi-protocol adaptation.

[0098] In Figure 7In the electronic device 1000 shown, the user interface 1003 is mainly used to provide an interface for the user to input and obtain the data input by the user; while the processor 1001 can be used to call the multi-protocol adaptation service processing application program stored in the memory 1005 and specifically perform the following operations: Receive a service processing request sent by a client deploying the first system, where the service processing request is used to request a client deploying the second system to perform collaborative processing of the service process, and the service processing request carries the service data to be sent; In the case where the data format of the service data to be sent is not the preset default data format, convert the data format of the service data to be sent into the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-configured service node to obtain the first service data; the multi-protocol adapter includes a data two-way conversion script between the data formats of different data protocols and the preset default data format; Identify the second system to which the service data to be sent needs to flow; In the case where the data request format of the second system is not the preset default data format, convert the data format of the first service data into the data request format according to the multi-protocol adapter to obtain the second service data; Push the second service data to the client deploying the second system through the HTTP protocol.

[0099] In one embodiment, the processor 1001 also performs the following operations: Receive the service processing result sent by the client deploying the second system; Convert the data format of the service processing result into the data request format of the first system according to the multi-protocol adapter to obtain the final service processing result of the service processing request; Send the final service processing result to the client deploying the first system.

[0100] In one embodiment, the processor 1001 also performs the following operations: Monitor the service status of the preset main service node through a preset health detection mechanism; In the case of a node outage in the service status, switch the traffic to the pre-configured service node through the Kubernetes cluster.

[0101] In one embodiment, when the processor 1001 executes the conversion of the data format of the service data to be sent into the preset default data format to obtain the first service data, it specifically performs the following operations: Extract the fixed fields of the message header of the service data to be sent; Establish a pattern fingerprint according to the fixed fields of the message header; Perform pattern matching between the pattern fingerprint and the feature templates set for different data protocols to obtain a matching result; When the matching result indicates a successful match, obtain the target feature template that successfully matches the pattern fingerprint; Determine the target data protocol corresponding to the target feature template; From the data bidirectional conversion scripts between the data formats of different data protocols included in the multi-protocol adapter and the preset default data format, obtain the target data bidirectional conversion script between the data format of the target data protocol and the preset default data format; Convert the data format of the service data to be sent into the preset default data format through the target data bidirectional conversion script to obtain the first service data.

[0102] In one embodiment, when the processor 1001 executes to establish a pattern fingerprint according to the fixed fields of the packet header, it specifically performs the following operations: Convert the fixed fields of the packet header into a hexadecimal string to obtain the original byte encoding; Encode the text fields in the fixed fields of the packet header to obtain the semantic hash encoding; Encode the field length values of the fixed fields of the packet header to obtain the structural feature encoding; Combine the original byte encoding, the semantic hash encoding, and the structural feature encoding to obtain a field feature triple; Use the field feature triple as the original parameter of the compression algorithm and execute the compression algorithm to compress the field feature triple to generate a 256-bit fixed-length pattern fingerprint.

[0103] In one embodiment, the processor 1001 also performs the following operations: When the matching result indicates a failed match, analyze the payload nested structure of the service data to be sent to determine the dispersion of JSON key-value pairs and the periodic characteristics of device data as the structural entropy characteristics; Classify the structural entropy characteristics according to a pre-trained lightweight classification model to obtain a classification result; Perform fuzzy matching between the classification result and the fields of each original protocol in the preset original protocol library to find the original protocol that matches the fixed fields of the packet header; Create a field value conversion script between the fields in the data format of the original protocol and the fields in the preset default data format to obtain a data bidirectional conversion script between the data format of the original protocol and the preset default data format; Store the data bidirectional conversion script between the data format of the original protocol and the preset default data format in the multi-protocol adapter.

[0104] In one embodiment, when the processor 1001 classifies the structural entropy features to obtain a classification result, it specifically performs the following operations: Quantify the structural entropy features to obtain the dispersion value of the JSON key-value pair and the periodicity intensity of the device data time series; Scale the dispersion value and the periodicity intensity of the device data time series to the standardized range that can be processed by the model to obtain a standardized feature vector; Input the standardized feature vector into a pre-trained lightweight classification model, and output the predicted probability distribution corresponding to each original protocol of the structural entropy features; Obtain the protocol label corresponding to the highest probability from the predicted probability distribution; Use the protocol label corresponding to the highest probability as the classification result.

[0105] In one embodiment, when the processor 1001 executes to generate a pre-trained lightweight classification model, it specifically performs the following operations: Extract protocol conversion logs from the multi-protocol adapter logs. The protocol conversion logs include dispersion values, periodicity intensities, and protocol type labels; Construct an initial training set according to the protocol conversion logs; Obtain the business system labels associated with the protocols in the initial training set; Perform business scenario weighting on the initial training set and the business system labels to obtain a feature vector set weighted by business scenarios; Group the feature vector set weighted by business scenarios according to the protocol type, calculate the mean and standard deviation of each group of features, and perform within-group Z-score normalization to obtain a normalized feature vector grouped by protocol clusters; Create a lightweight classification model that can output a multi-protocol probability distribution. The lightweight classification model includes an input layer and an output layer. The 2 nodes of the input layer correspond to dispersion and periodicity intensity, and the output layer includes a Softmax probability distribution; Input the normalized feature vector grouped by protocol clusters into the lightweight classification model for model training, and output the model loss value; Generate a pre-trained lightweight classification model when the model loss value reaches the minimum.

[0106] In the embodiments of the present application, on the one hand, the multi-protocol adapter includes a data bidirectional conversion script between the data formats of different data protocols and a preset default data format. As an intermediate layer, the multi-protocol adapter uniformly processes protocol conversion. When a new system is accessed, only the adapter script needs to be configured, and there is no need to rewrite any code in the system, which greatly reduces the development workload, can avoid the development work of point-to-point docking, and can meet the business scenarios with high real-time requirements at the same time. On the other hand, the protocol is dynamically recognized through a pre-trained lightweight classification model, enabling the model to adaptively recognize new protocols, automatically generate new data conversion scripts and store them, and continuously enrich and optimize the functions of the multi-protocol adapter.

[0107] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The program for business processing of multi-protocol adaptation can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the storage medium of the program for business processing of multi-protocol adaptation can be a magnetic disk, an optical disk, a read-only memory, or a random access memory, etc.

[0108] The above-disclosed are only the preferred embodiments of the present application. Of course, the scope of the rights of the present application cannot be limited thereby. Therefore, equivalent changes made according to the claims of the present application still fall within the scope covered by the present application.

Claims

1. A service processing method for multi - protocol adaptation, characterized in that, Applied to the server side, the method includes: Receiving a service processing request sent by a client that has deployed the first system, where the service processing request is used to request a client that has deployed the second system to perform collaborative processing of a service process, and the service processing request carries service data to be sent; In the case where the data format of the service data to be sent is not the preset default data format, converting the data format of the service data to be sent to the preset default data format according to a multi-protocol adapter stored in the preset main service node or the pre-configured service node to obtain first service data; the multi-protocol adapter includes data bidirectional conversion scripts between data formats of different data protocols and the preset default data format; Identifying the second system to which the service data to be sent needs to flow; In the case where the data request format of the second system is not the preset default data format, converting the data format of the first service data to the data request format according to the multi-protocol adapter to obtain second service data; Pushing the second service data to the client that has deployed the second system through the HTTP protocol.

2. The method according to claim 1, wherein The method further includes: Receiving a service processing result sent by a client that has deployed the second system; Converting the data format of the service processing result to the data request format of the first system according to the multi-protocol adapter to obtain the final service processing result of the service processing request; Sending the final service processing result to the client that has deployed the first system.

3. The method according to claim 1, characterized in that, The method further includes: Monitoring the service status of the preset main service node through a preset health detection mechanism; In the case where the service status has a node outage, switching the traffic to the pre-configured service node through the Kubernetes cluster.

4. The method according to claim 1, characterized in that, Feature templates are pre-set for the different data protocols; The converting the data format of the service data to be sent to the preset default data format to obtain first service data includes: Extracting the fixed fields of the message header of the service data to be sent; Establishing a pattern fingerprint according to the fixed fields of the message header; Performing pattern matching between the pattern fingerprint and the feature templates set for the different data protocols to obtain a matching result; In the case where the matching result indicates a successful match, obtaining a target feature template that matches the pattern fingerprint successfully; Determining the target data protocol corresponding to the target feature template; Obtaining a target data bidirectional conversion script between the data format of the target data protocol and the preset default data format from the data bidirectional conversion scripts between the data formats of different data protocols and the preset default data format included in the multi-protocol adapter; Converting the data format of the service data to be sent to the preset default data format through the target data bidirectional conversion script to obtain first service data.

5. The method according to claim 4, wherein The establishing a pattern fingerprint according to the fixed fields of the message header includes: Converting the fixed fields of the message header to a hexadecimal string to obtain the original byte encoding; Encoding the text fields in the fixed fields of the message header to obtain a semantic hash encoding; Encoding the field length values of the fixed fields of the message header to obtain a structural feature encoding; Combine the original byte encoding, the semantic hash encoding, and the structural feature encoding to obtain a field feature triple; Use the field feature triple as the original parameter of a compression algorithm and execute the compression algorithm to compress the field feature triple into a 256-bit fixed-length pattern fingerprint.

6. The method according to claim 4, wherein The method further includes: In the case where the matching result indicates a match failure, analyze the payload nested structure of the service data to be sent to determine the dispersion of JSON key-value pairs and the periodic characteristics of device data as structural entropy features; Classify the structural entropy features according to a pre-trained lightweight classification model to obtain a classification result; Perform fuzzy matching between the classification result and the fields of each original protocol in a preset original protocol library to find the original protocol that matches the fixed fields of the message header; Create a field value conversion script between the fields in the data format of the original protocol and the fields in a preset default data format to obtain a two-way data conversion script between the data format of the original protocol and the preset default data format; Store the two-way data conversion script between the data format of the original protocol and the preset default data format in the multi-protocol adapter.

7. The method according to claim 6, wherein The classifying the structural entropy features to obtain a classification result includes: Quantify the structural entropy features to obtain the dispersion value of JSON key-value pairs and the periodic intensity of device data time series; Scale the dispersion value and the periodic intensity of device data time series to the standardized range that can be processed by the model to obtain a standardized feature vector; Input the standardized feature vector into a pre-trained lightweight classification model and output the predicted probability distribution corresponding to each original protocol of the structural entropy features; Obtain the protocol label corresponding to the highest probability from the predicted probability distribution; Use the protocol label corresponding to the highest probability as the classification result.

8. The method according to claim 7, wherein Generate a pre-trained lightweight classification model according to the following steps, including: Extract protocol conversion logs from the multi-protocol adapter logs, where the protocol conversion logs include dispersion values, periodic intensities, and protocol type labels; Construct an initial training set according to the protocol conversion logs; Obtain the business system label associated with the protocol of the initial training set; Perform business scenario weighting on the initial training set and the business system label to obtain a business scenario weighted feature vector set; Group the business scenario weighted feature vector set by protocol type, calculate the mean and standard deviation of each group of features, and perform within-group Z-score normalization to obtain a normalized feature vector for protocol cluster grouping; Create a lightweight classification model that can output a multi-protocol probability distribution. The lightweight classification model includes an input layer and an output layer. The 2 nodes of the input layer correspond to dispersion and periodic intensity, and the output layer includes a Softmax probability distribution; Input the normalized feature vector for protocol cluster grouping into the lightweight classification model for model training and output the model loss value; Generate a pre-trained lightweight classification model when the model loss value reaches the minimum.

9. A service processing method for multi - protocol adaptation, characterized in that, Applied to a client where a second system is deployed, the method includes: Receive the second service data sent by the server; the second service data is obtained by the server converting the data format of the to-be-sent service data sent by the client where the first system is deployed according to the multi-protocol adapter; the multi-protocol adapter includes data two-way conversion scripts between the data formats of different data protocols and the preset default data format; Generate a business process collaborative processing request according to the second service data; Store the business process collaborative processing request in a preset distributed message queue to asynchronously process the business process collaborative processing request to obtain a business processing result; the preset distributed message queue is a Kafka queue designed with a distributed architecture; Send the business processing result to the server.

10. A service processing system for multi - protocol adaptation, characterized in that, The system includes: A receiving module, configured to receive a business processing request sent by a client where the first system is deployed, the business processing request is used to request a client where the second system is deployed to perform business process collaborative processing, and the business processing request carries to-be-sent service data; A first conversion module, configured to, when the data format of the to-be-sent service data is not the preset default data format, convert the data format of the to-be-sent service data into the preset default data format according to the multi-protocol adapter stored in the preset main service node or the pre-configured service node to obtain first service data; the multi-protocol adapter includes data two-way conversion scripts between the data formats of different data protocols and the preset default data format; An identification module, configured to identify the second system to which the to-be-sent service data needs to flow; A second conversion module, configured to, when the data request format of the second system is not the preset default data format, convert the data format of the first service data into the data request format according to the multi-protocol adapter to obtain second service data; A push module, configured to push the second service data to the client where the second system is deployed through the HTTP protocol.

Images