Flow Topology Generation Method and System

Abstract

The present application provides a method and system for generating a traffic topology. According to the embodiments of the present application, first, obtain the observability data, rule configuration data, and workload data obtained by the service mesh proxy; then perform fusion analysis on the obtained observability data, rule configuration data, and workload data to obtain service dependency relationships, and further generate a traffic topology.

Description

Technical Field

[0001] This application relates to service meshes, and in particular to a method and system for generating traffic topologies based on service mesh traffic topologies. Background Art

[0002] Service meshes are often used to describe the microservice network that makes up an application and the interactions between applications. In practice, it is a set of lightweight network proxies deployed together with application services.

[0003] One of the main purposes of service meshes is to manage service traffic. Currently, some common monitoring metric-based dashboards provided by the industry or open source communities can display basic service requests, calls, and response times in the form of traffic topologies. However, they do not support overlaying information from different dimensions onto the traffic topology, nor do they have the ability to correct the traffic topology in different dimensions according to different feature sources, and cannot perfectly display the behavior information of service meshes. Summary of the Invention

[0004] Embodiments of this application provide a method and system for generating traffic topologies to solve the above technical problems.

[0005] In a first aspect, an embodiment of this application provides a traffic topology generation method applied to a service mesh, where the service mesh is communicatively connected to at least two application services. The method includes: obtaining observability data of the service mesh, obtaining rule configuration data of the service mesh, and obtaining workload data of the at least two application services; analyzing the observability data and obtaining a first topological relationship of the at least two application services; analyzing the rule configuration data and the workload data and obtaining a second topological relationship of the at least two application services; and generating a comprehensive topological relationship based on the first topological relationship and the second topological relationship.

[0006] In a possible embodiment, the observability data includes monitoring data, and the monitoring data includes at least one monitoring metric of each of the at least two application services. Wherein, the analyzing the observability data includes: calculating the similarity of corresponding monitoring metrics between different application services in a time series, and using the similarity to evaluate the possibility of a dependency relationship existing between different services.

[0007] In a possible embodiment, the observability data includes log data, and the log data includes special logs about services since access generated by service mesh proxies. The special logs include, but are not limited to: the service name, port, and protocol with requests. Wherein, the analyzing the observability data includes: analyzing the log data and obtaining the dependency relationship of each of the at least two application services.

[0008] In a possible embodiment, the observability data includes trace data, and the trace data contains dependency information between different services. Among them, the analysis of the observability data includes: performing integrated analysis on the dependency information between different services contained in the trace data.

[0009] In a possible embodiment, after generating the comprehensive topology relationship, it further includes: correcting the comprehensive topology relationship to obtain rendering data.

[0010] In a possible embodiment, the comprehensive topology relationship includes at least two service nodes. Among them, the correction of the comprehensive topology relationship includes correcting from at least one of the following dimensions: preprocessing the at least two service nodes, where the preprocessing includes at least one of the following two: visibility processing, deduplication and merging processing; removing service nodes with no traffic in and out among the at least two service nodes; adding response time information to the at least two service nodes; adding security information to the at least two service nodes; adding throughput information to the at least two service nodes; adding aggregation nodes to the comprehensive topology relationship; adding grid resource information to the at least two service nodes; adding node identifiers to the at least two service nodes; adding weight information to the at least two service nodes; and adding display boundary information to the at least two service nodes.

[0011] In a possible embodiment, the correction of the comprehensive topology relationship further includes: customizing a topology correction mechanism according to requirements.

[0012] In a possible embodiment, after performing topology correction, it further includes: loading the rendering data to generate a visual topology.

[0013] In a second aspect, an embodiment of the present application provides a traffic topology generation system, and the system includes: a service mesh, the service mesh is communicatively connected to at least two application services; an observability data collector configured to obtain the observability data of the service mesh; a rule configuration data collector configured to obtain the rule configuration data of the service mesh; a workload data collector configured to obtain the workload data of the service mesh; an observability data controller configured to analyze the observability data and obtain a first topology relationship of the at least two application services; a configuration and workload analyzer configured to analyze the rule configuration data and the workload data and obtain a second topology relationship of the at least two application services; and a comprehensive topology relationship generator configured to generate a comprehensive topology relationship according to the first topology relationship and the second topology relationship.

[0014] In a possible embodiment, the observability data includes monitoring data, and the monitoring data includes at least one monitoring metric of each of the at least two application services. Wherein, the observability data controller is further configured to: calculate the similarity of the corresponding monitoring metrics between different application services in a time series, and use the similarity to evaluate the possibility of a dependency relationship existing between different services.

[0015] In a possible embodiment, the observability data includes log data. Wherein, the observability data controller is further configured to: analyze the log data and obtain the dependency relationship of each of the at least two application services.

[0016] In a possible embodiment, the observability data includes trace data, and the trace data includes dependency information between different services. Wherein, the observability data controller is further configured to: perform an integrated analysis on the dependency information between different services included in the trace data.

[0017] In a possible embodiment, the traffic topology generation system further includes: a topology corrector configured to correct the comprehensive topology relationship to obtain rendering data, and the topology corrector includes a built-in topology corrector and a custom topology corrector.

[0018] In a possible embodiment, for the traffic topology generation system, wherein the comprehensive topology relationship includes at least two service nodes, the built-in topology corrector corrects from at least one of the following dimensions: preprocessing the at least two service nodes, where the preprocessing includes at least one of the following two: visibility processing, de-duplication and merging processing; removing service nodes with no traffic in and out among the at least two service nodes; adding response time information to the at least two service nodes; adding security information to the at least two service nodes; adding throughput information to the at least two service nodes; adding aggregation nodes in the comprehensive topology relationship; adding grid resource information to the at least two service nodes; adding node identifiers to the at least two service nodes; adding weight information to the at least two service nodes; and adding display boundary information to the at least two service nodes.

[0019] In a possible embodiment, the traffic topology generation system further includes: a topology rendering engine configured to load the rendering data to generate a visual topology.

[0020] Compared with the prior art, the present application has the following advantages:

[0021] According to the embodiments of the present application, first, obtain the observability data, rule configuration data, and workload data obtained by the service mesh proxy; then, perform fusion analysis on these data to obtain service dependency relationships, and further generate a traffic topology; perform different-dimensional correction capabilities on the generated traffic topology according to different feature sources and topology visualization parameters, and support a custom feature correction mechanism; combine real-time request traffic with actual workload running information to provide instant insights into the behavior of the service mesh, enabling users to quickly identify problems and improve the efficiency of service mesh traffic governance.

[0022] The above description is only an overview of the technical solution of the present application. In order to be able to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features, and advantages of the present application more obvious and understandable, the following specifically illustrates the specific embodiments of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In the drawings, unless otherwise specified, the same reference numerals throughout the several views denote the same or similar components or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings only depict some embodiments in accordance with the present application and should not be regarded as limiting the scope of the present application.

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. The following drawings are only some embodiments recorded in the embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings.

[0025] Figure 1 is a schematic structural diagram of a service mesh according to an embodiment of the present application.

[0026] Figure 2 is a flowchart of a traffic topology generation method according to an embodiment of the present application.

[0027] Figure 3 is according to Figure 2 Another implementation of the traffic topology generation method shown in the embodiment.

[0028] Figure 4A is a structural diagram of a traffic topology generation system according to an embodiment of the present application.

[0029] Figure 4B is Figure 4A a structural diagram of the built-in topology feature corrector shown in

[0030] Figure 5 is a block diagram of an electronic device for implementing the embodiments of the present application. Detailed Implementation Manner

[0031] In the following text, only some exemplary embodiments are briefly described. As those skilled in the art can recognize, the described embodiments can be modified in various different ways without departing from the concept or scope of the present application. Therefore, the accompanying drawings and the description are considered to be exemplary in nature and not restrictive.

[0032] To facilitate the understanding of the technical solutions of the embodiments of the present application, the related technologies of the embodiments of the present application are described below. The following related technologies can be arbitrarily combined with the technical solutions of the embodiments of the present application as optional solutions, and they all fall within the protection scope of the embodiments of the present application.

[0033] A service mesh is a distributed interconnected proxy mesh deployed together with application services. Figure 1 It is a schematic diagram of a service mesh 100 according to an embodiment of the present application. The service mesh 100 is mainly used to facilitate secure and reliable communication between multiple microservices. The microservices refer to decomposing an application into multiple smaller services or instances and running them on different clusters / machines.

[0034] The microservices include application service instance A and application service instance B. The application service instance A and the application service instance B form the functional application layer of the service mesh 100. The application service instance A runs in the form of a container / process on the machine / workload container group 108. The application service instance B runs in the form of a container / process on the machine / workload container group 110. For example, the application service instance A can be a product query service, and the application service instance B can be a product order service.

