CN115529292A - Access request processing method, device, equipment, system and storage medium - Google Patents

Access request processing method, device, equipment, system and storage medium Download PDF

Info

Publication number
CN115529292A
CN115529292A CN202211241605.0A CN202211241605A CN115529292A CN 115529292 A CN115529292 A CN 115529292A CN 202211241605 A CN202211241605 A CN 202211241605A CN 115529292 A CN115529292 A CN 115529292A
Authority
CN
China
Prior art keywords
target
access request
domain name
load server
cluster
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.)
Granted
Application number
CN202211241605.0A
Other languages
Chinese (zh)
Other versions
CN115529292B (en
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.)
Agricultural Bank of China
Original Assignee
Agricultural Bank of China
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 Agricultural Bank of China filed Critical Agricultural Bank of China
Priority to CN202211241605.0A priority Critical patent/CN115529292B/en
Publication of CN115529292A publication Critical patent/CN115529292A/en
Application granted granted Critical
Publication of CN115529292B publication Critical patent/CN115529292B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

The embodiment of the application provides an access request processing method, an access request processing device, an access request processing system and a storage medium.

Description

Access request processing method, device, equipment, system and storage medium
Technical Field
The present application relates to the field of data processing technologies, and in particular, to a method, an apparatus, a device, a system, and a storage medium for processing an access request.
Background
The red hat cloud, or OpenShift Container Platform (OCP for short), is a mature commercial cloud Platform provided by red hat companies, has the capabilities of application containerization release, rapid expansion and contraction, and the like, and currently, mainly provides an engine technology for large-scale telecommunications, streaming video, games, banks, and other applications.
However, due to the domain name limitation of the red-hat cloud, all applications deployed in the multi-application cloud platform on the red-hat cloud must share one namespace to manage containerized resources, that is, all applications need to share the same set of domain name to implement page access or interface response, which causes a problem of domain name contention when the cloud platform deploys the applications.
In the prior art, a plurality of sets of domain names are reapplied for all applications in a multi-application cloud platform, and codes related to request addresses are rebuilt to solve the problem of domain name contention, so that the problem of large rebuilding workload exists in the prior art.
Disclosure of Invention
Embodiments of the present application provide an access request processing method, apparatus, device, system, and storage medium, so as to solve a problem in the prior art that a modification workload is large.
In a first aspect, an embodiment of the present application provides an access request processing method, which is applied to a target soft load server in a soft load server cluster, where the soft load server cluster is located in an access request processing system, the access request processing system further includes a hard load server cluster, and the method includes:
receiving an initial access request sent by the hard load server cluster, wherein the initial access request comprises context root information and domain name information;
determining a user-defined domain name address of a target application which a user requests to access according to the context root information;
according to the user-defined domain name address, the domain name information is changed to obtain a target access request;
determining a target entry server matched with the context root information in an entry server cluster of the multi-application cloud platform;
and forwarding the target access request to the target portal server so that the target portal server distributes the target access request to a target container in a containerization application cluster of the multi-application cloud platform according to the context root information and the custom domain name address.
In a second aspect, an embodiment of the present application provides an access request processing apparatus, which is integrated in a target soft load server in a soft load server cluster, where the soft load server cluster is located in an access request processing system, and the access request processing system further includes a hard load server cluster, and the apparatus includes:
a communication module, configured to receive an initial access request sent by the hard load server cluster, where the initial access request includes context root information and domain name information;
the processing module is used for determining a user-defined domain name address of a target application which a user requests to access according to the context root information; according to the user-defined domain name address, the domain name information is changed to obtain a target access request; determining a target portal server matched with the context root information in a portal server cluster of the multi-application cloud platform;
the communication module is further configured to forward the target access request to the target portal server, so that the target portal server distributes the target access request to a target container in a containerized application cluster of the multi-application cloud platform according to the context root information and the custom domain name address.
In a third aspect, an embodiment of the present application provides a target soft load server, including a memory, a processor, and a computer program stored on the memory and executable on the processor, where the processor implements the access request processing method according to the first aspect when executing the program.
In a fourth aspect, an embodiment provides an access request processing system, including: a hard load server cluster and a soft load server cluster, wherein the soft load server cluster comprises the target soft load server according to the third aspect.
In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored, and the program, when executed by a processor, implements the access request processing method according to the first aspect.
According to the access request processing method, device, equipment, system and storage medium provided by the embodiment of the application, a target soft load server in a soft load server cluster receives an initial access request sent by a hard load server cluster, the initial access request comprises context root information and domain name information, a user-defined domain name address of a target application which a user requests to access is determined according to the context root information, the domain name information is changed according to the user-defined domain name address to obtain a target access request, a target entry server which is matched with the context root information in an entry server cluster of a multi-application cloud platform is determined, and the target access request is forwarded to the target entry server, so that the target entry server distributes the target access request to a target container in a containerized application cluster of the multi-application cloud platform according to the context root information and the user-defined domain name address. The domain name information in all the received access request message headers is set based on the soft load server cluster and is consistent with virtual domain name addresses defined for different name spaces in the multi-application cloud platform, so that the application of multiple sets of domain names and large-scale code transformation are not needed, the domain name contention problem is solved, and the transformation workload of the system is reduced.
It should be understood that the statements in this section are not intended to identify key or critical features of the embodiments of the present application, nor are they intended to limit the scope of the present application. Other features of the present application will become apparent from the following description.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a schematic structural diagram of an access request processing system according to an embodiment of the present application;
fig. 2 is a schematic flowchart of an access request processing method according to an embodiment of the present application;
fig. 3 is a schematic diagram of a forwarding path of an access request according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of an access request processing apparatus according to a second embodiment of the present application;
fig. 5 is a schematic structural diagram of a target soft load server according to a third embodiment of the present application.
Detailed Description
In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only partial 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 without making any creative effort shall fall within the protection scope of the present application.
It should be noted that the terms "target," "original," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
Assuming that a platform a is a large-scale web page platform developed by depending on an OCP, the platform a is formed by 20 applications together, a development team is formed by different functional groups, and the applications belong to different systems, the applications share the same set of domain name to realize page access or interface response, after the applications go to the cloud, if a namespace is shared to manage containerized resources, the problems of no authority control, cloud resource contention, unclear system boundary, management confusion and the like are caused.
Based on the technical problems in the prior art, the embodiment of the application provides an access request processing system, a soft load server cluster is arranged in the access request processing system, and the soft load server cluster sets the domain name information in all the received access request message headers to be consistent with virtual domain name addresses defined for different namespaces in a multi-application cloud platform, so that the aims of multiplexing the current deployment architecture and the code logic by all applications in the platform A, carrying out cross-namespace management on the same cloud and supporting the personalized deployment mode of a heterogeneous system under the scenes of not modifying codes, not re-applying F5 loads and domain names and the like are fulfilled.
Example one
Fig. 1 is a schematic structural diagram of an access request processing system according to an embodiment of the present disclosure, where the access request processing system provided in the embodiment of the present disclosure is disposed between a user and a multi-application cloud platform (e.g., a red hat cloud), and is configured to process domain name information of an access request sent by the user to the multi-application cloud platform, and forward the processed access request to an entry server in the multi-application cloud platform. As shown in fig. 1, the access request processing system according to the embodiment of the present application includes a hard load server cluster and a soft load server cluster, and the multi-application cloud platform according to the embodiment of the present application includes an entry server cluster and a containerized application cluster.
In the embodiments of the present application, the servers included in the hard load server cluster, the soft load server cluster, the portal server cluster, and the containerized application cluster are respectively called a hard load server, a soft load server, a portal server, and an application server, and the servers that process the received access request in the hard load server cluster, the soft load server cluster, the portal server cluster, and the containerized application cluster are respectively called a target hard load server, a target soft load server, a target portal server, and a target container.
In the embodiment of the application, the hard load server cluster receives the access request sent by the user side and forwards the access request by adopting the target hard load server according to the preset strategy, so that load balancing is realized, single-point faults are avoided, and the service processing capacity of the system is improved.
Optionally, the hard load server cluster is an F5 application system.
In the embodiment of the application, a target soft load server in the soft load server cluster is used for processing the domain name information in the message header of the received access request to make the domain name information consistent with the domain name information defined for a plurality of namespaces in the containerized application cluster, and finally, the access request carrying the modified domain name information is forwarded to the entrance server cluster, so that the entrance server cluster distributes the access request to the corresponding application server.
Optionally, the soft load server cluster is an Nginx server cluster.
Fig. 2 is a schematic flowchart of an access request processing method provided in an embodiment of the present application, where the method of this embodiment may be executed by an access request processing apparatus provided in the embodiment of the present application, and the apparatus may be implemented by software and/or hardware, and may be integrated in a target soft load server in a soft load server cluster. As shown in fig. 2, the access request processing method of this embodiment includes:
s201, receiving an initial access request sent by the hard load server cluster.
In this step, a target soft load server in the soft load server cluster receives an initial access request sent by the hard load server cluster.
It is understood that any one server in the soft load server cluster can be used as the target soft load server according to the requirement, so as to execute the access request processing method in S201-S205.
For the sake of distinction, in the present embodiment, an access request sent from the hard load server cluster to the soft load server cluster is called an initial access request.
In one possible implementation, as shown in fig. 1, when a user inputs a domain name address or an IP address on a front-end page, an initial access request is generated by a user device and sent to a target hard load server in a hard load server cluster, after receiving the initial access request, the target hard load server determines a target soft load server according to information in the initial access request and forwards the initial access request to the target soft load server, and accordingly, the target soft load server receives the initial access request sent by the target hard load server.
In some embodiments, the target hard load server may be a server in any one of the hard load server clusters, a policy for determining the target hard load server may be preset, and accordingly, in this step, the target hard load server is determined according to the preset policy, for example, the target hard load server is determined according to a polling algorithm.
In other embodiments, the target hard load server may be a hard load server in the hard load server cluster that matches the domain name address or the IP address input by the user, a first configuration file containing a mapping relationship between the access address (domain name address and/or IP address) and the address of the hard load server in the hard load server cluster may be generated in advance, and accordingly, in this step, the target hard load server is determined according to the first configuration file.
In this embodiment, the header of the initial access request includes context root information and domain name information,
the context root information represents the service resource position of each application in the multi-application cloud platform. After receiving the initial access request, the target hard load server determines a target soft load server for processing the initial access request according to the context root information in the initial access request, and then forwards the initial access request to the target soft load server.
The domain name information is consistent with an access address input by a user on a front-end page, and specifically, if the initial access request is a domain name access request, the domain name information is a domain name address input by the user on the front-end page; and if the initial access request is an IP access request, the domain name information is an IP address input by the user on the front-end page.
S202, determining a user-defined domain name address of the target application which the user requests to access according to the context root information.
In this step, the target soft load server, after parsing the context root information from the initial access request, determines the user-defined domain name address of the target namespace in which the target application requested to be accessed by the user is deployed according to the context root information.
In order to enable a user to access different applications in the multi-application cloud platform by using the same domain name address, in this embodiment, different custom domain name addresses are set for different namespaces in advance.
Optionally, in this embodiment, a second configuration file including a mapping relationship between the context root information and the custom domain name address may be generated in advance, and the second configuration file may be stored in each soft load server. Correspondingly, in this step, the target soft load server determines the user-defined domain name address of the target application which the user requests to access according to the second configuration file.
S203, according to the user-defined domain name address, the domain name information is changed to obtain a target access request.
In this step, the target soft load server replaces the domain name address or the IP address in the domain name information with the customized domain name address determined in S202, so as to obtain a target access request.
For the sake of distinction, in this embodiment, an access request generated by the target soft load server and sent by the soft load server cluster to the portal server cluster is called a target access request.
The target access request comprises context root information and domain name information with the content of a user-defined domain name address. Optionally, a header of the target access request includes context root information and a custom domain name address.
And S204, determining a target portal server matched with the context root information in the portal server cluster of the multi-application cloud platform.
In this step, after the context root information is parsed from the initial access request, the target soft load server determines a target portal server in the portal server cluster, which is matched with the context root information.
Optionally, in this embodiment, a third configuration file including a mapping relationship between the context root information and the address of the entry server may be generated in advance, and the third configuration file may be stored in each soft load server. Correspondingly, in this step, the target soft load server determines the target portal server matched with the context root information according to the third configuration file.
It should be noted that, in this embodiment, there is no precedence order between S204 and S203, and S204 may be executed after or during S203, or may be executed simultaneously with S203, which is not limited herein.
S205, the target access request is forwarded to the target entrance server, so that the target entrance server distributes the target access request to a target container in a containerized application cluster of the multi-application cloud platform according to the context root information and the user-defined domain name address.
In this step, the target soft load server forwards the target access request generated in S203 to the target portal server determined in S204. And after the target access request is analyzed by the target entry server to obtain the context root information and the user-defined domain name address, determining a container for providing the relevant service of the target application in the containerized application cluster according to the context root information and the user-defined domain name address, and distributing the target access request to a target container.
In this embodiment, the applications are deployed in the namespace in a containerized form, and each application may correspond to multiple containers.
Wherein the target container is any one of a plurality of containers providing the target application related service. Illustratively, the target container may be a container currently in an idle state among a plurality of containers providing the target application service.
Fig. 3 is a schematic diagram of a forwarding path of An access request according to An embodiment of the present application, where Route-a and Route-B in fig. 3 represent routing components, service-a and Service-B represent Service components, pod-A1, pod-A2, \ 8230 \ 8230;, pod-An represent containers capable of providing application Service a, pod-B1, pod-B2, \8230;, and Pod-Bn represent containers capable of providing application Service B. As shown in fig. 3, in one possible implementation, the target portal server determines a target routing component (assumed to be Route-a) and a target Service component (assumed to be Service-a) that match the context root information and the custom domain name address, and distributes the target access request to the target container by invoking the target routing component and the target Service component.
Optionally, the target service component is configured to poll and dynamically update the available container list, and the target routing component is configured to send the target access request to a certain container in the available container list, that is, the target container.
Continuing with platform a as an example, assuming that 20 sub-applications under platform a belong to 7 systems, in the prior art, according to the planning, each system needs to apply for a namespace and correspond to a set of independent domain names, and the related transformation costs include, but are not limited to, the following:
1) Applying for at least 6 domain names according to the system dimension;
2) All domain names need to complete F5 mapping rule configuration to a server under the cloud;
3) Combing and informing all consumers of the sub application interfaces to modify the access addresses into domain name access;
4) Deleting redundant configuration in F5 mapping rules corresponding to the original domain name;
5) And after the sub-application goes to the cloud successively, modifying the F5 mapping rule configuration from the corresponding domain name to the Route entry server on the OCP cloud.
After the soft load server cluster is set, the key contents to be modified only include the following two aspects: firstly, defining an access server cluster on a multi-application cloud platform for distributing access requests; secondly, the domain name information of the access request message header needs to be set in a distribution strategy as a user-defined domain name distributed by a namespace, for the platform a, only one namespace can use a real domain name (DNS is resolvable), other six namespaces can use a user-defined virtual domain name (DNS is not resolvable, and no application is required), and the domain name information of all the access request message headers must correspond to a host in a Route component corresponding to an application.
Therefore, in the embodiment of the application, by introducing the soft load server cluster, and setting the domain name information in all the received access request headers by the soft load server cluster to make the domain name information consistent with the virtual domain name addresses defined for different name spaces in the multi-application cloud platform, the aims of multiplexing the current deployment architecture and the code logic by all the applications in the platform a and supporting the personalized deployment mode of the heterogeneous system on the same cloud without modifying codes and reapplicating F5 loads and domain names are achieved.
On the other hand, in the prior art, the overall cloud process is complicated, multi-party cooperation is needed, and smooth transition from cloud deployment to cloud deployment of the platform a is not facilitated.
In addition, various multi-application cloud platforms need to implement mapping with routing components based on domain names, but certain differences may exist among different multi-application cloud platforms, for example, some multi-application cloud platforms allow domain names to be shared across namespaces, some multi-application cloud platforms do not support route routing components and other routing components (such as Ingress) need to be adopted, and for the situation, the embodiment of the application can shield the difference of cloud platform technology selection, flexibly adapt to the routing components of various multi-application cloud platforms through soft loads, and support a mixed cloud deployment scene.
Example two
Fig. 4 is a schematic structural diagram of an access request processing apparatus according to a second embodiment of the present application, where the apparatus may be implemented by software and/or hardware, and may be integrated in a target soft load server in a soft load server cluster. As shown in fig. 4, the access request processing apparatus 10 in the present embodiment includes:
a communication module 11 and a processing module 12.
The communication module 11 is configured to receive an initial access request sent by a hard load server cluster, where the initial access request includes context root information and domain name information;
the processing module 12 is configured to determine a custom domain name address of a target application that a user requests to access according to the context root information; according to the user-defined domain name address, domain name information is changed to obtain a target access request; determining a target portal server matched with the context root information in a portal server cluster of the multi-application cloud platform;
the communication module 11 is further configured to forward the target access request to the target portal server, so that the target portal server distributes the target access request to a target container in a containerized application cluster of the multi-application cloud platform according to the context root information and the custom domain name address.
Optionally, the initial access request is sent by the user equipment to a target hard load server in the hard load server cluster when the user inputs a domain name address or an IP address on the front-end page, and the target hard load server is a hard load server in the hard load server cluster, which is matched with the domain name address or the IP address.
Optionally, if the initial access request is a domain name access request, the domain name information is a domain name address input by the user on the front-end page.
Optionally, if the initial access request is an IP access request, the domain name information is an IP address input by the user on the front-end page.
Optionally, the target soft load server is determined by the target hard load server according to the context root information.
Optionally, the target portal server is specifically configured to distribute the target access request to the target container by calling the target routing component and the target service component according to the context root information and the custom domain name address.
The access request processing device provided by the embodiment can execute the access request processing method provided by the method embodiment, and has corresponding functional modules and beneficial effects of the execution method. The implementation principle and technical effect of this embodiment are similar to those of the above method embodiments, and are not described in detail here.
EXAMPLE III
Fig. 5 is a schematic structural diagram of a target soft load server according to a third embodiment of the present application, and as shown in fig. 5, the target soft load server 20 includes a memory 21, a processor 22, and a computer program stored in the memory and executable on the processor; the number of the processors 22 in the electronic device 20 may be one or more, and one processor 22 is taken as an example in fig. 5; the processor 22 and the memory 21 in the electronic device 20 may be connected by a bus or other means, and fig. 5 illustrates the connection by the bus as an example.
The memory 21 is a computer-readable storage medium, and can be used for storing software programs, computer-executable programs, and modules, such as program instructions/modules corresponding to the communication module 11 and the processing module 12 in the embodiment of the present application. The processor 22 executes various functional applications of the target soft load server and access request processing by running software programs, instructions and modules stored in the memory 21, that is, implements the access request processing method described above.
The memory 21 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the storage data area may store data created according to the use of the terminal, and the like. Further, the memory 21 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some examples, memory 21 may further include memory located remotely from processor 22, which may be connected to a target soft load server through a grid. Examples of such a mesh include, but are not limited to, the internet, an intranet, a local area network, a mobile communications network, and combinations thereof.
Example four
A fourth embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, the computer program, when being executed by a computer processor, is configured to perform an access request processing method, the method including:
receiving an initial access request sent by a hard load server cluster, wherein the initial access request comprises context root information and domain name information;
determining a user-defined domain name address of a target application which a user requests to access according to the context root information;
according to the user-defined domain name address, changing the domain name information to obtain a target access request;
determining a target entry server matched with the context root information in an entry server cluster of the multi-application cloud platform;
and forwarding the target access request to a target entry server so that the target entry server distributes the target access request to a target container in a containerization application cluster of the multi-application cloud platform according to the context root information and the custom domain name address.
Of course, the computer program of a package computer-readable storage medium provided in this embodiment of the present application is not limited to the method operations described above, and may also perform related operations in the access request processing method provided in any embodiment of the present application.
From the above description of the embodiments, it is obvious for those skilled in the art that the present application can be implemented by software and necessary general hardware, and certainly can be implemented by hardware, but the former is a better embodiment in many cases. Based on such understanding, the technical solutions of the present application may be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as a floppy disk, a read-only memory (ROM), a Random Access Memory (RAM), a FLASH memory (FLASH), a hard disk or an optical disk of a computer, and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a grid device) to execute the methods described in the embodiments of the present application.
It should be noted that, in the embodiment of the access request processing apparatus, the included units and modules are merely divided according to functional logic, but are not limited to the above division as long as the corresponding functions can be implemented; in addition, specific names of the functional units are only used for distinguishing one functional unit from another, and are not used for limiting the protection scope of the present application.
It is to be noted that the foregoing is only illustrative of the preferred embodiments of the present application and the technical principles employed. It will be understood by those skilled in the art that the present application is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the application. Therefore, although the present application has been described in more detail with reference to the above embodiments, the present application is not limited to the above embodiments, and may include 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 appended claims.

