Method, device and system for calling micro service

Abstract

The embodiment of the invention discloses a micro-service calling method, device and system. The method comprises the following steps that a client gateway receives an interface calling request for a target micro-service; the client gateway rewrites the interface calling request according to the identity label of the client gateway, and sends the rewritten interface calling request to the server gateway, so that the server gateway forwards the interface calling request to the target micro-service; and under the condition that the server gateway obtains a response result from the target micro-service, the client gateway receives a response message from the server gateway and returns a calling result corresponding to the response message to a calling party of the target micro-service. According to the embodiment of the invention, the communication link is established between the client gateway and the server gateway, so that micro-services deployed in different domains can complete cross-domain request routing forwarding through the gateways, differentiated logic does not need to be realized in a program, the program complexity is simplified, and the development cost is reduced.

Description

Technical Field

[0001] The present application belongs to the field of computer technology, and specifically relates to a method, device and system for calling microservices. Background Art

[0002] At present, while SaaS products provide services to users on the public cloud, they also face the needs of customers for local private deployment. The public cloud SaaS platform and the customer's private environment are two completely independent environments, each deploying a complete set of programs. However, at the product function level, some core services of the product may not be deployed in the customer's private environment.

[0003] The solution in the existing technology is: SaaS products provide an open platform in the public cloud, and the customer's private domain side customizes the code to initiate an http request for the public cloud SaaS platform service interface that needs to be called, and calls the service interface on the public cloud through the open platform as the entry.

[0004] However, since SaaS products provide an open platform as an entry point for external customers to call, customized code needs to be written in the program delivered to the customer side to implement specific interfaces to access the public cloud service interface, which increases additional custom development costs and forms differentiated code logic in the program, thereby increasing the complexity of the program.

[0005] Application Contents

[0006] The purpose of the embodiments of the present application is to provide a method, device and system for calling microservices to solve the defects of high customized development cost and program complexity in the prior art.

[0007] In order to solve the above technical problems, this application is implemented as follows:

[0008] In a first aspect, a method for calling a microservice is provided, which is applied to a system including a client gateway and a server gateway, wherein the client gateway is deployed in a private domain as a client program, and the server gateway is deployed in a public cloud as a server program, and the method comprises the following steps:

[0009] The client gateway receives an interface call request for a target microservice;

[0010] The client gateway rewrites the interface call request according to its own identity, and sends the rewritten interface call request to the server gateway, so that the server gateway forwards the interface call request to the target microservice;

[0011] In the case where the server gateway obtains a response result from the target microservice, the client gateway receives a response message from the server gateway and returns a call result corresponding to the response message to the caller of the target microservice.

[0012] In a second aspect, a client gateway is provided, which is applied to a system including a client gateway and a server gateway, wherein the client gateway is deployed in a private domain as a client program, and the server gateway is deployed in a public cloud as a server program, and the client gateway includes:

[0013] A receiving module is used to receive an interface call request to a target microservice;

[0014] A rewriting module, used to rewrite the interface call request according to its own identity, and send the rewritten interface call request to the server gateway, so that the server gateway forwards the interface call request to the target microservice;

[0015] The transceiver module is used to receive a response message from the server gateway when the server gateway obtains a response result from the target microservice, and return the call result corresponding to the response message to the caller of the target microservice.

[0016] The embodiment of the present application establishes a communication link between the client gateway and the server gateway, so that microservices deployed in different domains can complete cross-domain request routing and forwarding through the gateway. There is no need to implement differentiated logic in the program, which simplifies the program complexity and reduces development costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of a method for calling a microservice provided by an embodiment of the present application;

[0018] Figure 2 It is a schematic diagram of the microservice gateway provided in the embodiment of the present application forwarding the call request to the domain and outside the domain;

[0019] Figure 3 This is a routing and forwarding flow chart of a microservice gateway deployed in a private domain provided in an embodiment of the present application;

[0020] Figure 4 It is a routing and forwarding flow chart of a microservice gateway deployed in a public cloud provided by an embodiment of the present application;

