Microservice data processing methods, devices, electronic equipment, and media

Abstract

This application discloses a microservice data processing method, apparatus, electronic device, and storage medium applied to a microservice processing platform. The method includes: collecting registration attributes and data characteristics of each microservice; classifying the microservices and assigning a unique data identifier to each microservice; deploying lightweight adaptation proxy nodes for registry centers of different registration types and establishing an encrypted communication link between the lightweight adaptation proxy nodes and the microservice processing platform; collecting raw data of the microservices within the corresponding registry center through the lightweight adaptation proxy nodes, and performing microservice association and format standardization processing on the raw data based on the unique data identifier to obtain standardized microservice data; writing the standardized microservice data into the distributed database of the microservice processing platform, and performing hierarchical centralized processing of the standardized microservice data according to the classification results of the microservices.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a microservice data processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the widespread application of microservice architecture in fields such as the Internet, finance, and government and enterprise informatization, business systems are broken down into multiple independently deployed and run microservices. The registration information of each microservice is usually deployed in different registration types of registry centers according to development needs. Common registry center types include Zookeeper, Eureka, Nacos, etc.

[0003] In existing technologies, for microservice data processing with multiple registration centers, interface adaptation is typically used to connect to registration centers of different registration types in order to obtain microservice data and perform centralized processing. However, this approach still has several technical drawbacks in practical applications: First, the lack of a unified identity for each microservice leads to data confusion and inconsistencies between microservice registration centers, making accurate data traceability and management difficult. Second, direct data interaction with the registration center via the adapter interface consumes significant resources, potentially causing delays in data response when the registration center handles a large volume of microservice registration information. Third, the uniform processing of acquired microservice data, without tiered processing based on business attributes and data characteristics, results in wasted computing resources and reduced data processing efficiency. Fourth, during microservice monitoring, the method of directly collecting all data is often used without fine-grained data slicing, and the analysis is limited to a single dimension, making it difficult to accurately identify potential problems during microservice operation. Fifth, the low compatibility between the microservice's operating environment and the adapter plugin leads to stuttering and compatibility issues in bidirectional data interaction between the platform and the microservice's operating environment, affecting the efficiency of microservice business component calls.

[0004] Meanwhile, in existing technologies, if microservice registration information from different registry centers is uniformly migrated to a single registry center, the registration information of each microservice needs to be manually deleted and redeployed one by one. This not only increases the workload of staff, but also easily leads to the risk of data loss and leakage during the data migration process. On the other hand, if the interfaces of each registry center are directly adapted without standardizing the collected raw data, it will lead to data redundancy and format conflicts when microservice data of different formats and dimensions are stored in a centralized manner, which will affect the subsequent data analysis and use.

[0005] In summary, existing technologies suffer from problems such as chaotic microservice data management under multiple registration centers, low data processing efficiency, significant impact on registration center performance, and poor microservice operation monitoring and adaptation, making it difficult to meet the business needs of unified data processing, refined management, and efficient monitoring under large-scale microservice architectures. Summary of the Invention

[0006] This application provides a microservice data processing method, electronic device, apparatus, and storage medium, aiming to solve the technical problems in the prior art of chaotic microservice data management, low processing efficiency, significant impact on the performance of the registration center, and poor microservice operation adaptation and monitoring analysis under multiple registration centers.

[0007] In a first aspect, embodiments of this application provide a microservice data processing method, applied to a microservice processing platform, comprising: Collect the registration attributes and data characteristics of each microservice, classify the microservices, and assign a unique data identifier to each microservice; Deploy lightweight adaptation proxy nodes for registry centers of different registration types, and establish encrypted communication links between the lightweight adaptation proxy nodes and the microservice processing platform; The lightweight adaptable proxy node collects the original data of the microservices in the corresponding registry center, and completes the microservice association and format standardization processing of the original data based on the unique data identifier to obtain standardized microservice data. The standardized microservice data is written into the distributed database of the microservice processing platform, and the standardized microservice data is processed in a hierarchical and centralized manner according to the classification results of the microservices. The distributed database contains standardized microservice data corresponding to multiple microservices and unique data identifiers.

[0008] Optionally, in some embodiments of this application, the registration center includes the unified registration center of the microservice processing platform and the existing registration center of the microservice; before collecting the registration attributes and data characteristics of each microservice, the method further includes: If the microservice does not have a corresponding registry center, a dedicated registration partition is created in the unified registry center based on the data characteristics of the microservice, and the registration attributes of the microservice are deployed and bound to the assigned unique data identifier; If the microservice already has a corresponding registry center, then the registration attributes of the microservice in the existing registry center are extracted, and the classification and allocation of unique data identifiers are completed in combination with the microservice data characteristics.

[0009] Optionally, in some embodiments of this application, before collecting the registration attributes and data characteristics of each microservice, the following steps are further included: If the microservice already has a corresponding registry center, its original registration data will be synchronized to the temporary cache area of ​​the microservice processing platform through the lightweight adaptation proxy node. The registration information of the microservice deployed in the existing corresponding registry center is deleted. The registration data based on the temporary cache is redeployed in the dedicated registration partition of the unified registry center and bound to the unique data identifier of the microservice.

[0010] Optionally, in some embodiments of this application, after writing the standardized microservice data into the distributed database of the microservice processing platform and performing hierarchical centralized processing of the standardized microservice data according to the classification results of the microservices, the method further includes: Identify the runtime dependency characteristics of the microservice, and call the adaptation plugin that matches the runtime dependency characteristics through the microservice adaptation engine of the microservice processing platform; When the microservice starts up and runs, the adapter plugin enables bidirectional data interaction between the microservice processing platform and the microservice runtime environment to invoke the business components of the microservice.

[0011] Optionally, in some embodiments of this application, after the microservice starts running and, through the adapter plugin, enables bidirectional data interaction between the microservice processing platform and the microservice runtime environment to invoke the business components of the microservice, the method further includes: Collect all monitoring data during the operation of the microservice, and slice the all monitoring data according to the preset collection dimensions to obtain sliced ​​monitoring data; Perform correlation and aggregation analysis on slice monitoring data within a preset time window to obtain microservice operation analysis results; The microservice operation analysis results are bound to the unique data identifier of the corresponding microservice and then stored in the distributed database.

[0012] Optionally, in some embodiments of this application, the collection of full monitoring data during the operation of the microservice includes: The full monitoring data of the microservice runtime is written to the distributed message queue of the microservice processing platform in real time, and the distributed message queue is partitioned and stored according to the unique data identifier of the microservice. Monitoring data from each partition in the distributed message queue is read concurrently using multiple threads and written into the time-series data storage system of the microservice processing platform.

[0013] Optionally, in some embodiments of this application, the step of performing correlation and aggregation analysis on slice monitoring data within a preset time window to obtain microservice operation analysis results includes: The sliced ​​monitoring data is sequentially processed to remove abnormal data and normalize data to obtain standardized monitoring data. The standardized monitoring data is aggregated and processed by a multi-dimensional visualization engine to obtain structured statistical report data and visualized trend graph data. The microservice operation analysis results are obtained by combining the quantitative indicators of the statistical report data and the changing characteristics of the trend graph data.

[0014] Secondly, embodiments of this application provide a microservice data processing apparatus, applied to a microservice processing platform, comprising: The data collection module is used to collect the registration attributes and data characteristics of each microservice, classify the microservices, and assign a unique data identifier to each microservice. A module is established to deploy lightweight adaptation proxy nodes for registry centers of different registration types, and to establish an encrypted communication link between the lightweight adaptation proxy nodes and the microservice processing platform. The processing module is used to collect the original data of the corresponding microservices in the registry center through the lightweight adaptation proxy node, and complete the microservice association and format standardization processing of the original data based on the unique data identifier to obtain standardized microservice data. The standardized microservice data is written into the distributed database of the microservice processing platform, and the standardized microservice data is processed in a hierarchical and centralized manner according to the classification results of the microservices. The distributed database contains standardized microservice data corresponding to multiple microservices and unique data identifiers.

