Private domain service penetration request method and system based on microservice gateway

Abstract

The invention provides a private domain service penetration request method and system based on a micro-service gateway, and the method comprises the steps: S1, transmitting a registration request to a gateway relay service module through a local micro-service gateway, and carrying out the authentication through a micro-service gateway management service module; s2, when the public cloud service sends a request to the private domain intranet service, the public cloud microservice gateway sends the request to a gateway relay service module, and the gateway relay service carries out routing forwarding control signaling to a local microservice gateway according to a routing key carried by the request; s3, after receiving the control signaling sent by the relay service, the local microservice gateway sends a request to pull the request content of the public cloud service according to parameters of the control signaling, and then forwards the request content to the private domain service; and S4, the private domain service processes the request of the public cloud service, pushes the response content to the gateway relay service module through the local microservice gateway, relays and forwards the response content to the public cloud microservice gateway, and forwards the response content to the public cloud service.

Description

Technical Field

[0001] The present invention relates to a microservice gateway, and in particular to a private domain service penetration request method and system based on the microservice gateway. Background Art

[0002] At present, local private domains can solve the passive data transmission application scenario by providing public domain names to achieve data transmission between local private domains and public cloud services. However, the operation and maintenance of the entrance to the public domain name involves domain names, certificates, security, etc., which is costly. Furthermore, the local private domain can also actively poll the public cloud API interface. This method requires high-frequency access to ensure real-time performance, which will generate a large number of useless HTTPS requests to the public cloud server.

[0003] Microservices is a software development technique in which a single application is composed of many smaller components or services that are loosely coupled and independently deployable. In a microservices architecture, services are fine-grained and protocols are lightweight. Because services are small and independently deployable, it no longer takes a head server to change a line of text in an application. Summary of the invention

[0004] The present invention provides a private domain service penetration request method and system based on a microservice gateway, which solves the problem of how microservices deployed in a public cloud actively send requests to local private domain services through a microservice gateway in a hybrid cloud application scenario. The technical solution is as follows:

[0005] A private domain service penetration request method based on a microservice gateway includes the following steps:

[0006] S1: The local microservice gateway sends a registration request to the gateway relay service module. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained.

[0007] S2: When the public cloud service sends a request to the private domain intranet service, the public cloud microservice gateway sends the request to the gateway relay service module, and the gateway relay service performs routing and forwarding control signaling to the local microservice gateway according to the routing key carried in the request;

[0008] S3: After the local microservice gateway receives the control signaling sent by the relay service, the local microservice gateway sends a request to pull the request content of the public cloud service according to the control signaling parameters. The local microservice gateway repackages the request content of the public cloud service pulled from the gateway relay service, and the local microservice gateway forwards the reorganized request to the corresponding private domain service;

[0009] S4: After the private domain service processes the request of the public cloud service, it pushes the response content to the gateway relay service module through the local microservice gateway via an Http request. The gateway relay service module relays the response content to the public cloud microservice gateway, and the public cloud microservice gateway forwards the response content to the public cloud service.

[0010] Furthermore, the step S1 comprises the following steps:

[0011] S101: After the local microservice gateway is started, it uses the WebScoket protocol to initiate a registration request to the cloud service and establish a websocket connection. It uses the WebSocket Upgrade request to agree on additional control header parameters to carry the client identity information.

[0012] S102: After receiving the registration request, the gateway relay service performs authentication through the microservice gateway management service. If the authentication fails, the gateway relay service directly rejects the registration request of the local microservice gateway through the 401 status code; if the authentication passes, go to step S103;

[0013] S103: The gateway relay service maintains a local routing table and a global routing table for the authenticated client. The local routing table is in-process, and the structure of the local routing table is unique ID = WebSocket connection. The global routing table is maintained by two sets of hash tables: routing key = "unique ID + service IP where the connection is located" and unique ID = "routing key", which are used to implement addressing based on the routing key and remove the global routing information when the client is offline;

[0014] S104: After the gateway relay service establishes a WebScoket connection with the local microservice gateway, it returns the client TOKEN information through CONNECT_ACK signaling;

