CN117544628A - Micro-service access method, device, equipment and medium in gateway proxy scene - Google Patents

Micro-service access method, device, equipment and medium in gateway proxy scene Download PDF

Info

Publication number
CN117544628A
CN117544628A CN202311623150.3A CN202311623150A CN117544628A CN 117544628 A CN117544628 A CN 117544628A CN 202311623150 A CN202311623150 A CN 202311623150A CN 117544628 A CN117544628 A CN 117544628A
Authority
CN
China
Prior art keywords
domain name
service
public network
intranet
micro
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311623150.3A
Other languages
Chinese (zh)
Inventor
叶宇轩
叶明亮
王钊金
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Sanqi Jichuang Network Technology Co ltd
Original Assignee
Guangzhou Sanqi Jichuang Network Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangzhou Sanqi Jichuang Network Technology Co ltd filed Critical Guangzhou Sanqi Jichuang Network Technology Co ltd
Priority to CN202311623150.3A priority Critical patent/CN117544628A/en
Publication of CN117544628A publication Critical patent/CN117544628A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1036Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/10Mapping addresses of different types
    • H04L61/103Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/25Mapping addresses of the same type
    • H04L61/2503Translation of Internet protocol [IP] addresses
    • H04L61/2514Translation of Internet protocol [IP] addresses between local and global IP addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The application discloses a method, a device, equipment and a medium for accessing micro services in a gateway proxy scene, and belongs to the technical field of Internet. The method comprises the following steps: receiving an access request sent by a user through a public network; based on the public network domain name of the target micro service determined by the API gateway according to the access request; determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule; and carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header. According to the technical scheme, the public network domain name in the access request sent by the user through the public network can be converted into the intranet domain name, the intranet domain name is subjected to intranet DNS analysis, the intranet address is determined, the access request is sent to the target micro-service interface, the network overhead is reduced, and meanwhile the influence of the public network stability is reduced.

Description