[0021] Figure 5 It is a structural diagram of a client gateway provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0023] Conventional microservice gateways are single-body, and multiple deployed gateways are independent entities, without the ability to forward requests. In view of this, the present application embodiment provides a set of microservice gateways that support point-to-point communication across network environments, and implements how microservices in private domains can seamlessly call public cloud SaaS platform services or microservices in private domains through microservice gateways in privatized deployment scenarios of SaaS products, solving the pain point that the private domain side needs to develop additional communication links with the public cloud SaaS platform side under conventional solutions.

[0024] Through the solution of the embodiment of the present application, a set of microservice gateways are deployed in the public cloud and the customer's private domain. The microservice gateway on the public cloud only needs to provide an address accessible to the public network. The microservice gateway deployed in the customer's private domain serves as the client of the request. The client gateway automatically identifies whether to call the local or public cloud service through dynamic routing rules. When it is identified that the service on the public cloud needs to be requested, it initiates a request to call the microservice gateway of the public cloud. The calling microservice achieves a set of logic applicable to the cloud and the local. The networking of the microservice gateways deployed in the private domain and public cloud environment forms a one-way communication form, breaking the status quo of independent and non-intercommunication between microservice gateways. In specific scenarios such as local deployment under the SaaS product cloud, some differentiated logic that originally needed to be implemented by the business side is implemented at the gateway layer, which reduces the complexity of program logic on the business side.

[0025] The gateway in the embodiment of the present application can be deployed as a client program in a private domain, or as a server program in a public cloud. The client gateway and the server gateway support mutual trust communication to establish a cascade relationship, and the client gateway can forward requests to the server gateway. The gateway in the embodiment of the present application has a routing table technology that indicates the direction of routing forwarding. For the same call interface url, the gateway can dynamically identify and forward requests to two destinations, the microservice within the domain or the gateway outside the domain, according to the routing table. The client gateway and the service segment gateway communication technology in the embodiment of the present application designs an integrated solution for cloud-ground tenant tenantId. The local tenant tenantId and its identity certificate are issued based on the cloud tenantId. Whether the request is routed to the domain or the cloud gateway, tenant data isolation can be achieved. The private domain gateway in the embodiment of the present application requests the configuration consistency control solution of routing forwarding to the cloud gateway. The cloud and local routing tables need to turn on the local routing to cloud switch at the same time, so as to achieve the controllability of the routing direction. The cloud gateway in the embodiment of the present application performs an interface authentication scheme for requests initiated by an external private domain gateway. Through the interface authorization group scheme, interfaces of the same business category can be placed in the same interface authorization group according to the business scenario, and then access to different interface authorization groups can be authorized according to the private domain tenantId, which can accurately control the interface range accessible to different private domain gateways.

[0026] The following is a detailed description of the method for calling microservices provided in the embodiment of the present application through specific embodiments and their application scenarios in conjunction with the accompanying drawings.

[0027] like Figure 1 As shown, it is a flow chart of a method for calling a microservice provided by an embodiment of the present application, which is applied to a system including a client gateway and a server gateway. The client gateway is deployed in a private domain as a client program, and the server gateway is deployed in a public cloud as a server program. The method includes the following steps:

[0028] Step 101: The client gateway receives an interface call request for a target microservice.

[0029] Step 102: The client gateway rewrites the interface call request according to its own identity identifier, and sends the rewritten interface call request to the server gateway, so that the server gateway forwards the interface call request to the target microservice.

[0030] In this embodiment, before the client gateway rewrites the interface call request according to its own identity, the process further includes: the client gateway determines whether it supports forwarding the interface call request to the server gateway according to a routing rule table.

[0031] Accordingly, in the case where the client gateway supports forwarding the interface call request to the server gateway, the client gateway rewrites the interface call request according to its own identity identifier;

[0032] After the client gateway determines whether to support forwarding the interface call request to the server gateway according to the routing rule table, it also includes: when the client gateway does not support forwarding the interface call request to the server gateway, the client gateway forwards the interface call request within the domain according to the forwarding target address corresponding to the interface call request in the routing rule table.

