Micro-service-based information processing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a micro-service-based information processing method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a calling relation between micro-services in a micro-service system; determining a calling topological structure of the micro-service system according to the calling relation; and performing fault positioning and / or performance analysis on the micro-service system according to the at least called topological structure. According to the invention, security analysis and performance improvement of the micro-service system are realized.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of information processing technologies, and in particular, to an information processing method, apparatus, electronic device, and storage medium based on microservices. Background Art

[0002] Currently, with the rapid development of the Internet, in order to adapt to the rapid iteration of Internet services, more and more services adopt a microservices architecture to replace the traditional monolithic architecture. The number of microservices is increasing continuously, resulting in intricate call relationships between microservices, which in turn increases the possibility and necessity of fault location and / or performance analysis for microservices.

[0003] However, fault location and / or performance analysis can only sample and record at key interfaces, and cannot fully record all the interfaces of microservices. At the same time, the construction basis of related technologies is a directed acyclic graph, which cannot traverse the mutual calls existing between business modules, may lead to incomplete interfaces and call relationships, and thus cannot accurately locate interfaces during fault location and / or performance analysis, affecting the results of fault location and / or performance analysis, and even possibly causing microservice information processing problems. Summary of the Invention

[0004] In view of this, embodiments of this application at least provide an information processing method, apparatus, electronic device, and storage medium based on microservices.

[0005] The technical solution of the embodiments of this application is implemented as follows:

[0006] On the one hand, embodiments of this application provide an information processing method based on microservices. The method includes: obtaining the call relationships between microservices in a microservice system; obtaining the call topology structure of the microservice system according to the call relationships; and performing fault location and / or performance analysis on the microservice system according to at least the call topology structure.

[0007] On the other hand, embodiments of this application provide an information processing apparatus. The apparatus includes: a first acquisition module for acquiring the call relationships between microservices in a microservice system; a first determination module for obtaining the call topology structure of the microservice system according to the call relationships; and a second determination module for performing fault location and / or performance analysis on the microservice system according to at least the call topology structure.

[0008] On yet another hand, embodiments of this application provide an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor, and when the processor executes the program, it implements some or all of the steps in the above method.

[0009] In another aspect, an embodiment of the present application provides a storage medium, on which a computer program is stored, and when the computer program is executed by a processor, some or all of the steps in the above method are implemented.

[0010] In another aspect, an embodiment of the present application provides a computer program, including computer-readable code, and when the computer-readable code runs in a computer device, a processor in the computer device executes to implement some or all of the steps in the above method.

[0011] In another aspect, an embodiment of the present application provides a computer program product. The computer program product includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, some or all of the steps in the above method are implemented.

[0012] In the embodiments of the present application, by obtaining the call relationships between microservices in a microservice system, the call topology structure of the microservice system is determined, so as to obtain a comprehensive and complete microservice interface and the call relationships therebetween. Then, based on the complete and comprehensive microservice interface and call relationships, microservice fault location and / or performance analysis are performed, which can improve the accuracy of microservice fault location and / or performance analysis, and further provide a basis for optimizing the microservice system.

[0013] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and do not limit the technical solution of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The drawings herein are incorporated into the specification and form a part of this specification. These drawings illustrate embodiments consistent with the present application and, together with the specification, are used to explain the technical solutions of the present application.

[0015] Figure 1 It is a schematic flowchart of the implementation of an information processing method based on microservices provided by an embodiment of the present application;

[0016] Figure 2 It is a schematic flowchart of the implementation of processing discarded interfaces in microservices in a scenario of determining discarded interfaces provided by an embodiment of the present application;

[0017] Figure 3 It is a schematic flowchart of the implementation of processing microservices with frequently changed interfaces in a scenario of determining frequently changed interfaces provided by an embodiment of the present application;

[0018] Figure 4 It is a schematic flowchart of the implementation of confirming dependencies of security risks provided by an embodiment of the present application;

[0019] Figure 5A schematic diagram of an implementation process for handling security risk dependencies existing in the currently scanned microservice module provided for the implementation of this application;

[0020] Figure 6 A schematic diagram of an implementation process for handling hot modules in microservices in a hot module scenario provided for the implementation of this application;

[0021] Figure 7 A schematic diagram of an implementation process for overall architecture analysis and security analysis provided for an embodiment of this application;

[0022] Figure 8 A schematic diagram of a structure of an information processing device provided for an embodiment of this application;

[0023] Figure 9 A schematic diagram of a structure of an electronic device provided for an embodiment of this application. Detailed implementation manners

[0024] In order to make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be further elaborated in detail below in conjunction with the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.

[0025] In the following descriptions, reference is made to "some embodiments", which describe subsets of all possible embodiments. However, it can be understood that "some embodiments" can be the same subsets or different subsets of all possible embodiments, and they can be combined with each other without conflict.

[0026] The Internet has developed rapidly, and more and more services have been deployed online. When the business volume of a system is very small, a lot of code is placed in one project, and then this project is deployed on one server, and all services of the entire project are provided by this server. This is the monolithic architecture. A monolith is a piece of code with multiple modules, and these modules are tightly coupled in sequence. Tightly coupled means that the business logic is intricate, so scalability becomes a challenge. However, with the continuous implementation of requirements, the codebase has also expanded rapidly, and it has become increasingly complex to add or improve functions. This complexity limits the feasibility of experimentation and makes it difficult to implement new concepts. The monolithic architecture increases the risk of application availability because many dependent and tightly coupled processes will amplify the impact of a single process failure. In order to implement intricate requirements and adapt to the rapid iteration of the business, with the rapid development of container technology, more and more services adopt the microservices architecture.

[0027] A microservices architecture is an architecture that builds an application as separate components and runs each application process as a service. These services communicate through well-defined interfaces using lightweight application programming interfaces (APIs). These services are built around business functions, with each service performing one function and being independently deployed through a fully automated deployment mechanism. These services may be written in different programming languages and use different data storage technologies. Since microservices run independently, the entire codebase is broken down into smaller services, and updates, deployments, and scaling can be performed for each service to meet the requirements for specific application functions. Compared with monolithic programs, the microservices architecture enables large and complex applications to be continuously delivered and deployed. Services can be independently deployed and scaled. At the same time, the microservices architecture can achieve team self-consistency. Individuals in the team can handle individual modules, and each person can independently build and deploy modules, thereby reducing the operation and maintenance friction of the team and improving development efficiency. It is also easier to experiment with and adopt new technologies and has better fault tolerance and other advantages.

[0028] A microservices architecture can consist of one or more microservices, and each microservice in this architecture can be independently deployed. The core idea of the microservices architecture is that an application is composed of multiple small and independent microservices, thus effectively splitting the application to achieve agile development and deployment. In the embodiments of this application, the microservices architecture is the microservices system.