Micro-service access method, device, equipment and medium in gateway proxy scene
Technical Field
The application belongs to the technical field of Internet, and particularly relates to a method, a device, equipment and a medium for accessing micro services in a gateway proxy scene.
Background
The micro-service architecture enables a large system of micro-services, each of which is responsible for handling specific business logic. And the API gateway serves as an entrance of the whole system and is used for receiving the request of the client and distributing the request to the corresponding micro-service according to the target path or other conditions of the request.
Currently, forwarding a gateway proxy offload architecture request to a backend service via a gateway is performed through a public network. But as the amount of access requests increases, forwarding in the public network environment increases network bandwidth overhead, and environmental stability is also susceptible to public network quality.
Therefore, how to adjust the existing gateway forwarding architecture to avoid the problem that the access quality of the micro service is affected by the network environment of the public network and the additional overhead is caused to the public network by the access of the micro service is a technical problem to be solved by the skilled person.
Disclosure of Invention
An object of the embodiment of the present invention is to provide a method, an apparatus, a device, and a medium for accessing a micro-service in a gateway proxy scenario, which can convert a public network domain name in an access request sent by a user through a public network into an intranet domain name, perform intranet DNS resolution on the intranet domain name, determine an intranet address, and send the access request to a target micro-service interface, thereby reducing network overhead and reducing the influence of public network stability.
In a first aspect, an embodiment of the present application provides a method for accessing a micro service in a gateway proxy scenario, where the method includes:
receiving an access request sent by a user through a public network;
based on the public network domain name of the target micro service determined by the API gateway according to the access request;
determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule;
and carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header.
Further, before determining the intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule, the method further includes:
and stopping access to the public network address of the target micro-service based on the public network domain name through a pre-constructed configuration file.
Further, before determining the intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule, the method further includes:
and determining an intranet domain name corresponding to the public network domain name of each micro service according to all downstream micro services managed by the current API gateway, and storing the intranet domain name in a configuration file.
Further, the configuration file includes: an upstream profile.
Further, the method further comprises:
and if the analysis address of the intranet domain name is identified to be changed, synchronously changing the intranet DNS analysis in the DNS server.
Further, before determining the public network domain name of the target micro service according to the access request based on the API gateway, the method further includes:
and determining the target micro-service of the access request according to the load capacity of the downstream micro-service and the preset load weight based on the API gateway.
In a second aspect, an embodiment of the present application provides a micro service access apparatus in a gateway proxy scenario, where the apparatus includes:
the access request receiving module is used for receiving an access request sent by a user through a public network;
the public network domain name determining module is used for determining the public network domain name of the target micro-service according to the access request based on the API gateway;
the intranet domain name determining module is used for determining an intranet domain name corresponding to the public network domain name of the target micro-service based on a predefined conversion rule;
and the request sending module is used for carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service and sending a request to the interface of the target micro-service with a public network domain name request head.
Further, the device further comprises:
and the access stopping module is used for stopping the access of the public network address of the target micro-service based on the public network domain name through a pre-constructed configuration file.
In a third aspect, embodiments of the present application provide an electronic device comprising a processor, a memory and a program or instruction stored on the memory and executable on the processor, the program or instruction implementing the steps of the method according to the first aspect when executed by the processor.
In a fourth aspect, embodiments of the present application provide a readable storage medium having stored thereon a program or instructions which when executed by a processor implement the steps of the method according to the first aspect.
In a fifth aspect, embodiments of the present application provide a chip, where the chip includes a processor and a communication interface, where the communication interface is coupled to the processor, and where the processor is configured to execute a program or instructions to implement a method according to the first aspect.
In the embodiment of the application, an access request sent by a user through a public network is received; based on the public network domain name of the target micro service determined by the API gateway according to the access request; determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule; and carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header. By the aid of the micro-service access method in the gateway proxy scene, public network domain names in access requests sent by users through the public network can be converted into intranet domain names, intranet domain names are subjected to intranet domain name analysis, intranet addresses are determined, the access requests are sent to the target micro-service interfaces, network overhead is reduced, and meanwhile influence of public network stability is reduced.
Drawings
Fig. 1 is a flowchart of a micro service access method in a gateway proxy scenario provided in an embodiment of the present application;
fig. 2 is a flow chart of a micro service access method in a gateway proxy scenario provided in the second embodiment of the present application;
fig. 3 is a flow chart of a micro service access method in a gateway proxy scenario provided in the third embodiment of the present application;
fig. 4 is a flowchart of a micro service access method in a gateway proxy scenario provided in the fourth embodiment of the present application;
fig. 5 is a flow chart of a micro service access method in a gateway proxy scenario provided in a fifth embodiment of the present application;
fig. 6 is a schematic structural diagram of a micro service access device in a gateway proxy scenario provided in the sixth embodiment of the present application;
fig. 7 is a schematic structural diagram of an electronic device according to a seventh embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the following detailed description of specific embodiments thereof is given with reference to the accompanying drawings. It is to be understood that the specific embodiments described herein are merely illustrative of the application and not limiting thereof. It should be further noted that, for convenience of description, only some, but not all of the matters related to the present application are shown in the accompanying drawings. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although a flowchart depicts operations (or steps) as a sequential process, many of the operations can be performed in parallel, concurrently, or at the same time. Furthermore, the order of the operations may be rearranged. The process may be terminated when its operations are completed, but may have additional steps not included in the figures. The processes may correspond to methods, functions, procedures, subroutines, and the like.
Technical solutions in the embodiments of the present application will be clearly described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application are within the scope of the protection of the present application.
The terms first, second and the like in the description and in the claims, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged, as appropriate, such that embodiments of the present application may be implemented in sequences other than those illustrated or described herein, and that the objects identified by "first," "second," etc. are generally of a type and not limited to the number of objects, e.g., the first object may be one or more. Furthermore, in the description and claims, "and/or" means at least one of the connected objects, and the character "/", generally means that the associated object is an "or" relationship.
The method, the device, the equipment and the medium for accessing the micro service in the gateway proxy scene provided by the embodiment of the application are described in detail by specific embodiments and application scenes thereof with reference to the accompanying drawings.
Example 1
Fig. 1 is a flowchart of a micro service access method in a gateway proxy scenario according to an embodiment of the present application. As shown in fig. 1, the method specifically comprises the following steps:
s101, receiving an access request sent by a user through a public network;
the application scenario of the scheme may be a scenario in which when a user requests to access a network, an API gateway receives an access request of the user, obtains an intranet domain name of a target micro-service according to a conversion rule, determines an intranet address of the target micro-service through intranet DNS resolution, and sends a request to an interface of the target micro-service.
Based on the above usage scenario, it can be understood that the execution body of the application may be the API gateway, or may be a desktop computer, a notebook computer, a tablet computer, an interactive multimedia device, etc. running the API gateway, which is not limited in any way.
The public network can be a remote network for connecting local area networks of different areas or computer communication. And the system has a large physical range, and can connect a plurality of areas, cities and countries to provide long-distance communication for the areas, cities and countries. The access request may be that after the user inputs a website to the browser, the browser resolves the domain name into a corresponding IP address, finds a corresponding server on the internet, and sends a protocol request packet to the server by the client to request a resource document in the server.
The method of receiving the access request of the user may be that the user inputs a web address to be accessed to a browser, the browser parses the web address into a corresponding IP address, and the IP address is transmitted from the client to the API gateway and received by the API gateway.
S102, determining a public network domain name of a target micro service according to the access request based on the API gateway;
the API gateway can be regarded as an entrance for communicating the system with the outside, and logic for processing some non-business logic, such as authority verification, monitoring, buffering, request routing and the like, can be performed through the gateway. The micro-service can be a micro-service architecture, which is a software architecture mode. The application is constructed into a series of small autonomous services which are divided into modules according to the service field. In micro services, each service is self-contained and implements a single business function. The target micro-service may be a micro-service that the user needs to access. The public network domain name may be an identifier of a host in a public network environment, and is a name of a certain computer or a computer group on the Internet, which is formed by a series of names separated by dots, and is used to identify an electronic azimuth (sometimes also referred to as a geographic location) of the computer during data transmission.
The public network domain name of the target micro-service can be determined by the API, after receiving an access request sent by a user, analyzing and reading the access request, extracting information such as a demand function and the like in the access request, and screening micro-services meeting the demand function condition and meeting the user request from all micro-services accessing to the API gateway as the target micro-service. And sending a domain name request to the target micro-service, and extracting the public domain name of the target micro-service from the returned information after the target micro-service responds.
S103, determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule;
the predefined conversion rule may be to collect public network domain names and intranet domain names of all micro services in advance, and store the public network domain names and intranet domain names of the same micro service in a designated position of the API gateway correspondingly. The intranet domain name can be a virtual domain name which only takes effect in the associated VPC, has the characteristics of random creation and use, can not be purchased by a domain name registrar, and can not pass through a record.
The method for determining the intranet domain name of the target micro-service may be that after the public domain name of the target micro-service is obtained, a conversion rule pre-stored in the API gateway is called, and the intranet domain name corresponding to the public domain name of the target micro-service is determined according to the mapping relationship between the public domain name and the intranet domain name.
S104, carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request head.
The intranet DNS resolution may be a method of resolving an intranet domain name of the target microservice into an intranet address. The public network domain name request header may be part of the HTTP protocol used to convey additional information about the request. The request header contains metadata required for communication between the client (typically a browser or application) and the server. In the process of accessing the micro server, only the intranet address cannot access the micro server, and the micro server can be normally accessed only by carrying the intranet domain name request head.
The method for performing intranet DNS resolution on the intranet domain name may be a recursive query method. Specifically, if the local domain name server queried by the host does not know the IP address of the queried domain name, the local domain name server continues to send query request messages to other root domain name servers according to the identity of the DNS client, that is, continues to query instead of the host until the server knowing the IP address of the queried domain name is queried.
The method of sending the request to the micro-service interface may be that the obtained intranet domain name is subjected to intranet DNS resolution, the intranet address corresponding to the intranet domain name is obtained through the information returned by the server, the intranet address and the request header of the public network domain name are written into the access request instruction together, and the access request instruction is sent to the interface corresponding to the micro-service.
For example, a user may first request an API gateway through a public network to access a downstream micro-service, and send an access request to the API gateway. The API gateway forwards the reverse proxy to a downstream micro-service interface public network domain name www.baidu.com according to a user request, the capturing of the public network domain name is completed by inputting www.baidu.com an upstream configuration file, the public network domain name is converted into an intranet domain name by inputting the upstream configuration file, the intranet domain name is converted into an intranet address by intranet DNS (domain name) resolution, and finally, an access request is sent to a downstream micro-service intranet entrance through a request header file carrying the public network domain name by the intranet address. In this example, compared with the public network portal accessing the downstream micro service, the sending of the access request to the downstream micro service intranet portal can reduce the request bandwidth of the whole platform service public network by 20%, and the cost is greatly optimized.
Moreover, the access request sent to the downstream micro-service through the intranet entrance can also reduce the damage range of the fault to a certain extent, for example, if the NAT exit gateway is abnormal due to the fault of a certain machine room of the messenger cloud, the IP address of the server exit network part is not available. The downstream micro service of the request coming from the user is not forwarded through the public network through the gateway intranet forwarding transformation, so that the fault plane can be greatly reduced.
In the embodiment of the application, an access request sent by a user through a public network is received; based on the public network domain name of the target micro service determined by the API gateway according to the access request; determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule; and carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header. By the aid of the micro-service access method in the gateway proxy scene, public network domain names in access requests sent by users through the public network can be converted into intranet domain names, intranet domain names are subjected to intranet domain name analysis, intranet addresses are determined, the access requests are sent to the target micro-service interfaces, network overhead is reduced, and meanwhile influence of public network stability is reduced.
Example two
Fig. 2 is a flowchart of a micro service access method in a gateway proxy scenario provided in the second embodiment of the present application. The scheme makes better improvement on the embodiment, and the specific improvement is as follows: before determining the intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule, the method further comprises: and stopping access to the public network address of the target micro-service based on the public network domain name through a pre-constructed configuration file.
As shown in fig. 2, the method specifically includes the following steps:
s201, receiving an access request sent by a user through a public network;
s202, determining a public network domain name of a target micro service according to the access request based on the API gateway;
s203, stopping access to the public network address of the target micro service based on the public network domain name through a pre-constructed configuration file;
the pre-built configuration file can be a configuration file capable of providing transverse processing capability crossing a single machine and realizing the receiving, processing and forwarding of network data. Public network addresses, which may be referred to as globally unique IP addresses, refer to IP addresses that can be accessed directly on the Internet. The public network address is distributed by an Internet registration mechanism, has global uniqueness and global accessibility, can directly access other devices on the Internet, and can carry out communication and data transmission through the Internet.
The method for stopping the access to the target micro-service may be that after the public network domain name of the target service is obtained, the API gateway automatically accesses the public network address of the target micro-service through the public network domain name, so as to occupy the public network resource. Through the pre-constructed configuration file, the weight of the access to the intranet address can be increased, so that the API gateway does not access to the public network address preferentially.
S204, determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule;
s205, carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header.
Optionally, the configuration file includes: an upstream profile.
The upstream configuration file can be a module for enabling the reverse proxy server to cross the limit of a single machine, getting rid of the limit that only a single function can be provided for the terminal node, completing the receiving, processing and forwarding of network data, and realizing the conversion from public network analysis to intranet analysis. The up stream profile may provide four algorithms to balance the load, including:
round robin: a default load balancing algorithm. If the server farm does not define a load balancing algorithm, the request will be routed to hosts in the server farm in a round robin fashion.
least_conn: the algorithm will route the new request to the back-end host with the least active connections while taking into account the weight of the server. If there are a plurality of such servers, then an attempt is made to use a weighted round robin balancing algorithm.
ip_hash: requests are allocated in the server group according to the client IP. The algorithm ensures that requests from the unified client will always be passed to the same server unless the server is not available.
hash: a hash-based server group is mapped for the client-server, which may contain text, variables, or a combination thereof.
The configuration file can stop the access of the public network domain name to the public network address of the target micro service, so that the network broadband overhead is reduced, the occupation of public network resources is avoided, and the preparation is made for the subsequent access of the target micro service through the intranet.
Example III
Fig. 3 is a flowchart of a micro service access method in a gateway proxy scenario provided in the third embodiment of the present application. The scheme makes better improvement on the embodiment, and the specific improvement is as follows: before determining the intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule, the method further comprises: and determining an intranet domain name corresponding to the public network domain name of each micro service according to all downstream micro services managed by the current API gateway, and storing the intranet domain name in a configuration file.
As shown in fig. 3, the method specifically includes the following steps:
s301, receiving an access request sent by a user through a public network;
s302, determining a public network domain name of a target micro service according to the access request based on the API gateway;
s303, determining an intranet domain name corresponding to a public network domain name of each micro service according to all downstream micro services managed by the current API gateway, and storing the intranet domain name in a configuration file;
the manner of determining the intranet domain name corresponding to the public network domain name of each micro service may be that the API gateway sends the public network domain name to the managed downstream micro service and obtains the request corresponding to the intranet domain name, and after receiving the response of each micro service, extracts the intranet domain name in the returned information, and stores the intranet domain name in association with the public network domain name of the corresponding micro service.
The manner of storing the public network domain name and the corresponding intranet domain name of each micro service in the configuration file may be to associate the public network domain name and the corresponding intranet domain name of each micro service, write in a search table, and store the public network domain name and the corresponding intranet domain name in the corresponding position of the configuration file in the form of a table.
S304, determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule;
s305, carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header.
The method has the advantages that the intranet domain name corresponding to the public network domain name of each micro-service can be stored in the configuration file in advance, so that the corresponding intranet domain name can be quickly and accurately obtained when the domain name of the target micro-service is converted.
Example IV
Fig. 4 is a flowchart of a micro service access method in a gateway proxy scenario provided in the fourth embodiment of the present application. The scheme makes better improvement on the embodiment, and the specific improvement is as follows: the method further comprises the steps of: and if the analysis address of the intranet domain name is identified to be changed, synchronously changing the intranet DNS analysis in the DNS server.
As shown in fig. 4, the method specifically includes the following steps:
s401, receiving an access request sent by a user through a public network;
s402, determining a public network domain name of the target micro-service according to the access request based on the API gateway;
s403, determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule;
s404, carrying out internal network DNS analysis according to the internal network domain name, and if the analysis address of the internal network domain name is identified to be changed, synchronously changing the internal network DNS analysis in the DNS server;
the DNS server may be a domain name server, and is a server for converting a domain name and an IP address corresponding to the domain name. The DNS server maintains a table of domain names and IP addresses corresponding thereto to resolve domain names of messages.
The method of identifying the change of the resolved address of the intranet domain name may be to compare the current resolved intranet address with the historical intranet address, and if the current intranet address is inconsistent with the historical intranet address, confirm that the resolved address of the intranet domain name is changed.
The method for synchronously changing the internal network DNS resolution in the DNS server may be that, after recognizing that the resolved address of the internal network domain name is changed, the changed internal network domain name is extracted from the table of the domain name resolved by the internal network DNS and the corresponding IP address, and the address of the internal network domain name is cleared and written into the new address after the change.
S405, determining an intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header.
The method has the advantages that when the analysis address of the intranet domain name is identified to be changed, the intranet DNS analysis in the DNS server can be synchronously changed, so that the analysis address is monitored, the intranet DNS analysis is updated in time, and the accuracy of the intranet address is ensured.
Example five
Fig. 5 is a flowchart of a micro service access method in a gateway proxy scenario provided in the fifth embodiment of the present application. The scheme makes better improvement on the embodiment, and the specific improvement is as follows: before determining the public network domain name of the target micro service according to the access request based on the API gateway, the method further comprises: and determining the target micro-service of the access request according to the load capacity of the downstream micro-service and the preset load weight based on the API gateway.
As shown in fig. 5, the method specifically includes the following steps:
s501, receiving an access request sent by a user through a public network;
s502, determining a target micro-service of the access request according to the load capacity of the downstream micro-service and a preset load weight based on the API gateway;
the load amount may be the number of tasks being processed by the downstream micro-service and the number of tasks to be processed. The preset load weight may be a preset duty ratio of the total tasks that the micro-service needs to process. When the API elbow is unbalanced according to the downstream micro-service performance distribution, the micro-service with higher performance and higher efficiency should be provided with a larger weight so as to reduce the burden of the micro-service with lower performance and prevent slow task processing.
The method for determining the target micro-service of the access request may be to extract a demand function in the access request, screen a corresponding micro-service according to the demand function, pre-select a micro-service with a large preset load weight and a small load as the target micro-service in the screened micro-service, and select a micro-service with a small preset load weight and a small load as the target micro-service if the load in the micro-service with a large preset load weight exceeds the load of the micro-service.
S503, determining a public network domain name of the target micro-service according to the access request based on the API gateway;
s504, determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule;
s505, carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header.
The method and the system have the advantages that the target micro-service can be determined according to the load capacity of the downstream micro-service and the preset load weight, so that the pressure of the micro-service for receiving the access request is relieved, and the response efficiency of the target micro-service is guaranteed to a certain extent.
Example six
Fig. 6 is a schematic structural diagram of a micro service access device in a gateway proxy scenario provided in the sixth embodiment of the present application.
As shown in fig. 6, the method specifically includes the following steps:
an access request receiving module 601, configured to receive an access request sent by a user through a public network;
a public network domain name determining module 602, configured to determine a public network domain name of the target micro service according to the access request based on the API gateway;
an intranet domain name determining module 603, configured to determine an intranet domain name corresponding to the public domain name of the target micro service based on a predefined conversion rule;
the request sending module 604 is configured to perform intranet DNS resolution according to the intranet domain name, determine an intranet address of the target micro service, and send a request to an interface of the target micro service with a public network domain name request header.
Correspondingly, the device further comprises:
and the access stopping module is used for stopping the access of the public network address of the target micro-service based on the public network domain name through a pre-constructed configuration file.
In this embodiment of the present application, an access request receiving module is configured to receive an access request sent by a user through a public network; the public network domain name determining module is used for determining the public network domain name of the target micro-service according to the access request based on the API gateway; the intranet domain name determining module is used for determining an intranet domain name corresponding to the public network domain name of the target micro-service based on a predefined conversion rule; and the request sending module is used for carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service and sending a request to the interface of the target micro-service with a public network domain name request head. Through the micro-service access device in the gateway proxy scene, the public network domain name in the access request sent by the user through the public network can be converted into the intranet domain name, the intranet domain name is subjected to intranet domain name analysis, the intranet address is determined, the access request is sent to the target micro-service interface, the network overhead is reduced, and meanwhile the influence of the public network stability is reduced.
The micro service access device in the gateway proxy scenario in the embodiment of the present application may be a device, or may be a component, an integrated circuit, or a chip in a terminal. The device may be a mobile electronic device or a non-mobile electronic device. By way of example, the mobile electronic device may be a cell phone, tablet computer, notebook computer, palm top computer, vehicle mounted electronic device, wearable device, ultra-mobile personal computer (ultra-mobile personal computer, UMPC), netbook or personal digital assistant (personal digital assistant, PDA), etc., and the non-mobile electronic device may be a micro server, network attached storage (Network Attached Storage, NAS), personal computer (personal computer, PC), television (TV), teller machine or self-service machine, etc., and embodiments of the present application are not limited in particular.
The micro service access device in the gateway proxy scenario in the embodiment of the present application may be a device with an operating system. The operating system may be an Android operating system, an ios operating system, or other possible operating systems, which are not specifically limited in the embodiments of the present application.
The micro service access device in the gateway proxy scene provided in the embodiment of the present application can implement each process implemented by the above method embodiments, and in order to avoid repetition, details are not repeated here.
Example seven
As shown in fig. 7, the embodiment of the present application further provides an electronic device 700, including a processor 701, a memory 702, and a program or an instruction stored in the memory 702 and capable of running on the processor 701, where the program or the instruction implements each process of the micro service access device embodiment in the gateway proxy scenario when executed by the processor 701, and the same technical effects can be achieved, and for avoiding repetition, a detailed description is omitted herein.
The electronic device in the embodiment of the application includes the mobile electronic device and the non-mobile electronic device described above.
Example eight
The embodiment of the present application further provides a readable storage medium, where a program or an instruction is stored on the readable storage medium, and when the program or the instruction is executed by a processor, the processes of the micro service access device embodiment in the gateway proxy scenario are implemented, and the same technical effects can be achieved, so that repetition is avoided, and no redundant description is provided herein.
Wherein the processor is a processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium such as a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk or an optical disk, and the like.
Example nine
The embodiment of the application further provides a chip, the chip includes a processor and a communication interface, the communication interface is coupled with the processor, the processor is used for running a program or an instruction, implementing each process of the micro service access device embodiment in the gateway proxy scene, and achieving the same technical effect, so as to avoid repetition, and no redundant description is provided here.
It should be understood that the chips referred to in the embodiments of the present application may also be referred to as system-on-chip chips, chip systems, or system-on-chip chips, etc.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element. Furthermore, it should be noted that the scope of the methods and apparatus in the embodiments of the present application is not limited to performing the functions in the order shown or discussed, but may also include performing the functions in a substantially simultaneous manner or in an opposite order depending on the functions involved, e.g., the described methods may be performed in an order different from that described, and various steps may also be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.
From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solutions of the present application may be embodied essentially or in a part contributing to the prior art in the form of a computer software product stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk), comprising several instructions for causing a terminal (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the methods described in the embodiments of the present application.
The embodiments of the present application have been described above with reference to the accompanying drawings, but the present application is not limited to the above-described embodiments, which are merely illustrative and not restrictive, and many forms may be made by those of ordinary skill in the art without departing from the spirit of the present application and the scope of the claims, which are also within the protection of the present application.
The foregoing description is only of the preferred embodiments of the present application and the technical principles employed. The present application is not limited to the specific embodiments described herein, but is capable of numerous obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the present application. Therefore, while the present application has been described in connection with the above embodiments, the present application is not limited to the above embodiments, but may include many other equivalent embodiments without departing from the spirit of the present application, and the scope of the present application is determined by the scope of the claims.

Claims (10)

1. A method for micro-service access in a gateway proxy scenario, the method comprising:
receiving an access request sent by a user through a public network;
based on the public network domain name of the target micro service determined by the API gateway according to the access request;
determining an intranet domain name corresponding to the public network domain name of the target micro service based on a predefined conversion rule;
and carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service, and sending a request to an interface of the target micro-service with a public network domain name request header.
2. The method for accessing a micro service in a gateway proxy scenario according to claim 1, wherein before determining an intranet domain name corresponding to a public network domain name of the target micro service based on a predefined conversion rule, the method further comprises:
and stopping access to the public network address of the target micro-service based on the public network domain name through a pre-constructed configuration file.
3. The method for accessing a micro service in a gateway proxy scenario according to claim 1, wherein before determining an intranet domain name corresponding to a public network domain name of the target micro service based on a predefined conversion rule, the method further comprises:
and determining an intranet domain name corresponding to the public network domain name of each micro service according to all downstream micro services managed by the current API gateway, and storing the intranet domain name in a configuration file.
4. A method of micro service access in a gateway proxy scenario according to claim 2 or 3, wherein the configuration file comprises: an upstream profile.
5. The method of micro service access in a gateway proxy scenario of claim 1, further comprising:
and if the analysis address of the intranet domain name is identified to be changed, synchronously changing the intranet DNS analysis in the DNS server.
6. The method of claim 1, wherein prior to determining the public domain name of the target micro service according to the access request based on the API gateway, the method further comprises:
and determining the target micro-service of the access request according to the load capacity of the downstream micro-service and the preset load weight based on the API gateway.
7. A micro service access device in a gateway proxy scenario, the device comprising:
the access request receiving module is used for receiving an access request sent by a user through a public network;
the public network domain name determining module is used for determining the public network domain name of the target micro-service according to the access request based on the API gateway;
the intranet domain name determining module is used for determining an intranet domain name corresponding to the public network domain name of the target micro-service based on a predefined conversion rule;
and the request sending module is used for carrying out intranet DNS analysis according to the intranet domain name, determining the intranet address of the target micro-service and sending a request to the interface of the target micro-service with a public network domain name request head.
8. The micro service access apparatus in a gateway proxy scenario of claim 7, wherein the apparatus further comprises:
and the access stopping module is used for stopping the access of the public network address of the target micro-service based on the public network domain name through a pre-constructed configuration file.
9. An electronic device comprising a processor, a memory and a program or instruction stored on the memory and executable on the processor, which when executed by the processor, implements the steps of the micro-service access method in a gateway proxy scenario as claimed in any one of claims 1 to 6.
10. A readable storage medium, characterized in that it has stored thereon a program or instructions, which when executed by a processor, implement the steps of the micro service access method in a gateway proxy scenario according to any of claims 1-6.
CN202311623150.3A 2023-11-29 2023-11-29 Micro-service access method, device, equipment and medium in gateway proxy scene Pending CN117544628A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311623150.3A CN117544628A (en) 2023-11-29 2023-11-29 Micro-service access method, device, equipment and medium in gateway proxy scene

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311623150.3A CN117544628A (en) 2023-11-29 2023-11-29 Micro-service access method, device, equipment and medium in gateway proxy scene

Publications (1)

Publication Number Publication Date
CN117544628A true CN117544628A (en) 2024-02-09

Family

ID=89784055

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311623150.3A Pending CN117544628A (en) 2023-11-29 2023-11-29 Micro-service access method, device, equipment and medium in gateway proxy scene

Country Status (1)

Country Link
CN (1) CN117544628A (en)

Similar Documents

Publication Publication Date Title
US20220232027A1 (en) Rule-Based Network-Threat Detection
US9712422B2 (en) Selection of service nodes for provision of services
CN111800458B (en) Dynamic load balancing method and system for Kubernetes container cloud platform
US8756340B2 (en) DNS wildcard beaconing to determine client location and resolver load for global traffic load balancing
US9917889B2 (en) Enterprise service bus routing system
US11218437B2 (en) Method for network traffic forwarding, request sending, and communication acceleration, forwarding server and node server
CN106572197B (en) Network address translation method, device and system
US10397179B2 (en) Systems and methods for localization based on Internet terminal location
CN109040243B (en) Message processing method and device
CN106657180B (en) Information transmission method and device for cloud service, terminal equipment and system
WO2017096888A1 (en) Method and device for implementing domain name system
CN112954089B (en) Method, device, equipment and storage medium for analyzing data
US11768890B2 (en) Method and server apparatus for dynamically identifying pop-out links in networked applications via lookup
CN114389886B (en) Access method, device, equipment and storage medium of virtual private cloud service
CN109413224B (en) Message forwarding method and device
CN110708309A (en) Anti-crawler system and method
CN111600929B (en) Transmission line detection method, routing strategy generation method and proxy server
CN114448849A (en) Website IPv6 network support mode detection method and electronic equipment
US20220124194A1 (en) Enum server and congestion control method
US12003600B2 (en) Network coordination between proxy servers
CN117544628A (en) Micro-service access method, device, equipment and medium in gateway proxy scene
CN107666444B (en) Method and system for routing data flow
US10958580B2 (en) System and method of performing load balancing over an overlay network
KR101379803B1 (en) System for distributing abnormal traffic and method of distributing abnormal traffice using the same
CN111818134A (en) Data transmission method and device based on fog calculation in substation data center

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination