Interface management method and related device

Abstract

Provided in the present application is an interface management method, which comprises: acquiring interface call records of a plurality of micro-services in an application, wherein the interface call records comprise interface calls that the micro-services provide for inside the application and / or interface calls that the micro-services provide for outside the application; on the basis of the interface call records of the plurality of micro-services, drawing an interface call relationship graph of the application in a running state; on the basis of micro-service registration information of the application, drawing a boundary of the application in the interface call relationship graph; and when there is an interface call in the interface call records that breaks through the boundary of the application, presenting to a user an interface call that poses a security risk, such as the interface call which breaks through the boundary of the application. In the method, an interface call relationship graph of an application in a running state is drawn by means of interface call records of a plurality of micro-services, and a boundary of the application is drawn in view of micro-service registration information of the application, such that an interface call which breaks through the boundary of the application is identified, thereby realizing security risk monitoring for the application, and providing a basis for security governance and flow control governance of the application.

Description

Interface management method and related equipment

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 2, 2023, with application number 202311456090.0 and invention name “A method for interface management and related equipment”, and claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 30, 2024, with application number 202410129034.4 and invention name “A method for interface management and related equipment”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to an interface management method, an application control system, a computing device cluster, a computer-readable storage medium, and a computer program product. Background Art

[0003] An Application Programming Interface (API) is a set of specific rules and requirements that programs provide to ensure interoperability. With the continuous development of cloud applications, applications can not only provide open APIs to other applications or users, but also provide APIs internally so that different application modules can make API calls. For example, in applications based on a microservices architecture, microservices can also make calls between each other through APIs.

[0004] As applications incorporate more and more microservices, API calls become increasingly complex. For example, API calls can include API calls between microservices within an application, as well as API calls between applications. Inter-application API calls can also be categorized as applications calling external APIs, or external applications calling internal APIs.

[0005] Application-level API call traffic poses significant challenges to application security and traffic control. For example, API calls in the form of Elephant Flow can impact the normal operation of applications. The industry urgently needs an interface management method to ensure application security or to implement effective traffic control.

[0006] Summary of the Invention

[0007] This application provides an interface management method that uses the interface call records of multiple microservices to draw an interface call relationship diagram of an application in operation. This method, combined with the application's microservice registration information, draws the application's boundaries, thereby identifying interface calls that break through the application's boundaries, enabling application security risk monitoring, ensuring application security, and effectively controlling application traffic, providing a foundation for API security governance and flow control governance. This application also provides an application control system, a computing device cluster, a computer-readable storage medium, and a computer program product corresponding to the above-mentioned interface management method.

[0008] In the first aspect, the present application provides an interface management method. The method can be executed by an application control system. The application control system is used to identify risks of interface calls to assist in security management and traffic management. The application control system can be a software system, which can be an independent software system, or integrated into other software systems in the form of plug-ins, functional modules, applets, etc. The software system can be deployed in a computing device cluster, and the computing device cluster executes the program code of the software system, thereby executing the interface management method of the present application. In some examples, the application control system can also be a hardware system, such as a computing device cluster with interface management functions, which executes the interface management method of the present application when the computing device cluster is running.

[0009] Specifically, the application control system can obtain the interface call records of multiple microservices in the application, and the interface call records include the interface calls provided by the microservices to the internal application and / or the interface calls provided by the microservices to the external application. The application control system can draw the interface call relationship diagram of the application in the running state based on the interface call records of multiple microservices. Then, the application control system can draw the boundary of the application in the interface call relationship diagram based on the microservice registration information of the application. Among them, the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center. When there are interface calls that break through the boundaries of the application in the interface call records, the application control system displays the interface calls with security risks to the user (such as abnormal calls, unreasonable API calls). Among them, the interface calls with security risks include interface calls that break through the boundaries of the application.

[0010] This method aggregates application-level interface call records and uses them to draw application-level interface call relationships. It defines the application boundary in combination with the application's microservice registration information. In this way, it can identify unsafe application-level traffic (i.e., traffic with security risks), such as interface calls that break through the application boundary. The above unsafe traffic is displayed in the form of a view. On the one hand, it can remind developers to rectify unreasonable interface call relationships. On the other hand, the identified interface calls can be used to monitor whether there are uncontrollable elephant flows, whether there are frequent calls that can trigger denial of service rat flows, and whether there are externally exposed interfaces without access control. In this way, effective traffic control can be performed on the application, providing a basis for security governance and flow control governance of application interfaces.

[0011] In some possible implementations, the application may also include an application gateway. The application gateway is a middleware for managing and routing microservice requests. The application gateway acts as an entry point in the microservice architecture, receiving requests from clients (such as other applications) and routing the requests to the appropriate microservices. In specific implementations, the application control system may also obtain the interface call records of the application gateway. The interface call records of the application gateway include the interface calls of the microservices inside the application by the application gateway. Accordingly, when drawing the interface call relationship diagram, the application control system may draw the interface call relationship diagram of the application in the running state based on the interface call records of multiple microservices and the interface call records of the application gateway. The application control system may draw the boundaries of the application in the running state in the interface call relationship diagram based on the microservice registration information of the application and the registration information of the application gateway. Among them, the boundaries of the application surround the microservices and the application gateway registered by the application in the registration center. The application control system can show the user the interface calls that break through the boundaries of the application and do not pass through the application gateway.

[0012] For applications that include application gateways, the application gateway can also be regarded as a microservice. When drawing the interface call relationship diagram, it can also be drawn according to the interface call records of the application gateway. When drawing the boundary of the application, it can be drawn in combination with the application's microservice registration information and the application gateway's registration information. Based on the above interface call relationship diagram and boundaries, interface calls that directly break through the application boundary without passing through the application gateway can be accurately identified, such as non-compliant calls from outside to inside or from inside to outside without passing through the application gateway, providing assistance for application security governance or flow control governance.

[0013] In some possible implementations, the application control system can aggregate the interface call records of multiple microservices in the application, and then analyze the aggregated interface call records to form a relational call record. Among them, the relational call record can be a record of the interface call relationship in the form of a relational data table. By performing the above-mentioned processing on the interface call records, the application control system can reduce the difficulty of drawing the interface call relationship diagram and improve the drawing efficiency. Furthermore, when the application includes an application gateway, the application control system can aggregate the call records of the application gateway with the interface call records of the microservices, thereby drawing an interface call relationship diagram including the application gateway. In this way, a more comprehensive and accurate interface call relationship diagram can be drawn.

