A service calling method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of communication, in particular to a service calling method and device, electronic equipment and storage medium, to improve the service calling efficiency of multiple micro-service running environments, wherein the method comprises the following steps: an API gateway receives an access request sent by a service caller and forwards the access request to a corresponding service publisher; the API gateway receives a response message returned by the service publisher and forwards the response message to the service caller, wherein the response message is generated by the service publisher after receiving the access request sent by the API gateway. Since the API gateway is used as a bridge between the service caller and the service publisher in the application, the API gateway is used for realizing unified management and adaptation of micro-service calling, so that additional development is not needed to adapt to different environments, the complexity of system development is reduced, and the service calling efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a service invocation method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rise of microservices, more and more organizations are developing their self-developed services using frameworks based on microservices. However, for organizations entering the era of digital transformation, the integration and unified governance of services across different operating environments has become an essential step in their digital transformation. Currently, vendors in the market only focus on the service registration and invocation process within their self-developed microservice frameworks, without considering the issues of inter-microservice invocation across multiple microservice operating environments and the relationship between microservices and ordinary binary services.

[0003] In summary, when services from different microservice runtime environments call each other, they need to be called according to the requirements of the other party's components, which brings additional adaptation development work, is complex to implement, and has low efficiency. Summary of the Invention

[0004] This application provides a service invocation method, apparatus, electronic device, and storage medium to improve the efficiency of service invocation between multiple microservice runtime environments.

[0005] The first service invocation method provided in this application embodiment includes:

[0006] The API (Application Programming Interface) gateway receives access requests sent by service callers and forwards the access requests to the corresponding service publishers.

[0007] The API gateway receives the response message returned by the service publisher and forwards the response message to the service caller, wherein the response message is generated by the service publisher after receiving the access request sent by the API gateway.

[0008] The second service invocation method provided in this application embodiment includes:

[0009] The service caller obtains the access address of the service publisher and sends an access request to the API gateway based on the access address, so that the API gateway forwards the access request to the service publisher.

[0010] The service caller receives a response message returned by the API gateway, wherein the response message is generated by the service publisher based on the access request.

[0011] In one optional implementation, sending an access request to the API gateway based on the access address includes:

[0012] When the service caller and the service publisher have the same microservice runtime environment, the service caller sends the access request to the API gateway through the authentication method corresponding to the microservice runtime environment; or

[0013] When the microservice runtime environment of the service caller and the service publisher are different, the service caller sends the access request to the API gateway through the authentication method corresponding to the API gateway.

[0014] The third service invocation method provided in this application includes:

[0015] The service publisher receives an access request sent by the API gateway, wherein the access request is sent by the service caller to the API gateway;

[0016] The service publisher generates a response message based on the access request and sends the response information to the API gateway, so that the API gateway forwards the response message to the service caller.

[0017] Optionally, sending the response information to the API gateway includes:

[0018] The service publisher sends the response information to the API gateway using the authentication method corresponding to its microservice runtime environment.

[0019] The first service invocation device provided in this application embodiment includes:

[0020] The first forwarding unit is used to receive access requests sent by service callers and forward the access requests to the corresponding service publishers.

[0021] The second forwarding unit is used to receive the response message returned by the service publisher and forward the response message to the service caller, wherein the response message is generated by the service publisher after receiving the access request sent by the API gateway.

[0022] In one optional implementation, the first forwarding unit is specifically used for:

[0023] The access request is forwarded to the service publisher using the authentication method corresponding to the microservice runtime environment where the service publisher is located.

[0024] In one optional implementation, the second forwarding unit is specifically used for:

[0025] When it is confirmed that the microservice runtime environment of the service caller and the service publisher is the same, the response message is forwarded to the service caller through the authentication method corresponding to the microservice runtime environment; or

[0026] When it is confirmed that the microservice runtime environment of the service caller and the service publisher are different, the response message is forwarded to the service caller through the authentication method corresponding to the API gateway.

[0027] The second service invocation device provided in this application embodiment includes:

[0028] An access unit is used to obtain the access address of the service publisher and send an access request to the API gateway based on the access address, so that the API gateway forwards the access request to the service publisher.

[0029] A receiving unit is configured to receive a response message returned by the API gateway, wherein the response message is generated by the service publisher based on the access request.

[0030] In one optional implementation, the access unit is specifically used for:

[0031] When the service caller and the service publisher have the same microservice runtime environment, the access request is sent to the API gateway through the authentication method corresponding to the microservice runtime environment; or

[0032] When the microservice runtime environment of the service caller and the service publisher are different, the access request is sent to the API gateway through the authentication method corresponding to the API gateway.

[0033] The third service invocation device provided in this application embodiment includes:

[0034] A response unit is used to receive an access request sent by the API gateway, wherein the access request is sent by the service caller to the API gateway;

[0035] The sending unit is configured to generate a response message based on the access request and send the response information to the API gateway, so that the API gateway forwards the response message to the service caller.

[0036] In one optional implementation, the transmitting unit is specifically used for:

[0037] The response information is sent to the API gateway using the authentication method corresponding to the microservice runtime environment where the service caller is located.

[0038] An electronic device provided in this application includes a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor performs the steps of any of the above-described service invocation methods.

[0039] This application provides a computer-readable storage medium including program code. When the program product is run on an electronic device, the program code is used to cause the electronic device to perform the steps of any of the above-described service invocation methods.

[0040] The beneficial effects of this application are as follows:

[0041] This application provides a service invocation method, apparatus, electronic device, and storage medium. Since all service invocation processes in this application embodiment pass through an API gateway, the API gateway acts as a bridge between the service invoker and the service publisher, enabling service integration. The API gateway achieves unified management and adaptation of microservice invocations, eliminating the need for additional development to adapt to different environments, reducing system development complexity, and improving service invocation efficiency. Furthermore, it achieves the goal of shielding differences in R&D technologies, realizing unified management of organizational applications, and accelerating the organization's digital transformation process.