[0015] S105: After the local microservice gateway establishes a WebSocket connection, it periodically sends a PING signaling to the gateway relay service to keep the connection alive. If no PONG response signaling is received within two cycles, the connection is automatically destroyed and the connection is rebuilt from step S101;

[0016] S106: The gateway relay service establishes a WebSocket connection with the client, and through periodic polling checks, the connection that has not generated any signaling interaction for two cycles is directly destroyed and deleted from the routing table to ensure the validity of the connection.

[0017] Furthermore, in step S101, the registration request will carry the identity information of the local microservice gateway, and the identity information includes a unique ID, a routing key, a local area network IP, and a data signature, which is transmitted through the Http request header when the gateway relay service sends the registration request.

[0018] After the WebSocket connection between the local microservice gateway and the gateway relay service is established, the WebSocket connection is kept alive through custom PING / PONG signaling. The public cloud server considers it disconnected if it does not receive PING in two keep-alive cycles. The private domain intranet service client considers it disconnected if it does not receive PONG in two keep-alive cycles. After disconnection, it automatically reconnects according to step S101.

[0019] Further, step S2 includes the following steps:

[0020] S201: The public cloud service sends a request to the public cloud microservice gateway;

[0021] S202: After receiving the request for the public cloud service, the public cloud microservice gateway obtains the client connection information of the private domain intranet service from the global routing table according to the routing key information in the request header;

[0022] S203: If the local microservice gateway of the private intranet service is not online, a 502 status code is directly returned with the error message: the client is not online;

[0023] S204: If the local microservice gateway is online, forward the request to the gateway relay service module according to the “connection service IP” in the connection information;

[0024] S205: After receiving the request, the gateway relay service module registers the request content in the form of "client ID = request content" into its pending hash table;

[0025] S206: The gateway relay service obtains the client WebSocket connection instance from the local routing table according to the client ID, and sends a processing request control signaling to the local microservice gateway, with the content = request ID and the service domain name where the request is located.

[0026] Further, step S3 includes the following steps:

[0027] S301: After receiving the processing request control signaling, the local microservice gateway sends an Https request to the gateway relay service through the service domain name where the request is located to pull the request content according to the request ID, and uses the request header in the https request to carry the client ID and TOKEN information;

[0028] S302: When the gateway relay service receives a request to pull the request content according to the request ID, it first performs TOKEN authentication. After the authentication is passed, it queries and locks the request from the pending hash table according to the request ID, responds to the request content to the local microservice gateway, and at the same time, the target service information of this request is transmitted through the response header;

[0029] S303: After the local microservice gateway pulls the request content from the public cloud service, it rebuilds the Http request according to the target service and other information in the response header, and forwards the request content to the private domain service through the HttpClient in the local microservice gateway.

[0030] Further, step S4 includes the following steps:

[0031] S401: After the private domain service business processing is completed, the processing result is responded to the local microservice gateway;

[0032] S402: After receiving the response from the private domain service, the local microservice gateway pushes the response content of the private domain service to the gateway relay service through https through the upload response result interface according to the request ID, and carries the request ID, client ID, and Token information through the request header;

[0033] S403: After receiving the response push request from the local microservice gateway, the gateway relay service module performs TOKEN authentication, obtains the request information from the pending hash table according to the request ID, and responds to the public cloud microservice gateway with the response content;

[0034] S404: After receiving the response, the public cloud microservice gateway forwards the response content to the public cloud service.

[0035] A private domain service penetration request system based on a microservice gateway, comprising:

[0036] Public cloud microservice gateway: used for routing and forwarding microservices within the public cloud, located on the public cloud side;

[0037] Gateway relay service module: used for local microservice gateway identity authentication, local microservice gateway routing table registration, local microservice gateway WebSocket long connection management, interface request relay forwarding, control information delivery, etc., located on the public cloud side;

[0038] Microservice gateway management service module: used to manage the identity of the local microservice gateway and the local microservice gateway identity authentication, located on the public cloud side;

[0039] Local microservice gateway: used to register with the gateway relay service module on the public cloud side at runtime, listen to the control signaling sent by websocket, and route and forward requests to private domain services. It is located on the private domain intranet service side.

[0040] Furthermore, the gateway relay service module processes the following:

[0041] Local microservice gateway identity authentication and local microservice gateway routing table registration refer to the following: after the local microservice gateway is started, it uses the WebScoket protocol to initiate a registration request to the cloud service and establish a websocket connection. It uses the WebSocket Upgrade request to agree on additional control header parameters to carry the client identity information. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained.

[0042] The local microservice gateway WebSocket long connection management refers to the WebSocket connection being kept alive through custom PING / PONG signaling;

[0043] Interface request relay forwarding means that when a public cloud service sends a request to a private domain intranet service, the public cloud microservice gateway sends the request to the gateway relay service module for request and response forwarding;

[0044] Control signaling refers to the registration and authentication of the local microservice gateway, as well as the sending of control signaling to the local microservice gateway when the public cloud service sends a request to the private domain intranet service for data transmission.

[0045] The private domain service penetration request method and system based on the microservice gateway can realize the transparent active calling capability of the public cloud service to the private domain service without providing the private domain public network domain name and only opening the external network access right, such as realizing the feedback of business status, the distribution of configuration information, active status inspection, etc. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is a structural diagram of the private domain service penetration request system based on the microservice gateway. DETAILED DESCRIPTION

[0047] like Figure 1 As shown, the private domain service penetration request system based on the microservice gateway includes:

[0048] 1. Public cloud microservice gateway: used for routing and forwarding microservices within the public cloud, located on the public cloud side;

[0049] 2. Gateway relay service module: used for local microservice gateway identity authentication, local microservice gateway routing table registration, local microservice gateway WebSocket long connection management, interface request relay forwarding, control information delivery, etc., located on the public cloud side; Among them,

[0050] Local microservice gateway identity authentication and local microservice gateway routing table registration mean that after the local microservice gateway is started, it uses the WebScoket protocol to initiate a registration request to the cloud service and establish a websocket connection. It uses the WebSocket Upgrade request to agree on additional control header parameters to carry client identity information. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained.

[0051] The local microservice gateway WebSocket long connection management means that the WebSocket connection is kept alive through custom PING / PONG signaling. The public cloud server considers the connection disconnected if it does not receive PING within two keep-alive cycles, and the private intranet service client considers the connection disconnected if it does not receive PONG within two keep-alive cycles.

[0052] Interface request relay forwarding means that when a public cloud service sends a request to a private domain intranet service, the public cloud microservice gateway sends the request to the gateway relay service module for request and response forwarding.

[0053] Control signaling refers to the registration and authentication of the local microservice gateway, as well as the sending of control signaling to the local microservice gateway when the public cloud service sends a request to the private domain intranet service for data transmission.

[0054] 3. Microservice gateway management service module: used to manage the identity of the local microservice gateway and the local microservice gateway identity authentication, located on the public cloud side;

[0055] 4. Local microservice gateway: used to register with the gateway relay service module on the public cloud side at runtime, listen to the control signaling sent by the websocket, and route and forward requests to the private domain service. It is located on the private domain intranet service side.

[0056] According to the private domain service penetration request system based on the microservice gateway, a private domain service penetration request method based on the microservice gateway is implemented, comprising the following steps:

[0057] S1: The local microservice gateway sends a registration request to the gateway relay service module. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained.

[0058] The specific steps include:

[0059] S101: After the local microservice gateway is started, a registration request is sent to the cloud service using the WebScoket protocol to establish a websocket connection, and additional control header parameters are carried using the WebSocket Upgrade request to carry client identity information;

[0060] The registration request carries the identity information of the local microservice gateway using the request header. The identity information includes information such as a unique ID, a routing key, a local area network IP, and a data signature (using the SHA256 algorithm). It is passed by sending the request header of the registration request to the gateway relay service module of the cloud service. The parameter format is: Authorization: DTCAuthV1 <JWT format content>;

[0061] S102: After the gateway relay service receives the registration request, it performs authentication through the microservice gateway management service. If the authentication fails, the gateway relay service directly rejects the registration request of the local microservice gateway with a 401 status code; if the authentication passes, it proceeds to step S103;

[0062] S103: The gateway relay service maintains a local routing table and a global routing table for the authenticated client. The local routing table is within the process, and the structure of the local routing table is unique ID = WebSocket connection. The global routing table is maintained through two hash tables: routing key = "unique ID + service IP where the connection is located" and unique ID = "routing key", which is used to achieve addressing based on the routing key and remove global routing information when the client goes offline;