[0014] In some possible implementations, the application control system may also obtain static analysis results of the application's source code, where the static analysis results include the static call relationships of the application's microservices. The application control system may analyze the application's runtime interface call relationship graph and static call relationships to obtain interface calls that exist in the runtime interface call relationship graph but not in the static call relationships. Accordingly, interface calls posing security risks include those that exist in the runtime interface call relationship graph but not in the static call relationships.

[0015] This method analyzes the static call relationship obtained by static analysis of the application source code and the interface call relationship diagram of the application in the running state, for example, by performing a comparative analysis, thereby discovering unsafe interface calls that do not exist in the static call relationship but exist in the interface call relationship diagram in the running state, providing richer information for the security management and flow control management of the application.

[0016] In some possible implementations, the application control system can also draw a static interface call relationship graph of the application based on the static call relationship of the application's microservices. Accordingly, the application control system can analyze the interface call relationship graph of the application in the running state and the interface call relationship graph of the application in the static state. Among them, the application control system can use a graph processing algorithm to analyze the interface call relationship graph of the application in the running state and the interface call relationship graph of the application in the static state, so as to quickly obtain abnormal calls that do not exist in the static call relationship but exist in the interface call relationship graph of the running state. This method combines dynamic and static analysis (dynamic analysis and static analysis) to identify interface calls with security risks in the application, thereby ensuring the security of the application.

[0017] In some possible implementations, the application control system can draw the static interface call relationship graph of the application in the running state based on the static call relationships of the application's microservices. Specifically, for any interface call relationship in the static call relationship, the application control system can check whether the running state interface call relationship graph includes an edge corresponding to the interface call relationship. If so, the edge is reused; if not, the edge corresponding to the interface call relationship is drawn in the running state interface call relationship graph. To facilitate differentiation, the application control system can use different styles to draw the edges corresponding to the static call relationships.

[0018] By drawing the static interface call relationship diagram and the running interface call relationship diagram on the same relationship diagram, the method can facilitate users to view abnormal calls or unreasonable interface calls, and provide a reference for developers to rectify unreasonable call relationships.

[0019] In some possible implementations, the application control system can also display call information about the interface call to the user, including at least one of the call source, call method, call path, or call parameters. By displaying detailed information such as the call source, call method, call path, or call parameters when displaying interface calls, this method can provide developers with richer information to help them correct unreasonable call relationships.

[0020] In some possible implementations, the application control system can also display interface calls that pose security risks to the user through a target style. The target style is different from the display style of compliant interface calls. The style can include at least one of the color, line type, or thickness of the edge that characterizes the interface call relationship. In specific implementations, the application control system can display compliant interface calls and non-compliant interface calls through different colors or different line types. For example, the boundary of an application can be displayed by a red dotted line. Accordingly, for interface calls that directly break through the boundary of an application without passing through an application gateway, the application control system can display the interface call to the user through a red line (for example, implemented in red). For interface calls that pass through an application gateway or interface calls within an application, the application control system can display the interface call to the user through a green line.

[0021] By displaying interface calls with security risks in the above target style, users can quickly locate security risks and make targeted corrections, thereby improving the efficiency of application security governance or flow control governance and enhancing governance effectiveness.

[0022] In some possible implementations, the application control system can also send warnings to users when calling interfaces that pose security risks. These warnings can be text messages, voice messages, flashing indicators, or vibrating buzzers. This method, by proactively issuing warnings for interface calls that pose security risks, can prompt developers to promptly rectify these calls, ensuring the security and reliability of applications.

[0023] In a second aspect, the present application provides an application control system. The system includes:

[0024] A record acquisition module is used to acquire interface call records of multiple microservices in an application, wherein the interface call records include calls by the microservices to interfaces provided within the application and / or calls by the microservices to interfaces provided outside the application;

[0025] A call relationship drawing module, configured to draw an interface call relationship diagram of the application in a running state based on the interface call records of the multiple microservices;

[0026] a boundary drawing module, configured to draw a boundary of the application in the interface call relationship graph based on the microservice registration information of the application, wherein the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center;

[0027] The call relationship display module is used to display the interface calls with security risks to the user when there are interface calls that break through the boundaries of the application in the interface call records. The interface calls with security risks include interface calls that break through the boundaries of the application.

[0028] In some possible implementations, the application further includes an application gateway, and the record acquisition module is further configured to:

[0029] Obtaining an interface call record of the application gateway, wherein the interface call record of the application gateway includes an interface call of the microservice within the application by the application gateway;

[0030] The call relationship drawing module is specifically used for:

[0031] Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices and the interface call records of the application gateway;

[0032] The boundary drawing module is specifically used for:

[0033] Based on the microservice registration information of the application and the registration information of the application gateway, a boundary of the application in the running state is drawn in the interface call relationship diagram, where the boundary of the application surrounds the microservices registered by the application in the registration center and the application gateway;

[0034] The call relationship display module is specifically used to:

[0035] The user is presented with interface calls that break through the boundaries of the application and do not pass through the application gateway.

[0036] In some possible implementations, the system further includes:

[0037] A static analysis module, configured to obtain static analysis results of the source code of the application, wherein the static analysis results include static call relationships of microservices of the application;

[0038] A call relationship analysis module is used to analyze the interface call relationship graph of the application in the running state and the static call relationship, and obtain interface calls that exist in the interface call relationship graph of the running state but do not exist in the static call relationship;

[0039] The interface calls with security risks include interface calls that exist in the interface call relationship graph in the running state and do not exist in the static call relationship.

[0040] In some possible implementations, the call relationship drawing module is further configured to:

[0041] Draw a static interface call relationship diagram of the application based on the static call relationship of the microservices of the application;

[0042] The call relationship analysis module is specifically used for:

[0043] An interface call relationship graph of the application in a running state and an interface call relationship graph of the application in a static state are analyzed.

[0044] In some possible implementations, the calling relationship drawing module specifically:

[0045] According to the static calling relationship of the microservices of the application, a static interface calling relationship diagram of the application is drawn in the interface calling relationship diagram of the application in the running state.

[0046] In some possible implementations, the call relationship display module is further configured to:

[0047] The calling information of the interface call is displayed to the user, where the calling information includes at least one of a calling source, a calling method, a calling path or a calling parameter.

[0048] In some possible implementations, the call relationship display module is specifically used to:

[0049] Interface calls that pose security risks are displayed to users in a target style, where the target style is different from a display style of compliant interface calls.

[0050] In some possible implementations, the system further includes:

[0051] The alarm module is used to send an alarm message to the user when the interface with security risks is called.

[0052] In a third aspect, the present application provides a computing device cluster. The computing device cluster includes at least one computing device, each of which includes at least one processor and at least one memory. The at least one processor and the at least one memory communicate with each other. The at least one processor is configured to execute instructions stored in the at least one memory, causing the computing device or computing device cluster to perform the interface management method described in the first aspect or any implementation of the first aspect.