[0042] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0043] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0044] Figure 1A This is a schematic diagram of a microservice framework in an embodiment of this application;

[0045] Figure 1B This is a schematic diagram of another microservice framework in the embodiments of this application;

[0046] Figure 2 This is a schematic diagram illustrating one application scenario in an embodiment of this application;

[0047] Figure 3 This is a schematic diagram of the first user interface in the embodiments of this application;

[0048] Figure 4 This is a schematic diagram of a second user interface in an embodiment of this application;

[0049] Figure 5 This is a schematic diagram of the first service invocation method in the embodiments of this application;

[0050] Figure 6 This is a schematic diagram of an optional interactive implementation timing process in an embodiment of this application;

[0051] Figure 7 This is a schematic diagram of another optional interactive implementation timing process in an embodiment of this application;

[0052] Figure 8A This is a schematic diagram illustrating an internal call within a microservice runtime environment as described in an embodiment of this application.

[0053] Figure 8B This is a schematic diagram illustrating a call between different microservice runtime environments in an embodiment of this application;

[0054] Figure 9 This is a schematic diagram of the second service invocation method in the embodiments of this application;

[0055] Figure 10 This is a schematic diagram of the third service invocation method in the embodiments of this application;

[0056] Figure 11 This is a sequence diagram of the registration and invocation logic of a centralized control platform registration center in one embodiment of this application;

[0057] Figure 12 This is a schematic diagram of the first type of service invocation device in the embodiments of this application;

[0058] Figure 13 This is a schematic diagram of the second type of service invocation device in the embodiments of this application;

[0059] Figure 14 This is a schematic diagram of the third service invocation device in the embodiments of this application;

[0060] Figure 15 This is a schematic diagram of the composition structure of an electronic device according to an embodiment of this application;

[0061] Figure 16 This is a schematic diagram of the hardware structure of a computing device according to an embodiment of this application. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments of this application. Obviously, the described embodiments are only some embodiments of the technical solutions of this application, and not all embodiments. Based on the embodiments recorded in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the technical solutions of this application.

[0063] The following describes some of the concepts involved in the embodiments of this application.

[0064] 1. Microservices refer to the development of multiple independent, small services with complete business functions, such as many small applications broken down from a system. Each service has its own processing and communication mechanism and can be deployed on different servers or on different containers of the same server. Microservices need to run under a microservice framework, such as Spring Cloud (an ordered collection of frameworks) or Kubernetes+Istio (an open-source microservice framework). Therefore, Spring Cloud and Kubernetes+Istio are both considered microservice runtime environments in the embodiments of this application.

[0065] 2. Ordinary binary services emphasize the entire system or application. Ordinary binary services can be deployed in any environment and do not depend on a microservice framework. In the embodiments of this application, the mutual calls between ordinary binary services and microservices also fall under the category of service calls between different microservice runtime environments.

[0066] 3. Centralized Control Platform: This platform focuses on the unified integration of user identity, applications and services, and network access control, assisting governments and large enterprises in promoting digital transformation. In this embodiment, it includes several systems, primarily a portal management system, a registration center, and related API gateways. The portal management system is used by administrators to manage services and write services to the registration center. The registration center handles unified service registration and updates. The related API gateways facilitate inter-service calls between multiple runtime environments.

[0067] 4. An API gateway is a server and the sole entry point to the system. From an object-oriented design perspective, it's similar to the facade pattern. The API gateway encapsulates the system's internal architecture, providing a customized API for each client. It may also have other responsibilities such as authentication, monitoring, load balancing, caching, request sharding and management, and static response processing.

[0068] In this application's embodiments, the API gateway is divided into a centralized control platform-related API gateway and a microservice API gateway. The centralized control platform-related API gateway, as described in the claims of this application, is primarily used to facilitate inter-service calls between multiple microservice runtime environments, acting as a bridge between microservices. All calls between multiple microservices are managed uniformly through the centralized control platform-related API gateway. The microservice API gateway refers to the microservice runtime environment, which can be categorized into two types: with and without a microservice API gateway. When a microservice API gateway is present, it primarily connects clients or consumers to the microservices through a unified entry point.

[0069] 5. Service invocation refers to a microservice needing to access other microservices. This can be divided into two types: 1) Invocation between services within the same microservice runtime environment; 2) Invocation between services within a microservice runtime environment needing to access services in other runtime environments. For example, different departments within the same organization may have purchased different microservice frameworks, but these departments may need to call each other; or, IT (Internet Technology) personnel in different departments may have varying technical capabilities and use different service development frameworks; or, a single department may need to build different microservice runtime environments to differentiate between production, development, and sensitive environments. All of these situations require service invocation between different microservice runtime environments.

[0070] 6. Service caller refers to the party that needs to access other services during the service call process; it can also be called the service consumer. For example, when APP1 needs to access APP2, APP1 is the service caller.

[0071] 7. Service publisher refers to the party that needs to be accessed by other services during the service call process; it can also be called the service provider. For example, when APP1 needs to access APP2, APP2 is the service publisher.

[0072] 8. Cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to realize the computing, storage, processing, and sharing of data.

[0073] Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0074] The design concept of the embodiments of this application is briefly introduced below:

[0075] Currently, internet companies' systems typically consist of numerous subsystems providing different functions, all built using a microservices architecture. Below, we introduce microservice API gateways in two common microservice frameworks:

[0076] Zuul is an API gateway component that provides a framework for edge services such as authentication, authorization, rate limiting, dynamic routing, monitoring, resilience, security, load balancing, assisting with single-point stress testing, and static response. Most of Zuul's functionality is implemented through filters. Its core is a series of filters that participate in filtering processes as Zuul routes requests to user processing logic, ultimately forwarding the requests to the microservices.

[0077] like Figure 1A The diagram illustrates the lifecycle of a Zuul request according to an embodiment of this application. It details the execution order of various filter types, which differ depending on the filter type and perform different functions. Specifically, `pre` is called before the request is routed, enabling functions such as log monitoring, authentication, and blacklisting; `routing` is called during request routing to construct the request sent to the microservice and request the microservice; `post` is called after the `routing` and `error` filters, enabling functions such as auditing and statistics; and `error` is called when an error occurs during request processing, enabling unified exception handling. Furthermore, Zuul also includes custom filters.

