A service governance system
By combining the service governance execution module and management platform with Java Agent technology, service components are dynamically upgraded, solving the problem of high coupling between service governance and application systems in existing technologies. This achieves non-intrusive, dynamically upgradeable service governance, reducing system coupling and invasiveness.
Patent Information
- Application Number
- CN202511453428.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-13
- Publication Date
- 2025-12-05
- Estimated Expiration
- 2045-10-13
AI Technical Summary
In existing technologies, service governance is highly coupled with application systems, making service component upgrades difficult, highly invasive, and requiring restarts. In cases where service component versions are inconsistent, dynamic upgrades are impossible.
It adopts a service governance execution module and management platform, and implements a non-intrusive, dynamically upgradeable service governance system through Java Agent technology. It dynamically upgrades service components and performs runtime enhancements during class loading through bytecode instrumentation technology, supporting service governance operations triggered by multiple source instructions.
It enables flexible and intelligent upgrading and removal of service components without modifying the target application code or restarting the service, reducing system coupling and invasiveness, and improving the flexibility and efficiency of service governance.
Smart Images

Figure CN120929152B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer software development technology, and in particular to a service governance system. Background Technology
[0002] In existing technologies, service removal mostly relies on SDK integration (such as Spring Cloud AlibabaSentinel, Dubbo Filter), requiring the introduction of specific dependencies into the project and modification of configuration or code. This not only leads to difficulties in upgrading service components, high invasiveness, and high coupling, but also results in the problem that service governance components can only be upgraded after restarting the service. Summary of the Invention
[0003] In view of this, the embodiments of this application provide a service governance system that can effectively solve the problem of high coupling between service governance and application systems in the prior art.
[0004] In a first aspect, embodiments of this application provide a service governance system, the system comprising:
[0005] A service governance execution module and a service governance management platform; the service governance execution module is mounted to the application system to be governed; wherein, the application system integrates several service components;
[0006] The service governance execution module is used to communicate with several auxiliary systems that assist the application system in its operation, and to receive governance suggestions sent by the several auxiliary systems.
[0007] The service governance management platform is used to issue target governance instructions to the service governance execution module according to the requirements or according to the governance suggestions forwarded by the service governance execution module;
[0008] The service governance execution module is used to govern each of the service components in the application system according to the target governance instructions.
[0009] In some embodiments, the service governance execution module is further configured to identify all dependent packages of the application system under a preset path after startup, obtain the metadata of the application system, and send it to the service governance management platform; the service governance management platform is further configured to receive any service component newly integrated by the user based on the application system, and add the corresponding component attribute to the stored metadata.
[0010] In some embodiments, the target governance instructions include service upgrade instructions;
[0011] The service governance management platform is specifically used to send a service upgrade instruction to the service governance execution module when the latest version of any first target service component stored in the server is inconsistent with the version of the service component integrated in the application system.
[0012] The service governance execution module is specifically used to pull the upgrade package of the first target service component according to the address in the service upgrade instruction, and to perform runtime enhancement on the qualified classes through bytecode instrumentation during the class loading process of the upgrade package, so as to dynamically upgrade the first target service component.
[0013] In some embodiments, the target governance instruction includes a governance escalation instruction;
[0014] The service governance management platform is specifically used to send a governance upgrade instruction to the service governance execution module when the service governance capability of the service governance execution module does not include the second target service component.
[0015] The service governance execution module is used to pull its own upgrade package according to the address in the governance upgrade instruction, and to dynamically upgrade the service governance execution module by using bytecode instrumentation technology to perform runtime enhancement on classes that meet the conditions during the class loading process of the upgrade package of the service governance execution module.
[0016] In some embodiments, the service governance management platform is further configured to receive registration information sent by the application system when adding and integrating a second target service component;
[0017] The service governance management platform is specifically used to determine whether the service governance capabilities of the service governance execution module include service governance of the second target service component by matching the governance service items stored in the platform with the registration information; wherein the governance service items are obtained by statistical analysis based on the metadata stored in the platform and the registration information.
[0018] In some embodiments, the target governance instruction includes a service removal instruction; the service removal instruction includes dependency package retrieval rules for the service component to be removed;
[0019] The service governance execution module is specifically used to retrieve the dependency packages of the service component to be removed according to the dependency package retrieval rules in the service removal instruction, obtain the highest version dependency package of the service component to be removed, and remove the highest version dependency package.
[0020] In some embodiments, the target governance instruction may further include service governance order data; the service removal instruction may further include service component identifiers of each service component to be removed.
[0021] The service governance execution module is also specifically used to set the governance order for each service component according to the requirements after startup, obtain service governance order data, and send it to the service governance management platform.
[0022] The service governance execution module is further specifically used to remove each service component to be removed from the service removal instruction according to the service governance sequence data.
[0023] In some embodiments, the service governance execution module specifically removes the corresponding service component to be removed through atomically designed service removal.
[0024] In some embodiments, the plurality of auxiliary systems include at least one of an operation and maintenance system, a monitoring system, and an inspection system; the governance recommendations include service removal instructions;
[0025] The service governance execution module is specifically used to receive service removal instructions sent by the operation and maintenance system, the monitoring system, or the inspection system, and to obtain the corresponding component attributes based on the metadata stored locally according to the service component identifier in the service removal instruction. If the component attributes exist, the module retrieves the dependency packages of the service component to be removed based on the component attributes and removes them. If the metadata does not exist, the module forwards the governance suggestion to the service governance management platform.
[0026] In some embodiments, the metadata includes component attributes and governance execution module information for each service component; wherein, the governance execution module information includes service governance order data and service governance capability data; and the component attributes include dependency package retrieval rules, service component identifier, and service component version.
[0027] The service governance management platform is specifically used to generate the service removal command based on the dependency package retrieval rules and service component identifier within the component attributes of the third target service component; wherein, the third target service component is a target service component determined according to the requirements or the governance recommendations.
[0028] The embodiments of this application have the following beneficial effects:
[0029] The service governance system in this application includes a service governance execution module and a service governance management platform. The service governance execution module is mounted on the application system to be governed. The application system integrates several service components. The service governance execution module communicates with several auxiliary systems that assist the application system and receives governance suggestions from these auxiliary systems. The service governance management platform issues target governance instructions to the service governance execution module based on requirements or governance suggestions forwarded by the service governance execution module. The service governance execution module governs each service component within the application system according to the target governance instructions. This application utilizes the service governance execution module to achieve service governance of each service component within the application system, without intruding on the application system and with low coupling. Attached Figure Description
[0030] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0031] Figure 1 A structural block diagram of a service governance system according to an embodiment of this application is shown;
[0032] Figure 2 This paper illustrates a workflow diagram of a service governance system implementing service removal according to an embodiment of the present application.
[0033] Figure 3 This paper illustrates a workflow diagram of a service governance system implementing service upgrades according to an embodiment of this application.
[0034] Explanation of key component symbols:
[0035] 100 - Service Governance Execution Module; 200 - Service Governance Management Platform; 300 - Application System; 310 - Service Components; 400 - Operation and Maintenance System; 500 - Monitoring System; 600 - Inspection System. Detailed Implementation
[0036] The technical solutions in 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.
[0037] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0038] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.
[0039] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.
[0040] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.
[0041] The main idea of this application is to implement a non-intrusive, dynamically upgradable service governance system that supports multi-source command triggering through Java Agent technology, so as to flexibly and intelligently complete operations such as "service removal" and "service upgrade" in service governance without modifying the target application code or restarting the service.
[0042] Java Agent is a powerful mechanism provided by the Java platform that allows developers to dynamically modify bytecode, monitor application behavior, and enhance class functionality at JVM startup or during runtime, without modifying the original code. It is the core technological foundation for implementing advanced features such as non-intrusive monitoring, performance analysis, hot updates, and service governance.
[0043] The service governance system will be described below with reference to some specific embodiments.
[0044] Figure 1 A structural block diagram of a service governance system according to an embodiment of this application is shown. Exemplarily, the service governance system includes: a service governance execution module 100 and a service governance management platform 200.
[0045] The service governance execution module 100 is mounted onto the application system 300 to be governed. The application system 300 integrates several service components 310. The service governance execution module 100 is used to govern the various service components 310 within the application system 300. For example, the service governance execution module 100 is used to control the upgrading, removal, etc., of the various service components 310 within the application system 300. The application system 300 is used to provide business functions, and this application does not impose any limitations on this. Service components 310 include asynchronous communication services, task scheduling services, etc., for example, service components 310 may be MQ, Dubbo, XXL-Job, etc.
[0046] The service governance execution module 100 is used to communicate with several auxiliary systems that assist the application system 300 in its operation, and to receive governance suggestions from these auxiliary systems. The service governance execution module 100 is communicatively connected to several auxiliary systems. These auxiliary systems are used to ensure the stability, availability, security, and maintainability of the application system 300, thereby assisting the application system 300 in its operation. Exemplarily, these auxiliary systems include, but are not limited to, the operation and maintenance system 400, the monitoring system 500, and the inspection system 600, etc.
[0047] The inspection system 600 is software used to automatically or semi-automatically perform regular health checks on the infrastructure of the application system 300. For example, the inspection system 600 is used for resource utilization detection (CPU, memory, disk), service availability detection (HTTP interface connectivity, port listening), log anomaly pattern recognition, security vulnerability scanning, etc.
[0048] The Operations and Maintenance System 400 is a comprehensive platform used to manage the deployment, monitoring, fault handling, change control, and capacity planning activities of the Application System 300 throughout its entire lifecycle. For example, the Operations and Maintenance System 400 is used to implement fault alarms and notifications, performance monitoring and trend prediction, etc.
[0049] The monitoring platform is used for real-time metric collection (CPU, memory, response time, etc.), log aggregation and analysis, anomaly detection and alarm triggering, etc.
[0050] The service governance management platform 200 is used to issue target governance instructions to the service governance execution module 100 based on requirements or governance suggestions forwarded by the service governance execution module 100. Here, "requirements" refers to instructions triggered by the service governance management platform 200 based on detected information, which require the service governance execution module 100 to perform certain governance tasks, such as service component upgrades.
[0051] After the operation and maintenance system 400, monitoring system 500, or inspection system 600 detects an anomaly, they issue a governance suggestion to the service governance execution module 100. This governance suggestion instructs the service governance execution module 100 to perform which governance actions, including but not limited to service removal and service upgrades. Therefore, this application can automatically analyze the services that need governance based on the governance suggestion.
[0052] The service governance execution module 100 is used to govern each service component 310 used within the application system 300 according to the target governance instructions. Governance in this embodiment includes, but is not limited to, service upgrades and service removal.
[0053] For example, the service governance execution module 100 includes, but is not limited to, the use of a Java Agent. This Java Agent incorporates a built-in HTTP service for service governance, receiving target governance commands and sending information to the service governance management platform via this HTTP service. The Java Agent is mounted to the application system 300, and starts simultaneously with the application system 300, providing service governance capabilities through the Java Agent.
[0054] In one implementation, in order to facilitate the centralized management of governance matters by the service governance execution module 100 by the service governance management platform 200, the service governance execution module 100 needs to report metadata from the application system 300.
[0055] Understandably, the service governance execution module 100 is also used to identify all dependency packages of the application system 300 under the preset path after startup, obtain the metadata of the application system 300 based on all dependency packages, and send it to the service governance management platform 200. The service governance execution module 100 will automatically start when the application system 300 starts.
[0056] For example, the metadata includes component attributes and governance execution module information for each service component 310. The governance execution module information includes service governance order data and service governance capability data; component attributes include dependency package retrieval rules, service component identifiers, and service component versions. The service component identifier can be the service component name. The service governance order data includes the dependency package removal order for each service component 310 and the removal order for each service component. The service governance capability data indicates whether the service governance execution module 100 provides governance capabilities for each service component 310. For example, if the service governance capability data includes the service component identifier of a certain service component, it indicates that the service governance execution module 100 provides governance capabilities for that service component.
[0057] In other words, the service governance execution module 100 is also used to identify all dependency packages of the application system 300 under the preset path after startup, obtain the component attributes of each service component 310, and report each component attribute, as well as its own version information, service governance capabilities, and service governance order data to the service governance management platform 200. Generally, enterprises use a fixed application framework, so the dependency packages of each service component 310 used by the application system 300 are all under the preset path. In this case, based on all dependency packages retrieved under the preset path—for example, if the application system 300 is a Java project—the module searches for all files with the .jar extension under the preset path to obtain all dependency packages.
[0058] Furthermore, to make the service governance execution module 100 compatible with more components, the service governance management platform 200 is also used to receive any newly integrated service component 310 from the application system 300 and add corresponding component attributes to the stored metadata. For example, when service component 310 is built using another framework, the dependency packages of service component 310 do not exist in the preset path. In this case, the user can configure the component attributes (dependent file information) of the service component into the stored metadata. For example, if the metadata is stored in a preset configuration item in the database, the dependency package retrieval rules, service component identifier, and service component version of the service component can be added to that configuration item.
[0059] In one implementation, in order to achieve dynamic component upgrades and timely updates to the functionality of service component 310, such as timely bug fixes and timely feature upgrades, the target governance instructions include service upgrade instructions.
[0060] The service governance management platform 200 is specifically used to send a service upgrade command to the service governance execution module 100 when the latest version of any first target service component stored on the server is inconsistent with the version of the service component integrated in the application system 300. The first target service component is any service component 310 integrated in the application system 300. When the version of the first target service component on the server is updated, if the service governance management platform 200 finds that the latest version of the first target service component on the server is inconsistent with the service component version of the first target service component integrated in the application system 300, it will send a service upgrade command to the service governance execution module 100. The service upgrade command includes information such as the storage address, name, and version of the service component. For example, if the service governance management platform 200 finds that the latest version of the first target service component on the server is inconsistent with the service component version of the first target service component stored in the metadata, it will send a service upgrade command to the service governance execution module 100.
[0061] Understandably, the service governance execution module 100 is specifically used to retrieve the upgrade package of the first target service component according to the address in the service upgrade instruction, and to perform runtime enhancement on eligible classes through bytecode instrumentation during the class loading process of the upgrade package, so as to dynamically upgrade the first target service component. Exemplarily, the service governance execution module 100 is a Java Agent, which implements runtime enhancement based on bytecode technology to achieve dynamic loading. For example, Javassist or ByteBuddy is used to generate bytecode from the upgrade package and load the classes in the upgrade package into the application system 300. For Java projects, in the prior art, `javac` is used to compile `.java` source files into `.class` bytecode files. However, Javassist and ByteBuddy in this embodiment are bytecode manipulation tools, whose function is to dynamically modify existing `.class` files or directly generate new bytecode during runtime or class loading.
[0062] In one implementation, in order to dynamically upgrade the capabilities of the service governance execution module 100 and update the capabilities of the service governance execution module 100 in a timely manner, the target governance instruction includes a governance upgrade instruction.
[0063] The service governance management platform 200 is specifically used to send a governance upgrade command to the service governance execution module 100 when the service governance capabilities of the service governance execution module 100 do not include the second target service component. The second target service component is any service component 310 integrated within the application system 300. Service governance capabilities refer to the ability to upgrade or remove any service component. Here, the service governance capability specifically refers to the ability to upgrade or remove the second target service component.
[0064] The service governance execution module 100 is specifically used to pull its own upgrade package according to the address in the governance upgrade instruction, and to dynamically upgrade the service governance execution module 100 by using bytecode instrumentation technology to enhance eligible classes during the class loading process of the upgrade package.
[0065] As an example, the service governance management platform 200 is specifically used to receive registration information sent by the application system 300 when adding and integrating a second target service component. The registration information includes, but is not limited to, dependency package retrieval rules, service component version, and service component identifier.
[0066] In other words, when a new service component 310 is added to the application system 300, the service governance execution module 100 sends the registration information of the new service component to the service governance management platform 200. After receiving the registration information, the service governance management platform 200 queries whether the service governance execution module 100 has the service governance capability for the new service component.
[0067] The service governance management platform 200 specifically determines whether the service governance capability of the service governance execution module 100 includes service governance of the second target service component by matching the governance service items stored in the platform with the registration information. The governance service items are calculated based on the platform's stored metadata and the registration information, both of which include the service component name and service component version.
[0068] Understandably, the governance service items include the names of all registered service components. If the service component names listed in the registration information are not included in the list of registered service component names, then the service governance capability of the service governance execution module 100 does not include service governance of the second target service component. Generally, this is because the service governance execution module 100 is outdated or has bugs, resulting in a lack of additional service governance capabilities. Therefore, it is necessary to send a governance upgrade command to the service governance execution module 100 to upgrade it and provide more service governance capabilities.
[0069] In one implementation, in order to achieve service removal non-intrusively and to reduce the coupling between the service removal function code and the application system 300 business code, the target governance instruction includes a service removal instruction; the service removal instruction includes dependency package retrieval rules for the service component to be removed.
[0070] The service governance execution module 100 is specifically used to retrieve the dependency packages of the service component to be removed according to the dependency package retrieval rules in the service removal instruction, obtain the highest version dependency package of the service component to be removed, and remove the highest version dependency package.
[0071] Removing a service from an application system 300 involves many dependent packages, such as unregistering Dubbo and XXL-Job, stopping message queue (MQ) consumption, etc. If application system 300 itself does not depend on a certain component and does not need to manage that service component—for example, some application systems 300 do not need the MQ message queue and therefore do not need the ability to stop MQ consumption—this application uses dependency package retrieval rules (regular expressions) obtained from the service governance management platform 200 to search for all dependent JAR files. If a match is found, it indicates that application system 300 depends on that dependency package. This application does not impose specific restrictions on the removal of dependency packages; the removal actions performed vary depending on the service component. For example, to remove the MQ service component, the MQ instance is obtained, and its stop method is called. This stop method disconnects the connection to the MQ message server. Similarly, in RPC communication service governance (taking Dubbo as an example), the RPC service component is unregistered from the registry center, thereby notifying all clients using this RPC service component that the current instance is about to go offline and should no longer call this service node.
[0072] Dependency package retrieval rules include, but are not limited to, using regular expressions to retrieve the dependency packages of service components. For example, for the Dubbo service component, regular expressions are used... The system searches for dependency packages in the current project (preset path). For example, if it finds jar files dubbo-1.0.jar, dubbo-2.0.jar, and dubbo-3.0.jar, it will ultimately remove the dependency package corresponding to dubbo-3.0.jar.
[0073] In one implementation, to ensure the stability of service governance, prevent exceptions, and ensure the normal operation of application system 300, the target governance instruction includes service governance sequence data; the service removal instruction includes the service component identifiers of each service component to be removed.
[0074] The service governance execution module 100 is further specifically used to set the governance order for each service component according to requirements after startup, obtain service governance order data, and send it to the service governance management platform 200. The service governance order data includes the removal order of each service component. If the access order of multiple service components is different, then the removal order will also be different. If removal is not carried out in order, the application system 300 will throw an exception, causing the application system 300 to stop working. The underlying general framework of JavaAgent governance can sort the service governance capabilities of multiple service components under governance to obtain service governance order data.
[0075] Understandably, the service governance execution module 100 is also specifically used to remove each service component to be removed from the service removal instruction according to the service governance order data.
[0076] In one implementation, to reduce coupling and improve stability, the service governance execution module 100 specifically removes the corresponding service component to be removed through an atomically designed removal service. Understandably, each service component's removal service is designed with a corresponding atomic capability, which is used to achieve service removal. The specific atomic capabilities designed vary depending on the service component.
[0077] In one implementation, the auxiliary systems include at least one of an operation and maintenance system 400, a monitoring system 500, and an inspection system 600; the governance recommendations include service removal instructions.
[0078] The service governance execution module 100 is specifically used to receive service removal commands sent by the operation and maintenance system 400, the monitoring system 500, or the inspection system 600. The service governance execution module 100 also retrieves the corresponding component attributes based on the metadata stored locally according to the service component identifier within the service removal command. The service governance execution module 100, i.e., the application system 300, can also store metadata locally. This metadata includes the component attributes of each component. The component attributes include dependency package retrieval rules and the corresponding service component identifier.
[0079] The service component to be removed is determined based on the service component identifier included in the service removal instruction. The dependency package retrieval rules are then obtained from the metadata based on the service component identifier, and the dependency packages of the service component to be removed are searched according to the dependency package retrieval rules.
[0080] If component attributes exist, the service governance execution module 100 retrieves and removes the dependency packages of the service component to be removed based on the component attributes. In other words, it retrieves the dependency packages of the service component to be removed according to the dependency package retrieval rules, removes the dependency packages from the application system, and thus removes the service component from the application system.
[0081] If the metadata is missing, the service governance execution module 100 will forward the governance recommendations to the service governance management platform 200.
[0082] In one implementation, the metadata includes component attributes and governance execution module information for each service component. The service governance management platform 200 is further configured to generate a service removal command based on the component attributes of the third target service component; wherein the third target service component is a target service component determined based on requirements or governance recommendations; and the third target service component is any service component integrated into the application system 300.
[0083] The governance execution module information includes service governance order data and service governance capability data; the component attributes include dependency package retrieval rules, service component identifiers, and service component versions.
[0084] The service governance management platform 200 is specifically used to generate service removal commands based on the dependency package retrieval rules and service component identifiers within the component attributes of the third target service component.
[0085] The following example illustrates the service governance system of this application. In this service removal example, application system 300 connects to operation and maintenance system 400, APM monitoring system, inspection system 600, etc. Application system 300 has a built-in service governance execution module 100, which includes a Java Agent. Service governance is provided through the Java Agent (referred to as Agent service). The dependency package retrieval formula uses regular expressions, such as... Figure 2 As shown, a specific example is as follows:
[0086] S110, start application system 300, and the Java Agent also starts at the same time.
[0087] S120: After startup, the Java Agent identifies all dependency packages of application system 300 under the preset path, obtains the metadata of application system 300, and sends it to the service governance management platform 200. The metadata includes service governance order data, service governance capability data, dependency package retrieval rules, service component identifiers, and service component versions.
[0088] S130, if the APM monitoring system detects a critical vulnerability in service component A within application system 300, the APM monitoring system sends a service removal command to the Agent service to remove service component A. This service removal command includes the service component name of service component A. Therefore, this application can automatically analyze the service components that need to be removed.
[0089] S140, the Agent service searches the local storage metadata to see if the dependency package retrieval formula and service governance order data of the A service component are stored. If not, the Agent service forwards the service removal command to the service governance management platform 200.
[0090] S150, if the service governance management platform 200 receives the service removal command, it will return the regular expression (dependency package retrieval formula) of service component A and the service governance order data.
[0091] S160, the Agent service retrieves all dependency packages of service component A under the preset path of regular expression, obtains the dependency package with the highest version, and removes the dependency package with the highest version.
[0092] Therefore, this application can achieve service removal non-intrusively.
[0093] The service governance system of this application is illustrated below with a service upgrade example. This service upgrade example includes a built-in service governance execution module 100, which contains a Java Agent. Service governance is provided through the Java Agent, such as... Figure 3 As shown, a specific example is as follows:
[0094] S210, the service governance management platform 200 detects that the version of service component B stored in the server has been upgraded, and the latest version of service component B after the upgrade is higher than the service component version of service component B stored in the metadata. Therefore, it is determined that the latest version of service component B is inconsistent with the service component version integrated in the application system 300. Generally, the server will only upgrade service component B after bug fixes or feature upgrades.
[0095] S220, the service governance management platform 200 sends a service upgrade instruction to the application system 300. This service upgrade instruction includes the address (storage address) of the upgrade package for service component B.
[0096] S230, the Agent service retrieves the upgrade package for service component B based on the address in the service upgrade instruction.
[0097] S240, the Agent service uses Javassit or bytebuddy to generate bytecode for the upgrade package and dynamically loads the classes in the upgrade package file into the application system 300 to achieve dynamic upgrade.
[0098] Furthermore, this application also supports dynamic upgrades of the Agent service. When the Agent service reports metadata, the metadata includes the Agent service version. If the Agent service lacks governance capabilities for a certain service component, or after the Agent service's functionality is upgraded, the service governance management platform 200 will also send a governance upgrade command to the Agent service. The Agent service similarly pulls its own upgrade package according to the address in the governance upgrade command, and then dynamically loads the classes within the upgrade package to achieve dynamic upgrades. Therefore, this application can dynamically upgrade the capabilities of service components.
[0099] This application does not rely on an SDK, exhibiting low coupling. It provides service governance capabilities non-intrusively through a Java agent. The application system can automatically discover service components that need to be removed, as well as automatically upgrade and add service components, without requiring application restarts; dynamic loading ensures real-time effectiveness. Finally, this application utilizes only a single, efficient HTTP service to receive instructions from multiple external channels, offering high flexibility.
[0100] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the service governance execution module or the service governance management platform 200 in the above-described service governance system.
[0101] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.
[0102] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.
[0103] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned terminal device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0104] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0105] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0106] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.
[0107] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.
Claims
1. A service governance system, characterized in that, The system includes: A service governance execution module and a service governance management platform; the service governance execution module is mounted to the application system to be governed; wherein, the application system integrates several service components; The service governance execution module is used to communicate with several auxiliary systems that assist the application system in its operation, and to receive governance suggestions sent by the several auxiliary systems. The service governance management platform is used to issue target governance instructions to the service governance execution module according to the requirements or according to the governance suggestions forwarded by the service governance execution module; The service governance execution module is used to govern each of the service components in the application system according to the target governance instruction; The target governance instructions include service removal instructions; the service removal instructions include dependency package retrieval rules for the service components to be removed. The service governance execution module is specifically used to retrieve the dependency packages of the service component to be removed according to the dependency package retrieval rules in the service removal instruction, obtain the highest version dependency package of the service component to be removed, and remove the highest version dependency package. The target governance instruction also includes service governance order data; the service removal instruction also includes service component identifiers for each service component to be removed. The service governance execution module is also specifically used to set the governance order for each service component according to the requirements after startup, obtain service governance order data, and send it to the service governance management platform. The service governance execution module is also specifically used to remove each service component to be removed from the service removal instruction according to the service governance sequence data.
2. The service governance system according to claim 1, characterized in that, The service governance execution module is also used to identify all dependent packages of the application system under the preset path after startup, obtain the metadata of the application system and send it to the service governance management platform; The service governance management platform is also used to receive any service component newly integrated by the user based on the application system, and add the corresponding component attributes to the stored metadata.
3. The service governance system according to claim 1, characterized in that, The target governance instructions include service upgrade instructions; The service governance management platform is specifically used to send a service upgrade instruction to the service governance execution module when the latest version of any first target service component stored in the server is inconsistent with the version of the service component integrated in the application system. The service governance execution module is specifically used to pull the upgrade package of the first target service component according to the address in the service upgrade instruction, and to perform runtime enhancement on the qualified classes through bytecode instrumentation during the class loading process of the upgrade package, so as to dynamically upgrade the first target service component.
4. The service governance system according to claim 1, characterized in that, The target governance instructions include governance upgrade instructions; The service governance management platform is specifically used to send a governance upgrade instruction to the service governance execution module when the service governance capability of the service governance execution module does not include the second target service component. The service governance execution module is used to pull its own upgrade package according to the address in the governance upgrade instruction, and to dynamically upgrade the service governance execution module by using bytecode instrumentation technology to perform runtime enhancement on classes that meet the conditions during the class loading process of the upgrade package of the service governance execution module.
5. The service governance system according to claim 1, characterized in that, The service governance management platform is also used to receive registration information sent by the application system when adding and integrating the second target service component; The service governance management platform is specifically used to determine whether the service governance capabilities of the service governance execution module include service governance of the second target service component by matching the governance service items stored in the platform with the registration information; wherein the governance service items are obtained by statistical analysis based on the metadata stored in the platform and the registration information.
6. The service governance system according to claim 1, characterized in that, The service governance execution module specifically removes the corresponding service components to be removed through atomic design of service removal.
7. The service governance system according to claim 1, characterized in that, The auxiliary systems include at least one of the operation and maintenance system, monitoring system, and inspection system; the governance recommendations include service removal instructions; The service governance execution module is specifically used to receive service removal instructions sent by the operation and maintenance system, the monitoring system, or the inspection system, and to obtain the corresponding component attributes based on the metadata stored locally according to the service component identifier in the service removal instruction. If the component attributes exist, the module retrieves the dependency packages of the service component to be removed based on the component attributes and removes them. If the metadata is not present, the governance recommendations will be forwarded to the service governance management platform.
8. The service governance system according to claim 2, 5, or 7, characterized in that, The target governance instructions include service removal commands; the metadata includes component attributes and governance execution module information for each service component; wherein, the governance execution module information further includes service governance order data and service governance capability data; the component attributes further include dependency package retrieval rules, service component identifier, and service component version; The service governance management platform is specifically used to generate the service removal command based on the dependency package retrieval rules and service component identifier within the component attributes of the third target service component; wherein, the third target service component is a target service component determined according to the requirements or the governance recommendations.
Citation Information
Patent Citations
Micro-service governance method, device and system
CN115878207A
Micro-service governance method, device, equipment and medium
CN118819674A