[0029] However, with the continuous development of business, the number of microservices is increasing, and the disadvantages of the microservices architecture are also emerging. In order to accelerate the realization of requirements, the functions of microservices are constantly increasing, which also increases the probability of unreasonable design, resulting in the interfaces of microservices not being cleaned up in time or having defects in implementation. At the same time, the increase in the number of microservices will lead to intricate call relationships between services and a complex online operating environment. It is difficult to list the call relationships using runtime means. At the same time, the dependencies used in microservice interface calls are different according to different languages and different versions, making it difficult to discover security risks during the development stage and impossible to determine the functional modules that may be affected by security fixes. In one example, the above runtime means can be to use the OpenTracing means to embed points for collection at nodes. The above collection can use a sampling mechanism and cannot fully sample the nodes. There may be infrequent call relationships and it is impossible to fully collect the nodes, resulting in the inability to fully list the call relationships.

[0030] Currently, the API of distributed tracing (such as OpenTracing, a distributed tracing system) is adopted to analyze the problems existing in the microservice system. OpenTracing constructs the service call chain by passing Spans (the call process of a module) across processes. Spans are generally constructed during remote procedure call (RPC) invocations and contain partial information of the RPC call. A Trace (call chain) is a directed acyclic graph composed of multiple Spans. Span information is generally recorded in the logging system and constructed quasi-real-time through technical means such as Flink (a distributed stream computing engine) to assist relevant system personnel in fault location. However, OpenTracing only samples and records at key interfaces and cannot fully record microservice interfaces. Because there are generally mutual calls between business modules, and the construction basis of OpenTracing is a directed acyclic graph, it cannot traverse the microservice interfaces in business modules and the mutual calls between business modules, which may lead to incomplete interfaces and call relationships, and further result in inaccurate microservice fault location and / or performance analysis, causing microservice information processing problems.

[0031] Based on this, the embodiments of this application provide a microservice-based information processing method, device, electronic device, and storage medium to obtain the call relationships between various microservices in the microservice system, obtain the call topology structure of the microservice system according to the call relationships, and perform fault location and / or performance analysis on the microservice system based on the module dependencies of the call topology structure, providing a basis for optimizing the microservice system.

[0032] Figure 1 It is a schematic flowchart of the implementation of a microservice-based information processing method provided by the embodiments of this application. Refer to Figure 1 As shown. The above-mentioned microservice-based information processing method can be applied to an information processing device. This method may include steps S101 to S103.

[0033] In step S101, the call relationships between various microservices in the microservice system are obtained.

[0034] In some embodiments, the call relationships between microservices can include many types, such as at least one of the upstream call relationship and the downstream call relationship. In one embodiment, the upstream call relationship refers to the call relationship between a microservice and its upstream microservice, where the upstream microservice calls this microservice. The downstream call relationship refers to the call relationship between a microservice and its downstream microservice, where the downstream microservice is called by this microservice.

[0035] It should be noted that for a microservice in a microservice system, there may be an upstream call relationship, a downstream call relationship, or both an upstream call relationship and a downstream call relationship for this microservice.

[0036] In some embodiments, for the upstream call relationship, in step S101, the information processing device can perform syntax analysis on the source code of each microservice, and the information processing device can obtain the library information of the dependency libraries relied on by each microservice. Then, based on the library information of the dependency libraries, the information processing device can record the interface information of the call interfaces exposed by at least one function in each microservice, and from the interface information of these call interfaces, obtain the call relationship between at least one microservice and its upstream microservice, that is, the upstream call relationship. In one embodiment, the above-mentioned dependency library can be a third-party database relied on by the microservice. In one example, the third-party database can include, but is not limited to, static libraries and dynamic libraries.

[0037] In some embodiments, the information processing device can perform syntax analysis on the source code of each microservice by scanning the source code of each microservice through a syntax analyzer. In one example, the syntax analyzer can perform syntax analysis using an abstract syntax tree (AST). In one example, the above-mentioned AST is a separately written software project, independent of the microservice system being scanned, and will not increase the source code of the microservice system being scanned; in one example, performing syntax analysis using the AST does not require embedding points for recording by placing a software development kit (SDK), has no intrusion into the business code, and can obtain a more complete service call relationship graph, etc.

[0038] In some embodiments, the information processing device can perform syntax analysis on the source code of each microservice. In one example, the information processing device can be an information processing device with AST functionality. In one example, the source code of each microservice can be the source code stored in the code repository corresponding to each microservice.

[0039] In some embodiments, for the downstream call relationship, in step S101, the information processing device can obtain the source code of each microservice for syntax analysis, and the information processing device can obtain at least one function in the source code. Then, based on each function in the source code, the information processing device can record the interface information of the call interfaces exposed by each function, and from the interface information of these call interfaces, obtain the call relationship between at least one microservice and its downstream microservice, that is, the call relationship with the downstream microservice.

[0040] In some embodiments, the information processing device may record the interface information exposed by each function by determining whether the current interface is an API interface according to the language characteristics of the microservices. In one example, the information processing device may determine whether the current interface is an API interface by determining the language used according to the language characteristics of the microservices, which may include but is not limited to differentiating the languages according to different language characteristics and determining the current interface according to the language characteristics corresponding to different languages. In one example, microservices communicate through interfaces. In one example, the call interface exposed by a function may be an API interface. In one example, the interface information exposed by each function may include but is not limited to at least one of the following: path, method, call parameters, interface function description. In one example, the language characteristics of microservices may include but is not limited to at least one of the following: Java annotations, Python decorator information.

[0041] In step S102, according to the call relationship, obtain the call topology structure of the microservice system.

[0042] It can be understood that after the information processing device obtains the call relationship between microservices through step S101, it can create the call topology structure of the microservice system through a visualization component according to the call relationship between microservices. Here, in the call topology structure, nodes represent microservices, and the edges of each node represent the call relationship between microservices. In the embodiments of the present application, the call topology structure can more completely display the call relationship between microservices. In one example, the visualization component may be any method that can visually display data, which is not limited herein.

[0043] In step S103, perform fault location and / or performance analysis on the microservice system according to at least the call topology structure.

[0044] It can be understood that step S103 may include but is not limited to performing fault location and / or performance analysis on the microservice system for the following two cases.

[0045] Case 1: The information processing device may perform fault location on the microservice system according to the call topology structure.

[0046] It can be understood that for the above Case 1, the information processing device may perform fault location processing on the microservice system after obtaining the call topology structure of the microservice system.