[0063] S104: After the gateway relay service establishes a WebScoket connection with the local microservice gateway, it sends back the client TOKEN information through the CONNECT_ACK signaling;

[0064] S105: After the local microservice gateway establishes a WebSocket connection, it periodically sends a PING signaling to the gateway relay service to keep the connection alive. If it does not receive a PONG response signaling within two cycles, the connection is automatically destroyed, and the connection is re-established starting from step S101;

[0065] S106: The gateway relay service establishes a WebSocket connection with the client. Through periodic polling checks, connections that have not had any signaling interactions for two cycles are directly destroyed and deleted from the routing table to ensure the validity of the connection.

[0066] In addition, after the local microservice gateway and the gateway relay service module establish a WebSocket connection, the WebSocket connection is kept alive through custom PING / PONG signaling. The public cloud server considers it disconnected if it does not receive PING within two keep-alive cycles, and the client of the private domain intranet service considers it disconnected if it does not receive PONG within two keep-alive cycles. After disconnection, it automatically reconnects according to step S101.

[0067] S2: When the public cloud service sends a request to the private domain intranet service, the public cloud microservice gateway sends the request to the gateway relay service module, and the gateway relay service performs routing and forwarding control signaling to the local microservice gateway according to the routing key carried in the request; specifically, the following steps are included:

[0068] S201: Public cloud service 2 sends a request to the public cloud microservice gateway;

[0069] S202: After receiving the request from public cloud service 2, the public cloud microservice gateway obtains the client connection information of the private domain intranet service from the global routing table according to the routing key information in the request header: X-GW-RoutingKey: <routing key value>;

[0070] S203: If the local microservice gateway of the private intranet service is not online, a 502 status code is directly returned with the error message: the client is not online;

[0071] S204: If the local microservice gateway is online, forward the request to the gateway relay service module according to the “connection service IP” in the connection information;

[0072] S205: After receiving the request, the gateway relay service module registers the request content in the form of "client ID = request content" into its pending hash table;

[0073] S206: The gateway relay service obtains the client WebSocket connection instance from the local routing table according to the client ID, and sends a processing request control signaling to the local microservice gateway: HTTP_PROXY_REQUEST_V1, content = request ID, service domain name where the request is located.

[0074] S3: After the local microservice gateway receives the control signaling sent by the relay service, the local microservice gateway sends a request to pull the request content of the public cloud service according to the control signaling parameters, and the local microservice gateway repackages the request content of the public cloud service pulled from the gateway relay service, and the local microservice gateway forwards the reorganized request to the corresponding private domain service; comprising the following steps:

[0075] S301: After receiving the control signaling: HTTP_PROXY_REQUEST_V1, the local microservice gateway sends an Https request to the gateway relay service through the service domain name where the request is located to pull the request content according to the request ID, and uses the request header in the https request to carry information such as the client ID and TOKEN;

[0076] S302: When the gateway relay service receives a request to fetch the request content according to the request ID, it first performs TOKEN authentication. After the authentication is passed, it searches and locks the request from the pending hash table according to the request ID, finds the request content of public cloud service 2, responds to the request content to the local microservice gateway, and transmits the target service information of public cloud service 2 through the response header;

[0077] S303: After the local microservice gateway pulls the request content from public cloud service 2, it rebuilds the Http request based on the target service and other information in the response header, and forwards the request content to private domain service 1 through the HttpClient in the local microservice gateway.

[0078] S4: After the private domain service processes the request of the public cloud service, it pushes the response content to the gateway relay service module through the local microservice gateway via an Http request. The gateway relay service module relays the response content to the public cloud microservice gateway, and the public cloud microservice gateway forwards the response content to the public cloud service.

[0079] The specific steps include:

[0080] S401: After the private domain service 1 business processing is completed, the processing result is responded to the local microservice gateway;

[0081] S402: After receiving the response from private domain service 1, the local microservice gateway pushes the response content of private domain service 1 to the gateway relay service through https through the upload response result interface according to the request ID, and carries the request ID, client ID, and Token information through the request header;

[0082] S403: After receiving the response push request from the local microservice gateway, the gateway relay service module performs TOKEN authentication, obtains the request information from the pending hash table according to the request ID, and responds to the public cloud microservice gateway with the response content;

[0083] S404: After receiving the response, the public cloud microservice gateway forwards the response content to the public cloud service;

[0084] In the present invention, TCP long connection can also be used instead of WebSocket long connection to realize the signaling channel between the public cloud microservice gateway and the local microservice gateway.

[0085] The present invention has the following advantages:

[0086] (1) It has millisecond-level real-time performance;

[0087] (2) Minimize the number of invalid network requests and improve service performance;

[0088] (3) Private domain services do not require separate operation and maintenance of public domain names to provide services;

[0089] (4) The signaling messages transmitted by the signaling channel are short, compact and highly real-time. The request and response messages transmitted by the data channel can be changed in length as needed to meet the needs of various scenarios.

[0090] (5) The transmission tunnel uses the commonly used application layer protocol technology wss+https, and there are a large number of mature tool chains available for site operation and maintenance, certificate management, traffic control, monitoring, etc.

Claims

1. A private domain service penetration request method based on a microservice gateway, comprising the following steps: S1: The local microservice gateway sends a registration request to the gateway relay service module. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained. S2: When the public cloud service sends a request to the private domain intranet service, the public cloud microservice gateway sends the request to the gateway relay service module, and the gateway relay service performs routing and forwarding control signaling to the local microservice gateway according to the routing key carried in the request; S3: After the local microservice gateway receives the control signaling sent by the relay service, the local microservice gateway sends a request to pull the request content of the public cloud service according to the control signaling parameters. The local microservice gateway repackages the request content of the public cloud service pulled from the gateway relay service, and the local microservice gateway forwards the reorganized request to the corresponding private domain service; S4: After the private domain service processes the request of the public cloud service, it pushes the response content to the gateway relay service module through the local microservice gateway via an Http request. The gateway relay service module relays the response content to the public cloud microservice gateway, and the public cloud microservice gateway forwards the response content to the public cloud service.

2. According to claim 1, the private domain service penetration request method based on microservice gateway is characterized in that: Step S1 includes the following steps: S101: After the local microservice gateway is started, it uses the WebScoket protocol to initiate a registration request to the cloud service and establish a websocket connection. It uses the WebSocket Upgrade request to agree on additional control header parameters to carry the client identity information. S102: After receiving the registration request, the gateway relay service performs authentication through the microservice gateway management service. If the authentication fails, the gateway relay service directly rejects the registration request of the local microservice gateway through the 401 status code; if the authentication passes, go to step S103; S103: The gateway relay service maintains a local routing table and a global routing table for the authenticated client. The local routing table is in-process and has a structure of unique ID = WebSocket connection. The global routing table is maintained by two sets of hash tables: routing key = "unique ID + service IP where the connection is located" and unique ID = "routing key", which are used to implement addressing based on the routing key and remove global routing information when the client is offline. S104: After the gateway relay service establishes a WebScoket connection with the local microservice gateway, it returns the client TOKEN information through CONNECT_ACK signaling; S105: After the local microservice gateway establishes a WebSocket connection, it periodically sends a PING signaling to the gateway relay service to keep the connection alive. If no PONG response signaling is received within two cycles, the connection is automatically destroyed and the connection is rebuilt from step S101; S106: The gateway relay service establishes a WebSocket connection with the client, and through periodic polling checks, the connection that has not generated any signaling interaction for two cycles is directly destroyed and deleted from the routing table to ensure the validity of the connection.

3. According to claim 2, the private domain service penetration request method based on the microservice gateway is characterized in that: In step S101, the registration request will carry the identity information of the local microservice gateway, and the identity information includes a unique ID, a routing key, a local area network IP, and a data signature, which is transmitted through the Http request header when the gateway relay service sends the registration request.

4. According to claim 2, the private domain service penetration request method based on the microservice gateway is characterized in that: After the WebSocket connection between the local microservice gateway and the gateway relay service is established, the WebSocket connection is kept alive through custom PING / PONG signaling. The public cloud server considers it disconnected if it does not receive PING in two keep-alive cycles. The private domain intranet service client considers it disconnected if it does not receive PONG in two keep-alive cycles. After disconnection, it automatically reconnects according to step S101.

