CN116436920A - Method, system, device and computer readable medium for acquiring data - Google Patents

Method, system, device and computer readable medium for acquiring data Download PDF

Info

Publication number
CN116436920A
CN116436920A CN202210005402.5A CN202210005402A CN116436920A CN 116436920 A CN116436920 A CN 116436920A CN 202210005402 A CN202210005402 A CN 202210005402A CN 116436920 A CN116436920 A CN 116436920A
Authority
CN
China
Prior art keywords
processing request
container
slave node
cluster
node
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
CN202210005402.5A
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.)
Beijing Jingdong Century Trading Co Ltd
Beijing Wodong Tianjun Information Technology Co Ltd
Original Assignee
Beijing Jingdong Century Trading Co Ltd
Beijing Wodong Tianjun Information 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 Beijing Jingdong Century Trading Co Ltd, Beijing Wodong Tianjun Information Technology Co Ltd filed Critical Beijing Jingdong Century Trading Co Ltd
Priority to CN202210005402.5A priority Critical patent/CN116436920A/en
Publication of CN116436920A publication Critical patent/CN116436920A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Computer And Data Communications (AREA)

Abstract

The invention discloses a method, a system, equipment and a computer readable medium for acquiring data, and relates to the technical field of computers. One embodiment of the method comprises the following steps: receiving a processing request according to an external network load balancing cluster control console, and sending the processing request to a main node of the cluster based on an external network IP address of the processing request; the master node determines a slave node bearing the processing request according to the application to which the processing request belongs; the slave node issues the processing request to a container in the slave node according to intranet load balancing based on the operation type of the processing request; and the container responds to the processing request to call resources in the cloud environment, and request data of the processing request are sent through the slave node and the master node. The embodiment can be suitable for different cloud environments, and the data acquisition efficiency is improved.

Description

