A middle platform service model monitoring system

Abstract

This invention proposes a middleware service model monitoring system, comprising system components and a service model data acquisition component. The system components include a system management unit, a data processing unit, and a data storage unit. The system management unit configures monitoring points for the middleware service model and generates the service model data acquisition component based on the configuration. The service model data acquisition component acquires monitoring point data of the middleware service model. The data processing unit monitors changes in the physical model, logical model, service interface model, and service interface call chain of the middleware service model based on the monitoring point data. The data storage unit stores the monitoring results generated by the data processing unit. The middleware service model monitoring system proposed in this invention has the advantages of configurable monitoring points, pluggable extensibility, independence from specific business systems, reusable functions, automatic adaptation to multiple framework components, and a friendly distributed architecture.

Description

Technical Field

[0001] This invention belongs to the field of system monitoring, and in particular relates to a monitoring system for a middleware service model. Background Technology

[0002] A middle platform is a collection of reusable system capabilities. Essentially, it integrates various general business capabilities and fundamental technical capabilities within an enterprise, enabling efficient reuse of enterprise-level capabilities and seamless integration across different business segments. This, in turn, efficiently supports the rapid development and innovation of the enterprise's business. The core of an enterprise-level middle platform lies in the general business capabilities accumulated during the enterprise's past development. These general capabilities are typically provided to systems outside the middle platform in the form of services or service combinations within the technical architecture. Data flow is achieved through the middle platform service model, which serves as the data carrier. Therefore, the quality and stability of the middle platform service model directly affect the stability and availability of the middle platform services, and consequently, the overall quality of the middle platform's capability output.

[0003] However, the construction of a middle platform is a continuous process of upgrading, iteration, and integration. During this process, the number of service models, model dependencies, and model attributes may change, posing challenges to the service quality and stability of the middle platform. Therefore, monitoring the service models of the middle platform is crucial in the design of the middle platform architecture.

[0004] Currently, the common practice in the industry is to use intrusive aspect-oriented programming techniques such as Spring AOP and static code writing to insert business logic into specific stages to monitor services and service models. This approach has several drawbacks, including poor flexibility, large development workload, strong binding to the business system itself, lack of reusability, poor scalability, and incompatibility with distributed architectures. Summary of the Invention

[0005] This invention addresses the shortcomings of common intrusive aspect-based technologies such as Spring AOP and static code writing, which suffer from poor flexibility, large development workload, strong binding to the business system itself, lack of reusability, poor scalability, and unfriendly to distributed architectures. This invention proposes a middleware service model monitoring system with advantages such as configurable monitoring points, pluggable extension capabilities, no binding to specific business systems, reusable functions, automatic adaptation to multiple development frameworks, and friendliness to distributed architectures.

[0006] The present invention proposes a middleware service model monitoring system, which includes system components and service model data acquisition components. The system components include a system management unit, a data processing unit, and a data storage unit.

[0007] The system management unit is used to configure monitoring points for the middleware service model and generate service model data acquisition components based on the configuration.

[0008] The service model data acquisition component is used to acquire monitoring point data of the middle platform service model;

[0009] The data processing unit is used to monitor changes in the physical model, logical model, service interface model, and service interface call chain of the middle platform service model based on the monitoring point data.

[0010] The data storage unit is used to store the monitoring results generated by the data processing unit.

[0011] Optionally, the service model data acquisition component includes a base unit, a bytecode plugin unit, a plugin loading unit, and a data processing and transmission unit;

[0012] The base unit is used to provide the entry mechanism for the service to be monitored, the bytecode operation framework, the configuration hot update abstract interface, the configuration change and hot reloading abstract interface;

[0013] The bytecode plugin unit is a collection of plugins for collecting monitoring point data, used to provide data collection services for the middle platform service model monitoring system;

[0014] The plugin loading unit is used to drive the loading of the bytecode plugin unit;

[0015] The data processing and transmission unit is used to serialize the monitoring point data collected by the bytecode plugin unit and send it to the system components in batches at regular intervals according to the data sending strategy.

[0016] Optionally, the service model data acquisition component further includes a configuration hot update unit and a heartbeat maintenance unit;

[0017] The configuration hot update unit is used to monitor the update events of the configuration content on the system side in real time, and to perform configuration content update based on the configuration hot update abstract interface provided by the base unit.

[0018] The heartbeat maintenance unit is used to monitor the heartbeat information of the middleware service model monitoring system.

[0019] Optionally, the system management unit includes a middleware system management module, a bytecode plugin management module, an application management module, a service instance management module, and a middleware service model monitoring module;

[0020] The middleware system management module is used to manage the basic information of the middleware service model;

[0021] The bytecode plugin management module is used to complete the registration of bytecode plugins;

[0022] The application management module is used to manage the basic information and the configuration information of the monitoring points, and to generate the service model data acquisition component based on the basic information and the configuration information.

[0023] Optionally, the system management unit may further include a service instance management module and a middleware service model monitoring module;

[0024] The service instance management module is used to manage and analyze the heartbeat information reported by the service model data acquisition component;

[0025] The middleware service model monitoring module is used to display the monitoring point data and the monitoring results generated by the data processing unit.