Claims (10)

1. An access request processing method, applied to a target soft load server in a soft load server cluster, where the soft load server cluster is located in an access request processing system, and the access request processing system further includes a hard load server cluster, the method including:
receiving an initial access request sent by the hard load server cluster, wherein the initial access request comprises context root information and domain name information;
determining a user-defined domain name address of a target application which a user requests to access according to the context root information;
according to the user-defined domain name address, the domain name information is changed to obtain a target access request;
determining a target entry server matched with the context root information in an entry server cluster of the multi-application cloud platform;
and forwarding the target access request to the target portal server so that the target portal server distributes the target access request to a target container in a containerization application cluster of the multi-application cloud platform according to the context root information and the custom domain name address.
2. The method of claim 1, wherein the initial access request is sent by the user device to a target hard load server in the cluster of hard load servers when the user enters a domain name address or an IP address in a front-end page, and wherein the target hard load server is a hard load server in the cluster of hard load servers that matches the domain name address or the IP address.
3. The method according to claim 2, wherein if the initial access request is a domain name access request, the domain name information is a domain name address input by a user on a front-end page.
4. The method according to claim 2, wherein if the initial access request is an IP access request, the domain name information is an IP address entered by a user on a front-end page.
5. The method of claim 2, wherein the target soft load server is determined by the target hard load server based on the context root information.
6. The method of any of claims 1-5, wherein the target portal server is specifically configured to distribute the target access request to the target container by invoking a target routing component and a target service component according to the context root information and the custom domain name address.
7. An access request processing apparatus, wherein a target soft load server is integrated into a soft load server cluster, the soft load server cluster is located in an access request processing system, the access request processing system further includes a hard load server cluster, the apparatus comprises:
the communication module is used for receiving an initial access request sent by the hard load server cluster, wherein the initial access request comprises context root information and domain name information;
the processing module is used for determining a user-defined domain name address of a target application which a user requests to access according to the context root information; according to the user-defined domain name address, the domain name information is changed to obtain a target access request; determining a target portal server matched with the context root information in a portal server cluster of the multi-application cloud platform;
the communication module is further configured to forward the target access request to the target portal server, so that the target portal server distributes the target access request to a target container in a containerized application cluster of the multi-application cloud platform according to the context root information and the custom domain name address.
8. A target soft load server comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the access request processing method according to any one of claims 1 to 6 when executing the program.
9. An access request processing system, comprising: a hard load server cluster and a soft load server cluster, said soft load server cluster including a target soft load server as claimed in claim 8.
10. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, is adapted to carry out the method for processing an access request according to any one of claims 1 to 6.
CN202211241605.0A 2022-10-11 2022-10-11 Access request processing method, device, equipment, system and storage medium Active CN115529292B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211241605.0A CN115529292B (en) 2022-10-11 2022-10-11 Access request processing method, device, equipment, system and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211241605.0A CN115529292B (en) 2022-10-11 2022-10-11 Access request processing method, device, equipment, system and storage medium

Publications (2)

Publication Number Publication Date
CN115529292A true CN115529292A (en) 2022-12-27
CN115529292B CN115529292B (en) 2024-09-03

Family

ID=84702416

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211241605.0A Active CN115529292B (en) 2022-10-11 2022-10-11 Access request processing method, device, equipment, system and storage medium

Country Status (1)

Country Link
CN (1) CN115529292B (en)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108551488A (en) * 2018-05-03 2018-09-18 山东汇贸电子口岸有限公司 Distributed container cluster load balancing method based on domestic CPU and OS
CN109587290A (en) * 2019-01-04 2019-04-05 平安科技(深圳)有限公司 A kind of method and relevant apparatus of domain name mapping
CN110149423A (en) * 2019-07-04 2019-08-20 深圳市珍爱捷云信息技术有限公司 Domain name processing method, device, readable storage medium storing program for executing and electronic equipment
CN110704158A (en) * 2019-09-23 2020-01-17 凡普数字技术有限公司 Method, apparatus and storage medium for forwarding access requests within a container cluster
CN111614738A (en) * 2020-05-07 2020-09-01 北京金山云网络技术有限公司 Service access method, device, equipment and storage medium based on Kubernetes cluster
CN112260990A (en) * 2020-09-16 2021-01-22 厦门网宿有限公司 Method and device for safely accessing intranet application
CN112995272A (en) * 2016-08-09 2021-06-18 华为技术有限公司 Method, device and system for accessing physical server by virtual machine in cloud computing system
CN114189393A (en) * 2022-02-15 2022-03-15 北京指掌易科技有限公司 Data processing method, device, equipment and storage medium
CN114430410A (en) * 2022-01-28 2022-05-03 中国农业银行股份有限公司 System access method, device and equipment based on virtual domain name

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112995272A (en) * 2016-08-09 2021-06-18 华为技术有限公司 Method, device and system for accessing physical server by virtual machine in cloud computing system
CN108551488A (en) * 2018-05-03 2018-09-18 山东汇贸电子口岸有限公司 Distributed container cluster load balancing method based on domestic CPU and OS
CN109587290A (en) * 2019-01-04 2019-04-05 平安科技(深圳)有限公司 A kind of method and relevant apparatus of domain name mapping
CN110149423A (en) * 2019-07-04 2019-08-20 深圳市珍爱捷云信息技术有限公司 Domain name processing method, device, readable storage medium storing program for executing and electronic equipment
CN110704158A (en) * 2019-09-23 2020-01-17 凡普数字技术有限公司 Method, apparatus and storage medium for forwarding access requests within a container cluster
CN111614738A (en) * 2020-05-07 2020-09-01 北京金山云网络技术有限公司 Service access method, device, equipment and storage medium based on Kubernetes cluster
CN112260990A (en) * 2020-09-16 2021-01-22 厦门网宿有限公司 Method and device for safely accessing intranet application
CN114430410A (en) * 2022-01-28 2022-05-03 中国农业银行股份有限公司 System access method, device and equipment based on virtual domain name
CN114189393A (en) * 2022-02-15 2022-03-15 北京指掌易科技有限公司 Data processing method, device, equipment and storage medium