[0053] In a fourth aspect, the present application provides a computer-readable storage medium storing instructions, wherein the instructions instruct a computing device or a computing device cluster to execute the interface management method described in the first aspect or any implementation of the first aspect.

[0054] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computing device or a computing device cluster, enables the computing device or computing device cluster to execute the interface management method described in the first aspect or any one of the implementations of the first aspect.

[0055] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In order to more clearly illustrate the technical methods of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments.

[0057] FIG1 is a schematic diagram illustrating an interface call relationship in a solution provided by this application;

[0058] FIG2 is a schematic diagram of the architecture of an application control system provided by the present application;

[0059] FIG3 is a schematic diagram showing call information of an interface call provided by the present application;

[0060] FIG4 is a flow chart of an interface management method provided by the present application;

[0061] FIG5 is a schematic diagram of call information of an interface call of each microservice in a drawing application provided by the present application;

[0062] FIG6 is an interface call relationship diagram of a drawing application in a running state provided by the present application;

[0063] FIG7 is a flow chart of an interface management method provided by the present application;

[0064] FIG8 is a schematic diagram provided by the present application showing an interface call with security risks;

[0065] FIG9 is a schematic diagram of an application scenario of an interface management method provided by this application;

[0066] FIG10 is a schematic diagram showing call information of an interface call provided by the present application;

[0067] FIG11 is a schematic diagram of the structure of a computing device provided by the present application;

[0068] FIG12 is a schematic diagram of the structure of a computing device cluster provided by this application;

[0069] FIG13 is a schematic diagram of the structure of another computing device cluster provided by the present application;

[0070] FIG14 is a schematic diagram of the structure of another computing device cluster provided in this application. DETAILED DESCRIPTION

[0071] The terms "first" and "second" in the embodiments of this application are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of technical features indicated. Therefore, features specified as "first" or "second" may explicitly or implicitly include one or more of the features.

[0072] First, some technical terms involved in the embodiments of this application are introduced.

[0073] An application programming interface (API) is a computing interface that defines the interactions between multiple computer programs, including the types of calls or requests that can be made, how to make them, the data formats that should be used, and the conventions that should be followed. An API can also provide extension mechanisms so that users can extend functionality to varying degrees in various ways. An API can be completely customized for a specific component, or it can be designed based on industry standards to ensure interoperability.

[0074] APIs allow application developers to call a set of routine functions without having to consider the underlying source code or understand the details of its internal workings. Consequently, more and more developers are choosing to develop applications based on APIs. Based on the permissions developers grant to the API, APIs can be categorized as internal APIs or open APIs. Internal APIs provide interface calls within the application, while open APIs provide interface calls externally.

[0075] API calls can be made by sending a request to the API server address, such as a Hypertext Transfer Protocol Secure (HTTPS) GET or POST request, and adding the corresponding request parameters in the request according to the API instructions. The API server can also return the processing results based on the request processing status.

[0076] An application gateway, such as an API Gateway (APIG), is an API management and service governance tool that integrates configuration publishing, environment management, access authentication, user authorization, and access control. Using an API gateway to host APIs allows for efficient, secure, and cost-effective service management. As a single entry point for requests, the API gateway dispatches them to the appropriate service, collects the results, and delivers them to the requester.

[0077] API Gateway can implement access control and traffic control for open APIs at the application level. However, API Gateway primarily manages open APIs and does not manage the calling relationships between microservices within an application. It is only responsible for interface calls passing through the API Gateway and cannot identify and manage APIs that are not exposed through the API Gateway. Therefore, faced with the significant challenges that application-level API call traffic poses to application security and traffic control, API Gateway struggles to identify interface calls that pose security risks, making it difficult to ensure application security or effectively control traffic within the application.

[0078] In view of this, the present application provides an interface management method. The method can be executed by an application control system. The application control system, also known as the application control center, is a tool that identifies risks of interface calls and assists in security management and traffic management. Specifically, the application control system can be a software system, which can be an independent software system or integrated into other software in the form of a plug-in. The software system can be deployed in a computing device cluster, and the computing device cluster executes the program code of the software system, thereby executing the interface management method of the present application. In some examples, the application control system can also be a hardware system, such as a computing device cluster with interface management functions. When the computing device cluster is running, the interface management method of the present application is executed.

[0079] Specifically, the application control system can obtain the interface call records of multiple microservices in the application, and the interface call records include the interface calls provided by the microservices to the internal application and / or the interface calls provided by the microservices to the external application. The application control system can draw an interface call relationship diagram of the application in the running state based on the interface call records of multiple microservices. Then, the application control system can draw the boundary of the application in the interface call relationship diagram based on the microservice registration information of the application. Among them, the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center. When there are interface calls that break through the boundaries of the application in the interface call records, the application control system displays the interface calls with security risks to the user. Interface calls with security risks include interface calls that break through the boundaries of the application.

[0080] This method uses the interface call records of multiple microservices to draw an interface call relationship diagram of the application in operation, and draws the application boundary in combination with the application's microservice registration information, thereby identifying interface calls that break through the application boundary, realizing application security risk monitoring, ensuring the security of the application, and effectively controlling the application's flow, providing a basis for API security governance and flow control governance.

[0081] In order to make the technical solution of the present application clearer and easier to understand, the application control system of the present application is introduced below with reference to the accompanying drawings.

[0082] A solution often includes multiple applications, each of which can be deployed in a multi-node model. Consequently, a large number of nodes, for example, tens of thousands of nodes, can be deployed in a single network. As shown in Figure 1, multiple applications within a solution can be deployed in a virtual private cloud (VPC) using a multi-node deployment model. The application control system primarily maps or depicts application-level API call relationships, including API calls within an application and between applications (also known as cross-application API calls), as well as application boundaries. Based on the application's runtime API call relationships and application boundaries, the application control system can identify API calls that pose security risks, ensuring that APIs are not abused. Furthermore, the application control system can send alerts for API calls that pose security risks and provide alert reasons (such as non-compliant API calls), providing a foundation for API security and traffic management. Furthermore, based on these API call relationships, access control can be implemented between microservices within an application and between applications.

[0083] For ease of description, the architecture of the application control system is explained below by drawing an interface call relationship diagram and boundary drawing for one of the applications.

[0084] FIG2 shows an architecture diagram of an application control system. Application control system 200 is used to map the interface call relationships and boundaries of an application, such as service A, during operation, and thereby identify interface calls that breach application boundaries and pose security risks. Application control system 200 includes a record acquisition module 202, a call relationship mapping module 204, a boundary mapping module 206, and a call relationship display module 208.