[0026] Optionally, the basic information of the middle platform service model includes the middle platform name, middle platform service characteristics, and middle platform service model specifications. The middle platform service characteristics include the middle platform service protocol, request header parameters, and request path factors.

[0027] Optionally, the data types of the monitoring point data include heartbeat data reported by the service model data acquisition component, physical model data, service interface model data, modification record data of the logical model and conceptual model, and call chain data of the service interface during service model runtime.

[0028] Optionally, when monitoring changes in the physical model, logical model, service interface model, and service interface call chain, the data processing unit achieves change monitoring by calculating the similarity before and after the change. The similarity calculation process includes: acquiring monitoring point data within two preset monitoring ranges; extracting features from the monitoring point data to generate feature vectors; summing all feature vectors within the first monitoring range to obtain a first monitoring feature vector; summing all feature vectors within the second monitoring range to obtain a second monitoring feature vector; calculating the cosine value between the first and second monitoring feature vectors; and calculating the similarity.

[0029] Where modelChange(X,Y) represents the similarity between the previous monitoring range X and the next monitoring range Y, cosθ is the cosine value, and the vector... This represents a single feature vector within the previous monitoring range. This represents a single feature vector within the next monitoring range.

[0030] Optionally, the data storage unit decouples the data storage logic from the specific storage medium by abstracting the data storage interface and providing a standard storage protocol.

[0031] Optionally, the system components and the service model data acquisition components transmit data through different communication protocols, including HTTP, WebSocket, gRPC, and RSocket.

[0032] The beneficial effects of the technical solution provided by this invention are:

[0033] The middle platform service model monitoring system proposed in this invention has the advantages of configurable monitoring points, plug-in extensibility, no binding to specific business systems, reusable functions, automatic adaptation to multiple framework components, and distributed architecture friendliness. The monitoring content of the middle platform service model includes at least the standardization detection of the middle platform service model, the tracking of the change trajectory of the middle platform service model, the dependency relationship between the middle platform service models, and the association topology between the middle platform services and the middle platform service models. It reduces the construction cost of the middle platform, helps to promote the progress of project construction, and improves the management and control capabilities of the middle platform services as the core asset of the middle platform architecture. Attached Figure Description

[0034] To more clearly illustrate the technical solution of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a schematic diagram of the overall architecture of a middleware service model monitoring system proposed in an embodiment of the present invention;

[0036] Figure 2 This is a schematic diagram of the monitoring workflow of the middleware service model in this embodiment of the invention;

[0037] Figure 3 This is a schematic diagram of the monitoring mechanism of the middleware service model in this embodiment of the invention;

[0038] Figure 4 This is a schematic diagram of the middleware service request chain in an embodiment of the present invention;

[0039] Figure 5 This is a schematic diagram of the monitoring topology of the middleware service model in an embodiment of the present invention. Detailed Implementation

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

[0041] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and figures of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein.

[0042] It should be understood that in the various embodiments of the present invention, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0043] It should be understood that in this invention, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or device.

[0044] It should be understood that in this invention, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, "and / or B" can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.

[0045] It should be understood that in this invention, "B corresponding to A", "B corresponding to A", "A and B correspond", or "B and A correspond" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.

[0046] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."

[0047] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0048] Example:

[0049] like Figure 1 As shown in the figure, this embodiment proposes a middleware service model monitoring system. The monitoring system includes system components and service model data acquisition components. The system components include a system management unit, a data processing unit, and a data storage unit. The system management unit is used to configure monitoring points for the middleware service model and generate the service model data acquisition components according to the configuration.

[0050] The service model data acquisition component is used to acquire monitoring point data of the middle platform service model;

[0051] The data processing unit is used to monitor changes in the physical model, logical model, service interface model, and service interface call chain of the middle platform service model based on the monitoring point data.

[0052] The data storage unit is used to store the monitoring results generated by the data processing unit.

[0053] To improve the transparency of the middleware service model and ensure that changes to the middleware service model are traceable, this embodiment proposes the aforementioned middleware service model monitoring system. This system comprises two parts: a system component and a service model data acquisition component. It collects middleware service model data, including physical model data, service interface model data, logical model and conceptual model operation records, and runtime service interface call chain data. Based on the collected physical model and service interface model data, it calculates the differences before and after changes to the middleware system-level and individual application-level physical models and service interface models. Changes measured numerically are more intuitive. Based on the collected logical model and conceptual model operation records, it displays the change trajectory and statistics of the logical model and concepts. Based on the runtime service interface call chain data, it monitors the entire service model of a single middleware service.

[0054] In terms of specific technical implementation, this embodiment loads itself into the target system based on the Agent_OnLoad method of the JVMTIAgent instrument (Java Virtual Machine), achieving decoupling from the target system and avoiding binding to any specific business system; based on the bytecode module architecture, it realizes flexible expansion of monitoring capabilities and reusable functions; based on the configuration management of system components, it realizes configurable data collection methods and monitoring points; and based on the global request ID generation and transmission plugin, it realizes data interconnection in the distributed system.

[0055] In summary, this embodiment achieves comprehensive monitoring of the middle platform service model from a business perspective, ensuring transparency and traceability of changes. Technically, it offers advantages such as configurable monitoring points, pluggable extensibility, independence from specific business systems, reusable functionality, automatic adaptation to various framework components, and a friendly distributed architecture. Therefore, it is significant in better empowering enterprise middle platform construction, reducing construction costs, accelerating project progress, and enhancing the management and control capabilities of the middle platform service—a core asset of the middle platform architecture.

[0056] To more clearly explain the content of this invention, several key terms involved in this embodiment will first be explained.

[0057] Bytecode: The bytecode involved in this embodiment is the file generated after Java source code is compiled by the virtual machine compiler (i.e., a file with the extension .class). It is not oriented towards any specific type of processor, but only towards the JVM virtual machine. The bytecode is interpreted and executed by the virtual machine.

[0058] Target system: The system to be monitored is an independently running application or service, such as an order system, user permission center, electricity price management service, etc.

[0059] Conceptual Model: A conceptual model is a set of conceptual entities extracted from the user requirements analysis phase to describe user needs within the user's business domain and the relationships between them, such as orders, products, customers, and salespersons. It generally does not involve specific attribute information and is usually represented by an ER diagram.

[0060] Logical Model: The logical model is the process of transforming the conceptual model mentioned above into a concrete data model. That is, it converts the basic ER diagram established in the conceptual model stage into a corresponding logical model. The logical model needs to clarify: 1) how many topics there are; 2) how many entities are under each topic; 3) what the specific attributes of each entity are; and 4) the relationships between entities, such as one-to-many and many-to-many relationships.

[0061] Physical Model: The physical model is the concrete manifestation of the logical model in a real physical medium. It is necessary to clarify 1) the field type and length; 2) other detailed definitions of the field, such as whether it is required, default value, etc.; 3) the constraint information of the field, such as whether it is a primary key or a foreign key.

[0062] Middle Platform: The concept of middle platform is relative to front-end and back-end. It is an architectural model designed to better serve the large-scale innovation of front-end business and enable the reuse of enterprise-level general and basic capabilities.

[0063] Middle Platform Services: In a middle platform architecture, middle platform services are a mapping of enterprise-level general and basic capabilities. They are the prerequisite for realizing the reuse of enterprise-level general capabilities, the soul of the middle platform architecture, and the core asset of the enterprise. Generally, middle platform services provide service support to external systems using lightweight protocols such as HTTP(S) and standardized models.

[0064] Mid-platform service model: The mid-platform service model in this invention includes an API interface model provided to external systems, a conceptual model and a logical model maintained in the business system after the requirements analysis phase, and a physical model stored in physical media.

[0065] RPC Protocol: RPC stands for Remote Procedure Call. The RPC protocol assumes the existence of certain transport protocols, such as TCP, UDP, ICMP, and Dubbo, to enable communication between different programs to transmit data. In the seven-layer network communication model, the RPC protocol spans both the transport and application layers.

[0066] Serialization: Serialization is the process of converting an object into a byte sequence that can be transmitted, enabling cross-platform storage and network transmission of the object.

[0067] ws: WebSocket protocol, is a protocol for full-duplex communication over a single TCP connection.

[0068] In this embodiment, the system components and the service model data acquisition components transmit data through different communication protocols, including HTTP, WebSocket, gRPC, and RSocket.

[0069] In this embodiment, the service model data acquisition component includes a base unit, a bytecode plugin unit, a plugin loading unit, and a data processing and transmission unit.

[0070] The base unit provides the entry mechanism for the service to be monitored, the bytecode operation framework, the configuration hot update abstract interface, the configuration change abstract interface, and the hot reloading abstract interface. The base unit is the foundation and mainboard for the operation of the service model data acquisition component and the construction of upper-layer capabilities; all other units rely on this base unit for operation.

[0071] The bytecode plugin unit is a collection of plugins for collecting monitoring point data, used to provide data collection services for the middleware service model monitoring system. In this embodiment, service model data collection is implemented based on bytecode plugins. Specifically, the steps for developing a bytecode functional plugin are as follows:

[0072] Write a class that inherits from the plugin and write a specification abstract class;

[0073] Furthermore, implement the matching target class method defined in the plugin writing specification abstract class. The role of this method can be understood as determining which classes need to be enhanced. The matching rules include, but are not limited to, using fully qualified name exact matching, regular expression matching, prefix matching, and multi-condition judgment matching.

[0074] Furthermore, implement the specific enhancement point methods of the target class defined in the abstract class of the plugin writing specification. The role of this method can be understood as which methods or parts of the target class to enhance and setting the corresponding business processing logic.

[0075] Furthermore, define a file with the .plugin extension in the resources directory of the plugin project, and define the plugin's unique identifier and the class's package name in key-value format in the file;

[0076] Finally, the plugin is compiled using the compilation tools to generate the final product.

[0077] The plugin loading unit is used to drive the loading of the bytecode plugin unit. The plugin loading unit expands the functionality of the service model data acquisition component by loading the plugin unit.