[0015] Accordingly, this application also provides an electronic device, including a memory, a processor, and a processor program stored in the memory and executable on the processor, wherein the processor executes the program as described in any of the methods above.

[0016] This application also provides a storage medium storing a processor program that, when executed by a processor, implements any of the methods described above.

[0017] This application provides a microservice data processing method, apparatus, electronic device, and storage medium applied to a microservice processing platform. It collects the registration attributes and data characteristics of each microservice, classifies the microservices, and assigns a unique data identifier to each microservice. Next, lightweight adaptation proxy nodes are deployed for registry centers of different registration types, and an encrypted communication link is established between the lightweight adaptation proxy nodes and the microservice processing platform. Then, the original data of the corresponding microservices in the registry center is collected through the lightweight adaptation proxy nodes, and microservice association and format standardization processing of the original data are completed based on the unique data identifiers to obtain standardized microservice data. Finally, the standardized microservice data is written into the distributed database of the microservice processing platform, and hierarchical centralized processing of the standardized microservice data is performed according to the classification results of the microservices. The distributed database contains standardized microservice data and unique data identifiers corresponding one-to-one with multiple microservices. In the microservice data processing scheme provided in this application, by assigning a unique data identifier to each microservice, accurate association and traceability of microservice data are achieved, solving the problem of multiple The system addresses the issue of disorganized data management within the registry center. By deploying lightweight, adaptable proxy nodes, it enables data interaction between the registry center and the platform, avoiding the performance overhead of direct platform-to-registration interaction and enhancing data transmission security through encrypted communication links. It standardizes the format of raw microservice data, eliminating data format conflicts between different registry centers. Combined with microservice classification results, it performs hierarchical and centralized processing, improving data processing efficiency and reducing unnecessary consumption of computing resources. By identifying microservice runtime dependency characteristics and invoking matching adaptable plugins, it achieves efficient bidirectional data interaction between the platform and the microservice runtime environment, ensuring stable calls to business components. It performs slice processing and multi-dimensional correlation aggregation analysis on full monitoring data of microservice operation, accurately identifying potential problems during microservice operation and providing precise data for microservice configuration optimization and troubleshooting. Furthermore, it creates dedicated registration partitions in the unified registry center for microservices without a registry center and provides flexible data synchronization and migration solutions for microservices with existing registry centers, reducing manual workload and mitigating data migration risks. Overall, this application achieves unified, efficient, and refined processing of microservice data under multiple registration centers, as well as precise adaptation and comprehensive monitoring of microservice operation, and is suitable for business scenarios with large-scale microservice architectures. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating the microservice data processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of the microservice data processing device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0021] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0022] The microservice data processing method provided in this application is applied to a microservice processing platform. The microservice processing platform is an integrated data processing and operation management platform designed for large-scale microservice architecture. It has built-in core functional components such as a unified registration center, a lightweight adaptation proxy node management module, a microservice adaptation engine, a distributed database, a temporary cache, a distributed message queue, a time-series data storage system, and a multi-dimensional visualization engine. The components work together to realize the collection, processing, storage, adaptation, and monitoring and analysis of microservice data. The unified registry center provides registration partition deployment services for microservices without corresponding registry centers, supporting the creation of dedicated registration partitions based on microservice data characteristics to achieve categorized storage of registration information. The lightweight adaptation proxy node management module deploys and manages lightweight adaptation proxy nodes for registry centers of different registration types, establishing and maintaining encrypted communication links between proxy nodes and the platform. The microservice adaptation engine stores adaptation plugins that match the runtime dependency characteristics of various microservices, enabling fast plugin invocation and loading. The distributed database is preferably a distributed storage system such as HBase or ClickHouse that supports massive data storage and efficient retrieval, used to store standardized microservice data, unique microservice data identifiers, runtime analysis results, etc., supporting accurate data traceability based on unique data identifiers. The temporary cache uses Redis. High-performance caching technologies are used for temporary data storage during the migration of microservice registration information, ensuring the integrity of data migration. Distributed message queues are preferably high-throughput, highly available message middleware such as Kafka and RocketMQ, used for real-time writing and partitioned storage of microservice monitoring data. Time-series data storage systems are preferably storage systems designed specifically for time-series data, such as InfluxDB and Prometheus, used to store full monitoring data of microservice operation and support efficient querying by time dimension. A multi-dimensional visualization engine is used to aggregate and visualize standardized monitoring data, generating statistical report data and trend graph data.

[0023] The microservice registration attributes mentioned in this application include, but are not limited to, basic registration information such as the microservice's service name, network address, deployment port, version number, affiliated business system, and responsible person information; data characteristics include, but are not limited to, the microservice's data transmission format, data size, data update frequency, and business data type (such as transaction data, log data, and user data); the unique data identifier is a globally unique identifier generated based on the microservice registration attributes and data characteristics, which can be generated using UUID, snowflake algorithm, etc., and can embed microservice classification information to facilitate rapid data classification and retrieval; the lightweight adaptation proxy node is a lightweight data interaction component deployed on the registration center side, which has low system resource consumption, basic functions of data collection, format conversion, and encrypted transmission, and does not participate in the core business logic of the registration center, thus avoiding impact on the performance of the registration center; runtime dependency feature package. This includes, but is not limited to, the environmental characteristics required for microservice operation, such as the microservice runtime framework type, operating system version, middleware dependencies, interface protocol type, and resource consumption requirements; the adaptation plugins are plug-in components in the form of software development kits (SDKs), which match the microservice runtime dependency characteristics one by one, realizing protocol adaptation, data interaction adaptation, and resource scheduling adaptation between the microservice processing platform and the microservice runtime environment; the full monitoring data includes, but is not limited to, comprehensive monitoring data such as CPU utilization, memory usage, disk I / O, network throughput, interface response time, business processing volume, and exception error information during microservice runtime; the collection dimensions include, but are not limited to, time dimension, resource dimension, business dimension, and interface dimension, which are used to perform fine-grained slicing of the full monitoring data; the time window is the monitoring data analysis period preset by the user according to business needs, such as 5 minutes, 10 minutes, 1 hour, etc., which supports dynamic adjustment.

[0024] This application provides a microservice data processing method, apparatus, server, and computer-readable storage medium, which will be described in detail below.

[0025] In the embodiments of the microservice data processing method of this application, a microservice data processing device is used as the execution subject. For simplification and ease of description, this execution subject will be omitted in subsequent method embodiments. The microservice data processing device is applied to a server. The method includes: collecting the registration attributes and data characteristics of each microservice; classifying the microservices and assigning a unique data identifier to each microservice; deploying lightweight adaptation proxy nodes for registration centers of different registration types and establishing an encrypted communication link between the lightweight adaptation proxy nodes and the microservice processing platform; collecting the original data of the microservices in the corresponding registration center through the lightweight adaptation proxy nodes, and completing the microservice association and format standardization processing of the original data based on the unique data identifier to obtain standardized microservice data; writing the standardized microservice data into the distributed database of the microservice processing platform, and performing hierarchical centralized processing of the standardized microservice data according to the classification results of the microservices. The distributed database contains standardized microservice data and unique data identifiers corresponding one-to-one with multiple microservices.

[0026] This application provides a microservice data processing method, which can be executed by an electronic device or a server. This application example illustrates the microservice data processing method executed by an electronic device. The electronic device includes a touchscreen display and a processor. The touchscreen display is used to present a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. When the user operates the GUI through the touchscreen display, the GUI can control the local content of the electronic device in response to the received operation commands, or it can control the content on the server side in response to the received operation commands.

