Micro-service management method and device, storage medium and product

Abstract

The invention provides a micro-service management method and device, a storage medium and a product, and the method comprises the steps: a first authentication and authorization module in a first cluster carries out the authentication and authorization of a second micro-service in a second cluster under the condition that a distributed key value database registers a second micro-service in a second cluster; obtaining a first resource request for the second micro-service from a first client; performing authentication based on first identity information carried in the first resource request; when the authentication is successful, sending the first resource request to a second authentication and authorization module associated with the second micro-service in the second cluster based on a first uniform resource locator carried in the first resource request, and the second authentication and authorization module sends the first resource request to the second micro-service after successful authentication.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a microservice management method, device, storage medium and product. Background Technology

[0002] With the development of computer technology and software development technology, microservice technology (or microservice architecture) has emerged, which advocates dividing a single application into a set of loosely coupled and independently deployable small services, in which each microservice has its own process and uses lightweight mechanisms to achieve communication.

[0003] Currently, enterprises typically containerize microservices and deploy them in container orchestration environments. As more and more applications are broken down into smaller microservices, the scale of microservices is getting larger and larger. In order to achieve high concurrency and high availability, multi-cluster solutions such as deploying microservices on clusters of multiple cloud vendors or multiple clusters of a single cloud vendor will emerge. However, there is still no effective solution for how to achieve cross-cluster communication of microservices. Summary of the Invention

[0004] This application provides a microservice management method, device, storage medium, and product that enables secure cross-cluster communication in a multi-cluster environment.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a microservice management method applied to a first authentication and authorization module in a first cluster. The first cluster further includes a first microservice and a distributed key-value database. The first authentication and authorization module is associated with the first microservice. The method includes: If a second microservice in a second cluster is registered in the distributed key-value database, a first resource request for the second microservice is obtained from the first client. Authentication and authorization are performed based on the first identity information carried in the first resource request; When authentication and authorization are successful, the first resource request is sent to the second authentication and authorization module associated with the second microservice in the second cluster based on the first Uniform Resource Locator carried in the first resource request, so that the second authentication and authorization module can send the first resource request to the second microservice after successful authentication and authorization.

[0006] In some exemplary embodiments, the authentication and authorization based on the first identity information carried in the first resource request includes: Based on the first identity information, perform identity authentication; When identity authentication is successful, the corresponding user role is determined based on the first identity information; Based on the user roles and the role-based access control rules pre-stored in the distributed key-value database, permission verification is performed. When the permission verification is successful, the authentication and authorization are confirmed to be successful.

[0007] In some exemplary embodiments, the method further includes: When a change is detected in the distributed key-value database, the service registration information added or updated by the second authentication and authorization module to the distributed key-value database is obtained. Based on the newly added or updated service registration information, a service proxy corresponding to the second microservice is generated.

[0008] In some exemplary embodiments, sending the first resource request to the second authentication and authorization module associated with the second microservice in the second cluster based on the first Uniform Resource Locator carried in the first resource request includes: Based on the first Uniform Resource Locator, the target service proxy is determined; The first resource request is sent to the second authentication and authorization module through the target service proxy.

[0009] In some exemplary embodiments, the method further includes: If the first microservice is registered in the distributed key-value database, a second resource request for the first microservice is obtained from the second client. Authentication and authorization are performed based on the second identity information carried in the second resource request; When authentication and authorization are successful, the second resource request is sent to the first microservice based on the second Uniform Resource Locator carried in the second resource request, so that the first microservice can process the second resource request.

[0010] In some exemplary embodiments, the method further includes: Obtain the configuration file corresponding to the first microservice; Obtain the service configuration information corresponding to the first microservice from the configuration file corresponding to the first microservice; Based on the service configuration information corresponding to the first microservice, generate the service registration information corresponding to the first microservice; Send the service registration information corresponding to the first microservice to the distributed key-value database; Based on the service registration information corresponding to the first microservice, a service proxy corresponding to the first microservice is generated.

[0011] This application provides a microservice management method applied to a second authentication and authorization module in a second cluster. The second authentication and authorization module is associated with a second microservice in the second cluster. The method includes: When the second microservice is registered with the distributed key-value database in the first cluster, the second authentication and authorization module receives the first resource request for the second microservice sent by the first authentication and authorization module in the first cluster after successful authentication and authorization. Authentication and authorization are performed based on the first identity information carried in the first resource request; When authentication and authorization are successful, the resource request is sent to the second microservice based on the first Uniform Resource Locator carried in the first resource request.

[0012] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. When a processor executes computer-executable instructions or computer programs stored in the memory, it implements the microservice management method provided in the embodiments of this application.

[0013] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions. When the computer program or computer-executable instructions are executed by a processor, they implement the microservice management method provided in this application.

[0014] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the microservice management method provided in this application.

[0015] The embodiments of this application have the following beneficial effects: The microservice management method, device, storage medium, and product provided in this application, by deploying a first authentication and authorization module and a distributed key-value database in a first cluster and a second authentication and authorization module in a second cluster, allows microservices in all clusters to register with the distributed key-value database. When a second microservice in the second cluster is registered in the distributed key-value database, the first authentication and authorization module, upon successful authentication and authorization, forwards resource requests for the second microservice in the second cluster to the second authentication and authorization module. This allows the second authentication and authorization module to send the resource requests for the second microservice to the second microservice for processing after successful authentication and authorization. Thus, by uniformly authenticating, authorizing, and forwarding resource requests through the first authentication and authorization module, the problems of how to communicate in cross-cluster scenarios and how to ensure resource security during communication are solved, enabling secure cross-cluster communication. Attached Figure Description

[0016] Figure 1 A schematic diagram of the system architecture of a microservice management method provided in this application embodiment; Figure 2 This is a first flowchart illustrating a microservice management method provided in an embodiment of this application. Figure 3 This is a second flowchart illustrating a microservice management method provided in an embodiment of this application. Figure 4 A schematic diagram illustrating an application scenario of a microservice management method provided in an embodiment of this application; Figure 5 This is a first flowchart illustrating an application scenario of a microservice management method provided in an embodiment of this application. Figure 6 This is a second flowchart illustrating an application scenario of a microservice management method provided in an embodiment of this application. Figure 7 A third flowchart illustrating an application scenario of a microservice management method provided in this application embodiment; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0017] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0020] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0021] In the embodiments of this application, the terms "module," "unit," or "component" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0022] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for descriptive purposes only and is not intended to limit the scope of this application.

[0023] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0024] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained below, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0025] 1. Microservice: Also known as application service instance or application instance, it is a software architecture design pattern and a variant of Service-oriented Architecture (SOA). It divides a single application into a set of loosely coupled, small, autonomous service units that can be deployed, scaled, and maintained independently. Each service unit is a microservice. Compared to traditional monolithic applications, microservice architecture treats each microservice as an independent entity / module, fundamentally simplifying its code and the maintenance of related infrastructure.

[0026] When breaking down large applications into multiple microservices, each microservice may use a different technology stack, such as a programming language and database, requiring the management of these environments within a complex architecture. While containerization helps manage and deploy individual microservices by running each in a separate container, communication between services remains highly complex due to the need to handle overall system health, fault tolerance, and multiple points of failure. Therefore, although these services are theoretically kept as independent micro-modules, they need to interact with each other.

[0027] 2. Kubernetes (K8s): An open-source container orchestration engine used to manage containerized applications across multiple hosts in a cloud platform. K8s aims to make deploying containerized applications simple and efficient, providing a mechanism for application deployment, planning, updating, and maintenance. In K8s, multiple containers can be created, each running an application instance. Built-in load balancing strategies enable management, discovery, and access to this group of application instances, eliminating the need for complex manual configuration and handling by operations personnel. K8s features include: Portability: Supports public, private, hybrid, and multicloud environments; Scalability: Modular, pluggable, mountable, and composable; Automation: Automatic deployment, automatic restart, automatic replication, and automatic scaling / expansion.

[0028] 3. Etcd is a highly available, strongly consistent distributed key-value store (also known as a key-value database) used to store all configuration data, state information, and metadata in the cluster. For example, all information related to the Kubernetes cluster, including the creation, updating, and deletion of objects such as Pods (container groups), Services, and Deployments, will be recorded in Etcd. In a distributed system, consistency means that regardless of which node a client connects to, all clients will see the same data at the same time. Availability means that any client requesting data will receive a response, even if some nodes are offline due to failure.

[0029] 4. Side Car: A common microservice architecture design pattern that refers to deploying auxiliary functions (such as authentication, monitoring, logging, etc.) as independent containers next to the main service to avoid intrusive modifications to the main service code.