[0078] Specifically, the plugin loading unit loads bytecode plugins from a specified directory using a custom ClassLoader. It reads configuration manifests with the .plugin extension from the resources directory of the bytecode plugin and retrieves business enhancement classes from them. It then instantiates the business enhancement classes and forces them to be cast to the plugin writing specification abstract class. The plugin loading unit first executes the class matching method in the plugin writing specification abstract class, searches for the target class in the context path according to the matching rules, and if it exists, executes the enhancement point method of the plugin writing specification abstract class, and updates the business monitoring logic in the business enhancement class to the specified enhancement point to achieve capability enhancement.

[0079] The data processing and transmission unit is used to serialize the monitoring point data collected by the bytecode plugin unit and send it to the system components in batches at regular intervals according to the data sending strategy. The data processing and transmission unit realizes high-performance serialization and transmission capabilities of monitoring data in the middle platform service model. Internally, it makes full use of the CPU's concurrency capabilities through a producer-consumer model to realize data collection and consumption, and sends data in batches or at regular intervals with maximum efficiency according to the sending strategy.

[0080] In addition, in order to improve the data acquisition service quality of the middle platform service model, in this embodiment, the service model data acquisition component also includes a configuration hot update unit and a heartbeat maintenance unit;

[0081] The configuration hot update unit is used to monitor configuration content update events on the system side in real time and execute configuration content updates based on the configuration hot update abstract interface provided by the base unit. The configuration hot update unit internally implements the configuration hot update abstract interface provided by the base unit and is the actual executor of the configuration hot update. It maintains a long connection with the system through a high-performance RPC protocol, monitors configuration content updates on the system side in real time, and compares the fingerprint information of the previous configuration content with the currently received configuration content fingerprint information. If the two fingerprint information are different, a configuration update event is sent through the event bus maintained internally by this unit. Different configuration update event listeners process the business according to their own business logic processing units.

[0082] The heartbeat maintenance unit is used to monitor the heartbeat information of the middleware service model monitoring system. After the middleware service model monitoring device is started, the heartbeat maintenance unit is responsible for assembling the obtained information such as the current target system name, timestamp, and startup parameters into a heartbeat packet and transmitting it to the system to indicate the current health status of the device.

[0083] In this embodiment, the system management unit includes a middleware system management module, a bytecode plugin management module, an application management module, a service instance management module, and a middleware service model monitoring module;

[0084] The middleware system management module is used to manage the basic information of the middleware service model;

[0085] The bytecode plugin management module is used to complete the registration of bytecode plugins;

[0086] The application management module is used to manage the basic information and the configuration information of the monitoring points, and to generate the service model data acquisition component based on the basic information and the configuration information.

[0087] In addition, in order to improve the monitoring service quality of the middle platform service model, in this embodiment, the system management unit also includes a service instance management module and a middle platform service model monitoring module;

[0088] The service instance management module is used to manage and analyze the heartbeat information reported by the service model data acquisition component;

[0089] The middleware service model monitoring module is used to display the monitoring point data and the monitoring results generated by the data processing unit.

[0090] The following is combined Figure 2 The specific application process of the system management unit will be further explained.

[0091] S110. Obtaining the service model data acquisition component, the specific steps are as follows:

[0092] S1101. Maintain the middleware information, specifically:

[0093] Enter the middle platform system management module, select "Create New Middle Platform Information", fill in the basic information of the middle platform system and save it. The basic information of the middle platform service model includes the middle platform name, middle platform service characteristics and middle platform service model specifications. The middle platform service characteristics include the middle platform service protocol, request header parameters and request path factors.

[0094] The characteristics of a middle platform service are the basis for determining whether a service is a middle platform service. These characteristics include the middle platform service protocol, request header parameters, and request path factors. The matching rules and operators for each factor include, but are not limited to, exact matching, regular expression matching, and inclusion matching. The middle platform service model specification is used to check whether the physical model and service interface model conform to the middle platform construction specifications.

[0095] For example, taking the creation of an invoice business middle platform information as an example, enter the middle platform system management module of the system, select the "Create New Middle Platform Information" button, fill in the middle platform system name as "Invoice Business Middle Platform", select the protocol type as "HTTPS" for the middle platform service characteristics, and include the keys "Api-version" and "Api-name" in the request header. When the backend service receives this service request, it determines whether the current request is a middle platform service based on the schema in the request and whether the request header contains both "Api-version" and "Api-name".

[0096] Optionally, the basic information of the middle platform can selectively maintain the package names and atomic methods of the conceptual model and logical model operation classes. The system components will automatically generate bytecode plugins for monitoring conceptual model and logical model data based on this information.

[0097] For example, to maintain conceptual model monitoring points: add a new conceptual model classpath `cn.com.test.ConcenptModelService` using the `addConceptMode` method; delete a conceptual model classpath `cn.com.test.ConcenptModelService` using the `removeConceptMode` method; modify a conceptual model classpath `cn.com.test.ConcenptModelService` using the `updateConceptMode` method. To maintain logical model monitoring points: add a logical model classpath `cn.com.test.LogicalModelService` using the `addLogicalMode` method; delete a conceptual model classpath `cn.com.test.ConcenptModelService` using the `removeLogicalMode` method; modify a conceptual model classpath `cn.com.test.ConcenptModelService` using the `updateLogicalMode` method. The middle platform service model specification allows for multiple selections from a dropdown menu, such as: physical table comments cannot be empty; physical table field comments cannot be empty; primary key field type cannot be text.