[0085] The record acquisition module 202 is used to obtain interface call records for multiple microservices in the application. The interface call records include calls by a microservice to an interface provided internally by the application and / or calls by the microservice to an interface provided externally by the application. An application's microservices can record a log of the APIs that call the microservices, which is also referred to as an API call log. The API call log includes calls by a microservice to an internally provided API and / or calls by a microservice to an externally provided API. A microservice can report an API call log to the application control system 200. Accordingly, the record acquisition module 202 can obtain the API call logs reported by multiple microservices in the application, thereby obtaining interface call records for the multiple microservices. Furthermore, when the application also includes an application gateway, the record acquisition module 202 can also obtain the API call logs reported by the application gateway, thereby obtaining the interface call records for the application gateway. As illustrated in FIG2 , multiple microservices of service A, such as microservices A to microservice F, and the application gateway of service A each report an API call log to the application control system 200.

[0086] The call relationship drawing module 204 is used to draw an interface call relationship diagram for the application in the running state based on the interface call records of multiple microservices. When the application includes an application gateway, the call relationship drawing module 204 can draw an interface call relationship diagram for the application in the running state based on the interface call records of multiple microservices and the interface call records of the application gateway. Before drawing the interface call relationship diagram, the interface call records can be aggregated, and then the aggregated interface call records, for example, all interface call records, can be analyzed to obtain relational call records. Accordingly, the call relationship drawing module 204 can draw an interface call relationship diagram for the application in the running state based on the relational call records.

[0087] The boundary drawing module 206 is used to draw the application boundary in the interface call relationship diagram based on the application's microservice registration information. The registration information indicates the microservices registered by the application with the registration center, and the application boundary encompasses the microservices registered with the registration center. If the application includes an application gateway, the boundary drawing module 206 also draws the application boundary based on the application gateway's registration information. In this case, the application boundary also includes the application gateway. Using service A as an example, the boundary of service A may encompass microservice A to microservice A, as well as service A's application gateway.

[0088] The call relationship display module 208 is used to display the interface calls with security risks to the user when there are interface calls that break through the boundaries of the application in the interface call records. Among them, the interface calls with security risks include interface calls that break through the boundaries of the application. Among them, when the application includes an application gateway, the interface calls with security risks can be calls that break through the application boundaries without passing through the application gateway. Taking Figure 2 as an example, service B (service B) directly calls microservice C of service A without passing through the application gateway of service A, service C (service C) directly calls microservice E of service A without passing through the application gateway of service A, and service D (service D) directly calls microservice B of service A without passing through the application gateway of service A. The call relationship display module 208 can display to the user the above-mentioned interface calls that directly break through the boundaries of service A without passing through the application gateway of service A.

[0089] The call relationship display module 208 can display interface calls that pose security risks to the user using a target style. The target style can be different from the display style of compliant interface calls. In some examples, compliant interface calls, such as interface calls within an application, can be displayed with green lines, while interface calls that pose security risks can be displayed with red lines.

[0090] Furthermore, the call relationship display module 208 can also display the call information of the interface call. The call information may include at least one of the call source, call method, call path or call parameters. The call source refers to the service or microservice that calls the interface provided by the microservice. The call method may include but is not limited to POST or GET. The call path (path) can be represented by a Uniform Resource Locator (URL). The call parameters can be interface parameters. As shown in Figure 3, the call relationship display module 208 can display the call relationship between multiple microservices in the application, the boundaries of the application, external calls without passing through the gateway, external calls passing through the gateway, and the call information of each interface call. The call information displayed by the call relationship display module 208 can refer to the code configuration of Figure 3, including the call path (denoted as path), the call method (denoted as method), the interface name (denoted as name), the request type (denoted as type) and the URL.

[0091] In some possible implementations, the application control system 200 may also include an alert module 209. This module is used to send alerts to users regarding API calls that pose security risks. This allows users to manage APIs in a timely manner based on these alerts, thereby providing a foundation for API security and traffic control management.

[0092] Based on the aforementioned application control system 200, the present application provides an interface management method. The interface management method of the present application is described below with reference to the accompanying drawings.

[0093] Referring to the flowchart of an interface management method shown in FIG4 , the method includes the following steps:

[0094] S402: The application control system 200 obtains interface call records of multiple microservices in the application.

[0095] Interface call records include calls from a microservice to an interface provided within the application and / or calls from a microservice to an interface provided externally to the application. Specifically, a microservice in an application can record call logs for APIs provided by the microservice. These call logs can serve as the interface call records for the microservice. Multiple microservices in an application can report their respective call logs to the application control system 200. In this way, the application control system 200 can obtain interface call records for multiple microservices in the application.

[0096] In some possible implementations, the application may further include an application gateway. The application gateway may also be called by other applications, such as other services or microservices in other services, to call microservices within the application. Similar to the microservices in the application, the application gateway may record the call log of the API provided by the application gateway, and the call log may serve as the interface call record of the application gateway. The application gateway may report the interface call record of the application gateway to the application control system 200. Accordingly, the application control system 200 may not only obtain the interface call records of multiple microservices in the application, but may also include the interface call record of the application gateway.

[0097] S404: The application control system 200 draws an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices.

[0098] Specifically, the application control system 200 aggregates the interface call records of multiple microservices. When the application includes an application gateway, the application control system 200 can aggregate the interface call records of the multiple microservices and the interface call records of the application gateway. The application control system 200 can analyze the aggregated interface call records to obtain relational call records. The relational call records can be interface call records organized by relational data. Relational data can be data represented by a relational model. The application control system 200 can then draw an interface call relationship diagram for the application in its running state based on the relational call records.

[0099] When drawing an interface call relationship diagram, as shown in FIG5 , application control system 200 can draw the call information of the interface calls of each microservice in the application based on the relational call records. For example, by drawing the call information of the interface calls of each microservice of service A in FIG2 , application control system 200 can draw the call information of the interface calls of microservices A through F.

[0100] The call information of each microservice interface call is as follows:

[0101] Service:service name

[0102] Request: {

[0103] Type: http|grpc|tcp

[0104] url:

[0105] path:

[0106] method:

[0107] port:

[0108] }

[0109] Among them, path can indicate the calling path, method can indicate the calling method, service name can be the service name of the calling source, used to indicate the calling source, port can indicate the port number, and port can be a parameter in the calling parameters.

[0110] The application control system 200 can draw an interface call relationship diagram of the application in the running state based on the call information of the interface call of each microservice. In specific implementation, the application control system 200 can draw an interface call relationship diagram of the application in the running state based on the call information of the interface call drawn for each microservice, as shown in Figure 6.