[0027] The microservice data processing solution provided in this application achieves precise association and traceability of microservice data by assigning a unique data identifier to each microservice, solving the problem of chaotic data management under multiple registration centers. It enables data interaction between the registration center and the platform by deploying lightweight adaptable proxy nodes, avoiding the performance overhead of the platform directly connecting to the registration center, while encrypting the communication link to improve data transmission security. It standardizes the format of raw microservice data, eliminating data format conflicts between different registration centers, and performs hierarchical centralized processing based on microservice classification results, improving data processing efficiency and reducing the ineffective consumption of computing resources. By identifying the runtime dependency characteristics of microservices and calling matching adaptable plugins, it achieves efficient bidirectional data interaction between the platform and the microservice runtime environment, ensuring stable calls to business components. It performs slice processing and multi-dimensional correlation aggregation analysis on the full monitoring data of microservice operation, accurately uncovering potential problems in the microservice operation process and providing precise basis for microservice configuration optimization and fault diagnosis. Furthermore, it creates a dedicated registration partition in the unified registration center for microservices without a registration center, and provides flexible solutions for data synchronization and migration for microservices with existing registration centers, reducing both manual workload and data migration risks. Overall, this application achieves unified, efficient, and refined processing of microservice data under multiple registration centers, as well as precise adaptation and comprehensive monitoring of microservice operation, and is suitable for business scenarios with large-scale microservice architectures.

[0028] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the priority of the embodiments.

[0029] A microservice data processing method includes: collecting registration attributes and data characteristics of each microservice; classifying the microservices and assigning a unique data identifier to each microservice; deploying lightweight adaptation proxy nodes for registry centers of different registration types and establishing an encrypted communication link between the lightweight adaptation proxy nodes and the microservice processing platform; collecting raw data of the corresponding microservices in the registry center through the lightweight adaptation proxy nodes, and performing microservice association and format standardization processing on the raw data based on the unique data identifier to obtain standardized microservice data; writing the standardized microservice data into the distributed database of the microservice processing platform, and performing hierarchical centralized processing on the standardized microservice data according to the classification results of the microservices, wherein the distributed database contains standardized microservice data and unique data identifiers corresponding one-to-one with multiple microservices.

[0030] Please see Figure 1 , Figure 1 This application provides a flowchart illustrating the microservice data processing method. The specific flow of this microservice data processing method is as follows: S101. Collect the registration attributes and data characteristics of each microservice, classify the microservices, and assign a unique data identifier to each microservice.

[0031] In application, the microservice processing platform first collects the registration attributes and data characteristics of all microservices to be processed through various methods such as network scanning, manual entry, and data synchronization with the registry center. During the collection process, the integrity and accuracy of the data must be ensured. For microservice data that is not collected completely, the platform will issue a data completion reminder, and staff will supplement the relevant information before proceeding with subsequent processing.

[0032] After data collection, the platform categorizes microservices based on preset microservice classification rules. These rules can be customized by staff according to business needs and technical characteristics. For example, microservices can be categorized by business domain (transaction, user, risk control, logs, etc.), by data processing type (real-time processing, offline processing), by resource consumption level (high, medium, low), or by registry type (Zookeeper registration, Eureka registration, etc.). The classification rules support multi-dimensional combinations; for instance, they can be categorized simultaneously by business domain and resource consumption level, enabling refined management of microservices.

[0033] After classifying microservices, the platform assigns a unique data identifier to each microservice. This identifier is unique globally within the microservice processing platform and is associated with the microservice's registration attributes, data characteristics, and classification results, stored in the platform's distributed database. The unique data identifier can be generated using the Snowflake algorithm, which generates a 64-bit globally unique ID. This ID can embed information such as the microservice's classification code and generation time, ensuring both uniqueness and facilitating rapid identification of the microservice's basic information. Alternatively, a 32-bit unique string can be generated using UUIDs. This method is simple to implement, does not rely on a central node, and is suitable for scenarios with a large number of microservices. After allocation, the platform binds the unique data identifier to the microservice's registration attributes and data characteristics, forming a basic information profile for the microservice, providing a foundation for subsequent data processing and correlation analysis.

[0034] The core purpose of this step is to establish a unique identity for each microservice, enabling classified management of microservices and solving the problems of chaotic data association and difficulty in tracing the source of microservices under multiple registration centers in existing technologies. At the same time, it lays the foundation for subsequent hierarchical data processing and refined monitoring and analysis.

[0035] S102. Deploy lightweight adaptation proxy nodes for registration centers of different registration types, and establish an encrypted communication link between the lightweight adaptation proxy nodes and the microservice processing platform.

[0036] In the application, for the different registration types of the registration center where the microservice to be processed resides, the microservice processing platform deploys a lightweight adaptation proxy node for each registration center through the lightweight adaptation proxy node management module. The proxy node is deployed on the local server of the registration center or the nearest edge node, and interacts with the registration center locally. It consumes very little system resources such as CPU and memory, and will not have any impact on the core business logic and running performance of the registration center.

[0037] The lightweight, adaptable proxy node possesses registry type adaptation capabilities. It can automatically load the corresponding adaptation driver based on the registry type (Zookeeper, Eureka, Nacos, etc.), achieving seamless integration with the registry. This eliminates the need for staff to develop separate adaptation programs for different registry types, reducing the workload of technical integration. The core function of the proxy node is data collection and encrypted transmission. It is only responsible for collecting raw data from microservices from the registry and transmitting the encrypted data to the microservice processing platform. It does not participate in core operations such as microservice registration, discovery, and decommissioning in the registry, ensuring the operational stability of the registry.

[0038] After deploying the lightweight, adaptable proxy nodes, an encrypted communication link is established between the microservice processing platform and the proxy nodes. Encryption methods employed include, but are not limited to, SSL / TLS encryption, AES symmetric encryption, and RSA asymmetric encryption to ensure data security during transmission and prevent data theft or tampering. The encrypted communication link is bidirectional. On one hand, the proxy nodes can encrypt and transmit the collected raw microservice data to the platform; on the other hand, the platform can encrypt and transmit control commands (such as data collection frequency adjustment and registration information synchronization commands) to the proxy nodes, enabling remote management of the proxy nodes by the platform. Simultaneously, the platform monitors the encrypted communication link in real time. If the link is interrupted or abnormal, the platform will immediately issue an alarm and attempt automatic reconnection to ensure the continuity and stability of data transmission.

[0039] The core objective of this step is to achieve "isolated" data interaction between the registry center and the microservice processing platform by using a lightweight, adaptable proxy node. This avoids the platform directly connecting to the registry center and thus limiting its performance. At the same time, it enhances the security of data transmission by using an encrypted communication link, thus solving the problems of performance loss in the registry center and high data transmission security risks caused by direct interface connection in existing technologies.

[0040] S103. Collect the original data of the corresponding microservices in the registry center through the lightweight adaptation proxy node, and complete the microservice association and format standardization processing of the original data based on the unique data identifier to obtain standardized microservice data.

[0041] In the application, the microservice processing platform sends data collection instructions to lightweight adapter nodes via an encrypted communication link. The instructions include information such as the list of microservices to be collected, the collection frequency, and the data collection range. The adapter nodes collect the raw data of the microservices from the corresponding registry center according to the instructions. The raw data includes the microservice's registration information, running status information, data interaction information, etc. The collection frequency can be dynamically adjusted according to business needs. For core microservices with high data update frequency, a higher collection frequency can be set (e.g., once per second), and for non-core microservices with low data update frequency, a lower collection frequency can be set (e.g., once per minute), to achieve refined data collection and reduce the pressure of data transmission and processing.

[0042] After encrypting the collected raw microservice data, the proxy node transmits it to the microservice processing platform via an encrypted communication link. Upon receiving the data, the platform first performs microservice association processing based on unique data identifiers. This involves matching the corresponding unique data identifier with the microservice registration attributes (such as service name and network address) in the raw data, binding the raw data to the unique data identifier. This ensures that each piece of raw data can be accurately associated with the corresponding microservice, solving the problem of chaotic and inaccurate traceability of microservice data under multiple registration centers. For example, if the unique data identifier of a microservice is "SF001-TR01-20250101", where "SF001" is the business system code, "TR01" is the transaction microservice classification code, and "20250101" is the generation time, the platform can quickly retrieve all relevant data for that microservice after binding the collected raw data of that microservice to this identifier.