[0047] In some embodiments, fault location may include: determining a discarded interface, confirming whether there is a risk in the microservice module currently being scanned, confirming dependencies with security risks, and confirming at least one of the microservice modules with frequently changed interfaces; performance analysis may include: confirming a hot module, determining the coupling degree of the hot module, confirming the functional redundancy of the hot module, reducing the coupling degree of the hot module, and reducing the functional redundancy of the hot module, at least one of the following. Here, a module can be understood as a smaller code block decomposed according to business functions in a microservice.

[0048] In some embodiments, in step S103, the information processing device may perform fault location on the microservice system according to the call topology structure, which may include: determining a discarded interface according to the call topology structure.

[0049] It can be understood that the information processing device can obtain the modules not involved in the call relationship and the interfaces that no longer provide services through the call topology structure to confirm the discarded interfaces.

[0050] In some embodiments, the information processing device can obtain the modules not involved in the call relationship through the call topology structure. In one embodiment, the above-mentioned modules not involved in the call relationship are functional modules with the number of edges of the nodes in the call topology structure being 0. In one example, a microservice is a functional module.

[0051] In some embodiments, the information processing device can obtain the interfaces that no longer provide services through the call topology structure. In one embodiment, the above-mentioned interfaces that no longer provide services are discarded interfaces.

[0052] Figure 2 It is a schematic diagram of the implementation process for processing discarded interfaces in a microservice in a scenario of determining discarded interfaces provided by an embodiment of the present application. Refer to Figure 2 As shown, the processing of discarded interfaces in the above-mentioned scenario of determining discarded interfaces may include steps S201 to S202.

[0053] In step S201, as shown by the solid line in Figure 2 , delete the discarded interfaces in the microservice system.

[0054] It can be understood that after the information processing device determines the discarded interfaces in the microservice system through step S103, it can delete the discarded interfaces in the microservice system, which can optimize the call topology structure.

[0055] Optionally, in step 202, as shown by the dashed line in Figure 2 , record the interface information of the discarded interfaces in the microservice system.

[0056] It can be understood that after the information processing device deletes the obsolete interfaces in the microservice system through step S201, it can obtain the interface information of the obsolete interfaces in the microservice system, and then record the interface information of the obsolete interfaces in the microservice system, which can provide a reference for subsequent overall architecture analysis.

[0057] Case 2: The information processing device can also perform fault location and / or performance analysis on the microservice system according to the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library. In one example, the historical call topology structure is the call topology structure of the microservice system before the current moment, the dependency library information is the information of the third-party databases on which the microservices in the microservice system depend, and the dependency security library includes a security library without security vulnerabilities on which the third-party databases depend or a security library in which the security vulnerabilities on which the third-party databases depend are within a controlled range.

[0058] It can be understood that for the above Case 2, the information processing device can perform fault location and / or performance analysis on the microservice system after obtaining the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library.

[0059] In some embodiments, for the above Case 2, in step S103, performing fault location on the service system according to the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library may include: determining the microservices with frequently changed interfaces according to the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library. Among them, a frequently changed interface refers to an interface whose change count is greater than or equal to a set threshold, and the change includes at least one of the following: addition, deletion, and modification.

[0060] It can be understood that the information processing device can determine the microservices with interface change counts greater than or equal to the set threshold by judging that it can obtain the microservices with changed interfaces through the call topology structure and the historical service call topology structure. Exemplarily, the set threshold can be any value of 2, 10, 100, and is not limited here.

[0061] Figure 3 It is a schematic diagram of an implementation process for processing microservices with frequently changed interfaces in a scenario of determining frequently changed interfaces provided by an embodiment of the present application. Refer to Figure 3 As shown. The above processing of microservices with frequently changed interfaces in the scenario of determining frequently changed interfaces may include steps S301 to S302.

[0062] In step S301, it is judged whether negative factors are generated for the current service call.

[0063] Understandably, the information processing device determines the microservices with frequently changed interfaces through step S103, and then further analyzes these microservices to determine whether negative factors are generated for the current service call, so as to avoid the negative impact of the microservices with frequently changed interfaces on the current service call. In some embodiments, the above negative factors may be factors that have an adverse impact on a certain situation. In one example, the negative factors may include, but are not limited to, a complex service call topology structure.

[0064] Optionally, in step S302, refer to Figure 3 the dashed part in, and record the judgment result in the analysis report.

[0065] Understandably, after the information processing device determines whether negative factors are generated for the current service call through step S301, it can determine the microservices with frequently changed interfaces that generate negative factors for the current service call, and then record the judgment result in the analysis report, which can provide a reference for subsequent overall architecture analysis.

[0066] In some embodiments, for the above-mentioned situation two, in step S103, according to the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library, fault location of the microservice system may include: determining whether there are risks in the currently scanned microservice module according to the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library.

[0067] Understandably, the information processing device can match the dependencies in the dependency library information in the dependency security library in sequence. If there is an unsuccessful match of a dependency, it indicates that a dependency with a security risk is used in the microservice, that is, there are risks in the currently scanned microservice module.

[0068] In some embodiments, for the above-mentioned situation two, in step S103, according to the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library, fault location of the service system may include: determining whether there are security risk dependencies in the currently scanned microservice module according to the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library.

[0069] Understandably, the information processing device can also compare the dependency security library with the scanned dependency library information according to the call topology structure, historical call topology structure, dependency library information, and information in the dependency security library, and match the dependencies in the dependency library information in the dependency security library in sequence. If there is an unsuccessful match of a dependency, it indicates that a dependency with a security risk is used in the microservice.

[0070] Figure 4Schematic diagram of the implementation process of a dependency for confirming security risks provided for the implementation of this application. Refer to Figure 4 As shown. The above-mentioned dependency for determining security risks may include steps S401 to S405.

[0071] See Figure 4 As shown by the solid line in, in step S401, it is judged whether the current microservice module has joined the business cluster.

[0072] It can be understood that after the information processing device determines whether there are security risk dependencies for the currently scanned microservice modules through step S103, it can further analyze these microservice modules to judge whether the current microservice module has joined the business cluster. In one embodiment, different microservices form a business cluster to provide capabilities to the outside world. If the current microservice module has not joined the business cluster, it is necessary to repair the risk items of the microservice that has not joined the business cluster by means before it can join the business cluster.

[0073] In some embodiments, the means of repairing risk items includes at least one of dependency replacement and insecure call correction. In one example, different levels of security problems may be, but are not limited to, security problems with relatively simple dependency for security risk repair and security problems with relatively complex dependency for security risk repair.

[0074] In step S402, for the dependencies with security risks, different analysis and processing are performed according to different levels of security problems.

[0075] It can be understood that after the information processing device judges whether the current microservice module has joined the business cluster through step S401, for the microservice modules that have joined the business cluster, it can also analyze the dependencies with security risks and perform different analysis and processing according to different levels of security problems, which can improve the processing efficiency of different security problems.