[0111] S406 . The application control system 200 draws the application boundary in the interface call relationship diagram according to the microservice registration information of the application.

[0112] The registration information indicates the microservices registered by the application in the registration center. In specific implementation, the registration information may include the identifier of the microservice registered by the application in the registration center, such as the microservice name. The boundary of the application surrounds the microservices registered by the application in the registration center. Furthermore, when the application includes an application gateway, the application control system 200 can also obtain the registration information of the application gateway in the registration center. The registration information may include the identifier of the application gateway, such as the name of the application gateway, or the Internet Protocol (IP) address. The application control system 200 can draw the boundary of the application in the interface call relationship diagram based on the microservice registration information and the application gateway registration information, and the boundary surrounds the microservices and application gateway registered by the application.

[0113] S408: When there are interface calls that break through the application boundary in the interface call record, the application control system 200 displays the interface calls with security risks to the user.

[0114] Specifically, the application control system 200 can identify whether there are interface calls that break through the boundaries of the application in the interface call record based on the interface call relationship diagram and the boundaries of the application. For example, the application control system 200 can identify the call source in the call information of the microservice. When the call source is a service or microservice outside the boundary of the application, specifically a service or microservice outside the microservice registered by the application, it means that the interface call breaks through the boundary of the application, and there are interface calls that break through the boundary of the application in the interface call record, and the application has security risks. Accordingly, the application control system 200 can display interface calls with security risks to the user. Among them, interface calls with security risks include interface calls that break through the boundaries of the application.

[0115] In some possible implementations, the application control system 200 can display interface calls that pose security risks to the user through a target style. The target style is different from the display style of compliant interface calls. Compliant interface calls may include interface calls within the application, or interface calls to microservices within the application through the application gateway. Interface calls that pose security risks include interface calls to microservices from outside the application, such as interface calls to microservices within the application that do not pass through the application gateway. In specific implementations, the display styles of the target style and compliant interface calls can be different colors, or different line types, or lines of different thicknesses. For example, the target style can be a red connecting line, and the display style of the compliant interface call can be a green connecting line.

[0116] The application control system 200 can also display call information of interface calls to the user. This call information includes at least one of the call source, call method, call path, or call parameters. The application control system 200 can display call information for interface calls that pose security risks, or it can display call information for all interface calls of the application. For example, the application control system 200 can display call information for all interface calls in the interface call relationship diagram.

[0117] Based on the above description, this application provides an interface management method. This method uses the interface call records of multiple microservices to draw an interface call relationship diagram of the application in the running state, and draws the application boundary in combination with the application's microservice registration information. It then identifies interface calls that break the application boundary, implements application security risk monitoring, ensures application security, and effectively controls the application's flow, providing a foundation for API security governance and flow control governance.

[0118] The embodiment of Figure 4 mainly identifies interface calls that pose security risks from a compliance perspective. In some possible implementations, the application control system 200 can also combine static analysis technology to identify interface calls that pose security risks, such as interface calls that exist in the running state but are not defined in the source code.

[0119] Referring to the flowchart of an interface management method shown in FIG7 , the method includes the following steps:

[0120] S702 : The application control system 200 obtains a static analysis result of the source code of the application.

[0121] Static analysis, also known as program static analysis, refers to a code analysis technology that scans program code (such as source code) through lexical analysis, syntax analysis, control flow, data flow analysis and other technologies without running the code to verify whether the code meets indicators such as standardization, security, reliability, and maintainability.

[0122] In a specific implementation, the application control system 200 may obtain the application's source code and then perform static analysis on the source code to obtain static analysis results. The static analysis results may include static call relationships between the application's microservices. These static call relationships may be the call relationships between microservices obtained through static analysis of the source code, specifically the call relationships between microservices defined in the application's source code. Furthermore, when the application includes an application gateway, the static call relationships may also include call relationships between the application gateway and microservices.

[0123] S704: The application control system 200 analyzes the interface call relationship graph and the static call relationship of the application in the running state, and obtains interface calls that exist in the interface call relationship graph in the running state but do not exist in the static call relationship.

[0124] Specifically, the application control system 200 can draw an interface call relationship diagram of the application in a static state based on the static call relationship of the microservices of the application. Among them, the application control system 200 can draw the interface call relationship diagram of the application in a static state in a similar manner to that of drawing the interface call relationship diagram in the running state. For example, the application control system 200 can draw the interface call relationship of each microservice based on the call information of the static call relationship, and then draw the interface call relationship diagram of the application in a static state based on the interface call relationship of each microservice. Accordingly, the application control system 200 can analyze the interface call relationship diagram of the application in the running state and the interface call relationship diagram of the application in the static state to obtain interface calls that exist in the interface call relationship diagram in the running state and do not exist in the static call relationship.

[0125] In some possible implementations, the application control system 200 can draw a static interface call relationship graph for the application within the application's runtime interface call relationship graph based on the static call relationships of the application's microservices. This facilitates the application control system 200 to compare the runtime interface call relationship graph with the static interface call relationship graph, identifying interface calls that exist in the runtime interface call relationship graph but not in the static interface call relationship graph.

[0126] Accordingly, the interface calls with security risks may include interface calls that exist in the interface call relationship graph in the running state but do not exist in the static call relationship.

[0127] If necessary, the embodiment shown in FIG7 can be combined with the embodiment of FIG4 . For example, the application control system 200 can further execute S702 and S704 on the basis of the embodiment shown in FIG4 . Accordingly, when the application control system 200 executes S608 to display interface calls with security risks, it can not only display interface calls that break through the boundaries of the application, but also display interface calls that exist in the interface call relationship diagram of the running state but do not exist in the static call relationship. As shown in FIG8 , still taking service A as an example, service A includes microservice F calling microservice C in the interface call relationship diagram of the running state. This interface call does not exist in the static call relationship of service A. The application control system 200 can display this interface call through a target style, such as a red connecting line or a bold connecting line.

[0128] In some possible implementations, the application control system 200 may also send a warning message to the user in response to an interface call that poses a security risk. The application control system 200 may send a warning message to the user in different ways. For example, the warning message may be a different type of signal. In some examples, the application control system 200 may send a warning message to the user in the form of a pop-up window in response to an interface call that poses a security risk. In other examples, the application control system 200 may also send a warning message to the user by vibrating or flashing a prompt light.

[0129] Next, the interface management method of this application is introduced in conjunction with a specific application scenario.

[0130] 9 shows an application scenario diagram of an interface management method. This method can be applied to a microservice hosting platform, which includes an application control center. The application control center is used as an important capability carrier for application-level API governance and implements the functions of the aforementioned application control platform 200. For example, the application control center is used to map, alert, and display all API call relationships, application boundaries, and illegal call relationships of the application. The method specifically includes the following steps:

[0131] Step 1: Each microservice hosted by the microservice hosting platform records the call log of the API that calls the microservice.

[0132] The call log may include calls made by the microservice to internal APIs and calls made by the microservice to external APIs (open APIs). As shown in FIG9 , the application's microservices may include Sermant. Sermant (also known as Java-mesh) is an agentless service mesh based on Java bytecode enhancement technology. It utilizes Java bytecode enhancement technology to provide service governance capabilities for host applications to address service governance issues in large-scale microservice architectures. In this embodiment, Sermant can record call logs for APIs that call microservices, and Sermant can report the call logs of the microservice APIs to the application control center. The call logs can be records of interface calls to the microservices.

[0133] In some possible implementations, the application also includes an application gateway. The application gateway can also record call logs for invoking the application gateway and report these logs to the application control center. This allows the application control center to obtain both the microservice interface call logs and the application gateway interface call logs.

[0134] Step 2: The application control center aggregates the interface call records of each microservice and application gateway.

[0135] Specifically, the application control center can aggregate the interface call records of each microservice and application gateway through clustering, thereby obtaining all interface call records of the application in the running state.

[0136] Step 3: The application control center analyzes all interface call records to form relational call records.

[0137] Specifically, the application control center may perform relationship analysis based on the interface call records, thereby forming relational call records.

[0138] Step 4: The application control center obtains the application's microservice registration information and the application gateway's registration information from the registration center.

[0139] The microservice registration information may include the identifier of the microservice registered by the application in the registration center, such as the microservice name. The application gateway registration information may include the identifier of the application gateway registered by the application in the registration center, such as the name or IP address of the application gateway.

[0140] It should be noted that step 4 can be executed in parallel with step 1, step 2, and step 3, or executed sequentially in a set order, and the embodiment of the present application does not limit this.

[0141] Step 5: The application control center draws an interface call relationship diagram of the application in the running state based on the relational call records.

[0142] The interface call relationship diagram includes call information for all of the application's interface calls. Based on the relational call records, the application control center can plot the interface call information for each microservice in the application. Then, based on the interface call information for each microservice, it can draw an interface call relationship diagram for the application in runtime.

[0143] Step 6: The application control center combines the application's microservice registration information to draw the application's boundaries in the interface call relationship diagram and displays interface calls that pose security risks.

[0144] Microservice registration information includes the identifier of the registered microservice. The application control center can use this identifier to draw a boundary around the microservices registered with the application in the interface call relationship diagram. The application control center can use a target style, such as red connecting lines, to highlight interface calls that pose security risks, such as those that violate the application's boundaries.

[0145] Furthermore, the application control center can also diagnose the security of the application boundary. For example, if the application's running state interface call records contain interface calls that break through the application boundary, it means that there is a security risk in the application boundary.

[0146] Step 7: The application control center issues an alert for interface calls that pose security risks.

[0147] The Application Control Center can identify unsafe application-level traffic, such as interface calls that pose security risks, and display them in a visual format, reminding developers to rectify unreasonable (such as non-compliant) interface calls to assist in security and traffic management. For example, the Application Control Center can identify interface calls that break through the boundaries of the application without passing through the application gateway. The interface calls that break through the boundaries identified by the Application Control Center can be used to monitor whether there are uncontrollable elephant flows, whether there are frequent calls that can trigger denial of service rat flows, and whether there are externally exposed interfaces without access control. This can provide assistance for application security and traffic management.

[0148] In some possible implementations, the application control center can also perform static analysis on the application's source code to obtain static interface call relationships. Based on the static interface call relationships, the application control center can draw a static interface call relationship graph. Accordingly, the application control center can compare the runtime interface call relationship graph (actual call relationships) with the static interface call relationship graph (call relationships defined in the source code) to identify interface calls that pose security risks, such as unsafe interface calls.

[0149] As shown in Figure 10, when the application control center draws an interface call relationship diagram, such as a running interface call relationship diagram or a static interface call relationship diagram, it can not only draw the interface calls between microservices, but also draw the call information of the interface calls. The call information can be as follows:

[0150] This method achieves auxiliary security governance and traffic management by drawing the relationship between all import and export API calls of the application and displaying the specific call information, drawing the boundaries of the application, and displaying the interface calls with security risks in the interface call relationship diagram, and issuing alarms for interface calls with security risks.

[0151] Based on the aforementioned interface management method, the present application also provides an application control system. As shown in FIG2 , the application control system 200 includes:

[0152] A record acquisition module 202 is configured to acquire interface call records of multiple microservices in an application, wherein the interface call records include calls by the microservices to interfaces provided within the application and / or calls by the microservices to interfaces provided externally to the application;

[0153] A call relationship drawing module 204 is configured to draw an interface call relationship diagram of the application in a running state based on the interface call records of the multiple microservices;

[0154] a boundary drawing module 206 for drawing a boundary of the application in the interface call relationship diagram based on the microservice registration information of the application, wherein the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center;

[0155] The call relationship display module 208 is used to display the interface calls with security risks to the user when there are interface calls that break through the boundaries of the application in the interface call records. The interface calls with security risks include interface calls that break through the boundaries of the application.

[0156] For example, the record acquisition module 202 , the call relationship drawing module 204 , the boundary drawing module 206 , and the call relationship display module 208 may be implemented by hardware or software.

[0157] When implemented via software, the record acquisition module 202, the call relationship drawing module 204, the boundary drawing module 206, and the call relationship display module 208 can be applications running on a computing device. Taking the call relationship drawing module 204 as an example, the application can be a computing engine. Applications can also be provided to users in the form of virtualization services. Virtualization services can include virtual machine (VM) services, bare metal server (BMS) services, and container services. VM services can be services that use virtualization technology to create a virtual machine (VM) resource pool on multiple physical hosts to provide VMs to users on demand. BMS services can be services that create a virtual BMS resource pool on multiple physical hosts to provide BMSs to users on demand. Container services can be services that create a virtual container resource pool on multiple physical hosts to provide containers to users on demand. A VM is a simulated virtual computer, that is, a logically single computer. BMS is a scalable, high-performance computing service with computing performance comparable to that of a traditional physical machine and featuring secure physical isolation. Containers are a kernel virtualization technology that provides lightweight virtualization to isolate user spaces, processes, and resources. It should be understood that the VM service, BMS service, and container service mentioned above are merely specific examples. In actual applications, virtualization services can also include other lightweight or heavyweight virtualization services, which are not specifically limited here.

