Sharding of Workflow Applications in Serverless Architecture

Abstract

Systems and methods provide a multi-version sharding plan to improve horizontal scaling and load balancing of distributed shards while avoiding downtime due to data migration. Based on a serverless architecture, application hosting service providers can provide customers with distributed computing resources divided into shards, which can be dynamically allocated, scaled, and load balanced for use in workflow applications that are independent of the architecture. The versioned sharding plan can be implemented in a database, storing key-value intervals that enable workflow application executions to be uniquely mapped to specific shards. The database controller can uniformly allocate a shard for each execution of the workflow application and publish a new version of the sharding plan that can be accessed by the front-end and back-end of the customer's hosted application. Through these solutions, data migration between shards is avoided during the horizontal scaling of computing resources allocated to the workflow application without causing downtime.

Description

Background Art

[0001] Application hosting services typically provide customers with distributed computing resources for deploying customer applications and customer services. Typically, customers of application hosting services may be granted access to some physical machines or, most commonly, virtual server hosts in a back-end data center. Under such a service model, customers who already have server hosts and want to develop and deploy applications need to write computer executable source code based on the underlying system architecture. Customers also need to configure the underlying server hosts to load balance and scale the computing workload requirements that come from deployed user applications and user services. Examples of this underlying system architecture include service-oriented architecture ("SOA") and microservice architecture.

[0002] Serverless architecture has recently emerged as an alternative to traditional application hosting systems. In a serverless architecture, the underlying server hosts and other aspects of the system architecture are managed by the service provider, not the customer. Customers can write architecture-independent source code that can be compiled to generate target code that can be executed on any serverless architecture. Configuration tasks such as load balancing and scaling can be provided by the service provider on the backend, eliminating the need for customer configuration.

[0003] Another application scenario for managed service architectures is database sharding. Server hosts in backend data centers can logically partition the database into multiple shards, allowing customer data subsets and workloads to be distributed and load-balanced across the different shards. This distribution of data and workload avoids computing bottlenecks. In scenarios where customers don't manually configure database sharding, as is the case in SOA and microservices architectures, technologies are needed to isolate the database sharding and load balancing process from the customer to improve service quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The detailed description is set forth with reference to the accompanying drawings. In the figures, the leftmost digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numeral in different figures indicates similar or identical items or features.

[0005] Figure 1 An architectural diagram of an example application hosting service according to an example implementation of the present disclosure is illustrated.

[0006] Figure 2 Diagram illustrating the traditional sharding process that results in downtime.

[0007] Figure 3 A logical diagram illustrating the architecture of a sharding plan according to an example embodiment of the present disclosure is illustrated.

[0008] Figure 4 A key-value space according to an example embodiment of the present disclosure is illustrated.

[0009] Figure 5 A swim lane diagram showing steps of a sharding process according to an example embodiment of the present disclosure is illustrated.

[0010] Figure 6 An architectural diagram illustrating communication between a front-end and a back-end according to an example embodiment of the present disclosure is illustrated.

[0011] Figure 7 The system architecture of a physical or virtual computing system according to an example embodiment of the present disclosure is illustrated.

[0012] Figure 8 An example computing system for implementing the above-described processes and methods for implementing sharding is illustrated.

[0013] Figure 9 An example computing system for implementing the above-described processes and methods for implementing sharding is illustrated. DETAILED DESCRIPTION

[0014] The systems and methods discussed herein relate to implementing sharding in distributed computing, and more particularly, to implementing a multi-version sharding plan to improve horizontal scaling and load balancing among distributed shards while avoiding downtime due to data migration.

[0015] Figure 1 An architectural diagram of an example application hosting service 100 is shown, according to an example embodiment of the present disclosure.

[0016] Customers of the application hosting service 100 can host one or more hosted applications 102, which are accessible via one or more computer networks. Hosted applications 102 include a front-end 104 and a back-end 106. The front-end 104 can include static web content (e.g., encoded using any suitable markup language) or dynamic web content (e.g., encoded using any suitable scripting language) for end users, hosted on any server connected to the one or more networks. The front-end 104 can include any number of website (web) hosts 108. The website hosts 108 can be one or more physical or virtual servers configured to host static or dynamic website content. The front-end 104 can invoke one or more functions of the hosted applications 102 in providing one or more services to end users. End users can access the hosted applications 102 by operating one or more terminal devices 110 to communicate with one or more website hosts 108.

[0017] The backend 106 may include an application programming interface ("API"), a database, a file system, a computing logic module, a service, a setting, etc., which may be configured to provide functions such as function calls and definitions, computing, searching, retrieving, data collection, indexing, authentication, security, etc., as services provided to end users accessing the hosted application 102. According to an example embodiment of the present disclosure, the backend 106 may also provide functions such as load balancing, sharding, scaling, etc., which will be further described below.

[0018] The backend 106 may be hosted in a data center 112, where computing resources such as physical and / or virtual processors, memory, storage devices, computer-executable applications, computer-readable data, etc. are interconnected via one or more networks. The data center 112 may receive inbound traffic from external hosts originating from external networks, such as personal area networks (“PANs”), wired and wireless local area networks (“LANs”), wired and wireless wide area networks (“WANs”), the Internet, etc., through connection points such as gateways and firewalls. The inbound traffic may be in the form of packets formatted and encapsulated according to any combination of various interoperable network communication protocols, such as the Internet Protocol (“IP”) and the Transmission Control Protocol (“TCP”); virtualized network communication protocols such as Virtual Extensible LAN (“VxLAN”); routing protocols such as Multiprotocol Label Switching (“MPLS”); and the like.

[0019] The data center 112 may include any number of data center hosts 114, which may be physical or virtual workload execution entities (hereinafter referred to as "workers") that provide computing resources for a hosted service, such as the backend 106. These computing resources may include, for example: physical computing systems, such as physical servers, computers, mobile devices, etc.; virtual computing systems, such as virtual servers, virtual machines, etc.; or environments suitable for running computer executable code, such as platforms, services, application containers, environments, functions, etc.

[0020] According to an exemplary embodiment of the present disclosure, a serverless architecture can be implemented when computing resources of a data center 112 are provisioned for a hosted application 102. By implementing a serverless architecture, a customer can define the computing logic module of the hosted application 102 by defining the business logic of one or more services accessed by end users accessing the hosted application 102. Those skilled in the art may generally understand business logic as high-level rules that define the input, collection, modification, storage, indexing, etc. of business objects and data associated therewith during the execution of a business process. For example, the service provided to end users accessing the hosted application 102 may be the sale of one or more goods and / or services, and the business objects involved in the process may include the purchase of goods and / or services by end users and data associated therewith; inventory items and data associated therewith; warehouses and data associated therewith; suppliers and data associated therewith; shippers and data associated therewith; payment processors and data associated therewith; merchants and data associated therewith; banks and data associated therewith; and the like.

[0021] According to an example embodiment of the present disclosure, business logic can be defined as a workflow application, which can be composed of human-readable descriptions written using the syntax of one or more markup languages, such as YAML. The workflow application can define a series of tasks that operate on data, such as data defining business objects and data associated with the business objects. Although the workflow application itself is not computer-executable, the workflow application can be read by computer-executable applications, such as transmitters and parsers known to those skilled in the art. The transmitter and parser can interpret the tasks defined in the workflow application as computer-executable instructions that are operable to configure one or more physical and / or virtual processors of the hosted computing resources to perform operations, such as obtaining input from one or more terminal devices, recording data in one or more databases of the backend 106, querying one or more databases of the backend 106, modifying one or more entries in one or more databases of the backend 106, performing operations based on one or more entries in one or more databases of the backend 106, and so on.

[0022] According to example embodiments of the present disclosure, "execution" may generally refer to at least one set of computer-executable instructions that are operable to configure one or more physical and / or virtual processors of a hosted computing resource to perform operations capable of carrying out the tasks of a workflow application from beginning to end. Various workflow engines known to those skilled in the art may implement such execution as one or more computer-executable instructions, at least some of which may be executed simultaneously, and at least some of which may be executed independently of each other, and may further include one or more computer-executable instructions in wrappers, modules, scripts, etc., which may further configure how the processor executes the computer-executable instructions.

[0023] According to example embodiments of the present disclosure, the backend 106, as well as the data center hosts 114 and their computing resources, including workers, can be logically organized into one or more shards 116. A database can be logically organized into one or more logical database shards, where each database contains a subset of the data entries contained in the database (although not all data can be organized in this manner; some data may be relevant to each logical database shard, and therefore a copy of it may exist in each logical database shard). The data center hosts 114 and computing resources can also be organized into one or more physical or logical computing shards, where each computing shard can constitute a physically or logically autonomous computing system that can perform operations independently of other computing shards. Therefore, according to example embodiments of the present disclosure, each shard 116 can include a physical or logical computing shard on which a logical database shard is stored; the backend 106, except for the database, can be common to each shard 116.

[0024] According to example embodiments of the present disclosure, the maximum number of shards may be arbitrarily defined as long as the number is greater than one.

[0025] According to an example embodiment of the present disclosure, the computing shards of each shard 116 can be configured, for example, by a computing logic module of the backend 106, to compute one or more tasks of a computing workflow application, which tasks read and write data of corresponding logical data shards of the shard 116. Since there are multiple computing tasks reading and writing the same data, each computing shard can be configured to maintain consistency of data read and written between different tasks of the same workflow application.

[0026] For example, each computing slice can be configured to execute each task of the same workflow application on the same computing slice. In other words, once the first task of a workflow application is executed on a specific computing slice, all other subsequent tasks of the workflow application will also be executed on the same computing slice.

[0027] In addition, after a computing shard begins executing a task of a workflow application, a symbol can be assigned to the execution, through which a call to an API of the backend 106 (e.g., called by the frontend 104) can issue a request related to the ongoing execution to retrieve information about the ongoing execution, such as its parameters. Thus, each computing shard can be configured to route requests for the same execution to the computing shard that is executing the execution.

[0028] Furthermore, ownership of shards 116 is dynamically assigned to specific customers so that the compute shards of shards 116 execute only the tasks of workflow applications created by that customer. Ownership can be dynamically assigned to provide horizontal scaling of computing resources based on the overall workload of a particular customer's workflow applications and network data traffic at data center 112. For example, any particular customer may initially have a first shard assigned to it, and tasks in all workflow applications created by that customer may be executed by the compute shards of the first shard; when network data traffic at data center 112 due to the execution of tasks of the customer's workflow applications exceeds a certain set threshold, additional shards may be assigned to that customer.