[0030] 5. A cluster refers to a pool of computing resources consisting of multiple servers. These servers are interconnected through a network and exist as a whole to work together to complete the same task.

[0031] Service migration to the cloud refers to containerizing services and deploying them in a container orchestration environment. Currently, service authentication and authorization primarily rely on role-based access control, which allows for fine-grained resource control. Each service has its own authentication and authorization module. Users authenticate via username / password on the terminal, and the module authorizes authenticated users. Subsequent accesses to service resources are verified by this module. If authentication or authorization fails, an error message is returned, denying the user access to the relevant resources. Username / password, roles, and permissions are all stored in a relational database.

[0032] In some related technologies, all services are deployed in a single Kubernetes cluster. All user resource requests pass through a gateway, which forwards the resource requests to the authentication and authorization module. Upon receiving the resource request, the authentication and authorization module verifies the access token. If authentication is successful, access control is applied to the service call according to a preset policy. If the resource request is allowed by the preset policy, the resource request is sent to the gateway for authorization, and then forwarded to the corresponding backend microservice.

[0033] Other related technologies employ a Platform as a Service (PaaS) layer solution. This approach first deploys license-related services within a single Kubernetes cluster, then integrates pre-developed Software Development Kits (SDKs) into microservices, naturally consolidating license capabilities. Microservices then leverage the SDK for secondary development, verifying the license and implementing authentication and authorization. An SDK is generally a collection of development tools used by software engineers to build application software for specific software packages, frameworks, hardware platforms, and systems, thereby achieving a specific function.

[0034] However, with the rapid increase in the number of microservices, services may be deployed on clusters of multiple cloud vendors or on multiple clusters of a single cloud vendor. However, there is still no effective solution for how to achieve cross-cluster communication between services.

[0035] This application provides a microservice management method, device, storage medium, and product. By deploying a first authentication and authorization module and a distributed key-value database in a first cluster, and a second authentication and authorization module in a second cluster, microservices from all clusters can register with the distributed key-value database. When a second microservice in the second cluster is registered in the distributed key-value database, the first authentication and authorization module forwards user-initiated resource requests for the second microservice in the second cluster to the second authentication and authorization module after successful authentication and authorization. The second authentication and authorization module then sends the resource requests for the second microservice to the second microservice for processing after successful authentication and authorization. Thus, by using the first authentication and authorization module to uniformly authenticate, authorize, and forward resource requests, the problem of how to communicate in cross-cluster scenarios and how to ensure resource security during communication is solved, enabling secure cross-cluster communication.

[0036] In some exemplary embodiments, the microservice management methods provided in the various embodiments of this application can realize secure cross-cluster communication and are applicable to various cloud service scenarios including multiple clusters, such as public cloud service scenarios, private cloud service scenarios, and hybrid cloud service scenarios.

[0037] The following describes an exemplary application of the microservice management method provided in the embodiments of this application. Figure 1 This is a schematic diagram of the system architecture for a microservice management method provided in an embodiment of this application. Figure 1 As shown, the system architecture may include: a client 10, a first cluster 20, and one or more second clusters 30. The first cluster 20 includes a first microservice, and the second cluster 30 includes a second microservice. The first cluster 20 may also include: a distributed key-value database and a first authentication and authorization module associated with the first microservice. The distributed key-value database is used to store various information about the cluster, and the first authentication and authorization module is used for global authentication and authorization, request forwarding, etc. The second cluster 30 may also include: a second authentication and authorization module associated with the second microservice, which is used for local authentication and authorization, request forwarding, etc.

[0038] In some exemplary embodiments, client 10 communicates with the cluster via a network. The network can be a wide area network (WAN), a local area network (LAN), or a combination of both. Client 10 can be implemented using various types of terminal devices, such as laptops, tablets, desktop computers, portable computers, smartphones, smart home appliances, vehicle terminals, or aircraft, etc., which are not limited in this embodiment.

[0039] For example, a user can initiate a resource request to a microservice deployed in the cloud through a client (such as a browser). For instance, a user can access a microservice (e.g., an order service) through the user interface of a terminal device. The client (such as a browser) on the terminal device can send a resource request to the first cluster 20 based on the user's access action. The first cluster 20 then determines whether to send the resource request to the first microservice or to the second microservice in the second cluster based on the resource request.

[0040] In some exemplary embodiments, a microservice can be a Java microservice.

[0041] In some exemplary embodiments, the cluster can be various electronic devices with certain computing capabilities, such as a server cluster consisting of multiple physical servers, a distributed system consisting of multiple physical servers, a cloud server capable of providing cloud computing services, or a collaborative system consisting of edge nodes (such as NTP servers deployed at the edge) and cloud servers, etc. Here, the embodiments of this application do not limit this.

[0042] In some exemplary embodiments, the first cluster and the second cluster can be Kubernetes-based clusters (also known as Kubernetes container management platforms).

[0043] In some exemplary embodiments, the distributed key-value database may be an Etcd database.

[0044] In some exemplary embodiments, the first authentication and authorization module is associated with the first microservice in a sidecar mode, so as to enable the first authentication and authorization module and the first microservice to be deployed together in the first cluster in a sidecar mode. For example, the first microservice and its associated first authentication and authorization module are deployed together in the same container group (Pod) in the same first cluster in a sidecar mode.

[0045] In some exemplary embodiments, the first microservice in the first cluster and the second microservice in the second cluster are both registered to the distributed key-value database in the first cluster in a sidecar mode.

[0046] here, Figure 1 The example shown is merely a system architecture example for a microservice management method provided in the embodiments of this application, to help those skilled in the art understand the technical content of this application, but does not mean that the embodiments of this application cannot be used in other devices, systems, environments or scenarios.

[0047] Figure 2 This is a first flowchart illustrating a microservice management method provided in an embodiment of this application. The following will combine... Figure 2 This explanation is provided. This microservice management method can be used in... Figure 1 The execution occurs on the first cluster side, for example, the execution of the first authentication and authorization module in the first cluster. The first cluster includes: a distributed key-value database, and a first microservice and its associated first authentication and authorization module, such as... Figure 2 As shown, the microservice management method may include the following steps S201 to S203: Step S201: If the first authentication and authorization module in the first cluster has registered the second microservice in the second cluster in the distributed key-value database, it obtains the first resource request for the second microservice from the first client. Step S202: The first authentication and authorization module in the first cluster performs authentication and authorization based on the first identity information carried in the first resource request; Step S203: When the authentication and authorization of the first authentication and authorization module in the first cluster is successful, it sends the first resource request to the second authentication and authorization module associated with the second microservice in the second cluster based on the first Uniform Resource Locator carried in the first resource request, so that the second authentication and authorization module sends the first resource request to the second microservice after successful authentication and authorization.

[0048] In this context, "registering a second microservice in a second cluster with a distributed key-value database" means that the second microservice has started and the distributed key-value database stores the service registration information corresponding to the second microservice. For example, after starting the second microservice, the second authorization and authentication module associated with the second microservice in the second cluster can generate the service registration information corresponding to the second microservice based on the configuration file corresponding to the second microservice, and send the service registration information to the distributed key-value database in the first cluster. For example, the configuration file corresponding to the second microservice can be a YAML configuration file. A YAML configuration file includes a Deployment section and a Service section, which can be written and entered by the user. YAML is a data serialization language specifically used for writing configuration files.

[0049] In some exemplary embodiments, the first resource request may be a message requesting to obtain resources from a microservice, a message requesting to send resources to a microservice, or a message requesting to create resources in a microservice. For example, taking an order service as an example, the first resource request may be a message requesting to obtain historical order information from the order service, a message requesting to delete a historical order from the order service, or a message requesting to create a new order in the order service.

[0050] The first resource request carries information necessary for the microservice to complete the resource request. This information includes, but is not limited to: primary identity information for authentication, a primary Uniform Resource Locator (URL) specifying the resource location, and context information. For example, the primary identity information may include, but is not limited to, a username, password, and token. Context information may include, for example, the time, location, and device from which the request was initiated. The token may be a JSON Web Token (JWT). For instance, after a user logs in, the server verifies the login information and generates a corresponding token, which is then returned to the first client for storage. Thus, when a user initiates a resource request, the first client can include the token in the request.

[0051] In some exemplary embodiments, the first resource request can be an HTTP request, such as a GET request or a POST request. A GET request is used to retrieve resources from a microservice, while a POST request is used to send resources to a microservice.

[0052] Among them, authentication and authorization refer to verifying at least one of the following: verifying the legitimacy of the identity of the source of the resource request and verifying whether the identity of the source of the resource request has the authority to access the target resource.