[0035] As Figure 1 shown, the application service instance A and the mesh proxy 103 coexist in the machine workload container group 114; the application service instance B and the mesh proxy 105 coexist in the machine workload container 116. The mesh proxies 103 and 105 form the data plane layer of the service mesh 100. The mesh proxy 103 runs in the form of a container / process 104; the mesh proxy 105 runs in the form of a container / process 106. Bidirectional communication can be carried out between the mesh proxy 103 and the application service instance A; bidirectional communication can be carried out between the mesh proxy 105 and the application service instance B; in addition, bidirectional communication can also be carried out between the mesh proxy 103 and the mesh proxy 105.

[0036] All traffic of the application service instance A is routed to the appropriate destination through the mesh proxy 103; all network traffic of the application service instance B is routed to the appropriate destination through the mesh proxy 105. It should be noted that the network traffic mentioned here includes, but is not limited to, HTTP, REST, gRPC, and Redis forms.

[0037] As Figure 1 shown, the service mesh 100 further includes a control plane layer. The control plane layer can be a set of services running in a dedicated namespace, and the managed control plane component 101 in the machine / workload container group 102 hosts these services. As Figure 1 shown, the managed control plane component 101 communicates bidirectionally with the mesh proxy 103; the managed control plane component 101 and the mesh proxy 105 communicate bidirectionally. The managed control plane component 101 is configured to perform some control and management functions; the managed control plane component 101 receives the telemetry data transmitted by the mesh proxy 103 and the mesh proxy 105, and can further aggregate this telemetry data. The managed control plane component 101 can also provide user-facing application interfaces to more easily manipulate network behavior; further, the managed control plane component 101 can also provide configuration data and the like to the mesh proxy 103 and the mesh proxy 105.

[0038] Figure 2 is a flowchart of a traffic topology generation method 200 according to an embodiment of the present application. The traffic topology generation method 200 is applied to a service mesh, and the service mesh is communicatively connected to the at least two application services. The traffic topology generation method 200 may include the following steps S201 to S204. Each step in the traffic topology generation method 200 will be described below.

[0039] In step S201, obtain the observability data, rule configuration data of the service mesh, and workload data of the at least two application services. The above data acquisition method can be a non-intrusive method.

[0040] The rule configuration data may be the configuration data sent by the control plane to each service mesh proxy. This configuration data can enable the service mesh to correctly proxy service traffic and achieve service interconnection and service governance.

[0041] The workload data may be the metadata information of each workload. The metadata information includes, but is not limited to, the following information: namespace, name, location, tag content included, protocol version, etc.

[0042] In some embodiments, the observability data may include monitoring data. Unless otherwise specified, the monitoring data has the same meaning as the monitoring metrics. Since the traffic of the application service is intercepted by the service mesh proxy, the service mesh proxy can generate multiple monitoring metrics for the access situation of the service and collect them into the monitoring data storage by the monitoring system.

[0043] The observability data may also include log data. Since the traffic of the application service in each data plane is intercepted by the service mesh proxy, the service mesh proxy can generate service access logs based on the intercepted traffic, and these logs are automatically collected into a log storage by a log collection system to generate log data.

[0044] The observability data may further include trace data, which refers to the trace information of the access messages between services.

[0045] Next, enter step S202. In step S202, analyze the observability data and obtain the first topological relationship of the at least two application services.

[0046] In some embodiments, analyzing the observability data includes analyzing the monitoring data. Analyzing the monitoring data may include: calculating the similarity of the corresponding monitoring metrics between different application services in the time series and using the similarity to evaluate the possibility of a dependency relationship between different services.

[0047] In some embodiments, the similarity of the monitoring data between any two services may be determined based on the monitoring data, and the services whose similarity meets the set conditions are determined as services with a dependency relationship.

[0048] Taking the monitoring metrics including the request time, the data volume size of the response data corresponding to the request, and the data status of the response data as an example, for any two services, the similarity of the monitoring data corresponding to any one of the monitoring metrics can be determined. Thus, when the determined similarity meets the target conditions, it can be determined that there is a dependency relationship between these two services.

[0049] In some embodiments, for any two services, the similarity of the monitoring data corresponding to multiple monitoring metrics may also be determined respectively to obtain multiple similarities. Then, based on the multiple similarities, the similarity of these two services is determined. Thus, when the determined similarity meets the target conditions, it can be determined that there is a dependency relationship between these two services.

