Service interface full life cycle management method and system based on micro-service architecture

Abstract

The invention discloses a service interface full-life-cycle management method and system based on a micro-service architecture, relates to the technical field of distributed system monitoring and management, and mainly aims to solve the problem of low service interface management efficiency of an existing micro-service management system. The method mainly comprises the steps of receiving a registration request reported by a newly added micro-service through a registration center; performing interface document auditing on the newly-added micro-service based on the interface document reported by the newly-added micro-service, performing release permission approval based on the release list of the newly-added micro-service, and releasing the newly-added micro-service under the condition that both the interface document auditing and the release permission approval are passed; under the condition that the application relationship is successfully bound for the newly-added micro-service which is published, publishing an interface of the newly-added micro-service, and performing security configuration on the interface of the newly-added micro-service; and according to the called data or the modification request, determining to-be-managed assets, and executing target operation of matching the to-be-managed assets to the to-be-managed assets. The method is mainly used for managing micro-service interfaces.

Description

Technical Field

[0001] This invention relates to the field of distributed system monitoring and management technology, and in particular to a method and system for managing the entire lifecycle of service interfaces based on a microservice architecture. Background Technology

[0002] As enterprises deepen their digital transformation, microservice architecture has become the mainstream model for modern application system construction due to its advantages such as flexibility, scalability, and technological heterogeneity. In this architecture, applications are broken down into multiple independently deployed, loosely coupled microservices, which communicate and collaborate through clearly defined interfaces. This distributed nature, while improving development efficiency and system resilience, also places higher demands on service governance and management, making the full lifecycle management of service interfaces a crucial link in ensuring stable system operation and data security.

[0003] However, in existing management practices, the control of service interfaces still faces significant challenges, with numerous steps in the management process relying heavily on manual operations. For example, from reviewing and uploading interface documentation and approving publishing permissions, to configuring the binding relationship between services and applications after service deployment, and even handling the removal of invalid or outdated interfaces, manual intervention and judgment are often required. This highly manual approach is not only inefficient and slow to respond, but also prone to problems such as missing online service documentation, chaotic permissions, overlooked security configurations, or "zombie" services continuously consuming resources due to operational negligence or inconsistent standards. Consequently, the effectiveness and timeliness of microservice monitoring fail to meet the management needs of microservices. Summary of the Invention

[0004] In view of this, the present invention provides a method and system for full lifecycle management of service interfaces based on microservice architecture, the main purpose of which is to solve the problem of low efficiency in existing microservice interface management.

[0005] According to one aspect of the present invention, a method for managing the entire lifecycle of service interfaces based on a microservice architecture is provided, comprising: The system receives registration requests from newly added microservices through the registry center and updates the service list based on the service and interface information of the newly added microservices. Based on the interface documentation reported by the newly added microservice, the interface documentation of the newly added microservice is reviewed, and the release permission is approved based on the release order of the newly added microservice. If both the interface documentation review and the release permission approval are passed, the newly added microservice is released so that the newly added microservice can be called. If the newly added microservice has been successfully bound to the application relationship, the interface of the newly added microservice is published and the interface of the newly added microservice is configured for security. Monitor the invoked data and modification requests of each microservice in the service list, determine the assets to be managed based on the invoked data or modification requests, and perform target operations matching the assets to be managed, wherein the target operations include new additions and automatic offline removal.

[0006] Furthermore, the step of reviewing the interface documentation of the newly added microservice based on the interface documentation reported by the newly added microservice includes: The document collection component collects the interface association data of the newly added microservices and generates interface documents based on the interface association data. Call the document reporting interface and pass the interface document to the input parameters of the document reporting interface to request the interface document review from the developer community. The data items for the interface document review include interface path, interface name, interface person in charge, interface description, request parameter description, response parameter description and response example.

[0007] Furthermore, the approval of release permissions based on the release order of the newly added microservice includes: The approval platform receives release orders entered by users through the interactive interface and submits the release orders to the approval node for release permission approval. The release orders include interface-related content and interface call permission-related content. The input controls of the interactive interface are configured with standardized drop-down selection, format validation and naming rule prompts. The process of publishing the new microservice after both the interface documentation review and the publishing permission approval is passed includes: In response to the approval instruction from the approval node, the newly added microservice is published, and permissions are added to the service interface according to the access permission association content.

[0008] Furthermore, the application relationship includes associated departments, associated application objects, and associated application groups. The step of publishing the interface for the newly added microservice, after successfully binding the application relationship to the newly added microservice for publication, includes: Assign associated departments, associated application objects, and associated application groups to the newly added microservices, and publish the interface of the newly added microservices if the binding is successful; The security configuration of the interface of the newly added microservice includes: The encryption type of the newly added microservice is retrieved, and the interface security settings of the newly added microservice are configured according to the encryption type. The encryption type includes no encryption, encrypted external network input parameters, encrypted external network return values, and encrypted external network input parameters and return values. Retrieve the completed approval request form for the newly added microservice, and check whether the interface call permission identifier in the request form exists in the intranet key table and the extranet key table. If it exists, authorize the interface access of the newly added microservice based on the interface call permission identifier.

[0009] Furthermore, the process of determining the assets to be managed based on the invoked data includes: Based on the called data, calculate the empty duration of each interface and each interface call permission identifier under each microservice, and regard the interface and / or interface call permission identifier whose empty duration is greater than the corresponding preset empty duration threshold as assets to be managed. The step of performing a target operation on the asset to be managed, matching the asset to be managed, includes: If the asset to be managed is an interface, call the cancellation interface, using the interface's attribute information as input parameters, to cancel the interface; When the asset to be managed is an interface call permission identifier, a key table to be deregistered is determined based on the type parameter of the interface call permission identifier. The key table to be deregistered is then processed sequentially as follows: deleting the interface call permission identifier group, deleting the interface authorization information of the interface call permission identifier, and deleting the interface call permission identifier. The key table to be deregistered includes an intranet key table or an extranet key table.