[0053] For example, taking the order service in a shopping platform as the second microservice, a registered user of the shopping platform has the permission to browse the historical orders corresponding to that user. They can access the historical orders corresponding to that user based on their username and password. In this case, the registered user of the shopping platform can send a resource request to the first authentication and authorization module deployed in the first cluster to obtain order information. The first authentication and authorization module deployed in the first cluster will then verify the identity and permissions of the registered user. After successful verification, the first authentication and authorization module will forward the resource request to obtain order information to the second authentication and authorization module associated with the order service. The second authentication and authorization module will then send the resource request to the second microservice (such as the order service).

[0054] For example, if the second microservice is the order service in a shopping platform, unregistered users (guests) do not have the permission to browse historical orders. If an unregistered user sends a resource request to the first authentication and authorization module deployed in the first cluster to obtain order information, the authentication and authorization will fail. The first authentication and authorization module deployed in the first cluster will not forward the resource request to the second authentication and authorization module associated with the order service.

[0055] Thus, the microservice management method provided in this application, by deploying a first authentication and authorization module and a distributed key-value database in the first cluster and a second authentication and authorization module in the second cluster, allows all microservices in the clusters to register with the distributed key-value database. When a second microservice in the second cluster is registered with the distributed key-value database, the first authentication and authorization module, upon successful authentication and authorization, forwards the user's resource request for the second microservice in the second cluster to the second authentication and authorization module. The second authentication and authorization module, upon successful authentication and authorization, then sends the resource request for the second microservice to the second microservice for processing. In this way, because the first authentication and authorization module performs unified authentication, authorization, and forwarding of resource requests, it solves the problems of how to communicate in cross-cluster scenarios and how to ensure resource security during cross-cluster communication, enabling secure cross-cluster communication.

[0056] Successful authentication and authorization can refer to both successful identity authentication and successful authorization verification.

[0057] In some exemplary embodiments, step S202: performing authentication and authorization based on the first identity information carried in the first resource request may include the following steps: Step S301: The first authentication and authorization module in the first cluster performs identity authentication based on the first identity information carried in the first resource request; Step S302: When identity authentication is successful, the first authentication and authorization module in the first cluster determines the corresponding user role based on the first identity information; Step S303: The first authentication and authorization module in the first cluster performs permission verification based on user roles and role-based access control rules pre-stored in the distributed key-value database; Step S304: When the permission verification is successful, the first authentication and authorization module in the first cluster determines that the authentication and authorization are successful.

[0058] Identity authentication refers to verifying the legitimacy of the user who initiates the resource request.

[0059] In this context, permission verification refers to verifying whether the user role corresponding to the user who initiated the resource request has the permission to access the target resource.

[0060] Role-based access control (RBAC) rules are a model that authorizes end-users to access systems, applications, and data based on predefined user roles. For example, in this embodiment, RBAC rules can be dynamically updated based on privilege escalation or demotion results.

[0061] In some exemplary embodiments, different user roles can be assigned different resource access permissions for the same resource provided by a microservice, or different user roles can be assigned the same resource access permissions. For example, taking the second microservice as an order service in a shopping platform, different user roles can be assigned different access permissions to the historical order information provided by the order service. When a registered user logs into the shopping platform, the user role corresponding to the registered user can be a logged-in user, and in this case, the registered user has the permission to access the historical order information provided by the order service; while when a registered user does not log into the shopping platform, the user role corresponding to the registered user can be a guest user, and in this case, the registered user does not have the permission to access the historical order information provided by the order service. As another example, taking the second microservice as a product display service in a shopping platform, the user initiating the resource request to obtain product information, whether logged-in or a guest user, has the permission to access the product information provided by the product display service.

[0062] Thus, the microservice management method provided in this application performs identity authentication based on the first identity information, ensuring the effective verification of the user's identity initiating the first resource request. Furthermore, it performs permission verification based on the user role determined by the first identity information, ensuring the effective verification of the resource access permissions of the user initiating the first resource request. In this way, through authentication and authorization, effective verification of user identity and resource access permissions based on user roles is achieved, thereby ensuring resource security in cross-cluster communication scenarios. In addition, by setting role-based access control rules, the access permissions of different users can be flexibly configured, enhancing the system's controllability and security.

[0063] In some exemplary embodiments, taking the first identity information as including a first username and its corresponding first password as an example, step S301 may include: matching the first username and its corresponding first password with the username and its corresponding password pre-stored in the distributed key-value database; when the first username and its corresponding first password both match, determining that identity authentication is successful; when at least one of the first username and its corresponding first password does not match, determining that identity authentication fails.

[0064] In some other exemplary embodiments, taking the first identity information as including a first token as an example, step S301 may include: verifying whether the first token is within its validity period and checking whether the first token has been tampered with; when it is determined that the first token is within its validity period and has not been tampered with, the identity authentication is determined to be successful; when it is determined that the first token meets at least one of the following conditions: not within its validity period or has been tampered with, the identity authentication is determined to be unsuccessful.

[0065] In some exemplary embodiments, after step S301, the microservice management method may further include: when authentication fails, returning a message indicating authentication failure to the first client. For example, when authentication fails due to a username mismatch, returning a message indicating a username mismatch to the first client. As another example, when authentication fails due to a password mismatch, returning a message indicating a password mismatch to the first client.

[0066] In some exemplary embodiments, successful permission verification in step S304 may include: determining successful permission verification when the permission verification result indicates that the user has permission to access the resource. The permission verification result is obtained based on user roles and role-based access control rules pre-stored in the distributed key-value database.

[0067] In some other exemplary embodiments, successful permission verification in step S304 may include: when the permission verification result is a result indicating that the user has the necessary permissions to access the resource, determining whether to perform a permission reduction operation based on the role information, the first Uniform Resource Locator and context information carried in the first resource request; and when it is determined that no permission reduction operation should be performed, determining that the permission verification is successful.

[0068] The permission verification result is obtained by verifying permissions based on user roles and role-based access control rules pre-stored in the distributed key-value database.

[0069] The user role is determined based on the first user information (such as a token) carried in the first resource request.

[0070] Context information refers to the environment itself and any information, whether explicit or implicit, that can be used to describe the state (including historical state) of the entities within it.

[0071] In some exemplary embodiments, the context information may include: time context, device context, and spatial context. The time context may be the system time of the terminal device used by the user initiating the request; the device context may be the device information of the terminal device used by the user initiating the request; and the spatial context may be the location information of the terminal device used by the user initiating the request. For example, the context information may include: the time of the request, the device, and the location.

[0072] For example, determining whether to perform a demotion operation based on role information, the first Uniform Resource Locator (URL) and context information carried in the first resource request can include: determining whether to perform a demotion operation based on role information, the first URL and context information carried in the first resource request, through a pre-set role adjustment model.

[0073] In some exemplary embodiments, successful permission verification in step S304 may include: when the permission verification result indicates that the user does not have permission to access the resource, the first authentication and authorization module in the first cluster determines whether to perform an elevation of privilege operation based on role information, the first Uniform Resource Locator (URL) and context information carried in the first resource request; when it is determined that an elevation of privilege operation should be performed, the permission verification is determined to be successful. The permission verification result is obtained based on user roles and role-based access control rules pre-stored in the distributed key-value database.

[0074] For example, determining whether to perform an escalation of privileges operation based on role information, the first Uniform Resource Locator (URL) and context information carried in the first resource request can include: determining whether to perform an escalation of privileges operation based on role information, the first URL and context information carried in the first resource request, through a pre-set role adjustment model.

[0075] For example, determining whether to perform an escalation of privileges operation based on role information and the first Uniform Resource Locator (URL) and context information carried in the first resource request can include: the first authentication and authorization module in the first cluster determines whether to perform an escalation of privileges operation based on role information and the first URL and context information carried in the first resource request using a pre-set role adjustment model; when the result output by the role adjustment model indicates that privilege escalation is possible, the first authentication and authorization module in the first cluster sends an audit request to the administrator for manual judgment; when the administrator determines that privilege escalation is possible, the administrator can perform operations on the client; the client associated with the administrator can generate and return a response message indicating privilege escalation to the first authentication and authorization module in the first cluster based on the administrator's operation; when the first authentication and authorization module in the first cluster receives the response message indicating privilege escalation, it determines to perform the escalation of privileges operation, thereby confirming successful privilege verification.