5. According to claim 1, the private domain service penetration request method based on microservice gateway is characterized in that: Step S2 includes the following steps: S201: The public cloud service sends a request to the public cloud microservice gateway; S202: After receiving the request for the public cloud service, the public cloud microservice gateway obtains the client connection information of the private domain intranet service from the global routing table according to the routing key information in the request header; S203: If the local microservice gateway of the private intranet service is not online, a 502 status code is directly returned with the error message: the client is not online; S204: If the local microservice gateway is online, forward the request to the gateway relay service module according to the "connection service IP" in the connection information; S205: After receiving the request, the gateway relay service module registers the request content in the form of "client ID = request content" into its pending hash table; S206: The gateway relay service obtains the client WebSocket connection instance from the local routing table according to the client ID, and sends a processing request control signaling to the local microservice gateway, with the content = request ID and the service domain name where the request is located.

6. According to claim 1, the private domain service penetration request method based on microservice gateway is characterized in that: Step S3 includes the following steps: S301: After receiving the processing request control signaling, the local microservice gateway sends an Https request to the gateway relay service through the service domain name where the request is located to pull the request content according to the request ID, and uses the request header in the https request to carry information such as the client ID and TOKEN; S302: When the gateway relay service receives a request to pull the request content according to the request ID, it first performs TOKEN authentication. After the authentication is passed, it queries and locks the request from the pending hash table according to the request ID, responds to the request content to the local microservice gateway, and at the same time, the target service information of this request is transmitted through the response header; S303: After the local microservice gateway pulls the request content from the public cloud service, it rebuilds the Http request according to the target service information in the response header, and forwards the request content to the private domain service through the HttpClient in the local microservice gateway.

7. According to claim 1, the private domain service penetration request method based on microservice gateway is characterized in that: Step S4 includes the following steps: S401: After the private domain service business processing is completed, the processing result is responded to the local microservice gateway; S402: After receiving the response from the private domain service, the local microservice gateway pushes the response content of the private domain service to the gateway relay service through https through the upload response result interface according to the request ID, and carries the request ID, client ID, and token information through the request header; S403: After receiving the response push request from the local microservice gateway, the gateway relay service module performs TOKEN authentication, obtains the request information from the pending hash table according to the request ID, and responds to the public cloud microservice gateway with the response content; S404: After receiving the response, the public cloud microservice gateway forwards the response content to the public cloud service.

8. A private domain service penetration request system based on a microservice gateway, characterized in that: include: Public cloud microservice gateway: used for routing and forwarding microservices within the public cloud, located on the public cloud side; Gateway relay service module: used for local microservice gateway identity authentication, local microservice gateway routing table registration, local microservice gateway WebSocket long connection management, interface request relay forwarding, control information delivery, etc., located on the public cloud side; Microservice gateway management service module: used to manage the identity of the local microservice gateway and the local microservice gateway identity authentication, located on the public cloud side; Local microservice gateway: used to register with the gateway relay service module on the public cloud side at runtime, listen to the control signaling sent by websocket, and route and forward requests to private domain services. It is located on the private domain intranet service side.

9. The private domain service penetration request system based on microservice gateway according to claim 8 is characterized in that: The gateway relay service module processes the following: Local microservice gateway identity authentication and local microservice gateway routing table registration refer to that after the local microservice gateway is started, it uses the WebScoket protocol to initiate a registration request to the cloud service and establish a websocket connection. It uses the WebSocketUpgrade request to agree on additional control header parameters to carry the client identity information. The gateway relay service module sends the registration request to the microservice gateway management service module for authentication. After successful authentication, a WebSocket connection is established and the routing table is maintained. The local microservice gateway WebSocket long connection management refers to the WebSocket connection being kept alive through custom PING / PONG signaling; Interface request relay forwarding means that when a public cloud service sends a request to a private domain intranet service, the public cloud microservice gateway sends the request to the gateway relay service module for request and response forwarding; Control signaling refers to the registration and authentication of the local microservice gateway, as well as the sending of control signaling to the local microservice gateway when the public cloud service sends a request to the private domain intranet service for data transmission.

Images