[0010] Furthermore, the process of determining the assets to be managed based on the aforementioned modification request includes: The modification request is directed to designate the microservice containing the object to be modified as an asset to be managed. The step of performing a target operation on the asset to be managed, matching the asset to be managed, includes: If the modification request indicates that the interface path should be modified, the microservice containing the interface will be treated as a new microservice. Starting from the step of receiving the registration request reported by the new microservice through the registry center, the operation of the full lifecycle management of the service interface will be re-executed. If the modification request indicates that only the server where the microservice resides should be modified, the microservice will be adaptively identified and its interface will be treated as a new interface asset. When the modification request indicates any of the operations of rate limiting, encryption, and degradation, the corresponding rate limiting operation, encryption operation, or degradation operation is performed on the asset to be managed through the gateway, wherein the gateway is configured with a load balancer and supports horizontally scalable authorization servers and Redis clusters.

[0011] Furthermore, after configuring the security of the interface of the newly added microservice, the method further includes: Collect and store the log data of the newly added microservices; Establish the association relationships between the newly added microservice and each interface under the microservice, and their corresponding business organization and operation and maintenance execution objects; When the display terminal of the business organization or the operation and maintenance execution object makes a request to display log data, the log data of the global microservice that is related to the business organization or the operation and maintenance execution object is retrieved and displayed.

[0012] According to another aspect of the present invention, a service interface lifecycle management system based on a microservice architecture is provided, the system including a monitoring center and a registration center; The registration center is used to receive registration requests reported by newly added microservices and update the service list based on the service information and interface information of the newly added microservices. The monitoring center is used to review the interface documentation of the newly added microservice based on the interface documentation reported by the newly added microservice, and to approve the release permission based on the release order of the newly added microservice. If both the interface documentation review and the release permission approval are passed, the newly added microservice is released so that it can be called. If the newly added microservice has successfully bound an application relationship, the interface of the newly added microservice is released and the interface of the newly added microservice is configured with security. The center also monitors the called data and modification requests of each microservice in the service list, determines the assets to be managed based on the called data or modification requests, and performs target operations matching the assets to be managed. The target operations include new addition detection and automatic offline.

[0013] Furthermore, the system also includes a document collection component and a document reporting interface; The document collection component is used to collect the interface association data of the newly added microservice and generate interface documents based on the interface association data. The document reporting interface is used to receive a call instruction with the interface document as input parameter and request the interface document review from the developer community. The data items for the interface document review include the interface path, interface name, interface manager, interface description, request parameter description, response parameter description, and response example.

[0014] Furthermore, the monitoring center is also used to receive the release order entered by the user through the interactive interface through the approval platform, and submit the release order to the approval node for release permission approval. The release order includes interface-related content and interface call permission-related content. The input controls of the interactive interface are configured with standardized drop-down selection, format validation and naming rule prompts. The process of publishing the new microservice after both the interface documentation review and the publishing permission approval is passed includes: In response to the approval instruction from the approval node, the newly added microservice is published, and permissions are added to the service interface according to the access permission association content.

[0015] Furthermore, the application relationships include associated departments, associated application objects, and associated application groups. The monitoring center is also used to bind associated departments, associated application objects, and associated application groups to the newly added microservices, and, upon successful binding, publish the interface of the newly added microservices; retrieve the encryption type of the newly added microservices, and configure the interface security settings of the newly added microservices according to the encryption type, wherein the encryption type includes no encryption, encrypted external network input parameters, encrypted external network return values, and encrypted external network input parameters and return values. Retrieve the completed approval request form for the newly added microservice, and check whether the interface call permission identifier in the request form exists in the intranet key table and the extranet key table. If it exists, authorize the interface access of the newly added microservice based on the interface call permission identifier.

[0016] Furthermore, the monitoring center is also used to calculate the empty duration of each interface and each interface call permission identifier under each microservice based on the called data, and to regard the interfaces and / or interface call permission identifiers with empty durations greater than the corresponding preset empty duration thresholds as assets to be managed. The step of performing a target operation on the asset to be managed, matching the asset to be managed, includes: If the asset to be managed is an interface, call the cancellation interface, using the interface's attribute information as input parameters, to cancel the interface; When the asset to be managed is an interface call permission identifier, a key table to be deregistered is determined based on the type parameter of the interface call permission identifier. The key table to be deregistered is then processed sequentially as follows: deleting the interface call permission identifier group, deleting the interface authorization information of the interface call permission identifier, and deleting the interface call permission identifier. The key table to be deregistered includes an intranet key table or an extranet key table.

[0017] Furthermore, the system also includes a gateway configured with a load balancer that supports horizontally scalable authorization servers and Redis clusters; The monitoring center is also used to treat the microservice where the modification request indicates the object to be modified as an asset to be managed; when the modification request indicates modification of the interface path, the microservice where the interface is located is treated as a new microservice, and the service interface full lifecycle management operation is re-executed starting from the step of receiving the registration request reported by the new microservice through the registry center; when the modification request indicates modification only of the server where the microservice is located, the microservice is adaptively perceived, and the interface of the microservice is treated as a new interface asset. The gateway is configured to perform the corresponding rate limiting, encryption, or degradation operation on the asset to be managed when the modification request indicates any one of the operations of rate limiting, encryption, and degradation.

[0018] Furthermore, the monitoring center is also used to collect and store log data of the newly added microservices; Establish the association relationships between the newly added microservice and each interface under the microservice, and their corresponding business organization and operation and maintenance execution objects; When the display terminal of the business organization or the operation and maintenance execution object makes a request to display log data, the log data of the global microservice that is related to the business organization or the operation and maintenance execution object is retrieved and displayed.

[0019] By employing the above-described technical solutions, the technical solutions provided by the embodiments of the present invention have at least the following advantages: This invention provides a method and system for managing the entire lifecycle of service interfaces based on a microservice architecture. In this embodiment, the system receives registration requests from newly added microservices through a registry center and updates the service list based on the service and interface information of the newly added microservices. It reviews the interface documentation of the newly added microservices based on the submitted documentation and approves release permissions based on the release order. If both the interface documentation review and the release permission approval are passed, the newly added microservice is released to enable it to be invoked. Finally, if the newly released microservice is successfully bound to an application relationship, it is released... The system adds interfaces to microservices and configures them for security. It monitors the invoked data and modification requests of each microservice in the service list, identifies assets to be managed based on the invoked data or modification requests, and performs target operations on these assets. These target operations include new service awareness and automatic decommissioning. This significantly reduces the workload and error probability of manual management of microservice interfaces, lowering the risk of system failures due to poor interface management. Simultaneously, it ensures standardized and efficient management of all aspects of the service interface's lifecycle, thereby greatly improving the efficiency of microservice interface management.

