Application service topology processing method and device, equipment and storage medium

Abstract

The embodiment of the invention provides an application service topology processing method and device, equipment and a computer readable storage medium. The method comprises the following steps: acquiring dependency information related to a software system; based on the dependency information, constructing a topology view for the software system, the topology view comprising at least one of the following items: service upstream and downstream topologies, the service upstream and downstream topologies used for displaying a calling relationship among the application services, service resource topologies, the service resource topologies used for displaying resources respectively associated with the application services, and middleware topologies, the middleware topology is used for displaying application services associated with the middleware; and in response to the detected fault of the application service or resource in the software system, determining the range of the application service and / or resource influenced by the fault in the software system based on the topology view. According to the scheme disclosed by the invention, the topological view is constructed in a layered manner, so that various dependency relationships in a software system are cleared, and the influence range can be quickly positioned when a fault occurs.

Description

Technical Field

[0001] Example embodiments of the present disclosure generally relate to the field of computer technology, and more particularly, to a method, apparatus, device, and computer-readable storage medium for application service topology processing. Background Art

[0002] In modern software systems, especially in complex distributed systems and microservice architectures, there are a large number of calls and dependencies between software entities (such as services, database resources, domain name resources, etc.).

[0003] In related technologies, software topology networks can be used to represent the various software entities that make up a system, their dependencies, and their invocation methods. However, this approach often displays the relationships between various software entities in a system within a single topology view. Furthermore, due to the complexity of these relationships, the topology view suffers from information clutter, poor loading performance, and difficulty distinguishing dependencies.

[0004] Therefore, a clearer and more efficient application service topology processing solution is needed to deal with these problems. Summary of the Invention

[0005] In a first aspect of the present disclosure, a method for application service topology processing is provided. The method includes: obtaining dependency information related to a software system, the dependency information indicating the dependency relationship between each application service and resource in the software system; constructing a topology view for the software system based on the dependency information, the topology view including at least one of the following: a service upstream and downstream topology, the service upstream and downstream topology being used to display the call relationship between each application service; a service resource topology, the service resource topology being used to display the resources associated with each application service; and a middleware topology, the middleware topology being used to display the application services associated with each middleware; and in response to detecting a fault in an application service or resource in the software system, determining, based on the topology view, the scope of the application services and / or resources in the software system affected by the fault.

[0006] In a second aspect of the present disclosure, a device for application service topology processing is provided. The device includes: an acquisition module configured to acquire dependency information related to a software system, wherein the dependency information indicates the dependency relationship between each application service and resource in the software system; a construction module configured to construct a topology view for the software system based on the dependency information, wherein the topology view includes at least one of the following: a service upstream and downstream topology, wherein the service upstream and downstream topology is used to display the call relationship between each application service; a service resource topology, wherein the service resource topology is used to display the resources associated with each application service; and a middleware topology, wherein the middleware topology is used to display the application services associated with each middleware; and a determination module configured to determine, in response to detecting a fault in an application service or resource in the software system, the scope of the application services and / or resources affected by the fault in the software system based on the topology view.

[0007] In a third aspect of the present disclosure, an electronic device is provided. The electronic device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the electronic device to perform the method of the first aspect of the present disclosure.

[0008] In a fourth aspect of the present disclosure, a computer-readable storage medium is provided, wherein a computer program is stored on the computer-readable storage medium and can be executed by a processor to perform the method according to the first aspect of the present disclosure.

[0009] It should be understood that the contents described in the Summary of the Invention are not intended to limit the key features or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The above and other features, advantages and aspects of the various embodiments of the present disclosure will become more apparent hereinafter with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals represent the same or similar elements, wherein:

[0011] Figure 1 A schematic diagram illustrating an example environment in which embodiments of the present disclosure can be implemented;

[0012] Figure 2 A flowchart illustrating a process of application service topology processing according to some embodiments of the present disclosure is shown;

[0013] Figure 3A A flowchart illustrating a process of obtaining dependency information of an application service according to some embodiments of the present disclosure is shown;

[0014] Figure 3B A flowchart illustrating a process of constructing a service upstream and downstream topology according to some embodiments of the present disclosure is shown;

[0015] Figure 3C A schematic diagram showing a service upstream and downstream topology according to some embodiments of the present disclosure is shown;

[0016] Figure 3D A flowchart illustrating a process of constructing a service resource topology according to some embodiments of the present disclosure is shown;