[0033] Among them, the routing rule table is used to define the routing ID, interface name, interface request method, request path, forwarding target address, and the "whether to enable local routing to the cloud" switch item.

[0034] Correspondingly, the client gateway obtains the value of the "Whether to enable local routing to the cloud" switch item corresponding to the interface call request in the routing rule table. If the value is yes, it is determined that it supports forwarding the interface call request to the server gateway; otherwise, it is determined that it does not support forwarding the interface call request to the server gateway.

[0035] Step 103, when the server gateway obtains a response result from the target microservice, the client gateway receives a response message from the server gateway and returns a call result corresponding to the response message to the caller of the target microservice.

[0036] In this embodiment, the server gateway uniquely identifies the identity of the client gateway according to the tenant identifier. The client gateway obtains the identity credential information corresponding to the tenant identifier from the cloud before being deployed to the private domain, and uses the tenant identifier as its own identity identifier;

[0037] The client gateway rewrites the interface call request according to its own identity identifier, specifically including: the client gateway embeds the tenant identifier into the request header of the interface call request;

[0038] After the client gateway sends the rewritten interface call request to the server gateway, it also includes: the server gateway obtains the tenant identifier from the request header of the rewritten interface call request, and obtains the identity credential information of the client gateway according to the tenant identifier; the server gateway decrypts the request body of the rewritten interface call request according to the identity credential information to obtain the original request body; the server gateway assembles a string according to the original request body and the parameters in the request header, signs the string, and obtains a signature value; the server gateway determines whether the signature value is consistent with the request header. If so, the server gateway determines that the client gateway can access the interface authorization group and forwards the interface call request to the target microservice; otherwise, the server gateway returns an error message to the client gateway.

[0039] Specifically, the client gateway concatenates the request body, request query parameters and request header parameters in the interface call request into a string, performs signature calculation on the string, and obtains a signature result; the client gateway concatenates the signature result and the string into a request header, and uses the identity credential information corresponding to its own tenant identifier to encrypt the request body in the interface call request.

[0040] The embodiment of the present application establishes a communication link between the client gateway and the server gateway, so that microservices deployed in different domains can complete cross-domain request routing and forwarding through the gateway. There is no need to implement differentiated logic in the program, which simplifies the program complexity and reduces development costs.

[0041] In the embodiment of the present application, a set of microservice gateway programs is designed and developed. Under the microservice deployment architecture, the gateway acts as a centralized forwarding device for interface calls between different microservices, providing core functions such as interface forwarding and interface authentication. In addition, it is also necessary to provide mutual trust communication capabilities between gateways, and interface routing forwarding is supported between gateways. The gateway as a client needs to have its own unique identity identification. The gateway as a server provides client gateway identity management capabilities, can identify the identity of the client gateway, and perform legal identity authentication and authentication on requests initiated by the client gateway, ensuring that only mutually trusted gateways can communicate normally, and the server gateway does not accept requests initiated by unauthenticated client gateways, thereby ensuring the security of the system.

[0042] The process for the gateway to forward requests within the current private domain environment is: service A → microservice gateway (private domain) → service B; the process for the gateway to forward requests to the cloud in the private domain is: local service A → microservice gateway (private domain) → microservice gateway (shared cloud) → service B.

[0043] like Figure 2As shown, the main modules and functions of the system are as follows:

[0044] Client microservice gateway: A microservice gateway deployed in the customer's private domain environment. It maintains a set of routing rule configuration tables to forward microservice interface requests within the current private domain environment and forward interface requests to the cloud. The gateway has its own unique identity, which is uniformly managed and allocated by the server-side microservice gateway.

[0045] Server-side microservice gateway: A microservice gateway deployed in a public cloud environment maintains a set of routing rule configuration tables to carry out the forwarding of microservice interface requests within the current cloud environment and the forwarding of interface requests initiated by the private domain. A private domain gateway management module is provided to assign its own identity to each microservice gateway deployed in the private domain, and to manage and control interface call permissions.

[0046] Communication between microservice gateways: The server-side gateway provides an accessible HTTPS domain name address on the public network as an external private domain access entrance, and performs identity verification and interface access authentication verification on the client gateway request received. When the client gateway receives the caller's request, it selects the forwarding target address as the server-side gateway or the microservice in the domain for request forwarding according to the routing forwarding rule configuration table. Only gateways marked as private domain deployment support forwarding requests to the server-side gateway, otherwise only forwarding within the domain is supported.

[0047] It can be seen that the microservice gateways deployed in private domains and public clouds are the same set of gateway programs, but the deployment locations are different. For microservice gateways deployed in the cloud and private domains, in addition to the common gateway functions, each has its own characteristic functions to realize the communication link between local and cloud. The following are the key function implementation solutions:

[0048] Gateway routing rules table

[0049] The routing table is maintained through the gateway console web interface to maintain the configuration information of the interface request. Only the interfaces maintained in the routing table can be forwarded through the gateway. The routing table defines the interface request method, request path, forwarding target address and other information, as shown in Table 1.

[0050] Table 1 Routing table

[0051]

[0052]

[0053] Both private domain and server-side gateways need to maintain routing table configuration. For private domain client gateways, "Whether to enable local routing to the cloud" is used as a switch item to determine the forwarding target domain of the interface. If it is no, the request is forwarded within the domain according to the address specified by the "forwarding target address" parameter. If it is yes, the request is forwarded to the cloud microservice gateway; for server-side gateways, if "Whether to enable local routing to the cloud" is no, private domain gateway requests to its interface are not accepted. If it is yes, private domain gateway requests to its interface are accepted.

[0054] Credentials and authorization management for private domain gateways

[0055] The server-side gateway features are not required for private domain deployment. The private domain gateway identity credentials and authorization are maintained through the gateway console web interface. The server-side gateway provides a service entry to the outside world. Security needs to be considered and only the caller who has issued the identity credentials is released. The server uses the tenant ID to uniquely identify the caller identity and allocates a set of access credentials key / key secret keys for each tenant ID. When deploying in a private domain environment, apply for identity credentials in the cloud gateway in advance and configure the tenant table during deployment, as shown in Table 2.

[0056] Table 2 Tenant table

[0057]

[0058] On the basis of tenant identity authentication, the interfaces that tenants can call on the cloud gateway are also managed uniformly. The specified interfaces are placed in the interface authorization group according to the usage scenario. Only interfaces with "whether to enable local routing to the cloud" set to yes are allowed to be added to the interface authorization group, and then the required interface authorization group permissions are added to the tenants. Among them, the interface authorization group table, the interface authorization group associated routing table, and the tenant and interface authorization group association table are shown in Table 3, Table 4, and Table 5 respectively.

[0059] Table 3 Interface authorization group table

[0060] Interface authorization group ID Interface authorization group name G1 Scenario 1 Authorization Group G2 Scenario 2 Authorization Group

[0061] Table 4 Interface authorization group associated routing table

[0062] Authorization group ID Routing table route ID G1 R1 G1 R2

[0063] Table 5 Tenant and interface authorization group association table

[0064] Private tenant ID Interface authorization group ID A G1 B G1

[0065] Gateway request forwarding module

[0066] The microservice gateway deployed in the public cloud accepts interface call requests from within the domain and external private domains. It determines whether the request is from within the domain or outside by determining whether there are specified parameters in the HTTP header of the request. If the request is initiated from within the domain, it is forwarded directly. If the request is initiated from an external private domain, authentication and authorization are performed before forwarding the request.

[0067] The microservice gateway deployed in the private domain determines whether to forward the request within the domain or to the cloud by determining the configuration of the request interface in the routing table. If the request is forwarded to the cloud, it will be signed and encrypted before forwarding the request to the cloud microservice gateway.

[0068] The prerequisite for the private domain microservice gateway to access the cloud microservice gateway is the integration of cloud and local tenants. The cloud microservice gateway uniquely identifies the client gateway identity based on the tenantId. Before the private domain gateway is deployed, it is necessary to obtain the identity credential information corresponding to the tenantId from the cloud and use the tenantId as its own identity. Each request routed locally to the cloud needs to embed the tenantId into the request header parameter for the cloud gateway to identify the client gateway identity and to perform tenant-level data isolation based on the tenantId.