Also Published As

Publication number Publication date
CN115529292B (en) 2024-09-03

Similar Documents

Publication Publication Date Title
CN109688235B (en) Virtual network method for processing business, device and system, controller, storage medium
CN105376303B (en) Docker implementation system and communication method thereof
CN111510515B (en) Method and device for distinguishing containers of mixed application environment
CN111858054B (en) Resource scheduling system and method based on edge computing in heterogeneous environment
CN111880902A (en) Pod creation method, device, equipment and readable storage medium
CN113127192B (en) Method, system, device and medium for sharing same GPU by multiple services
CN112187864B (en) Load balancing method and device, storage medium and electronic equipment
CN106817236A (en) The collocation method and device of virtual network function
CN114070822A (en) Kubernetes Overlay IP address management method
CN113886011A (en) Container group pod deployment configuration method, device, equipment and storage medium
CN113301144B (en) Concurrent access processing method and device for Nginx server, server and storage medium
CN114157668B (en) Multi-tenant cross-cluster networking method, communication system and readable storage medium
CN112565475B (en) Ip address allocation method for adding new node in container cluster service layer
CN115529292A (en) Access request processing method, device, equipment, system and storage medium
CN113395183B (en) Virtual node scheduling method and system for network simulation platform VLAN interconnection
CN113904871B (en) Access method of network slice, PCF entity, terminal and communication system
CN111770179B (en) High-performance high-availability cloud networking gateway implementation method, medium and terminal
CN113407306B (en) Resource management system, method, device, equipment and medium
CN115883283A (en) Deployment method and device of containerization VNF
CN108768890B (en) Multi-tenant resource multiplexing method and device in SDN network and controller
CN109639447B (en) Method and device for mapping network function virtualization service chain under ring networking
CN113973092A (en) Link resource scheduling method and device, computing equipment and computer storage medium
CN109257201B (en) License sending method and device
US20190278625A1 (en) Rule-based reallocation of hosted compute resources
CN101394426B (en) Internet service processing method and system based on network television

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
GR01 Patent grant
GR01 Patent grant