[0050] In some embodiments, when determining the similarity between the two services based on multiple similarities, the average value of the multiple similarities may be calculated, and the calculated average value may be used as the similarity between the two services. Additionally, other methods may be adopted to determine the similarity between the two services based on multiple similarities, and the present application does not limit this.

[0051] The target condition may be that the similarity is greater than a preset threshold. The preset threshold may take any value, and the present application does not limit the specific value of the preset threshold, as long as the technical concept of the present application can be realized.

[0052] The analysis of the observable data also includes the analysis of the log data. The analysis of the log data may include: integrally analyzing the dependency information between different services included in the log data. Based on the log data, services with the same request name and service namespace in the log data may be determined as services with a dependency relationship.

[0053] The log data may include the log data corresponding to two services. For example, the log data includes the log data corresponding to service A and the log data corresponding to service B. If both the data corresponding to service A and the log data corresponding to service B include the same request name (such as a payment request), and the service namespaces of service A and service B are the same, then it may be determined that there is a dependency relationship between service A and service B.

[0054] Other types of information in the log data may also be combined to determine the dependency relationship between services. Taking the log data also including the transmission port and transmission protocol as an example, when determining the dependency relationship between each service in the service mesh based on the log data as the running state data, the following at least one implementation method may also be adopted: based on the log data, services with the same service name, service namespace, and transmission port in the log data are determined as services with a dependency relationship; based on the log data, services with the same service name, service namespace, and transmission protocol in the log data are determined as services with a dependency relationship.

[0055] It should be noted that the above two methods may also be used in combination. That is to say, in more possible implementation methods, services with the same service name, service namespace, transmission port, and transmission protocol in the log data may also be determined as services with a dependency relationship based on the log data.

[0056] The determination of the dependency relationship may also be performed by combining information such as the transmission port and the transmission protocol. Thus, information from more perspectives can be integrated to realize the determination of the dependency relationship, and further improve the accuracy of the determined dependency relationship.

[0057] Further, the observability data may further include analyzing the trace data. The specific process of analyzing the trace data includes: by extracting the trace information in the access messages between services, request path trace data in the grid can be generated for each service request, and these data can be automatically collected into the trace data storage. Analyzing the observability data includes analyzing the trace data. For example, the dependency information between different services included in the trace data can be integratively analyzed.

[0058] In another implementation, based on the trace data, any two adjacent services in the transmission path indicated by the trace data are determined as services with a dependency relationship.

[0059] It should be noted that based on the transmission path of a request in the service mesh, the dependency relationships between various services in the service mesh can be determined. Moreover, the transmission paths of multiple requests in the service mesh can be collected, so as to obtain more comprehensive dependency information based on the transmission paths of multiple requests in the service mesh.

[0060] For the solution of obtaining observability data in the above embodiments, the dependencies of each service in the service mesh can be determined simultaneously from three different dimensions (for example, monitoring data, log data, trace data). In other implementations, as Figure 3 shown, the data of the above three dimensions can also be obtained sequentially in time to achieve the determination of the dependency relationship.

[0061] Similarly, for the solution of obtaining observability data in the above embodiments, the dependencies of each service in the service mesh can be determined from the above three different dimensions. The above three methods can be used alone, that is, the determination of the dependency relationship can be achieved based on any one of the above methods. In other implementations, the above three methods can also be combined, that is, any combination of one or more of them can be used to achieve the determination of the dependency information.

[0062] Next, step S203 is entered. In step S203, the rule configuration data and the workload data are analyzed, and the second topological relationship of the at least two application services is obtained.

[0063] In some embodiments, step S203 may include: recording the basic information of the service mesh data plane proxy and the metadata information of each workload through the service mesh control plane; analyzing to obtain the endpoint information of all services running in the grid data plane and the traffic proxy policy of each service, so as to supplement the information of other grid topologies except for the dependency relationships between services. Among them, the information of other grid topologies refers to the data information used in multiple dimensions required for correcting the comprehensive topological relationship.

[0064] Next, enter step S204. In step S204, a comprehensive topological relationship is generated based on the first topological relationship and the second topological relationship.

[0065] In some embodiments, when the running state data for determining the dependency relationship corresponds to at least two dimensions, a weighted calculation is performed on the dependency relationships in the first topological relationship and the dependency relationships in the second topological relationship to obtain the dependency relationships between the respective services corresponding to the service mesh proxy, that is, the comprehensive topological relationship.