Method, system, device and computer readable medium for acquiring data
Technical Field
The present invention relates to the field of computer technology, and in particular, to a method, a system, an apparatus, and a computer readable medium for acquiring data.
Background
The cloud refers to the cloud as the object that receives the service. Public clouds generally refer to clouds that third party providers provide users with the ability to use. The core attribute of public clouds is shared resource services. In the environments of different clouds, there is a difference between a basic environment deployment mode and a service interaction mode.
In the process of implementing the present invention, the inventor finds that at least the following problems exist in the prior art: for different cloud environments, a hardware layer and a software layer need to be adapted, so that the efficiency of acquiring data is low.
Disclosure of Invention
In view of this, the embodiments of the present invention provide a method, a system, an apparatus, and a computer readable medium for acquiring data, which can be adapted to different cloud environments, and improve the efficiency of acquiring data.
To achieve the above object, according to one aspect of the embodiments of the present invention, there is provided a method for acquiring data, including:
receiving a processing request according to an external network load balancing cluster control console, and sending the processing request to a main node of the cluster based on an external network IP address of the processing request;
the master node determines a slave node bearing the processing request according to the application to which the processing request belongs;
the slave node issues the processing request to a container in the slave node according to intranet load balancing based on the operation type of the processing request;
and the container responds to the processing request to call resources in the cloud environment, and request data of the processing request are sent through the slave node and the master node.
The method further comprises the steps of:
responding to a container processing request, and feeding back an intranet IP address of the container, wherein the intranet IP address of the container is obtained according to an extranet IP address of the container processing request;
and accessing the container according to the intranet IP address of the container.
The master node maps to a nasspace of Kubernetes; the application maps to the ReplicationSet of Kubernetes.
The slave node issues the processing request to a container in the slave node according to intranet load balancing based on the operation type of the processing request, and the processing request comprises the following steps:
the slave node determines the load of the processing request based on the operation type of the processing request;
and the slave node determines and transmits the processing request to a container in the slave node according to the intranet load balance and the load of the processing request.
The cluster console and the master node are located in an application cluster; the slave node and the container are located in a middleware cluster.
The application cluster is used for interacting data with applications; the middleware cluster is used for interacting data with a cloud environment.
The container adopts a dynamic resource mode or a static resource mode.
According to a second aspect of an embodiment of the present invention, there is provided a system for acquiring data, including a cluster console, a master node, and a slave node;
the cluster console is used for receiving a processing request according to external network load balancing and sending the processing request to a main node of the cluster based on an external network IP address of the processing request;
the master node is used for determining a slave node bearing the processing request according to the application to which the processing request belongs and forwarding request data of the processing request;
the slave node is used for issuing the processing request to the slave node container according to intranet load balancing based on the operation type of the processing request; and
and the container responds to the processing request to call resources in the cloud environment and sends request data of the processing request.
According to a third aspect of an embodiment of the present invention, there is provided an electronic device that acquires data, including:
one or more processors;
storage means for storing one or more programs,
the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the methods as described above.
According to a fourth aspect of embodiments of the present invention, there is provided a computer readable medium having stored thereon a computer program which when executed by a processor implements a method as described above.
One embodiment of the above invention has the following advantages or benefits: receiving a processing request according to an external network load balancing cluster control console, and sending the processing request to a main node of the cluster based on an external network IP address of the processing request; the master node determines a slave node bearing the processing request according to the application to which the processing request belongs; the slave node issues the processing request to a container in the slave node according to intranet load balancing based on the operation type of the processing request; and the container responds to the processing request to call resources in the cloud environment, and request data of the processing request are sent through the slave node and the master node. The cluster control console, the master node, the slave node and the slave node are used for storing the request data of the processing request in a feedback manner, and the request data is not limited by cloud environments, so that the method is applicable to different cloud environments and the data acquisition efficiency is improved.
Further effects of the above-described non-conventional alternatives are described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:
FIG. 1 is a schematic diagram of the main flow of a method of acquiring data according to an embodiment of the present invention;
FIG. 2 is an interactive schematic diagram of a system for acquiring data according to an embodiment of the invention;
FIG. 3 is a flow chart of issuing a processing request to a container in a slave node according to intranet load balancing according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of an application cluster according to an embodiment of the invention;
FIG. 5 is a schematic diagram of a middleware cluster according to an embodiment of the invention;
FIG. 6 is a schematic diagram of the main structure of a system for acquiring data according to an embodiment of the present invention;
FIG. 7 is an exemplary system architecture diagram in which embodiments of the present invention may be applied;
fig. 8 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the invention.
Detailed Description
Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings, in which various details of the embodiments of the present invention are included to facilitate understanding, and are to be considered merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
In different cloud environments, there are differences in the deployment mode of the base environment and the mutual calling mode of the service. Based on various cloud schemes, even with the use of generic Kubernetes, there are fundamental differences. Kubernetes is an open source for managing containerized applications on multiple hosts in a cloud platform. The goal of Kubernetes is to make deploying containerized applications simple and efficient.
Currently, application container platform solutions in cloud environments have the following problems. On one hand, depending on a specific cloud environment, the adaptation of a hardware layer and a software layer is needed; on the other hand, service management schemes are not uniform, and even in Kubernetes, there are various schemes.
Therefore, the hardware layer and the software layer are required to be adapted for different cloud environments, so that the efficiency of acquiring data from the cloud environments is low, the migration of the data among different clouds is further influenced, and the data is easily bound by the cloud environments.
In order to solve the technical problem of low data acquisition efficiency, the following technical scheme in the embodiment of the invention can be adopted.
Referring to fig. 1, fig. 1 is a schematic diagram of a main flow of a method for acquiring data according to an embodiment of the present invention, where an external network load balance is used to determine a master node, and an internal network load balance is used to determine a container in a slave node, so as to implement resource invocation in a cloud environment. As shown in fig. 1, the method specifically comprises the following steps:
s101, receiving a processing request according to an external network load balancing cluster control console, and sending the processing request to a main node of the cluster based on an external network IP address of the processing request.
In an embodiment of the invention, applications (APP) are deployed in clusters through containers. The clusters are used to process requests of applications. As one example, the clusters interact with Kubernetes, enabling deployment of applications through the container. As one example, the master node maps to a nalespace of Kubernetes; the ReplicationSet mapped to Kubernetes is applied.
In Kubernetes clusters, there may be multiple nasspace, which are logically isolated from each other. The naspace may help organize Kubernetes resources.
The ReplicationSet belongs to the controller. The ReplicationSet functions are all to manage and control the number of copies of the container. As one example, the capacity expansion and contraction function of the container is implemented by changing the number of container copies in the ReplicationSet.
Referring to fig. 2, fig. 2 is an interactive schematic diagram of a system for acquiring data according to an embodiment of the present invention. A cluster console, a Master Node (Master) and a slave Node (Node) are included in fig. 2. Wherein the number of master nodes may be greater than 1. The slave nodes specifically comprise a slave node A and a slave node B. That is, the number of slave nodes may be greater than 1. Data is interacted between the master node and the slave node.
In an embodiment of the invention, the cluster console is used for processing requests of the application. In particular, in acquiring data, a plurality of applications are involved. For each application processing request, cluster control console processing is needed, and the number of the cluster control consoles is greater than or equal to 1. The cluster console accesses data related to the application through the master node.
Then the controller accesses the APP and sends the processing request by clicking. The cluster console receives a processing request. In consideration of the fact that a large number of processing requests are received in the same time period, the processing requests are distributed to the cluster control consoles according to the external network load balancing in order to improve the processing efficiency.
In the embodiment of the invention, the load balancing comprises external network load balancing and internal network load balancing. The external network refers to a network outside the cluster, and the internal network refers to a network inside the cluster. Correspondingly, the external network is identified by an external network IP address, and the internal network is identified by an internal network IP address.
As one example, external network load balancing includes implementing load balancing for multiple cluster consoles depending on the number of processing requests received by the cluster consoles. As another example, external network load balancing includes implementing load balancing for multiple cluster consoles according to the correspondence between APP and cluster console. Such as: the processing requests of the APP1 and the APP2 are distributed to the cluster console 1 for processing; the processing requests of APP3 and APP4 are distributed to the cluster console 2 for processing.
After the cluster control console receives the processing request, the processing request needs to be sent to a master node of the cluster, and the master node is responsible for processing. Including a plurality of master nodes in the cluster, the master nodes may be determined based on the external network IP address of the processing request. As one example, the cluster console sends a processing request to a master node of the cluster based on the external network IP address of the processing request.
It is understood that the correspondence between the IP address and the master node may be established in advance. And then, according to the corresponding relation, sending the processing request to the master node of the cluster.
S102, the master node determines a slave node bearing the processing request according to the application to which the processing request belongs.
For the master node, the processing request needs to be forwarded to the slave node, which executes the processing request. The cluster comprises a plurality of slave nodes, and the corresponding relation between the slave nodes and the application is preset. And then, determining the slave node bearing the processing request according to the corresponding relation and the application to which the processing request belongs.
As one example, the correspondence relationship of the slave node a and APP1, and the correspondence relationship of the slave node B and APP2 are set. After receiving the processing request, the master node obtains the APP1 to which the processing request belongs. The processing request belongs to the APP1, namely the processing request is triggered by the APP1. Then, according to the corresponding relation between the slave node A and the APP1, the slave node bearing the processing request is determined to be the slave node A.
S103, the slave node issues the processing request to the slave node container according to the intranet load balancing based on the operation type of the processing request.
The correspondence between the slave nodes and the APPs is pre-established, i.e. the predetermined slave node is responsible for executing the processing request of the corresponding APP. Specifically, the processing request includes requests of a plurality of operation types. As one example, processing requests include accessing page requests, copying page content requests, and revoking copy content requests, among others. The CPU resources, memory resources, disk resources, and IP resources consumed for processing requests of different operation types are different.
In an implementation, a slave node is subordinate to a plurality of containers. Each container is capable of invoking CPU resources, memory resources, disk resources, and IP resources. With continued reference to fig. 2, the slave node a in fig. 2 includes two containers, container A1 and container A2, respectively; the slave node B comprises two containers, container B1 and container B2, respectively.
In order to increase the speed of executing the processing request, a container for executing the processing request can be determined according to the operation type of the processing request and the intranet load balancing, and then the processing request is issued to the determined container. It will be appreciated that the container is then determined from both the type of operation that is handling the request and the intranet load balancing.
Referring to fig. 3, fig. 3 is a flow chart of issuing a processing request to a container in a slave node according to intranet load balancing according to an embodiment of the present invention, and specifically includes the following steps:
s301, the slave node determines the load of the processing request based on the operation type of the processing request.
The types of operations are different, and the amount of resources of the containers used by them is different. As one example, an access page request uses a larger amount of resources to copy page content requests than to copy page content requests. Thus, more resources need to be invoked for replicating page content requests. Among the resources include, but are not limited to: CPU resources, memory resources, disk resources and IP resources.
The slave node may determine the load of processing the request based on the type of operation that processed the request. As an example, the correspondence between the operation type and the load is preset, and then the slave node can determine the load of the processing request according to the operation type of the processing request. The corresponding relation between the operation type and the load is obtained according to the operation type and the used load statistics.
S302, the slave node determines and issues a processing request to a container in the slave node according to intranet load balancing and the load of the processing request.
Intranet load balancing is used to balance the load of subordinate containers from nodes. It is necessary for the slave node subordinate container to take on the tasks involved in processing the request. To facilitate invocation of containers, the containers are identified inside the cluster by intranet IP addresses. And then accessing the container in the cluster according to the intranet IP address.
Intranet load balancing refers to load balancing among a plurality of containers subordinate to a slave node. The slave node subordinate to a plurality of containers, each container invoking a resource in the cloud environment to execute a processing request. In order to improve the efficiency of executing processing requests, load balancing among containers needs to be achieved through intranet load balancing.
As one example, the load of a container is determined according to the operation type of the processing request, and then the container carrying the processing request is determined among a plurality of containers subordinate to the slave node based on intranet load balancing. Such as: and determining that the load of the container is 1 according to the operation type of the processing request, determining that the container bearing the processing request is the container A2 based on intranet load balancing, wherein the load of the container A1 is 3, the load of the container A2 is 1 and the load of the container A2 is lighter.
In the embodiment of fig. 3, load balancing between containers is achieved without external network coordination.
In one embodiment of the invention, the container is in either a dynamic resource mode or a static resource mode. The dynamic resource model includes newly created containers to support added resources. The static resource mode adopts a resource pool mode, and the added resources can not generate new containers.
Then, for the container subordinate to the slave node, the resource may be used in either a dynamic resource mode or a static resource mode.
And S104, the container responds to the processing request to call resources in the cloud environment, and request data of the processing request are sent through the slave node and the master node.
After the container receives the processing request distributed according to the intranet load balancing, the processing request is executed by calling the resources in the cloud environment, for example: one or more of CPU resources, memory resources, disk resources, and IP resources are invoked.
The purpose of processing the request is to request data. And the container executes the processing request by calling the resource in the cloud environment to obtain the request data. Then, the request data is sequentially transmitted to the user through the slave node and the master node.
From the user's perspective, a processing request is sent. In response to the processing request, request data of the processing request is fed back to the user. The execution process of the user for processing the request is not changed according to different cloud environments. This is because the cluster console is determined according to the external network load balancing, and the container for executing the processing request is determined according to the internal network load balancing. In different scenes, external network load balancing and internal network load balancing are respectively adopted, so that the data acquisition efficiency is improved, and the method is further suitable for various cloud environments.
In one embodiment of the present invention, the container is identified by an intranet IP address, so that the intranet IP address needs to be known in order to facilitate direct access to the container through the extranet.
Specifically, in response to the container processing request, the intranet IP address of the container is fed back, and the intranet IP address of the container is known according to the extranet IP address of the container processing request. As one example, the cluster console receives the container processing request via domain name resolution, thereby obtaining the external network IP address of the container processing request. And finally, the container processing request is executed by the container, and the corresponding relation between the internal network IP address of the container and the external network IP address of the container processing request is established. And feeding back the intranet IP address of the container. Finally, the container is accessed according to the intranet IP address of the container.
In one embodiment of the present invention, kubernetes may be monitored according to a preset period to update the external network IP address of the processing request and the correspondence between the external network IP address and the internal network IP address.
In the above embodiment, the container is directly accessed by the domain name through the intranet IP address of the container.
In the embodiment of the invention, the data is interacted with the application conveniently and the data is interacted with the cloud environment conveniently. And establishing an application cluster and a middleware cluster. The cluster control console and the master node are positioned in the application cluster; the slave nodes and containers are located in a middleware cluster.
As one example, an application cluster is used to interact data with an application; the middleware cluster is used for interacting data with the cloud environment.
The following description is exemplary with reference to the accompanying drawings.
Referring to fig. 4, fig. 4 is a schematic structural diagram of an application cluster according to an embodiment of the present invention. In fig. 4, the cluster console belongs to 3 master nodes, namely a master node 1, a master node 2 and a master node 3. Each master node is subordinate to a plurality of slave nodes, which are not shown in fig. 4. And the mirror image management and the operation work are completed through the master node.
The controller accesses the APP and sends a processing request in a clicking mode. In consideration of the fact that a large number of processing requests are received in the same time period, the processing requests are distributed to the cluster control consoles according to the external network load balancing in order to improve the processing efficiency. The cluster control console receives the processing request, determines a slave node according to the application to which the processing request belongs, and sends the processing request to a master node to which the slave node belongs.
It can be known that the application cluster can communicate with other application clusters through the external network IP address, so as to realize external load balance.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a middleware cluster according to an embodiment of the present invention. In fig. 5, a master node is subordinate to two slave nodes, namely, a slave node a and a slave node B. From node a, there are three containers, container A1, container A2, and container A3, respectively. The slave node B belongs to three containers, namely a container B1, a container B2 and a container B3. The slave nodes are mainly environments providing the respective applications to run.
Each container interacts with resources in the cloud environment, including CPU resources, memory resources, disk resources, and IP resources.
The middleware cluster can acquire information of resource interaction in the cloud environment. As one example, the middleware cluster is hooked with PODs inside Kubernetes, with the internal domain name as the connection. According to the intranet load balancing, the request does not need to be routed to the outside of the cluster, and further the performance is guaranteed. Middleware clusters support middleware such as databases, caches, queues, and the like. As one example, the middleware described above is deployed through the Kubernetes standard component.
In one embodiment of the invention, the middleware cluster may also respond to requests to store data through an Application Program Interface (API).
In the embodiment of the invention, a processing request is received according to an external network load balancing cluster console, and the processing request is sent to a master node of the cluster based on an external network IP address of the processing request; the master node determines a slave node bearing the processing request according to the application to which the processing request belongs; the slave node issues the processing request to a container in the slave node according to intranet load balancing based on the operation type of the processing request; and the container responds to the processing request to call resources in the cloud environment, and request data of the processing request are sent through the slave node and the master node. The cluster control console, the master node, the slave node and the slave node are used for storing the request data of the processing request in a feedback manner, and the request data is not limited by cloud environments, so that the method is applicable to different cloud environments and the data acquisition efficiency is improved.
Referring to fig. 6, fig. 6 is a schematic diagram of a main structure of a system for acquiring data according to an embodiment of the present invention, where the system for acquiring data may implement a method for acquiring data, and as shown in fig. 6, the system for acquiring data specifically includes a cluster console 601, a master node 602, and a slave node 603.
The cluster console 601 is configured to receive a processing request according to external network load balancing, and send the processing request to a master node of the cluster based on an external network IP address of the processing request;
the master node 602 is configured to determine, according to an application to which the processing request belongs, a slave node that carries the processing request, and forward request data of the processing request;
the slave node 603 is configured to issue the processing request to a container in the slave node according to intranet load balancing based on an operation type of the processing request; and
and the container responds to the processing request to call resources in the cloud environment and sends request data of the processing request.
In one embodiment of the present invention, the slave node 603 is further configured to respond to a container processing request by feeding back an intranet IP address of the container, where the intranet IP address of the container is known according to an extranet IP address of the container processing request;
and accessing the container according to the intranet IP address of the container.
In one embodiment of the invention, the master node 602 maps to a nalespace of Kubernetes; the application maps to the ReplicationSet of Kubernetes.
In one embodiment of the present invention, the slave node 603 is specifically configured to determine a load of the processing request based on the operation type of the processing request by the slave node;
and the slave node determines and transmits the processing request to a container in the slave node according to the intranet load balance and the load of the processing request.
In one embodiment of the invention, the cluster console 601 and the master node 602 are located in an application cluster; the slave node 603 and the container are located in a middleware cluster.
In one embodiment of the invention, the application cluster is used for interacting data with applications; the middleware cluster is used for interacting data with a cloud environment.
In one embodiment of the invention, the container is in either a dynamic resource mode or a static resource mode.
Fig. 7 illustrates an exemplary system architecture 700 of a method of acquiring data or a system of acquiring data to which embodiments of the present invention may be applied.
As shown in fig. 7, a system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. The network 704 is the medium used to provide communication links between the terminal devices 701, 702, 703 and the server 705. The network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A user may interact with the server 705 via the network 704 using the terminal devices 701, 702, 703 to receive or send messages or the like. Various communication client applications such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only) may be installed on the terminal devices 701, 702, 703.
The terminal devices 701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.
The server 705 may be a server providing various services, such as a background management server (by way of example only) providing support for shopping-type websites browsed by users using the terminal devices 701, 702, 703. The background management server may analyze and process the received data such as the product information query request, and feedback the processing result (e.g., the target push information, the product information—only an example) to the terminal device.
It should be noted that, the method for acquiring data provided in the embodiment of the present invention is generally executed by the server 705, and accordingly, a system for acquiring data is generally disposed in the server 705.
It should be understood that the number of terminal devices, networks and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 8, there is illustrated a schematic diagram of a computer system 800 suitable for use in implementing an embodiment of the present invention. The terminal device shown in fig. 8 is only an example, and should not impose any limitation on the functions and the scope of use of the embodiment of the present invention.
As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU) 801 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other by a bus 804. An input/output (I/O) interface 805 is also connected to the bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, mouse, etc.; an output portion 807 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and a speaker; a storage section 808 including a hard disk or the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. The drive 810 is also connected to the I/O interface 805 as needed. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as needed so that a computer program read out therefrom is mounted into the storage section 808 as needed.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication section 809, and/or installed from the removable media 811. The above-described functions defined in the system of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU) 801.
The computer readable medium shown in the present invention may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules involved in the embodiments of the present invention may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, as: a processor includes a cluster console, a master node, and a slave node. Wherein these names do not constitute a limitation on themselves in some cases, for example, a cluster console may also be described as "receiving a processing request according to an external network load balancing and sending the processing request to a master node of the cluster based on an external network IP address of the processing request".
As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be present alone without being fitted into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to include:
receiving a processing request according to an external network load balancing cluster control console, and sending the processing request to a main node of the cluster based on an external network IP address of the processing request;
the master node determines a slave node bearing the processing request according to the application to which the processing request belongs;
the slave node issues the processing request to a container in the slave node according to intranet load balancing based on the operation type of the processing request;
and the container responds to the processing request to call resources in the cloud environment, and request data of the processing request are sent through the slave node and the master node.
According to the technical scheme of the embodiment of the invention, a processing request is received by an external network load balancing cluster control console, and the processing request is sent to a main node of the cluster based on an external network IP address of the processing request; the master node determines a slave node bearing the processing request according to the application to which the processing request belongs; the slave node issues the processing request to a container in the slave node according to intranet load balancing based on the operation type of the processing request; and the container responds to the processing request to call resources in the cloud environment, and request data of the processing request are sent through the slave node and the master node. The cluster control console, the master node, the slave node and the slave node are used for storing the request data of the processing request in a feedback manner, and the request data is not limited by cloud environments, so that the method is applicable to different cloud environments and the data acquisition efficiency is improved.
The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention.