[0069] like Figure 3 The figure shows the routing and forwarding flow chart of the microservice gateway deployed in the private domain. Since the request initiated by the client gateway to the server gateway is across the public network, the HTTPS protocol is used to consider the security of network transmission. The data is encrypted and signed when the client initiates the request. The server receives the request and decrypts and verifies the signature. If it fails, the request is intercepted. After the server gateway forwards the response result to the target microservice, it encrypts and signs the response message. The client gateway receives the response message and decrypts and verifies the signature. The encryption and decryption and signature verification process of the response message is the same as that of the request message. The private domain microservice gateway initiates a request to the cloud microservice gateway. The steps for encrypting the request signature are as follows: Generate a string to be signed according to the rules. The request body, request query parameters, and specific request header parameters participate in the signature. The rules are as follows:

[0070] <accesskey>+\n

[0071] +<md5(<request body content>)>+\n

[0072] +<queryparams, example of query parameter format: k1=1,2&k2=2>+\n

[0073] +<headers, example of request header parameter format: k1=1;k2=2>

[0074] Perform signature calculation on the unsigned string generated in the previous step. Use the SHA256 algorithm and convert the result into a Hexadecimal format string;

[0075] Add a request header to the Http header. The parameter name is Authorization. Append the signature value obtained in the previous step to the unsigned string to get the final signed string as the parameter value. The Authorization format is as follows:

[0076] Authorization=<signature algorithm version, fixed value>Credential=<caller identity Accesskey> / <result value of md5 encryption of the request body> / <queryParam string> / <header parameter string>,AdditionalHeaders=<request headers participating in the signature>,Signature=<signature value>

[0077] Use the symmetric encryption algorithm to encrypt the content of the request body of this request. Use the tenant identity credential as the encryption password, and generate a string of ciphertext after encryption.

[0078] As Figure 4 shown, it is the routing and forwarding flowchart of the microservice gateway for public cloud deployment. The cloud microservice gateway receives the client gateway request, and the steps for decrypting and verifying the signature are as follows: Obtain the tenantId from the request header, and obtain the identity credential data of the private network gateway according to the tenant tenantId; Decrypt the request body according to the identity credential data to obtain the original request body of the caller; Obtain Authorization from the request header, parse the parameter value, and verify the necessary request header parameters; Assemble the signed string according to the parameters obtained in the above two steps, sign the previous string to get the signature value, and compare the currently calculated signature value with the request header carried by the request Authorization. If they are consistent, the verification is passed.

[0079] The embodiment of the present application establishes a communication link between the microservice gateway and the gateway, so that microservices deployed in different domains can complete cross-domain request routing and forwarding through the gateway. For the request initiator microservice, the interface call is completed by connecting to the gateway, and there is no need to implement differentiated logical judgment and processing requests in the program, which greatly simplifies the complexity of the program. The interface routing solution from the client gateway to the server gateway proposed in the embodiment of the present application realizes the identity authentication and data transmission security of the request at the gateway layer, ensures the reliability between gateways, and both the requester microservice and the server microservice that perform interface calls through the gateway do not need to implement the security policy of data transmission on the network by themselves.

[0080] like Figure 5 As shown, it is a structural diagram of a client gateway provided in an embodiment of the present application, which is applied to a system including a client gateway and a server gateway. The client gateway is deployed in a private domain as a client program, and the server gateway is deployed in a public cloud as a server program. The client gateway includes:

[0081] The receiving module 510 is used to receive an interface call request for a target microservice.

[0082] The rewriting module 520 is used to rewrite the interface call request according to its own identity, and send the rewritten interface call request to the server gateway, so that the server gateway forwards the interface call request to the target microservice.

[0083] The transceiver module 530 is used to receive a response message from the server gateway when the server gateway obtains a response result from the target microservice, and return the call result corresponding to the response message to the caller of the target microservice.