[0043] After the data association is completed, the platform performs format standardization processing on the original data. The core purpose of this processing is to eliminate the differences in format, fields, units, etc. of the original data from different registry centers, and to achieve unified format storage of microservice data. Specifically, the format standardization process includes the following operations: First, field unification: The platform pre-sets a standard field set for microservice data, including required and optional fields. Non-standard fields in the original data are mapped, completed, or deleted. For example, the "Service IP" field in the registry is mapped to the standard field "Network Address," the missing optional field "Version Number" is completed, and the meaningless "Local Identifier" field is deleted. Second, format unification: The transmission format of the original data is unified to standardized formats such as JSON and Protobuf, and the units of numerical data are unified. For example, the unit of network throughput is unified to "MB / s," and the unit of interface response time is unified to "ms." Third, encoding unification: The character encoding, status encoding, etc., in the original data are unified to the platform's pre-set encoding rules. For example, the status encoding "0 / 1" is unified to "Normal / Abnormal," and the character encoding is unified to UTF-8.

[0044] After microservice association and format standardization, standardized microservice data is obtained. This data includes unique data identifiers, standardized registration attributes, data characteristics, and runtime status information. It has a unified format and standardized fields, and can be directly used for subsequent centralized storage and processing.

[0045] S104. Write the standardized microservice data into the distributed database of the microservice processing platform, and perform hierarchical centralized processing on the standardized microservice data according to the classification results of the microservices. The distributed database contains standardized microservice data corresponding to multiple microservices and unique data identifiers.

[0046] In application, the microservice processing platform writes the standardized microservice data into a distributed database. During the writing process, a unique data identifier is used as the primary key to achieve efficient data retrieval and accurate traceability. Simultaneously, the platform shards and partitions the data in the distributed database, for example, by microservice classification results and by unique data identifier codes, improving data storage and query efficiency. The distributed database stores standardized microservice data and corresponding unique data identifiers for all microservices, achieving unified storage of microservice data across multiple registry centers. Users can quickly retrieve the corresponding microservice data by entering keywords such as unique data identifier, microservice name, and classification information through the platform's search interface.

[0047] After data writing is complete, the platform performs hierarchical centralized processing of standardized microservice data based on the microservice classification results. The core principle of hierarchical processing is to allocate different computing resources, processing priorities, and processing methods according to the importance of the microservices, data processing needs, and resource consumption, thereby achieving reasonable allocation of computing resources, improving data processing efficiency, and reducing unnecessary resource consumption. Specifically, the hierarchical centralized processing method can be customized according to the microservice classification rules. The following are some common classification methods as examples: If microservices are categorized into core microservices, important microservices, and ordinary microservices based on their business importance, then standardized data from core microservices will be processed with high priority, high computing resources, and real-time processing to ensure the timeliness and accuracy of data processing. Examples include transaction microservices and risk control microservices in the financial field. Standardized data from important microservices will be processed with medium priority, medium computing resources, and near real-time processing. Examples include user management microservices and order management microservices. Standardized data from ordinary microservices will be processed with low priority, shared computing resources, and offline batch processing. Examples include log microservices and statistics microservices.

[0048] If we categorize microservices into real-time update microservices, near-real-time update microservices, and offline update microservices based on their data update frequency, then for real-time update microservices, standardized data is processed using streaming methods, employing streaming computing frameworks such as Flink and Spark Streaming for real-time data processing and analysis. For near-real-time update microservices, standardized data is processed using micro-batch processing, performing small-batch data processing at preset time intervals. For offline update microservices, standardized data is processed using batch processing, with centralized processing performed during periods of low computing resource availability, such as at night.

[0049] If microservices are categorized into high-resource-consuming, medium-resource-consuming, and low-resource-consuming microservices based on their resource consumption levels, then standardized data from high-resource-consuming microservices will be processed on independent computing nodes to avoid resource competition with data from other microservices. Standardized data from medium- and low-resource-consuming microservices will be processed using shared computing nodes to improve the utilization of computing resources.

[0050] The specific operations of hierarchical centralized processing include, but are not limited to, data cleaning, deduplication, index building, data statistics, and anomaly detection. For example, real-time anomaly detection is performed on the data of core microservices. If data anomalies are detected (such as abnormal running status or interface response time exceeding a threshold), the platform immediately issues an alarm. Batch deduplication and index building are performed on the data of ordinary microservices to improve data query efficiency. After processing, the platform binds the processing results with standardized microservice data and stores them together in a distributed database, providing data support for subsequent microservice operation adaptation, monitoring, and analysis.

[0051] The core objective of this step is to achieve unified storage and hierarchical processing of microservice data under multiple registration centers. This solves the problems of scattered data storage, single processing method, and waste of computing resources in existing technologies, thereby improving the processing efficiency and management level of microservice data.

[0052] Optionally, in some embodiments of this application, before collecting the registration attributes and data characteristics of each microservice in S101 above, the platform also performs corresponding preprocessing operations depending on whether the microservice has a corresponding registration center, specifically including the following steps S101A to S101B: S101A. If the microservice does not have a corresponding registry center, a dedicated registration partition is created in the unified registry center based on the data characteristics of the microservice, and the registration attributes of the microservice are deployed and bound to the assigned unique data identifier.

[0053] In application, for newly launched microservices that haven't deployed any registry center, the microservice processing platform no longer deploys a separate registry center for them. Instead, it creates a dedicated registry partition for each microservice within the platform's built-in unified registry center. The creation of this dedicated registry partition is based on the microservice's data characteristics. For example, for microservices with JSON data transmission format and real-time data update frequency, a dedicated registry partition supporting JSON format and real-time data synchronization is created. For microservices with large data volumes and offline processing, a dedicated registry partition supporting massive data storage and offline data synchronization is created. Each dedicated registry partition has independent storage and management space, preventing interference between registration information from different microservices. Simultaneously, the unified registry center provides unified registration, discovery, and management services for all dedicated registry partitions, improving the efficiency of microservice registration information management.

[0054] After creating a dedicated registration partition, the platform deploys the registration attributes of microservices to this partition and binds the partition's identifier to the microservice's unique data identifier, achieving a precise association between registration information and microservice identity. The unified registration center seamlessly integrates with the microservice adaptation engine, distributed database, and other components of the microservice processing platform. This eliminates the need to deploy lightweight adaptation proxy nodes, enabling direct collection and processing of microservice data, reducing component deployment workload and lowering platform maintenance costs.

[0055] S101B. If the microservice already has a corresponding registry center, extract the registration attributes of the microservice in the existing registry center, and combine the microservice data characteristics to complete the classification and allocation of unique data identifiers.

[0056] In application, for existing microservices deployed in various registration centers, the platform extracts their registration attributes in existing registration centers through network scanning and pre-collection using lightweight adaptable proxy nodes. Simultaneously, it collects their data characteristics and, combined with the classification rules and unique data identifier allocation method in S101 above, completes the classification of microservices and the allocation of unique data identifiers. This method requires no modification or migration of the registration information of existing microservices, maximizing the operational stability of existing microservices. It also achieves unified identification and classification management for existing and newly launched microservices, laying the foundation for subsequent unified data processing.

[0057] The core objective of this embodiment is to provide a flexible registration information management solution for different scenarios, such as whether a microservice has a corresponding registry center. This solution not only achieves standardized deployment of registration information for newly launched microservices but also ensures the operational stability of existing microservices. Furthermore, it enables unified classification and identifier allocation for all microservices, thus resolving the issue of inconsistent data management between new and old microservices in existing technologies.

[0058] Please refer to Figure 3, which shows a flowchart of the implementation of microservice registration information migration provided in another embodiment of this application. Before collecting the registration attributes and data characteristics of each microservice in S101 above, for microservices that already have corresponding registration centers, the platform also provides an optional solution for migrating registration information to a unified registration center, specifically including the following steps S101C to S101D: S101C. If the microservice already has a corresponding registry center, then the original registration data is synchronized to the temporary cache area of ​​the microservice processing platform through the lightweight adaptation proxy node.

[0059] In application, for microservices with existing registry centers, if staff need to migrate their registration information to the platform's unified registry center based on business requirements, the platform first synchronizes the microservice's original registration data to a temporary cache by deploying a lightweight adapter proxy node in that registry center. The synchronization process uses an incremental synchronization + full verification approach. First, incremental registration data is synchronized to the temporary cache, and then the full registration data is verified to ensure that the synchronized data is completely consistent with the original data in the registry center, with no data loss or tampering. The temporary cache is a high-performance memory cache, enabling fast storage and retrieval of registration data, providing data support for subsequent redeployment of registration information.

[0060] S101D. Delete the registration information of the microservice deployed in the existing corresponding registry center, redeploy the registration data based on the temporary cache in the exclusive registration partition of the unified registry center, and bind it with the unique data identifier of the microservice.

[0061] In the application, after synchronizing and verifying the registration data, the platform sends a registration information deletion command to the original registry center through a lightweight adaptable proxy node. This deletes all registration information for the microservice in the original registry center, ensuring that there is no residual data for the microservice in the original registry center. Subsequently, based on the registration data in the temporary cache, the platform creates a dedicated registration partition for the microservice in the unified registry center and redeploys the registration data to this partition. During the deployment process, the registration data is formatted strictly according to the platform's standardized field set to ensure standardization. After deployment, the dedicated registration partition identifier in the unified registry center is bound to the microservice's unique data identifier, achieving a precise association between registration information and the microservice's identity identifier. Simultaneously, the registration data in the temporary cache is deleted, releasing cache resources.

[0062] The registration information migration scheme in this embodiment is suitable for business scenarios where the number of microservices in the existing registration center is small and unified management of microservice registration information is required. This scheme can migrate the registration information of existing microservices to the platform's unified registration center, reducing the number of lightweight adaptation proxy nodes deployed, lowering platform operation and maintenance costs, and simultaneously achieving unified management and standardized deployment of all microservice registration information. It should be noted that this scheme is optional; staff can choose whether to migrate registration information based on actual business needs, maximizing the flexibility of the solution.

[0063] Optionally, in some embodiments of this application, after writing standardized microservice data into the distributed database and performing hierarchical centralized processing in S104 above, the platform also achieves precise adaptation for microservice operation, specifically including the following steps S104A to S104C: S104A. Identify the runtime dependency characteristics of the microservice, and call the adaptation plugin that matches the runtime dependency characteristics through the microservice adaptation engine of the microservice processing platform.

[0064] In application, the microservice processing platform uses standardized microservice data stored in a distributed database to identify the runtime dependencies of microservices through feature extraction algorithms. These dependencies include the microservice's runtime framework type (e.g., Spring Cloud, Dubbo, Service Mesh), operating system version (e.g., Linux, Windows), middleware dependencies (e.g., MySQL, Redis, Kafka), interface protocol type (e.g., HTTP, RPC, gRPC), and resource requirements (e.g., number of CPU cores, memory size). During feature extraction, the platform matches the extracted runtime dependency features with a pre-defined feature library to ensure accuracy. For incompletely identified runtime dependency features, the platform will issue a reminder, prompting staff to supplement the relevant information.

[0065] After identifying runtime dependency characteristics, the platform uses a microservice adaptation engine to call the corresponding adaptation plugins. The microservice adaptation engine stores a one-to-one correspondence between various runtime dependency characteristics and the plugins in SDK format, supporting hot reloading and fast invocation. For example, for a microservice running on the Spring Cloud framework and using the HTTP interface protocol, the engine will call the Spring Cloud-HTTP adaptation plugin; for a microservice running on the Dubbo framework and using the RPC interface protocol, the engine will call the Dubbo-RPC adaptation plugin. The adaptation plugins are loaded on demand, only before the microservice starts running, reducing the platform's memory footprint.

[0066] S104B. When the microservice starts running, the adapter plugin enables bidirectional data interaction between the microservice processing platform and the microservice runtime environment to call the business components of the microservice.

[0067] In the application, when a microservice starts running, the microservice processing platform injects the loaded adapter plugin into the microservice's runtime environment, enabling bidirectional data interaction between the platform and the microservice runtime environment. Specifically, this bidirectional data interaction includes two aspects: First, the platform sends control commands to the microservice runtime environment, such as business component invocation commands, resource scheduling commands, and configuration modification commands. The adapter plugin converts the platform's standardized commands into a command format recognizable by the microservice runtime environment, ensuring effective execution of the commands. Second, the microservice runtime environment feeds back runtime status data to the platform, such as component running status, resource usage, and business processing results. The adapter plugin converts the microservice's raw feedback data into a standardized format recognizable by the platform and transmits it to the platform for processing.

[0068] Through bidirectional data interaction, the platform enables remote invocation of microservice business components. Users can select the desired microservice component via the platform's interface. The platform then sends invocation commands to the microservice runtime environment via an adapter plugin. The microservice, in turn, launches the corresponding business component based on the command and returns the processing result to the platform. The adapter plugin eliminates compatibility issues between the platform and the microservice runtime environment, ensuring smooth and stable bidirectional data interaction and improving the efficiency of business component invocation.

[0069] The core objective of this embodiment is to achieve efficient bidirectional data interaction between the platform and the microservice runtime environment by identifying the microservice runtime dependency characteristics and calling the matching adaptation plugins. This solves the problems of poor microservice adaptability, data interaction lag, and low efficiency of business component invocation in the prior art, and ensures the stable operation of microservices.

[0070] Optionally, in some embodiments of this application, after the above-described S104C achieves bidirectional data interaction between the platform and the microservice runtime environment and calls business components through the adapter plugin, the platform also implements full monitoring and multi-dimensional analysis of the microservice runtime process, specifically including the following steps S104CA to S104CC: S104CA collects full monitoring data during the operation of the microservice, and slices the full monitoring data according to preset collection dimensions to obtain sliced ​​monitoring data.

[0071] In the application, after the microservice starts running, the microservice processing platform uses components such as adapter plugins and lightweight adapter proxy nodes to collect full monitoring data in real time during the microservice's operation. This includes comprehensive monitoring data such as CPU utilization, memory usage, disk I / O, network throughput, interface response time, business processing volume, exception error information, and component running status. The collection process achieves seamless and full-dimensional coverage, ensuring the integrity of the monitoring data.

[0072] After collecting all monitoring data, the platform slices the data according to preset collection dimensions. The core purpose of slicing is to finely break down the massive amount of monitoring data into different dimensions, facilitating subsequent correlation and aggregation analysis and avoiding inefficient analysis due to excessive data volume. Collection dimensions can be customized by staff based on business needs. Common collection dimensions include: time dimension, dividing monitoring data into time slices based on time units such as seconds, minutes, and hours (e.g., 5-minute slices, 1-hour slices); resource dimension, dividing monitoring data into resource slices based on resource types such as CPU, memory, disk, and network; business dimension, dividing monitoring data into business slices based on microservice business functions and modules (e.g., transaction business slices, user business slices); and interface dimension, dividing monitoring data into interface slices based on microservice interface names and protocols. During the slicing process, the platform adds unique data identifiers, slice dimensions, and slice time tags to each slice of monitoring data, enabling accurate identification and correlation of the sliced ​​data.

[0073] S104CB performs correlation and aggregation analysis on slice monitoring data within a preset time window to obtain microservice operation analysis results.

[0074] In application, the platform extracts the monitoring data of the slices within the preset time window. The time window can be set by the staff according to business needs, such as 5 minutes, 10 minutes, 1 hour, etc., and supports dynamic adjustment. For core microservices, a smaller time window can be set to achieve real-time monitoring and analysis, while for ordinary microservices, a larger time window can be set to reduce the analysis pressure.

[0075] The platform performs correlation and aggregation analysis on the extracted slice monitoring data. Correlation refers to linking slice monitoring data from different dimensions based on unique data identifiers to achieve multi-dimensional data fusion analysis. For example, it can link slice data with a time dimension of 5 minutes and a resource dimension of CPU with slice data with a time dimension of 5 minutes and a business dimension of transactions to analyze the relationship between CPU utilization and transaction processing volume. Aggregation refers to summarizing and statistically analyzing slice monitoring data within the same dimension and the same time window. For example, it can aggregate interface response time slice data within 5 minutes to calculate the average response time, maximum response time, and minimum response time. The specific process of correlation and aggregation analysis will be described in detail in subsequent sub-examples. After the analysis is completed, the microservice operation analysis results are obtained, which include microservice operation status assessment, resource consumption analysis, business processing efficiency analysis, anomaly location, and operation trend prediction.

[0076] S104CC: After binding the microservice operation analysis results with the unique data identifier of the corresponding microservice, store them in the distributed database.

[0077] In the application, after completing the microservice operation analysis, the platform binds the analysis results with the unique data identifier of the corresponding microservice to ensure that the analysis results can be accurately traced back to the corresponding microservice. Subsequently, the bound operation analysis results are stored in a distributed database and stored in association with standardized microservice data, monitoring data, etc. Staff can use the platform's visual interface to query the microservice operation analysis results by entering the unique data identifier, and can also perform multi-dimensional searches by time, category, operation status, and other conditions.

[0078] Meanwhile, the platform stores the operational analysis results long-term, forming a historical archive of microservice operations. Staff can compare the operational analysis results across different time windows to uncover long-term trends in microservice operation, providing precise data analysis basis for microservice configuration optimization, scaling up / down, and troubleshooting. For example, if the comparison reveals that the CPU utilization of a certain microservice has been continuously increasing recently, staff can scale up the microservice based on the analysis results to ensure its stable operation.

[0079] Optionally, in some embodiments of this application, the specific steps of collecting full monitoring data during the microservice operation process in S104CA above include the following sub-steps S104CA1 to S104CA2: S104CA1: Write all monitoring data of the microservice runtime into the distributed message queue of the microservice processing platform in real time, and partition the distributed message queue according to the unique data identifier of the microservice.

[0080] In application, the platform writes all collected microservice monitoring data to a distributed message queue in real time. This distributed message queue features high throughput, high availability, and asynchronous processing, enabling real-time reception and storage of massive amounts of monitoring data, preventing platform congestion caused by excessive monitoring data volume. Simultaneously, the platform partitions the distributed message queue according to the unique data identifier of each microservice. This means that each microservice's monitoring data is stored in an independent message partition, ensuring that monitoring data from different microservices does not interfere with each other. This guarantees data independence and facilitates rapid retrieval of monitoring data based on the unique data identifier. For example, the monitoring data of a microservice with the unique data identifier "SF001-TR01-20250101" is stored in the "SF001-TR01" partition, and the monitoring data of a microservice with the unique data identifier "SF001-US01-20250101" is stored in the "SF001-US01" partition.

[0081] S104CA2: The monitoring data of each partition in the distributed message queue is read concurrently by multiple threads and written into the time-series data storage system of the microservice processing platform.

[0082] In application, the platform employs multi-threaded concurrent reading to retrieve monitoring data from various partitions of a distributed message queue. This multi-threaded concurrent reading significantly improves data retrieval efficiency and ensures real-time processing of monitoring data. After reading, the platform writes the monitoring data to a time-series data storage system. This system is specifically designed for time-series data, supporting efficient storage and querying by time dimension, and perfectly adapts to the time-series characteristics of microservice monitoring data. Simultaneously, the time-series data storage system synchronizes data with a distributed database, synchronizing core metrics of the monitoring data to the distributed database, providing data support for subsequent correlation and aggregation analysis.

[0083] This embodiment achieves asynchronous writing and partitioned storage of monitoring data through a distributed message queue, efficient processing of monitoring data through multi-threaded concurrent reading, and professional storage of monitoring data through a time-series data storage system. It solves the problems of low efficiency in monitoring data collection, chaotic storage, and difficulty in querying in the prior art, and ensures the integrity, real-time performance, and queryability of monitoring data.

[0084] The specific steps in S104CB above for performing correlation and aggregation analysis on the slice monitoring data within the preset time window include the following sub-steps S104CB1 to S104CB3: S104CB1, The slice monitoring data is sequentially processed for abnormal data removal and data normalization to obtain standardized monitoring data.

[0085] In application, the platform first performs anomaly removal processing on the slice monitoring data. Anomalies include invalid data, erroneous data, and extreme value data generated due to acquisition failures, transmission errors, equipment malfunctions, etc., such as erroneous data with a CPU utilization of 150% or invalid data with an interface response time of 0ms. The platform identifies slice monitoring data using preset anomaly identification rules (such as numerical range rules, trend change rules, and correlation verification rules), removes the identified anomalies, and records the removed anomalies for subsequent troubleshooting. For example, if the network throughput in a slice monitoring data suddenly drops from 100MB / s to 0MB / s without corresponding business operations, the platform classifies this data as anomaly and removes it.

[0086] After removing outlier data, the platform performs data normalization on the slice monitoring data. The core purpose of this process is to eliminate differences in units and numerical ranges among different slice monitoring data, achieving data standardization and laying the foundation for subsequent multi-dimensional aggregation analysis. The data normalization methods include, but are not limited to, min-max normalization, Z-Score normalization, and decimal scaling normalization. For example, metrics with different units, such as CPU utilization (0-100%), memory usage (0-100%), and interface response time (0-1000ms), are uniformly normalized to a numerical range of [0,1]. After outlier removal and data normalization, standardized monitoring data is obtained. This data is clean, standardized, and has uniform units, and can be directly used for subsequent aggregation analysis.

[0087] S104CB2. The standardized monitoring data is aggregated and processed by a multi-dimensional visualization engine to obtain structured statistical report data and visualized trend graph data.

[0088] In application, the platform aggregates standardized monitoring data through a multi-dimensional visualization engine. This aggregation is performed according to preset analysis dimensions, including time, resource, business, and interface dimensions. The engine summarizes, statistically analyzes, and calculates standardized monitoring data within the same dimension and time window, generating two types of data: First, structured statistical report data, presented in structured formats such as tables and forms, containing quantitative values ​​for various monitoring indicators, such as average CPU utilization, maximum memory usage, average interface response time, total business processing volume, and number of exceptions / errors. Statistical report data can be exported to Excel, CSV, and other formats for easy offline analysis. Second, visualized trend graph data, presented in visual formats such as line charts, bar charts, pie charts, heatmaps, and dashboards, showing the changing trends, percentages, and distribution of monitoring indicators, such as a line chart of CPU utilization over time, a bar chart of resource usage, and a pie chart of business processing volume. Trend graph data supports real-time updates and multi-dimensional switching, allowing staff to intuitively and quickly grasp the operational status of microservices.

[0089] S104CB3. By combining the quantitative indicators of the statistical report data and the changing characteristics of the trend graph data, the microservice operation analysis results are obtained.

[0090] In application, the platform combines quantitative indicators from statistical reports with the changing characteristics of trend graph data for comprehensive analysis. It moves beyond simple numerical analysis, achieving a fusion of quantitative indicators and trend features to improve the accuracy and comprehensiveness of the analysis results. Specifically, the comprehensive analysis includes the following: First, operational status assessment. Based on whether the quantitative indicators in the statistical reports exceed preset thresholds, and combined with the changing trends in the trend graph data, the operational status of the microservice is assessed as normal, warning, or abnormal. For example, if the quantitative indicator of CPU utilization is 85% (not exceeding the 90% threshold), but the trend graph data shows that it dropped from 50% within one hour... If the memory usage rate continues to rise to 85%, the platform will assess it as a warning state. Secondly, resource usage analysis will analyze the usage and utilization efficiency of various resources, combined with changes in business processing volume, to determine if there is any waste or insufficiency of resources. For example, if the quantitative indicator of memory usage is 90% and the business processing volume continues to increase, the platform will determine that memory resources are insufficient. Thirdly, business processing efficiency analysis will analyze quantitative indicators such as interface response time and business processing volume, combined with changes in trend graphs, to assess the business processing efficiency of microservices. For example, if the quantitative indicator of the average interface response time is 200ms, and the trend graph shows that it is continuously decreasing... If the microservice's operating status is low, the platform will determine that it is due to improved business processing efficiency. Fourth, for anomaly identification, if the microservice's operating status is abnormal, the platform will locate the cause of the anomaly by combining the abnormal quantitative indicators of statistical report data and the sudden change points of trend graph data. For example, if the number of abnormal errors suddenly increases and the trend graph of network throughput drops sharply, the platform will identify the anomaly as caused by network failure. Fifth, for operation trend prediction, based on the historical quantitative indicators of statistical report data and the long-term change characteristics of trend graph data, the platform will use algorithms such as machine learning and time series prediction to predict the future operation trend of the microservice. For example, it will predict that the CPU utilization rate will rise to 95% in the next hour, providing a basis for staff to intervene in advance.