[0020] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the specification. Furthermore, in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0021] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This invention provides a flowchart of a service interface lifecycle management method based on a microservice architecture. Figure 2 This diagram illustrates a network architecture of a system provided by an embodiment of the present invention. Figure 3 This diagram illustrates the operational relationship of a monitoring center within a system, as provided in an embodiment of the present invention. Figure 4 This diagram illustrates the operational relationship of a registration center within a system, as provided in an embodiment of the present invention. Figure 5 The flowchart illustrates a method for automatically decommissioning microservices according to an embodiment of the present invention. Figure 6 This diagram illustrates a method for sensing new additions according to an embodiment of the present invention. Figure 7 This paper illustrates a block diagram of a service interface lifecycle management system based on a microservice architecture, provided by an embodiment of the present invention. Detailed Implementation

[0022] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0023] To address the issue of low efficiency in existing microservice interface management, this invention provides a method for managing the entire lifecycle of service interfaces based on a microservice architecture. This method is applied to a system for managing the entire lifecycle of service interfaces based on a microservice architecture, including a registry center, monitoring center, and gateway. This method uses the monitoring center as the execution entity to perform the following steps. Figure 1 As shown, the method includes: 101. Receive the registration request reported by the newly added microservice through the registration center, and update the service list according to the service information and interface information of the newly added microservice.

[0024] In this embodiment of the invention, when a newly added microservice instance starts after automatic deployment, it proactively sends a registration request to the registry center. This request includes the service's basic metadata (such as service name, version number, and instance address) and the definition information of all its provided interfaces. Upon receiving this information, the registry center persists it and dynamically updates its internally maintained global service list, enabling service consumers to retrieve the service list from the service registry center, thereby completing service discovery and registration. At this point, the lifecycle of the microservice interface officially begins. Automatic deployment can be implemented based on a pipeline, that is, by pre-associating the GitLab code repository with CI / CD pipeline tools, the pipeline calls the service source code in the code repository and performs automatic testing and deployment. This step achieves automatic registration and centralized directory management of microservices, laying a solid foundation for service discovery. Simultaneously, the system can perceive all available service instances and their capabilities in real time, providing accurate and up-to-date service metadata for subsequent service calls and governance.

[0025] 102. Based on the interface documentation reported by the newly added microservice, review the interface documentation of the newly added microservice and approve the release permission based on the release order of the newly added microservice. If both the interface documentation review and the release permission approval are passed, release the newly added microservice so that the newly added microservice can be called.

[0026] In this embodiment of the invention, when a new microservice starts, it also proactively reports its interface documentation to the system. Upon receiving the interface documentation from the new microservice, the system reviews it. For example, it checks whether the interface's input and output parameters conform to specifications and whether the interface's functional description is clear. This review can follow pre-set internal review rules or be conducted by calling external resources, such as publishing the interface documentation as a review task in a developer community (a user platform integrating interface information and interface demo testing), allowing developers in the developer community to review it. This embodiment of the invention does not impose specific limitations. Simultaneously, based on the release order submitted by the new microservice, relevant approval personnel approve the release permissions. Only when both the interface documentation review and release permission approval are passed will the new microservice be marked as publishable, allowing it to be called by other services. Through interface documentation review and release order approval, the interface quality and release compliance of the new microservice are ensured, preventing non-compliant or security-risk microservices from accessing the system, thus improving the overall system stability and security. Of course, if either the interface documentation review or the release order approval fails, the applicant is returned for modification and must resubmit for review or approval after modification.

[0027] 103. If the newly added microservice has been successfully bound to the application relationship, publish the interface of the newly added microservice and perform security configuration on the interface of the newly added microservice.

[0028] In this embodiment of the invention, after a new microservice is published, it needs to be bound to related application objects (such as departments, personnel, and their respective application groups) to establish application relationships. For example, after successfully binding the application relationships, the system will publish the interface of the newly added microservice, making it visible to the outside world. Simultaneously, the interface is configured with security according to a preset security policy, such as setting call permissions, encryption methods, and authentication. Through security configuration, it is ensured that the microservice interface provides services externally in a secure environment, preventing unauthorized access and data leakage, ensuring system security, and enabling legitimate applications to call the interface normally.

[0029] 104. Monitor the invoked data and modification requests of each microservice in the service list, determine the assets to be managed based on the invoked data or modification requests, and perform the target operation matching the assets to be managed on the assets to be managed.

[0030] In this embodiment of the invention, the target operations include detecting new additions and automatically taking them offline. The system continuously monitors the invoked data (such as the number of calls, call time, call source, etc.) and modification requests of each microservice in the service list. Based on the invoked data, the system analyzes the usage of the microservices; based on the modification requests, it understands the change requirements of the microservices. Based on this information, it identifies the assets to be managed, i.e., assets that require operations such as detecting new additions, automatically taking them offline, rate limiting, encryption, and degradation. These assets can be microservices, microservice interfaces, interface call permission identifiers, etc. Then, according to preset rules, the corresponding target operations are executed, such as performing a new addition detection operation when a new microservice is detected, and performing an automatic offline operation when a microservice is no longer used or malfunctions. Through the above operations, dynamic management of microservice assets is achieved, timely detection of changes in microservices in the system is achieved, automatic asset updates and maintenance are performed, the system's automation management level is improved, manual intervention is reduced, and management costs are lowered.

[0031] In one application example, the above method can be applied to, for example... Figure 2The system network architecture shown is based on a microservice architecture, implementing full lifecycle management of service interfaces, and is divided into multiple layers. The API gateway layer is responsible for security verification, access control, service forwarding, and protocol conversion, and caches result sets; the microservice layer includes pipelined deployment services, a business aggregation layer, and multiple atomic layers, each of which can cache result sets, register and discover services through a service registry, and implement asynchronous service calls and processing with the help of a message center; the data caching layer uses a distributed cache to store database replicas, and the database access layer accesses the data layer (big data, data warehouse) through DAL database sharding and table partitioning, supporting read and write operations; in addition, the work order platform interacts with the system through service access control, and the monitoring center and log platform are responsible for system monitoring and logging.

[0032] In this system, the monitoring center (service monitoring center) serves as a core operations and maintenance component in the distributed architecture, such as... Figure 3 The diagram illustrating the operational relationship of the monitoring center within the system demonstrates its role in providing comprehensive, real-time observation and management of the microservice architecture's operational status, performance metrics, and anomalies. By integrating multi-dimensional monitoring capabilities, this monitoring center effectively addresses microservice governance challenges such as complex service chains, dynamic node expansion, and difficulties in fault location, providing data support for system stability, observability, and continuous optimization. The monitoring center's externally accessible data can include the following categories: First, it monitors the registry center to obtain information on all registered services and service changes as a source of application, service node, and API data; second, it collects gateway call logs, using periodic statistical collection and real-time data querying to obtain service call information as a data source for gateway monitoring and service call monitoring reports; third, it retains information on reported circuit breakers and their recovery from reported circuit breakers, generating circuit breaker log reports. Furthermore, the monitoring center also features functions such as publishing or calling permission control, automatic reporting or decommissioning of instances, encryption, rate limiting, and degradation.

[0033] A gateway is an application responsible for authentication, permission checks, security control, protocol conversion, and request forwarding. A gateway can include resource services and authorization services, enabling authentication of callers, load balancing of service calls, caching, static responses, service integration, and OAuth 2.0-based authorization. The gateway uses Nginx as a load balancer, communicates with external clients via HTTPS, and the resource and authorization services it reverse proxies are both HTTP.

[0034] A service registry, which can be implemented based on a ZooKeeper cluster, is used to maintain a list of currently available services and maintain long-lived connections with all service producers and consumers. For example... Figure 4The diagram illustrates the operational relationship of the service registry within the system. When a service producer starts up, it registers the services it provides with the service registry. When a service consumer starts up, it retrieves the service list from the service registry. If the service list changes, the service registry will proactively notify all service consumers to update the list.

[0035] In one embodiment of the present invention, for further explanation and limitation, the step of reviewing the interface documentation of the newly added microservice based on the interface documentation reported by the newly added microservice includes: The document collection component collects the interface association data of the newly added microservices and generates interface documents based on the interface association data. Call the document reporting interface and pass the interface document to the input parameters of the document reporting interface to request the interface document review from the developer community.

[0036] In this embodiment of the invention, the document collection component plays a crucial role by comprehensively collecting relevant information about newly added microservices, covering various associated data of the interfaces, such as the basic attributes and functional characteristics of the interfaces. Subsequently, based on this collected interface-related data, a complete interface document is generated according to a predetermined format and specification, ensuring that the document contains detailed information about the interface. Then, the system calls a pre-defined document reporting interface, passing the generated interface document as a parameter to the input parameter location of the interface. In this way, an interface document review request is initiated to the developer community. Upon receiving the request, the developer community conducts a detailed review of each data item in the interface document according to the prescribed review standards. These data items specifically include whether the interface path is accurate and reasonable, whether the interface name is clear and easy to understand, whether the interface owner is clearly identified, whether the interface description is complete and accurate, whether the request parameter description is detailed and standardized, whether the response parameter description is comprehensive, and whether the response example is consistent with reality. In other words, the data items for interface document review include the interface path, interface name, interface owner, interface description, request parameter description, response parameter description, and response example.

[0037] The documentation collection component can be integrated into the CI / CD process, working in conjunction with common CI / CD tools such as Jenkins and GitLab CI / CD. Upon microservice startup, this component automatically triggers the collection and processing of API documentation. For example, when code is committed to a version control system and a build task is triggered, the component extracts API information from the build artifacts and submits the API documentation to the designated review platform according to a defined process. The documentation submission API can be ` / ldsfdc / apidoc / addApiDoc`. By calling the API ` / ldsfdc / apidoc / addApiDoc` and passing in the input parameter (API documentation), the documentation can be automatically uploaded to the developer community, and this feature is compatible with all types of Java programs.

[0038] In one embodiment of the present invention, for further explanation and limitation, the approval of release permissions based on the release order of the newly added microservice includes: The approval platform receives publishing orders entered by users through the interactive interface and submits the publishing orders to the approval node for publishing permission approval. The process of publishing the new microservice after both the interface documentation review and the publishing permission approval is passed includes: In response to the approval instruction from the approval node, the newly added microservice is published, and permissions are added to the service interface according to the access permission association content.

[0039] In this embodiment of the invention, the release form includes interface-related content and interface call permission-related content. The input controls of the interactive interface are configured with standardized drop-down selection, format validation, and naming rule prompts. When a user needs to submit a microservice application form, they enter the release form through the interactive interface provided by the approval platform, following the interface prompts. The interactive interface is designed with input controls, which are equipped with at least three of the following auxiliary functions: standardized drop-down selection, format validation, and naming rule prompts. For example, for input boxes containing key information, when the user clicks, the drop-down selection box provides standardized options for the user to choose from, avoiding the user from entering non-standard content; the format validation function checks whether the format of the input content meets the requirements in real time after the user finishes inputting it, and if it does not meet the requirements, it promptly prompts the user and forces modification (the form cannot be submitted without modification); the naming rule prompt displays pre-set naming rules when the user enters relevant names, helping the user to name correctly. After the user completes the release form entry, they click the submit button, and the approval platform submits the received release form to the pre-set approval node, initiating the release permission approval process. The release form contains interface-related content and interface call permission-related content, which are important bases for approval. It should be noted that, in addition to the application form, the approval platform also provides a cancellation form input, which is used to take microservice interfaces or keys offline.

[0040] The staff at the approval node conducts a detailed review of the release request. Once approved, the approval node sends an approval command to the system. The system responds to this command, executing the release operation for the new microservice, making the microservice available for use. Simultaneously, the system adds appropriate permissions to the service interface based on the API access permission associations specified in the release request. For example, it determines which users or applications have permission to call the interface based on the permission associations, and sets corresponding access control policies to ensure that only authorized users or applications can successfully call the interface.

[0041] It should be noted that the standardized drop-down selection, format validation, and naming rule prompts in the input controls of the interactive interface can effectively standardize user input behavior, reduce input errors, and improve the accuracy and efficiency of data entry.

