Request processing method, apparatus and electronic device

Abstract

This application provides a request processing method, apparatus, and electronic device. The method includes: in response to an operation request for a first application, obtaining an application identifier carried in the operation request; determining a first data center corresponding to a first gateway, and determining a second data center corresponding to the first application based on the application identifier; if the first data center and the second data center are inconsistent, sending the operation request to the second data center through a second gateway corresponding to the second data center, so that the second data center performs the operation indicated by the operation request on the first application. This application ensures the normal flow of operation requests for applications under abnormal circumstances, improving disaster recovery capabilities under abnormal conditions.

Description

Technical Field

[0001] This application relates to application processing technology, and more particularly to a request processing method, apparatus, and electronic device. Background Technology

[0002] With the rapid development of the internet, various industries have placed higher demands on the high availability and business continuity of computer systems. As a result, multi-datacenter architectures have emerged. Each data center can provide hardware hosting services for applications, which are typically deployed on servers within the data center and interact with users through network links provided by the data center.

[0003] However, when an application migrates or a network link fails, it is usually necessary to manually configure the correct network link to ensure the normal flow of operation requests to the application. This approach has poor disaster recovery capabilities when the entire system fails. Summary of the Invention

[0004] This application provides a request processing method, apparatus, and electronic device that can ensure the normal flow of operation requests for applications under abnormal circumstances, thereby improving disaster recovery capabilities under abnormal circumstances.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides a request processing method applied to a first gateway, the method comprising:

[0007] In response to an operation request for a first application, the application identifier carried in the operation request is obtained; a first data center corresponding to the first gateway is determined, and a second data center corresponding to the first application is determined based on the application identifier; if the first data center and the second data center are inconsistent, the operation request is sent to the second data center through the second gateway corresponding to the second data center, so that the second data center performs the operation indicated by the operation request on the first application.

[0008] This application embodiment provides a request processing device, disposed in a first gateway, the request processing device comprising:

[0009] The acquisition module is used to acquire the application identifier carried in the operation request in response to the operation request for the first application.

[0010] The determination module is used to determine the first data center corresponding to the first gateway, and to determine the second data center corresponding to the first application based on the application identifier;

[0011] The gateway sending module is used to send the operation request to the second data center through the second gateway corresponding to the second data center if the first data center and the second data center are inconsistent, so that the second data center performs the operation indicated by the operation request on the first application.

[0012] This application embodiment also provides a request processing method applied to a request transit area, the method comprising:

[0013] In response to an operation request for a first application, a first boundary proxy corresponding to the first application is determined. If the first boundary proxy is functioning normally, the operation request is sent to the first boundary proxy and forwarded to a first gateway through the first boundary proxy, so that the first gateway responds to the operation request. If it is determined that the first data center corresponding to the first gateway is inconsistent with the second data center to which the first application belongs, the operation request is sent to the second data center through the second gateway corresponding to the second data center, so that the second data center performs the operation indicated by the operation request on the first application.

[0014] This application embodiment also provides a request processing device, disposed in a request transfer area, the request device comprising:

[0015] The proxy determination module is used to determine the first boundary proxy corresponding to the first application in response to an operation request for the first application.

[0016] The proxy sending module is configured to send the operation request to the first boundary proxy when the first boundary proxy is functioning normally, and forward the operation request to the first gateway through the first boundary proxy so that the first gateway responds to the operation request. When it is determined that the first data center corresponding to the first gateway is inconsistent with the second data center to which the first application belongs, the module sends the operation request to the second data center through the second gateway corresponding to the second data center so that the second data center performs the operation indicated by the operation request on the first application.

[0017] This application provides an electronic device, the electronic device comprising:

[0018] Memory is used to store executable instructions for a computer;

[0019] The processor, when executing computer-executable instructions stored in the memory, implements the request processing method provided in the embodiments of this application.

[0020] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the request processing method provided in this application when executed by a processor.

[0021] This application provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implements the request processing method provided in this application.

[0022] The embodiments of this application have the following beneficial effects:

[0023] By applying the above embodiments, each data center is configured with a corresponding gateway. A gateway can send requests to its corresponding data center or forward requests to gateways in other data centers. In this way, operation requests for applications within a data center are isolated by gateways. When a gateway receives an operation request that is not for an application in its corresponding data center, it can forward the operation request to the appropriate gateway to ensure the normal flow of the operation request. That is, when the first gateway receives an operation request for the first application, it responds by determining its own corresponding first data center and using the application identifier carried in the operation request to determine the second data center currently corresponding to the first application. If the first and second data centers are inconsistent, the first gateway can forward the operation request to the second gateway corresponding to the second data center of the first application, ensuring that the operation request is accurately sent to the second data center through the second gateway. In this way, operation requests initiated for the first application can be sent normally and accurately to the data center currently corresponding to the first application in cases such as application migration, without the problem of link interruption of the operation request, thus improving disaster recovery capabilities in abnormal situations. Attached Figure Description

[0024] Figure 1A This is a schematic diagram of the first flow of an operation request in the related technology provided in the embodiments of this application;

[0025] Figure 1B This is a schematic diagram of the second flow of an operation request in the related technology provided in the embodiments of this application;

[0026] Figure 2 This is a schematic diagram of the architecture of the request processing system provided in the embodiments of this application;

[0027] Figures 3A-3B This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0028] Figure 4 This is a first flowchart illustrating the request processing method provided in this application embodiment;

[0029] Figure 5 This is a schematic diagram of the second process of the request processing method provided in the embodiments of this application;

[0030] Figure 6 This is a schematic diagram of the first flow of an operation request provided in an embodiment of this application;

[0031] Figure 7 This is a schematic diagram of the link for operation requests based on multiple data centers provided in an embodiment of this application;

[0032] Figure 8 This is a schematic diagram of the second flow of the operation request provided in the embodiments of this application.

[0033] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0036] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0037] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0038] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0039] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0040] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0041] 1) A data center is a specialized facility that provides a reliable and secure environment for hosting and running websites, applications, databases, and other information technology services. Data centers are typically operated by third-party service providers, but can also be built and managed by the enterprise itself. The purpose of a data center is to provide a secure, reliable, and efficient environment so that users can run their own information technology systems.

[0042] 2) A request relay zone, also known as a network isolation zone, is typically used to isolate sensitive internal networks from public networks to protect the internal network from security threats and attacks from the public network. The request relay zone essentially creates a buffer between the internal and external networks to improve security, allowing servers on the internal network to provide services while restricting direct access from the external network to the internal network. In this embodiment, the request relay zone is used to isolate the internal network where applications deployed in the data center reside from the external network used by users to initiate operation requests for the applications.

[0043] 3) A border proxy, acting as an intermediary between the external and internal networks, can be a network device or server, typically located in a request relay zone. The main functions of a border proxy include, but are not limited to: request forwarding, security policies, performance optimization, load balancing, and policy control.

[0044] 4) A gateway is a service or system located between two or more networks or systems. It acts as an intermediary or bridge between these networks or systems, responsible for data conversion, transmission, routing, and control. In different scenarios, gateways may have different functions and characteristics, but their main purpose is to achieve interconnection between different networks or systems. In this embodiment, the gateway is used to achieve interconnection between the data center and the request transit area.

[0045] With the rapid development of the internet, various industries have placed higher demands on the high availability and business continuity of computer systems, leading to the emergence of multi-datacenter architectures. In related technologies, to ensure the operational security of applications deployed in data centers, a request relay zone is typically built between the data center and the external network, and boundary proxies corresponding to each data center are deployed within this request relay zone. When users operate on applications within a data center through the external network, the operation requests for those applications must pass through the boundary proxies in the request relay zone, and then be forwarded to the corresponding data center by the boundary proxies.