[0017] Figure 3E A schematic diagram showing a service resource topology according to some embodiments of the present disclosure is shown;

[0018] Figure 3F A flowchart illustrating a process of constructing a middleware topology according to some embodiments of the present disclosure is shown;

[0019] Figure 3G A schematic diagram showing a middleware topology according to some embodiments of the present disclosure;

[0020] Figure 3H A flowchart illustrating a process of redrawing a topology view according to some embodiments of the present disclosure is shown;

[0021] Figure 4 A block diagram illustrating an apparatus for application service topology processing according to some embodiments of the present disclosure; and

[0022] Figure 5 A block diagram of an electronic device is shown in which one or more embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION

[0023] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although some embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Instead, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0024] In the description of the embodiments of the present disclosure, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to." The term "based on" should be understood as "based at least in part on." The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment." The term "some embodiments" should be understood as "at least some embodiments." Other explicit and implicit definitions may be included below.

[0025] It should be noted that the acquisition, storage and application of user personal information involved in the technical solution of this disclosure are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0026] It is understandable that before using the technical solutions disclosed in the various embodiments of this disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved in this disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0027] For example, in response to receiving a user's active request, a prompt message is sent to the user to clearly remind the user that the operation requested to be performed will require obtaining and using the user's personal information, so that the user can independently choose whether to provide personal information to the electronic device, application, server or storage medium and other software or hardware that performs the operation of the technical solution of the present disclosure based on the prompt message.

[0028] As an optional but non-limiting implementation, in response to receiving a user's active request, a prompt message may be sent to the user, for example, in the form of a pop-up window, in which the prompt message may be presented in text form. Furthermore, the pop-up window may also include a selection control for the user to select "agree" or "disagree" to provide personal information to the electronic device.

[0029] As briefly mentioned above, in modern software systems, especially in complex distributed systems and microservices architectures, numerous calls and dependencies exist between software entities (such as services, database resources, host resources, domain name resources, etc.). These dependencies are an important foundation for software design, development, and debugging. In related technologies, software topology networks can be used to represent the various software entities that make up a system, their relationships, and their call methods. For example, some application performance monitoring and management software can be used to draw a topological view of a software system.

[0030] However, with the popularity of distributed service architectures, the relationships between application services and resources in software systems have become increasingly complex. The topology views in related technologies have the following shortcomings:

[0031] Information clutter: Displaying the relationships between different types of software entities in a software system in a topological view makes the diagram appear very cluttered.

[0032] Poor loading performance: Due to the large number of service-related and dependent nodes, the entire topology view takes a long time to load, and may even cause loading crashes due to excessive dependencies.

[0033] Difficulty distinguishing dependencies: The topology view makes it difficult to distinguish between service dependencies, resource dependencies, and middleware dependencies. This results in inaccurate analysis of the impact scope and fault location when an application service or resource in the software system fails.

[0034] In view of this, an improved solution for application service topology processing is proposed in an embodiment of the present disclosure. According to an embodiment of the present disclosure, dependency information related to the software system is obtained, and the dependency information indicates the dependency relationship between each application service and resource in the software system; based on the dependency information, a topology view for the software system is constructed, and the topology view includes at least one of the following: service upstream and downstream topology, which is used to display the call relationship between each application service; service resource topology, which is used to display the resources associated with each application service; middleware topology, which is used to display the application services associated with each middleware; and in response to detecting a failure of an application service or resource in the software system, based on the topology view, the scope of the application services and / or resources affected by the failure in the software system is determined.

[0035] By building a layered topology view and separating service dependencies, resource dependencies, and middleware dependencies into independent topology views, developers and operations personnel can better understand the system structure and optimize it more effectively. Furthermore, when a failure occurs, they can quickly understand the impact on other parts of the system, allowing them to make timely and effective decisions.

[0036] Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings.

[0037] Figure 1 1 shows a schematic diagram of an example environment 100 in which embodiments of the present disclosure can be implemented. Figure 1 In the environment 100, the electronic device 110 can obtain dependency information 120 related to the software system. According to an embodiment of the present disclosure, the dependency information 120 can indicate the dependency relationship between each application service and resource in the software system. Based on the dependency information 120, the electronic device 110 can construct a topology view 130 for the software system. In some embodiments, the topology view 130 includes at least one of the following: a service upstream and downstream topology 131, the service upstream and downstream topology 131 is used to display the call relationship between each application service, a service resource topology 132, the service resource topology 132 is used to display the resources associated with each application service, and a middleware topology 133, the middleware topology 133 is used to display the application services associated with each middleware.

[0038] exist Figure 1In the present invention, electronic device 110 may include any computing system with computing capabilities, such as various computing devices / systems, terminal devices, servers, etc. Terminal devices may refer to any type of mobile, fixed, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. Servers include but are not limited to mainframes, edge computing nodes, computing devices in cloud environments, etc.

[0039] It should be understood that Figure 1 The components and arrangements in the illustrated environment 100 are merely examples, and a computing system suitable for implementing the exemplary implementations described herein may include one or more different components, other components, and / or different arrangements. Implementations of the present disclosure are not limited in this respect.

[0040] Figure 2 FIG. 2 is a flow chart illustrating a process 200 for application service topology processing according to some embodiments of the present disclosure. The process 200 may be implemented in the environment 100 , for example, the process 200 may be implemented at the electronic device 110 .

[0041] In block 210 , the electronic device 110 obtains dependency information related to the software system.

[0042] In some embodiments, dependency information indicates the dependency relationships between various application services and resources in the software system. Electronic device 110 needs to first obtain dependency information related to the software system. The dependency information indicates the dependency relationships between various application services and resources in the software system. For example, dependency information includes information describing the mutual calls and dependencies between application services and resources in the software system. This information includes how different components in the software system interact, how they depend on each other, and how data flows.

[0043] In some embodiments, dependency information can be configured by relevant technical personnel or collected and stored in a configuration management database (CMDB) or other similar data systems through monitoring and management tools. Obtaining this dependency information is the basis for building a topology view for the software system.

[0044] In some embodiments, the dependency information includes at least one of the following: service dependency information, which indicates the calling relationship between the caller application service and the callee application service in the software system; and resource dependency information, which indicates the association relationship between the application service and the resource in the software system.

[0045] Service dependency information indicates the calling relationships between caller and callee application services within a software system. Specifically, this information records the methods and paths by which one application service calls other application services or is used by other application services. This information helps understand the calling relationships between different services in the system and facilitates analysis of the system's overall structure and organizational relationships. For example, service A may call service B to obtain specific data or perform certain functions, and service B may in turn call service C to complete certain operations. Service dependency information records this service call chain, including the relationship between the caller and the callee. Resource dependency information indicates the relationships between application services and resources in the system. These resources include database components, caches, message queues, and more. Resource dependency information describes which resources are used by which application services and the relationships between them. Service and resource dependency information helps understand the dependencies between services and between application services and resources, helping developers and operations personnel understand the system structure and optimize resource allocation.

[0046] For example, you can refer to Figure 3A , Figure 3A FIG. 3 is a flow chart illustrating a process 300A for obtaining dependency information of an application service according to some embodiments of the present disclosure. The process 300A may be implemented at the electronic device 110 .

[0047] In block 311 , the electronic device 110 receives service dependency information via a dependency configuration page.

[0048] In some embodiments, the service dependency information of different application services can be configured through the dependency configuration page. For example, on the dependency configuration interface, an administrator or operator can manually configure the calling relationship between application services. This configuration is usually presented in a graphical manner, and the user can select the calling service and the called application service on the interface. The service dependency information of these configurations is recorded by the system. After the configuration is completed, the electronic device 110 can receive this service dependency information.

[0049] At block 312 , the electronic device 110 obtains resource dependency information from a configuration management database.

[0050] In some embodiments, the electronic device 110 may obtain the association relationship between application services and resources in the software system by querying the configuration management database CMDB.

[0051] A CMDB is a database that stores system configuration information and relationships, typically used to record the attributes, status, and dependencies of various resources in the system. Specifically, a CMDB may contain information about various resources, such as databases, caches, and message queues. Records of these resources may include their names, types, IP addresses, operating status, and their associations with application services. By querying the CMDB, you can obtain information about the resources that each application service in the system depends on, as well as the relationships between resources and services. For example, you can query resources such as database instances, cache servers, or message queues that a particular application service depends on.

[0052] In the disclosed embodiment, electronic device 110 can receive service dependency information via a dependency configuration page and obtain resource dependency information from a configuration management database. Configuring service dependency information on this page and obtaining resource dependency information from a configuration management database can accurately determine complex dependencies in a software system, helping to understand the overall system structure and resource usage, thereby improving system reliability and performance.

[0053] Continue to refer Figure 2 In block 220 , the electronic device 110 constructs a topology view for the software system based on the dependency information.

[0054] In some embodiments, the topology view includes at least one of the following: service upstream and downstream topology, which is used to display the calling relationship between various application services; service resource topology, which is used to display the resources associated with each application service; and middleware topology, which is used to display the application services associated with each middleware.

[0055] The service upstream and downstream topology displays the call relationships between application services. It reveals the dependencies between services, specifically which services are called and which services call other services. This topology provides a clear understanding of the interactions between services in the system, helping to locate issues and optimize performance.

[0056] The service resource topology displays the resources associated with each application service. This helps you understand the resources used by each service and the extent to which these resources impact business data. This helps you better manage and optimize system resources.

[0057] The middleware topology shows the relationships between various middleware components and application services. Middleware resources are a specific type of resource within a software system that coordinates communication, data transfer, and state management between different components. For example, middleware resources can include message queue systems (such as RabbitMQ and Kafka), database management systems (such as MySQL and MongoDB), and cache systems (such as Redis). Middleware resources play a critical role in the system architecture and are often shared and relied upon by multiple application services. Therefore, understanding the dependencies between middleware resources and application services is crucial.

[0058] For example, you can refer to Figure 3B , Figure 3B A flowchart of a process 300B of building a service upstream and downstream topology according to some embodiments of the present disclosure is shown.

[0059] In block 321 , the electronic device 110 may determine an upstream node and a downstream node of each application service based on the service dependency information in the dependency information.

[0060] In some embodiments, an upstream node is a node corresponding to an upstream application service that calls the application service, and a downstream node is a node corresponding to a downstream application service called by the application service. For example, a software system contains three application services, A, B, and C, where application service A calls application service B, and application service B calls application service C. In this case, application service B is the downstream node of application service A, and application service A is the upstream node of application service B. Similarly, application service C is the downstream node of application service B, and application service B is the upstream node of application service C. Electronic device 110 can determine the upstream and downstream nodes of each application service based on the service dependency information in the dependency information.

[0061] In block 322 , the electronic device 110 may determine the start node and the target node of the node corresponding to each application service in the service upstream and downstream topology based on the upstream node and the downstream node of each application service to obtain the service upstream and downstream topology.

[0062] In some embodiments, the electronic device 110 can determine the starting node and target node of each application service in the topology based on the determined upstream and downstream nodes. Based on the determined starting and target nodes, the electronic device 110 can construct a service upstream and downstream topology.

[0063] In some embodiments, nodes in a topology represent specific application services or resources in a software system. These nodes are represented in the topology using graphical symbols or symbols. For example, a node in a topology diagram might represent a specific microservice, which corresponds to an independent service instance in the software system; another node might represent a database resource, which corresponds to a specific database resource instance in the software system. In short, nodes in a topology are abstract representations of application services, resources, or components in a software system, and the topological view they form reflects the structure and dependencies of the system.

[0064] In some embodiments, the calling relationship between services can be represented by arrows in the topology view, and the arrows point to the called services, reflecting the direction of the calling relationship. Figure 3C , Figure 3C Schematic diagram of an example service upstream and downstream topology according to some embodiments of the present disclosure is shown. Figure 3C As shown, application service A calls application service B, and application service B calls application service C and application service D. In this case, the node corresponding to application service B (also called node B) is the downstream node of the node corresponding to application service A (also called node A), and node A is the upstream node of node B. Similarly, the node corresponding to application service C (also called node C) and the node corresponding to application service D (also called node D) are both downstream nodes of node B, and node B is the upstream node of node C and node D. In the upstream and downstream service topology corresponding to application service B, node A is the starting node, node B is the destination node of node A, and node C and node D are the destination nodes of node B. In the topology view, there will be arrows pointing from node A to node B and from node B to node C and node D to indicate the calling relationship between them. Of course, for the purpose of explanation, in Figure 3C A simple example of the upstream and downstream service topology is shown in FIG. 4 , but in actual applications, the topology may include more nodes and more complex call relationships.

[0065] In the disclosed embodiments, by constructing a service upstream and downstream topology, system administrators and developers can clearly understand the call relationships between various application services. When a system failure or anomaly occurs, the root cause of the problem can be quickly located. Using the service upstream and downstream topology, the path of the problem can be traced, identifying the service that caused the problem and its upstream and downstream services, facilitating rapid troubleshooting and repair. Furthermore, by understanding the dependencies between various services, application services can be upgraded and expanded more effectively, avoiding impacts on the normal operation of other services.