[0066] When performing a weighted calculation on the dependency relationships in the first topological relationship and the dependency relationships in the second topological relationship, the weights of the dependency relationships can be determined based on different types of running state data. For example, the weights can be determined based on the sampling rate and sampling time of different types of running state data, and other information can also be combined to determine the weights.

[0067] Taking the determination of the weights of the dependency relationships determined based on different types of running state data based on the sampling rate and sampling time of different types of running state data as an example, the product of the sampling rate and the sampling time can be calculated, and the ratio of the calculated product can be taken to achieve the determination of the weights.

[0068] Through the above method, the sampling rate and the sampling time can be combined to achieve the weights of the dependency relationships determined based on the running state data of different dimensions, which can ensure that the weights of the dependency relationships determined by the data with a longer sampling time and a higher sampling rate are greater, and the data with a longer sampling time and a higher sampling rate is more accurate, so that the credibility of the dependency relationships obtained by the weighted calculation is higher.

[0069] In the above embodiments, the determination of the dependency relationships is realized from different dimensions, and then a weighted calculation is performed on the multiple determined dependency relationships, so as to realize the integration of the dependency relationships determined based on the running state data of different dimensions to obtain a comprehensive dependency relationship, thereby further enhancing the accuracy, comprehensiveness and integrity of the determined dependency relationships.

[0070] The traffic topology generation method 200 of the present application generates the dependency relationships of multiple services in the service mesh analyzed from three different dimensions of data (such as observability data, rule configuration data, workload data). By further integrating the service dependency relationships obtained from the three different dimensions of data, the integrity and accuracy of the obtained service dependency relationships can be further enhanced. Through service dependency relationship fusion, the traffic topology generation method 200 takes the union of the service dependency relationships from different sources, and performs a weighted calculation to ensure the integrity of the analyzed service dependency relationships, obtains the fused service dependency relationships, and generates the in-memory data describing the above topological relationships, which is called the traffic topology.

[0071] In some embodiments, after generating the comprehensive topological relationship, it further includes: correcting the comprehensive topological relationship to obtain rendering data. The comprehensive topological relationship includes at least two service nodes, wherein correcting the comprehensive topological relationship includes correcting from at least one of the following multiple dimensions.

[0072] Dimension 1: Preprocessing the at least two service nodes, where the preprocessing includes at least one of the following two: visibility processing, deduplication and merging processing. For example, identifying all workloads under the service mesh and their corresponding service information, the preprocessing function of service nodes includes visibility setting of service nodes in different namespaces, deduplication and merging operations.

[0073] Dimension 2: Removing service nodes with no traffic in and out among the at least two service nodes, so as to more accurately display traffic topology information in the graph.

[0074] Dimension 3: Adding response time information to the at least two service nodes, including response time information from multiple dimensions for different protocols.

[0075] Dimension 4: Adding security information to the at least two service nodes, including but not limited to policy rule configuration, TLS configuration.

[0076] Dimension 5: Adding throughput information to the at least two service nodes, including throughput information from multiple dimensions for different protocols.

[0077] Dimension 6: Adding aggregation nodes to the comprehensive topological relationship, so as to obtain the visibility of traffic aggregation in the user-specified metric dimension.

[0078] Dimension 7: Adding mesh resource information to the at least two service nodes, including but not limited to service circuit breaker rule configuration and routing rule configuration information defined for different protocols.

[0079] Dimension 8: Adding a node identifier to the at least two service nodes, and the identifier is used to describe whether the workload corresponding to the backend lacks a Sidecar proxy.

[0080] Dimension 9: Adding weight information to the at least two service nodes. For example, different display weights can be added to the nodes according to different benchmarks specified in the mesh topology visualization parameters (including but not limited to the number of dependent services, the number of services being depended on, throughput), so as to highlight important services in the service mesh.

[0081] Dimension 10: Add display boundary information for the at least two service nodes. For example, service nodes within the same range can be delimited based on different service classification criteria (including but not limited to namespaces, the machines they are on) specified in the grid topology visualization parameters, to clearly show different boundaries in the service mesh.

[0082] In some embodiments, the modification of the comprehensive topological relationship further includes: customizing a topology correction mechanism according to requirements.

[0083] In some embodiments, after performing topology correction, it further includes: loading the rendering data to generate a visualized topology.