[0076] In some exemplary embodiments, after step S303: performing permission verification based on user roles and role-based access control rules pre-stored in the distributed key-value database, the microservice management method may further include: when the permission verification result in the first authentication and authorization module in the first cluster indicates that it has the permission to access resources, it determines whether to perform a permission reduction operation based on role information, the first Uniform Resource Locator (URL) and context information carried in the first resource request; when it is determined to perform a permission reduction operation, it adjusts the role information to the role information after the permission reduction; and performs permission verification again based on the role information after the permission reduction and the role-based access control rules pre-stored in the distributed key-value database.

[0077] For example, determining whether to perform a demotion operation based on role information, the first Uniform Resource Locator (URL) and context information carried in the first resource request can include: determining whether to perform a demotion operation based on role information, the first URL and context information carried in the first resource request, through a pre-set role adjustment model.

[0078] Thus, the microservice management method provided in this application, through a pre-set role adjustment model, determines whether to elevate or demote privileges based on role information, the first Uniform Resource Locator (URL) carried in the first resource request, and context information. This allows for dynamic adjustment of access permissions for different users, enhancing controllability and security.

[0079] In some exemplary embodiments, the microservice management method may further include: Step S401: When the first authentication and authorization module in the first cluster detects a change in the distributed key-value database, the first authentication and authorization module in the first cluster obtains the service registration information added or updated by the second authentication and authorization module in the distributed key-value database. Step S402: The first authentication and authorization module in the first cluster generates a service proxy corresponding to the second microservice based on the newly added or updated service registration information.

[0080] In some exemplary embodiments, service registration information may include service identification information, host identification information, service port information, public key, and security information. For example, service identification information may be a service name, host identification information may be a host name, host IP address, or cluster VIP (Virtual IP) address. The host IP address is a unique identifier for a host in the network, and the cluster VIP address is a unique identifier for a cluster in the network. Service port information may be the port exposed by the service, and security information may be service application programming interface (API) bytecode data and encrypted service API bytecode data.

[0081] Thus, the microservice management method provided in this application obtains the latest service registration information in real time by monitoring changes in the distributed key-value database and generates corresponding service proxies accordingly. This enables dynamic proxying and ensures timely updates of service proxies, avoiding call failures caused by outdated service registration information.

[0082] In some exemplary embodiments, step S203, sending the first resource request to the second authentication and authorization module associated with the second microservice in the second cluster based on the first Uniform Resource Locator carried in the first resource request, may include the following steps S2031 to S2032: Step S2031: The first authentication and authorization module in the first cluster determines the target service proxy based on the first Uniform Resource Locator carried in the first resource request; Step S2032: The first authentication and authorization module in the first cluster sends the first resource request to the second authentication and authorization module through the target service proxy.

[0083] Thus, the microservice management method provided in this application sends the first resource request to the second authentication and authorization module by determining the target service proxy based on the first Uniform Resource Locator carried in the first resource request, thereby achieving accurate forwarding of the request.

[0084] In some exemplary embodiments, the microservice management method may further include: Step S501: If the first microservice is registered in the distributed key-value database, the first authentication and authorization module in the first cluster obtains the second resource request for the first microservice from the second client. Step S502: The first authentication and authorization module in the first cluster performs authentication and authorization based on the second identity information carried in the second resource request; Step S503: When authentication and authorization are successful, the first authentication and authorization module in the first cluster sends the second resource request to the first microservice based on the second Uniform Resource Locator carried in the second resource request, so that the first microservice can process the second resource request.

[0085] In some exemplary embodiments, the first microservice receives the second resource request and returns a response result to the second client.

[0086] For example, the first microservice receives the second resource request, performs the corresponding service processing, and returns a response result corresponding to the second resource request. For example, the response result returned by the first microservice can be the response resource corresponding to the second resource request, where the response result exists in the form of a response header + response body.

[0087] Thus, the microservice management method provided in this application, when the first authentication and authorization module in the first cluster receives a second resource request for the first microservice, can forward the user-initiated second resource request to the first microservice after successful authentication and authorization. This allows the first microservice to process the second resource request and return a response. In this way, by uniformly authenticating, authorizing, and forwarding resource requests through the first authentication and authorization module, secure cross-cluster communication can be achieved, while also addressing resource security issues within the microservices of this cluster.

[0088] In some exemplary embodiments, the microservice management method may further include: Step S601: The first authentication and authorization module in the first cluster obtains the configuration file corresponding to the first microservice; Step S602: The first authentication and authorization module in the first cluster obtains the service configuration information corresponding to the first microservice from the configuration file corresponding to the first microservice; Step S603: The first authentication and authorization module in the first cluster generates service registration information corresponding to the first microservice based on the service configuration information corresponding to the first microservice; Step S604: The first authentication and authorization module in the first cluster sends the service registration information corresponding to the first microservice to the distributed key-value database; Step S605: The first authentication and authorization module in the first cluster generates a service proxy corresponding to the first microservice based on the service registration information corresponding to the first microservice.

[0089] For example, the configuration file for the first microservice can be a Yaml configuration file. A Yaml configuration file includes a deployment section and a service section, which can be written and entered by the user. Yaml is a data serialization language specifically used for writing configuration files.

[0090] Thus, the microservice management method provided in this application registers the first microservice to the distributed key-value database in a sidecar mode through the first authentication and authorization module.

[0091] In some exemplary embodiments, the first cluster further includes a third microservice and its associated third authentication and authorization module. In this case, the microservice management method may further include the following steps: If the third microservice in the first cluster is registered in the distributed key-value database, the first authentication and authorization module in the first cluster obtains a third resource request for the third microservice from a third client; the first authentication and authorization module in the first cluster performs authentication and authorization based on the third identity information carried in the third resource request; when authentication and authorization are successful, the first authentication and authorization module in the first cluster sends the third resource request to the third authentication and authorization module associated with the third microservice in the first cluster based on the third Uniform Resource Locator carried in the third resource request, so that the third authentication and authorization module performs authentication and authorization on the third resource request, and sends the third resource request to the third microservice after successful authentication and authorization.

[0092] The process of the first authentication and authorization module authenticating and authorizing based on the third identity information carried in the third resource request, and the process of the third authentication and authorization module authenticating and authorizing based on the third identity information carried in the third resource request, can be understood by referring to the process of the first authentication and authorization module authenticating and authorizing the first resource request described above, and will not be elaborated further here.

[0093] In some exemplary embodiments, the process of registering a third microservice in a first cluster with a distributed key-value database may include: obtaining a configuration file corresponding to the third microservice through a third authentication and authorization module associated with the third microservice in the first cluster; obtaining service configuration information corresponding to the third microservice from the configuration file; generating service registration information corresponding to the third microservice based on the service configuration information; and sending the service registration information to the distributed key-value database. Thus, the microservice management method provided in this application uses a third authentication and authorization module to register the third microservice to the distributed key-value database in a sidecar mode. This allows the first authentication and authorization module to generate a service proxy for the third microservice based on the newly added service registration information in the distributed key-value database when it detects new service registration information for the third microservice.

[0094] In some exemplary embodiments, the first authentication and authorization module in the first cluster determines the target service proxy based on the third Uniform Resource Locator carried in the third resource request; the first authentication and authorization module in the first cluster sends the third resource request to the third authentication and authorization module through the target service proxy.

[0095] Thus, the microservice management method provided in this application, when the first authentication and authorization module in the first cluster receives a third resource request for a third microservice in the first cluster, can send the third resource request to the third authentication and authorization module associated with the third microservice in the first cluster after successful authentication and authorization. This allows the third authentication and authorization module to authenticate and authorize the third resource request, and then send it to the third microservice after successful authentication and authorization. This enables the third microservice to process the third resource request. In this way, by uniformly authenticating, authorizing, and forwarding resource requests through the first authentication and authorization module, secure cross-cluster communication and secure intra-cluster communication can be achieved simultaneously.

[0096] In some exemplary embodiments, after step S202: the first authentication and authorization module in the first cluster performs authentication and authorization based on the first identity information carried in the first resource request, the microservice management method may further include: when authentication and authorization fails, the first authentication and authorization module in the first cluster sends a message to the first client to indicate that authentication and authorization has failed, such as a message indicating identity authentication failure, a message indicating permission error, etc.

[0097] In some exemplary embodiments, in step S203: when the first authentication and authorization module in the first cluster successfully authenticates and authorizes, it sends the first resource request to the second authentication and authorization module in the second cluster associated with the second microservice based on the first Uniform Resource Locator carried in the first resource request. This allows the second authentication and authorization module to send the first resource request to the second microservice after successful authentication and authorization. The microservice management method may further include: the first authentication and authorization module in the first cluster receiving a response result sent by the second microservice; and the first authentication and authorization module in the first cluster sending the response result to the first client. For example, the response result could be the resource requested by the first resource request (such as order information), a processing result (such as a newly created order), etc.