[0066] For example, you can refer to Figure 3D , Figure 3DA flowchart of a process 300D of constructing a service resource topology according to some embodiments of the present disclosure is shown.

[0067] In block 331 , the electronic device 110 may construct nodes corresponding to each application service and nodes corresponding to resources that each application service depends on in a service resource topology based on the resource dependency information in the dependency information.

[0068] In some embodiments, the electronic device 110 may determine the resources that each application service depends on based on the resource dependency information, and construct nodes corresponding to each application service and nodes corresponding to the resources that each application service depends on.

[0069] In block 332 , the electronic device 110 may obtain a service resource topology by constructing a node corresponding to each application service as a start node and constructing a node corresponding to a resource on which each application service depends as a destination node.

[0070] For example, you can refer to Figure 3E , Figure 3E A schematic diagram of a service resource topology according to some embodiments of the present disclosure is shown. , the electronic device 110 can determine the application service C in the software system based on the resource dependency information, and the resources that the application service C depends on include resource 1, resource 2, resource 3, and middleware a and middleware b. Then the electronic device 110 can construct the service resource topology with the node corresponding to the application service C as the starting node in the service resource topology, and the nodes corresponding to all resources associated with the service, resource 1, resource 2, resource 3, and middleware a and middleware b as the destination nodes. And in the service resource topology, arrows are used to represent the dependency relationship between the node corresponding to the application service and the node corresponding to the resource. The arrow points to the node corresponding to the resource, indicating that the service uses the resource. Of course, for the purpose of explanation, in Figure 3E A simple example of a service resource topology is shown in FIG. 4 , but in actual applications, the topology may include more nodes and more complex call relationships.

[0071] In the disclosed embodiments, by constructing a service resource topology, complex dependencies are presented in an intuitive topological view, helping system administrators and developers better understand the system architecture and resource usage, facilitating resource management and optimization. Furthermore, when an application service fails, all the resources it depends on can be quickly viewed to determine the potential impact of the failure.

[0072] For example, you can refer to Figure 3F , Figure 3F A flowchart of a process 300F of building a middleware topology according to some embodiments of the present disclosure is shown.

[0073] In block 341 , the electronic device 110 may construct nodes corresponding to middleware resources and nodes corresponding to application services that depend on the middleware resources in the middleware topology based on the resource dependency information in the dependency information.

[0074] In block 342 , the electronic device 110 may obtain a middleware topology by constructing nodes corresponding to middleware resources as start nodes and constructing nodes corresponding to application services that rely on the middleware resources as destination nodes.

[0075] In some embodiments, the electronic device 110 may determine each middleware resource and the application service that depends on the middleware resource based on the resource dependency information, and then construct a middleware topology using the middleware resource as the starting node and the application resource as the destination node.

[0076] For example, you can refer to Figure 3G , Figure 3G A schematic diagram of a middleware topology according to some embodiments of the present disclosure is shown. In the software system, application services A, B, and D all need to use middleware resource a. Therefore, the node corresponding to middleware a can be used as the starting node, and the nodes corresponding to application services A, B, and D can be used as the destination nodes to construct the middleware topology. Arrows are used to represent the dependency relationship between the nodes corresponding to the middleware resources and the nodes corresponding to the application services. The arrow points to the application service node, indicating that the operation of the service depends on the middleware resource. Of course, for the purpose of explanation, Figure 3G A simple example of a middleware topology is shown in FIG, but in actual applications, the topology may include more nodes and more complex call relationships.

[0077] In the disclosed embodiments, middleware resources, as a specific type of resource in the software system, play an important role in the system architecture and are typically shared and relied upon by multiple application services. Therefore, understanding the relationship and dependencies between middleware and application services is crucial. By constructing a middleware topology, the association between middleware resources and application services can be clearly displayed, helping system administrators and developers understand the usage of each middleware in the system and which services are affected when a middleware fails. This facilitates system troubleshooting, performance optimization, and resource management.

[0078] Continue to refer Figure 2 In block 230 , in response to detecting a failure of an application service or resource in the software system, the electronic device 110 determines a scope of application services and / or resources in the software system that are affected by the failure based on the topology view.

[0079] In some embodiments, a failure of an application service or resource in a software system may affect the overall operation of the system. To cope with this situation, the constructed topology view can be used to quickly determine the affected scope.

[0080] When an application service or resource in a software system fails, the system detects this anomaly. The service upstream and downstream topology can be used to identify the upstream and downstream services associated with the failed application service. This helps determine which services may be affected by the failure. For example, if service A fails, the topology diagram can be used to view the upstream services (services that call A) and downstream services (services called by A) directly connected to service A. The service resource dependency topology can be used to identify all resources associated with the failed service. For example, if service B fails, the database, server host, middleware, and other resources it depends on can be viewed to determine whether these resources are also affected. The middleware dependency topology can be used to identify all application services associated with the failed middleware. For example, if the middleware Redis fails, it can be used to view which services depend on Redis and determine whether these services are affected.

[0081] In the disclosed embodiments, electronic device 110 can quickly locate the impact scope of a fault using various topology views, eliminating the need to check all services and resources one by one, greatly improving troubleshooting efficiency. Furthermore, once the affected scope is clearly identified, appropriate measures can be taken to isolate the fault, prevent further spread of the problem, and reduce the impact on the overall system.

[0082] For example, you can refer to Figure 3H , Figure 3H A flowchart of a process 300H of redrawing a topology view according to some embodiments of the present disclosure is shown.

[0083] In block 351 , the electronic device 110 may receive a selection of a node corresponding to an application service or resource in a topology view.

[0084] In block 352 , the electronic device 110 redraws the topology view using the node corresponding to the selected application service or resource as a starting node.

[0085] In some embodiments, the topology view allows users to jump to or dynamically redraw the topology view by clicking on the node corresponding to the application service or resource. When the user clicks on a node (application service or resource) in the topology view, the electronic device 110 can receive the selection operation and use the selected node as the new starting node to regenerate and display the corresponding topology view.

[0086] As an example, in the service upstream and downstream topology, each node corresponding to an application service can be selected by clicking or other operations. Clicking a node corresponding to an application service redraws the topology view to display the service upstream and downstream topology centered on that node. For example, the service upstream and downstream topology for application service A is currently displayed. By clicking the node corresponding to application service B in the service upstream and downstream topology, the system redraws the topology view (that is, jumps to the service upstream and downstream topology for application service B) to display the upstream and downstream service dependencies of application service B.

[0087] As another example, in the service resource topology, nodes corresponding to resources (such as domain names and database nodes) can be selected. After selecting a node corresponding to a resource by clicking or other operations, the topology view can be redrawn (that is, jumping to the topology view with that resource as the starting node). For example, if the node MW1 corresponding to a certain middleware (such as RocketMQ) is selected in the service resource topology of application service A, the system will display the middleware topology with MW1 as the starting node, indicating which application services depend on that middleware resource.

[0088] As another example, in the middleware topology, the node corresponding to an application service can be selected. After selecting the node corresponding to an application service by clicking or other operations, the topology view is redrawn with the node corresponding to the application service as the starting node (that is, jumping to the upstream and downstream dependency topology of the application service). In the middleware topology of the RocketMQ (MW1) middleware, application service A and application service C are displayed. Selecting the node corresponding to application service A will open a new page showing the upstream and downstream service topology of service A.

[0089] In the embodiment of the present disclosure, the electronic device 110 can dynamically redraw the topology map to gradually present the dependency relationship starting from one node and trace the dependency path, which helps to fully understand the system structure and dependency situation and facilitates rapid determination of the root cause of the fault.

[0090] Figure 4 FIG2 is a block diagram of an apparatus 400 for processing application service topology according to some embodiments of the present disclosure. The apparatus 400 may be implemented as or included in the electronic device 110.

[0091] The device 400 includes an acquisition module 410, which is configured to acquire dependency information related to the software system, where the dependency information indicates the dependency relationship between each application service and resource in the software system; a construction module 420, which is configured to construct a topology view for the software system based on the dependency information, where the topology view includes at least one of the following: a service upstream and downstream topology, which is used to display the calling relationship between each application service; a service resource topology, which is used to display the resources associated with each application service; and a middleware topology, which is used to display the application services associated with each middleware; and a determination module 430, which is configured to determine, in response to detecting a failure of an application service or resource in the software system, the scope of the application services and / or resources affected by the failure in the software system based on the topology view.

[0092] In some embodiments, the dependency information includes at least one of the following: service dependency information, which indicates the calling relationship between the caller application service and the callee application service in the software system; and resource dependency information, which indicates the association relationship between the application service and the resource in the software system.

[0093] In some embodiments, the acquisition module 410 is further configured to receive service dependency information via a dependency configuration page; and / or acquire resource dependency information from a configuration management database.

[0094] In some embodiments, the construction module 420 is further configured to determine the upstream node and downstream node of each application service based on the service dependency information in the dependency information, where the upstream node is the node corresponding to the upstream application service that calls the application service, and the downstream node is the node corresponding to the downstream application service called by the application service; and based on the upstream node and downstream node of each application service, determine the starting node and target node of the node corresponding to the application service in the service upstream and downstream topology to obtain the service upstream and downstream topology.

[0095] In some embodiments, the construction module 420 is further configured to construct nodes corresponding to each application service and nodes corresponding to resources that each application service depends on in the service resource topology based on the resource dependency information in the dependency information; and to obtain the service resource topology by constructing the node corresponding to each application service as a starting node and the node corresponding to the resource that each application service depends on as a destination node.

[0096] In some embodiments, the construction module 420 is further configured to construct nodes corresponding to middleware resources and nodes corresponding to application services that depend on middleware resources in the middleware topology based on resource dependency information in the dependency information; and to obtain the middleware topology by constructing the nodes corresponding to the middleware resources as starting nodes and the nodes corresponding to application services that depend on the middleware resources as destination nodes.

[0097] In some embodiments, the apparatus 400 further includes a redrawing module 440 configured to receive a selection of a node corresponding to an application service or resource in the topology view; and redraw the topology view using the node corresponding to the selected application service or resource as a starting node.

[0098] The modules included in the device 400 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more units can be implemented using software and / or firmware, such as machine executable instructions stored on a storage medium. In addition to or as an alternative to machine executable instructions, some or all of the units in the device 400 can be implemented at least in part by one or more hardware logic components. By way of example and not limitation, exemplary types of hardware logic components that can be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0099] Figure 5 1 shows a block diagram of an electronic device 500 in which one or more embodiments of the present disclosure may be implemented. Figure 5 The electronic device 500 shown is merely exemplary and should not be construed as limiting the functionality and scope of the embodiments described herein. The electronic device 500 may be implemented as or included in Figure 1 electronic device 110 or Figure 4 In the device 400.

[0100] like Figure 5 As shown, electronic device 500 is in the form of a general electronic device. Components of electronic device 500 may include, but are not limited to, one or more processors or processing units 510, memory 520, storage device 530, one or more communication units 540, one or more input devices 550, and one or more output devices 560. Processing unit 510 may be a real or virtual processor and is capable of performing various processes according to programs stored in memory 520. In a multi-processor system, multiple processing units execute computer-executable instructions in parallel to increase the parallel processing capabilities of electronic device 500.

[0101] The electronic device 500 typically includes a plurality of computer storage media. Such media can be any available media accessible to the electronic device 500, including but not limited to volatile and non-volatile media, removable and non-removable media. The memory 520 can be a volatile memory (e.g., registers, cache, random access memory (RAM)), a non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. The storage device 530 can be a removable or non-removable medium and can include a machine-readable medium, such as a flash drive, a disk, or any other medium that can be used to store information and / or data and can be accessed within the electronic device 500.

[0102] The electronic device 500 may further include additional removable / non-removable, volatile / non-volatile storage media. Figure 5 As shown in FIG, a magnetic disk drive for reading from or writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, non-volatile optical disk may be provided. In these cases, each drive may be connected to a bus (not shown) by one or more data media interfaces. Memory 520 may include a computer program product 525 having one or more program modules configured to perform various methods or actions of various embodiments of the present disclosure.

[0103] The communication unit 540 enables communication with other electronic devices via a communication medium. Additionally, the functions of the components of the electronic device 500 can be implemented in a single computing cluster or multiple computing machines that can communicate via a communication connection. Thus, the electronic device 500 can operate in a networked environment using a logical connection with one or more other servers, a network personal computer (PC), or another network node.

[0104] Input device 550 may be one or more input devices, such as a mouse, keyboard, or trackball. Output device 560 may be one or more output devices, such as a display, a speaker, or a printer. Electronic device 500 may also communicate with one or more external devices (not shown) via communication unit 540 as needed, such as a storage device, a display device, or the like, with one or more devices that allow a user to interact with electronic device 500, or with any device that allows electronic device 500 to communicate with one or more other electronic devices (e.g., a network card, a modem, etc.). Such communication may be performed via an input / output (I / O) interface (not shown).

[0105] According to an exemplary implementation of the present disclosure, a computer-readable storage medium is provided, on which one or more computer instructions are stored, wherein the one or more computer instructions are executed by a processor to implement the method described above. According to an exemplary implementation of the present disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, and the computer-executable instructions are executed by a processor to implement the method described above.

[0106] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products implemented according to the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0107] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, such that when these instructions are executed by the processing unit of the computer or other programmable data processing device, a device is generated that implements the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0108] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0109] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to multiple implementations of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a part for a module, program segment or instruction, and a part for a module, program segment or instruction comprises one or more executable instructions for realizing the logical function of the specification. In some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be realized by a special hardware-based system that performs the function or action of the specification, or can be realized by a combination of special hardware and computer instructions.

[0110] While various implementations of the present disclosure have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is selected to best explain the principles of the implementations, their practical applications, or improvements to existing technologies, or to enable others skilled in the art to understand the implementations disclosed herein.

Claims

1. A method for application service topology processing, comprising: Obtaining dependency information related to a software system, wherein the dependency information indicates dependency relationships between various application services and resources in the software system; Based on the dependency information, a topology view for the software system is constructed, wherein the topology view includes at least one of the following: The service upstream and downstream topology is used to show the calling relationship between various application services. The service resource topology is used to display the resources associated with each application service. Middleware topology, where the middleware topology is used to display application services associated with each middleware; as well as In response to detecting a failure of an application service or resource in the software system, a scope of the application services and / or resources in the software system affected by the failure is determined based on the topology view.

2. The method according to claim 1, wherein the dependency information comprises at least one of the following: Service dependency information, the service dependency information indicating the calling relationship between the calling application service and the called application service in the software system, Resource dependency information, wherein the resource dependency information indicates an association relationship between application services and resources in the software system.

3. The method according to claim 2, wherein obtaining dependency information of the application service comprises: Receiving the service dependency information via a dependency configuration page; and / or The resource dependency information is obtained from a configuration management database.

4. The method according to claim 1, wherein constructing a topology view for the software system based on the dependency information comprises: Based on the service dependency information in the dependency information, determine the upstream node and the downstream node of each application service, the upstream node is a node corresponding to the upstream application service that calls the application service, and the downstream node is a node corresponding to the downstream application service called by the application service; as well as Based on the upstream node and the downstream node of each application service, a start node and a target node of a node corresponding to the application service in the service upstream and downstream topology are determined to obtain the service upstream and downstream topology.

5. The method according to claim 1, wherein constructing a topology view for the software system based on the dependency information comprises: Based on the resource dependency information in the dependency information, construct nodes corresponding to each application service in the service resource topology and nodes corresponding to resources that each application service depends on; as well as The service resource topology is obtained by constructing a node corresponding to each application service as a start node and a node corresponding to a resource on which each application service depends as a destination node.

6. The method according to claim 1, wherein said constructing a topology view for said software system based on said dependency information comprises: Based on the resource dependency information in the dependency information, construct nodes corresponding to the middleware resources in the middleware topology and nodes corresponding to the application services that depend on the middleware resources; as well as The middleware topology is obtained by constructing nodes corresponding to middleware resources as start nodes and nodes corresponding to application services dependent on the middleware resources as destination nodes.

7. The method according to claim 1, further comprising: Receiving a selection of a node corresponding to an application service or a resource in the topology view; as well as The topology view is redrawn with the node corresponding to the selected application service or resource as the starting node.

8. An application service topology processing device, comprising: An acquisition module is configured to acquire dependency information related to a software system, wherein the dependency information indicates dependency relationships between various application services and resources in the software system; A construction module is configured to construct a topology view for the software system based on the dependency information, wherein the topology view includes at least one of the following: The service upstream and downstream topology is used to show the calling relationship between various application services. The service resource topology is used to display the resources associated with each application service. Middleware topology, where the middleware topology is used to display application services associated with each middleware; as well as The determination module is configured to, in response to detecting a failure of an application service or resource in the software system, determine, based on the topology view, a scope of application services and / or resources in the software system that are affected by the failure.

9. An electronic device, comprising: at least one processing unit; as well as At least one memory, the at least one memory being coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to any one of claims 1 to 7 when executed by the at least one processing unit.

10. A computer-readable storage medium having a computer program stored thereon, wherein the computer program can be executed by a processor to implement the method according to any one of claims 1 to 7.

Images