[0078] Second, Kong is another API gateway component, and its principle is similar to Zuul, such as... Figure 1BThe features shown can be used for authentication, caching, monitoring, call rate limiting, login, security, access control lists, and more. It offers a large number of plugins to extend applications, and by configuring different plugins, various enhanced functionalities can be provided to the service.

[0079] While Zuul and Kong can provide capabilities such as access control, security, load balancing, request distribution, and monitoring within the corresponding microservice runtime environment, these components, whether Zuul, Kong, or other microservice framework gateways, all share the following issues:

[0080] 1. The components are basically only concerned with the traffic flowing into the API gateway component to protect their own services. If a service inside a certain microservice runtime environment needs to access services in other microservice runtime environments, then the service needs to call according to the requirements of the other party's component, including the access method and the call authentication method, which brings additional adaptation and development work.

[0081] 2. If an organization has multiple microservice runtime environments, the current components cannot provide a unified management platform for management, thus failing to achieve the goal of unified organizational management. For example, if there are both production and testing environments, two separate system deployments need to be maintained. Alternatively, if different microservice runtime environments exist simultaneously, applications or services also need to be maintained on different platforms.

[0082] In view of this, embodiments of this application provide a service invocation method, apparatus, electronic device, and storage medium. A centralized control platform provides a registration center and service synchronization consistent with the registration methods provided by current mainstream microservice runtime environments. First, the registration center of the centralized control platform achieves unified registration or updating of services. Then, an API gateway enables mutual invocation of microservices in different runtime environments. In this embodiment, the API gateway acts as a bridge in the service invocation process; invocations between multiple microservices are uniformly managed through the API gateway. For the service invoker, it is only necessary to confirm that the service to be invoked is in a specific environment; no additional development is needed to adapt to different microservice runtime environments. For the service publisher, it is only necessary to confirm the authentication method and invocation format of the published service; authentication for other environments is uniformly converted and adapted by the API gateway. Therefore, multiple microservice runtime environments and ordinary binary services can be integrated, achieving the goal of shielding differences in development technologies, realizing unified management of organizational applications, and accelerating the organization's digital transformation process.

[0083] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0084] See Figure 2 As shown, it is a schematic diagram of an application scenario provided by an embodiment of this application. Figure 2 The application scenarios shown include centralized control platforms and internal systems. Furthermore, organizations can deploy multiple runtime environments based on partner requirements, such as regular servers, Spring Cloud runtime environments, and Kubernetes + Istio runtime environments. These environments can be further categorized into production environments, testing environments, and sensitive environments. Figure 2 The application scenarios shown include Spring Cloud runtime environment and K8S+Istio runtime environment.

[0085] In this embodiment, a centralized control platform allows services developed based on Spring Cloud or Kubernetes to maintain their registration method. Once a service starts in a specific microservice runtime environment, the registration center of the centralized control platform automatically synchronizes the service to the platform. Backend services automatically connect to the API gateway, which supports cross-network service calls and provides APIs with capabilities such as data format conversion, encryption / decryption, overload protection, and secondary verification. Therefore, the centralized control platform enables the integration of different microservice runtime environments, allowing microservices in different runtime environments to register and call services while maintaining their original service registration method.

[0086] It should be noted that the API gateway is a server. In this embodiment, the server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and the server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0087] Optionally, the administrator can use the portal management system of the centralized control platform to perform unified maintenance of all services. For example, the administrator can log in to the portal management system and find all services directly registered on it through the corresponding system; or they can view the registration status of a microservice through the corresponding microservice runtime environment.

[0088] like Figure 3The diagram shown illustrates a UI (User Interface) provided in an embodiment of this application, through which a list of all services can be viewed. For example, an administrator can register a new service by clicking the "Create Service" button shown in the diagram, and view the registered services through the "My Services" section, which specifically includes information such as service name, service identifier, visibility, service deployment region, status, authorized application, and operations.

[0089] by Figure 3 Taking a service as an example, the service name is: Spring Cloud Service Example, and the service identifier is: Spring Cloud Demo. Service visibility is a parameter registered on the centralized control platform. Only services set to public can be called by other applications. Therefore, a public service means that the service can be called by other applications. The service deployment area is the Spring Cloud environment, and the status is: Approved. This is a status of the service registration on the centralized control platform. After registration, the service needs administrator approval before it can be officially activated.

[0090] In addition, the organization administrator can perform unified CRUD operations, which greatly reduces the administrator's maintenance costs.

[0091] See Figure 4 The diagram shown is another UI illustration provided in an embodiment of this application. The diagram mainly displays basic service information and service details. The basic information specifically includes: service name, service identifier, service description, service tag, public path, visibility, load balancing, and global configuration. Service details specifically include the service deployment region, etc.

[0092] The service description refers to the descriptive information provided when a service is published. This description, which can be filled in by the publisher, explains the purpose of the service. For example... Figure 4 The service shown is named "Spring Cloud Service Example" and its service description is "Validate Service Fusion Process," indicating that this service is an example created to validate the service fusion process.

[0093] Furthermore, it should be noted that the public path of the service in this embodiment is the path actually made visible to other applications. Some system administrators may use the public path to hide the service's actual path when they do not want other applications to see it. The original path in the global configuration, however, is the actual path where the original service is deployed, and is the actual address the API gateway uses to forward requests.

[0094] See Figure 5The diagram shown is an implementation flowchart of the first service invocation method provided in this application embodiment, applied to an API gateway. The specific implementation flow of this method is as follows:

[0095] S51: The API gateway receives access requests sent by service callers and forwards the access requests to the corresponding service publishers; where the API gateway refers to the API gateway related to the centralized control platform.

[0096] Optionally, when the API gateway forwards an access request to the corresponding service publisher, the specific process is as follows:

[0097] Regardless of whether the microservice runtime environments of the service caller and the service publisher are the same, the access request is forwarded to the service publisher through the authentication method corresponding to the microservice runtime environment of the service publisher.

[0098] In other words, it achieves the integration of different microservice runtime environments, allowing services in different environments to register and be invoked while maintaining their original service registration methods. Services registered in Spring Cloud or Kubernetes via the API gateway of the centralized control platform are used according to the authentication method of the centralized control platform; when invoking services from Spring Cloud or Kubernetes, they can be accessed according to the original environment's invocation method. The following example... Figure 6 and Figure 7 The following example illustrates the point:

[0099] In this embodiment, the microservice runtime environment can be divided into two forms: one with a microservice API gateway and the other without. In these two cases, the authentication methods corresponding to the microservice runtime environment are different.

[0100] Specifically, for microservice runtime environments without a microservice API gateway, the corresponding authentication method is the original authentication method of the microservice runtime environment. Taking Spring Cloud as an example, the authentication method of the microservice runtime environment is the Spring Cloud authentication method. See details... Figure 6 As shown, the Spring Cloud microservice runtime environment does not have a microservice API gateway.

[0101] Taking the example where the microservices of the service consumer and the service publisher run in the same environment, for example... Figure 6 As shown, when APP2, which is located in the Spring Cloud microservice runtime environment, accesses APP3, the service caller A is APP2, and the service publisher B is APP3. Both APP2 and APP3 are located in the Spring Cloud microservice runtime environment. The API gateway related to the centralized control platform uses Spring Cloud authentication to send the access request to APP3.

[0102] Taking the example of different microservice runtime environments between the service consumer and the service publisher, for example... Figure 6 As shown, when APP1, located in a normal binary service environment, accesses APP2, located in a Spring Cloud microservice runtime environment, the service caller is APP1 and the service publisher is APP2. Since APP1 and APP2 are located in different microservice runtime environments, the API gateway related to the centralized control platform uses Spring Cloud authentication to send the access request to APP2.

[0103] For microservice runtime environments with a microservice API gateway, the corresponding authentication method is the microservice API gateway authentication method. See details... Figure 7 As shown, the Spring Cloud microservice runtime environment includes a microservice API gateway.

[0104] Taking the example where the microservices of the service consumer and the service publisher run in the same environment, for example... Figure 7 As shown, when APP2 accesses APP3, the API gateway related to the centralized control platform uses the microservice API gateway authentication method to send the access request to APP3. Specifically, the access request forwarded by the API gateway related to the centralized control platform first passes through the microservice API gateway in Spring Cloud, and then to APP3.

[0105] For example Figure 7 As shown, when APP1 accesses APP2, the API gateway related to the centralized control platform uses the microservice API authentication method to send the access request to APP2.

[0106] S52: The API gateway receives the response message returned by the service publisher and forwards the response message to the service caller. The response message is generated by the service publisher after receiving the access request sent by the API gateway.

[0107] Optionally, the API gateway related to the centralized control platform will forward the response message to the service caller, which can be done in the following two ways:

[0108] Method 1: When the API gateway confirms that the microservice runtime environment of the service caller and the service publisher is the same, it forwards the response message to the service caller through the authentication method corresponding to the microservice runtime environment.

[0109] For microservice runtime environments without a microservice API gateway, the approach remains the same. Figure 6 As shown in the example, when APP2 accesses APP3, the API gateway related to the centralized control platform forwards the response message to APP2 through Spring Cloud authentication.

[0110] For microservice runtime environments with microservice API gateways, the approach remains the same. Figure 7 For example, the API gateway forwards the access request to APP3 through microservice API authentication. Specifically, the response message forwarded to APP2 by the API gateway related to the centralized control platform does not directly reach APP2, but first passes through the microservice API gateway in Spring Cloud, and then is forwarded to APP2 by the microservice API gateway.

[0111] Method 2: When the API gateway confirms that the microservice runtime environments of the service caller and the service publisher are different, it forwards the response message to the service caller through the authentication method corresponding to the API gateway.

[0112] Still with Figure 6 As shown in the example, when APP1 accesses APP2, the API gateway uses the API gateway authentication method related to the centralized control platform to forward the response message to APP1.

[0113] In the above implementation, when a service registered in a microservice runtime environment such as Spring Cloud or Kubernetes is called through the API gateway, it is used according to the authentication method of the centralized control platform. When a service in a microservice runtime environment such as Spring Cloud or Kubernetes initiates a service call, it can be accessed according to the original environment's calling method. All calling processes pass through the API gateway related to the centralized control platform. The organization can uniformly manage and approve all services within the organization, and can also view the operation monitoring logs in a unified way or externally.

[0114] In this embodiment, for a microservice runtime environment, the service call implementation process is similar for both methods with and without a microservice API gateway. The only difference lies in whether the centralized control platform adapts to the authentication method of the microservice API gateway or the microservice's original authentication method when the service actually initiates the call. The following example uses the method without a microservice API gateway. Figure 6 The operation process of service invocation in the embodiments of this application is described in detail:

[0115] Figure 6 This is a service call diagram provided for an embodiment of this application. The diagram includes: a Spring Cloud framework without a microservice API gateway, three applications (APP1, APP2, and APP3), and a centralized control platform.

[0116] It should be noted that Figure 6This document describes the process of implementing microservice calls in Spring Cloud applications through a centralized control platform. It should be noted that this method is also applicable to Kubernetes (K8S). The process can be mainly divided into three parts: deployment, service registration, and service invocation. These three parts will be described in detail below.

[0117] I. Deployment Process:

[0118] First, a centralized control platform and registry center are deployed within the organization, using Spring Cloud as the microservice runtime environment. Then, Spring Cloud is deployed throughout the organization, and its registry center is configured to be the same as the one provided by the centralized control platform, facilitating unified service registration.

[0119] Specifically, you can configure the Spring Cloud service registry to be provided by the centralized control platform by changing the Consul address (a tool for service discovery) of your Spring Cloud application to the domain name of the centralized control platform. For example, you can modify the Spring Cloud configuration files application.yml or bootstrap.yml to configure the registry. Consul is a service registration component of Spring Cloud used to manage services enabled in Spring Cloud.

[0120] II. Registration Service:

[0121] Taking APP1, APP2, and APP3 as examples, assume that APP1 is deployed on a regular server, while APP2 and APP3 are deployed in a Spring Cloud microservice runtime environment. Since a regular server can be deployed in any environment, when deploying APP1, the service can be directly registered through the portal management system. The specific process is as follows: the service address of APP1 is generated in the API gateway, and the service is written into the registry center.

[0122] For APP2 and APP3, the services are started using Spring Cloud and registered with Spring Cloud. Since the Spring Cloud registry is pre-configured as the registry provided by the centralized control platform, the services are already registered with the centralized control platform registry at this time.

[0123] In the above implementation, unified registration and management of services under different microservice operating environments can be achieved, enabling the integration of ordinary binary services and microservices, so that when Spring Cloud or Kubernetes initiates a service call, it can be accessed according to the original environment's calling method.

[0124] It should be noted that the gray part in the figure represents the default calling method supported by Spring Cloud internal microservice calls in related technologies. In this embodiment, after the calling method is managed by the centralized control platform through the service registration process, this method is no longer used. Instead, the service calling method in the dashed box in the third part is adopted, which will be described in detail below.

[0125] III. Service Invocation Process:

[0126] In this application embodiment, based on the deployment of the microservice runtime environment, it can be specifically divided into service calls within the same microservice runtime environment and service calls within different microservice runtime environments, which are illustrated below.

[0127] 1. Service calls within the same microservice runtime environment.

[0128] For example, consider the call between APP2 and APP3 within Spring Cloud. Assume the service caller A is APP2 and the service publisher B is APP3. When service caller A (APP2) initiates a request, the request is forwarded to service publisher B (APP3) through the API gateway. At this point, the API gateway automatically adapts to the original calling methods of both the service publisher and the service caller. If there was no verification process previously, it transparently forwards the request and provides protection mechanisms such as load balancing and traffic control. Figure 8A As shown.

[0129] in, Figure 8A The Consul shown is a service registration component of Spring Cloud, used to manage services enabled in Spring Cloud, namely APP2 and APP3 in this embodiment. The dotted line represents a normal Spring Cloud environment call process, which is the way services are called in the same microservice runtime environment in related technologies. The specific service call process is as follows: Service caller A obtains the IP address (Internet Protocol) of the service publisher from Consul. Based on the IP list returned by Consul, service caller A directly accesses service publisher B according to the IP address.

[0130] The solid line represents the centralized control platform registry center invocation process provided in this application embodiment. The specific service invocation process is as follows: Service caller A first obtains the domain name assigned during registration from the registry center through the service fusion acquisition method, and then accesses service publisher B through the API gateway via the service fusion access method.

[0131] It should be noted that, in reality, the usage of the dashed and solid lines is exactly the same. Service caller A is unaware of the existence of the centralized control platform. Therefore, service caller A's calls to all applications within the microservice are based on the original usage, including consistent input and return parameters. This ensures that the original service is not affected.

[0132] 2. Service calls between different microservice runtime environments, such as mutual calls between other environments (ordinary binary service environment) and Spring Cloud services.

[0133] For example Figure 8B As shown, assume the service caller C is APP1 and the service publisher D is APP2. First, service caller C (APP1) checks the access address of service publisher D (APP2) from the portal management system and accesses it through the signature of the API gateway related to the centralized control platform. After receiving the access request from service caller A, the API gateway, based on the fact that the access address is a service ID (Identity) rather than a service domain name, confirms that the actual access request is from the microservice runtime environment. Therefore, the API gateway looks up the address corresponding to the service ID in the registry center. Further, based on the address corresponding to the found service ID in the registry center, the API gateway forwards the access request to service publisher D within the microservice runtime environment.

[0134] The service ID refers to the service ID published within the microservice runtime environment. All applications within the microservice runtime environment will register a service ID when they start up.

[0135] In the above implementation, the signature access of the API gateway is the authentication method corresponding to the API gateway. API gateway authentication is only required for ordinary binary service environments to initiate service calls within the microservice runtime environment. It is used to protect the callee and determine that the request initiated is genuine and valid.

[0136] It should be noted that, Figure 7 That is, the service call process when the microservice runtime environment has a microservice API gateway, and Figure 6 The only difference is that Spring Cloud authentication is no longer used; instead, the microservice API gateway authentication method is used.

[0137] In one alternative implementation, the API gateway can determine whether the microservice runtime environments of the service caller and the service publisher are the same by means of the following methods.

[0138] Specifically, the API gateway determines the service publisher's runtime environment based on the address information obtained by the service caller. If the address is the API gateway domain name, it confirms that the service caller and the service publisher have the same microservice runtime environment. If the address is a service ID instead of the API gateway domain name, it confirms that the service caller and the service publisher have different microservice runtime environments; the service publisher is located in a microservice runtime environment, while the service publisher is located in a regular binary service environment. With this approach, the service caller only needs to obtain the service publisher's address information from the portal management system or registry center, eliminating the need for additional development to adapt to different microservice runtime environments.

[0139] It should be noted that the above implementation method is only one way to determine the microservice operating environment listed in the embodiments of this application. Other determination methods are also applicable to the embodiments of this application and are not specifically limited here.

[0140] See Figure 9 The diagram shown is an implementation flowchart of the second service invocation method provided in this application embodiment, applied to the service invoker. The specific implementation flow of this method is as follows:

[0141] S91: The service caller obtains the access address of the service publisher and sends an access request to the API gateway based on the access address, so that the API gateway forwards the access request to the service publisher.

[0142] Optionally, when a service consumer obtains the access address of a service publisher, it can do so through a registry center or portal management system, such as... Figure 8A or Figure 8B As shown, in a normal binary service environment, service caller C can directly find the public path of service publisher D from the portal management system and then call it without going through the registration center.

[0143] In one alternative implementation, the service caller sends an access request to the API gateway based on the access address, which can be divided into the following two methods:

[0144] Method 1: When the microservice runtime environment of the service caller and the service publisher is the same, the service caller sends an access request to the API gateway through the authentication method corresponding to the microservice runtime environment.

[0145] For microservice runtime environments without a microservice API gateway, the approach remains the same. Figure 6 As shown in the example, when APP2 accesses APP3, APP2 uses Spring Cloud authentication to send the access request to the relevant API gateway of the centralized control platform.

[0146] For microservice runtime environments with microservice API gateways, the approach remains the same. Figure 7 As shown in the example, when APP2 accesses APP3, APP2 uses the microservice API gateway authentication method to send the access request to the API gateway. Specifically, the access request sent by APP2 needs to be sent through the microservice API gateway in Spring Cloud to the relevant API gateway of the centralized control platform.

[0147] Method 2: When the microservice runtime environments of the service caller and the service publisher are different, the service caller sends an access request to the API gateway through the authentication method corresponding to the API gateway.

[0148] Still with Figure 6 For example, when APP1, located in a normal binary service environment, accesses APP2, located in a Spring Cloud microservice runtime environment, APP1 sends the access request to the API gateway using the API gateway authentication method related to the centralized control platform.

[0149] It should be noted that the authentication of the microservice API gateway occurs between the API gateway related to the centralized control platform and the application within the microservice runtime environment, and is unrelated to the application in the ordinary binary service environment.

[0150] S92: The service caller receives a response message returned by the API gateway, where the response message is generated by the service publisher based on the access request.

[0151] In the above implementation, the service caller only needs to be concerned with the service being called in a specific environment; there is no need to perform additional development to adapt to different environments. This reduces the organization's maintenance costs while shielding its partners / developers from technical differences, saving development time and procurement adaptation costs.

[0152] See Figure 10 The diagram shown is an implementation flowchart of the third service invocation method provided in this application embodiment, applied to the service publisher. The specific implementation flow of this method is as follows:

[0153] S101: The service publisher receives an access request sent by the API gateway, where the access request is sent by the service caller to the API gateway;

[0154] S102: The service publisher generates a response message based on the access request and sends the response information to the API gateway so that the API gateway forwards the response message to the service caller.

[0155] In one alternative implementation, when the service publisher sends the response information to the API gateway, regardless of whether the service caller and the service publisher have the same or different microservice runtime environments, the service publisher sends the response information to the API gateway through the authentication method corresponding to its microservice runtime environment.

[0156] For microservice runtime environments without a microservice API gateway, such as Figure 6 As shown, when APP2, which is located in the Spring Cloud microservice runtime environment, accesses APP3, APP3 uses the Spring Cloud authentication method to send the response message to the API gateway related to the centralized control platform.

[0157] For microservice runtime environments with microservice API gateways, such as Figure 7 As shown, when APP2, which is located in the Spring Cloud microservice runtime environment, accesses APP3, APP3 uses the microservice API authentication method to send the response message through the microservice API gateway to the relevant API gateway of the centralized control platform.

[0158] Or, for example Figure 6 As shown, when APP1, located in a normal binary service environment, accesses APP2, located in a Spring Cloud microservice runtime environment, APP2 uses Spring Cloud authentication to send the response message to the relevant API gateway of the centralized control platform, etc.

[0159] In the above implementation, the service publisher only needs to be concerned with the authentication method and calling format of the published service. The authentication of other environments is uniformly converted and adapted by the API gateway, which reduces the organization's maintenance costs while shielding the organization's partners or developers from technical differences, saving development time and procurement adaptation costs.

[0160] Optionally, in this embodiment, the registration center of the centralized control platform can also support asynchronous and synchronous updates of services.

[0161] For example, if a microservice runtime environment does not use a configuration registry center but instead directly uses Consul, the centralized control platform can support synchronizing services from Consul to the registry center, including full synchronization and synchronization of specified services.

[0162] Full synchronization refers to synchronizing all services to the centralized control platform registration center, while specified service synchronization refers to synchronizing a specific service to the centralized control platform registration center.

[0163] In the above embodiments, by modifying the microservice registry or synchronizing services, the centralized control platform registry can uniformly manage all services, achieving the integration of the ordinary binary service environment and the microservice runtime environment. The microservice runtime environment can continue to operate as before. Therefore, while reducing the organization's maintenance costs, it shields the organization's partners or developers from technical differences, saving development time and procurement adaptation costs.

[0164] See Figure 11 The diagram shown is a sequence diagram of service call interactions within a microservice runtime environment provided in an embodiment of this application. The specific implementation process of this method is as follows:

[0165] Step 1101: Service A calls the interface / agent / service / register to register Service A on the centralized control platform;

[0166] Step 1102: The centralized control platform returns a message to service A indicating that service A has successfully registered;

[0167] Step 1103: Service B calls the interface / agent / service / register to obtain the address of Service A from the centralized control platform;

[0168] Step 1104: The centralized control platform returns the address of service A, A.service..com, to service B;

[0169] Step 1105: Service B sends an access request GET http: / / A.service.rio.com / user / list;

[0170] Step 1106: The centralized control platform forwards the request to service A based on the address A.service.rio.com;

[0171] Step 1107: Service A returns a list of users;

[0172] Step 1108: The centralized control platform forwards the users list to service B.

[0173] The service registration method in step 1101 can be found in the registration service section listed in the above embodiments, and will not be repeated here. In step 1105, GET is used for information retrieval, where *.service.rio.com will resolve the request to the API gateway related to the centralized control platform, and / user / list represents the list of users used to retrieve service A.