[0098] S1102. Maintain basic application information, specifically:

[0099] Enter the application management module, select the "Create Application" function, fill in the basic application information and save. The basic application information should include at least the selected application platform, application name, application description, and selected data transmission protocol information.

[0100] S1103. Optionally, register the bytecode plugin. After the bytecode plugin is compiled at the code level, it needs to be registered with the system components to take effect. Specifically:

[0101] Enter the bytecode plugin management module and select the "Register Plugin" button;

[0102] Fill in the basic information of the bytecode plugin, including the bytecode plugin name, plugin function description, plugin activation status, and plugin unique identifier.

[0103] Add a new plugin configuration item, and fill in the configuration name, configuration key, configuration value, and configuration description;

[0104] Click "Register" to complete plugin registration;

[0105] For example, click the "Register Plugin" button, fill in the bytecode plugin name as "Physical Model Data Acquisition Plugin" in the bytecode plugin basic information, the function description as "acquiring physical model data", the plugin activation status as "enabled", and the plugin unique identifier as "xxxxx"; add a new plugin configuration item, the configuration name as "Acquisition Frequency", the configuration key as "mp.physicmodel.collect.frequence", the configuration value as "30min", and the configuration description as "the frequency at which the plugin acquires physical model data", and click "Save" to complete the plugin registration.

[0106] S1104, Generation and Download Service Model Data Acquisition Component, specifically:

[0107] Enter the application management module, select an application in the application list, click Configure service model data acquisition component, and check the registered bytecode plugins in the pop-up bytecode plugin selection page;

[0108] Click to generate the service model data acquisition component. The logic for generating the service model data acquisition component is as follows:

[0109] If the application's middleware system information has configured logical model and physical model monitoring points, generate the corresponding logical model and physical model bytecode plugins for the application.

[0110] Optionally, copy the logical model and physical model monitoring bytecode plugins corresponding to the application to the bytecode plugin unit of the service model data acquisition component;

[0111] Copy the selected bytecode plugin to the bytecode plugin unit of the service model data acquisition component;

[0112] Generate configuration information and copy it to the service model data acquisition component configuration directory;

[0113] Package and generate a zip file containing the service model data acquisition component, and provide the download address;

[0114] Download the service model data acquisition component zip package.

[0115] S120, Service model data acquisition component acquisition and target system integration;

[0116] The integration process is divided into three stages: before the target system starts, during the target system startup, and after the target system startup is complete. The specific process and steps are as follows:

[0117] Before the target system starts:

[0118] S1201. The Agent_OnLoad method of the JVM (Java Virtual Machine) instrument JVMTIAgent is used to load the service model data acquisition component before the target system starts. During the loading process, the service model data acquisition component first starts the base unit to start the bytecode operation framework and start the bytecode plugin loading capability.

[0119] S1202, Load bytecode plugin unit;

[0120] This method utilizes a custom ClassLoader to load bytecode plugins from a predefined directory to enhance the capabilities of specific components or methods in the target system. Its key feature is that, through the bytecode framework described in step S1201, the predefined classes or methods in the bytecode plugins identify and modify the bytecode content in the target system to achieve capability enhancement. The plugin functionality is decoupled from the loading mechanism; any component that conforms to the service plugin development specification placed in the predefined directory will be loaded.

[0121] S1203, Service Model Data Acquisition Component Startup Configuration Hot Update Unit. Its characteristic is that the configuration hot update unit loads the configuration hot update abstract interface class provided by the base unit from the classpath context based on the SPI (service provider interface) mechanism. Therefore, it can be obtained from within this unit or other bytecode plugins, as long as it is within the classpath context, exhibiting strong scalability.

[0122] For example, the abstract interface class for hot reloading is configured as xxx.xxx.xxx.AbstractConfigChangeListener, and the abstract method onChange is defined in this abstract type;

[0123] A custom implementation class, PhysicCollectConfigChangeListener, is defined, which inherits from the abstract class xxx.xxx.xxx.AbstractConfigChangeListener and implements the onChange method. The specific configuration update business logic is then implemented in onChange.

[0124] Add a file named xxx.xxx.xxx.AbstractConfigChangeListener to the resource directory of the service model data collection component, and add the full path name of the PhysicCollectConfigChangeListener class to the file;

[0125] The service model data acquisition component starts the configuration hot update unit to automatically load the xxx.xxx.xxx.AbstractConfigChangeListener file, load and instantiate the specific class information of the configuration in the file and put it into the configuration hot update unit queue;

[0126] When there is a configuration change in the system, the service model data acquisition component sends a system configuration change event and executes the business logic processing of the specific listeners in the configuration hot update unit queue to complete the configuration hot update.

[0127] S1204. The service model data acquisition component starts the data processing and transmission unit. Optionally, this unit realizes high-performance transmission of monitoring data based on high-performance data serialization and high-performance RPC protocol. Internally, it makes full use of the CPU's concurrency capability through the producer-consumer model to realize data acquisition and consumption, and sends data in batches or at regular intervals according to the sending strategy.