Claims (10)

1. A method of acquiring data, comprising:
receiving a processing request according to an external network load balancing cluster control console, and sending the processing request to a main node of the cluster based on an external network IP address of the processing request;
the master node determines a slave node bearing the processing request according to the application to which the processing request belongs;
the slave node issues the processing request to a container in the slave node according to intranet load balancing based on the operation type of the processing request;
and the container responds to the processing request to call resources in the cloud environment, and request data of the processing request are sent through the slave node and the master node.
2. The method of acquiring data according to claim 1, wherein the method further comprises:
responding to a container processing request, and feeding back an intranet IP address of the container, wherein the intranet IP address of the container is obtained according to an extranet IP address of the container processing request;
and accessing the container according to the intranet IP address of the container.
3. The method of claim 1, wherein the master node maps to a nalespace of Kubernetes; the application maps to the ReplicationSet of Kubernetes.
4. The method according to claim 1, wherein the slave node issues the processing request to the slave node container according to intranet load balancing based on the operation type of the processing request, and the method comprises:
the slave node determines the load of the processing request based on the operation type of the processing request;
and the slave node determines and transmits the processing request to a container in the slave node according to the intranet load balance and the load of the processing request.
5. The method of claim 1, wherein the cluster console and the master node are located in an application cluster; the slave node and the container are located in a middleware cluster.
6. The method of claim 5, wherein the application cluster is configured to interact with an application; the middleware cluster is used for interacting data with a cloud environment.
7. The method of claim 1, wherein the container is in a dynamic resource mode or a static resource mode.
8. A system for acquiring data, comprising a cluster console, a master node and a slave node;
the cluster console is used for receiving a processing request according to external network load balancing and sending the processing request to a main node of the cluster based on an external network IP address of the processing request;
the master node is used for determining a slave node bearing the processing request according to the application to which the processing request belongs and forwarding request data of the processing request;
the slave node is used for issuing the processing request to the slave node container according to intranet load balancing based on the operation type of the processing request; and
and the container responds to the processing request to call resources in the cloud environment and sends request data of the processing request.
9. An electronic device for acquiring data, comprising:
one or more processors;
storage means for storing one or more programs,
when executed by the one or more processors, causes the one or more processors to implement the method of any of claims 1-7.
10. A computer readable medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any of claims 1-7.
CN202210005402.5A 2022-01-04 2022-01-04 Method, system, device and computer readable medium for acquiring data Pending CN116436920A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210005402.5A CN116436920A (en) 2022-01-04 2022-01-04 Method, system, device and computer readable medium for acquiring data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210005402.5A CN116436920A (en) 2022-01-04 2022-01-04 Method, system, device and computer readable medium for acquiring data