[0158] When implemented through hardware, the record acquisition module 202, the call relationship drawing module 204, the boundary drawing module 206, and the call relationship display module 208 may include at least one computing device, such as a server. Alternatively, the record acquisition module 202, the call relationship drawing module 204, the boundary drawing module 206, and the call relationship display module 208 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0159] In some possible implementations, the application further includes an application gateway, and the record acquisition module 202 is further configured to:

[0160] Obtaining an interface call record of the application gateway, wherein the interface call record of the application gateway includes an interface call of the microservice within the application by the application gateway;

[0161] The call relationship drawing module 204 is specifically used for:

[0162] Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices and the interface call records of the application gateway;

[0163] The boundary drawing module 206 is specifically used for:

[0164] Based on the microservice registration information of the application and the registration information of the application gateway, a boundary of the application in the running state is drawn in the interface call relationship diagram, where the boundary of the application surrounds the microservices registered by the application in the registration center and the application gateway;

[0165] The call relationship display module 208 is specifically used to:

[0166] The user is presented with interface calls that break through the boundaries of the application and do not pass through the application gateway.

[0167] In some possible implementations, the application control system 200 further includes:

[0168] A static analysis module, configured to obtain static analysis results of the source code of the application, wherein the static analysis results include static call relationships of microservices of the application;

[0169] A call relationship analysis module is used to analyze the interface call relationship graph of the application in the running state and the static call relationship, and obtain interface calls that exist in the interface call relationship graph of the running state but do not exist in the static call relationship;

[0170] The interface calls with security risks include interface calls that exist in the interface call relationship graph in the running state and do not exist in the static call relationship.

[0171] The static analysis module and the call relationship analysis module are not shown in Figure 2. Similar to the aforementioned record acquisition module 202, call relationship drawing module 204, boundary drawing module 206, and call relationship display module 208, the static analysis module and the call relationship analysis module can be implemented by software or hardware.

[0172] In some possible implementations, the call relationship drawing module 204 is further configured to:

[0173] Draw a static interface call relationship diagram of the application based on the static call relationship of the microservices of the application;

[0174] The call relationship analysis module is specifically used to:

[0175] An interface call relationship graph of the application in a running state and an interface call relationship graph of the application in a static state are analyzed.

[0176] In some possible implementations, the calling relationship drawing module 204 specifically:

[0177] According to the static calling relationship of the microservices of the application, a static interface calling relationship diagram of the application is drawn in the interface calling relationship diagram of the application in the running state.

[0178] In some possible implementations, the call relationship display module 208 is further configured to:

[0179] The calling information of the interface call is displayed to the user, where the calling information includes at least one of a calling source, a calling method, a calling path or a calling parameter.

[0180] In some possible implementations, the call relationship display module 208 is specifically configured to:

[0181] Interface calls that pose security risks are displayed to users in a target style, where the target style is different from a display style of compliant interface calls.

[0182] In some possible implementations, the application control system 200 further includes:

[0183] The warning module 209 is used to send warning information to the user when the interface with security risks is called.

[0184] This application also provides a computing device 1100. As shown in Figure 11, computing device 1100 includes a bus 1102, a processor 1104, a memory 1106, and a communication interface 1108. Processor 1104, memory 1106, and communication interface 1108 communicate with each other via bus 1102. Computing device 1100 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in computing device 1100.

[0185] Bus 1102 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG11 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 1102 may include a path for transmitting information between various components of computing device 1100 (e.g., memory 1106, processor 1104, and communication interface 1108).

[0186] The processor 1104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0187] The memory 1106 may include a volatile memory, such as a random access memory (RAM). The memory 1106 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD). The memory 1106 stores executable program code, and the processor 1104 executes the executable program code to implement the aforementioned interface management method. Specifically, the memory 1106 stores instructions for the application control system 200 to execute the interface management method.

[0188] The communication interface 1108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1100 and other devices or a communication network.

[0189] Embodiments of the present application also provide a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0190] As shown in Figure 12, the computing device cluster includes at least one computing device 1100. The memory 1106 of one or more computing devices 1100 in the computing device cluster may store the same application control system 200 instructions for executing the interface management method.

[0191] In some possible implementations, one or more computing devices 1100 in the computing device cluster may also be used to execute some of the instructions for executing the interface management method by the application control system 200. In other words, the combination of one or more computing devices 1100 may jointly execute the instructions for executing the interface management method by the application control system 200.

[0192] It should be noted that the memories 1106 in different computing devices 1100 in the computing device cluster may store different instructions for executing partial functions of the application control system 200 .

[0193] FIG13 shows a possible implementation. As shown in FIG13 , two computing devices 1100A and 1100B are connected via a communication interface 1108. The memory in the computing device 1100A stores instructions for executing the functions of the record acquisition module 202 and the call relationship display module 208. The memory in the computing device 1100B stores instructions for executing the functions of the call relationship drawing module 204 and the boundary drawing module 206. In other words, the memories 1106 of the computing devices 1100A and 1100B jointly store instructions for the application control system 200 to execute the interface management method. Furthermore, the memory in the computing device 1100A stores instructions for executing the functions of the alarm module 209, and the memory in the computing device 1100B stores instructions for executing the functions of the static analysis module and the call relationship analysis module.

[0194] The connection method between the computing device clusters shown in Figure 13 may be considered to be based on the fact that the interface management method provided in this application requires a lot of computing power to perform call relationship drawing and boundary drawing. Therefore, it is considered to transfer the functions implemented by the call relationship drawing module 204 and the boundary drawing module 206 to the computing device 1100B.

[0195] It should be understood that the functionality of the computing device 1100A shown in FIG13 may also be implemented by multiple computing devices 1100. Similarly, the functionality of the computing device 1100B may also be implemented by multiple computing devices 1100.

[0196] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network or a local area network, etc. FIG14 shows a possible implementation. As shown in FIG14 , two computing devices 1100C and 1100D are connected via a network. Specifically, the connection to the network is made through a communication interface in each computing device. In this type of possible implementation, the memory 1106 in the computing device 1100C stores instructions for executing the functions of the record acquisition module 202 and the call relationship display module 208. At the same time, the memory 1106 in the computing device 1100D stores instructions for executing the functions of the call relationship drawing module 204 and the boundary drawing module 206.

[0197] The connection method between the computing device clusters shown in Figure 14 can be considered to be that the interface management method provided by this application requires a lot of computing power to perform call relationship drawing and boundary drawing, so it is considered to hand over the functions implemented by the call relationship drawing module 204 and the boundary drawing module 206 to the computing device 1100D for execution.

[0198] It should be understood that the functionality of the computing device 1100C shown in FIG14 may also be accomplished by multiple computing devices 1100. Similarly, the functionality of the computing device 1100D may also be accomplished by multiple computing devices 1100.