[0098] Figure 3 This is a second flowchart illustrating a microservice management method provided in an embodiment of this application. The following will be combined with... Figure 3 This explanation is provided. This microservice management method can be used in... Figure 1 The execution occurs on the second cluster side, for example, the second authentication and authorization module within the second cluster. The second cluster includes: the second microservice and its associated second authentication and authorization module. For example... Figure 3 As shown, the microservice management method may include the following steps S701 to S704: Step S701: When the second microservice is registered with the distributed key-value database in the first cluster, the second authentication and authorization module in the second cluster receives the first resource request for the second microservice sent by the first authentication and authorization module in the first cluster after successful authentication and authorization. Step S702: The second authentication and authorization module in the second cluster performs authentication and authorization based on the first identity information carried in the first resource request; Step S703: When the authentication and authorization of the second authentication and authorization module in the second cluster is successful, it sends the first resource request to the second microservice based on the first Uniform Resource Locator carried in the first resource request.

[0099] Among them, authentication and authorization refer to verifying at least one of the following: verifying the legitimacy of the identity of the source of the resource request and verifying whether the identity of the source of the resource request has the authority to access the target resource.

[0100] In some exemplary embodiments, step S702: the second authentication and authorization module in the second cluster performs authentication and authorization based on the first identity information carried in the first resource request, which may include the following steps: the second authentication and authorization module in the second cluster performs identity authentication based on the first identity information carried in the first resource request; when identity authentication is successful, the second authentication and authorization module in the second cluster determines the corresponding user role based on the first identity information; the second authentication and authorization module in the second cluster performs permission verification based on the user role and the role-based access control rules pre-stored in the distributed key-value database; when permission verification is successful, the second authentication and authorization module in the second cluster determines that authentication and authorization are successful.

[0101] In some exemplary embodiments, the microservice management method may further include: when authentication fails, a second authentication and authorization module in the second cluster sends a message indicating authentication failure to a first authentication and authorization module in the first cluster, so that the first authentication and authorization module in the first cluster sends the message indicating authentication failure to a first client.

[0102] In some exemplary embodiments, the microservice management method may further include: when authentication fails, a second authentication and authorization module in the second cluster sends a message to the first client indicating that authentication has failed.

[0103] Thus, the microservice management method provided in this application, by deploying a first authentication and authorization module and a distributed key-value database in the first cluster and a second authentication and authorization module in the second cluster, allows microservices from all clusters to register with the distributed key-value database. When a second microservice in the second cluster is registered in the distributed key-value database, the first authentication and authorization module forwards resource requests initiated by the user for the second microservice in the second cluster to the second authentication and authorization module after successful authentication and authorization. Upon receiving a resource request for the second microservice, the second authentication and authorization module performs authentication and authorization again, and after successful authentication and authorization, sends the resource request for the second microservice to the second microservice for processing. In this way, because the first authentication and authorization module performs unified authentication, authorization, and forwarding of resource requests, it solves the problems of how to communicate in cross-cluster scenarios and how to ensure resource security during cross-cluster communication, enabling secure cross-cluster communication. Furthermore, authentication and authorization performed locally in the cluster where the second microservice resides through the second authentication and authorization module can prevent unauthorized access and ensure local resource security.

[0104] Figure 4 This is a schematic diagram illustrating an application scenario of a microservice management method provided in an embodiment of this application. Figure 4 The system architecture of an exemplary application scenario where the microservice management method of the embodiments of this application can be applied is shown. For example... Figure 4As shown, the system architecture may include multiple clusters, which may include K8s cluster 1, K8s cluster 2 and K8s cluster 3.

[0105] K8s cluster 1 (if designated as the first cluster) may include: Etcd database 40, microservice 41-1 (if designated as the first microservice), Authentication Authorization Core (AAC) module (if designated as the first authentication and authorization module), microservice 41-4 (if designated as the third microservice), and Authentication Authorization Local (AAL) module (if designated as the third authentication and authorization module). The Authentication Authorization Core module is associated with microservice 41-1 in a sidecar mode, and the Authentication Authorization Local (AAL) module is associated with microservice 41-4 in a sidecar mode. For example, the Authentication Authorization Core (AAC) module is deployed in a sidecar mode along with microservice 41-1 in a container group (Pod) within K8s cluster 1 (if designated as the first cluster), and the Authentication Authorization Local (AAL) module 43-1 is deployed in a sidecar mode along with microservice 41-4 in a container group (Pod) within K8s cluster 1 (if designated as the first cluster).

[0106] K8s cluster 2 (if used as a second cluster) may include: microservice 41-2 (if used as a second microservice) and authentication and authorization local (AAL) module (if used as a second authentication and authorization module), which is associated with microservice 41-2 in a sidecar mode. For example, the authentication and authorization local module is deployed in a container group (Pod) in K8s cluster 2 (if used as a second cluster) in a sidecar mode along with the microservice.

[0107] Kubernetes cluster 3 (if used as a second cluster) may include: microservice 41-3 (if used as a second microservice) and an authentication and authorization local (AAL) module (if used as a second authentication and authorization module). The authentication and authorization local module is associated with microservice 41-2 in a sidecar mode. For example, the authentication and authorization local module is deployed in a container group (Pod) in Kubernetes cluster 2 (if used as a second cluster) in a sidecar mode along with microservice 41-2.

[0108] In some exemplary embodiments, such as Figure 4 As shown, K8s cluster 1 (such as the first cluster) may also include: ports for communicating with clients.

[0109] In some exemplary embodiments, such as Figure 4As shown, the authentication and authorization center module (denoted as AAC) (such as the first authentication and authorization module) may include: a first configuration manager module, a service manager module, a first service registration component, a service proxy, a first authentication module, a first authorization module, a first audit module, a strategy adjustment module, and a port for communicating with the first cluster.

[0110] In some exemplary embodiments, such as Figure 4 As shown, the authentication and authorization local module (denoted as AAL) (such as as the second authentication and authorization module or the third authentication and authorization module) may include: a second configuration manager module, a second server-register component, a second authentication module, a second authorization module, a second audit module, and a port for communication with the port in the authentication and authorization center module.

[0111] In some exemplary embodiments, the authentication and authorization center module (AAC) and the authentication and authorization local module (AAL) are developed using the Kubernetes Software Development Kit (Kubernetes SDK), and the images of the authentication and authorization center module (AAC) and the authentication and authorization local module (AAL) are integrated into the microservice in the sidecar mode, thereby giving the microservice secure communication capabilities across clusters.

[0112] In some exemplary embodiments, the Etcd database is used to store service registration information, and all microservices can register their services to the Etcd database through the sidecar pattern.

[0113] It should be understood that Figure 4 The number of clusters and microservices shown are for illustrative purposes only. The system architecture may contain more or fewer clusters and microservices.

[0114] The following is combined Figure 4The system shown illustrates the microservice management method of this application embodiment. Exemplarily, the scheme of this application can be divided into the following four parts: The first part is the service registration part, including: the first authentication and authorization module in the first cluster registers the first microservice (e.g., the authentication and authorization center module 42 in K8s cluster 1 registers microservice 41-4), the second authentication and authorization module in the second cluster registers the second microservice (e.g., the authentication and authorization local module 43-2 in K8s cluster 2 registers microservice 41-2, and the authentication and authorization local module 43-3 in K8s cluster 3 registers microservice 41-2), and the third authentication and authorization module in the first cluster registers the third microservice (e.g., the authentication and authorization local module 43-3 in K8s cluster 1 registers microservice 41-4). The second part is generating a dynamic service proxy. The third part is resource request authentication, authorization, and forwarding. The fourth part is the initialization and updating of role-based access control (RBAC) rules.

[0115] The first part will be explained below.

[0116] Figure 5 This is a first flowchart illustrating an application scenario of a microservice management method provided in an embodiment of this application, as shown below. Figure 5 As shown, this microservice management method may include: Step S11: When it is necessary to start the first microservice in the first cluster, the service registration process is executed through the first authentication and authorization module associated with the first microservice in the first cluster, based on the service configuration information corresponding to the first microservice in the YAML configuration file uploaded by the user.

[0117] For example, step S11 may include the following steps S11-1 to S11-4: Step S11-1: When it is necessary to start the first microservice in the first cluster, the service configuration information in the YAML configuration file uploaded by the user corresponding to the first microservice is read through the first configuration manager module in the first authentication and authorization module, and the user's identity is verified according to the service configuration information in the YAML configuration file. If identity verification is successful, the registration process is executed to start the first microservice; if identity verification fails, the first microservice fails to start.