[0042] In one embodiment of the present invention, for further explanation and limitation, when a newly added microservice is successfully bound to an application relationship for completion of publication, publishing the interface of the newly added microservice includes: Assign associated departments, associated application objects, and associated application groups to the newly added microservices, and publish the interface of the newly added microservices if the binding is successful; The security configuration of the interface of the newly added microservice includes: Retrieve the encryption type of the newly added microservice, and configure the interface security settings of the newly added microservice according to the encryption type; Retrieve the completed approval request form for the newly added microservice, and check whether the interface call permission identifier in the request form exists in the intranet key table and the extranet key table. If it exists, authorize the interface access of the newly added microservice based on the interface call permission identifier.

[0043] In this embodiment of the invention, after a new microservice is published, it is bound to an associated department, an associated application object, and an associated application group. If the application group or associated department does not exist, an exception is thrown. If the applicant's employee ID does not exist, a person and user are created using the applicant's name, employee ID, and organization number, and the person creation information is returned. The relationship binding continues. The system verifies and processes the binding operation. When the binding is successful, the association between the new microservice and the application object is completed. At this time, the system automatically triggers an interface publishing operation to publish the interface of the new microservice to the outside world, enabling it to be called by relevant objects in the bound application relationship.

[0044] The system retrieves the encryption type of the newly added microservice from the application form. Encryption types include no encryption, encrypted external network input, encrypted external network return value, and encrypted external network input and return values. The system then configures the corresponding security settings for the interface of the newly added microservice. For example, if the encryption type is encrypted external network input, the system will encrypt the input parameters of the request when the interface receives an external network request, ensuring data security during transmission.

[0045] The system retrieves the approved API call permission application form for the newly added microservice and then checks whether the API call permission identifier in the application form exists in the internal and external key tables. Specifically, it calls the ` / platform / monitor / checkClient` interface to query both the internal and external key tables to check if the key already exists. Next, it calls the ` / platform / monitor / clientAuth` interface to authorize access to the provided key and associated interface. The internal and external key tables are pre-set tables used to store valid permission identifiers; the key is the permission identifier required to call the interface. If the API call permission identifier exists in the corresponding key table, the system authorizes access to the newly added microservice based on that identifier, allowing objects with that permission identifier to access the interface; otherwise, it denies the access request.

[0046] In one embodiment of the present invention, for further illustration and limitation, such as Figure 5 As shown, the methods for automatically taking microservices offline include: 201. Calculate the empty duration of each interface and each interface call permission identifier under each microservice based on the called data, and designate the interfaces and / or interface call permission identifiers with empty durations greater than the corresponding preset empty duration thresholds as assets to be managed.

[0047] 202. If the asset to be managed is an interface, call the cancellation interface, using the interface's attribute information as input parameters, and cancel the interface.

[0048] 203. If the asset to be managed is an interface call permission identifier, determine the key table to be cancelled based on the type parameter of the interface call permission identifier, and sequentially delete the interface call permission identifier group, delete the interface authorization information of the interface call permission identifier, and delete the interface call permission identifier in the key table to be cancelled.

[0049] In this embodiment of the invention, the preferred application scenario for determining the asset to be managed based on the invoked data is automatic shutdown. When the target operation is automatic shutdown, the system first collects the invoked data of each interface and each interface call permission identifier under each microservice. This invoked data includes information such as the time record of when the interface or permission identifier was accessed. Based on the collected invoked data, the system calculates the empty duration of each interface and each interface call permission identifier under each microservice. The empty duration refers to the time interval from the most recent invocation to the present. The calculated empty duration is compared with the corresponding pre-set empty duration threshold. If the empty duration of a certain interface or interface call permission identifier is greater than its corresponding pre-set empty duration threshold, then the interface or interface call permission identifier is marked as an asset to be managed.

[0050] Further, the target operation is executed, specifically: When the asset to be managed is an interface, after confirming that the asset is an interface, the system calls a predefined cancellation interface (which can be ` / platform / monitor / cancelApiPublish`). Simultaneously, the interface's attribute information (such as interface name, interface path, etc.) is passed as parameters to the cancellation interface. Upon receiving the parameters, the cancellation interface performs the corresponding cancellation operation, deregistering the interface from the system so that it no longer provides services externally. When the asset to be managed is an interface call permission identifier: The system calls an interface to query the type parameter of the interface call permission identifier to distinguish whether it is an intranet or extranet-related permission identifier, thereby determining the key table to be cancelled (including the intranet key table or the extranet key table), i.e., determining whether it is an intranet key table or an extranet key table. The type parameter of the interface call permission identifier can be queried by calling ` / platform / monitor / cancelClient`. Then, perform the following operations in sequence: First, delete the interface call permission identifier group, which clears the group information related to the permission identifier; next, delete the interface authorization information of the interface call permission identifier, thereby revoking the authorization relationship between the permission identifier and the corresponding interface; finally, delete the interface call permission identifier itself, completely removing it from the key table.

[0051] It's important to note that determining the assets to be managed by calculating the idle time and comparing it with a threshold accurately identifies interfaces and interface call permission identifiers that have not been used for a long time. This helps to promptly identify idle resources in the system, preventing them from consuming system space and impacting system performance. For idle interfaces, calling the deregistration interface can release system resources in a timely manner, reducing unnecessary interface maintenance costs and making the system simpler and more efficient. For idle interface call permission identifiers, deleting them in a specific order can thoroughly clear related permission information, ensuring the accuracy and security of system permission management and preventing security risks such as unauthorized access that may arise from idle permission identifiers. This standardized cleanup process also facilitates system maintenance and management. Of course, automatic deregistration can also be performed in response to user-initiated deregistration requests, deregistering the corresponding microservice interfaces or keys, depending on specific application requirements.

[0052] In one embodiment of the present invention, for further explanation and limitation, the process of determining the asset to be managed based on the modification request includes: The modification request is directed to designate the microservice containing the object to be modified as an asset to be managed. The step of performing a target operation on the asset to be managed, matching the asset to be managed, includes: If the modification request indicates that the interface path should be modified, the microservice containing the interface will be treated as a new microservice. Starting from the step of receiving the registration request reported by the new microservice through the registry center, the operation of the full lifecycle management of the service interface will be re-executed. If the modification request indicates that only the server where the microservice resides should be modified, the microservice will be adaptively identified and its interface will be treated as a new interface asset. When the modification request indicates any of the operations of rate limiting, encryption, and degradation, the corresponding rate limiting operation, encryption operation, or degradation operation is performed on the asset to be managed through the gateway.