[0199] The present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the above-mentioned application control system 200 for executing the interface management method.

[0200] Embodiments of the present application also provide a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored on any available medium. When the computer program product is run on at least one computing device, the at least one computing device executes the interface management method described above.

[0201] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present invention.

Claims

1. An interface management method, characterized in that: The method comprises: Obtaining interface call records of multiple microservices in an application, wherein the interface call records include calls by the microservice to an interface provided inside the application and / or calls by the microservice to an interface provided outside the application; Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices; According to the microservice registration information of the application, drawing the boundary of the application in the interface call relationship diagram, wherein the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center; When there are interface calls that break through the boundary of the application in the interface call record, interface calls with security risks are displayed to the user, and the interface calls with security risks include interface calls that break through the boundary of the application.

2. The method according to claim 1, characterized in that The application further includes an application gateway, and the method further includes: Obtaining an interface call record of the application gateway, wherein the interface call record of the application gateway includes an interface call of the application gateway calling a microservice within the application; Drawing an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices includes: Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices and the interface call records of the application gateway; Drawing the boundary of the application in the interface call relationship diagram according to the microservice registration information of the application includes: According to the microservice registration information of the application and the registration information of the application gateway, a boundary of the application in the running state is drawn in the interface call relationship diagram, where the boundary of the application surrounds the microservice registered by the application in the registration center and the application gateway; The step of displaying the interface calls that have security risks to the user includes: Interface calls that break through the boundaries of the application and do not pass through the application gateway are displayed to the user.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: Obtaining a static analysis result of the source code of the application, wherein the static analysis result includes a static call relationship of microservices of the application; Analyze the interface call relationship graph of the application in the running state and the static call relationship to obtain interface calls that exist in the interface call relationship graph of the running state and do not exist in the static call relationship; The interface calls with security risks include interface calls that exist in the interface call relationship graph in the running state and do not exist in the static call relationship.

4. The method according to claim 3, characterized in that The method further comprises: Draw a static interface call relationship diagram of the application according to the static call relationship of the microservices of the application; The analyzing the interface call relationship graph and the static call relationship of the application in the running state includes: An interface call relationship graph of the application in a running state and an interface call relationship graph of the application in a static state are analyzed.

5. The method according to claim 4, characterized in that Drawing a static interface call relationship diagram of the application according to the static call relationship of the microservices of the application includes: According to the static calling relationship of the microservices of the application, a static interface calling relationship graph of the application is drawn in the interface calling relationship graph of the application in the running state.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The calling information of the interface call is displayed to the user, wherein the calling information includes at least one of a calling source, a calling method, a calling path or a calling parameter.

7. The method according to any one of claims 1 to 6, characterized in that: The step of displaying the interface calls that have security risks to the user includes: Interface calls with security risks are displayed to users through a target style, where the target style is different from a display style of compliant interface calls.

8. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: For the interface call with security risks, a warning message is sent to the user.

9. An application control system, characterized in that: The system comprises: A record acquisition module, used to acquire interface call records of multiple microservices in an application, wherein the interface call records include calls by the microservice to an interface provided inside the application and / or calls by the microservice to an interface provided outside the application; A call relationship drawing module, used to draw an interface call relationship diagram of the application in a running state according to the interface call records of the multiple microservices; A boundary drawing module, used to draw the boundary of the application in the interface call relationship diagram according to the microservice registration information of the application, wherein the registration information indicates the microservices registered by the application in the registration center, and the boundary of the application surrounds the microservices registered by the application in the registration center; The call relationship display module is used to display the interface calls with security risks to the user when there are interface calls that break through the boundaries of the application in the interface call records, and the interface calls with security risks include interface calls that break through the boundaries of the application.

10. The system according to claim 9, characterized in that The application further includes an application gateway, and the record acquisition module is further used for: Obtaining an interface call record of the application gateway, wherein the interface call record of the application gateway includes an interface call of the application gateway calling a microservice within the application; The calling relationship drawing module is specifically used for: Draw an interface call relationship diagram of the application in the running state according to the interface call records of the multiple microservices and the interface call records of the application gateway; The boundary drawing module is specifically used for: According to the microservice registration information of the application and the registration information of the application gateway, a boundary of the application in the running state is drawn in the interface call relationship diagram, where the boundary of the application surrounds the microservice registered by the application in the registration center and the application gateway; The calling relationship display module is specifically used for: Interface calls that break through the boundaries of the application and do not pass through the application gateway are displayed to the user.

11. The system according to claim 9 or 10, characterized in that: The system further comprises: A static analysis module, used to obtain a static analysis result of the source code of the application, wherein the static analysis result includes a static call relationship of microservices of the application; A call relationship analysis module, used to analyze the interface call relationship graph of the application in the running state and the static call relationship, and obtain interface calls that exist in the interface call relationship graph of the running state and do not exist in the static call relationship; The interface calls with security risks include interface calls that exist in the interface call relationship graph in the running state and do not exist in the static call relationship.

12. The system according to claim 11, characterized in that The call relationship drawing module is also used for: Draw a static interface call relationship diagram of the application according to the static call relationship of the microservices of the application; The call relationship analysis module is specifically used for: An interface call relationship graph of the application in a running state and an interface call relationship graph of the application in a static state are analyzed.

13. The system according to claim 12, characterized in that The calling relationship drawing module specifically: According to the static calling relationship of the microservices of the application, a static interface calling relationship graph of the application is drawn in the interface calling relationship graph of the application in the running state.

14. The system according to any one of claims 9 to 13, characterized in that The call relationship display module is also used for: The calling information of the interface call is displayed to the user, wherein the calling information includes at least one of a calling source, a calling method, a calling path or a calling parameter.

15. The system according to any one of claims 9 to 14, characterized in that The calling relationship display module is specifically used for: Interface calls with security risks are displayed to users through a target style, where the target style is different from a display style of compliant interface calls.

16. The system according to any one of claims 9 to 15, characterized in that The system further comprises: The alarm module is used to send alarm information to the user when the interface with security risks is called.

17. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, and the at least one computing device includes at least one processor and at least one memory, wherein the at least one memory stores computer-readable instructions; the at least one processor executes the computer-readable instructions so that the computing device cluster executes the interface management method as described in any one of claims 1 to 8.

18. A computer-readable storage medium, characterized in that: Comprising computer-readable instructions; the computer-readable instructions are used to implement the interface management method according to any one of claims 1 to 8.

19. A computer program product, characterized in that Comprising computer-readable instructions; the computer-readable instructions are used to implement the interface management method according to any one of claims 1 to 8.

Images