[0118] Step S11-2: When identity verification is successful, the service configuration information corresponding to the first microservice read is passed to the first service registration component through the first configuration manager module. Step S11-3: Using the first service registration (server-register) component, generate service registration information corresponding to the first microservice based on the service configuration information corresponding to the first microservice.

[0119] In some exemplary embodiments, service registration information may include service identification information, host identification information, service port information, public key, and security information. For example, service identification information may be a service name, host identification information may be a host name, host IP, or cluster VIP, service port information may be the port exposed by the service, and security information may be service API bytecode data or encrypted service API bytecode data.

[0120] For example, service registration information can be represented as a five-element information group (ServiceName, HostName, Port, publicKey, SecurityInfo), where ServiceName is the service name; HostName can be the hostname, host IP, or cluster VIP; Port is the port exposed by the service; publicKey is the public key of the first authentication and authorization module in the first cluster; and SecurityInfo is encrypted service API bytecode data. SecurityInfo is security information that can be used to encrypt service data and verify whether the service data has been tampered with. For example, SecurityInfo can include the service API bytecode data and its MD5 hash. Taking a Java microservice as an example, SecurityInfo can be represented as SecurityInfo = PK(md5(Java Class Code), Java Class Code), where md5(Java Class Code) represents the MD5 hash of the service API bytecode data, and Java Class Code represents the service API bytecode data.

[0121] Step S11-4: After the service registration information corresponding to the first microservice is generated, the service registration information corresponding to the first microservice is sent to the Etcd database of the first cluster through the first service registration (server-register) component.

[0122] This completes the registration process for the first microservice in the first cluster.

[0123] Step S12: When it is necessary to start the second microservice in the second cluster, the service registration process is executed through the second authentication and authorization module associated with the second microservice in the second cluster, based on the service configuration information corresponding to the second microservice in the YAML configuration file uploaded by the user.

[0124] For example, step S12 may include the following steps S12-1 to S12-4: Step S12-1: When it is necessary to start the second microservice in the second cluster, the second cluster reads the service configuration information corresponding to the second microservice in the YAML configuration file uploaded by the user through the second configuration manager module in the second authentication and authorization module, and verifies the user's identity according to the service configuration information corresponding to the second microservice. If the verification is successful, continue to execute steps S12-2 to S12-4 to start the second microservice; if the verification fails, the second microservice fails to start.

[0125] Step S12-2: When the user identity verification is successful, the service configuration information corresponding to the second microservice read by the second configuration management (configurationManager) module is passed to the second service registration (server-register) component; Step S12-3: Using the second service registration (server-register) component, generate service registration information for the second microservice based on its service configuration information. This service registration information may include service identifier information, host identifier information, service port information, public key, and security information. For example, the service identifier information can be the service name, the host identifier information can be the hostname, host IP address, or cluster VIP, the service port information can be the port exposed by the service, and the security information can be service API bytecode data or encrypted service API bytecode data.

[0126] Step S12-4: After the service registration information corresponding to the second microservice is generated, the service registration information corresponding to the second microservice is sent to the Etcd database of the first cluster through the second service registration (server-register) component.

[0127] This completes the registration process for the second micro-server in the second cluster.

[0128] The second part is explained below. The first authentication and authorization module, associated with the first microservice, monitors the service registration information in the Etcd database. When a change is detected in the service registration information in the Etcd database, the dynamic proxy process for the service is executed. For example... Figure 5 As shown, it may include: Step S21: Using the Service Management (ServerManager) module within the first authentication and authorization module associated with the first microservice, a watch mechanism is employed to monitor the service registration information in the Etcd database. This facilitates real-time detection of changes in service registration information.

[0129] Step S22: When the Server Manager module in the first authentication and authorization module detects changes in the service registration information in the Etcd database, such as adding or updating service registration information in the Etcd database, the Server Manager module reads the newly added or updated service registration information from the Etcd database and generates a dynamic service proxy based on the read information.

[0130] For example, step S22 may include: Step S22-1: Using the Server Manager module, based on the public key in the service registration information and the private key of the first authentication and authorization module, decrypt the security information (SecurityInfo) in the service registration information to obtain the service API bytecode data and the information digest of the service API bytecode data. Step S22-2: Using the Server Manager module, perform hash calculations on the decrypted service API bytecode data using a hash algorithm (such as MD5) to obtain the hash value of the calculated service API bytecode data; Step S22-3: Through the Server Manager module, compare the message digest of the decrypted service API bytecode data with the hash value of the calculated service API bytecode data; Step S22-4: Through the Server Manager module, verify whether the decrypted service API bytecode data has been tampered with based on the comparison results.

[0131] Specifically, if the message digest of the decrypted service API bytecode data matches the hash value of the calculated service API bytecode data, it is determined that the decrypted service API bytecode data has not been tampered with; conversely, if the message digest of the decrypted service API bytecode data does not match the hash value of the calculated service API bytecode data, it is determined that the decrypted service API bytecode data has been tampered with. This ensures the security of cross-cluster service registration.

[0132] Step S22-5: Using the Server Manager module and Java class loading technology, the service API class object (such as a Class object) is generated based on the decrypted service API bytecode data (such as a *.class file compiled from the service API source program).

[0133] The bytecode data of the service API is a binary file that strictly adheres to the Java Virtual Machine (JVM) specification and contains all the information that constitutes a class or interface.

[0134] The class object of the service API serves as the access point for the service API at runtime.

[0135] Step S22-6: Through the Server Manager module, using Java reflection, based on the class object (such as the Class object) of the service API, extract class-related information from the class object (such as the Class object) of the service API. The class-related information may include: class name, method name, method parameters, URL, etc.

[0136] Step S22-7: Through the Server Manager module, using dynamic proxy technology, based on the class-related information extracted by reflection, as well as the host identification information (such as hostname) and service port information (Port) in the service registration information, a dynamic service proxy interface is generated.

[0137] In this way, the dynamic generation process of the service agent is completed.

[0138] The third part is explained below. When a user needs to access a resource provided by a microservice, the user can initiate a resource request. At this time, the first authentication and authorization module in the first cluster will receive the resource request initiated by the user. Based on the resource request, it will begin to execute the process of user authentication, resource access permission verification, and adaptive authorization, such as... Figure 6 As shown, it may include: S31: Authentication is performed based on resource requests through the first authentication module in the first authentication and authorization module of the first cluster; wherein, the resource request includes: service URL, user information for identity verification (such as token), and context information, which includes the time, device, and location of the request.

[0139] For example, step 31 may include: S31-1: Obtain a resource request through the first authentication module in the first authentication and authorization module of the first cluster; wherein, the resource request includes: service URL, user information for identity verification (such as token), and context information, which includes the time, device, and location of the request.

[0140] For example, when a user accesses a microservice (such as an order service) on the user terminal's user interface, the client on the user terminal can send a resource request to the first cluster based on the user's access operation. At this time, the first authentication and authorization module in the first cluster can obtain the resource request sent by the client.

[0141] S31-2: The first authentication module within the first authentication and authorization module of the first cluster performs identity authentication based on user information (such as a token) carried in the resource request. If authentication times out or fails, a first authentication result indicating the failure is generated and sent to the client to notify the user of the failure. Alternatively, if authentication is successful, the resource request is forwarded to the first authorization module via the first authentication module within the first authentication and authorization module of the first cluster.

[0142] S32: When authentication is successful, permission verification is performed based on the resource request through the first authorization module in the first authentication and authorization module of the first cluster.

[0143] S33: When the permission verification is successful, the corresponding registered target microservice is determined based on the URL carried in the resource request by the service proxy component in the first authentication and authorization module in the first cluster.

[0144] S34: Using the server-proxy component in the first authentication and authorization module of the first cluster, based on the type of the target microservice, determine whether to forward the resource request to the second authentication and authorization module associated with the target microservice so that the second authentication and authorization module can process the request. Alternatively, determine whether to forward the request directly to the first microservice so that the first microservice can process the request based on the URL carried in the resource request and return the processing result.

[0145] S35: When the target microservice is the second microservice in the second cluster, the resource request is sent to the second authentication and authorization module associated with the target microservice (i.e. the second microservice) through the service proxy component in the first authentication and authorization module in the first cluster, so that the second authentication and authorization module can perform operations such as S41 to S44 to authenticate the resource request.

[0146] Alternatively, S36: When the target microservice is the first microservice in the first cluster, the resource request is directly forwarded to the first microservice so that the first microservice can process the request based on the URL carried in the resource request and return the processing result.