[0053] In this embodiment of the invention, when the system receives a modification request, it parses the request to identify the object to be modified. Based on the microservice where the object resides, that microservice is directly identified as an asset to be managed. For example... Figure 6 The illustrated process for detecting new additions involves treating the microservice containing the API as a newly added microservice if the modification request indicates a change to the API path. Then, starting from the step of receiving the registration request from the newly added microservice through the registry center, the entire lifecycle management process for the service interface is re-executed. This includes a series of operations such as updating the service list in the registry center, reviewing API documentation and approving release permissions, binding application relationships, releasing the API, and performing security configurations to ensure the microservice can run normally and securely after the API path is modified. When the modification request only indicates a change to the server where the microservice resides, the system activates an adaptive detection mechanism. This mechanism detects changes to the microservice and manages the microservice's API as a new API asset. This means the system automatically identifies the microservice's operation on the new server, updates relevant API information, and ensures the accuracy and timeliness of API asset management.

[0054] If the request is modified to perform any of the following operations: rate limiting, encryption, or degradation, the system will invoke the relevant gateway functions. Based on the request instructions, the gateway will perform the corresponding rate limiting operation (e.g., limiting interface access traffic), encryption operation (encrypting data transmitted through the interface), or degradation operation (reducing the service level of the interface when the system experiences anomalies or high load) on the asset to be managed, thereby achieving flexible management and control of microservices. The gateway is configured with a load balancer, supporting horizontally scalable authorization servers and Redis clusters. The overall gateway operation process includes: an external client initiates a request, which passes through a firewall to ensure its legitimacy. The request reaches the load balancer (Nginx with Kong plugin), which distributes the request to the appropriate service according to its configuration. For different interface requests: if the request is a REST API request, the load balancer forwards it to the REST API gateway. The REST API gateway checks the AccessToken in the request and verifies its validity. If the AccessToken is valid, the gateway forwards the request to the internal client for processing; if invalid, it returns the corresponding error message. The authorization process includes: if a request requires user authorization, the load balancer forwards the request to the OAuth2.0 authorization server (Vert.x). The authorization server processes the user authorization request, issues an AccessToken and a RefreshToken, and stores these tokens in the Redis cluster. The authorization server returns the AccessToken to the external client, which can then use this AccessToken to access protected APIs. Redis Cluster supports horizontal scaling, dynamically adding or removing nodes based on system load to ensure system performance and scalability.

[0055] It's important to note that when interface paths are modified, re-executing the full lifecycle management process ensures compliance and security after the changes, guaranteeing that microservices can be properly integrated into the system and managed under the new interface paths. When only the server hosting the microservice is modified, the system adaptively detects and updates interface assets, enabling it to adapt promptly to deployment changes and maintain accurate interface asset information for easier monitoring and management. By performing rate limiting, encryption, and degradation operations through the gateway, microservices can be dynamically adjusted according to actual needs, improving system stability, security, and performance to meet the requirements of different business scenarios.

[0056] In one embodiment of the present invention, for further explanation and limitation, after configuring the security of the interface of the newly added microservice, the method further includes: Collect and store the log data of the newly added microservices; Establish the association relationships between the newly added microservice and each interface under the microservice, and their corresponding business organization and operation and maintenance execution objects; When the display terminal of the business organization or the operation and maintenance execution object makes a request to display log data, the log data of the global microservice that is related to the business organization or the operation and maintenance execution object is retrieved and displayed.

[0057] In this embodiment of the invention, after completing the security configuration of the newly added microservice interface, the system initiates the log collection function. By deploying a log collection agent in the microservice runtime environment or utilizing the log output interface provided by the microservice itself, various log data generated during the operation of the newly added microservice are collected in real time, such as interface call logs, system runtime status logs, and error logs. The collected log data is transmitted to a dedicated log storage system, such as a log database or a distributed file storage system, for persistent storage, facilitating subsequent querying and analysis. By analyzing the log data, problems and potential risks in the system can be identified in a timely manner, allowing for corresponding measures to be taken to resolve and prevent them, thereby improving the stability and reliability of the system.

[0058] Based on preset business rules and management architecture, the system constructs the association relationships between newly added microservices and their various interfaces, and their corresponding business organizations and operation and maintenance (O&M) execution objects. For example, the system determines the corresponding business organization based on the business module to which the microservice belongs, and the O&M execution object is determined based on the personnel or team responsible for the microservice's O&M. These association relationships can be stored and managed in the form of database tables, clearly defining the correspondence between each microservice and interface and its business organization and O&M execution object. Constructing these association relationships between newly added microservices and their interfaces and their business organizations and O&M execution objects enables precise classification and management of log data. This allows for quick location of logs related to specific business organizations or O&M execution objects when log data needs to be viewed, improving the efficiency of data querying and analysis.

[0059] To enable the retrieval and display of log data, an ELK visual log platform was built, and log specifications were established. Log parsing configuration followed these specifications ensured concise, clear, and real-time updates of the visualized information. When a business organization or operations and maintenance (O&M) execution object's display terminal initiates a log data display request, the system first parses the information about the business organization or O&M execution object contained in the request. Then, based on previously established relationships, it retrieves log data related to that business organization or O&M execution object from the stored global microservice log data. Finally, the retrieved log data is organized, formatted, and displayed on the display terminal for easy viewing and analysis by users. The construction of the visual log platform has enabled standardized log display and convenient querying.

[0060] This invention provides a method for managing the entire lifecycle of service interfaces based on a microservice architecture. In this embodiment, the method receives registration requests from newly added microservices through a registry center and updates the service list based on the service and interface information of the newly added microservices. It reviews the interface documentation of the newly added microservices based on their submitted documentation and approves their release permissions based on their release order. If both the interface documentation review and the release permission approval are passed, the newly added microservice is released to enable it to be invoked. If the newly released microservice has successfully bound to an application relationship, its interface is released and its security configuration is performed. The method monitors the invoked data and modification requests of each microservice in the service list, identifies assets to be managed based on the invoked data or modification requests, and performs target operations matching the assets to be managed. These target operations include new service awareness and automatic decommissioning. This significantly reduces the workload and error probability of manual management of microservice interfaces, lowering the risk of system failures due to poor interface management. Simultaneously, it ensures standardized and efficient management of each stage of the service interface's lifecycle, thereby greatly improving the efficiency of microservice interface management.

[0061] Furthermore, as a response to the above Figure 1 The implementation of the method shown in this embodiment of the invention provides a service interface lifecycle management system based on a microservice architecture, such as... Figure 7 As shown, the system includes: a registration center 31 and a monitoring center 32; The registration center 31 is used to receive registration requests reported by newly added microservices and update the service list based on the service information and interface information of the newly added microservices. The monitoring center 32 is used to review the interface documentation of the newly added microservice based on the interface documentation reported by the newly added microservice, and to approve the release permission based on the release order of the newly added microservice. If both the interface documentation review and the release permission approval are passed, the newly added microservice is released so that the newly added microservice can be called. If the newly added microservice has successfully bound the application relationship, the interface of the newly added microservice is released and the interface of the newly added microservice is configured with security. The monitoring center 32 listens to the called data and modification requests of each microservice in the service list, determines the assets to be managed based on the called data or modification requests, and performs the target operation matching the assets to be managed. The target operation includes new detection and automatic offline.

[0062] Furthermore, the system also includes a document collection component 33 and a document reporting interface 34; The document collection component 33 is used to collect the interface association data of the newly added microservice and generate interface documents based on the interface association data. The document reporting interface 34 is used to receive a call instruction with the interface document as input parameter and request the interface document review from the developer community. The data items for the interface document review include interface path, interface name, interface person in charge, interface description, request parameter description, response parameter description, and response example.

[0063] Furthermore, the monitoring center 32 is also used to receive the release order entered by the user through the interactive interface through the approval platform, and submit the release order to the approval node for release permission approval. The release order includes interface-related content and interface call permission-related content. The input control of the interactive interface is configured with standardized drop-down selection, format validation and naming rule prompts. In response to the approval instruction from the approval node, the newly added microservice is published, and permissions are added to the service interface according to the access permission association content.

[0064] Furthermore, the application relationships include associated departments, associated application objects, and associated application groups. The monitoring center 32 is also used to bind associated departments, associated application objects, and associated application groups to the newly added microservice, and, upon successful binding, publish the interface of the newly added microservice; retrieve the encryption type of the newly added microservice, and configure the interface security settings of the newly added microservice according to the encryption type, wherein the encryption type includes no encryption, encrypted external network input parameters, encrypted external network return values, and encrypted external network input parameters and return values. Retrieve the completed approval request form for the newly added microservice, and check whether the interface call permission identifier in the request form exists in the intranet key table and the extranet key table. If it exists, authorize the interface access of the newly added microservice based on the interface call permission identifier.

[0065] Furthermore, the monitoring center 32 is also used to calculate the empty duration of each interface and each interface call permission identifier under each microservice based on the called data, and to regard the interface and / or interface call permission identifier with an empty duration greater than the corresponding preset empty duration threshold as assets to be managed. The step of performing a target operation on the asset to be managed, matching the asset to be managed, includes: If the asset to be managed is an interface, call the cancellation interface, using the interface's attribute information as input parameters, to cancel the interface; When the asset to be managed is an interface call permission identifier, a key table to be deregistered is determined based on the type parameter of the interface call permission identifier. The key table to be deregistered is then processed sequentially as follows: deleting the interface call permission identifier group, deleting the interface authorization information of the interface call permission identifier, and deleting the interface call permission identifier. The key table to be deregistered includes an intranet key table or an extranet key table.

[0066] Furthermore, the system also includes a gateway 35, which is configured with a load balancer and supports horizontally scalable authorization servers and Redis clusters; The monitoring center 32 is also used to treat the microservice where the modification request indicates the object to be modified as an asset to be managed; when the modification request indicates modification of the interface path, the microservice where the interface is located is treated as a new microservice, and the operation of full lifecycle management of the service interface is re-executed starting from the step of receiving the registration request reported by the new microservice through the registration center 31; when the modification request indicates modification only of the server where the microservice is located, the microservice is adaptively perceived, and the interface of the microservice is treated as a new interface asset. The gateway 35 is used to perform the corresponding rate limiting operation, encryption operation, or degradation operation on the asset to be managed when the modification request indicates any one of the operations of rate limiting, encryption, and degradation.

[0067] Furthermore, the monitoring center 32 is also used to collect and store log data of the newly added microservice; Establish the association relationships between the newly added microservice and each interface under the microservice, and their corresponding business organization and operation and maintenance execution objects; When the display terminal of the business organization or the operation and maintenance execution object makes a request to display log data, the log data of the global microservice that is related to the business organization or the operation and maintenance execution object is retrieved and displayed.

[0068] This invention provides a service interface lifecycle management system based on a microservice architecture. In this embodiment, the system receives registration requests from newly added microservices through a registry center and updates the service list based on the service and interface information of the newly added microservices. It reviews the interface documentation of the newly added microservices based on their submitted documentation and approves their release permissions based on their release orders. If both the interface documentation review and the release permission approval are passed, the newly added microservice is released to enable it to be invoked. If the newly released microservice has successfully bound to an application relationship, its interface is released and its security configuration is performed. The system monitors the invoked data and modification requests of each microservice in the service list, identifies assets to be managed based on the invoked data or modification requests, and performs target operations matching the assets to be managed. These target operations include new addition detection and automatic decommissioning. This significantly reduces the workload and error probability of manual management of microservice interfaces, lowering the risk of system failures due to poor interface management. Simultaneously, it ensures standardized and efficient management of all stages of the service interface lifecycle, thereby greatly improving the efficiency of microservice interface management.

[0069] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing systems. They can be centralized on a single computing system or distributed across a network of multiple computing systems. Optionally, they can be implemented using program code executable by a computing system, thereby storing them in a storage system for execution by the computing system. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0070] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for managing the entire lifecycle of service interfaces based on a microservice architecture, characterized in that, include: The system receives registration requests from newly added microservices through the registry center and updates the service list based on the service and interface information of the newly added microservices. Based on the interface documentation reported by the newly added microservice, the interface documentation of the newly added microservice is reviewed, and the release permission is approved based on the release order of the newly added microservice. If both the interface documentation review and the release permission approval are passed, the newly added microservice is released so that the newly added microservice can be called. If the newly added microservice has been successfully bound to the application relationship, the interface of the newly added microservice is published and the interface of the newly added microservice is configured for security. Monitor the invoked data and modification requests of each microservice in the service list, determine the assets to be managed based on the invoked data or modification requests, and perform target operations matching the assets to be managed, wherein the target operations include new additions and automatic offline removal.

2. The method according to claim 1, characterized in that, The step of reviewing the interface documentation of the newly added microservice based on the interface documentation reported by the newly added microservice includes: The document collection component collects the interface association data of the newly added microservices and generates interface documents based on the interface association data. Call the document reporting interface and pass the interface document to the input parameters of the document reporting interface to request the interface document review from the developer community. The data items for the interface document review include interface path, interface name, interface person in charge, interface description, request parameter description, response parameter description and response example.

3. The method according to claim 1, characterized in that, The approval of release permissions based on the release order of the newly added microservice includes: The approval platform receives release orders entered by users through the interactive interface and submits the release orders to the approval node for release permission approval. The release orders include interface-related content and interface call permission-related content. The input controls of the interactive interface are configured with standardized drop-down selection, format validation and naming rule prompts. The process of publishing the new microservice after both the interface documentation review and the publishing permission approval is passed includes: In response to the approval instruction from the approval node, the newly added microservice is published, and permissions are added to the service interface according to the access permission association content.

4. The method according to claim 1, characterized in that, The application relationships include associated departments, associated application objects, and associated application groups. The step of publishing the interface for the newly added microservice, after successfully binding the application relationships for the newly added microservice, includes: Assign associated departments, associated application objects, and associated application groups to the newly added microservices, and publish the interface of the newly added microservices if the binding is successful; The security configuration of the interface of the newly added microservice includes: The encryption type of the newly added microservice is retrieved, and the interface security settings of the newly added microservice are configured according to the encryption type. The encryption type includes no encryption, encrypted external network input parameters, encrypted external network return values, and encrypted external network input parameters and return values. Retrieve the completed approval request form for the newly added microservice, and check whether the interface call permission identifier in the request form exists in the intranet key table and the extranet key table. If it exists, authorize the interface access of the newly added microservice based on the interface call permission identifier.

5. The method according to claim 4, characterized in that, The process of determining the assets to be managed based on the retrieved data includes: Based on the called data, calculate the empty duration of each interface and each interface call permission identifier under each microservice, and regard the interface and / or interface call permission identifier whose empty duration is greater than the corresponding preset empty duration threshold as assets to be managed. The step of performing a target operation on the asset to be managed, matching the asset to be managed, includes: If the asset to be managed is an interface, call the cancellation interface, using the interface's attribute information as input parameters, to cancel the interface; When the asset to be managed is an interface call permission identifier, a key table to be deregistered is determined based on the type parameter of the interface call permission identifier. The key table to be deregistered is then processed sequentially as follows: deleting the interface call permission identifier group, deleting the interface authorization information of the interface call permission identifier, and deleting the interface call permission identifier. The key table to be deregistered includes an intranet key table or an extranet key table.

6. The method according to claim 1, characterized in that, The process of determining the assets to be managed based on the aforementioned modification request includes: The modification request is directed to designate the microservice containing the object to be modified as an asset to be managed. The step of performing a target operation on the asset to be managed, matching the asset to be managed, includes: If the modification request indicates that the interface path should be modified, the microservice containing the interface will be treated as a new microservice. Starting from the step of receiving the registration request reported by the new microservice through the registry center, the operation of the full lifecycle management of the service interface will be re-executed. If the modification request indicates that only the server where the microservice resides should be modified, the microservice will be adaptively identified and its interface will be treated as a new interface asset. When the modification request indicates any of the operations of rate limiting, encryption, and degradation, the corresponding rate limiting operation, encryption operation, or degradation operation is performed on the asset to be managed through the gateway, wherein the gateway is configured with a load balancer and supports horizontally scalable authorization servers and Redis clusters.

7. The method according to claim 1, characterized in that, After configuring the security of the interface of the newly added microservice, the method further includes: Collect and store the log data of the newly added microservices; Establish the association relationships between the newly added microservice and each interface under the microservice, and their corresponding business organization and operation and maintenance execution objects; When the display terminal of the business organization or the operation and maintenance execution object makes a request to display log data, the log data of the global microservice that is related to the business organization or the operation and maintenance execution object is retrieved and displayed.

8. A service interface lifecycle management system based on a microservice architecture, characterized in that, The system includes a monitoring center and a registration center; The registration center is used to receive registration requests reported by newly added microservices and update the service list based on the service information and interface information of the newly added microservices. The monitoring center is used to review the interface documentation of the newly added microservice based on the interface documentation reported by the newly added microservice, and to approve the release permission based on the release order of the newly added microservice. If both the interface documentation review and the release permission approval are passed, the newly added microservice is released so that the newly added microservice can be called. If the newly added microservice has been successfully bound to the application relationship, the interface of the newly added microservice is published and the interface of the newly added microservice is configured for security. Monitor the invoked data and modification requests of each microservice in the service list, determine the assets to be managed based on the invoked data or modification requests, and perform target operations matching the assets to be managed, wherein the target operations include new additions and automatic offline removal.

9. The system according to claim 8, characterized in that, The system also includes a document collection component and a document reporting interface; The document collection component is used to collect the interface association data of the newly added microservice and generate interface documents based on the interface association data. The document reporting interface is used to receive a call instruction with the interface document as input parameter and request the interface document review from the developer community. The data items for the interface document review include the interface path, interface name, interface manager, interface description, request parameter description, response parameter description, and response example.

10. The system according to claim 8, characterized in that, The system also includes a gateway, which is configured with a load balancer and supports horizontally scalable authorization servers and Redis clusters; The monitoring center is also used to designate the microservice containing the object to be modified by the modification request as an asset to be managed. If the modification request indicates that the interface path should be modified, the microservice containing the interface will be treated as a new microservice. Starting from the step of receiving the registration request reported by the new microservice through the registry center, the operation of the full lifecycle management of the service interface will be re-executed. If the modification request indicates that only the server where the microservice resides should be modified, the microservice will be adaptively identified and its interface will be treated as a new interface asset. The gateway is configured to perform the corresponding rate limiting, encryption, or degradation operation on the asset to be managed when the modification request indicates any one of the operations of rate limiting, encryption, and degradation.

Images