[0084] Corresponding to the application scenario and method of the method provided by the embodiments of the present application, the embodiments of the present application further provide a traffic topology generation system 400. FIG. 4 shows a structural diagram of a traffic topology generation system 400 according to an embodiment of the present application. The traffic topology generation system 400 may include: a service mesh 401, an observability data collector 402, a rule configuration data collector 403, an observability data controller 405, a metric analyzer 406, a log analyzer 407, a trace analyzer 408, a configuration and workload analyzer 409, a comprehensive topology generator 410, a topology corrector 411, and a topology rendering engine 412. The following is an explanation of each component of the traffic topology generation system 400.

[0085] Service mesh 401, the service mesh is communicatively connected to at least two application services.

[0086] Observability data collector 402, configured to obtain the observability data of the service mesh. In some possible embodiments, the observability data collector 402 may further include the following collectors according to the different sources of the collected data: a monitoring data collector 4021, configured to obtain the monitoring data obtained by the service mesh proxy; a log data collector 4022, configured to obtain the log data obtained by the service mesh proxy; and a trace data collector 4023, configured to obtain the total data obtained by the service mesh proxy.

[0087] Rule configuration data collector 403, configured to obtain the rule configuration data of the service mesh.

[0088] Workload data collector 404, configured to obtain the workload data of the service mesh.

[0089] Observability data controller 405, configured to analyze the observability data and obtain the first topological relationship of the at least two application services.

[0090] The metric analyzer 406 is configured to utilize one or more monitoring metrics of each service in the monitoring data store, calculate the similarity of each monitoring metric among services over time series; and evaluate the likelihood of the existence of a dependency relationship among services using the calculated similarity.

[0091] The log analyzer 407 is configured to search for special logs generated by the service mesh proxy regarding accessing dependent services, and further extract and generate service dependency information for each service from the logs.

[0092] The trace analyzer 408 is configured to obtain dependency information among all services in the system by collecting a large number of trace paths and integrating and analyzing them.

[0093] The configuration and workload analyzer 409 is configured to analyze the rule configuration data and the workload data and obtain the second topological relationship of the at least two application services.

[0094] The comprehensive topology relationship generator 410 is configured to generate a comprehensive topology relationship based on the first topological relationship and the second topological relationship.

[0095] The comprehensive topology relationship generator 410, as one of the core components of the traffic topology generation system 400, is responsible for processing the observability data generated by the service mesh proxy and constructing a memory structure describing the topological relationship through analysis. The specific definition of the memory structure is as follows:

[0096] TrafficTopologyMap map[string]Node / / where each Node represents each node in the topology graph, and the data structure definition is as follows:

[0097]

[0098] Where Edge refers to the connection lines corresponding to the in - direction and out - direction of the node. Each line includes the node as the source point and the node as the end point, and also includes the metadata information of the corresponding line.

[0099]

[0100]

[0101] The topology corrector 411 is configured to correct the comprehensive topology relationship to obtain rendering data. The topology corrector includes a built - in topology corrector 4111 and a custom topology corrector 4112.

[0102] In some embodiments, such as Figure 4BAs shown, according to different sources of features, the built-in topology corrector 4111 may include one or more of the following correctors:

[0103] The preprocessing node feature corrector is configured to identify all workloads under the service mesh and their corresponding service information. The preprocessing function of the service node includes operations such as visibility setting and deduplication and merging of the service node in different namespaces.

[0104] The idle service feature corrector is configured to remove some service nodes without traffic in and out, so as to more accurately display the traffic topology information in the graph.

[0105] The response time feature corrector is configured to add response time information to the service nodes in the graph, including response time information from multiple dimensions for different protocols.

[0106] The security information feature corrector is configured to add security information to the service nodes in the graph, including but not limited to policy rule configuration, TLS configuration, etc.

[0107] The throughput feature corrector is configured to add throughput information to the service nodes in the graph, including throughput information from multiple dimensions for different protocols.

[0108] The aggregated node feature corrector is configured to inject aggregated nodes into the graph to obtain the visibility of traffic aggregation in the user-specified metric dimension.

[0109] The mesh resource feature corrector is configured to add mesh resource information to the service nodes in the graph, including service circuit breaker rule configuration, routing rule configuration, etc. defined for different protocols.

[0110] The mesh proxy feature corrector is configured to add an identifier to the service nodes in the graph, which is used to describe whether the corresponding workload of its backend lacks a Sidecar proxy.

[0111] The node weight feature corrector is configured to add weight information to the service nodes in the graph. This corrector adds different display weights to the nodes according to different benchmarks specified in the mesh topology visualization parameters (including but not limited to benchmarks such as the number of dependent services, the number of services being depended on, throughput, etc.) to highlight the important services in the service mesh.