[0084] In this embodiment, the client gateway further includes:

[0085] The judgment module is used to determine whether it supports forwarding the interface call request to the server gateway according to the routing rule table.

[0086] Correspondingly, the rewriting module 520 is specifically configured to rewrite the interface call request according to its own identity identifier when the client gateway supports forwarding the interface call request to the server gateway.

[0087] The transceiver module 530 is also used to forward the interface call request within the domain according to the forwarding target address corresponding to the interface call request in the routing rule table when the client gateway does not support forwarding the interface call request to the server gateway.

[0088] The routing rule table is used to define the routing ID, interface name, interface request method, request path, forwarding target address, and the "whether to enable local routing to the cloud" switch item.

[0089] Correspondingly, the judgment module is specifically used to obtain the value of the "whether to enable local routing to the cloud" switch item corresponding to the interface call request in the routing rule table. If the value is yes, it is determined that it supports forwarding the interface call request to the server gateway; otherwise, it is determined that it does not support forwarding the interface call request to the server gateway.

[0090] In this embodiment, the server gateway uniquely identifies the identity of the client gateway according to the tenant identifier. Before being deployed to the private domain, the client gateway obtains the identity credential information corresponding to the tenant identifier from the cloud, and uses the tenant identifier as its own identity identifier.

[0091] Correspondingly, the rewriting module 520 is specifically configured to embed the tenant identifier into the request header of the interface call request.

[0092] Specifically, the rewriting module 520 is specifically used to concatenate the request body, request query parameters and request header parameters in the interface call request into a string, perform signature calculation on the string, and obtain a signature result; concatenate the signature result and the string into a request header, and use the identity credential information corresponding to its own tenant identifier to encrypt the request body in the interface call request.

[0093] The embodiment of the present application establishes a communication link between the client gateway and the server gateway, so that microservices deployed in different domains can complete cross-domain request routing and forwarding through the gateway. There is no need to implement differentiated logic in the program, which simplifies the program complexity and reduces development costs.

[0094] An embodiment of the present application also provides a system for calling microservices, including the client gateway and server gateway described in the above device embodiment, wherein the client gateway is deployed in a private domain as a client program, and the server gateway is deployed in a public cloud as a server program.

[0095] The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the above-mentioned method of calling a microservice is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

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

[0097] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0098] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.< / accesskey>

Claims

1. A method for calling a microservice, characterized in that: Applied to a system including a client gateway and a server gateway, the client gateway is deployed in a private domain as a client program, and the server gateway is deployed in a public cloud as a server program, and the method includes the following steps: The client gateway receives an interface call request for a target microservice; The client gateway rewrites the interface call request according to its own identity, and sends the rewritten interface call request to the server gateway, so that the server gateway forwards the interface call request to the target microservice; In the case where the server gateway obtains a response result from the target microservice, the client gateway receives a response message from the server gateway and returns a call result corresponding to the response message to the caller of the target microservice.

2. The method according to claim 1, characterized in that: Before the client gateway rewrites the interface call request according to its own identity, the method further includes: The client gateway determines whether it supports forwarding the interface call request to the server gateway according to the routing rule table; The client gateway rewrites the interface call request according to its own identity, specifically including: In the case where the client gateway supports forwarding the interface call request to the server gateway, the client gateway rewrites the interface call request according to its own identity identifier; After the client gateway determines whether to support forwarding the interface call request to the server gateway according to the routing rule table, the method further includes: In the case that the client gateway does not support forwarding the interface call request to the server gateway, the client gateway forwards the interface call request within the domain according to the forwarding target address corresponding to the interface call request in the routing rule table.

3. The method according to claim 2, characterized in that The routing rule table is used to define the routing ID, interface name, interface request method, request path, forwarding target address, and "whether to enable local routing to the cloud" switch item; The client gateway determines whether it supports forwarding the interface call request to the server gateway according to the routing rule table, specifically including: The client gateway obtains the value of the "whether to enable local routing to the cloud" switch item corresponding to the interface call request in the routing rule table, and if the value is yes, determines that it supports forwarding the interface call request to the server gateway; Otherwise, it is determined that it does not support forwarding the interface call request to the server gateway.