[0046] As an example, Figure 1A This is a schematic diagram of the first flow of an operation request in the related technology provided in the embodiments of this application. (See also...) Figure 1A Users can initiate operation requests to the first application from the external network using the inbound domain name corresponding to the first application. The operation request passes through a request relay zone and is forwarded by the request relay zone to the border proxy configured for the data center where the first application is located. Then, the border proxy forwards the request to the corresponding data center. For example, if application A is deployed in the first data center (i.e., application A belongs to the first data center), and the first data center corresponds to the first border proxy, users can initiate operation requests to application A from the external network based on the inbound domain name of application A (such as A.xxx.com). The operation request flows to the first data center through the first border proxy in the request relay zone.

[0047] In this approach of related technologies, every time an application in the data center is deployed or migrated, or when an anomaly occurs in the boundary proxy, manual configuration of the boundary proxy is required to ensure that the boundary proxy corresponds to the current data center of the application, in order to guarantee the normal flow of operation requests initiated by the application. However, before the manual configuration is completed, the entire system is in an abnormal state, and normal access to the application cannot be guaranteed (i.e., operation requests cannot be sent to the application normally).

[0048] As an example, Figure 1B This is a schematic diagram illustrating the second flow of an operation request in the related technology provided in the embodiments of this application. (See also...) Figure 1B Taking application A and application C as an example, application A is initially deployed in the first data center, which corresponds to the first boundary agent. If application A is migrated to the second data center due to business adjustments, in order to ensure that users can operate application A normally, the first boundary agent needs to be manually configured so that the first boundary agent corresponds to the second data center.

[0049] This approach in related technologies is not conducive to unified management of the flow of operation requests, resulting in poor disaster recovery capabilities for the entire system during application migration. Furthermore, at the request relay zone level, because each application's inbound domain name is resolved independently using records, during application migration, the request relay zone needs to identify the data center to be accessed by all operation requests in the inbound traffic and modify the resolution of each request individually. When inbound traffic is high, this resolution modification in the request relay zone is time-consuming and increases the pressure on the request relay zone.

[0050] This application provides a request processing method, apparatus, electronic device, computer-readable storage medium, and computer program product that can ensure the normal flow of operation requests for applications under abnormal conditions, thereby improving disaster recovery capabilities under abnormal conditions.

[0051] See Figure 2 , Figure 2 This is a schematic diagram of the architecture of the request processing system 100 provided in this application embodiment. To support a request processing application, the terminal 401 connects to various data centers (e.g., the first data center 210 and the second data center 220) through a request relay zone 300 and gateways (e.g., the first gateway 510 and the second gateway 520). Each data center deploys at least one application. The request relay zone 300 can be a wide area network (WAN), a local area network (LAN), or a combination of both. The request relay zone 300 is equipped with boundary proxies corresponding to each data center (e.g., the first boundary proxy 310 of the first data center 210 and the second boundary proxy 320 of the second data center 220).

[0052] Terminal 401 is used to receive an operation instruction initiated by a user for a first application, and in response to the operation instruction, sends an operation request for the first application to the request relay zone. Assuming the first application is application 2101, the request relay zone 300 is used to respond to the operation request for the first application, determine the first data center 210 to which the first application belongs in advance, and the first boundary agent 310 corresponding to the first data center 210.

[0053] When the request transit zone 300 confirms that the first boundary agent 310 is normal, an operation request is sent to the first boundary agent 310. The first boundary agent 310 forwards the operation request to the first gateway 510 of the first data center 210, and then sends the operation request to the application 2101 in the first data center 210 through the first gateway 510.

[0054] Here, when the first gateway 510 receives an operation request for the first application, if the application 2101 has already migrated from the first data center 210 to the second data center 220, the first gateway 510 responds to the operation request and, if it determines that the first data center 210 is inconsistent with the second data center 220 currently corresponding to the first application, sends the operation request to the second gateway 520 of the second data center 220; the second gateway 520 is used to send the operation request to the second data center 220.

[0055] In some embodiments, after the second data center 220 receives an operation request for the first application, it can perform the operation requested by the operation request for the first application and send the result of the operation to the terminal 401 through the corresponding second gateway 520 and second border agent 320.

[0056] In some embodiments, the terminal 401 described above can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, and in-vehicle terminals.

[0057] In some embodiments, the request relay zone 300 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. The terminal 401 and the request relay zone 300 can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0058] See Figures 3A-3B , Figures 3A-3B This is a schematic diagram of the structure of the electronic device 400 provided in the embodiments of this application. Figures 3A-3B The illustrated electronic device 400 includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the electronic device 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figures 3A-3B The general labeled all buses as Bus System 440.

[0059] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0060] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0061] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0062] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0063] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0064] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0065] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0066] Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 (e.g., a display screen, a speaker, etc.) associated with user interface 430;

[0067] The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0068] In some embodiments, the request processing apparatus provided in this application can be implemented in software. Figure 3A A request processing device 455A stored in memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: an acquisition module 4551, a determination module 4552, and a gateway sending module 4553. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0069] In some embodiments, the request processing apparatus provided in this application can be implemented in software. Figure 3B A request processing device 455B stored in memory 450 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: agent determination module 4554 and agent sending module 4555. These modules are logically linked and can therefore be arbitrarily combined or further separated according to their implemented functions. The functions of each module will be described below.

[0070] In other embodiments, the request processing apparatus provided in this application can be implemented in hardware. As an example, the request processing apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the request processing method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0071] The request processing method provided in the embodiments of this application will now be described in conjunction with the accompanying drawings. As mentioned above, the electronic device that implements the request processing method of the embodiments of this application may be a gateway (e.g., gateway 510, gateway 520) or a request relay zone 300.

[0072] Below, we will first describe the request processing method of this application embodiment using a gateway (e.g., gateway 510, gateway 520) as an example of the executing entity. See also Figure 4 , Figure 4 This is a first flowchart illustrating the request processing method provided in this application embodiment, which will be combined with... Figure 4 The steps shown are explained.

[0073] In step 101, in response to an operation request for the first application, the application identifier carried in the operation request is obtained.

[0074] In actual implementation, the request processing system comprises multiple data centers. Each data center is pre-configured with a corresponding gateway and border proxy. The border proxy and gateway forward inbound traffic originating from their respective data centers. Inbound traffic may include operation requests for applications deployed within those data centers. Operation requests request the execution of operations on a first application, including but not limited to accessing, downloading, forwarding, and responding to the first application.

[0075] In practical implementation, the data center in this embodiment can be built using an Internet Data Center (IDC). The data center provides a professional IT environment for managing and deploying various applications. Within each data center, multiple business areas can be divided according to actual business needs, and the applications to be deployed are assigned to the corresponding business areas within the data center based on their business functions.

[0076] In this embodiment, the relationship between the data center (IDC) and applications is that of infrastructure and services. The IDC provides the runtime environment for applications, including computing resources, storage space, network connectivity, and security. Applications are the core content of the IDC, running on the hardware resources provided by the IDC, supporting daily operations and business development. The Abstracted Runtime Execution Area (Area), also known as the application runtime environment, typically refers to the software framework or platform that provides the runtime environment for applications. It may include operating systems, middleware, database management systems, and various tools and interfaces that provide the necessary resources and services for applications. In the IDC, the Area can be considered the software layer supporting application operation. Combined with the hardware resources provided by the IDC, it constitutes the enterprise's IT architecture. Applications run in the Area, relying on the IDC's infrastructure to perform their functions. In summary, the IDC provides physical and infrastructure-level support, while the Area provides software and runtime environment-level support; both jointly support the operation of business applications.

[0077] In practice, after building the request processing system and deploying each application to its corresponding data center, application metadata describing the application deployment information can be constructed based on the system's configuration. Application metadata can include a mapping between the application's application identifier and the central identifier of the data center to which the application belongs, and can also include a status table for each data center, which describes whether the data center is in normal working order.

[0078] As an example, application metadata may include Table 1 and Table 2, see Table 1 and Table 2.

[0079] Table 1

[0080] Application Identifier Central logo Business area identifier Application A Data Center 1 Area 1 … … … Application N Data Center M Area*