[0029] However, during the sharding process of assigning a second shard to a particular customer's workflow application, after the second shard is assigned, some tasks currently being executed by the first shard should be reallocated to the second shard for execution, so that the first shard does not fully consume its computing resources and become a computing bottleneck in the service provided by hosted application 102. Conventionally, tasks can be reallocated to the second shard for execution by pausing execution at the first shard, saving the data state and the execution state of the first shard in a storage device, and then loading the data state and the execution state of the first shard to resume execution at the second shard. As a result of this sharding process, both shards may become unavailable for task computation, resulting in downtime that may last for seconds or minutes, depending on the network data traffic at data center 112.

[0030] Figure 2 The conventional sharding process that causes downtime described above is illustrated. A sharding process 200 is shown, wherein, in an update start step 202, the database begins reallocating tasks from the first shard to the second shard; in a delete step 204, the database deletes tasks assigned to the first shard, causing downtime 206 for the shard while it waits for deletion; in a write step 208, the database writes tasks assigned to the second shard, causing downtime 210 for the shard while it waits for writes; and in a realloc step 212, the database updates the assignment of the customer's second shard to the first shard, causing downtime 214 for the shard while it waits for updates. Three downtimes can occur.

[0031] Therefore, example embodiments of the present disclosure provide a sharding plan that can avoid causing downtime as described above.

[0032] Figure 3 A logical diagram illustrating the architecture of a sharding plan 300 according to an example embodiment of the present disclosure is shown.

[0033] The sharding plan 300 according to an example embodiment of the present disclosure can be implemented by a database 302. The database 302 can be a relational database, a non-relational database, or any database with a generally suitable schema that is used to store a certain number of data records. In addition, the database 302 can be a versioned database, in which a snapshot of the state of the database 302 at a particular time can be recorded and persistently stored, so that the snapshot is immutable and independent of the current state of the database 302. Any number of snapshots can be stored in this manner, and each snapshot can be referred to as a version of the sharding plan 300. As shown, three versions 304A, 304B, and 304C are stored (where any unspecified version can be referred to as version 304). The versions can be numbered incrementally according to any suitable numbering scheme.

[0034] The sharding plan 300 can be stored on a host (not shown) that is central to the web hosts 108 and the data centers 122, such that both the web hosts 108 and the data centers 122 can access the sharding plan 300. By centrally hosting the sharding plan 300, both the web hosts 108 and the data centers 122 can access a consistent copy of the sharding plan 300, eliminating the need to synchronize multiple copies of the sharding plan 300 to maintain consistency.

[0035] In the sharding plan 300, each record 306 of the database 302 may store information associated with a shard 116 of the data center 112 that has been assigned to a particular customer's hosted application. Thus, information associated with a shard may be stored in association with the corresponding shards that are assigned to different customers' hosted applications.

[0036] like Figure 3 As shown, each subsequent version of the sharding plan 300 has more records than the previous version. This indicates that, according to the sharding plan 300, the database 302 has been updated to increase the number of shards 116 allocated to a particular customer. However, a subsequent version of the sharding plan 300 may also have fewer records than a previous version; this indicates that, according to the sharding plan 300, the database 302 has been updated to decrease the number of shards 116 allocated to a particular customer. The process of scaling up and down shards will be described later.

[0037] Information associated with shard 116 may include a key interval. According to example embodiments of the present disclosure, a unique key may be generated for assignment to shard 116. For example, a unique key may be generated using a hash algorithm known to those skilled in the art. Examples of such algorithms include the so-called DJB2 algorithm, the Fowler-Noll-Vo hash function (e.g., which may be implemented as a variant of "FNV-1" or "FNV-1a"), and the so-called DBM hash algorithm (e.g., including variants of the SDBM hash algorithm). A sequentially generated key interval may be assigned to shard 116, the interval comprising a plurality of key values. According to example embodiments of the present disclosure, any number of unique key values ​​may be generated for this purpose; for example, all possible unique key values ​​within a maximum key space (which may be defined by a plurality of bits) may be generated. If a collision occurs in the generated key value, resulting in a non-unique key value being generated, for example, because the hash algorithm known to those skilled in the art is not inherently collision-free, or because all possible key values ​​within the maximum key space are generated, an additional string of any length may be appended to the end of the non-unique key value to ensure its uniqueness. Adding a string to a key value increases the bit length of the key value, thereby expanding the maximum key value space.

[0038] Figure 4 A key value space 400 according to an example embodiment of the present disclosure is shown. The key value space applied to the present disclosure can be the entire space containing all possible unique key values, which are generated by a hash algorithm. The example embodiments of the present disclosure do not limit the data structure that can store the key values ​​of the key value space 400. Such a data structure can be, for example, a hash table, and the key value space 400 is shown herein as a hash ring. The hash ring can facilitate the expansion of the key value space 400 as described above without causing remapping of the hashes that generate existing key values.