Publications (1)

Publication Number Publication Date
CN116436920A true CN116436920A (en) 2023-07-14

Family

ID=87093118

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210005402.5A Pending CN116436920A (en) 2022-01-04 2022-01-04 Method, system, device and computer readable medium for acquiring data

Country Status (1)

Country Link
CN (1) CN116436920A (en)

Similar Documents

Publication Publication Date Title
CN107590001B (en) Load balancing method and device, storage medium and electronic equipment
CN109976667B (en) Mirror image management method, device and system
US20120203911A1 (en) Xml-based web feed for web access of remote resources
JP2020096357A (en) Dynamic routing using container orchestration service
US20190132276A1 (en) Unified event processing for data/event exchanges with existing systems
US10243919B1 (en) Rule-based automation of DNS service discovery
US20230028120A1 (en) State management and object storage in a distributed cloud computing network
US11201930B2 (en) Scalable message passing architecture in a cloud environment
US11356531B2 (en) Data caching for cloud services
CN112527520A (en) Method and device for deploying message middleware
CN110166507B (en) Multi-resource scheduling method and device
CN111124589B (en) Service discovery system, method, device and equipment
US20200213387A1 (en) Bidirectional Communication Clusters
US11853806B2 (en) Cloud computing platform that executes third-party code in a distributed cloud computing network and uses a distributed data store
WO2011087584A2 (en) Fault tolerant and scalable load distribution of resources
CN111225003B (en) NFS node configuration method and device
US10885028B2 (en) Searching and aggregating data across multiple geolocations
JP7081014B2 (en) Methods and devices for adjusting the number of instances, electronic devices, storage media and computer programs
CN113079098B (en) Method, device, equipment and computer readable medium for updating route
CN116034576B (en) Container Orchestration System (COS) service discovery across multiple COS clusters based on COS cluster domain name system
WO2024045646A1 (en) Method, apparatus and system for managing cluster access permission
US11210347B2 (en) Object search with pagination and non-duplicates support
CN116436920A (en) Method, system, device and computer readable medium for acquiring data
US10896077B2 (en) Messaging abstraction layer for integration with message oriented middleware platforms
KR102209044B1 (en) Cloud system having cloud native database structure

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