[0081] Table 1 shows the mapping relationship between application identifiers and central identifiers.

[0082] Table 2

[0083] Central logo Data Center Status Business area identifier Business Area Status Data Center 1 UP Area 1 UP Data Center 1 UP Area2 DOWN … … … … Data Center M UP Area 1 UP

[0084] Table 2 is the status table of the data center, where UP indicates a normal state and DOWN indicates an abnormal state.

[0085] In practice, the status of the data center, the status of each business area within the data center, and the data center to which each application belongs can be continuously monitored. When a change in the status of each data center or each business area within a data center is detected, the status table shown in Table 2 is updated; when an application is detected to have migrated, for example from data center 1 to data center 2, or from business area Area1 in data center 1 to business area Area2 in data center 1, the mapping relationship table shown in Table 2 is updated.

[0086] In practice, different global domain names, also known as inbound domain names, can be built for different applications. Users can initiate calls to the data center from the external network through the inbound domain name to make operation requests to the primary application. Hereinafter, we will refer to them collectively as inbound domain names.

[0087] As an example, the inbound domain can be set to a third-level domain (x.xxx.com), and the inbound domain includes the application identifier. For example, the inbound domain set for application A can be A.xxx.com, and the inbound domain set for application B can be B.xxx.com.

[0088] In actual implementation, if the first gateway receives an operation request for the first application forwarded by the first border proxy, it can parse the operation request, obtain the application identifier in the inbound domain name corresponding to the operation request, and obtain the application metadata of the first application, so as to determine the data center to which the first application currently belongs through the application metadata.

[0089] In this configuration, both the first gateway and the first border proxy are configured to correspond to the first data center. In actual implementation, the border proxy can only forward received operation requests for the first application to its corresponding gateway.

[0090] In step 102, the first data center corresponding to the first gateway is determined, and the second data center corresponding to the first application is determined based on the application identifier.

[0091] In practice, because the mapping between gateways, border proxies, and data centers is deployed when the request processing system is built, when a border proxy receives an operation request, it directly forwards the operation request to the gateway on the same line. The gateway can only send operation requests for its corresponding data center to that data center; it cannot send operation requests to other data centers. Therefore, when the first gateway receives an operation request for the first application, it needs to determine whether the data center corresponding to the first application is the same as its own data center. If they are the same data center, the first gateway can directly send the operation request to its corresponding data center; if they are not the same data center, the first gateway needs to forward the operation request to the gateway corresponding to the data center of the first application.

[0092] It is understandable that the data center corresponding to the first application refers to the server on which the first application is deployed, that is, the data center to which the first application belongs.

[0093] In actual implementation, the first gateway can first determine the first data center corresponding to itself, and then, by using the application identifier carried in the obtained operation request, search in the application metadata to determine the second data center where the first application is currently deployed, that is, determine the second data center corresponding to the first application.

[0094] As an example, since application metadata is updated in real time based on the real-time status of the data center, business area, and application, the first gateway can obtain the application metadata each time it receives an operation request, thus obtaining the latest application metadata. In this way, the data center corresponding to the first application can be accurately determined through the application metadata.

[0095] As an example, when the first gateway receives an operation request for the first application, it parses the operation request and obtains the application identifier from the inbound domain name corresponding to the operation request. Based on this application identifier, it searches in the mapping table of application metadata as shown in Table 1 to obtain the target center identifier and target business area identifier corresponding to the application identifier. The target center identifier is the identifier of the second data center where the first application is deployed, and the first application is deployed on the business area corresponding to the target business area identifier in the second data center.

[0096] In step 103, if the first data center and the second data center are not the same, the operation request is sent to the second data center through the second gateway corresponding to the second data center, so that the second data center performs the operation indicated by the operation request on the first application.

[0097] In one scenario, if the first application is pre-deployed on data center 1, all operation requests sent to the first application will be allocated by the request relay zone to the border proxy 1 corresponding to data center 1. The border proxy 1 then forwards the operation requests to the gateway 1 corresponding to data center 1, and the gateway 1 forwards the operation requests to data center 1. Under this premise, if the first application is migrated from data center 1 to data center 2 due to business needs, and the border proxy has not yet updated the application migration in time, the operation requests sent to the first application will still be allocated by the request relay zone to the border proxy 1, and the border proxy 1 will forward the operation requests to the gateway 1. In this case, gateway 1 is the first gateway, and the data center 1 corresponding to gateway 1 is the first data center. When gateway 1 receives the operation request, it responds by obtaining the latest application metadata. Based on the application metadata, it determines that the second data center where the first application is currently deployed is data center 2. In this case, the first data center and the second data center are inconsistent. At this time, gateway 1 (i.e., the first gateway) needs to forward the operation request to gateway 2 (i.e., the second gateway) corresponding to data center 2, so that the operation data can be forwarded to data center 2 (i.e., the second data center) through gateway 2, so that the second data center can perform the operation requested by the operation request for the first application.

[0098] In another scenario, the first application is deployed on data center 1. When the border proxy 1 corresponding to data center 1 is functioning normally, operation requests sent to the first application will be allocated to border proxy 1 by the request relay area. Border proxy 1 then forwards the operation request to gateway 1 corresponding to data center 1, and gateway 1 forwards the operation request to data center 1. Based on this premise, if border proxy 1 malfunctions and cannot function properly when a user initiates an operation request for the first application, the request relay area will allocate the operation request to any other border proxy besides border proxy 1 (e.g., border proxy 3) to initiate the operation request to the first application via cross-border proxy. Since border proxy 3 corresponds to data center 3, and data center 3 corresponds to gateway 3, border proxy 3 will forward the received operation request to gateway 3. Here, gateway 3 is the first gateway, and data center 3 is the first data center. The first gateway, responding to the operation request, determines through application metadata that the first application is still deployed on data center 1 (i.e., the second data center). In this situation, inconsistencies may occur between the first data center and the second data center. In this case, gateway 3 (i.e., the first gateway) needs to forward the operation request to gateway 1 (i.e., the second gateway) so that the operation request can be forwarded to data center 1 (the second data center) through gateway 1, so that the second data center can perform the operation requested by the first application.

[0099] In some embodiments, Figure 4In step 103 shown, "sending the operation request to the second data center through the second gateway corresponding to the second data center" can be achieved in the following way.

[0100] Determine the second gateway corresponding to the second data center; send an operation request to the second gateway so that the second gateway determines the second application routing address corresponding to the first application based on the second center identifier and application identifier of the second data center, and sends the operation request to the second application routing address; wherein, the second application routing address is the interface address allocated by the second data center for the first application.

[0101] In practice, a routing address mapping table is pre-configured. When each gateway receives an operation request, it can determine the application routing address corresponding to the first application through the routing address mapping table. The application routing address is the interface address assigned to the application by the data center. The application routing address ensures that the application is correctly accessed within the data center. The application routing address can be a private IP address or a public IP address, depending on whether the application is used only within the data center or needs to be exposed externally. If the application needs to be accessed from outside the data center, it is usually assigned a public IP address. In order for the application to receive and send data, corresponding routing configurations need to be made in the data center network to ensure that data can be correctly forwarded to the application according to the application's corresponding application routing address.

[0102] As an example, see Table 3, which configures the mapping relationship between application identifier, inbound domain name, application routing address, and center identifier.

[0103] Table 3

[0104]

[0105] In Table 3, taking application A as an example, the inbound domain name corresponding to application A is A.xxx.com. When application A belongs to data center 1, the application routing address corresponding to application A is 1.1.1.11.8080; when application A belongs to data center 2, the application routing address corresponding to application A is 2.1.1.21.8080.