[0147] For example, step 32 may include: S32-1: When identity authentication is successful, the user role is determined by the first authorization module in the first authentication and authorization module of the first cluster, based on the user information (such as a token) carried in the resource request for identity verification.

[0148] S32-2: The first authorization module in the first authentication and authorization module of the first cluster performs permission verification based on user roles and role-based access control (RBAC) rules pre-stored in Etcd, and obtains the permission verification result.

[0149] The permission verification result can be used to indicate whether a user role does not have the required permissions to access the resource, or to indicate whether a user role has the required permissions to access the resource.

[0150] Role-based access control (RBAC) rules are a model that authorizes end users to access systems, applications, and data based on their predefined roles.

[0151] In this context, permission verification refers to determining whether a user's role has the necessary permissions to access resources.

[0152] S32-3: The first authorization module calls the strategy adjustment module, which adjusts permissions based on the permission verification result, user role, service URL carried in the resource request, and context information.

[0153] The user role is determined based on the user information (such as a token) carried in the resource request for identity verification.

[0154] The context information can include: time context, device context, and spatial context. Time context can be the system time of the terminal device used by the user initiating the request; device context can be the device information of the terminal device used by the user initiating the request; and spatial context can be the location information of the terminal device used by the user initiating the request. For example, context information includes: the time, device, and location of the request.

[0155] In some exemplary embodiments, S32-3 may include steps S32-31 to S32-34: S32-31: When the permission verification result indicates that the user role does not have the necessary permissions to access the resource, the first authorization module calls the strategy adjustment module. The strategy adjustment module inputs the five-data set (URL, role, time, location, device, raise) consisting of the user role, the URL carried in the resource request, the context information carried in the resource request (such as time, device, and location), and the privilege escalation instruction into the role adjustment model. The role adjustment model in the strategy adjustment module determines whether to perform permission adjustment (such as privilege escalation) based on the request context information. S32-32: The strategy adjustment module determines whether to send an audit request based on the privilege escalation results output by the role adjustment model; S32-33: When the privilege escalation result output by the role adjustment model indicates that privilege escalation is possible, the strategy adjustment module records this operation and sends an audit request to the client associated with the administrator for manual judgment. Alternatively, when the privilege escalation result output by the role adjustment model indicates that privilege escalation is not possible, the strategy adjustment module records the event data corresponding to this event and returns a message indicating a permission error. The recorded event data includes the user role (determined based on user information in the resource request), the URL carried in the resource request, the context information in the resource request, the permission adjustment operation status information (such as status information indicating no permission adjustment), and the role after permission adjustment.

[0156] Specifically, when an administrator determines that privilege escalation is permissible, the administrator can perform actions on the client. The client associated with the administrator can then generate and return a response message indicating privilege escalation based on the administrator's actions, and record the event data corresponding to this event. The event data includes the user role (determined based on the user information in the resource request), the URL carried in the resource request, the context information in the resource request, the status information of the permission adjustment operation (such as the status information indicating privilege escalation), and the role after the permission adjustment. Alternatively, when an administrator determines that privilege escalation is not permissible, the administrator can perform actions on the client. The client associated with the administrator can then generate and return a response message indicating a permission error based on the administrator's actions.

[0157] S32-34: When the strategy adjustment module receives a response message indicating privilege escalation, it executes S33 to determine the corresponding registered target microservice based on the URL carried in the resource request through the server-proxy component in the first authentication and authorization module in the first cluster. In some other exemplary embodiments, S32-3 may include the following steps S32-35 to S32-37: S32-35: When the permission verification result indicates that the user role has the necessary permissions to access the resource, the first authorization module calls the strategy adjustment module. The strategy adjustment module inputs the five-data set (URL, role, time, location, device, drop) consisting of the user role, the URL carried in the resource request, the context information carried in the resource request (such as time, device, and location), and the drop instruction into the role adjustment model. The role adjustment model determines whether a drop is needed based on the request context information. For example, if there are no anomalies in the context, it can be determined that a reduction in weight is not necessary.

[0158] S32-36: Strategy adjustment module, based on the weight reduction results output by the role adjustment model, determines whether to reduce the weight; S32-37: When the role adjustment model outputs a demotion result indicating that demotion is permissible, execute the demotion operation, adjust the user role to a reasonable role, and record the demotion operation. Then, execute S33 to determine the corresponding registered target microservice based on the URL carried in the resource request using the service proxy component in the first authentication and authorization module of the first cluster. Alternatively, when the role adjustment model outputs a demotion result indicating that demotion is not permissible, execute S33 to determine the corresponding registered target microservice based on the URL carried in the resource request using the service proxy component in the first authentication and authorization module of the first cluster. Record the event data corresponding to this event, which includes the user role (determined based on the user information in the resource request), the URL carried in the resource request, the context information in the resource request, the permission adjustment operation status information (such as status information indicating demotion), and the role after permission adjustment.

[0159] In some exemplary embodiments, the event data corresponding to a permission adjustment event may include the user role (determined based on user information in the resource request), the URL carried in the resource request, context information in the resource request, permission adjustment operation status information (such as status information indicating demotion), and the role after permission adjustment. The permission adjustment operation status information may include status information indicating privilege elevation, status information indicating privilege demotion, and status information indicating no permission adjustment.

[0160] In some exemplary embodiments, the event data (URL, role, time, location, device, op, result) recorded in steps S32-33 and S32-37 can be used as input to the model and trained using a Support Vector Machine (SVM). Op represents the permission adjustment result. Op has three values: 1 indicates a raise, -1 indicates a drop, and 0 indicates no operation (i.e., no permission adjustment). Result represents the role after permission adjustment.

[0161] In some other exemplary embodiments, S32-3 may include step S32-38: when the permission verification result is a first result indicating that the microservice and the user role do not match, the first authorization module determines that the user role does not have the permission to call the microservice, generates a verification result indicating a permission error, and sends the verification result to the client to remind the user of the permission error.

[0162] Following step S35, the microservice management method may further include the following steps: Step S41: When the target microservice is the second microservice in the second cluster, the second authentication and authorization module associated with the second microservice in the second cluster can receive resource requests forwarded by the service proxy component in the first authentication and authorization module in the first cluster.

[0163] Step S42: Authentication is performed based on the resource request through the second authentication module in the second authentication and authorization module of the second cluster; wherein, the resource request includes: service URL, user information for identity verification (such as token), and context information, which includes the time, device, and location of the request.

[0164] Here, the authentication process of the second authentication module can be understood by referring to the authentication process of the first authentication module in step S31, and will not be repeated here.

[0165] Step S43: If authentication is successful, perform permission verification based on the resource request through the second authorization module in the second authentication and authorization module of the second cluster. Alternatively, if authentication fails, return a message indicating authentication failure.

[0166] Step S44: When the permission verification is successful, the resource request is sent to the second microservice through the second authorization module in the second authentication and authorization module in the second cluster, so that the second microservice can process the request based on the URL carried in the resource request and return the processing result.

[0167] The fourth part is explained below. This involves the initialization and updating of Role-Based Access Control (RBAC) rules in the Etcd database, such as... Figure 7 As shown, it may include: Step S51: When it is necessary to start the first microservice in the first cluster, the first authentication and authorization module associated with the first microservice in the first cluster reads the role-based access control (RBAC) rule configuration information corresponding to the first microservice in the user-uploaded Yaml configuration file, and stores the role-based access control (RBAC) rules in the Etcd database of the first cluster.

[0168] For example, step S51 may include the following steps: when it is necessary to start the first microservice in the first cluster, the first configuration management module in the first authentication and authorization module associated with the first microservice in the first cluster reads the role-based access control (RBAC) rule configuration information corresponding to the first microservice in the user-uploaded Yaml configuration file; and verifies the configuration information and instantiates the RBAC rule object according to the role-based access control (RBAC) rule configuration information corresponding to the first microservice; and stores the role-based access control (RBAC) rule in the Etcd database of the first cluster.

[0169] Step S52: When it is necessary to start the second microservice in the second cluster, the role-based access control (RBAC) rules corresponding to the second microservice in the second cluster are stored in the Etcd database of the first cluster through the second authentication and authorization module in the second cluster, based on the role-based access control (RBAC) rule configuration information of the second microservice in the Yaml configuration file uploaded by the user.

[0170] For example, step S52 may include the following steps: when it is necessary to start the second microservice in the second cluster, the second configuration manager module in the second authentication and authorization module of the second cluster reads the role-based access control (RBAC) rule configuration information corresponding to the second microservice in the user-uploaded Yaml configuration file; and verifies the configuration information and instantiates the RBAC rule object according to the role-based access control (RBAC) rule configuration information corresponding to the second microservice; and stores the role-based access control (RBAC) rule in the Etcd database of the first cluster.