[0128] S1205, The service model data acquisition component finally starts the heartbeat maintenance unit;

[0129] After the service model monitoring data component starts up, the heartbeat maintenance unit establishes a long connection with the system component. The communication protocols for establishing the long connection include at least gRPC, Thrift, and WebSocket. Based on the current target system name, timestamp, startup parameters, IP port information, and plugin list information obtained periodically by the timed thread pool, the heartbeat packet information is assembled and sent to the system component through the long connection. If the system component does not receive the heartbeat packet sent by the service model data acquisition component within a certain period of time, the service model data acquisition component is considered to be offline.

[0130] During the target system startup process:

[0131] S1206. After the pre-startup phase of the target system, the middleware service model monitoring device has successfully enhanced the functionality of the target system through bytecode plugins. The functions of these plugins are divided into two parts: one part operates during the target system startup process, and the other part operates during the functional operation phase after the target system has started up. The basic core bytecode plugin operation mechanism operating during the target system startup process is as follows:

[0132] S1206-1. Actively detect and identify the target system framework component type during startup. The feature is that, according to different framework types including but not limited to spring, spring boot, vertex, etc., functional enhancements are performed at the critical paths of the framework components to obtain key object instances of the target system, and the instance references are cached in memory to provide the necessary prerequisites for subsequent monitoring of the middle platform service model.

[0133] For example, let's take retrieving a container class from the Spring framework as an example. From the perspective of system framework principles, any project using the Spring framework will call the `refresh` method of `org.springframework.context.support.AbstractApplicationContext` to initialize the system container. Therefore, our bytecode plugin only needs to enhance the `org.springframework.context.support.AbstractApplicationContext#refresh` method to retrieve the container class instance and concurrently place it in the cache after the `refresh` method completes. Subsequently, the Spring container class can be used freely without needing to trigger it again in an additional way.

[0134] S1206-2. After obtaining the key object instance of the target system, the middle platform service model monitoring device automatically obtains the physical model and interface service data model corresponding to the target system, establishes the association between the system instance and the physical model, as well as the association between the system instance, interface service, and interface service data model, and performs fingerprinting processing on the physical model data.

[0135] S1206-3. The above-mentioned method for processing the acquired monitoring data is characterized in that the data is processed by a high-performance serialization algorithm and then placed into a high-performance memory-mapped file queue to avoid occupying the JVM memory of the system itself, thereby affecting the performance of the target system itself.

[0136] S1206-4. Start the data consumption thread to consume data from the queue in batches or at regular intervals and send the data to the system for processing through the data processing and transmission unit.

[0137] S1206-5. Start a scheduled task to periodically acquire the physical model fingerprint and compare it with the previous fingerprint to monitor changes in the physical model. When the physical model changes, update the memory-mapped file queue information.

[0138] S1207. After the target system starts up, report the target system startup completion event information, including the target system startup parameters and startup completion time.

[0139] At this point, the integration of the service model data acquisition component with the target system has been completed.

[0140] S130. Collect the middleware service model data of the target system;

[0141] Steps S110 and S120 have completed the integration of the service model data acquisition component with the target system, and enhanced the functions of the core component classes and methods, providing the necessary implementation conditions for the service model monitoring and data acquisition in the middle platform.

[0142] To more clearly describe the data collection process of the middle platform service model, the following will combine... Figure 3 The working mechanism and process of monitoring the middle platform service model are explained. Figure 3 The entire process of initiating a middleware service request for a client involves the following steps after receiving the middleware service request:

[0143] S1301, Service model data acquisition component intercepts requests:

[0144] The service model data acquisition component intercepts service requests from the middle platform based on bytecode plug-ins, and obtains the routing information of the service requests from the middle platform.

[0145] S1302. Determine if it is a middleware service:

[0146] Based on the middleware service characteristics configured in step S1101, determine whether the request type is a middleware service call type. If it is not a middleware service request type, allow it without monitoring.

[0147] S1303. Determine if the request header contains a global request ID:

[0148] If it is a middle platform service type, then check if the global ID in the request header is empty. If it is not empty, it can be understood that it is not the request entry point of the middle platform service, and there is no need to monitor the service interface model. If it is empty, generate a global request ID according to the global request ID rules and put it into the request context to realize the end-to-end transmission.

[0149] When generating the global request ID, the global request ID is generated according to a fixed segmentation strategy. Each segment can be reverse parsed. In this embodiment, the feature value of the middle platform service is hashed and then put into the global request ID to realize the call transmission in a distributed environment.

[0150] S1304. If it is the request entry point for the middle platform service, the middle platform service interface model needs to be obtained.

[0151] S1305. Obtaining information on external data calls:

[0152] Record information about components that call external data components within the middleware service, including cascading calls.

[0153] Generally, the service request chain of the middle platform is as follows: Figure 4As shown, the client first initiates a request to call the middleware service. Within the middleware service, different types of components may then initiate data requests to services within or outside the middleware system. Corresponding related services may in turn initiate data requests to other services, and so on, ultimately forming a call relationship topology graph. This step specifically records the component type and related connection information for non-database query operations, and the database query operation records the database type and the executed logical statements, including but not limited to traditional SQL.