[0174] It should be noted that, in this embodiment of the application, the logic of service registration and service discovery is different from the Spring Cloud Consul process (i.e. Figure 8A The dotted line portion shown is completely identical. The only difference is that the address obtained by the service caller based on the service name will no longer be the original IP of the service publisher (target service), but in the form of a domain name, such as serviceid.service.rio.com. This domain name will resolve to the API gateway related to the centralized control platform, and the API gateway will then forward the request to the service publisher's address.

[0175] For example, Figure 11 Service B accesses service A using the domain name A.service.rio.com. All domain names of *.service.rio.com resolve to the API gateway, which then forwards the request to service A.

[0176] See Figure 12 The diagram shown is a structural schematic of the first service invocation device provided in an embodiment of this application. Figure 12 As shown, the service invocation device 1200 may include:

[0177] The first forwarding unit 1201 is used to receive access requests sent by the service caller and forward the access requests to the corresponding service publisher.

[0178] The second forwarding unit 1202 is used to receive the response message returned by the service publisher and forward the response message to the service caller. The response message is generated by the service publisher after receiving the access request sent by the API gateway.

[0179] In one optional implementation, the first forwarding unit 1201 is specifically used for:

[0180] The access request is forwarded to the service publisher using the authentication method corresponding to the microservice runtime environment where the service publisher is located.

[0181] In one optional implementation, the second forwarding unit 1202 is specifically used for:

[0182] When it is confirmed that the microservice runtime environment of the service caller and the service publisher is the same, the response message is forwarded to the service caller using the authentication method corresponding to the microservice runtime environment; or

[0183] When it is confirmed that the microservice runtime environments of the service caller and the service publisher are different, the response message is forwarded to the service caller through the authentication method corresponding to the API gateway.

[0184] See Figure 13The diagram shown is a structural schematic of the second service invocation device provided in an embodiment of this application. Figure 13 As shown, the service invocation device 1300 may include:

[0185] Access unit 1301 is used to obtain the access address of the service publisher and send an access request to the API gateway based on the access address, so that the API gateway forwards the access request to the service publisher.

[0186] The receiving unit 1302 is used to receive the response message returned by the API gateway, wherein the response message is generated by the service publisher based on the access request.

[0187] In one optional implementation, the access unit 1301 is specifically used for:

[0188] When the service caller and the service publisher have the same microservice runtime environment, the access request is sent to the API gateway through the authentication method corresponding to the microservice runtime environment; or

[0189] When the microservice runtime environments of the service caller and the service publisher are different, an access request is sent to the API gateway through the authentication method corresponding to the API gateway.

[0190] See Figure 14 The diagram shown is a structural schematic of the third service invocation device provided in an embodiment of this application. Figure 14 As shown, the service invocation device 1400 may include:

[0191] The response unit 1401 is used to receive an access request sent by the API gateway, wherein the access request is sent by the service caller to the API gateway;

[0192] The sending unit 1402 is used to generate a response message based on the access request and send the response information to the API gateway so that the API gateway forwards the response message to the service caller.

[0193] In one alternative implementation, the transmitting unit 1402 is specifically used for:

[0194] The response information is sent to the API gateway using the authentication method corresponding to the microservice runtime environment where the service publisher is located.

[0195] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0196] After introducing the service invocation method and apparatus of exemplary embodiments of this application, an electronic device according to an exemplary embodiment of this application will be described next.

[0197] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0198] See Figure 15 The diagram shown is a structural schematic of an electronic device according to an embodiment of this application. The electronic device 1500 according to this application may include at least a processor 1501 and a memory 1502, such as... Figure 15 As shown. The memory 1502 stores program code that, when executed by the processor 1501, causes the processor 1501 to perform the steps of the service invocation methods according to various exemplary embodiments of this application described in this specification. For example, the processor 1501 can perform, as... Figure 5 The steps are shown in the figure.

[0199] In some possible implementations, the computing device according to this application may include at least one processing unit and at least one storage unit. The storage unit stores program code that, when executed by the processing unit, causes the processing unit to perform the steps of the service invocation methods according to the various exemplary embodiments of this application described above. For example, the processing unit may perform actions such as... Figure 5 The steps are shown in the figure.

[0200] The following reference Figure 16 To describe a computing device 160 according to this embodiment of the present application. Figure 16 The computing device 160 is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0201] like Figure 16 The computing device 160 is manifested in the form of a general-purpose computing device. The components of the computing device 160 may include, but are not limited to: at least one processing unit 161, at least one storage unit 162, and a bus 163 connecting different system components (including storage unit 162 and processing unit 161).

[0202] Bus 163 represents one or more of several bus structures, including a memory cell bus or memory controller, a peripheral bus, a processor, or a local bus using any of the various bus structures.

[0203] Storage unit 162 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 1621 and / or cache storage unit 1622, and may further include read-only memory (ROM) 1623.

[0204] Storage unit 162 may also include a program / utility 1625 having a set (at least one) of program modules 1624, such program modules 1624 including but not limited to: operating system, one or more application programs, other program modules and program data, each of these examples or some combination of these may include an implementation of a network environment.

[0205] The computing device 160 can also communicate with one or more external devices 164 (e.g., keyboard, pointing device, etc.), one or more devices that enable a user to interact with the computing device 160, and / or any device that enables the computing device 160 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 165. Furthermore, the computing device 160 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 166. As shown, network adapter 166 communicates with other modules used in the computing device 160 via bus 163. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with the computing device 160, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0206] In some possible implementations, various aspects of the service invocation method provided in this application can also be implemented as a program product, which includes program code. When the program product is run on a computer device, the program code causes the computer device to perform the steps of the service invocation method according to the various exemplary embodiments of this application described above. For example, the computer device can perform actions such as... Figure 5 The steps are shown in the figure.