[0091] After comprehensive analysis, the platform organizes and summarizes the analysis results to form microservice operation analysis results. These results are presented in a combination of text, tables, and graphs, including quantitative analysis data, intuitive trend displays, and targeted optimization suggestions, providing staff with comprehensive and accurate basis for microservice management and optimization.

[0092] This application provides a microservice data processing method applied to a microservice processing platform. It collects the registration attributes and data characteristics of each microservice, classifies the microservices, and assigns a unique data identifier to each microservice. Next, lightweight adaptation proxy nodes are deployed for registry centers of different registration types, and an encrypted communication link is established between the lightweight adaptation proxy nodes and the microservice processing platform. Then, the original data of the microservices within the corresponding registry centers is collected through the lightweight adaptation proxy nodes, and microservice association and format standardization processing of the original data are completed based on the unique data identifiers to obtain standardized microservice data. Finally, the standardized microservice data is written into the distributed database of the microservice processing platform, and hierarchical centralized processing is performed on the standardized microservice data according to the classification results of the microservices. The distributed database contains standardized microservice data and unique data identifiers corresponding one-to-one with multiple microservices. In the microservice data processing scheme provided in this application, by assigning a unique data identifier to each microservice, accurate association and traceability of microservice data are achieved, solving the problem of data retrieval under multiple registry centers. To address the issue of disorganized management, lightweight adaptive proxy nodes were deployed to enable data interaction between the registry center and the platform, avoiding the performance overhead of direct platform-to-registration connection. Encrypted communication links also enhanced data transmission security. Raw microservice data underwent format standardization, eliminating data format conflicts between different registry centers. Combined with microservice classification results, hierarchical centralized processing improved data processing efficiency and reduced unnecessary consumption of computing resources. By identifying microservice runtime dependency characteristics and invoking matching adaptive plugins, efficient bidirectional data interaction between the platform and the microservice runtime environment was achieved, ensuring stable calls to business components. Full monitoring data of microservice operation was sliced ​​and subjected to multi-dimensional correlation and aggregation analysis, enabling precise identification of potential problems during microservice operation and providing accurate data for microservice configuration optimization and troubleshooting. Furthermore, a dedicated registration partition was created in the unified registry center for microservices without a registry center, and flexible data synchronization and migration solutions were provided for microservices with existing registry centers, reducing manual workload and mitigating data migration risks. Overall, this application achieves unified, efficient, and refined processing of microservice data under multiple registration centers, as well as precise adaptation and comprehensive monitoring of microservice operation, and is suitable for business scenarios with large-scale microservice architectures.

[0093] To facilitate better implementation of the microservice data processing method of this application embodiment, this application embodiment also provides a microservice data processing apparatus, wherein the meanings of the terms are the same as those in the microservice data processing method described above, and specific implementation details can be found in the description of the system embodiment.

[0094] Please see Figure 2 , Figure 2This is a schematic diagram of the structure of a microservice data processing device provided in an embodiment of this application. Specifically, the microservice data processing device may include a data acquisition module 201, a data creation module 202, a processing module 203, and a data writing module 204, as follows: The data acquisition module 201 is used to collect the registration attributes and data characteristics of each microservice, classify the microservices, and assign a unique data identifier to each microservice. Module 202 is established to deploy lightweight adaptation proxy nodes for registration centers of different registration types and to establish an encrypted communication link between the lightweight adaptation proxy nodes and the microservice processing platform. The processing module 203 is used to collect the original data of the microservices in the corresponding registry center through the lightweight adaptation proxy node, and complete the microservice association and format standardization processing of the original data based on the unique data identifier to obtain standardized microservice data. The writing module 204 is used to write the standardized microservice data into the distributed database of the microservice processing platform, and to perform hierarchical centralized processing of the standardized microservice data according to the classification results of the microservices. The distributed database contains standardized microservice data corresponding one-to-one with multiple microservices and unique data identifiers.

[0095] This application provides a microservice data processing device applied to a microservice processing platform. A collection module 201 collects the registration attributes and data characteristics of each microservice, classifies the microservices, and assigns a unique data identifier to each microservice. Next, a setup module 202 deploys lightweight adaptation proxy nodes for different registration types of registration centers, establishing an encrypted communication link between the lightweight adaptation proxy nodes and the microservice processing platform. Then, a processing module 203 collects the original data of the corresponding microservices within the registration center through the lightweight adaptation proxy nodes, and performs microservice association and format standardization processing based on the unique data identifier to obtain standardized microservice data. Finally, a writing module 204 writes the standardized microservice data into the distributed database of the microservice processing platform and performs hierarchical centralized processing of the standardized microservice data according to the microservice classification results. The distributed database contains standardized microservice data and unique data identifiers corresponding one-to-one with multiple microservices. In the microservice data processing scheme provided in this application, precise association of microservice data is achieved by assigning a unique data identifier to each microservice. By addressing the issue of chaotic data management across multiple registry centers, this system traces the source of data flow. It deploys lightweight, adaptable proxy nodes to facilitate data interaction between the registry center and the platform, avoiding the performance overhead of direct platform-to-registration interaction and enhancing data transmission security through encrypted communication links. Standardizing the format of raw microservice data eliminates data format conflicts between different registry centers. Combining microservice classification results with hierarchical centralized processing improves data processing efficiency and reduces unnecessary consumption of computing resources. Identifying microservice runtime dependencies and invoking matching adaptable plugins enables efficient bidirectional data interaction between the platform and the microservice runtime environment, ensuring stable calls to business components. Slicing and multi-dimensional correlation aggregation analysis of full-scale microservice runtime monitoring data accurately uncovers potential problems during microservice operation, providing precise data for microservice configuration optimization and troubleshooting. Furthermore, it creates dedicated registration partitions in the unified registry center for microservices without a registry center and provides flexible data synchronization and migration solutions for microservices with existing registry centers, reducing manual workload and mitigating data migration risks. Overall, this application achieves unified, efficient, and refined processing of microservice data under multiple registration centers, as well as precise adaptation and comprehensive monitoring of microservice operation, and is suitable for business scenarios with large-scale microservice architectures.

[0096] Furthermore, embodiments of this application also provide an electronic device, such as... Figure 3 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically: The electronic device may include components such as a processor 301 with one or more processing cores, a memory 302 with one or more processor-readable storage media, a power supply 303, and an input unit 304. Those skilled in the art will understand that... Figure 3 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: Processor 301 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 302, and by calling data stored in memory 302, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, processor 301 may include one or more processing cores; preferably, processor 301 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless microservice data processing. It is understood that the modem processor may not be integrated into processor 301.

[0097] The memory 302 can be used to store software programs and modules. The process 301 executes various functional applications and microservice data processing methods by running the software programs and modules stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 302 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 302 may also include a memory controller to provide the process 301 with access to the memory 302.

[0098] The electronic device also includes a power supply 303 that supplies power to various components. Preferably, the power supply 303 can be logically connected to the processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 303 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0099] The electronic device may also include an input unit 304, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0100] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in the embodiments of this application, the processing 301 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 302 according to the following instructions, and the processing 301 runs the applications stored in the memory 302 to realize various functions, as follows: The system collects the registration attributes and data characteristics of each microservice, classifies the microservices, and assigns a unique data identifier to each microservice. Lightweight adaptation proxy nodes are deployed for registration centers of different registration types, and an encrypted communication link is established between the lightweight adaptation proxy nodes and the microservice processing platform. The system collects the original data of the corresponding microservices within the registration center through the lightweight adaptation proxy nodes, and performs microservice association and format standardization processing based on the unique data identifier to obtain standardized microservice data. The standardized microservice data is written into the distributed database of the microservice processing platform, and is then processed hierarchically and centrally according to the classification results of the microservices. The distributed database contains standardized microservice data and unique data identifiers corresponding one-to-one with multiple microservices.