[0154] For example, if the middle platform service requests an external service interface through HttpClient, the record component type is HttpClient, the statement is requesting the service interface address http: / / xxxx / a / b, and then operates on the MySQL database, the record component type is MySQL, the statement is select * from a,b where a.id = b.aid. The relationship between the middle platform service and the data acquisition logic statement is indirectly established through the request ID and recorded in the high-performance virtual memory queue.

[0155] S140, Send data to system components:

[0156] After the monitoring point data is processed by a high-performance serialization algorithm, it is put into a high-performance memory-mapped file queue. The consumer thread consumes data from the queue and sends the data to the system in batches according to the sending strategy.

[0157] At this point, it can be understood that the monitoring work of the middle platform service model has been completed, the original monitoring data of the middle platform service model has been sent to the system, and the system components will parse and persist the original data.

[0158] S150, Monitoring Data Processing:

[0159] In this embodiment, the data types of the monitoring point data include heartbeat data reported by the service model data acquisition component, physical model data, service interface model data, modification record data of the logical model and conceptual model, and call chain data of the service interface during service model runtime.

[0160] Specifically, the heartbeat data sent by the middleware service model device includes:

[0161] The system processes the basic application and environmental information from the received heartbeat packets using a fingerprinting algorithm to generate a unique identifier for the service model data collection component. This identifier is stored in system memory in a key-value format with an expiration time. Specifically, the unique identifier is used as the key, and the heartbeat packet information is used as the value. When the same heartbeat information is received again, the previous heartbeat information will be overwritten and updated. If the platform service model monitoring device fails to report heartbeat information within the expiration time, it is considered offline. In a distributed environment, the system maintains state consistency among its instances based on the Raft algorithm.

[0162] The data processing for monitoring the service model in the middle platform includes physical model data, service interface model data, modification records and statistical data of logical model and conceptual model, and model specification monitoring.

[0163] Specifically, the physical model data includes basic physical model information, physical model field attribute information, physical model change record information, and model specification verification.

[0164] The physical model change record information includes at least the change time, change content, and physical model change degree. The change content can be understood as specific change information, such as field a in table A being 10 before modification and 20 after modification. The physical model change degree can be understood as measuring the extent of the physical model modification.

[0165] To quantify changes in the middleware service model and improve the visibility of monitoring results, this embodiment proposes a general change degree calculation method to measure the degree of model change. This calculation method is not limited to physical model change degree calculation, but can also be used for service interface model, conceptual model, and logical model change degree calculation.

[0166] Specifically, when monitoring changes in the physical model, logical model, service interface model, and service interface call chain, the data processing unit achieves change monitoring by calculating the similarity before and after the change. The similarity calculation process includes:

[0167] Data from monitoring points within two preset monitoring ranges are acquired. Feature extraction is performed on the monitoring point data to generate feature vectors. All feature vectors from the first monitoring range are summed to obtain a first monitoring feature vector, and all feature vectors from the second monitoring range are summed to obtain a second monitoring feature vector. The cosine value between the first and second monitoring feature vectors is calculated, and the similarity is calculated. Where modelChange(X, Y) represents the similarity between the previous monitoring range X and the next monitoring range Y, cosθ is the cosine value, and the vector... This represents a single feature vector within the previous monitoring range. This represents a single feature vector within the next monitoring range. The larger cosθ is, the smaller the angle θ between the two features, and the smaller the change in the model before and after.

[0168] The runtime middleware service interface call chain data processing includes:

[0169] The monitoring data during the middleware service call process comes from step S1305. All data in this link is associated using the distributedId (distributed ID) to... Figure 5 Taking the monitoring process shown below as an example, the specific explanation is as follows:

[0170] Upon receiving a client request, the middleware service and its interface model are retrieved from the `interfaceMode` field. Then, associated services A and B are identified. All physical table information corresponding to associated services A and B, along with the physical table model of the middleware design for associated service A or B, are determined, thus establishing the physical model relationships. Assuming associated service A is also associated with service C, all physical table information corresponding to service C, along with the physical table model of service C in the middleware service design, are also retrieved simultaneously to determine the physical model relationships.

[0171] For example, the physical model association for associated service A is the customer ID association between the customer table and the order table; the physical model association for associated service B is the order ID association between the order table and the rule validation table; and the physical model association for associated service C is the order ID association between the order table and the payment record table.

[0172] Specifically, it retrieves segment data information. If it is a database query operation, it retrieves the sequence statement content, obtains the corresponding statement parser instance from the statement parser through componentType, and performs syntax and statement analysis on the data retrieval logic statement to extract the corresponding data model and relationships.

[0173] For example, taking MySQL as an example, the specific steps of the syntax and statement analysis process are as follows:

[0174] The lexical analysis module transforms the data acquisition logic statements into an AST (Abstract Syntax Tree). Then, the syntax analysis module traverses and analyzes the AST to find the specific actions, logic, and specific operation objects involved in the data acquisition logic statements.