[0039] Four key value intervals are shown in key value space 400; these four key value intervals can be assigned to four shards. A first key value interval runs from key value 402 (including key value 402) to key value 404 (excluding key value 404) and can be assigned to a first shard. A second key value interval runs from key value 404 (including key value 404) to key value 406 (excluding key value 406) and can be assigned to a second shard. A third key value interval runs from key value 406 (including key value 406) to key value 408 (excluding key value 408) and can be assigned to a third shard. A fourth key value interval runs from key value 408 (including key value 408) to key value 410 (excluding key value 410) and can be assigned to a fourth shard.

[0040] Figure 5A swim lane diagram illustrating steps of a sharding process 500 according to an example embodiment of the present disclosure is shown. The steps of the sharding process 500 may be performed between the front end 104, the back end 106, the database 302 (which may exist in as many consistent replicas as are required in the front end 104 and the back end 106 to coordinate the steps of the sharding process 500), and the version 304 of the sharding plan 300.

[0041] At step 502, the front end 104 assigns an execution identifier and an execution key to the execution of the workflow application in the database. The execution of the workflow application can be initialized by calling one or more functions of the hosting application 102 in the process of providing services to end users.

[0042] When initializing an execution, front-end 104 assigns a unique execution identifier (hereinafter referred to as "exec_id") to the execution. Execution identifiers may be generated sequentially. Alternatively, execution identifiers may be generated in intervals, not sequentially, across the key space described above. The manner in which execution identifiers are generated may determine the load balancing of workflow application executions in the data center, as will be described below.

[0043] In addition, when initializing an execution, the front end 104 generates an execution key and assigns the execution key to the execution indicated by the assigned execution identifier. The execution key can be generated in the same manner as the unique key assigned to the shard described above, for example, using the same algorithm in a deterministic manner so that the content used to generate each unique key assigned to the shard can be generated once as the execution key, but not more than once. For example, a hash algorithm can be used in a deterministic manner by passing a certain set of inputs to a hash function to generate a unique key for assigning to the shard, and then passing each input in the input set to the hash function at most once to generate the execution key. In this way, each execution key will match a unique key assigned to the shard.

[0044] At step 504 , the database controller durably records the execution identifier corresponding to the execution in the database 302 and publishes the version 304 of the sharding plan 300 .

[0045] The latest version of the sharding plan 300 may identify the version of the sharding plan 300 that was persistently recorded during the recording of the execution identifier. Thus, after recording the execution identifier, the latest version of the sharding plan 300 is published in an unchanged form; subsequent recordings of the execution identifier may publish subsequent latest versions without changing the currently recorded latest version.

[0046] The execution identifier and the latest version can be recorded in association as a mapping from the execution identifier to the latest version. Alternatively, the execution identifier and the latest version can be recorded in association as a record with the execution identifier as an index value and the latest version as the value of a field of the record. For example, Tables 1 and 2 illustrate portions of a database architecture according to an example embodiment of the present disclosure. It should be understood that although these tables are shown herein for illustrative purposes, Tables 1 and 2 can be sets of records corresponding to similar suitable database schemas according to any suitable database schema.

[0047] exec_id plan_version exec_key handling_shard exec_1 1 111 shard_1 exec_2 1 MMM shard_3 exec_3 1 SSS shard_3 exec_4 1 ZZZ shard_4

[0048] As shown in Table 1, the execution identification may be recorded as an index "exec_id" of each record associated with the latest version, and the latest version is recorded as the value of the "plan_version" field.

[0049] Additionally, the execution identifier may be recorded in association with information other than the latest version. As further shown in Table 1, as described above, the execution identifier may be recorded as an index of each record associated with an execution key value, which is recorded as the value of the "exec_key" field.

[0050] Furthermore, for any record, if the execution corresponding to the execution identifier indexed as the index value has completed, the record can be deleted. A master service (not shown) can be hosted centrally between the database controller and data center 122, and the master service is configured to communicate with data center 122 to track ongoing executions. When one or more executions are completed, the master service can communicate with the database controller to cause the database controller to delete one or more corresponding records.

[0051] At step 506, the database controller returns the published version of the sharding plan 300 to the front end 104. The front end 104 may receive the published version of the sharding plan 300 from the database controller.

[0052] At step 508 , the front end 104 determines the shard identifier assigned to the execution based on the published version of the shard plan 300 returned from the database controller.

[0053] shard_id plan_version account_id begin_token end_token shard_1 1 111 INF_MIN F shard_2 1 111 F M shard_3 1 111 M S shard_4 1 111 S INF_MIN

[0054] As shown in Table 2, the database 302 may already store information such as that shown in the sharding plan 300 described above. As described above, Table 2 shows records associated with the shards 116 (each of whose corresponding shard identifiers is recorded as the index "shard_id" of each record) and other information. This other information may include a version, which is recorded as the value of the "plan_version" field; a customer identifier, which is recorded as the value of the "account_id" field (here, all records shown are related to the shards assigned to the same customer with the customer identifier "111"; as described above, in the earliest version of the sharding plan 300 that records the customer's customer identifier, each customer may be assigned only one shard, and subsequent versions may enable the assignment of more shards to the customer); and a key value interval, which is recorded as the value of the "begin_token" field and the value of the "end_token" field (these two fields define the beginning and end of the key value interval, respectively).

[0055] By searching the set of records shown in Table 2 for the execution key value, the front end 104 can determine the shard identifier of the shard 116 corresponding to the key value interval in which the execution key value falls. From this query, the front end 104 can return the shard identifier and record it as the value of the "handling_shard" field, in association with the corresponding execution identifier. In this way, by persistently recording this information in the latest version of the sharding plan 300, the shard 116 can be unchangingly assigned to the execution corresponding to the execution key value. After the value of the "handling_shard" field is recorded, the front end 104 can perform other searches without further writing the value of the "handling_shard" field.

[0056] Since each key interval has a predetermined lower and upper limit, when an execution key within a first key interval is generated and an assigned shard is received, subsequent execution keys can no longer be generated within the first key interval, but must be generated within other key intervals. Therefore, the first key interval being consumed can indicate that the shard assigned to the key interval is full and no additional workflow applications should be assigned to it. Therefore, the size of the key interval can be determined based on the computing power of each shard in the data center; for example, the size of the key interval can be determined so that the shard will be at maximum computing power before no workflow applications are assigned to it, or so that the shard can have some remaining computing power before no workflow applications are assigned to it to avoid bottlenecks.

[0057] Furthermore, the way execution keys are generated can influence the load balancing of workflow applications across shards within a data center. For example, if execution keys are generated sequentially, the computing power of the first shard can be fully loaded before the second shard begins to receive workload. If execution keys are generated at regular intervals, each shard may receive a roughly equal workload in a round-robin fashion.

[0058] According to example embodiments of the present disclosure, the shards 116 allocated for execution may be immutable for reasons described below.

[0059] At step 510 , the front end 104 forwards execution to the assigned shard 116 at the back end 106 .

[0060] The front end 104 may call the API of the back end 106 with the execution ID and the shard ID as parameters. Subsequently, as described above, the execution of the tasks of the workflow application may be performed by the back end 106 (eg, by the emitter and the parser).

[0061] Subsequently, as described above, the front end 104 may initiate a request for execution. The request may be initiated at any time during the operation of the front end 104 by calling one or more functions of the hosted application 102 in the course of providing services to the end user.

[0062] Thereafter, similarly to the above-described step 502 and steps 506 to 510 , the following steps 512 to 518 are performed.

[0063] At step 512 , the front end 104 receives a request for execution of the workflow application. The front end 104 may query the database 302 for the version 304 of the sharding plan 300 without further recording information in the database 302 .

[0064] At step 514 , the database controller returns the published version 304 of the sharding plan 300 to the front end 104 .

[0065] At step 516 , the front end 104 determines the shard identifier assigned to the execution based on the version 304 of the shard plan 300 returned from the database controller.

[0066] At step 518 , the front end 104 forwards the request to the assigned shard 116 at the back end 106 .

[0067] According to the sharding process 500 described above, since each shard is assigned to execution unchanged, workflow applications will not be reassigned from one shard to another. Consequently, downtime caused by the sharding process is minimal, and shards may remain available for incoming workflow applications and requests when they have spare computing capacity. Furthermore, once the database controller releases a new version of the sharding plan, both the frontend and backend can quickly access the new version of the sharding plan and modify the assignments of incoming workflow applications and requests as reflected in the new version of the sharding plan, ensuring that shards do not continue to receive workloads that exceed their computing capacity.

[0068] Figure 6 An architectural diagram illustrating communication between a front-end and a back-end according to an exemplary embodiment of the present disclosure is shown. Both the front-end 104 and the back-end 106 communicate with a database host 602, which can be controlled by a database controller 604 to record persistent entries in a database and publish an immutable version of the database. As shown, the front-end 104 can receive requests.

[0069] The front end 104 further communicates with physical or virtual workers 606 at the data center 112 that provide computing resources to the back end 106. The computing resources of the workers 606 can be organized into partitions 608, which can be further organized into shards 116.

[0070] Figure 7 A system architecture of a physical or virtual computing system 700 is shown according to an example embodiment of the present disclosure.

[0071] A physical or virtual computing system 700 according to an example embodiment of the present disclosure may include one or more general-purpose processors 702 and may also include one or more special-purpose processors 704. The general-purpose processor 702 and the special-purpose processor 704 may be physical, or may be virtualized and / or distributed. The general-purpose processor 702 and the special-purpose processor 704 may execute one or more instructions stored on a computer-readable storage medium as described below to cause the general-purpose processor 702 or the special-purpose processor 704 to perform tasks of a workflow application. The special-purpose processor 704 may be a computing device having hardware or software elements that facilitate the execution of specific data-related tasks. For example, the special-purpose processor 704 may be an accelerator, such as a neural network processing unit ("NPU"), an implementation using a field programmable gate array ("FPGA") and an application-specific integrated circuit ("ASIC"), and the like.

[0072] The physical or virtual computing system 700 may also include a system memory 706 communicatively coupled to the general-purpose processor 702 and the special-purpose processor 704 via a system bus 708. The system memory 706 may be physical or may be virtualized and / or distributed. Depending on the exact configuration and type of the system 700, the system memory 706 may be volatile, such as RAM, non-volatile, such as ROM, flash memory, a micro hard drive, a memory card, etc., or a combination thereof.

[0073] The system bus 708 can transfer data between the general-purpose processor 702 and the system memory 706, between the special-purpose processor 704 and the system memory 706, and between the general-purpose processor 702 and the special-purpose processor 704. In addition, a data bus 710 can transfer data between the general-purpose processor 702 and the special-purpose processor 704. The data bus 710 can be, for example, a Peripheral Component Interconnect Express ("PCIe") connection or the like.

[0074] Figure 8 An example computing system 800 is shown for implementing the above-described processes and methods for implementing sharding.

[0075] The techniques and mechanisms described herein can be implemented by multiple instances of computing system 800, as well as any other computing devices, systems, and / or environments. Computing system 800 can be any kind of computing device, such as a personal computer, a personal tablet, a mobile device, or other such computing device operable to perform matrix arithmetic calculations. Figure 8 The computing system 800 shown in the figure is only one example of a system and is not intended to imply any limitation on the scope of use or functionality of any computing device used to perform the above-mentioned processing and / or process. Other well-known computing devices, systems, environments and / or configurations that may be suitable for the embodiments include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, game consoles, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, implementations using field programmable gate arrays ("FPGAs") and application-specific integrated circuits ("ASICs"), and the like.

[0076] The system 800 may include one or more processors 802 and a system memory 804 communicatively coupled to the processors 802. The processors 802 and the system memory 804 may be physical or may be virtualized and / or distributed. The processors 802 may execute one or more modules and / or processes to enable the processors 802 to perform various functions. In embodiments, the processors 802 may include a central processing unit ("CPU"), a graphics processing unit ("GPU"), an NPU, any combination thereof, or other processing units or components known in the art. In addition, each processor 802 may have its own local memory, which may also store program modules, program data, and / or one or more operating systems.

[0077] System memory 804 may be volatile, such as RAM, non-volatile, such as ROM, flash memory, a micro hard drive, a memory card, or a combination thereof, depending on the exact configuration and type of computing system 800. System memory 804 may include one or more computer-executable modules 806 that are executable by processor 802.

[0078] Module 806 may include, but is not limited to, an allocation module 808 , a key value generation module 810 , a sharding plan version receiving module 812 , a sharding determination module 814 , and an execution forwarding module 816 .

[0079] The assignment module 808 may be configured to assign an execution identifier and an execution key to an execution of a workflow application in the database, as described above with reference to Figure 5 As stated.

[0080] The key value generation module 810 can be configured to generate an execution key value, as described above with reference to Figure 5 As stated.

[0081] The sharding plan version receiving module 812 may be configured to receive a published version of the sharding plan from the database, as described above with reference to Figure 5 As stated.

[0082] The shard determination module 814 may be configured to determine the shard identifier assigned to the execution based on the version of the shard plan, as described above with reference to Figure 5 As stated.

[0083] The execution forwarding module 816 may be configured to forward execution to the assigned shards at the backend, as described above with reference to Figure 5 As stated.

[0084] The system 800 may further include an input / output ("I / O") interface 840 and a communication module 850 to allow the system 800 to communicate with other systems and devices (e.g., the database host and data center described above) over a network. The network may include the Internet, wired media such as a wired network or a direct wired connection, and wireless media such as acoustic, radio frequency ("RF"), infrared, and other wireless media.

[0085] Figure 9 An example computing system 900 is shown for implementing the above-described processes and methods for implementing sharding.

[0086] The techniques and mechanisms described herein can be implemented by multiple instances of computing system 900, as well as any other computing devices, systems, and / or environments. Computing system 900 can be any kind of computing device, such as a personal computer, a personal tablet, a mobile device, or other such computing device operable to perform matrix arithmetic calculations. Figure 9 The computing system 900 shown is only one example of a system and is not intended to imply any limitation on the scope of use or functionality of any computing device used to perform the above-described processes and / or procedures. Other well-known computing devices, systems, environments, and / or configurations that may be suitable for use with the embodiments include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, game consoles, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, implementations using field programmable gate arrays ("FPGAs") and application-specific integrated circuits ("ASICs"), and the like.

[0087] The system 900 may include one or more processors 902 and a system memory 904 communicatively coupled to the processor 902. The processor 902 and the system memory 904 may be physical or may be virtualized and / or distributed. The processor 902 may execute one or more modules and / or processes to enable the processor 902 to perform various functions. In an embodiment, the processor 902 may include a central processing unit ("CPU"), a graphics processing unit ("GPU"), an NPU, any combination of the above, or other processing units or components known in the art. In addition, each processor 902 may have its own local memory, which may also store program modules, program data, and / or one or more operating systems.

[0088] System memory 904 may be volatile, such as RAM, non-volatile, such as ROM, flash memory, a micro hard drive, a memory card, or a combination thereof, depending on the exact configuration and type of computing system 900. System memory 904 may include one or more computer-executable modules 906 that are executable by processor 902.

[0089] Module 906 may include, but is not limited to, a version publishing module 908 and a version returning module 910 .

[0090] The version publishing module 908 can be configured to permanently record the execution identifier corresponding to the execution in the database and publish the version of the sharding plan, as described above with reference to Figure 1 As stated.

[0091] The version return module 910 can be configured to return the published version of the sharding plan to the front end, as described above with reference to Figure 5 described.

[0092] The system 900 may further include an input / output ("I / O") interface 940 and a communication module 950 to allow the system 900 to communicate with other systems and devices (e.g., the aforementioned website hosts and data centers) over a network. The network may include the Internet, wired media such as a wired network or a direct wired connection, and wireless media such as acoustic, radio frequency ("RF"), infrared, and other wireless media.

[0093] Some or all of the operations of the above methods may be performed by executing computer-readable instructions stored on a computer-readable storage medium, as defined below. As used in the specification and claims, the term "computer-readable instructions" includes routines, applications, application modules, program modules, programs, components, data structures, algorithms, and the like. Computer-readable instructions may be implemented on a variety of system configurations, including single-processor or multi-processor systems, minicomputers, mainframe computers, personal computers, handheld computing devices, microprocessor-based programmable consumer electronics, combinations thereof, and the like.

[0094] Computer-readable storage media may include volatile memory (e.g., random access memory ("RAM")) and / or non-volatile memory (e.g., read-only memory ("ROM"), flash memory, etc.). Computer-readable storage media may also include additional removable and / or non-removable storage, including but not limited to flash memory, magnetic storage devices, optical storage devices, and / or tape storage devices, which may provide non-volatile storage of computer-readable instructions, data structures, program modules, etc.

[0095] Non-transitory computer-readable storage media are examples of computer-readable media. Computer-readable media include at least two types of computer-readable media, namely computer-readable storage media and communication media. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented by any process or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer-readable storage media include, but are not limited to, phase change memory ("PRAM"), static random access memory ("SRAM"), dynamic random access memory ("DRAM"), other types of random access memory ("RAM"), read-only memory ("ROM"), electrically erasable programmable read-only memory ("EEPROM"), flash memory or other memory technology, compact disc read-only memory ("CD-ROM"), digital versatile disk ("DVD") or other optical storage devices, cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. Communication media can embody computer-readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism. As defined herein, computer-readable storage media does not include communication media.

[0096] Computer readable instructions stored on one or more non-transitory computer readable storage media, when executed by one or more processors, can perform the above-mentioned Figures 1 to 7 The operations described. Generally, computer-readable instructions include routines, programs, objects, components, data structures, etc. that perform specific functions or implement specific abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0097] Through the above technical solutions, the present disclosure provides a multi-version sharding plan to improve the horizontal scaling and load balancing of distributed shards while avoiding downtime caused by data migration. According to the serverless architecture, application hosting service providers can provide customers with distributed computing resources divided into shards, which can be dynamically allocated, expanded and load balanced for workflow applications that are independent of the architecture. The versioned sharding plan can be implemented in a database, which stores key-value intervals that enable workflow application executions to be uniquely mapped to specific shards. The database controller can invariably allocate shards for each execution of the workflow application and publish a new version of the sharding plan that can be accessed by the front-end and back-end of the customer's hosted application. Through these solutions, data migration between shards is avoided during the horizontal scaling of computing resources allocated to workflow applications, and no downtime is caused.

[0098] Sample Clauses

[0099] A. A method comprising: assigning an execution identifier to an execution of a workflow application in a database; determining a shard identifier assigned to the execution based on a published shard plan returned by the database; and forwarding the execution to the assigned shard at a backend.

[0100] B. The method of paragraph A further comprising: generating an execution key and assigning the execution key to the execution.

[0101] C. The method of paragraph B, wherein generating the execution key comprises: deterministically generating a unique key in a key space.

[0102] D. The method as described in paragraph B, wherein the sharding plan includes a correspondence between shard identifiers and key value intervals.

[0103] E. The method of paragraph D, wherein determining the shard identifier assigned to the execution comprises searching a key interval that includes the execution key.

[0104] F. The method as described in paragraph E, wherein determining the shard identifier assigned to the execution further comprises: recording the correspondence between the execution identifier and the shard identifier in the shard plan.

[0105] G. The method as described in F, wherein the correspondence between the execution identifier and the slice identifier is permanently recorded.

[0106] H. A system comprising: one or more processors; and a memory, the memory being communicatively coupled to the one or more processors, the memory storing computer executable modules that can be executed by the one or more processors, the computer executable modules implementing associated operations when executed by the one or more processors, the computer executable modules comprising: an allocation module configured to assign an execution identifier to an execution of a workflow application in a database; a shard determination module configured to determine a shard identifier assigned to the execution based on a published shard plan returned by the database; and an execution forwarding module configured to forward the execution to the assigned shard at the back end.

[0107] I. The system of paragraph H further includes a key generation module configured to generate an execution key, and wherein the assignment module is further configured to assign the execution key to the execution.

[0108] J. The system of paragraph I, wherein the key value generation module is further configured to generate the execution key value by deterministically generating a unique key value in a key value space.

[0109] K. A system as described in paragraph I, wherein the sharding plan includes a correspondence between shard identifiers and key value intervals.

[0110] L. The system of paragraph K, wherein the shard determination module is configured to determine the shard identifier assigned to the execution by searching a key interval that includes the execution key.

[0111] M. The system as described in paragraph L, wherein the shard determination module is configured to: further determine the shard identifier assigned to the execution by recording the corresponding relationship between the execution identifier and the shard identifier in the shard plan.

[0112] N. The system as described in paragraph M, wherein the shard determination module is configured to: persistently record the correspondence between the execution identifier and the shard identifier.

[0113] O. A computer-readable storage medium storing computer-readable instructions executable by one or more processors, which, when executed by the one or more processors, causes the one or more processors to perform the following operations: assigning an execution identifier to an execution of a workflow application in a database; determining a shard identifier assigned to the execution based on a published shard plan returned by the database; and forwarding the execution to the assigned shard at the back end.

[0114] P. The computer-readable storage medium of paragraph O, wherein the operations further comprise generating an execution key and assigning the execution key to the execution.

