Cross-regional data processing

Abstract

Techniques are disclosed for implementing cross-region communication for computing regions executing different coding protocols. A server computer system may receive a request for a service via a proxy layer of a first application instance executing within a first computing area according to a first set of encoding protocols, the service being executed via a second application instance in a second computing area according to a different second set of encoding protocols. The system may change, via the remote layer of the first instance, a set of data specified in the request to comply with the second set of protocols. The system may transmit the modified set of data to the remote layer of the second instance via the remote layer of the first instance. The system can advantageously provide a simplified development interface, allowing development and testing in a local environment without the need to deploy a plurality of different services.

Description

Technical Field

[0001] The present disclosure relates generally to data management, and more particularly to techniques for managing data communications across multiple computing areas having different data management and communication protocols. Background Art

[0002] As more and more entities migrate their data from physical data centers to cloud storage devices, data communication across cloud storage devices becomes increasingly complex. Similarly, as entities divide their data between different regions (e.g., online production regions, offline batch computing regions, etc.), data communication and security policies across these different regions become more complex, which may require more computer resources, such as network bandwidth, storage, CPU processing, monetary resources, etc. For example, the number of policies (e.g., security policies such as injection authentication policies) that data must follow when communicating across regions increases. This, in turn, may increase the development burden of generating program code in a multi-region development environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 is a block diagram illustrating an example system configured to facilitate cross-region data processing according to some embodiments.

[0004] Figure 2 is a block diagram illustrating example cross-region policy differentiation and an example cross-region processing pipeline according to some embodiments.

[0005] Figure 3 is a block diagram illustrating example RPC layer policies and example database services according to some embodiments.

[0006] Figure 4 is a block diagram illustrating example cross-region communications involving multiple code repositories according to some embodiments.

[0007] Figure 5A and Figure 5B are block diagrams illustrating an example system architecture and a developer's view, respectively, of the disclosed cross-region data processing according to some embodiments.

[0008] Figure 6 is a block diagram illustrating an example system architecture of a system configured to facilitate cross-region data processing according to some embodiments.

[0009] Figure 7 is a flow chart illustrating a method for processing cross-region data processing requests via a multi-tier application configuration according to some embodiments.

[0010] Figure 8 is a block diagram illustrating an example computing device in accordance with some embodiments. DETAILED DESCRIPTION

[0011] In various cases, cross-region (also referred to herein as cross-cloud) data processing becomes increasingly complex due to different policies implemented in different regions or different cloud environments. For example, as part of executing a given programming process, a computing system may need to perform a first step to process a set of data in a first region, and then perform a second step to process the set of data in a second region. In this example, the first region may require communication via Hypertext Transfer Protocol (HTTP), while the second region may require communication via messageQ. Therefore, in this example, the program code of a given programming process may need to be changed to allow communication between two regions requiring two different communication protocols. Different regions may implement different types of communication, data management, security, and other policies or protocols. As a specific example, within a given system architecture, two separate engines may perform data management and data loading. In this specific example, a data management engine is deployed as software as a service (SaaS) (e.g., a customer data platform) in an online production region, while a set of data loading tasks are executed in a distributed computing cluster (e.g., a Hadoop cluster) in an offline batch computing region. In other cases, the online production region may be in a cloud computing environment (e.g., Google Cloud Platform TM ) is executed.

[0012] Traditional cross-region communication systems often attempt to address differences in cross-region policies by manually changing every part of the program code involved in cross-region data processing. Another traditional approach involves developing highly customized services and agents and deploying these services across regions or across different clouds. However, the cost of developing and maintaining such solutions is high (both in terms of computing and finance). For example, a traditional communication system attempts to facilitate cross-region communication via a cloud gateway, where multiple different microservices corresponding to different data regions communicate with the cloud gateway to facilitate communication between each different region. However, this cloud gateway communication is cumbersome in terms of computing resources and is often difficult for end users to interact with and implement.

[0013] The disclosed technology provides a framework that includes one or more abstraction layers that mask the differences in protocols and security policies on different regions or cloud services while preventing intrusion into entity-specific logic (e.g., business logic), which can advantageously reduce the development and maintenance costs of program codes belonging to different entities that communicate across regions or across clouds. For example, during the development of program code, the disclosed technology provides developers with simplified configurations and interfaces to reduce the developer's workload (e.g., abstracting the developer's view of the program code).

[0014] During maintenance of program code, the disclosed technology builds and deploys the same application with different configurations to different regions or clouds. Furthermore, the disclosed technology allows increasing or decreasing the number of application instances in each region to achieve scalability. In various cases, the disclosed technology decouples the business logic of the entity and the underlying communication logic of the program code into two separate layers: a web application layer and an abstraction and adapter layer. For example, the web application layer may be a proxy layer that provides annotations and interfaces for marking services to execute in different regions, and the abstraction and adapter layer may be a remote procedure call (RPC) layer. In order to reduce the cost of developing and managing program code that includes cross-region or cross-cloud communication, the disclosed technology changes the overall framework of the network system instead of requiring developers to change their underlying business logic.

[0015] Unlike entities that attempt to employ multiple microsystems to allow different regions or clouds to communicate with a central gateway to achieve cross-region communication, the disclosed framework decoupling technology can advantageously reduce the amount of time (e.g., developer time) and computing power to develop and maintain cross-region communication networks. The disclosed unified management service allows developers to view a single service including a single code repository to develop and test their program code in a local environment without having to deploy, for example, two different services and two different testing processes during the development phase. For example, when a new region is introduced within the disclosed multi-tier system architecture, developers do not need to modify or migrate their specific logic (e.g., business logic), but are able to develop new extensions to the framework to add their region.

[0016] As used herein, the term "region" refers to a group of computer systems that implement different protocols and policies. For example, a first computing region may include a collection of one or more data repositories (e.g., databases) controlled by a specific network device and operated according to a set of policies. The first computing region may execute a first set of policies, while the second computing region may enforce a second set of different policies. In the disclosed technology, a region may refer to a given internal environment, such as a test region (e.g., PayPal offline data loading and batch computing region) or a production region (e.g., another PayPal code processing region). For example, data in a software development environment generally does not have strict security requirements in a software production environment. Similarly, data in a specific geographic region may have certain legal requirements (e.g., privacy laws) that are different from those in other regions. A data center (i.e., a physical facility that stores data that drives enterprise computing applications) may be considered a type of data region. For example, a region may also refer to an environment distributed across clouds (e.g., facilitated via Google Cloud Platform), such as an entity's program code executed in a first data center, and communicated across clouds with a second entity's program code executed in a different second data center. Therefore, in the disclosed embodiments, both the terms cross-region and cross-cloud can be used.

[0017] Example multi-tier system architecture

[0018] Figure 1 is a block diagram illustrating an example system configured to facilitate cross-region data processing. In the illustrated embodiment, system 100 includes two different computing regions 130A and 130B having application instances 102 and 112 , respectively, that participate in cross-region communication via an intermediate module 160 .

[0019] In the illustrated embodiment, the first region 130A includes one or more databases 150A and an application instance 102, which in turn includes one or more proxy modules 104A and a cross-region communication module 110A, and the application instance 102 is divided into two different layers: a proxy layer 122 and a remote layer 124. The proxy layer 122 provides annotations and interfaces to entities (e.g., end users or developers), which allows entities to mark services that require execution in different computing regions. The remote layer 124 provides an abstract layer for implementing protocols or security policies across computing regions. In various embodiments, the remote layer 124 can be extended to adapt to different regions (e.g., developers can adapt the remote layer to different policies or protocols). In some embodiments, the application instance 102 is a web application (e.g., executed using Java Spring Boot). In various embodiments, multiple instances of the application (e.g., in addition to the application instance 102 or the application instance 112) are deployed in the first region 130A or the second region 130B. In some cases, the application instance 102 and the application instance 112 can use the Java framework as Spring Boot TM In other cases, only one of the instances 102 and 112 is executed as a Spring Boot application.

[0020] The first region 130A also includes one or more databases 150A that store data for the application instance 102. For example, the (one or more) databases 150A can act as a code repository for storing program code drafted by an entity utilizing the application instance 102. The (one or more) databases 150A can also store various policies and protocols implemented by the first region 130A. In some embodiments, the first region 130A is an online production region deployed as a data management engine. The data management engine can be deployed as a standard software as a service (SaaS), such as a flowchart-based programming environment. As described above, as a specific example, SaaS can be deployed using a Spring Boot application.

[0021] In the illustrated embodiment, the second region 130B also includes (one or more) databases 150B that execute similarly to (one or more) databases 150A but store different policies and protocols. Similarly, the second region 130B includes an application instance 112, which includes one or more proxy modules 104B and a cross-region communication module 110B. In the disclosed technology, the service executed in module 110A (or module 110B) is replaced by a proxy version of the service from the second region 130B, and the proxy service makes a call to the second region 130B instead of calling a local service in the first region 130A. For example, the proxy service is an object generated by the disclosed system architecture that implements the same user interface as the source service. As a specific example, an interface named "JobService" with a method name "createJob()" is implemented by an original implementation named "Job ServicImpl" in an application programming interface (e.g., Hadoop API) that is reachable only in a batch computing region (e.g., the first region 130A). The disclosed system architecture generates an object in an online computing region (eg, the second region 130B) and implements a "JobService" interface and proxies requests to a batch computing region (eg, the first region 130A).

[0022] In various embodiments, the proxy module(s) 104A may receive a request for a service performed via the application instance 112. For example, the request may be initiated based on program code generated by an end user (e.g., a developer) via the application instance 112. The program code may be executed according to a first set of encoding protocols, but may need to communicate with or access data stored in the second region 130B, which is executed according to a second set of different encoding protocols. The request is processed by the proxy module(s) 104A and sent to the cross-region communication module 110A included in the remote layer 124 of the application instance 102. The cross-region communication module 110A changes the data included in the request to comply with the second set of different encoding protocols implemented by the second region 130B, and then sends the request including the changed data to the intermediate module 160. The intermediate module 160 then sends the request to the cross-region communication module 110B of the application instance 112. In various embodiments, the intermediate module 160 handles the authentication, authorization, and conversion processes of data between regions. In some embodiments, the intermediate module 160 is a communication module such as Apache Kafka. TM 、ActiveMQ TM 、Redis TM Event streaming platform such as .

[0023] In some embodiments, application instance 112 performs various operations including accessing database(s) 150B to retrieve data requested in a request received from first region 130B, and then relaying that information back to first region 130A via intermediary module 160. For example, data retrieved from database(s) 150B may require modification at cross-region communication module 110B to conform to a first set of encoding protocols implemented by first region 130A before transmitting the data to first computing region 130A.

[0024] In the present disclosure, various "modules" operable to perform specified functions are shown in the figures and described in detail (e.g., cross-region communication module 110A, intermediate module 160, etc.). As used herein, "module" refers to software or hardware operable to perform a specified set of operations. A module may refer to a set of software instructions that can be executed by a computer system to perform the set of operations. A module may also refer to hardware configured to perform the set of operations. A hardware module may constitute general-purpose hardware and a non-transitory computer-readable medium storing program instructions, or special-purpose hardware such as a customized application-specific integrated circuit (ASIC).

[0025] Example cross-region policy differences

[0026] Figure 2 is a block diagram illustrating example cross-region policy differences and example cross-region processing pipelines. In the illustrated embodiment, Figure 2 The example 200 shown at the top shows a communication conflict between different regions due to cross-region policy differences. For example, region A 202, region B 204, and region C 206 cannot communicate directly with each other without intermediate program code translation or modification of the data being processed or communicated between the three different regions.

[0027] Figure 2The example 230 shown in the bottom portion of shows seamless communication between three different computing regions via the disclosed cross-region communication architecture, which divides application instances into two different layers. For example, the region A management system 240 is able to interact directly with various other regions (e.g., region B 204 and region C 206). In the illustrated embodiment, the region A management system 240 performs action 232 in region A. This action is the first step in a given data processing pipeline. The region A management system 240 causes the next step (action 234) of the data processing pipeline to be performed in region C (e.g., processing data generated in region A 202). The region A management system 240 continues the given data processing pipeline by performing two separate actions 236 and 238 in region B. Then, the region management system 240 performs action 242 in region A to complete the data processing pipeline. In the illustrated embodiment, the cross-region data processing pipeline 230 enables direct calls between regions A, B, and C, and then returns to region A. For example, rather than having to manually change region A to communicate with region B using messageQ (the communication protocol used by region B), the disclosed cross-region communication architecture allows regions A and B to communicate without manually changing the communication protocols of the two regions. For example, region A can still implement HTTP while region B implements messageQ without having to change each code segment from implementing HTTP to implementing messageQ.

[0028] Example Application Layer

[0029] Figure 3 30B. 30A is a block diagram showing an example RPC layer strategy and an example database service. In the illustrated embodiment, the system 300 includes a first computing region 330A and a second computing region 330B that communicate via an intermediate module 360. The intermediate module 360 ​​can be executed via any of a variety of stream processing, database management, or messaging systems. In some embodiments, the first region 330A is a cloud-based computing region, and the second region 330B is an online production region. As a specific example, the first region 330A can be executed via Google Cloud Services, and the second region 330B can be executed via a server computer system local to PayPal. In this particular example, when transmitting data from, for example, Google Cloud Services to PayPal Services, region 330A may require different credentials from region 330B. In order to maintain the privacy and security of data in the PayPal service, the service implements various security policies that may require various different types of authorization or authentication.

[0030] In the illustrated embodiment, the first computing region 330A includes a database 354, a plurality of services 356, and an application 302. The application 302 is divided into two separate layers: a proxy layer 322 and an RPC layer 324. The proxy layer 322 includes a controller 304 and services 306, while the RPC layer 324 includes a data access object (DAO) 308A and a remote procedure call (RPC) module 310A. The database 354 can be implemented as a relational database or a non-relational database. In a relational implementation, the database 354 can be, for example, a MySQL database. In a non-relational implementation, for example, the database 354 can be implemented as a NoSQL database.

[0031] In the illustrated embodiment, the second computing region 330B includes the application 312, which is divided into two separate layers. The proxy layer 322 of the application 312 includes the controller 314 and the service 316 (the service 316 is a proxy version of the service 306), while the RPC layer 324 includes the RPC module 310B and the DOA module 308B. Note that Figure 3 The applications 302 and 312 shown in FIG. 3 may be two different instances of the same application, or may be two completely different applications.

[0032] The disclosed system architecture separates the application into two different layers by decoupling the business logic portion of the application from the communication logic portion of the application. For example, the proxy layer 322 includes the business logic of the application 302 and performs the functions of a typical web application, while the RPC layer 324 includes the communication logic and performs as an adapter layer.

[0033] In various embodiments, application 312 receives a request (e.g., from a developer) to execute program code via controller 314. Controller 314 provides details of the request to service 316, which is a proxy version of service 306. Service 316 performs one or more operations specified in the request and then provides information to RPC module 310B that specifies one or more operations or additional operations to be performed based on executing program code. RPC module 310B communicates with DOA module 308B to translate (or otherwise change) information before transmitting the information to first computing area 330A via intermediate module 360. In some embodiments, intermediate module 360 ​​performs additional translations or changes before providing the requested information to application 302. In various embodiments, application 302 can receive the request, and the process can be repeated in reverse by application 302 to communicate or execute program code within second computing area 330B. In embodiments where application 302 receives the request, application 302 may access database 354 or one or more other services 356 to modify the data according to the request before sending the information to region 330B via intermediate module 360 ​​.

[0034] Example multi-repository cross-region communication

[0035] Figure 4 is a block diagram illustrating an example cross-region communication involving multiple code repositories. In the illustrated embodiment, an offline batch computing region 410B communicates with an online production region 410A to process code maintained in three different code repositories 402A, 402B, and 402C.

[0036] In the illustrated embodiment, the system architecture 400 needs to maintain three different code repositories. For example, the maintenance of three different code repositories that follow different policies according to their corresponding regions (e.g., regions 410A and 410B) is often computationally and economically expensive due to the time to test, build, and deploy each repository. The offline batch computing region 410B accesses the code repository 402B, which manually maintains a script to obtain a task scheduling script 440. The script 440 is executed in response to a trigger 442, which causes the data loading task 450 retrieved from the code repository 402C to be executed. In some cases, the data loading task 450 retrieves data from the offline database 432B. In the illustrated embodiment, the data loading task 450 sends the retrieved data to the intermediate module 430, which changes the retrieved data to comply with the policy of the online production region 410A. After changing the retrieved code, the intermediate module 430 transmits the data to the data processing service 420. Data processing service 420 accesses code repository 402A to process data received from intermediate module 430. In some embodiments, as part of processing the received data, data processing service 420 accesses online database 432A to store the received data or to retrieve additional data for processing.

[0037] Data analysis and data processing between code repositories 402A, 402B, and 402C may be connected and executed through various different code segments generated and communicated via the intermediate module 430, which reduces the flexibility of data processing, especially when the system switches from one intermediate platform to another. In this example case, each code segment connected via the intermediate platform needs to be changed. However, as Figure 5A and Figure 5B As shown, the disclosed technology provides a system architecture that facilitates maintaining and using a single code repository across multiple regions.

[0038] Example unified cross-region system architecture

[0039] Figure 5A and Figure 5B 5 is a block diagram showing an example system architecture and a developer view of the disclosed cross-region data processing. In the illustrated embodiment, the system architecture 510 is as follows: Figure 5A As shown, the developer view 520 of the system architecture 520 is as follows Figure 5B shown.

[0040] exist Figure 5A, system architecture 510 includes local region 530A, third cloud region 530B, and code repository 502. Third cloud region 530B may be one of three different computing regions executing in a cloud in communication with local region 530A. System architecture 510 allows regions 530A and 530B to share the same code repository and implementation via the use of different configuration files (a first configuration file is executed for region 530A, while a different second configuration file is executed for region 530B).

[0041] Local area 530A includes application 532, while third cloud area 530B includes application 542. In addition, application 532 may include service 534A and service 536B (proxy), while application 542 may include service 544A and service 546B (proxy). In other cases, services 534A and 536B may be included in another application other than application 532 within local area 530A (thus, services 534A and 536B are not independent services). In the illustrated embodiment, application 532 executed by local area 530A accesses a single code repository 502 shared with application 542 executed by third cloud area 530B. In some embodiments, application 532 executes program code retrieved from code repository 502. For example, application 532 may communicate with service 543A or service 536B (which is a proxy version of service 546B executed within third cloud area 530B). For example, service 534A can be a graphics computing service that obtains data from multiple different entities (e.g., received via different instances of application 532) and draws the data so that it is displayed in a form that is easy to understand or manipulate. As a specific example, graphics computing service 534A can draw data for electronic communications (e.g., online transactions) and can perform various calculations on the drawn data (e.g., to determine whether the transaction is suspicious). In some embodiments, both service 534A and service 546B are graphics computing services, where one service receives data streams from various entities and draws the data, and the other service performs calculations on the drawn data. In some embodiments, service 534A can be a data object service for a local database, and service 536B can be a computing service for cloud area computing.

[0042] exist Figure 5B , a developer view 520 of architecture 510 includes code repository 502 and user interface 560, which in turn includes application 562, service A 504, and service B 506. One or more developers observing or interacting with view 520 will only see the proxy layer (e.g., Figure 3). For example, the terminal developer will interact with the user interface 560 to define certain settings in its corresponding configuration file so that the disclosed system architecture 510 recognizes different policies and protocols across different regions. As a specific example, the configuration file can specify one or more of the following items: whether a given framework is enabled (e.g., whether remote service execution is enabled), a timeout for a remote service (e.g., in seconds), one or more protocols for a given region (e.g., HTTP), and the current deployment region of a given service (e.g., service 534A is deployed in local region 530A). As a specific example, a given application can be deployed in the same code repository across multiple different computing regions. In this example, different instances of the same application will have different configurations in different regions (determined by the configuration files provided in different regions). However, in this example, the developer only sees a single service and code repository when interacting with one of the applications 532 or 542. In addition, in this example, developers are able to develop and test their program code within a single code repository in their local environment without having to deploy multiple different services during, for example, the development phase.

[0043] System architecture 510 (together with user interface 560) allows developers to test and execute their program code on local region 530A and third cloud region 530B without accessing their code or storing parts of their code in two different code repositories, or interacting with or deploying their code on multiple different services in different regions. Instead, developers see a single interface with two services, where they can write and test their code via a single code repository 502 in their local environment (local region 530A). In this way, program code can call cross-region services as easily as calling local services. For example, even if the original service 546B is located in the third cloud region 530B, service 534A can make a local call to proxy service 536B.

[0044] Figure 6 6 is a block diagram illustrating an example system architecture of a system configured to facilitate cross-region data processing. In the illustrated embodiment, system 600 includes three different regions: an online production region 670, a high availability region 672, and a batch computing region 674. An example cross-region data processing infrastructure for a platform (e.g., PayPal) is shown in FIG. Figure 6 It is shown as including various different software components (which can be executed via hardware components, for example, data warehouse 650 can be executed via any of various types of databases), including message queues, databases, clusters, applications, user interfaces, etc.

[0045] In the illustrated embodiment, several different clusters are deployed in two different computing regions (online production region 670 and high availability region 672) via the same code repository. For example, cluster 610A is deployed in online production region 670. Similarly, cluster 610B is deployed in high availability region 672, and cluster 610C is deployed in batch computing region 674. In the illustrated embodiment, these deployed clusters 610A, 610B, and 610C execute several backend applications 608A, 608B, and 608C, respectively. As a specific example, these backend applications 608A-608C can be a unified graph management service application that allows various entities to interact with and process data via an online graph management service (an example of online service 612). In various embodiments, due to the single code repository, developers viewing the code repository for deploying clusters 610A-610C will only see a single data processing application (e.g., backend application 608A), rather than three separate applications (e.g., applications 608B and 608C). In this way, developers can deploy a single service while testing or developing their program code in a single code repository.

[0046] In various embodiments, an entity (e.g., a developer) may interact with the web user interface 604 to access the backend application 608A to deploy its code. The backend application 608A may access the database 606 (which may be a relational database such as MySQL). TM , PostgreSQL TM 、Azure database TM ), and communicates with online services 612 via HTTP RPC protocol or communicates with components in high availability zone 672 (i.e., backend application 608C) via message queue RPC protocol. As an example, message queues can be implemented via one or more of the following message queue systems: Apache Kafka, Google Pub / Sub TM 、RocketMQ TM . The communication is achieved through an intermediate topic module 632A (e.g., a first topic implemented in Kafka). Topics can include various categories of messages transmitted via module 632A. For example, topics can be independent queue messages. As a specific example, a Kafka cluster can include multiple message queues that are independent of each other and execute for different use cases. In this particular example, one message queue (Topic A) can be used for the first topic of RPC communication, while another message queue (Topic B) can be used for business data transmission.

[0047] In the illustrated embodiment, the deployed cluster 610C includes processing executors 624A and 624B and a backend application 608B. The backend application 608B communicates with one or both of the executors based on commands or data received from the subject module 632 via the message queue RPC protocol. The processing executor 624A can be a pipeline executor that executes a pipeline of jobs received from the subject module 632, while the processing executor 622B can be a verification executor that verifies the jobs executed by the executor 624A. In some embodiments, the deployed cluster 610C is a continuous integration (CI) cluster.

[0048] For example, the online service 612 shown in the illustrated embodiment can be an online drawing service configured to process and draw a variety of different data. However, it is noted that the online service 612 can be any of various types of online services that process data, including data that needs to be processed or transmitted across different computing areas. In the illustrated embodiment, the online service 612 includes an online query service 614, two different online transaction processing (OLTP) databases 616A and 616B, and a real-time data processing service 620. It is noted that real-time data processing includes processing of a set of data that is completed within a threshold time (e.g., milliseconds, seconds, or minutes) after the start of processing the set of data. In the illustrated embodiment, the real-time data processing service 620 consumes events 634 received from a topic module 632B included in the cluster 630B based on the output of a batch job module 646B (the output is based on data received from a data warehouse 650). In some embodiments, the data warehouse 650 stores large-scale offline data from various entities (e.g., enterprises). For example, the data warehouse 650 can store user operation logs, user profile information, user portraits, etc.

[0049] Batch job module 646B can use Apache MapReduce TM 、Spark TM etc., while clusters 630A and 630B can use YARN Hadoop TM 、Nomad TM 、Apache Aurora TMetc. The real-time data processing service 620 then performs a write operation 622 to the OLTP database 616A based on the event 634, and sends a production log event 624 to the log service 636, which in turn communicates with the data warehouse 650 within the high availability zone 672. The OLTP database 616A provides data to the online query service 614, for example, so that the service provides data to an entity using the web user interface 604. In the illustrated embodiment, the online service 612 also receives data and stores it in the OLTP database 616B. The data stored in the database 616B is received via the data movement service 638. In the illustrated embodiment, the data movement service 638 receives and executes the data processing job 652 from the data warehouse 650. The data movement service 638 can use Wormhole TM 、Internxt TM Waiting to realize.

[0050] In the illustrated embodiment, the deployed cluster 610B includes a data processing executor 640. In some embodiments, the deployed cluster 610B includes multiple executors. For example, the deployed cluster 610B may include any of a pipeline, validation, distributed replica executor, or various other types of modules that can execute various batch jobs of the backend application 608C. The multiple executors included in the cluster 610B can perform various data processing tasks, such as executing Hadoop jobs.

[0051] Example Method

[0052] Figure 7 is a flow chart illustrating a method 700 for processing cross-region data processing requests via a multi-tier application configuration according to some embodiments. Figure 7 The method 700 shown in the can be used in combination with any computer circuit, system, device, element or component disclosed herein and other devices. In various embodiments, some of the method elements shown can be performed simultaneously in a different order than shown, or can be omitted. Other method elements can also be performed as needed. In some embodiments, the method 700 is performed by one or more server systems executed in the first area 130A or the second area 130B of the system architecture 100.

[0053] At 710, in the illustrated embodiment, a server computer system receives, via a proxy layer of a first application instance executing in a first computing region according to a first set of coding protocols, a request for a service executed in a second computing region via a second application instance according to a second, different set of coding protocols. In some embodiments, the first set of coding protocols includes an authentication protocol that prompts for a developer certificate, wherein the second, different set of coding protocols includes a load balancing protocol. In some embodiments, the first instance and the second instance of the application are implemented via a single code repository across the first computing region and the second computing region.

[0054] At 720, the server computer system changes a set of data specified in the request via a remote layer of the first application instance to conform to a second, different set of encoding protocols. In some embodiments, a proxy layer of the first application instance is visible to one or more developers using the first application instance and provides annotations and a user interface to the one or more developers interacting with the first application instance, wherein the remote layer of the first application instance is not visible to the one or more developers and abstracts underlying differences between protocols of different computing regions. In some embodiments, the remote layer of the first application instance and the second application instance is a remote procedure call (RPC) layer, wherein the annotations and the user interface provided by the proxy layer allow the developer to indicate one or more services executed in different computing regions.

[0055] At 730, the server computer system transmits the modified set of data specified in the request for the service to the remote layer of the second application instance via the remote layer of the first application instance. In some embodiments, the receiving, modifying, and transmitting are performed using a single code repository, where the single code repository can be used to develop and execute program code across multiple application instances on multiple different computing regions. In some embodiments, the single code repository simplifies calls by program code to cross-region services so that they are similar to calls to local services (e.g., services local to a given computing region).

[0056] In some embodiments, prior to transmitting a set of data specified in a request for a service executed via a second application instance, a server computer system communicates with a service executed within a first computing region via a remote layer of a first application instance. In some embodiments, the communication includes modifying, by the remote layer of the first application instance, data received in the request for a service executed via a second application instance. In some embodiments, the remote layer of the first application is an RPC layer that executes program code using a structured query language (e.g., MySQL) or a service as part of the execution of the code prior to communicating with other regions.

[0057] In some embodiments, the alteration includes converting a first type of communication protocol implemented by the first computing area to a second type of communication protocol implemented by the second computing area. In some embodiments, the first type of communication protocol implemented by the first computing area is a client-to-server request-response communication protocol, and the second type of communication protocol implemented by the second computing area is an asynchronous process-to-process communication protocol. For example, the two different communication protocols may be HTTP and messageQ. In some embodiments, the first computing area is a first cloud computing area, and the second computing area is a different second cloud computing area. In some embodiments, the first computing area is a cloud computing area, and the second computing area is an offline testing area.

[0058] In some embodiments, the disclosed system architecture decouples the business logic and the underlying communication log within a given region. For example, when developing code to process data across multiple regions, developers using the disclosed system architecture do not need to see what is happening at the bottom layer. In some embodiments, the first computing region is an online production region and the second computing region is an offline batch computing region. In some embodiments, the transmission between the remote layer of the first application instance executed in the first computing region and the remote layer of the second application instance executed in the second computing region is performed via an intermediate data stream processor that transmits data in real time between the two computing regions. In some embodiments, the remote layer of the first application implements Apache Kafka.

[0059] Example computing device

[0060] Now go to Figure 8 , depicts a block diagram of an embodiment of a computing device (which may also be referred to as a computing system) 810. The computing device 810 may be used to implement various portions of the present disclosure. The computing device 810 may be any suitable type of device, including but not limited to a personal computer system, a desktop computer, a laptop or notebook computer, a mainframe computer system, a network server, a workstation, or a network computer. In some embodiments, the computing device 810 is an example of the system 100, or a client computer system executing the application instance 102 or a client computer system executing the application instance 112. As shown, the computing device 810 includes a processing unit 850, a storage device 812, and an input / output (I / O) interface 830 coupled via an interconnect 860 (e.g., a system bus). The I / O interface 830 may be coupled to one or more I / O devices 840. The computing device 810 also includes a network interface 832, which may be coupled to a network 820 for communicating with, for example, other computing devices.

[0061] In various embodiments, processing unit 850 includes one or more processors. In some embodiments, processing unit 850 includes one or more coprocessor units. In some embodiments, multiple instances of processing unit 850 may be coupled to interconnect 860. Processing unit 850 (or each processor within 850) may include cache or other forms of onboard memory. In some embodiments, processing unit 850 may be implemented as a general-purpose processing unit, and in other embodiments, processing unit 850 may be implemented as a special-purpose processing unit (e.g., ASIC). In general, computing device 810 is not limited to any particular type of processing unit or processor subsystem.

[0062] Storage subsystem 812 may be used by processing unit 850 (e.g., to store instructions executable and data used by processing unit 850). Storage subsystem 812 may be implemented by any suitable type of physical storage medium, including hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM—SRAM, EDO RAM, SDRAM, DDR SDRAM, RDRAM, etc.), ROM (PROM, EEPROM, etc.), etc. In one embodiment, storage subsystem 812 may consist only of volatile memory. Storage subsystem 812 may store program instructions executable by computing device 810 using processing unit 850, including program instructions executable to cause computing device 810 to implement various techniques disclosed herein.

[0063] According to various embodiments, the I / O interface 830 may represent one or more interfaces and may be any of various types of interfaces configured to be coupled to and communicate with other devices. In one embodiment, the I / O interface 830 is a bridge chip from the front side to one or more back side buses. The I / O interface 830 may be coupled to one or more I / O devices 840 via one or more corresponding buses or other interfaces. Examples of I / O devices include storage devices (hard disks, optical drives, removable flash drives, storage arrays, SANs or related controllers), network interface devices, user interface devices, or other devices (e.g., graphics, sound, etc.).

[0064] Various articles of manufacture that store instructions (and optionally data) that can be executed by a computing system to implement the techniques disclosed herein are also contemplated. The computing system can use one or more processing elements to execute the instructions. Articles of manufacture include non-transitory computer-readable storage media. Contemplated non-transitory computer-readable storage media include portions of a memory subsystem of a computing device, and storage media or storage media, such as magnetic media (e.g., disks) or optical media (e.g., CDs, DVDs, and related technologies, etc.). Non-transitory computer-readable media can be volatile or non-volatile memory.

[0065] The present disclosure includes references to "an embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different implementations or instances of the disclosed concepts. References to "an embodiment," "one embodiment," "a particular embodiment," etc. do not necessarily refer to the same embodiment. A large number of possible embodiments are contemplated, including those specifically disclosed as well as modifications or alternatives that fall within the spirit or scope of the present disclosure.

[0066] The present disclosure may discuss potential advantages that may be generated by the disclosed embodiments. Not all implementations of these embodiments will necessarily exhibit any or all potential advantages. Whether an advantage is achieved for a particular implementation depends on many factors, some of which are outside the scope of the present disclosure. In fact, there are multiple reasons why an implementation that falls within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular implementation may include other circuits outside the scope of the present disclosure, which, in combination with one of the disclosed embodiments, negate or reduce one or more of the disclosed advantages. In addition, suboptimal design execution of a particular implementation (e.g., implementation techniques or tools) may also negate or reduce the disclosed advantages. Even assuming a skilled implementation, the realization of the advantages may still depend on other factors, such as the environmental conditions in which the implementation is deployed. For example, the input provided to a particular implementation may prevent one or more problems solved in the present disclosure from occurring on a particular occasion, with the result that the benefits of its solution cannot be realized. In view of the existence of possible factors outside the present disclosure, it is explicitly intended that any potential advantages described herein should not be interpreted as claim limitations that must be met to prove infringement. Instead, the confirmation of these potential advantages is intended to illustrate the type of (one or more) improvements that are available to designers who benefit from the present disclosure. The permissive description of advantages (eg, stating that a particular advantage "may occur") is not intended to cast doubt on whether such advantages can actually be achieved, but rather to recognize that achievement of such advantages often depends on technical realities of additional factors.

[0067] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of claims drafted based on the present disclosure, even if only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be illustrative and not restrictive, and there is no statement to the contrary in the present disclosure. Thus, the present application is intended to allow claims covering the disclosed embodiments, as well as such substitutions, modifications, and equivalents that are apparent to those skilled in the art having the benefit of the present disclosure.

[0068] For example, features in this application may be combined in any suitable manner. Thus, during the examination of this application (or an application claiming priority thereto), new claims may be formulated to any such combination of features. In particular, with reference to the appended claims, features of dependent claims may be combined with features of other dependent claims, including claims that are dependent on other independent claims, where appropriate. Similarly, features from individual independent claims may be combined where appropriate.

[0069] Thus, while the appended dependent claims may be drafted such that each dependent claim is dependent on a single other claim, additional dependencies are also contemplated. Any combination of features in the dependent claims consistent with the present disclosure is contemplated and may be claimed in this or another application. In short, the combinations are not limited to those specifically listed in the appended claims.

[0070] It is also contemplated that claims drafted in one format or legal type (eg, apparatus) are intended to support corresponding claims in another format or legal type (eg, method), where appropriate.

[0071] Because this disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. It is hereby notified that the definitions provided in the following paragraphs as well as throughout this disclosure will be used to determine how to interpret claims drafted based on this disclosure.

[0072] Unless the context clearly indicates otherwise, reference to an item in the singular (i.e., a noun or noun phrase beginning with "a," "an," or "the") is intended to mean "one or more." Thus, reference to "an item" in a claim does not exclude additional instances of that item in the absence of accompanying context. A "plurality" item refers to a collection of two or more items.

[0073] The word "may" is used herein in a permissive sense (ie, having the potential to, being able to), rather than in the mandatory sense (ie, must).

[0074] The terms "including" and "comprising" and forms thereof are open ended and mean "including, but not limited to."

[0075] When the term "or" is used in this disclosure with respect to a list of options, it will generally be understood to be used in an inclusive sense unless the context provides otherwise. Thus, a recitation of "x or y" is equivalent to "x or y, or both," thereby covering 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, a phrase such as "either x or y, but not both" makes it clear that "or" is used in an exclusive sense.

[0076] The recitation of "w, x, y, or z, or any combination thereof" or "at least one of . . . w, x, y, and z" is intended to cover all possibilities involving a single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element of the set (e.g., w but no x, y, or z), any two elements (e.g., w and x but no y or z), any three elements (e.g., w, x, and y but no z), and all four elements. Thus, the phrase "at least one of . . . w, x, y, and z" refers to at least one element in the set [w, x, y, z], thereby covering all possible combinations in the list of elements. The phrase should not be interpreted as requiring the presence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0077] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context provides otherwise, different labels for a feature (e.g., "first circuit," "second circuit," "particular circuit," "given circuit," etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the labels "first," "second," and "third" do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0078] The phrase "based on" is used to describe one or more factors that influence a determination. This term does not exclude the possibility that additional factors may influence a determination. That is, a determination may be based only on specified factors, or on specified factors and other unspecified factors. Consider the phrase "A is determined based on B." This phrase states that B is a factor used to determine A or influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor, such as C. The phrase is also intended to cover embodiments in which A is determined based only on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0079] The phrases "in response to" and "in response to..." describe one or more factors that trigger an effect. The phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect in conjunction with or independently of the specified factors. That is, the effect may be responsive only to these factors, or may be responsive to the specified factors as well as other unspecified factors. Consider the phrase "in response to B, A is executed." The phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. The phrase does not exclude that the execution of A may also be responsive to some other factor, such as C. The phrase also does not exclude that the execution of A may be jointly responsive to B and C. The phrase is also intended to cover embodiments in which A is executed only in response to B. As used herein, the phrase "in response to" is synonymous with the phrase "at least partially responsive to." Similarly, the phrase "in response to..." is synonymous with the phrase "at least partially responsive to."

[0080] Within the present disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured" to perform one or more tasks or operations. This expression—"[the entity] is configured to [perform one or more tasks]"—is used herein to refer to a structure (i.e., something physical). More specifically, this expression is used to indicate that the structure is arranged to perform one or more tasks during operation. A structure may be said to be "configured to" perform a task even if the structure is not currently being operated. Thus, an entity described or stated as "configured to" perform a task refers to something physical, such as a device, a circuit, a memory having a processor unit and storing program instructions executable to implement the task, etc. The phrase is not used herein to refer to something intangible.

[0081] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured to" perform these tasks / operations, even if not specifically stated.

[0082] The term "configured to" is not intended to mean "configurable to". For example, an unprogrammed FPGA would not be considered to be "configured to" perform a particular function. However, the unprogrammed FPGA may be "configurable to" perform that function. After appropriate programming, the FPGA may then be said to be "configured to" perform a particular function.

[0083] For purposes of a U.S. patent application based on the present disclosure, reciting in a claim that a structure is “configured to” perform one or more tasks is expressly not intended to invoke 35 U.S.C. § 112(f) for that claim element. If the applicant wishes to invoke § 112(f) during prosecution of a U.S. patent application based on the present disclosure, it would use the “means for [performing the function]” construction to recite the claim element.

Claims

1. A method for implementing cross-region communication for computing regions executing different encoding protocols, comprising: Receiving, by a server computer system, a request for a service executed by a second application instance in a second computing region in accordance with a second, different set of coding protocols, via a proxy layer of a first application instance executing in a first computing region in accordance with a first set of coding protocols; modifying, by the server computer system, via a remote layer of the first application instance, a set of data specified in the request to conform to the second different set of encoding protocols; as well as A modified set of data specified in the request for the service is transmitted, by the server computer system, to the remote tier of the second application instance via the remote tier of the first application instance.

2. The method according to claim 1, wherein: The receiving, modifying, and transmitting are performed using a single code repository, and wherein the single code repository can be used to develop and execute program code across multiple application instances on multiple different computing regions.

3. The method according to claim 1, wherein: The proxy layer of the first application instance is visible to one or more developers using the first application instance and provides annotations and a user interface for the one or more developers interacting with the first application instance, and wherein the remote layer of the first application instance is invisible to the one or more developers and abstracts underlying differences between protocols of different computing areas.

4. The method according to claim 3, wherein: The remote layer of the first application instance and the second application instance is a remote procedure call (RPC) layer, and wherein annotations and a user interface provided by the proxy layer allow a developer to indicate one or more services to execute in different computing regions.

5. The method according to claim 1, wherein: The first computing area is an online production area, and the second computing area is an offline batch processing computing area.

6. The method according to claim 1, further comprising: Prior to transmitting the set of data specified in the request for the service executed via the second application instance, communicating, by the server computer system, via the remote layer of the first application instance with the service executed within the first computing region, wherein the communicating comprises: Data received in a request for a service executed via the second application instance is modified by the remote layer of the first application instance.

7. The method according to claim 6, wherein: The altering includes converting a first type of communication protocol implemented by the first computing region to a second type of communication protocol implemented by the second computing region.

8. The method according to claim 7, wherein: The first type of communication protocol implemented by the first computing region is a client-to-server request-response communication protocol, and the second type of communication protocol implemented by the second computing region is an asynchronous process-to-process communication protocol.

9. The method according to claim 1, wherein: The transmission between the remote tier of the first application instance executing in the first computing region and the remote tier of the second application instance executing in the second computing region is performed via an intermediate data stream processor that transmits data in real time between the two computing regions.

10. A non-transitory computer readable medium having instructions stored thereon, the instructions being executable by a server computer system to perform operations comprising: A request for a service is received via a proxy layer of a first application instance executing in a first computing region according to a first set of coding protocols, the service being executed via a second application instance in a second computing region according to a second, different set of coding protocols, wherein The first application instance and the second application instance are implemented via a single code repository; modifying, by the server computer system, via a remote layer of the first application instance, a set of data specified in the request to conform to the second different set of encoding protocols; as well as A modified set of data specified in the request for the service is transmitted, by the server computer system, to the remote tier of the second application instance via the remote tier of the first application instance.

11. The non-transitory computer readable medium of claim 10, wherein: The receiving, modifying, and transmitting are performed using a single code repository, and wherein the single code repository can be used to develop and execute program code across multiple application instances on multiple different computing regions.

12. The non-transitory computer readable medium of claim 10, wherein: The remote layer of the first application instance and the second application instance is a remote procedure call (RPC) layer, and wherein annotations and a user interface provided by the proxy layer allow a developer to indicate one or more services to execute in different computing regions.

13. The non-transitory computer readable medium of claim 10, wherein: The operations also include: Prior to transmitting the set of data specified in the request for the service executed via the second application instance, communicating, by the server computer system, via the remote layer of the first application instance with the service executed within the first computing region, wherein the communicating comprises: The remote layer of the first application instance modifies data received in a request for a service executed via the second application instance, wherein the modification includes converting a first type of communication protocol implemented by the first computing area to a second type of communication protocol implemented by the second computing area.

14. The non-transitory computer readable medium of claim 10, wherein: The first set of encoding protocols includes authentication protocols that prompt for developer credentials, and wherein the second, different set of encoding protocols includes load balancing protocols.

15. The non-transitory computer readable medium of claim 10, wherein: The first computing region is a first cloud computing region, and the second computing region is a different second cloud computing region.

16. A system comprising: at least one processor; and A memory having instructions stored thereon, wherein the instructions can be executed by the at least one processor to cause the system to perform the following operations: Receiving, via a first layer of a first application instance executing in a first computing region according to a first set of coding protocols, a request for a service executed via a second application instance in a second computing region according to a second, different set of coding protocols; modifying, via a second layer of the first application instance, a set of data specified in the request to conform to the different second set of encoding protocols; as well as A modified set of data specified in the request for the service is transmitted to the second layer of the second application instance via the second layer of the first application instance.

17. The system of claim 16, wherein: The first application instance and the second application instance are implemented via a single code repository across the first computing region and the second computing region.

18. The system of claim 16, wherein: The first layer of the first application instance is a proxy layer, which is visible to one or more developers using the first application instance and provides annotations and a user interface for the one or more developers interacting with the first application instance; wherein the second layer of the first application instance is a remote layer, which is invisible to the one or more developers and abstracts the underlying differences between protocols of different computing areas, wherein the second layers of the first application instance and the second application instance are remote procedure call (RPC) layers, and wherein the annotations and user interface provided by the proxy layer allow developers to indicate one or more services executed in different computing areas.

19. The system of claim 16, wherein: The instructions are also executable by the at least one processor to cause the system to perform the following operations: Prior to transmitting the set of data specified in the request for the service executed via the second application instance, communicating with the service executed within the first computing region via the second layer of the first application instance, wherein the communicating comprises: A second layer of the first application instance modifies data received in a request for a service executed via the second application instance, wherein the modification includes converting a first type of communication protocol implemented by the first computing area to a second type of communication protocol implemented by the second computing area.

20. The system of claim 16, wherein: The first computing area is a cloud computing area, and the second computing area is an offline testing area.

Images