[0175] Specifically, the nodes in the AST syntax tree are sequentially arranged as follows: expression, execution statement, and operation. Entities and their corresponding physical model relationships are identified based on join keywords. For example, expressions containing key predicates include Full Outer Join, Left Outer Join, and Right Outer Join. The keyword "on" following "Join" effectively identifies the relationships between physical models. For instance, "SELECT Customers.CustomerName, Orders.OrderID FROM Customers LEFT JOIN Orders ON Customers.CustomerID = Orders.CustomerID" identifies the relationship between Customers (customer table) and Orders (order table) through CustomerID (customer ID). Entities can also be identified using other keywords such as update, select, insert, and delete, while physical model relationships can be identified using conditional keywords such as where and having.

[0176] S160. The data storage component saves the processed data:

[0177] The data storage component provides data storage capabilities to the system. The data storage unit decouples the data storage logic from the specific storage medium by abstracting the data storage interface and providing a standard storage protocol. Any application or component that implements the standard protocol can interface with the system of this invention. The backend storage medium can be at least MySQL, Elasticsearch, ClickHour, etc.

[0178] The serial numbers in the above embodiments are for descriptive purposes only and do not represent the order in which the components are assembled or used.

[0179] The above description is merely an embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A monitoring system for a middleware service model, characterized in that, The monitoring system includes system components and a service model data acquisition component. The system components include a system management unit, a data processing unit, and a data storage unit. The system management unit is used to configure monitoring points for the middleware service model and generate service model data acquisition components based on the configuration. The service model data acquisition component is used to acquire monitoring point data of the middle platform service model; The data processing unit is used to monitor changes in the physical model, logical model, service interface model, and service interface call chain of the middle platform service model based on the monitoring point data. The data storage unit is used to store the monitoring results generated by the data processing unit; The service model data acquisition component includes a base unit, a bytecode plugin unit, a plugin loading unit, and a data processing and transmission unit; The base unit is used to provide the entry mechanism for the service to be monitored, the bytecode operation framework, the configuration hot update abstract interface, the configuration change and hot reloading abstract interface; The bytecode plugin unit is a collection of plugins for collecting monitoring point data, used to provide data collection services for the middle platform service model monitoring system; The plugin loading unit is used to drive the loading of the bytecode plugin unit; The data processing and transmission unit is used to serialize the monitoring point data collected by the bytecode plugin unit and send it to the system components in batches at regular intervals according to the data sending strategy; When monitoring changes in the physical model, logical model, service interface model, and service interface call chain, the data processing unit achieves change monitoring by calculating the similarity before and after the change. The similarity calculation process includes: Acquire monitoring point data from two preset monitoring ranges before and after, extract features from the monitoring point data, and generate feature vectors; The first monitoring feature vector is obtained by summing all feature vectors within the previous monitoring range, and the second monitoring feature vector is obtained by summing all feature vectors within the next monitoring range. The cosine value between the first and second monitoring feature vectors is calculated, and the similarity is calculated as follows: ; Where modelChange(X,Y) represents the similarity between the previous monitoring range X and the next monitoring range Y, cosθ is the cosine value, and the vector... This represents a single feature vector within the previous monitoring range. This represents a single feature vector within the next monitoring range.

2. The monitoring system for a middleware service model according to claim 1, characterized in that, The service model data acquisition component also includes a configuration hot update unit and a heartbeat maintenance unit; The configuration hot update unit is used to monitor the update events of the configuration content on the system side in real time, and to perform configuration content update based on the configuration hot update abstract interface provided by the base unit. The heartbeat maintenance unit is used to monitor the heartbeat information of the middleware service model monitoring system.

3. The monitoring system for a middleware service model according to claim 1, characterized in that, The system management unit includes a middleware system management module, a bytecode plugin management module, an application management module, a service instance management module, and a middleware service model monitoring module; The middleware system management module is used to manage the basic information of the middleware service model; The bytecode plugin management module is used to complete the registration of bytecode plugins; The application management module is used to manage the basic information and the configuration information of the monitoring points, and to generate the service model data acquisition component based on the basic information and the configuration information.

4. The middleware service model monitoring system according to claim 3, characterized in that, The system management unit also includes a service instance management module and a middleware service model monitoring module; The service instance management module is used to manage and analyze the heartbeat information reported by the service model data acquisition component; The middleware service model monitoring module is used to display the monitoring point data and the monitoring results generated by the data processing unit.

5. The monitoring system for a middleware service model according to claim 1, characterized in that, The basic information of the middle platform service model includes the middle platform name, middle platform service characteristics, and middle platform service model specifications. The middle platform service characteristics include the middle platform service protocol, request header parameters, and request path factors.

6. The monitoring system for a middleware service model according to claim 1, characterized in that, The data types of the monitoring point data include heartbeat data reported by the service model data acquisition component, physical model data, service interface model data, modification record data of the logical model and conceptual model, and call chain data of the service interface during service model runtime.

7. The monitoring system for a middleware service model according to claim 1, characterized in that, The data storage unit decouples the data storage logic from the specific storage medium by abstracting the data storage interface and providing standard storage protocols.

8. The monitoring system for a middleware service model according to claim 1, characterized in that, The system components and the service model data acquisition components transmit data through different communication protocols, including HTTP, WebSocket, gRPC, and RSocket.

Images