[0106] In practice, when the first gateway determines that the first data center and the second data center are inconsistent, the first gateway first determines the second gateway corresponding to the second data center where the first application is deployed and forwards the operation request to the second gateway. The second gateway responds to the operation request by obtaining a routing address mapping table. Based on the application identifier carried in the operation request and the second center identifier corresponding to the second data center, it searches the routing address mapping table to obtain the application routing address corresponding to the application identifier and the second center identifier, and uses this application routing address as the second application routing address corresponding to the first application. The second gateway then forwards the operation request to the second application routing address, thus enabling the operation request to be sent to the first application deployed in the second data center.

[0107] In some embodiments, Figure 4 After step 102 is executed, step 104 can also be executed.

[0108] In step 104, if the first data center and the second data center are the same, an operation request is sent to the first data center so that the first data center performs the operation requested by the operation request for the first application.

[0109] In actual implementation, if the first data center and the second data center are the same, it indicates that the access to the first application is in a normal state. At this time, the first gateway can directly send the operation request to the first data center to perform the operation requested by the first application.

[0110] As an example, application A is deployed on data center 1. When an operation request is initiated for application A, the request relay zone allocates the operation request to the border proxy 1 corresponding to data center 1. Border proxy 1 then forwards the operation request to gateway 1 corresponding to data center 1. At this time, gateway 1 is the first gateway, and data center 1 is the first data center. If gateway 1 determines through the latest application metadata that application A still belongs to data center 1, then data center 1 is also the second data center, and gateway 1 is also the second gateway. In this case, gateway 1 can directly forward the operation request to data center 1, so that data center 1 can perform the operation requested by application A.

[0111] In some embodiments, the "sending operation request to the first data center" shown in step 104 can be implemented in the following ways.

[0112] Based on the first center identifier and application identifier of the first data center, determine the first application routing address corresponding to the first application; and send the operation request to the first data center based on the first application routing address.

[0113] In practice, the first application routing address is the interface address allocated by the first data center to the first application. In response to an operation request, the first gateway retrieves a routing address mapping table. Based on the application identifier carried in the operation request and the first center identifier corresponding to the first data center, it searches the routing address mapping table to obtain the application routing address corresponding to the application identifier and the first center identifier. This application routing address is then used as the first application routing address for the first application. The first gateway forwards the operation request to the first application routing address, thus ensuring that the operation request is sent to the first application corresponding to the first data center.

[0114] Through the above embodiments, each data center is configured with a corresponding gateway. The gateway can send requests to its corresponding data center or forward requests to gateways in other data centers. In this way, operation requests for applications within a data center are isolated by the gateways. When a gateway receives an operation request that is not for an application in its corresponding data center, it can forward the operation request to the appropriate gateway to ensure the normal flow of the operation request. That is, when the first gateway receives an operation request for the first application, it responds by determining its own corresponding first data center and then using the application metadata of the first application to determine the second data center currently corresponding to the first application. If the first and second data centers are inconsistent, the first gateway can forward the operation request to the second gateway corresponding to the second data center to which the first application belongs, ensuring that the operation request is accurately sent to the second data center through the second gateway. In this way, operation requests initiated for the first application can be sent normally and accurately to the data center currently corresponding to the first application in the event of application migration, without interruption of the operation request flow, thus improving disaster recovery capabilities in abnormal situations.

[0115] The request processing method of this application embodiment will be described below, taking the execution subject as the request transit area as an example. See also Figure 5 , Figure 5 This is a second flowchart illustrating the request processing method provided in the embodiments of this application, which will be combined with... Figure 5 The steps shown are explained.

[0116] In step 201, in response to an operation request for the first application, a first boundary proxy corresponding to the first application is determined.

[0117] In practice, since the boundary proxies corresponding to each data center are deployed in the request transit zone, when the request transit zone receives inbound traffic from the external network, it is necessary to determine the boundary proxies to which each operation request in the inbound traffic should flow, and then allocate each operation request to the corresponding boundary proxies.

[0118] In some embodiments, Figure 5 Step 201 shown can be implemented by steps 2011 to 2012.

[0119] In step 2011, the application identifier carried in the operation request is obtained.

[0120] In practice, the request relay zone responds to the operation request for the first application, parses the operation request, and obtains the application identifier in the inbound domain name corresponding to the operation request.

[0121] In step 2012, the first proxy address is determined based on the first mapping table between the application identifier and the proxy address and the application identifier, and the first boundary proxy is determined based on the first proxy address.

[0122] In this embodiment of the application, a first mapping table is pre-configured for the request transit area. The first mapping table contains the mapping relationship between the application identifier of each application and the proxy address corresponding to each boundary proxy.

[0123] In some embodiments, the proxy address of the border proxy can be the IP address of the border proxy, such as a Virtual IP (VIP) address.

[0124] In practice, the request relay zone can look up the first proxy address corresponding to the application identifier carried in the operation request in the first mapping table. The first proxy address points to the first boundary proxy. Then, the operation request is forwarded to the first proxy address.

[0125] In some embodiments, before the execution of step 2012, "determine the first proxy address based on the first mapping table between the application identifier and the proxy address and the application identifier", the first mapping table can be constructed or updated in the following ways.

[0126] Based on the application metadata of the first application, determine the first center identifier of the first data center; based on the second mapping table between the center identifier and the proxy address and the first center identifier, determine the first proxy address; establish the first mapping relationship between the application identifier of the first application and the first proxy address, and add the first mapping relationship to the first mapping table.

[0127] In this embodiment of the application, after determining the correspondence between each data center and the border proxy when building the request processing system, a second mapping table can be constructed. The second mapping table configures the mapping relationship between the central identifier of the data center and the proxy address of the border proxy. In some cases, in order to achieve load balancing, the border proxy corresponding to the data center can allocate different proxy addresses for different business areas of the data center, so that the border proxy can handle the incoming traffic evenly.

[0128] As an example, see Table 4. The second mapping table can also be configured with the mapping relationship between the data center center identifier, the business area identifier of the business area, and the proxy address.

[0129] Table 4

[0130] Central logo Business Area Identifier Proxy address Data Center 1 Area 1 1.1.1.1 Data Center 1 Area2 1.2.1.1 Data Center 2 Area 1 2.1.1.1 … … … Data Center N Area* n.*.1.1

[0131] In actual implementation, when the request relay zone receives an operation request for the first application for the first time, there is no mapping relationship corresponding to the application identifier of the first application in the first mapping table. At this time, the request relay zone needs to parse the first received operation request, obtain the application identifier carried by the operation request, and determine the first proxy address corresponding to the first application through the application metadata and the second mapping table. Then, the first mapping relationship between the application identifier and the first proxy address is established, and the first mapping relationship is updated to the first mapping table.

[0132] Here, when the request transit zone receives an operation request for the first application for the first time, it can determine the first center identifier and the first business area identifier of the first data center where the first application is pre-deployed through the application metadata. Then, based on the first center identifier and the first business area identifier, it queries the second mapping table to obtain the first proxy address corresponding to the first center identifier and the first business area identifier. The first boundary proxy pointed to by the first proxy address is the boundary proxy corresponding to the first data center.

[0133] In this embodiment, after the request relay zone adds the first mapping relationship corresponding to the application identifier of the first application to the first mapping table, when a subsequent operation request for the first application is received, the first boundary proxy corresponding to the first application can be directly determined through the first mapping table, and the operation request can be directly assigned to the first proxy address of the first boundary proxy. This reduces the number of times the request relay zone is parsed, alleviating its load. When inbound traffic is large, only the first operation request for a certain application in the inbound traffic needs to undergo the above parsing process. For other operation requests, the boundary proxy to be assigned can be directly determined through the first mapping table, reducing the parsing time of the request relay zone and alleviating its parsing pressure.

[0134] As an example, see Table 5(a), where the first mapping table can be configured with the mapping relationship between application identifiers and proxy addresses.

[0135] Table 5(a)

[0136]

[0137] In some embodiments, a fourth-level domain name can also be built for each application, which includes the identifier of the data center where the application is deployed and the business area of ​​the business region.