[0112] The node boundary feature corrector is configured to add display boundary information to the service nodes in the graph. This corrector delimits the service nodes within the same range according to different service classification benchmarks specified in the mesh topology visualization parameters (including but not limited to benchmarks such as namespaces, the machines where they are located, etc.) to clearly display different boundaries in the service mesh.

[0113] A topology rendering engine 412 is configured to load the rendering data obtained after being corrected by a topology corrector to generate a visualized topology.

[0114] For the functions of each module in each device of the embodiments of the present application, reference may be made to the corresponding descriptions in the above methods, and the corresponding beneficial effects are achieved, which will not be elaborated herein.

[0115] Figure 5 It is a block diagram of an electronic device for implementing the embodiments of the present application. As Figure 5 shown, the electronic device includes: a memory 510 and a processor 520. The memory 510 stores a computer program that can run on the processor 520. When the processor 520 executes the computer program, the method in the above embodiments is implemented. The number of the memory 510 and the processor 520 can be one or more.

[0116] The electronic device further includes:

[0117] A communication interface 530, configured to communicate with external devices for data interaction and transmission.

[0118] If the memory 510, the processor 520, and the communication interface 530 are implemented independently, the memory 510, the processor 520, and the communication interface 530 can be interconnected through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 5 only a thick line is shown in the figure, but it does not mean that there is only one bus or one type of bus.

[0119] Optionally, in specific implementation, if the memory 510, the processor 520, and the communication interface 530 are integrated on a chip, the memory 510, the processor 520, and the communication interface 530 can communicate with each other through an internal interface.

[0120] The embodiments of the present application provide a computer-readable storage medium that stores a computer program, and when the program is executed by a processor, the method provided in the embodiments of the present application is implemented.

[0121] The embodiments of the present application further provide a chip, which includes a processor for calling and running an instruction stored in a memory from the memory, so that a communication device installed with the chip executes the method provided in the embodiments of the present application.

[0122] An embodiment of the present application further provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected through an internal connection path. The processor is configured to execute the code in the memory. When the code is executed, the processor is configured to execute the method provided by the embodiment of the application.

[0123] It should be understood that the above-mentioned processor may be a central processing unit (CPU), or may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor that supports the advanced reduced instruction set machine (ARM) architecture.

[0124] Further, optionally, the above-mentioned memory may include a read-only memory and a random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct rambus random access memory (DR RAM).

[0125] In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium.

[0126] In the description of this specification, the descriptions with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0127] In addition, the terms "first" and "second" are used for descriptive purposes only and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of the present application, "a plurality of" means two or more unless otherwise specifically defined.

[0128] Any process or method described in the flowchart or otherwise described herein can be understood to represent a module, segment, or portion of code including one or more executable instructions for implementing a specific logical function or process. And the scope of the preferred embodiments of the present application includes additional implementations, where the functions may be performed in a substantially simultaneous manner or in a reverse order according to the involved functions, rather than in the order shown or discussed.

[0129] The logic and / or steps described in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing a logical function, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or in connection with these instruction execution systems, apparatus, or devices.

[0130] It should be understood that each part of the present application can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above method embodiments can be completed by a program instructing relevant hardware, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0131] In addition, each functional unit in various embodiments of the present application may be integrated into one processing module, or each unit may exist physically alone, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the above-mentioned integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic disk, an optical disc, or the like.

[0132] As described above, only the exemplary embodiments of the present application are provided, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope recorded in the present application can easily think of various changes or substitutions, and these should all be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A traffic topology generation method, which is applied to a service mesh. The service mesh is communicatively connected to at least two application services. The method includes: Obtaining the observability data of the service mesh, obtaining the rule configuration data of the service mesh, and obtaining the workload data of the at least two application services; Analyzing the observability data and obtaining a first topological relationship of the at least two application services, where the first topological relationship is used to represent the dependency relationship of calls between the at least two application services; Analyzing the rule configuration data and the workload data and obtaining a second topological relationship of the at least two application services, where the second topological relationship is used to represent other network topological relationships except the dependency relationship of calls between the at least two application services; Generating a comprehensive topological relationship according to the first topological relationship and the second topological relationship, where the second topological relationship is used to correct the first topological relationship to obtain the comprehensive topological relationship.

2. The method according to claim 1, wherein, The observability data includes monitoring data, and the monitoring data includes at least one monitoring metric of each of the at least two application services. Wherein, the analyzing the observability data includes: Calculating the similarity of corresponding monitoring metrics between different application services in time series, and using the similarity to evaluate the possibility of a dependency relationship existing between different services.

3. The method according to claim 1, wherein The observability data includes log data. Wherein, the analyzing the observability data includes: Analyzing the log data and obtaining the dependency relationship of each of the at least two application services.

4. The method according to claim 1, wherein The observability data includes trace data, and the trace data includes dependency information between different services. Wherein, the analyzing the observability data includes: Performing integrated analysis on the dependency information between different services included in the trace data.

5. The method according to claim 1, wherein, The generating a comprehensive topological relationship according to the first topological relationship and the second topological relationship includes: Performing weighted calculation on the first topological relationship and the second topological relationship.

6. According to the method described in claim 1, after generating the comprehensive topological relationship, it further includes: Correcting the comprehensive topological relationship to obtain rendering data.

7. The method according to claim 6, wherein, The comprehensive topological relationship includes at least two service nodes. Wherein, the correcting the comprehensive topological relationship includes correcting from at least one of the following dimensions: Performing preprocessing on the at least two service nodes, where the preprocessing includes at least one of the following two: visibility processing, deduplication and merging processing; Removing service nodes with no traffic in and out among the at least two service nodes; Adding response time information to the at least two service nodes; Adding security information to the at least two service nodes; Adding throughput information to the at least two service nodes; Adding aggregation nodes to the comprehensive topological relationship; Adding grid resource information to the at least two service nodes; Adding node identifiers to the at least two service nodes; Adding weight information to the at least two service nodes; and Adding display boundary information to the at least two service nodes.

8. The method according to claim 6, wherein The correction of the comprehensive topological relationship further includes: Customizing a topological correction mechanism according to requirements.

9. The method according to claim 6, further including, after performing topological correction: Loading the rendering data to generate a visual topology.

10. A traffic topology generation system, including: A service mesh communicatively connected to at least two application services; An observability data collector configured to obtain the observability data of the service mesh; A rule configuration data collector configured to obtain the rule configuration data of the service mesh; A workload data collector configured to obtain the workload data of the service mesh; An observability data controller configured to analyze the observability data and obtain a first topological relationship of the at least two application services, the first topological relationship being used to represent the dependency relationship of calls between the at least two application services; A configuration and workload analyzer configured to analyze the rule configuration data and the workload data and obtain a second topological relationship of the at least two application services, the second topological relationship being used to represent other network topological relationships other than the dependency relationship of calls between the at least two application services; And A comprehensive topological relationship generator configured to generate a comprehensive topological relationship according to the first topological relationship and the second topological relationship, wherein the second topological relationship is used to correct the first topological relationship to obtain the comprehensive topological relationship.

11. The traffic topology generation system according to claim 10, wherein, The observability data includes monitoring data, and the monitoring data includes at least one monitoring metric of each of the at least two application services, wherein the observability data controller is further configured to: Calculate the similarity of corresponding monitoring metrics between different application services in a time series, and use the similarity to evaluate the possibility of a dependency relationship existing between different services.

12. The traffic topology generation system according to claim 10, wherein, The observability data includes log data, wherein the observability data controller is further configured to: Analyze the log data and obtain the dependency relationship of each of the at least two application services.

13. The traffic topology generation system according to claim 10, wherein, The observability data includes trace data, and the trace data includes dependency information between different services, wherein the observability data controller is further configured to: Perform an integrated analysis of the dependency information between different services included in the trace data.

14. The traffic topology generation system according to claim 10, further including: A topology corrector configured to correct the comprehensive topological relationship to obtain rendering data, the topology corrector including a built-in topology corrector and a custom topology corrector.

15. The traffic topology generation system according to claim 14, wherein The comprehensive topological relationship includes at least two service nodes, and the built-in topology corrector corrects from at least one of the following dimensions: Preprocess the at least two service nodes, wherein the preprocessing includes at least one of the following two: visibility processing, deduplication and merging processing; Remove service nodes with no traffic in and out among the at least two service nodes; Add response time information to the at least two service nodes; Add security information to the at least two service nodes; Add throughput information to the at least two service nodes; Add an aggregation node to the comprehensive topological relationship; Add grid resource information to the at least two service nodes; Add node identifiers to the at least two service nodes; Add weight information to the at least two service nodes; and Add display boundary information to the at least two service nodes.

16. The traffic topology generation system according to claim 14, further comprising: A topology rendering engine configured to load the rendering data to generate a visual topology.

Images