[0207] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A service invocation method, characterized in that, The method includes: The application programming interface (API) gateway of the centralized control platform receives access requests from service callers and forwards the access requests to the corresponding service publishers; wherein, the service callers and the service publishers only support the service call function after they have successfully registered with the centralized control platform; the API gateway is used to complete mutual calls between multiple runtime environment microservices; The API gateway receives the response message returned by the service publisher and forwards the response message to the service caller, wherein the response message is generated by the service publisher after receiving the access request sent by the API gateway; The step of forwarding the response message to the service caller includes: When the API gateway confirms that the microservice runtime environment of the service caller and the service publisher is the same, it forwards the response message to the service caller using the authentication method corresponding to the microservice runtime environment; or, when the API gateway confirms that the microservice runtime environment of the service caller and the service publisher is different, it forwards the response message to the service caller using the authentication method corresponding to the API gateway; different authentication methods correspond to different microservice runtime environments; wherein, whether the microservice runtime environment of the service caller and the service publisher is the same is determined by the API gateway based on the address information of the service publisher obtained by the service caller.

2. The method as described in claim 1, characterized in that, Forwarding the access request to the corresponding service publisher includes: The access request is forwarded to the service publisher using the authentication method corresponding to the microservice runtime environment where the service publisher is located.

3. A service invocation method, characterized in that, The method includes: The service caller obtains the access address of the service publisher and sends an access request to the API gateway of the centralized control platform based on the access address, so that the API gateway forwards the access request to the service publisher; wherein, the service call function is only supported after the service caller and the service publisher have successfully registered on the centralized control platform; the API gateway is used to complete the mutual call between multiple runtime environment microservices; The service caller receives a response message returned by the API gateway, wherein the response message is generated by the service publisher based on the access request; The step of sending an access request to the API gateway based on the access address includes: When the microservice runtime environment of the service caller and the service publisher is the same, the service caller sends the access request to the API gateway through the authentication method corresponding to the microservice runtime environment; or, when the microservice runtime environment of the service caller and the service publisher is different, the service caller sends the access request to the API gateway through the authentication method corresponding to the API gateway; the authentication methods corresponding to different microservice runtime environments are different; wherein, whether the microservice runtime environment of the service caller and the service publisher is the same is determined by the API gateway based on the address information of the service publisher obtained by the service caller.

4. A service invocation method, characterized in that, The method includes: The service publisher receives an access request from the API gateway of the centralized control platform. When the service caller and the service publisher have the same microservice runtime environment, the access request is sent by the service caller to the API gateway using the authentication method corresponding to the microservice runtime environment. Alternatively, when the service caller and the service publisher have different microservice runtime environments, the access request is sent by the service caller to the API gateway using the authentication method corresponding to the API gateway. The service call function is only supported after both the service caller and the service publisher have successfully registered with the centralized control platform. The API gateway is used to facilitate mutual calls between microservices in multiple runtime environments. Different microservice runtime environments have different authentication methods. Whether the microservice runtime environments of the service caller and the service publisher are the same is determined by the API gateway based on the address information of the service publisher obtained by the service caller. The service publisher generates a response message based on the access request and sends the response message to the API gateway, so that the API gateway forwards the response message to the service caller.

5. A service invocation device, characterized in that, include: The first forwarding unit is used to receive access requests sent by service callers and forward the access requests to the corresponding service publishers; wherein, the service callers and the service publishers only support the service call function after they have successfully registered on the centralized control platform; the centralized control platform includes an API gateway, which is used to complete mutual calls between multiple runtime environment microservices; The second forwarding unit is used to receive the response message returned by the service publisher and forward the response message to the service caller, wherein the response message is generated by the service publisher after receiving the access request sent by the API gateway; Specifically, the second forwarding unit is used for: If it is confirmed that the microservice runtime environment of the service caller and the service publisher is the same, the response message is forwarded to the service caller through the authentication method corresponding to the microservice runtime environment; or, if it is confirmed that the microservice runtime environment of the service caller and the service publisher is different, the response message is forwarded to the service caller through the authentication method corresponding to the API gateway; the authentication methods corresponding to different microservice runtime environments are different; wherein, whether the microservice runtime environment of the service caller and the service publisher is the same is determined by the API gateway based on the address information of the service publisher obtained by the service caller.

6. A service invocation device, characterized in that, include: An access unit is used to obtain the access address of the service publisher and send an access request to the API gateway of the centralized control platform according to the access address, so that the API gateway forwards the access request to the service publisher; wherein, the service caller and the service publisher only support the service call function after they have successfully registered on the centralized control platform; the API gateway is used to complete the mutual call of multiple runtime environment microservices; A receiving unit is configured to receive a response message returned by the API gateway, wherein the response message is generated by the service publisher based on the access request; Specifically, the access unit is used for: When the microservice runtime environment of the service caller and the service publisher is the same, the access request is sent to the API gateway through the authentication method corresponding to the microservice runtime environment; or, when the microservice runtime environment of the service caller and the service publisher is different, the access request is sent to the API gateway through the authentication method corresponding to the API gateway; the authentication methods corresponding to different microservice runtime environments are different; wherein, whether the microservice runtime environment of the service caller and the service publisher is the same is determined by the API gateway based on the address information of the service publisher obtained by the service caller.

7. A service invocation device, characterized in that, include: A response unit is used to receive access requests sent by the API gateway of the centralized control platform. When the microservice runtime environments of the service caller and the service publisher are the same, the access request is sent by the service caller to the API gateway using the authentication method corresponding to the microservice runtime environment. Alternatively, when the microservice runtime environments of the service caller and the service publisher are different, the access request is sent by the service caller to the API gateway using the authentication method corresponding to the API gateway. The service call function is only supported after the service caller and the service publisher have successfully registered with the centralized control platform. The API gateway is used to complete mutual calls between microservices in multiple runtime environments. Different authentication methods correspond to different microservice runtime environments. Whether the microservice runtime environments of the service caller and the service publisher are the same is determined by the API gateway based on the address information of the service publisher obtained by the service caller. The sending unit is configured to generate a response message based on the access request and send the response message to the API gateway, so that the API gateway forwards the response message to the service caller.

8. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores program code that, when executed by the processor, causes the processor to perform the steps of any of the methods described in claims 1 to 4.

9. A computer-readable storage medium, characterized in that, It includes program code that, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described in claims 1 to 4.

Images