[0101] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0102] This application's embodiments achieve precise association and traceability of microservice data by assigning a unique data identifier to each microservice, solving the problem of chaotic data management under multiple registration centers. By deploying lightweight adaptable proxy nodes, data interaction between the registration center and the platform is achieved, avoiding the performance overhead of the platform directly connecting to the registration center, while encrypted communication links enhance data transmission security. The original microservice data undergoes format standardization processing, eliminating data format conflicts between different registration centers. Combined with microservice classification results, hierarchical centralized processing improves data processing efficiency and reduces ineffective consumption of computing resources. By identifying microservice runtime dependency characteristics and calling matching adaptable plugins, efficient bidirectional data interaction between the platform and the microservice runtime environment is achieved, ensuring stable calls to business components. Slicing and multi-dimensional correlation aggregation analysis of full-volume monitoring data of microservice operation accurately uncovers potential problems during microservice operation, providing precise basis for microservice configuration optimization and fault diagnosis. Furthermore, for microservices without a registration center, a dedicated registration partition is created in the unified registration center; for microservices with existing registration centers, a flexible solution for data synchronization and migration is provided, reducing both manual workload and data migration risks. Overall, this application achieves unified, efficient, and refined processing of microservice data under multiple registration centers, as well as precise adaptation and comprehensive monitoring of microservice operation, and is suitable for business scenarios with large-scale microservice architectures.

[0103] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a processor-readable storage medium and loaded and executed by a processor.

[0104] To this end, embodiments of this application provide a storage medium storing multiple instructions that can be loaded by a processor to execute steps in any of the microservice data processing methods provided in embodiments of this application. For example, the instructions can execute the following steps: The system collects the registration attributes and data characteristics of each microservice, classifies the microservices, and assigns a unique data identifier to each microservice. Lightweight adaptation proxy nodes are deployed for registration centers of different registration types, and an encrypted communication link is established between the lightweight adaptation proxy nodes and the microservice processing platform. The system collects the original data of the corresponding microservices within the registration center through the lightweight adaptation proxy nodes, and performs microservice association and format standardization processing based on the unique data identifier to obtain standardized microservice data. The standardized microservice data is written into the distributed database of the microservice processing platform, and is then processed hierarchically and centrally according to the classification results of the microservices. The distributed database contains standardized microservice data and unique data identifiers corresponding one-to-one with multiple microservices.

[0105] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0106] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0107] Since the instructions stored in the storage medium can execute the steps of any of the microservice data processing methods provided in the embodiments of this application, the beneficial effects that any of the microservice data processing methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0108] The above provides a detailed description of a microservice data processing method, apparatus, electronic device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A microservice data processing method, characterized in that, Applied to microservice processing platforms, including: Collect the registration attributes and data characteristics of each microservice, classify the microservices, and assign a unique data identifier to each microservice; Deploy lightweight adaptation proxy nodes for registry centers of different registration types, and establish encrypted communication links between the lightweight adaptation proxy nodes and the microservice processing platform; The lightweight adaptable proxy node collects the original data of the microservices in the corresponding registry center, and completes the microservice association and format standardization processing of the original data based on the unique data identifier to obtain standardized microservice data. The standardized microservice data is written into the distributed database of the microservice processing platform, and the standardized microservice data is processed in a hierarchical and centralized manner according to the classification results of the microservices. The distributed database contains standardized microservice data corresponding to multiple microservices and unique data identifiers.

2. The microservice data processing method according to claim 1, characterized in that, The registration center includes the unified registration center of the microservice processing platform and the existing registration center of the microservice; Before collecting the registration attributes and data characteristics of each microservice, the following is also included: If the microservice does not have a corresponding registry center, a dedicated registration partition is created in the unified registry center based on the data characteristics of the microservice, and the registration attributes of the microservice are deployed and bound to the assigned unique data identifier; If the microservice already has a corresponding registry center, then the registration attributes of the microservice in the existing registry center are extracted, and the classification and allocation of unique data identifiers are completed in combination with the microservice data characteristics.

3. The microservice data processing method according to claim 2, characterized in that, Before collecting the registration attributes and data characteristics of each microservice, the following is also included: If the microservice already has a corresponding registry center, its original registration data will be synchronized to the temporary cache area of ​​the microservice processing platform through the lightweight adaptation proxy node. The registration information of the microservice deployed in the existing corresponding registry center is deleted. The registration data based on the temporary cache is redeployed in the dedicated registration partition of the unified registry center and bound to the unique data identifier of the microservice.

4. The microservice data processing method according to claim 1, characterized in that, After writing the standardized microservice data into the distributed database of the microservice processing platform and performing hierarchical centralized processing of the standardized microservice data according to the classification results of the microservices, the process further includes: Identify the runtime dependency characteristics of the microservice, and call the adaptation plugin that matches the runtime dependency characteristics through the microservice adaptation engine of the microservice processing platform; When the microservice starts up and runs, the adapter plugin enables bidirectional data interaction between the microservice processing platform and the microservice runtime environment to invoke the business components of the microservice.

5. The microservice data processing method according to claim 4, characterized in that, After the microservice starts and runs, and the adaptation plugin enables bidirectional data interaction between the microservice processing platform and the microservice runtime environment to call the microservice's business components, the process also includes: Collect all monitoring data during the operation of the microservice, and slice the all monitoring data according to the preset collection dimensions to obtain sliced ​​monitoring data; Perform correlation and aggregation analysis on slice monitoring data within a preset time window to obtain microservice operation analysis results; The microservice operation analysis results are bound to the unique data identifier of the corresponding microservice and then stored in the distributed database.

6. The microservice data processing method according to claim 5, characterized in that, The collection of full monitoring data during the operation of the microservice includes: The full monitoring data of the microservice runtime is written to the distributed message queue of the microservice processing platform in real time, and the distributed message queue is partitioned and stored according to the unique data identifier of the microservice. Monitoring data from each partition in the distributed message queue is read concurrently using multiple threads and written into the time-series data storage system of the microservice processing platform.

7. The microservice data processing method according to claim 5, characterized in that, The process of performing correlation and aggregation analysis on slice monitoring data within a preset time window to obtain microservice operation analysis results includes: The sliced ​​monitoring data is sequentially processed to remove abnormal data and normalize data to obtain standardized monitoring data. The standardized monitoring data is aggregated and processed by a multi-dimensional visualization engine to obtain structured statistical report data and visualized trend graph data. The microservice operation analysis results are obtained by combining the quantitative indicators of the statistical report data and the changing characteristics of the trend graph data.

8. A microservice data processing device, characterized in that, Applied to microservice processing platforms, including: The data collection module is used to collect the registration attributes and data characteristics of each microservice, classify the microservices, and assign a unique data identifier to each microservice. A module is established to deploy lightweight adaptation proxy nodes for registry centers of different registration types, and to establish an encrypted communication link between the lightweight adaptation proxy nodes and the microservice processing platform. The processing module is used to collect the original data of the corresponding microservices in the registry center through the lightweight adaptation proxy node, and complete the microservice association and format standardization processing of the original data based on the unique data identifier to obtain standardized microservice data. The writing module is used to write the standardized microservice data into the distributed database of the microservice processing platform, and to perform hierarchical centralized processing of the standardized microservice data according to the classification results of the microservices. The distributed database contains standardized microservice data corresponding one-to-one with multiple microservices and unique data identifiers.

9. An electronic device, characterized in that, include: A memory, a processor, and a processor program stored in the memory and executable on the processor, wherein the processor executes the program as steps of the microservice data processing method according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The computer processing program is stored and can be loaded by a processor and executed according to any one of claims 1 to 7.

Images