[0138] As an example, if application A is deployed in business area 1 (business area identifier: Area1) of data center 1 (center identifier: IDC1), then in the application metadata, application A corresponds to the center identifier "IDC1" and the business area identifier "Area1". Therefore, the fourth-level domain name corresponding to application A can be: Area1.IDC1.xxx.com. When the request relay zone responds to an operation request for application A, it can record the inbound domain name "A.xxx.com" corresponding to the operation request as the fourth-level domain name "Area1.IDC1.xxx.com".

[0139] To improve the accuracy of determining the proxy address corresponding to the first application through the first mapping table, the fourth-level domain name corresponding to the application can be added to the first mapping table. As an example, see Table 5(b). The first mapping table can also be configured to map the application identifier, the fourth-level domain name, and the proxy address.

[0140] Table 5(b)

[0141]

[0142] In response to an operation request for the first application, the transit zone, after determining the data center where the first application is currently deployed and the business area within the data center through application metadata, can convert the inbound domain name of the first application into a fourth-level domain name. Based on the fourth-level domain name and the application identifier carried in the operation request, it can look up the proxy address of the boundary proxy corresponding to the first application in the first mapping table shown in Table 5(b).

[0143] In practice, due to situations such as application migration between different data centers and modifications to the correspondence between data centers and border agents, the request transit zone can update the first mapping table based on application metadata and the second mapping table.

[0144] In some embodiments, the first mapping table can be updated in the following ways: if the first mapping relationship is invalid, delete the first mapping relationship from the first mapping table and establish a second mapping relationship between the application identifier of the first application and the second proxy address, where the second proxy address corresponds to the second data center; add the second mapping relationship to the first mapping table.

[0145] Here, the invalidity of the first mapping relationship can be understood as follows: when receiving an operation request for the first application, passing the request through the first mapping relationship would result in cross-gateway or cross-border proxy situations. In this case, it indicates that the first application has been migrated in the data center, or that the mapping relationship between the data center and the border proxy has been adjusted.

[0146] In some embodiments, the invalidity of the first mapping relationship can be determined in the following ways: if the first data center corresponding to the first gateway is inconsistent with the second data center to which the first application belongs, the first mapping relationship is determined to be invalid; or, if the second mapping table indicates that the proxy address corresponding to the first center identifier is updated from the first proxy address to the second proxy address, the first mapping relationship is determined to be invalid.

[0147] In practice, the second mapping table configures the mapping relationship between the central identifier of the data center and the proxy address of the corresponding border agent. This second mapping table is adjusted according to the configuration of the data center and the border agent. If, due to business needs, the administrator of the request processing system actively modifies the mapping relationship between the data center and the border agent, and simultaneously updates the second mapping table according to the modified mapping relationship, the request transit zone can determine that the second mapping table has been updated by checking its status. That is, if the second mapping table indicates that the proxy address corresponding to the first central identifier has been updated from the first proxy address to the second proxy address, the first mapping relationship can be determined to be invalid.

[0148] If the first mapping relationship is determined to be invalid by detecting that the proxy address corresponding to the first center identifier is updated from the first proxy address to the second proxy address in the second mapping table, the first mapping table can be updated in the following way: in response to the second mapping table indicating that the proxy address corresponding to the first center identifier is updated from the first proxy address to the second proxy address, the first mapping relationship in the first mapping table is canceled (i.e., the first mapping relationship is deleted from the first mapping table); a second mapping relationship is established between the application identifier of the first application and the second proxy address, and the second mapping relationship is added to the first mapping table.

[0149] In practice, the first mapping relationship is configured between the first application and the first proxy address. Therefore, upon receiving an operation request for the first application, according to the first mapping relationship, the operation request is directly sent to the first boundary proxy of the first proxy address for processing. Then, the first boundary proxy sends the operation request to the first gateway, which in turn sends it to the first data center. However, if the first application has migrated from the first data center to the second data center, when transmitting the operation request through the first mapping relationship, the first gateway can determine from the application metadata that the first application currently belongs to the second data center. The first gateway will then send the operation request to the second gateway corresponding to the second data center, which in turn sends the operation request to the second data center. In other words, the flow of the operation request involves cross-gateway situations, confirming that the first data center corresponding to the first gateway and the second data center to which the first application belongs are inconsistent. In this case, the first mapping relationship is also confirmed to be invalid.

[0150] In some embodiments, the first mapping table can also be updated in the following ways: in response to the inconsistency between the first data center corresponding to the first gateway and the second data center to which the first application belongs, the first mapping relationship in the first mapping table is canceled (i.e., the first mapping relationship is deleted from the first mapping table); a second mapping relationship is established between the application identifier of the first application and the proxy address of the second boundary proxy corresponding to the second data center, and the second mapping relationship is updated to the first mapping table.

[0151] Based on application metadata and the second mapping table, the proxy address corresponding to the application identifier is checked to obtain a verification result. If the verification result indicates that the proxy address corresponding to the application identifier determined by the application metadata and the proxy address mapping table is inconsistent with the first proxy address, an update prompt for the first mapping table is generated.

[0152] In other cases, if the mapping between data centers and border proxies has not been updated (i.e., no update to the second mapping table is detected), and if an application migrates—that is, if it is determined that the first data center corresponding to the first gateway is inconsistent with the second data center to which the first application belongs (e.g., application A migrates from data center 1 to data center 2)—then operation requests for application A must also be forwarded through the border proxy corresponding to data center 2. Therefore, the request transit zone can detect the border proxy corresponding to the first application based on the application metadata and the second mapping table. If a change in the border proxy corresponding to the first application is detected, the first mapping table is updated, mapping the application identifier of the first application in the first mapping table to the proxy address of the second border proxy in the second data center.

[0153] As an example, if the first application is initially deployed in the first data center, in the first mapping table, the application identifier corresponding to the first application has a first mapping relationship with the first proxy address of the first boundary proxy corresponding to the first data center. During business development, due to business needs, the first application is migrated from the first data center to the second data center. At this time, the center identifier corresponding to the application identifier of the first application in the application metadata is updated from the first center identifier to the second center identifier of the second data center. In this case, the request transit zone performs proxy address detection based on the application metadata and the second mapping table. The verification detection result indicates that the application identifier corresponding to the first application, determined by the application metadata and the second mapping table, corresponds to the second proxy address. However, in the first mapping table, the application identifier corresponding to the first application still corresponds to the first proxy address. Since the proxy addresses corresponding to the application identifiers in the two mapping tables are inconsistent, the first mapping relationship in the first mapping table is canceled, and a second mapping relationship is re-established between the application identifier of the first application and the proxy address of the second boundary proxy of the second data center. The second mapping relationship is then updated in the first mapping table, completing the update of the first mapping table.

[0154] If the requesting transit area is unable to update the first mapping table proactively, the requesting transit area can generate an update prompt for the first mapping table and send the update prompt to the terminal where the administrator is located, so as to prompt the administrator to update the first mapping table.

[0155] Through the above embodiments, by constructing a first mapping table and a second mapping table, it is possible to achieve unified management of inbound traffic in the request processing system through a request transit zone. This distributes each operation request within the inbound traffic to the corresponding boundary proxy, solving the problems of chaotic domain name configuration and unclear operation request flow links in related technologies, and reducing the scenarios where operation requests cross boundary proxies. Furthermore, in the event of large-scale application migration, this embodiment only needs to update the application metadata and the first mapping table to complete the migration at both the application and proxy levels, accelerating the migration speed and shortening the application migration period.

[0156] Continue reading Figure 5 The following explanation follows step 201 above.

[0157] In step 202, if the first boundary proxy is normal, an operation request is sent to the first boundary proxy and forwarded to the first gateway through the first boundary proxy so that the first gateway responds to the operation request. If it is determined that the first data center corresponding to the first gateway is inconsistent with the second data center to which the first application belongs, the operation request is sent to the second data center through the second gateway corresponding to the second data center so that the second data center performs the operation indicated by the operation request on the first application.