[0115] Q. The computer-readable storage medium of paragraph P, wherein generating the execution key comprises deterministically generating a unique key in a key space.

[0116] R. The computer-readable storage medium of paragraph P, wherein the sharding plan includes a correspondence between shard identifiers and key-value intervals.

[0117] S. The computer-readable storage medium of paragraph R, wherein determining the shard identifier assigned to the execution comprises searching a key interval that includes the execution key.

[0118] T. The computer-readable storage medium of paragraph S, wherein determining the shard identifier assigned to the execution comprises recording a correspondence between execution identifiers and shard identifiers in a sharding plan.

[0119] U. The computer-readable storage medium as described in paragraph T, wherein the correspondence between the execution identifier and the slice identifier is persistently recorded.

[0120] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

1. A sharding method for a workflow application in a serverless architecture, comprising: Assigning an execution identifier to an execution of the workflow application in the database, wherein the execution is an operation of performing a task of the workflow application from beginning to end by configuring one or more physical and / or virtual processors of a hosting computing resource; Determining a shard identifier assigned to the execution according to a published shard plan returned by the database, wherein the shard plan includes a correspondence between shard identifiers and key value intervals, and determining the shard identifier assigned to the execution according to the published shard plan returned by the database includes: determining the shard identifier assigned to the execution according to the execution key and the corresponding key value interval; and The execution is forwarded to the assigned shard at the backend.

2. The method according to claim 1, further comprising: An execution key is generated and assigned to the execution.

3. The method according to claim 2, wherein: Generating the execution key includes deterministically generating a unique key in a key space.

4. The method according to claim 1, wherein Determining the shard identifier assigned to the execution includes searching for a key interval that includes the execution key.

5. The method according to claim 4, wherein Determining the shard identifier assigned to the execution further includes: recording a correspondence between the execution identifier and the shard identifier in the shard plan.

6. The method according to claim 5, wherein: The corresponding relationship between the execution identifier and the slice identifier is permanently recorded.

7. A sharding system for workflow applications in a serverless architecture, comprising: one or more processors; and a memory communicatively coupled to the one or more processors, the memory storing computer-executable modules executable by the one or more processors, the computer-executable modules implementing associated operations when executed by the one or more processors, the computer-executable modules comprising: an allocation module configured to allocate an execution identifier to an execution of the workflow application in the database, wherein the execution is an operation of performing a task of the workflow application from beginning to end by configuring one or more physical and / or virtual processors of a hosting computing resource; a shard determination module configured to determine a shard identifier assigned to the execution based on a published shard plan returned by the database, wherein the shard plan includes a correspondence between shard identifiers and key value intervals, and determining the shard identifier assigned to the execution based on the published shard plan returned by the database comprises: determining the shard identifier assigned to the execution based on an execution key value and a corresponding key value interval; and An execution forwarding module is configured to forward the execution to the assigned shard at the back end.

8. The system according to claim 7, further comprising a key value generation module configured to generate an execution key value, and wherein The assignment module is further configured to assign the execution key to the execution.

9. The system according to claim 8, wherein: The key value generation module is further configured to generate the execution key value by deterministically generating a unique key value in a key value space.

10. The system according to claim 7, wherein: The shard determination module is configured to determine the shard identifier assigned to the execution by searching a key value interval including the execution key value.

11. The system according to claim 10, wherein: The shard determination module is configured to: further determine the shard identifier assigned to the execution by recording a corresponding relationship between the execution identifier and the shard identifier in the shard plan.

12. The system according to claim 11, wherein: The fragment determination module is configured to continuously record the corresponding relationship between the execution identifier and the fragment identifier.

13. A computer-readable storage medium storing computer-readable instructions executable by one or more processors, wherein when the computer-readable instructions are executed by the one or more processors, the one or more processors are caused to perform the following operations: Assigning an execution identifier to an execution of a workflow application in a database, where The execution is an operation to perform the tasks of the workflow application from beginning to end by configuring one or more physical and / or virtual processors of the hosting computing resources; Determining a shard identifier assigned to the execution according to a published shard plan returned by the database, wherein the shard plan includes a correspondence between shard identifiers and key value intervals, and determining the shard identifier assigned to the execution according to the published shard plan returned by the database includes: determining the shard identifier assigned to the execution according to the execution key and the corresponding key value interval; and The execution is forwarded to the assigned shard at the backend.

14. The computer-readable storage medium of claim 13, wherein: The operations also include generating an execution key and assigning the execution key to the execution.

15. The computer-readable storage medium of claim 14, wherein: Generating the execution key includes deterministically generating a unique key in a key space.

16. The computer-readable storage medium of claim 13, wherein: Determining the shard identifier assigned to the execution includes searching for a key interval that includes the execution key.

17. The computer-readable storage medium of claim 16, wherein: Determining the shard identifier assigned to the execution further includes: recording a correspondence between the execution identifier and the shard identifier in the shard plan.

Images