[0076] In step S403, for the security problems with relatively simple dependency for security risk repair, at least one of direct configuration or minor version number upgrade is used for repair.

[0077] It can be understood that after the information processing device analyzes the dependencies with security risks and performs different analysis and processing according to different levels of security problems through step S402, it can also repair the security problems with relatively simple dependency for security risk by at least one of direct configuration or minor version number upgrade, which can repair the security problems with relatively simple dependency for security risk.

[0078] In step S404, for the security problems with relatively complex dependency for security risk repair, it is judged whether the current module is a hot module.

[0079] It can be understood that after the information processing device analyzes the dependencies with security risks through step S402 and performs different analysis and processing according to different levels of security issues, it can also target the relatively complex security issues for which the dependencies are security risks. By further analyzing whether the current module is a hot module, it is possible to classify and discuss the relatively complex security issues for which the dependencies are security risks, improving the efficiency of problem handling.

[0080] In some embodiments, as shown Figure 4 by the dashed line in [reference], in step S405, for the services and corresponding interface information involved in the identified risk module, determine the risk repair steps.

[0081] It can be understood that after the information processing device determines whether the current module is a hot module for the relatively complex security issues for which the dependencies are security risks through step S404, it can also determine the risk repair steps for the services and corresponding interface information involved in the identified risk module, providing a method for subsequent risk repair.

[0082] Figure 5 This is a schematic diagram of the implementation process for handling security risk dependencies in the currently scanned microservice module provided by the present application. Refer to Figure 5 as shown in [reference], the above handling of security risk dependencies in the currently scanned microservice can include steps S501 to S504.

[0083] Refer to Figure 5 as shown by the solid line in [reference], in step S501, for the hot module, determine the risk repair steps according to the priority rating of interface changes.

[0084] It can be understood that after the information processing device determines the risk repair steps for the services and corresponding interface information involved in the identified risk module through step S405, it can also determine the risk repair steps for the hot module according to the priority rating of interface changes, providing a method for subsequent risk repair.

[0085] In step S502, reduce the impact of security repair on the business and performance of the business cluster by updating in batches.

[0086] In one embodiment, before each batch update, it is necessary to perform a static scan to determine whether the current service security update will cause a destructive update to the dependent services. In some embodiments, the above static scan will not affect the online running process.

[0087] It can be understood that after the information processing device determines the risk repair for the hot module according to the priority rating of interface changes through step S501, it can also reduce the impact of security repair on the business and performance of the business cluster by updating in batches.

[0088] In some embodiments, evaluating the priority of interface changes includes at least one of the number of invocations and the number of dependent services.

[0089] In some embodiments, referring to Figure 5 as shown by the dashed line in, in step S503, for non-hot modules, determine the services and corresponding interfaces involved in the risk module update.

[0090] It can be understood that after the information processing device reduces the impact of security fixes on the services and performance of the business cluster through step S502 in batches, it can also determine the services and corresponding interfaces involved in the risk module update for non-hot modules, so as to make preventive handling before the risk module update.

[0091] In some embodiments, referring to Figure 5 as shown by the dashed line in, in step S504, before the service security update goes live, determine whether a disruptive update is made to the dependent services through static scanning.

[0092] It can be understood that after the information processing device determines the services and corresponding interfaces involved in the risk module update for non-hot modules through step S503, it can also determine whether a disruptive update is made to the dependent services through static scanning before the security update of the service goes live, so as to avoid a disruptive update of the dependent services, thereby affecting the system after the security update. In an example, after a disruptive update occurs to a dependent service, the service cannot be used in the original way.

[0093] In some embodiments, for the above-mentioned situation two, in step S103, according to the call topology structure, the historical call topology structure, the dependency library information, and the information in the dependency security library, perform performance analysis on the microservice system, which may include: determining hot modules according to the call topology structure, the historical call topology structure, the dependency library information, and the information in the dependency security library.

[0094] It can be understood that the information processing device can obtain the interface information of the externally exposed call interfaces through the call topology structure, and confirm the interfaces with duplicate functions, that is, hot modules, according to the function information in the interface information.

[0095] The information processing device can also obtain the interface information of the externally exposed call interfaces through the call topology structure, and confirm the interfaces with duplicate functions, that is, hot modules, according to the reference factors in the interface information.

[0096] The information processing device can also determine the modules whose number of calls or being called exceeds a preset threshold through the call topology structure as hot modules in the service system.

[0097] In some embodiments, the reference factors are at least one of the number of module dependencies, the degree of module coupling, and the number of API interfaces. The number of module dependencies refers to the number of other modules that a certain module depends on, and the dependency includes at least one of calling and being called. The degree of module coupling refers to the degree of at least one of association, perception, and dependency between a module and other modules. The number of API interfaces refers to the number of interfaces through which microservices communicate via clearly defined interfaces.

[0098] In some embodiments, when the reference factor is the number of module dependencies, the information processing device can call the topological structure and determine whether the number of module dependencies is greater than a third preset quantity. If the number of module dependencies is less than the third preset quantity, it is determined as a hot module. Exemplarily, the third preset quantity can be any value of 1, 10, 100, and is not limited herein.

[0099] In some embodiments, when the reference factor is the degree of module coupling, the information processing device can also call the topological structure and determine whether the degree of module coupling is greater than a fourth preset quantity. If the number of module dependencies is less than the fourth preset quantity, it is determined as a hot module. Exemplarily, the fourth preset quantity can be any value of 1, 10, 100, and is not limited herein.

[0100] In some embodiments, when the reference factor is the number of API interfaces, the information processing device can call the topological structure and determine whether the number of API interfaces is greater than a fifth preset quantity. If the number of API interfaces is less than the fifth preset quantity, it is determined as a hot module. Exemplarily, the fifth preset quantity can be any value of 1, 10, 100, and is not limited herein.

[0101] Figure 6 It is a schematic diagram of the implementation process for processing hot modules in microservices in a scenario of determining hot modules provided by an embodiment of the present application. Refer to Figure 6 As shown. The above processing of hot modules in microservices in the scenario of determining hot modules may include steps S601 to step S608.

[0102] Refer to Figure 6 As shown by the solid line in, in step S601, interface information of the call interfaces exposed by each function in the hot module is obtained.

[0103] It can be understood that after the information processing device determines the hot module through step S103, it can further analyze the above hot module to obtain the interface information of the call interfaces exposed by each function in the hot module, providing a reference for obtaining the functions of each call interface subsequently.

[0104] In step S602, the functions of each of the above call interfaces are determined.

[0105] It can be understood that after the information processing device obtains the interface information of the call interfaces exposed by each function in the hotspot module through step S601, it can also determine the functions of the respective call interfaces in the above call interfaces based on the call information of the call interfaces, and can confirm microservices with different functions.

[0106] In step S603, confirm the coupling degree of the hotspot module.

[0107] In one embodiment, the module coupling degree may be the degree including at least one of association, perception, and dependence between a module and other modules.

[0108] It can be understood that after the information processing device determines the functions of the respective call interfaces in the above call interfaces through step S602, it can further analyze and confirm the coupling degree of the hotspot module based on the functions of the respective call interfaces, and can confirm that the number of microservices with different functions of the call interfaces is greater than or equal to the second preset number.

[0109] In step S604, determine the microservices to be disassembled.

[0110] In one embodiment, the microservices to be disassembled may be microservices with the number of call interfaces with different functions greater than or equal to the second preset number.

[0111] It can be understood that after the information processing device determines the microservices to be disassembled through step S603 based on the functions of the respective call interfaces and determines that there are multiple types of service interfaces, it can also determine the microservices to be disassembled, providing a reference for processing microservices with the number of call interfaces with different functions greater than or equal to the second preset number.

[0112] In step S605, disassemble the microservices.

[0113] It can be understood that after the information processing device determines the microservices to be disassembled through step S604, it can also disassemble the microservices to be disassembled, which can reduce the coupling degree of the hotspot module.

[0114] In one embodiment, the microservices to be disassembled may be disassembled into multiple microservices according to the service type, so that the number of call interfaces in the disassembled microservices is less than the second preset number, reducing the coupling degree of the hotspot module.

[0115] In some embodiments, as shown by the dotted line in Figure 6 In step S606, confirm the functional redundancy of the hotspot module.

[0116] In one embodiment, the functional redundancy of the above hotspot module is a module with the number of functions greater than or equal to the first preset number in the system.

[0117] It can be understood that after the information processing device determines the functions of each call interface in the above call interfaces through step S602, and further analyzes the interface information of the call interfaces, it can also determine the functional redundancy of the hot modules, providing an object for deleting or modifying hot modules with a function number greater than or equal to the first preset number in the subsequent process.

[0118] In some embodiments, as shown by the dashed line in Figure 6 in step S607, determine the microservices to be deleted or modified.

[0119] It can be understood that after the information processing device confirms the functional redundancy of the hot modules through step S606, it can also confirm the microservices to be deleted or modified according to the microservices with at least one similar function, providing an object for deleting or modifying hot modules with a function number greater than or equal to the first preset number in the subsequent process.

[0120] In some embodiments, in step S608, as shown by the dashed line in Figure 6 delete or modify the microservices.

[0121] It can be understood that after the information processing device determines the microservices to be deleted or modified through step S607, it can also delete or modify microservices with a function number greater than or equal to the first preset number, so that the function number of microservices with similar functions is less than the first preset number, thereby reducing the functional redundancy of the hot modules.

[0122] Figure 7 It is a schematic diagram of the implementation process of the overall architecture analysis and security analysis provided by the embodiments of the present application. Refer to Figure 7 as shown. The above overall architecture analysis and security analysis may include steps S701 to S724.

[0123] In step S701, use the Abstract Syntax Tree (AST) to scan and analyze the code to obtain the function list and dependency library information in the source code file.

[0124] It can be understood that the information processing device can perform syntax analysis on the source code of each microservice, and the information processing device can obtain the function list in the source code and the dependency library information relied on by each microservice.

[0125] In some embodiments, the information processing device can perform syntax analysis on the source code of each microservice by scanning the source code of each microservice through a syntax analyzer. In one example, the syntax analyzer can perform syntax analysis using an Abstract Syntax Tree (AST). In one example, the above AST is a separately written software project, independent of the microservice system being scanned, and will not increase the source code of the microservice system being scanned; in one example, performing syntax analysis using the AST does not require embedding an SDK for logging, is non-invasive to the business code, and can obtain a more complete service call relationship graph, etc.

[0126] In step S702, the function list is scanned sequentially.

[0127] It can be understood that after the information processing device scans and analyzes the code using the Abstract Syntax Tree (AST) through step S701 to obtain the function list and dependency library information in the source code file, it can also scan the function list sequentially to prepare for determining the microservices it depends on later.

[0128] In step S703, if it is determined according to the language characteristics that the current function is an API interface, the information of the current interface is recorded.

[0129] It can be understood that after the information processing device scans the function list sequentially through step S702, it can also determine according to the language characteristics that the current function is an API interface and record the information of the current interface to prepare for the subsequent overall architecture analysis. The above information includes the path, Method, call parameters, etc.

[0130] In step S704, the microservices it depends on are determined according to the interface information it calls.

[0131] It can be understood that after the information processing device determines according to the language characteristics that the current function is an API interface and records the information of the current interface through step S703, it can also determine the microservices it depends on according to the interface information it calls to prepare for constructing a service call topology graph.

[0132] In step S705, the microservices it depends on are recursively called.

[0133] It can be understood that after the information processing device determines the microservices it depends on according to the interface information it calls through step S704, it can also recursively call the microservices it depends on to prepare for constructing a service call topology graph.

[0134] In step S706, a service call topology graph is constructed through a visualization component.

[0135] It can be understood that after the information processing device recursively calls the microservices it depends on through step S705, it can also construct a service call topology graph through the visualization component, which can more completely and intuitively determine the call relationship between each microservice.

[0136] In step S707, a snapshot is recorded.

[0137] It can be understood that after the information processing device constructs a service call topology graph through the visualization component in step S706, it can also record a snapshot, which can provide a reference for subsequent analysis.

[0138] In step S708, based on the current topology graph, historical topology graph snapshots, dependency security library, and service ethical dependency library information, a security analysis is performed on the overall architecture and security issues.

[0139] It can be understood that after the information processing device records a snapshot in step S707, it can also perform a security analysis on the overall architecture and security issues based on the current topology graph, historical topology graph snapshots, dependency security library, and service ethical dependency library information.

[0140] In step 709, a comparison is made based on the dependency security library and the dependency library information obtained by scanning to obtain the dependent modules with security risks.

[0141] It can be understood that after the information processing device performs a security analysis on the overall architecture and security issues based on the current topology graph, historical topology graph snapshots, dependency security library, and service ethical dependency library information in step S708, it can also make a comparison based on the dependency security library and the dependency library information obtained by scanning to obtain the dependent modules with security risks, which can prepare for the analysis of security issues.

[0142] In step 710, it is judged whether the current risk module joins the cluster.

[0143] It can be understood that after the information processing device obtains the dependent modules with security risks by making a comparison based on the dependency security library and the dependency library information obtained by scanning in step S709, it can also judge whether the current risk module joins the cluster, which can classify and process whether the current risk module joins the cluster.

[0144] In step S711, for the risk modules that join the cluster among the current risk modules, it is judged whether it is difficult to repair the security risks.

[0145] It can be understood that after the information processing device judges whether the current risk module joins the cluster in step S710, it can also judge whether it is difficult to repair the security risks for the risk modules that join the cluster among the current risk modules, which can classify and process the repair of security risks according to complexity.

[0146] In step S712, for the risk modules with simple security risk repair, direct security repair is performed.

[0147] It can be understood that after the information processing device determines whether the security risk repair is difficult for the risk modules added to the cluster through step S711, it can also directly perform security repair on the risk modules with simple security risk repair. The above security repair can be performed through configuration or minor version number upgrade, etc., without causing destructive updates to the definition or call method of the interfaces of the current service.

[0148] In step S713, for the risk modules with complex security risk repair, it is determined whether the current risk module is a hot module.

[0149] It can be understood that after the information processing device determines whether the security risk repair is difficult for the risk modules added to the cluster through step S711, it can also determine whether the current risk module is a hot module for the risk modules with complex security risk repair, and classify and process the current risk modules according to whether they are hot modules.

[0150] In step S714, for the risk modules that are hot modules among the current risk modules, determine the services and corresponding interface information involved in the risk module update.

[0151] It can be understood that after the information processing device determines whether the current risk module is a hot module for the risk modules with complex security risk repair through step S713, it can also determine the services and corresponding interface information involved in the risk module update for the risk modules that are hot modules among the current risk modules, so as to prepare for subsequent evaluation of interface priorities.

[0152] In step S715, evaluate the priority of interface changes and determine the risk point repair steps.

[0153] It can be understood that after the information processing device determines the services and corresponding interface information involved in the risk module update for the risk modules that are hot modules among the current risk modules through step S714, it can also determine the risk point repair steps according to the evaluation of the priority of interface changes, so as to prepare for subsequent risk point repair.

[0154] In step S716, perform batch updates.

[0155] It can be understood that after the information processing device evaluates the priority of interface changes and determines the risk point repair steps through step S715, it can also perform batch updates. In some embodiments, batch updates are used to reduce the impact of security repair on the business and performance of the service cluster.

[0156] In step S717, for a risk module where the current risk module is a non - hot - spot module, determine the services involved in the risk module update and the corresponding interface information.

[0157] It can be understood that after the information processing device determines whether the current risk module is a hot - spot module for a risk module with complex security risk repair through step S713, it can also determine the services involved in the risk module update and the corresponding interface information for a risk module where the current risk module is a non - hot - spot module.

[0158] In step S718, determine through static scanning that no destructive update has occurred to the dependent services.

[0159] It can be understood that after the information processing device determines the services involved in the risk module update and the corresponding interface information for a risk module where the current risk module is a non - hot - spot module through step S717, it can also determine through static scanning that no destructive update has occurred to the dependent services, which can avoid destructive updates to the dependent services. In some embodiments, it is determined through static scanning that no destructive update has occurred to the dependent services before the service security update goes live.

[0160] In step S719, for a risk module where the current risk module has not joined the cluster, perform risk repair items before it can join the cluster.

[0161] It can be understood that after the information processing device determines whether the current risk module has joined the cluster through step S710, it can also perform risk repair items for a risk module where the current risk module has not joined the cluster before it can join the cluster, which can add a risk module that has not joined the cluster to the cluster after risk repair. In some embodiments, the above - mentioned risk repair items can be risk - dependency replacement or insecure call correction.

[0162] In step S720, analyze the overall architecture and security issues based on the current topology diagram, historical topology diagram snapshot, dependency security library, and dependency library information of the service.

[0163] It can be understood that after the information processing device records the snapshot through step S707, it can also analyze the overall architecture and security issues based on the current topology diagram, historical topology diagram snapshot, dependency security library, and dependency library information of the service, which can achieve the overall architecture analysis and security issue analysis of the microservice system.

[0164] In step S721, record the abandoned interfaces, hot - spot modules, and interface call change trends of the modules in the analysis report.

[0165] It can be understood that after the information processing device performs an overall architecture analysis on the overall architecture and security issues based on the current topology diagram, historical topology diagram snapshots, dependency security libraries, and service ethical dependency library information through step S720, it can also record the abandoned interfaces, hot modules, and interface call change trends of the modules in the analysis report, providing a reference for subsequent evaluation of the problems existing in the system.

[0166] In step S722, based on the analysis report, evaluate the problems currently existing in the system.

[0167] It can be understood that after the information processing device records the abandoned interfaces, hot modules, and interface call change trends of the modules in the analysis report through step S721, it can also evaluate the problems currently existing in the system based on the analysis report, providing a reference for subsequent optimization of the system solution.

[0168] In step S723, propose an optimization solution.

[0169] It can be understood that after the information processing device evaluates the problems currently existing in the system according to the analysis report through step S722, it can also propose an optimization solution, providing a reference for fixing the problems existing in the system.

[0170] In step S724, record the optimization solution in the analysis report to form a knowledge base.

[0171] It can be understood that after the information processing device evaluates the problems currently existing in the system according to the analysis report through step S722, it can also record the optimization solution in the analysis report to form a knowledge base. In some embodiments, the knowledge base can provide support for the update and optimization of subsequent projects.

[0172] See Figure 8 , Figure 8 is a schematic structural diagram of an information processing device provided by an embodiment of the present application, which can be software in the form of programs and plugins, etc. The information processing device 855 includes the following software modules: a first acquisition module 8551, a first determination module 8552, and a second determination module 8553. These modules are logical, so they can be arbitrarily combined or further split according to the functions they implement. The functions of each module will be described below.

[0173] The first acquisition module 8551 is used to acquire the call relationships between each microservice in the microservice system; among them, the information processing for acquiring the call relationships between each microservice in the microservice system is used to represent the call relationships between each microservice and its upstream and downstream microservices.

[0174] The first determination module 8552 is configured to obtain the call topology of the microservice system according to the above call relationship; wherein, the call topology of the microservice system is used to visually represent the call relationship between each microservice and its upstream and downstream microservices.

[0175] The second determination module 8553 is configured to perform fault location and / or performance analysis on the microservice system according to at least the above call topology; wherein, by analyzing each node and the edges of the nodes in the call topology, the nodes for fault location and / or performance analysis in the call topology are determined, so as to further perform fault location and / or performance analysis on the microservice system.

[0176] In some embodiment modes, according to at least the above call topology includes according to the call topology of the microservice system; the second determination module 8553 is configured to: perform fault location on the microservice system.

[0177] In some embodiment modes, according to at least the above call topology includes according to the call topology of the microservice system, the historical call topology, the dependency library information, and the information in the dependency security library; the second determination module 8553 is configured to: perform fault location and / or performance analysis on the microservice system.

[0178] In some embodiment modes, fault location includes confirming abandoned interfaces; the second determination module 8553 is configured to obtain the interfaces that do not involve call relationships and no longer provide services according to the call topology to confirm abandoned interfaces.

[0179] In some embodiment modes, fault location includes determining the microservices with frequently changed interfaces; the second determination module 8553 is configured to determine the interfaces with the number of changes greater than or equal to the set threshold according to the call topology, the historical call topology, the dependency library information, and the information in the dependency security library.

[0180] In some embodiment modes, fault location includes determining whether there are risks in the currently scanned microservice module; the second determination module 8553 is configured to match the dependencies in the dependency library information with the dependency security library one by one according to the call topology, the historical call topology, the dependency library information, and the information in the dependency security library. If there is an unsuccessful match of a dependency item, it indicates that a dependency with security risks is used in the microservice, that is, there are risks in the currently scanned microservice module.

[0181] In some embodiments, fault location includes determining whether there are security risk dependencies in the currently scanned microservice module; a second determination module 8553, configured to compare, according to the call topology structure, the historical call topology structure, the dependency library information, and the information in the dependency security library, and match the dependencies in the dependency library information in the dependency security library one by one. If there is a dependency item that fails to match, it indicates that the microservice uses a dependency with security risks.

[0182] In some embodiments, performance analysis includes determining a hot module; a second determination module 8553, configured to obtain the interface information of the externally exposed call interfaces according to the call topology structure, and confirm the interfaces with duplicate functions, that is, the hot modules, according to the function information in the interface information.

[0183] The description of the above device embodiments is similar to the description of the above method embodiments and has similar beneficial effects to the method embodiments.

[0184] In some embodiments, the functions or modules included in the device provided in the embodiments of the present application can be used to execute the methods described in the above method embodiments. For the technical details not disclosed in the device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

[0185] It should be noted that in the embodiments of the present application, if the above-mentioned microservice-based information processing method is implemented in the form of software function modules and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the related technology, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions for causing an electronic device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods in the various embodiments of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read only memory (ROM), magnetic disks, or optical discs that can store program codes. In this way, the embodiments of the present application are not limited to any specific hardware, software, or firmware, or any combination of hardware, software, and firmware.

[0186] In some other embodiments, the information processing apparatus 855 provided in the embodiments of the present application may be implemented in a hardware manner. As an example, the information processing apparatus 855 provided in the embodiments of the present application may be a processor in the form of a hardware decoding processor, which is programmed to execute the information processing method based on microservices provided in the embodiments of the present application. For example, a processor in the form of a hardware decoding processor may employ one or more application specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0187] The following describes an exemplary application of the electronic device provided in the embodiments of the present application. The electronic device provided in the embodiments of the present application may be a notebook computer, a tablet computer, a desktop computer, a mobile device (such as a mobile phone, a wearable smart watch, a dedicated messaging device), an electric vehicle, or other rechargeable devices, but is not limited thereto. Alternatively, the electronic device may also be implemented as a server.

[0188] In some embodiments, the server may be an independent physical server, or a server cluster or a distributed system composed of multiple physical servers, or may also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, and big data and artificial intelligence platforms, but is not limited thereto.

[0189] In some embodiments, the server and the electronic device may be directly or indirectly connected through a wired communication method or a wireless communication method, and no specific limitation is imposed in the embodiments of the present application.

[0190] See Figure 9 , Figure 9 is a schematic structural diagram of the electronic device provided in the embodiments of the present application. Figure 9 The electronic device 900 shown includes: at least one processor 910, a memory 950, at least one network interface 920, and a user interface 930. Each component in the electronic device 900 is coupled together through a bus system 940. It can be understood that the bus system 940 is used to realize the connection and communication between these components. In addition to the data bus, the bus system 940 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in Figure 9Various buses are labeled as bus system 940.

[0191] Processor 910 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0192] User interface 930 includes one or more output devices 931 that enable the presentation of media content, including one or more speakers and / or one or more visual display screens. User interface 930 also includes one or more input devices 932, including user interface components that facilitate user input, such as a keyboard, a mouse, a microphone, a touch screen display, a camera, and other input buttons and controls.

[0193] Memory 950 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disc drives, etc. Memory 950 optionally includes one or more storage devices that are physically remote from processor 910.

[0194] Memory 950 includes volatile memory or non-volatile memory, and can also include both volatile and non-volatile memory. The non-volatile memory can be read only memory (ROM), and the volatile memory can be random access memory (RAM). The memory 950 described in the embodiments of the present application is intended to include any suitable type of memory.

[0195] In some embodiments, memory 950 is capable of storing data to support various operations. Examples of such data include programs, modules, and data structures, or subsets or supersets thereof, which are illustrated below.

[0196] Operating system 951, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks.

[0197] Network communication module 952 is used to reach other computing devices via one or more (wired or wireless) network interfaces 920. Exemplary network interfaces 920 include: Bluetooth, Wi-Fi (Wireless Fidelity), and Universal Serial Bus (USB), etc.

[0198] A presentation module 953 for enabling the presentation of information (e.g., a user interface for operating a peripheral device and displaying content and information) via one or more output devices 931 associated with the user interface 930 (e.g., a display screen, a speaker, etc.).

[0199] An input processing module 954 for detecting and translating one or more user inputs or interactions from one of one or more input devices 932.

[0200] Figure 9 The information processing device 955 in Figure 8 The information processing device 855 may be the same device.

[0201] In some embodiments, the microservice information processing method provided by the embodiments of the present application may be implemented in software and stored in the memory 950.

[0202] The embodiments of the present application provide an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, some or all of the steps in the above method are implemented.

[0203] The embodiments of the present application provide a storage medium, on which a computer program is stored. When the computer program is executed by a processor, some or all of the steps in the above method are implemented. The above storage medium may be transient or non-transient.

[0204] The embodiments of the present application provide a computer program, including computer-readable code. When the above computer-readable code runs in an electronic device, the processor in the electronic device executes to implement some or all of the steps in the above method.

[0205] The embodiments of the present application provide a computer program product. The computer program product includes a non-transient computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, some or all of the steps in the above method are implemented. The computer program product may be specifically implemented in a manner of hardware, software, or a combination thereof.