[0158] In this embodiment, if an application undergoes a data center deployment migration, the application-level switch is completed after the application metadata is updated according to the migration details. The switch between the application-level and proxy-level switches is completed after both the application metadata and the first mapping table are updated.

[0159] In some cases, if the first application is migrated, for example from the first data center (data center 1) to the second data center (data center 2), the update of the first mapping table usually takes some time after the application metadata is updated. Therefore, the period when the application metadata has been updated but the first mapping table has not been updated can be considered the application migration period. If the request transit area receives an operation request for the first application during this application migration period, the request transit area will still determine the first proxy address corresponding to the application identifier based on the unupdated first mapping table, and then send the operation request to the first boundary proxy pointed to by the first proxy address. The first boundary proxy will forward the operation request to the first gateway corresponding to the first data center. At this time, the first gateway responds to the operation request, obtains the latest application metadata, and determines the second data center (data center 2) where the first application is currently deployed. At this time, the first data center (data center 1) and the second data center (data center 2) corresponding to the first gateway are inconsistent. Therefore, the first gateway forwards the operation request to the second gateway corresponding to the second data center, and the second gateway sends the operation request to the second data center.

[0160] As an example, Figure 6 This is a schematic diagram of the first flow of the operation request provided in the embodiments of this application, see below. Figure 6 Application A is pre-deployed in business area 1 of data center 1. If the request relay zone receives an operation request for application A, in response to the operation request, it determines the application identifier of application A through the inbound domain name corresponding to the operation request, and based on the application identifier, it queries the first mapping table to determine the proxy address (1.1.1.1) of the border proxy corresponding to data center 1. Then, the request relay zone sends the operation request to the border proxy at proxy address 1.1.1.1, which in turn sends the operation request to the gateway (1.1.1.2). The gateway then responds to the operation request by... The latest application metadata determines that application A is currently deployed in data center 2. Therefore, gateway (1.1.1.2) forwards the operation request to the corresponding gateway (2.1.1.2) in data center 2. Gateway (2.1.1.2) can determine the application routing address (2.1.1.21:8080) corresponding to application A when it is deployed in data center 2 based on the routing address mapping table. Then, gateway (2.1.1.2) forwards the operation request to the application routing address (2.1.1.21:8080). Thus, the process of sending the operation request of application A to data center 2 is completed.

[0161] In some embodiments, the description continues from step 201. Figure 5 After step 201 is executed, step 203 can also be executed.

[0162] In step 203, if the first boundary proxy is abnormal, a third boundary proxy is determined from the candidate boundary proxies according to the priority parameter of the candidate boundary proxies, and the operation request is forwarded using the third boundary proxy.

[0163] In some embodiments, step 203, "forwarding operation requests using a third boundary proxy", can be implemented as follows: sending an operation request to a third boundary proxy of a third data center, and forwarding the operation request to a third gateway of the third data center through the third boundary proxy, so that when the third gateway responds to the operation request and determines that the third data center is inconsistent with the second data center, it sends the operation request to the second data center through the second gateway corresponding to the second data center, so that the second data center performs the operation indicated by the operation request on the first application.

[0164] In other cases, the first application is not migrated, but the border proxy corresponding to the data center where the first application is deployed experiences an anomaly. In this case, user operation requests for the first application can be forwarded across the border proxy to the data center where the first application is deployed.

[0165] As an example, if the request relay zone responds to an operation request for the first application and determines, through the first mapping table, that the proxy address corresponding to the application identifier is the first proxy address of the first boundary proxy, but the first boundary proxy is in an abnormal state, the request relay zone can allocate the operation request to a third boundary proxy other than the first boundary proxy. The third boundary proxy then forwards the operation request to the third gateway corresponding to the third boundary proxy. Here, both the third boundary proxy and the third gateway correspond to the third data center. The third gateway responds to the operation request, obtains the latest application metadata, and determines the second data center where the first application is deployed through the application metadata. If the second data center and the third data center are inconsistent, the third gateway forwards the operation request to the second gateway corresponding to the second data center, thus forwarding the operation request to the second data center through the second gateway.

[0166] In the above embodiments, the request relay zone responds to an operation request for the first application, determines the first boundary proxy corresponding to the first application, and, if the first boundary proxy is functioning normally, allocates the operation request to the corresponding first boundary proxy. The first boundary proxy then forwards the operation request to the first gateway. Upon receiving an operation request for the first application, the first gateway responds to the request, determines its own first data center, and uses the application identifier carried in the operation request to determine the second data center where the first application is currently deployed. If the first application migrates or an operation request is issued across boundary proxies, causing inconsistencies between the first and second data centers, the first gateway can forward the operation request to the second gateway corresponding to the second data center where the first application is deployed. This ensures that the operation request is accurately sent to the second data center through the second gateway. In this way, operation requests initiated for the first application can be sent normally and accurately to the data center where the first application is currently deployed, even in cases of application migration or cross-proxygen requests, without interrupting the flow of operation requests, thus improving disaster recovery capabilities under abnormal conditions.

[0167] In some embodiments, the step 203 of "determining a third boundary agent from the candidate boundary agents according to the priority parameters of the candidate boundary agents" can be implemented in the following way: for each candidate boundary agent among a plurality of candidate boundary agents, a priority parameter of the candidate boundary agent is determined; a data processing model predicts the priority of the candidate boundary agent to be selected based on the priority parameter; and the candidate boundary agent whose priority is higher than the preset priority is determined as the third boundary agent.

[0168] Priority parameters used to influence the selection priority of each candidate boundary agent may include at least one of the following: the hardware processing resource margin of the candidate boundary agent, and the concurrent request processing capacity.

[0169] In practice, after determining that the first boundary proxy is faulty, cross-boundary proxy forwarding of operation requests can be achieved through any candidate boundary proxy other than the first boundary proxy. If there are multiple candidate boundary proxies, a suitable candidate boundary proxy can be selected as the third boundary proxy based on the hardware processing resource availability and concurrent request processing volume of the multiple candidate boundary proxies.

[0170] As an example, when a border proxy forwards and processes requests, it may be affected by the following factors: the hardware resources of the border proxy (such as CPU, memory, network bandwidth, etc.). When the number of requests to the border proxy exceeds the processing capacity of the proxy server hardware, a performance bottleneck will occur; the preset threshold for concurrent request processing of the border proxy. Exceeding this threshold may cause new requests to be rejected or delayed. Therefore, in this embodiment of the application, the influencing parameters that may affect the selection priority of each fourth border proxy may include at least one of the hardware processing resource margin of the fourth border proxy and the concurrent request processing volume.

[0171] The system obtains the current hardware processing resource availability and concurrent request processing volume of each candidate boundary agent. A pre-trained data processing model is then used to predict the selection priority of each candidate boundary agent, resulting in a predetermined selection priority. The principle behind this prediction is that a larger hardware processing resource availability and a smaller concurrent request processing volume result in a higher selection priority. Subsequently, based on the selection priorities determined by the data processing model, candidate boundary agents with selection priorities higher than a preset priority are selected. A third boundary agent is then determined from this selected pool. For example, either any candidate boundary agent from the selected pool can be chosen as the third boundary agent, or the candidate boundary agent with the highest selected priority can be selected as the third boundary agent.

[0172] By selecting a third-boundary proxy in the above manner, the occurrence of request timeouts, rejection of new request processing by the third-boundary proxy, and slow response speed due to increased processing time of operation requests can be reduced, thereby improving the processing rate of operation requests for the first application.

[0173] In one specific embodiment, the request processing system may include a first gateway of a first data center, a second gateway of a second data center, and a request relay zone, wherein the request relay zone is configured with a first boundary proxy of the first data center.

[0174] The request relay zone is used to respond to operation requests for the first application, determine the first data center where the first application is pre-deployed, and the first boundary proxy corresponding to the first data center, and send the operation request to the first boundary proxy when the first boundary proxy is normal, and forward the operation request to the first gateway through the first boundary proxy; the first gateway is used to respond to the operation request, and when it is determined that the first data center is inconsistent with the second data center where the first application is currently deployed, it sends the operation request to the second gateway; the second gateway is used to send the operation request to the second data center.