4. The method according to claim 1, characterized in that: The server gateway uniquely identifies the identity of the client gateway according to the tenant identifier. The client gateway obtains the identity credential information corresponding to the tenant identifier from the cloud before being deployed to the private domain, and uses the tenant identifier as its own identity identifier; The client gateway rewrites the interface call request according to its own identity, specifically including: The client gateway embeds the tenant identifier into the request header of the interface call request; After the client gateway sends the rewritten interface call request to the server gateway, the method further includes: The server gateway obtains the tenant identifier from the request header of the rewritten interface call request, and obtains the identity credential information of the client gateway according to the tenant identifier; The server gateway decrypts the request body of the rewritten interface call request according to the identity credential information to obtain the original request body; The server gateway assembles a string according to the original request body and the parameters in the request header, signs the string, and obtains a signature value; The server gateway determines whether the signature value is consistent with the request header. If so, the server gateway determines that the client gateway can access the interface authorization group and forwards the interface call request to the target microservice; otherwise, the server gateway returns an error message to the client gateway.

5. The method according to claim 4, characterized in that The client gateway embeds the tenant identifier into the request header of the interface call request, specifically including: The client gateway concatenates the request body, request query parameters and request header parameters in the interface call request into a string, performs signature calculation on the string, and obtains a signature result; The client gateway concatenates the signature result and the string into a request header, and uses the identity credential information corresponding to its own tenant identifier to encrypt the request body in the interface call request.

6. A client gateway, characterized in that: Applied to a system including a client gateway and a server gateway, wherein the client gateway is deployed in a private domain as a client program, and the server gateway is deployed in a public cloud as a server program, and the client gateway includes: A receiving module is used to receive an interface call request to a target microservice; A rewriting module, used to rewrite the interface call request according to its own identity, and send the rewritten interface call request to the server gateway, so that the server gateway forwards the interface call request to the target microservice; The transceiver module is used to receive a response message from the server gateway when the server gateway obtains a response result from the target microservice, and return the call result corresponding to the response message to the caller of the target microservice.

7. The client gateway according to claim 6, characterized in that: Also includes: A judgment module, used to determine whether it supports forwarding the interface call request to the server gateway according to the routing rule table; The rewriting module is specifically used to rewrite the interface call request according to its own identity identifier when the client gateway supports forwarding the interface call request to the server gateway; The transceiver module is also used to forward the interface call request within the domain according to the forwarding target address corresponding to the interface call request in the routing rule table when the client gateway does not support forwarding the interface call request to the server gateway.

8. The client gateway according to claim 7, characterized in that: The routing rule table is used to define the routing ID, interface name, interface request method, request path, forwarding target address, and "whether to enable local routing to the cloud" switch item; The judgment module is specifically used to obtain the value of the "whether to enable local routing to the cloud" switch item corresponding to the interface call request in the routing rule table, and if the value is yes, it is determined that it supports forwarding the interface call request to the server gateway; Otherwise, it is determined that it does not support forwarding the interface call request to the server gateway.

9. The client gateway according to claim 6, characterized in that: The server gateway uniquely identifies the identity of the client gateway according to the tenant identifier. The client gateway obtains the identity credential information corresponding to the tenant identifier from the cloud before being deployed to the private domain, and uses the tenant identifier as its own identity identifier; The rewriting module is specifically used to embed the tenant identifier into the request header of the interface call request.

10. The client gateway according to claim 9, characterized in that: The rewriting module is specifically used to splice the request body, request query parameters and request header parameters in the interface call request into a string, perform signature calculation on the string, and obtain a signature result; splice the signature result and the string into a request header, and use the identity credential information corresponding to its own tenant identifier to encrypt the request body in the interface call request.

11. A system for calling microservices, characterized in that: It comprises a client gateway and a server gateway as described in any one of claims 6 to 10, wherein the client gateway is deployed in a private domain as a client program, and the server gateway is deployed in a public cloud as a server program.

Images