[0171] For example, the RBAC rule configuration information in the Yaml configuration file is shown in Table 1 below: Table 1. RBAC rule configuration information in the Yaml configuration file

[0172] For example, Role-Based Access Control (RBAC) rules can pre-define four classes: User, Role, Permission, and RBAC Rule. The RBAC Rule class can include the mapping between users, roles, and permissions. The User class can include the mapping between user ID, username, password, and role ID. The Role class can include the mapping between role ID and role name. The Permission class can include the mapping between permission ID, resource URL, and a list of roles.

[0173] Step S53: After service registration, the Server Manager module in the first authentication and authorization module of the first cluster uses a watch mechanism to monitor the service registration information in the Etcd database. When the Server Manager module detects changes in the service registration information in the Etcd database, such as updating the service registration information in the Etcd database, it reads the updated service registration information from the Etcd database. Based on the read updated service registration information, it obtains the resource role relationships in the microservices through deserialization. According to the resource role relationships in the microservices, it updates the role-based access control (RBAC) rules in the Etcd database.

[0174] Step S54: After service registration, the first authentication module and the first authorization module in the first authentication and authorization module of the first cluster use a watch mechanism to monitor the RBAC rules in the Etcd database. When a change is detected in the RBAC rules in the Etcd database, such as updating the RBAC rules in the Etcd database, the updated RBAC rules are read from the Etcd database and the locally stored RBAC rules are updated.

[0175] Step S55: After service registration, the second authentication and authorization modules in the second authentication and authorization modules of the second cluster are used to monitor the RBAC rules in the Etcd database through a watch mechanism. When a change in the RBAC rules in the Etcd database is detected, such as updating the RBAC rules in the Etcd database, the updated RBAC rules are read from the Etcd database and the locally stored RBAC rules are updated.

[0176] The embodiments of this application have the following beneficial effects: By using a public / private key encryption mechanism to protect service registration information, the security of service registration information is ensured throughout the communication process, effectively preventing data leakage and tampering. Cross-cloud platform authentication and authorization are supported, applicable to various cloud environments, improving system compatibility and scalability. RBAC rules and a context-aware adaptive authorization mechanism are introduced to achieve more precise access control. User permissions can be dynamically adjusted based on contextual information such as the time of request initiation, geographical location, and device used, thereby reducing manual intervention and improving system response efficiency and judgment accuracy. Service proxies are dynamically generated at runtime, which improves the execution efficiency of service calls and enhances the scalability and fault tolerance of the entire system. Through the load balancing strategy of the authentication and authorization center module and the listening mechanism of the service management (Server Manager) module, efficient service discovery and service request distribution can be achieved.

[0177] Embodiments of this application provide an electronic device, which may include: Memory is used to store executable instructions or computer programs. When a processor executes computer-executable instructions or computer programs stored in memory, it implements one or more of the microservice management methods provided in the embodiments of this application.

[0178] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. This electronic device can be applied to... Figure 2 In a corresponding embodiment, a microservice management method is provided. For example... Figure 8 As shown, the electronic device 800 may include a processor 801, a memory 802, and a bus system 803. The various components in the electronic device 800 are coupled together via the bus system 803. Wherein: Bus system 803 is used to realize the communication connection between processor 801 and memory 802; Memory 802 is used to store computer-executable instructions or computer programs; When the processor 801 executes computer-executable instructions or computer programs stored in the memory 802, it implements the microservice management method in one or more exemplary embodiments described above.

[0179] In some exemplary embodiments, the bus system 803 may include, in addition to a data bus, a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity, in... Figure 8 The general labeled all buses as Bus System 803.

[0180] In some exemplary embodiments, the electronic device may also include a server (such as a standalone physical server), or a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services, etc.

[0181] In some exemplary embodiments, the processor may be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor may be a microprocessor or any conventional processor, etc.

[0182] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the microservice management method provided in this application can be implemented. For example, ... Figure 2 The microservice management method is shown.

[0183] This application provides a computer program product, which includes a computer program or computer-executable instructions. When the computer-executable instructions or the computer program are executed by a processor, the microservice management method provided in this application can be implemented. For example, ... Figure 2 The microservice management method is illustrated. For example, the computer program or computer-executable instructions are stored in a computer-readable storage medium, the processor of the electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium, and the processor executes the computer program or computer-executable instructions, causing the electronic device to perform the microservice management method provided in the embodiments of this application.

[0184] In some exemplary embodiments, the aforementioned computer-readable storage medium / memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; or it may be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0185] In some embodiments, a computer program or computer-executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0186] As an example, a computer program or computer-executable instructions may, but not necessarily, correspond to a file in a file system. It may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0187] As an example, a computer program or computer-executable instructions may be deployed to execute on one electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected by a communication network.

[0188] It should be noted that the descriptions of the above device, storage medium, or product embodiments are similar to the descriptions of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device, storage medium, or product embodiments of this application, those skilled in the art should refer to the descriptions of the method embodiments of this disclosure for understanding. Further details will not be repeated here.

[0189] The features disclosed in the several methods, devices, storage media, or product embodiments provided in this application can be arbitrarily combined to obtain new method embodiments, devices, storage media, or product embodiments without conflict. The above descriptions are merely embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A microservice management method, characterized in that, A first authentication and authorization module is applied in a first cluster, the first cluster further comprising: a first microservice and a distributed key-value database, the first authentication and authorization module being associated with the first microservice, the method comprising: If a second microservice in a second cluster is registered in the distributed key-value database, a first resource request for the second microservice is obtained from the first client. Authentication and authorization are performed based on the first identity information carried in the first resource request; When authentication and authorization are successful, the first resource request is sent to the second authentication and authorization module associated with the second microservice in the second cluster based on the first Uniform Resource Locator carried in the first resource request, so that the second authentication and authorization module can send the first resource request to the second microservice after successful authentication and authorization.

2. The method according to claim 1, characterized in that, The authentication and authorization based on the first identity information carried in the first resource request includes: Based on the first identity information, perform identity authentication; When identity authentication is successful, the corresponding user role is determined based on the first identity information; Based on the user roles and the role-based access control rules pre-stored in the distributed key-value database, permission verification is performed. When the permission verification is successful, the authentication and authorization are confirmed to be successful.

3. The method according to claim 1, characterized in that, The method further includes: When a change is detected in the distributed key-value database, the service registration information added or updated by the second authentication and authorization module to the distributed key-value database is obtained. Based on the newly added or updated service registration information, a service proxy corresponding to the second microservice is generated.

4. The method according to claim 3, characterized in that, The step of sending the first resource request to the second authentication and authorization module associated with the second microservice in the second cluster based on the first Uniform Resource Locator carried in the first resource request includes: Based on the first Uniform Resource Locator, the target service proxy is determined; The first resource request is sent to the second authentication and authorization module through the target service proxy.

5. The method according to claim 1, characterized in that, The method further includes: If the first microservice is registered in the distributed key-value database, a second resource request for the first microservice is obtained from the second client. Authentication and authorization are performed based on the second identity information carried in the second resource request; When authentication and authorization are successful, the second resource request is sent to the first microservice based on the second Uniform Resource Locator carried in the second resource request, so that the first microservice can process the second resource request.

6. The method according to claim 5, characterized in that, The method further includes: Obtain the configuration file corresponding to the first microservice; Obtain the service configuration information corresponding to the first microservice from the configuration file corresponding to the first microservice; Based on the service configuration information corresponding to the first microservice, generate the service registration information corresponding to the first microservice; Send the service registration information corresponding to the first microservice to the distributed key-value database; Based on the service registration information corresponding to the first microservice, a service proxy corresponding to the first microservice is generated.

7. A microservice management method, characterized in that, A second authentication and authorization module applied in a second cluster, the second authentication and authorization module being associated with a second microservice in the second cluster, the method comprising: When the second microservice is registered with the distributed key-value database in the first cluster, the second authentication and authorization module receives the first resource request for the second microservice sent by the first authentication and authorization module in the first cluster after successful authentication and authorization. Authentication and authorization are performed based on the first identity information carried in the first resource request; When authentication and authorization are successful, the first resource request is sent to the second microservice based on the first Uniform Resource Locator carried in the first resource request.

8. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method as described in any one of claims 1 to 6, or the method as described in claim 7.

9. A computer-readable storage medium storing a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by a processor, they implement the method as described in any one of claims 1 to 6, or the method as described in claim 7.

10. A computer program product comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by a processor, they implement the method as described in any one of claims 1 to 6, or the method as described in claim 7.

Images