[0175] In practical applications, the request transit zone can be built based on Demilitarized Zone (DMZ) technology, and multiple border proxies can be set up within the request transit zone. Data centers are built using Internet Data Centers (IDCs), and corresponding gateways are configured for each data center.

[0176] As an example, Figure 7 This is a schematic diagram of the operation request chain based on multiple data centers provided in an embodiment of this application. (See also...) Figure 7 Users can initiate an operation request for the first application (e.g., application A) through the inbound domain name (A.xxx.com) corresponding to the first application (e.g., application A) on the external network. The request relay zone responds to the operation request for the first application (e.g., application A), determines the central identifier (e.g., data center 1) of the data center corresponding to the first application (e.g., application A) based on the application metadata, and then converts the inbound domain name to a fourth-level domain name (Area1.idc1.xxx.com). Based on the application identifier and the fourth-level domain name in the inbound domain name corresponding to the operation request, the first proxy address (e.g., 1.1.1.1) of the first boundary proxy is determined in the first mapping table shown in Table 5(b). The request relay zone forwards the operation request to the first gateway (1.xxx). When the first gateway determines that the data center where the first application is deployed and its corresponding data center are both data centers with the central identifier data center 1, the operation request is forwarded to data center 1.

[0177] As an example, please continue reading Figure 7 In the process of requesting a fourth-level domain name in the transit zone to point to a proxy address via a dotted line, this can be achieved by modifying or updating the first or second mapping table; this involves switching at the proxy level. At the gateway level, the gateway can forward operation requests to other gateways via dotted lines to ensure that the operation request link remains uninterrupted.

[0178] As an example, Figure 8 This is a second flow diagram of the operation request provided in the embodiments of this application. In the request processing system of this application embodiment, the flow path of the operation request in the system includes, as follows: Figure 8 The four scenarios are shown.

[0179] Specifically, with Figure 8 Taking application A as an example, application A is deployed in data center IDC1, and the corresponding business area is Area1. Based on the request processing process of application A, if application C is deployed in data center IDC2, and the corresponding business area is Area2, the request processing process of application C can be verified in the same way.

[0180] In Scene 1, see Figure 8In Figure (a), application A is currently deployed in Area1 of data center IDC1. The inbound domain name of application A corresponds to the fourth-level domain Area1.idc1.xxx.com. Inbound traffic corresponding to operation requests for application A is forwarded to the gateway (1.1.1.2) via the boundary proxy (1.1.1.1) in the request transit zone, and then forwarded to data center IDC1 by the gateway (1.1.1.2). In this scenario, the flow path of inbound traffic is entirely on the line built for data center IDC1.

[0181] In scenario two, see [reference] Figure 8 In Figure (b), application A has migrated from data center IDC1 to data center IDC2. However, the first mapping table has not yet been updated. Therefore, the inbound traffic corresponding to the operation request for application A is forwarded through the boundary proxy (1.1.1.1) of the request transit zone to the gateway (1.1.1.2), then forwarded by the gateway (1.1.1.2) to the gateway (2.1.1.2), and finally forwarded by the gateway (2.1.1.2) to data center IDC2. This scenario represents a traffic path where the application layer has completed the switch, but the proxy layer has not yet completed the switch.

[0182] In Scenario 3, see [link / reference] Figure 8 In diagram (c), application A has not migrated, but the border proxy (1.1.1.1) corresponding to data center IDC1 is experiencing an anomaly. Therefore, the inbound traffic corresponding to the operation request for application A can cross the border proxy, being forwarded from the border proxy (2.1.1.1) to the gateway (2.1.1.2), then from the gateway (2.1.1.2) to the gateway (1.1.1.2), and finally from the gateway (1.1.1.2) to data center IDC1. This scenario illustrates the traffic path across the border proxy in the inbound process.

[0183] In Scenario 4, see [reference] Figure 8 In diagram (d), application A has migrated from data center IDC1 to data center IDC2, and the first mapping table has also been updated, meaning that both the proxy layer and the application layer have completed the switch. Therefore, the inbound traffic corresponding to the operation request of application A can request the boundary proxy (2.1.1.1) in the transit zone to forward it to the gateway (2.1.1.2), and then forward it to data center IDC2 through the gateway (2.1.1.2). In this way, the entire inbound traffic path converges from the line switch of data center IDC1 to the line of data center IDC2.

[0184] In this embodiment, the request processing system, including both the request relay zone and the gateway, has its routing configuration pre-configured, such as the first mapping table, the second mapping table, application metadata, and the routing address mapping table mentioned above. When applications migrate subsequently, the routing configuration requires no adjustment; only timely updates to the various tables are needed, reducing manual operations and shortening application migration time. Furthermore, in the event of data center failure, if a large number of applications migrate, at the proxy level, only the first mapping table needs to be updated. Based on the first mapping table, operation requests for the migrated applications only require a single parsing process, reducing the pressure on the request relay zone and shortening parsing time. For applications, only the relevant routing configuration needs to be performed when adding a new application; no further configuration adjustments are required afterward.

[0185] Furthermore, through the above embodiments, after application migration, the migration at the application layer and proxy layer can be completed in a timely manner by updating the mapping table, achieving a smooth switch of inbound traffic without the user's awareness as the requester. This ensures that the entire traffic link is on the same data center line as quickly as possible, reducing the occurrence of cross-data center and cross-traffic access. By configuring the first mapping table, the second mapping table, application metadata, and the routing address mapping table, it can also be applied to the horizontal expansion of subsequent data centers and the division of business areas within the data center network.

[0186] The following description continues to illustrate the exemplary structure of the request processing device 455A provided in the embodiments of this application as a software module. In some embodiments, such as Figure 3A As shown, the software modules stored in the request processing device 455A in the memory 440 may include:

[0187] The acquisition module 4551 is used to acquire the application identifier carried in the operation request in response to the operation request for the first application.

[0188] The determination module 4552 is used to determine the first data center corresponding to the first gateway and to determine the second data center corresponding to the first application based on the application identifier.

[0189] The gateway sending module 4553 is used to send an operation request to the second data center through the second gateway corresponding to the second data center if the first data center and the second data center are inconsistent, so that the second data center can perform the operation indicated by the operation request on the first application.

[0190] In some embodiments, the request processing apparatus 455A further includes a second sending module, configured to send an operation request to the first data center when the first data center and the second data center are the same, so that the first data center performs the operation requested by the operation request for the first application.

[0191] In some embodiments, the second sending module is further configured to determine the first application routing address corresponding to the first application based on the first center identifier and the application identifier of the first data center; and send the operation request to the first data center based on the first application routing address.

[0192] In some embodiments, the gateway sending module 4553 is further configured to determine the second gateway corresponding to the second data center; send an operation request to the second gateway, so that the second gateway determines the second application routing address corresponding to the first application based on the second center identifier and application identifier of the second data center, and sends the operation request to the second application routing address; wherein, the second application routing address is the interface address allocated by the second data center for the first application.

[0193] The following description continues to illustrate the exemplary structure of the request processing device 455B provided in the embodiments of this application as a software module. In some embodiments, such as Figure 3B As shown, the software modules stored in the request processing device 455B of the memory 440 may include:

[0194] The proxy determination module 4554 is used to determine the first boundary proxy corresponding to the first application in response to an operation request for the first application.

[0195] The proxy sending module 4555 is used to send an operation request to the first boundary proxy when the first boundary proxy is normal, and forward the operation request to the first gateway through the first boundary proxy so that the first gateway responds to the operation request. When it is determined that the first data center corresponding to the first gateway is inconsistent with the second data center corresponding to the first application, the first gateway sends the operation request to the second data center through the second gateway corresponding to the second data center so that the second data center performs the operation indicated by the operation request on the first application.