[0206] In some embodiments, the above computer program product is specifically embodied as a computer storage medium. In other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0207] It should be noted here that: the descriptions of the above embodiments tend to emphasize the differences between the embodiments, and their similarities can be referred to each other. The descriptions of the above device, storage medium, computer program, and computer program product embodiments are similar to the descriptions of the above method embodiments and have beneficial effects similar to those of the method embodiments. For the technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of the present application, please refer to the descriptions of the method embodiments of the present application for understanding.

[0208] It should be understood that the "one embodiment" or "an embodiment" mentioned throughout the specification means that the specific features, structures, or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, the "in one embodiment" or "in an embodiment" that appears throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures, or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the order numbers of the above steps / processes do not mean the order of execution. The order of execution of each step / process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application. The serial numbers of the embodiments of the present application above are only for description and do not represent the advantages or disadvantages of the embodiments.

[0209] It should be noted that in this article, the term "comprising", "including" or any other variation thereof is intended to cover a non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the phrase "comprising a..." does not exclude the existence of additional identical elements in the process, method, article or device including the element.

[0210] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only illustrative. For example, the above unit division is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed with each other can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical, or other forms.

[0211] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units; and some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0212] In addition, in each embodiment of this application, each functional unit may be fully integrated into one processing unit, or each unit may be separately regarded as a unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware, or in the form of a combination of hardware and software functional units.

[0213] Those of ordinary skill in the art can understand that all or part of the steps of implementing the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including the above method embodiments; and the foregoing storage medium includes: removable storage devices, read only memory (ROM), magnetic disks, or optical disks and other various media that can store program codes.

[0214] Alternatively, if the above-mentioned integrated units of this application are implemented in the form of software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the related technology can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing an electronic device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the above methods of each embodiment of this application. And the foregoing storage medium includes: removable storage devices, ROM, magnetic disks, or optical disks and other various media that can store program codes.

[0215] The above is only the implementation mode of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed by this application can easily think of changes or substitutions, which should all be covered by the protection scope of this application.

Claims

1. An information processing method based on microservices, characterized in that The method includes: Obtaining the call relationships among the microservices in the microservice system; Obtaining the call topology structure of the microservice system according to the call relationships; Performing fault location and / or performance analysis on the microservice system according to at least the call topology structure.

2. The method according to claim 1, characterized in that, The obtaining of the call relationships among the microservices in the microservice system includes at least one of the following: Obtaining the call relationships between each of the microservices and the upstream microservices; Obtaining the call relationships between each of the microservices and the downstream microservices; Wherein, the upstream microservice is the microservice that calls each of the microservices, and the downstream microservice is the microservice called by each of the microservices.

3. The method according to claim 2, wherein The obtaining of the call relationships between each of the microservices and the upstream microservices includes: Scanning the source code of each of the microservices using an Abstract Syntax Tree (AST) to obtain at least one dependency library information in the source code, where the dependency library information is the information of the third-party databases on which the microservices in the microservice system depend; For each of the dependency library information in the at least one dependency library information, recording the interface information of the call interfaces exposed by each function in the source code; Determining the upstream microservice according to the recorded interface information of the call interfaces exposed by each function; Recursively calling the upstream microservice to obtain the call relationships between each of the microservices and the upstream microservices.

4. The method according to claim 2, characterized in that, The obtaining of the call relationships between each of the microservices and the downstream microservices includes: Scanning the source code of each of the microservices using an Abstract Syntax Tree (AST) to obtain at least one function in the source code; For each function in the source code, recording the interface information of the call interfaces exposed by each function; Obtaining the call relationships between each of the microservices and the downstream microservices according to the interface information.

5. The method according to claim 1, wherein The obtaining of the call topology structure of the microservice system according to the call relationships includes: Obtaining the call topology structure of the microservice system through a visualization component according to the call relationships.

6. The method according to claim 1, wherein The performing of fault location on the microservice system according to the call topology structure includes: Determining the abandoned interfaces in the microservice system according to the call topology structure, where the abandoned interfaces include the modules not involved in the call relationships and the interfaces that no longer provide services.

7. The method according to claim 6, wherein After determining the abandoned interfaces in the microservice system, the method further includes: Deleting the abandoned interfaces; and / or, Recording the interface information of the abandoned interfaces.

8. The method according to claim 1, wherein The performing of fault location and / or performance analysis on the microservice system according to at least the call topology structure includes: Performing fault location and / or performance analysis on the microservice system according to the call topology structure, the historical call topology structure, the dependency library information, and the information in the dependency security library; Among them, the historical call topology structure is the call topology structure of the microservice system before the current moment, the dependency library information is the information of the third-party databases on which the microservices in the microservice system depend, and the dependent security library includes the security library without security vulnerabilities on which the third-party database depends or the security library with security vulnerabilities within a controlled range on which the third-party database depends.

9. The method according to claim 8, characterized in that Performing fault location and / or performance analysis on the microservice system according to the information in the call topology structure, historical call topology structure, dependency library information, and dependent security library includes: Determining a first interface in the microservice system whose number of changes exceeds a preset threshold according to the information in the call topology structure, historical call topology structure, dependency library information, and dependent security library, where the changes include at least one of the following: addition, deletion, and modification; and / or, Determining a hot module in the microservice system according to the information in the call topology structure, historical call topology structure, dependency library information, and dependent security library, where the hot module includes a module whose number of calls or being called exceeds a preset threshold.

10. The method according to claim 9, wherein After determining the hot module in the microservice system, the method further includes: Obtaining interface information of the call interfaces exposed by each function in the hot module; Determining a microservice whose number of functions in the call interface is greater than or equal to a first preset number according to the interface information; Deleting or modifying the microservice whose number of functions is greater than or equal to the first preset number.

11. The method according to claim 9, wherein After determining the hot module in the microservice system, the method further includes: Obtaining interface information of the call interfaces exposed by each function in the hot module; Determining the functions of each call interface in the call interface according to the interface information; Determining a microservice to be disassembled in the hot module according to the functions of each call interface, where the microservice to be disassembled is a microservice whose number of call interfaces with different functions is greater than or equal to a second preset number; Disassembling the microservice to be disassembled so that the number of call interfaces with different functions in the disassembled microservice is less than the second preset number.

12. An information processing apparatus, characterized in that, The device includes: A first acquisition module, configured to acquire the call relationships between microservices in the microservice system; A first determination module, configured to obtain the call topology structure of the microservice system according to the call relationships; A second determination module, configured to perform fault location and / or performance analysis on the microservice system according to at least the call topology structure.

13. An electronic device, comprising a memory and a processor, the memory storing a computer program that can run on the processor, characterized in that, When the processor executes the program, it implements the steps in the method according to any one of claims 1 to 11.

14. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps in the method according to any one of claims 1 to 11.

15. A computer program product, the computer program product includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, it implements the steps in the method according to any one of claims 1 to 11.

Images