[0196] In some embodiments, the proxy determination module 4554 is further configured to obtain the application identifier carried in the operation request; determine the first proxy address based on the first mapping table between the application identifier and the proxy address and the application identifier; and determine the first boundary proxy based on the first proxy address.

[0197] In some embodiments, the request processing apparatus 455B further includes a first update module, configured to determine a first center identifier of the first data center based on the application metadata of the first application; determine a first proxy address based on a second mapping table of the center identifier and the proxy address and the first center identifier; establish a first mapping relationship between the application identifier of the first application and the first proxy address, and add the first mapping relationship to the first mapping table.

[0198] In some embodiments, the first update module is further configured to delete the first mapping relationship from the first mapping table and establish a second mapping relationship between the application identifier of the first application and the second proxy address, wherein the second proxy address corresponds to the second data center, if the first mapping relationship is invalid; and add the second mapping relationship to the first mapping table.

[0199] In some embodiments, the first update module is further configured to determine that the first mapping relationship is invalid if the first data center corresponding to the first gateway is inconsistent with the second data center to which the first application belongs; or, if the second mapping table indicates that the proxy address corresponding to the first center identifier is updated from the first proxy address to the second proxy address, the first update module is configured to determine that the first mapping relationship is invalid.

[0200] In some embodiments, the request processing apparatus 455B further includes a fourth sending module, configured to determine a third boundary agent from the candidate boundary agents based on the priority parameter of the candidate boundary agents in the event of an anomaly of the first boundary agent, and to forward the operation request using the third boundary agent.

[0201] In some embodiments, the fourth sending module is further configured to, if the first boundary proxy is abnormal, send an operation request to the third boundary proxy of the third data center, and forward the operation request to the third gateway of the third data center through the third boundary proxy, so that the third gateway, in response to the operation request, determines that the third data center and the second data center are inconsistent, and sends the operation request to the second data center through the second gateway corresponding to the second data center, so that the second data center performs the operation indicated by the operation request on the first application.

[0202] In some embodiments, the fourth sending module is further configured to determine a priority parameter for each of the multiple candidate boundary agents; the data processing model predicts the priority of the candidate boundary agent to be selected based on the priority parameter; and the candidate boundary agent whose priority is higher than the preset priority is determined as the third boundary agent.

[0203] This application provides a computer program product including a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the request processing method described above in this application.

[0204] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the request processing method provided in this application, for example, such as... Figure 4 The request processing method is shown.

[0205] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0206] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0207] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0208] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located in one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0209] In summary, through the embodiments of this application, corresponding gateways are configured for each data center. These gateways can send requests to their respective data centers or forward requests to gateways in other data centers. This isolates operation requests for applications within a data center through these gateways. When a gateway receives an operation request that is not for an application in its corresponding data center, it can forward the request to the appropriate gateway to ensure the normal flow of the operation request. Specifically, when the first gateway receives an operation request for the first application, it responds by determining its own corresponding first data center and then using the application identifier carried in the operation request to determine the second data center currently corresponding to the first application. If the first and second data centers are inconsistent, the first gateway can forward the operation request to the second gateway corresponding to the second data center of the first application, ensuring the operation request is accurately sent to the second data center. This approach ensures that operation requests initiated for the first application can be correctly and accurately sent to the data center currently corresponding to the first application during application migration or other situations, without interrupting the operation request link and improving disaster recovery capabilities under abnormal circumstances.

[0210] In the request processing system of this application embodiment, the routing configurations of both the request relay zone and the gateway are pre-configured, such as the first mapping table, the second mapping table, application metadata, and the routing address mapping table mentioned above. When applications migrate subsequently, the routing configuration does not need any adjustment; only the tables need to be updated promptly, reducing manual operations and shortening application migration time. Furthermore, in the event of data center failure, if a large number of applications migrate, at the proxy level, only the first mapping table needs to be updated. Based on the first mapping table, operation requests for the migrated applications only need to undergo a single parsing process. This reduces the pressure on the request relay zone and shortens the parsing time. For applications, only the relevant routing configuration needs to be performed when adding a new application; no further configuration adjustments are required afterward. Moreover, after application migration, the migration at the application level and the proxy level can be completed promptly by updating the mapping table through management, achieving a smooth switch of inbound traffic without the user's awareness as the requester. This ensures that the entire traffic link is on the same data center line as quickly as possible, reducing the occurrence of cross-data center and cross-traffic access. By configuring the first mapping table, the second mapping table, application metadata, and the routing address mapping table, it can also be applied to the horizontal expansion of the data center and the internal network of the data center to divide the business areas.

[0211] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A request processing method, characterized in that, Applied to the first gateway; the method includes: In response to an operation request for a first application, obtain the application identifier carried in the operation request; Determine the first data center corresponding to the first gateway, and determine the second data center corresponding to the first application based on the application identifier; If the first data center and the second data center are not the same, the operation request is sent to the second data center through the second gateway corresponding to the second data center, so that the second data center performs the operation indicated by the operation request on the first application.

2. The method according to claim 1, characterized in that, The method further includes: If the first data center and the second data center are the same, the operation request is sent to the first data center so that the first data center performs the operation requested by the operation request on the first application.

3. A request processing method, characterized in that, Applied to a request transit zone; the method includes: In response to an operation request for the first application, determine the first boundary proxy corresponding to the first application; When the first boundary proxy is functioning normally, the operation request is sent to the first boundary proxy and forwarded to the first gateway through the first boundary proxy, so that the first gateway responds to the operation request. When it is determined that the first data center corresponding to the first gateway is inconsistent with the second data center corresponding to the first application, the operation request is sent to the second data center through the second gateway corresponding to the second data center, so that the second data center performs the operation indicated by the operation request on the first application.

4. The method according to claim 3, characterized in that, Determining the first boundary proxy corresponding to the first application includes: Obtain the application identifier carried in the operation request; Based on the first mapping table between application identifiers and proxy addresses and the application identifiers, a first proxy address is determined, and a first boundary proxy is determined based on the first proxy address.

5. The method according to claim 4, characterized in that, Before determining the first proxy address based on the first mapping table between the application identifier and the proxy address and the application identifier, the method further includes: Based on the application metadata of the first application, determine the first center identifier of the first data center; The first proxy address is determined based on the second mapping table between the central identifier and the proxy address, and the first central identifier. Establish a first mapping relationship between the application identifier of the first application and the first proxy address, and add the first mapping relationship to the first mapping table.

6. The method according to claim 5, characterized in that, The method further includes: If the first mapping relationship is invalid, delete the first mapping relationship from the first mapping table and establish a second mapping relationship between the application identifier of the first application and the second proxy address, where the second proxy address corresponds to the second data center; Add the second mapping relationship to the first mapping table.

7. The method according to claim 6, characterized in that, The method further includes: If the first data center corresponding to the first gateway is inconsistent with the second data center to which the first application belongs, the first mapping relationship is determined to be invalid. Alternatively, if the second mapping table indicates that the proxy address corresponding to the first central identifier has been updated from the first proxy address to the second proxy address, the first mapping relationship is determined to be invalid.

8. The method according to claim 3, characterized in that, The method further includes: In the event of an anomaly in the first boundary proxy, a third boundary proxy is determined from the candidate boundary proxies based on their priority parameters, and the operation request is forwarded using the third boundary proxy.

9. A request processing apparatus, characterized in that, The device is located at the first gateway; the device includes: The acquisition module is used to acquire the application identifier carried in the operation request in response to the operation request for the first application. The determination module is used to determine the first data center corresponding to the first gateway, and to determine the second data center corresponding to the first application based on the application identifier; The gateway sending module is used to send the operation request to the second data center through the second gateway corresponding to the second data center if the first data center and the second data center are inconsistent, so that the second data center performs the operation indicated by the operation request on the first application.

10. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions for a computer; A processor, when executing computer-executable instructions stored in the memory, implements the method according to any one of claims 1 to 8.

Images