Service scheduling method and device, and electronic device

Abstract

Embodiments of the present disclosure provide a service scheduling method and device and electronic equipment, and relate to the technical field of computers. The method comprises: receiving a request to be processed from different channels; wherein the request to be processed comprises a channel identifier and an application credential; determining a first channel party to which the request to be processed belongs according to the channel identifier and the application credential; determining a first isolated domain corresponding to the first channel party from a plurality of isolated domains, and routing the request to be processed to the first isolated domain; wherein each isolated domain is independent of other isolated domains in at least one dimension of thread pool, connection pool and queue resources.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a service scheduling method, apparatus, and electronic device. Background Technology

[0002] With the continuous development of Internet and cloud computing technologies, more and more services need to use service clusters to better meet user needs.

[0003] However, in related technologies, all services are typically deployed in a unified service cluster, and the resources within the service cluster are used to process requests from all channels. When traffic surges or service malfunctions occur in one channel, it may consume the resources of the service cluster, causing other channels to become unresponsive. Summary of the Invention

[0004] This disclosure provides a service scheduling method, apparatus, electronic device, computer-readable storage medium, and computer program product to achieve resource isolation between channels and improve overall processing efficiency.

[0005] According to one aspect of the present disclosure, a service scheduling method is provided, comprising: receiving pending requests from different channels; wherein the pending requests include a channel identifier and an application credential; determining a first channel to which the pending requests belong based on the channel identifier and the application credential; determining a first isolation domain corresponding to the first channel from a plurality of isolation domains, and routing the pending requests to the first isolation domain; wherein each isolation domain is independent of other isolation domains in at least one dimension of thread pool, connection pool, and queue resources.

[0006] According to another aspect of the present disclosure, a service scheduling apparatus is provided, comprising: a receiving module for receiving pending requests from different channels; wherein the pending requests include a channel identifier and an application credential; a determining module for determining a first channel to which the pending request belongs based on the channel identifier and the application credential; and a processing module for determining a first isolation domain corresponding to the first channel from a plurality of isolation domains and routing the pending request to the first isolation domain; wherein each isolation domain is independent of other isolation domains in at least one dimension of thread pool, connection pool, and queue resources.

[0007] According to another aspect of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement one or more of the methods described in the present disclosure.

[0008] According to another aspect of the present disclosure, a computer-readable storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements one or more of the methods described in the embodiments of the present disclosure.

[0009] According to another aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements one or more of the methods described in the embodiments of the present disclosure.

[0010] The beneficial effects of the technical solutions provided in this disclosure are: The service scheduling method provided in this disclosure, on the one hand, achieves physical isolation in at least one dimension of thread pool, connection pool, and queue resources by allocating independent isolation domains to different channels. This avoids the impact of sudden traffic or internal failures in a single channel on other channels, improving the stability and fault tolerance of the system. Simultaneously, this channel isolation mechanism reduces the overhead caused by multiple channels competing for the same set of resources, increasing overall throughput. On the other hand, routing requests from different channels to their corresponding isolation domains facilitates rapid fault location in case of failure, prevents fault propagation between channels, and improves system reliability.

[0011] Additional aspects and advantages of embodiments of this disclosure will be set forth in part in the description which follows, and will become apparent from the description or may be learned by practice of this disclosure. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments of this disclosure will be briefly introduced below.

[0013] Figure 1 This is a flowchart illustrating a service scheduling method provided in an embodiment of this disclosure; Figure 2 This is a flowchart illustrating another service scheduling method provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of the platform architecture for the service scheduling method provided in this embodiment of the disclosure; Figure 4 This is a schematic diagram of a process for routing a request to be processed to a corresponding isolation domain, provided by an embodiment of this disclosure; Figure 5 This is a schematic diagram of an assembly line provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of a process for expanding and shrinking capacity according to an embodiment of the present disclosure; Figure 7 This is a schematic diagram of the structure of a service scheduling device provided in an embodiment of this disclosure; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0014] The embodiments of this disclosure are described below with reference to the accompanying drawings. It should be understood that the embodiments described below with reference to the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of this disclosure, and do not constitute a limitation on the technical solutions of the embodiments of this disclosure.

[0015] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the terms “comprising” and “including” as used in embodiments of this disclosure mean that the corresponding feature can be implemented as the presented feature, information, data, step, operation, element, and / or component, but do not exclude implementation as other features, information, data, step, operation, element, component, and / or combinations thereof supported by the art. It should be understood that when we say that an element is “connected” or “coupled” to another element, the element can be directly connected or coupled to the other element, or it can mean that the element and the other element are connected through an intermediate element. Furthermore, “connected” or “coupled” as used herein can include wireless connection or wireless coupling. The term “multiple” refers to two or more; therefore, in embodiments of this disclosure, “multiple” may also be understood as “at least two.” The term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / ", unless otherwise specified, generally indicates that the related objects before and after it are in an "or" relationship.

[0016] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0017] This disclosure provides a service scheduling method, apparatus, electronic device, computer-readable storage medium, and computer program product.

[0018] The following description of several exemplary embodiments illustrates the technical solutions of this disclosure and the technical effects produced by these solutions. It should be noted that the following embodiments can be referenced, learned from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0019] Figure 1 This is a flowchart illustrating a service scheduling method provided in an embodiment of this disclosure.

[0020] like Figure 1 As shown, the method may include the following steps.

[0021] Step S101: Receive pending requests from different channels; wherein, the pending requests include channel identifiers and application credentials.

[0022] The service scheduling method provided in this disclosure can be executed by any electronic device with computing capabilities, such as a terminal device and / or a server. Terminal devices include, but are not limited to, smartphones, tablets, laptops, desktop computers, wearable devices, virtual reality devices, smart home devices, etc. Servers can be servers that provide various services, such as servers that analyze and process received requests and other data, and then return the processing results.

[0023] For example, the service scheduling method provided in this embodiment of the disclosure can be executed by a first server, which receives pending requests from different channels and routes the pending requests to the corresponding isolation domains.

[0024] In this embodiment, the requests to be processed come from different channels, where a channel refers to the application provider or operator. Taking a game application as an example, a channel could be the game provider or operator. Different channels have different business characteristics. If all requests from all channels are routed to the same resource pool for processing, a surge in traffic or service anomalies in one channel may consume all resources, causing a simultaneous decline in the service quality of other channels. For example, a large number of timeout requests in the payment callback interface of one channel may fill the shared thread pool, preventing other channels' payment services from responding normally. This embodiment addresses this by setting separate isolation domains for different channels, routing requests from different channels to their corresponding isolation domains, thus avoiding the impact of sudden traffic surges or internal failures in a single channel on other channels. In this embodiment, there can be one or more requests to be processed, each including a channel identifier and application credentials. The channel identifier identifies the channel from which the request originates. The channel identifier can be represented by a channel number consisting of Arabic numerals or a channel code consisting of Arabic numerals and letters. For example, channel identifiers could be 1001, 1002, or A1, A2, etc. Application credentials are used to verify the authenticity and legitimacy of the channel identity corresponding to the channel identifier included in the request to be processed. The channel identity, for example, is operator A, used to prove the authenticity of the channel and prevent forgery by a third party. As an example, application credentials can take the form of an application identifier and a signature value generated based on an application key. The application identifier and application key are pre-assigned to each channel. The channel uses the pre-assigned application key to sign the request parameters and includes the application identifier and the signature value generated based on the application key in the request to be processed.

[0025] Step S102: Determine the first channel party to which the request to be processed belongs based on the channel identifier and application credentials.

[0026] In this embodiment, the first server determines the channel provider corresponding to the channel identifier, verifies the identity of the channel provider corresponding to the channel identifier based on the application credential, and, upon successful verification, determines the channel provider corresponding to the channel identifier as the channel provider to which the request to be processed belongs. For ease of distinction, the channel provider to which the request to be processed belongs is referred to as the first channel provider.

[0027] As an example, the first server looks up the corresponding application key based on the application identifier included in the application credential, and uses the found application key to generate a verification signature value; it then verifies the signature value included in the application credential based on the verification signature value to confirm the legitimacy of the request to be processed.

[0028] Step S103: Determine the first isolation domain corresponding to the first channel from multiple isolation domains, and route the request to be processed to the first isolation domain; wherein, each isolation domain is independent of other isolation domains in at least one dimension of thread pool, connection pool and queue resources.

[0029] In this embodiment of the disclosure, service resources can be logically divided into multiple isolation domains in advance, with each channel corresponding to one or more isolation domains. The isolation domains are independent of each other in at least one dimension of thread pool, connection pool, and queue, and the exhaustion of resources in one isolation domain will not affect the service capabilities of other isolation domains.

[0030] As an example, thread pools, connection pools, and queue resources are allocated differently for different channels based on their transaction volume. For instance, channel A, with higher request volume, is allocated a thread pool with a maximum of 300 threads, a connection pool with a maximum of 200 connections, and a queue with a capacity of 3000. Channel B, with lower request volume, is allocated a thread pool with a maximum of 80 threads, a connection pool with a maximum of 50 connections, and a queue with a capacity of 500. After allocation, a mapping relationship is established between channel identifiers and thread pool instances, connection pool instances, and queue instances, thus binding the channels to the resources.

[0031] In this embodiment of the disclosure, after determining the first channel party to which the request to be processed belongs, one or more isolation domains corresponding to the first channel party are determined from multiple isolation domains pre-divided according to the channel party. The isolation domain corresponding to the first channel party is referred to as the first isolation domain. The request to be processed is routed to the first isolation domain, and the service resources of the first isolation domain are used to process the request.

[0032] For example, channel A corresponds to isolation domain 1, and channel B corresponds to isolation domain 2. After receiving a request to be processed from channel A, the request is routed to isolation domain 1, where the service resources of isolation domain 1 are used to process it. After receiving a request to be processed from channel B, the request is routed to isolation domain 2, where the service resources of isolation domain 2 are used to process it. This achieves channel-level resource isolation.

[0033] The service scheduling method provided in this disclosure, on the one hand, achieves physical isolation in at least one dimension of thread pool, connection pool, and queue resources by allocating independent isolation domains to different channels. This avoids the impact of sudden traffic or internal failures in a single channel on other channels, improving the stability and fault tolerance of the system. Simultaneously, this channel isolation mechanism reduces the overhead caused by multiple channels competing for the same set of resources, increasing overall throughput. On the other hand, routing requests from different channels to their corresponding isolation domains facilitates rapid fault location in case of failure, prevents fault propagation between channels, and improves system reliability.

[0034] In some embodiments, each channel provider corresponds to one or more isolation domains, and the number of isolation domains corresponding to each channel provider is determined according to the channel provider's business volume.

[0035] Specifically, service resources can be logically divided into multiple isolation domains in advance, with each channel corresponding to one or more isolation domains. The granularity of the isolation domains can be flexibly configured according to the channel's business volume. For example, high-traffic channels may have one or more exclusive isolation domains, while medium- to low-traffic channels may share one isolation domain. Determining the number of isolation domains corresponding to a channel based on its business volume ensures that high-traffic channels have sufficient resources to improve processing efficiency; at the same time, low-traffic channels sharing isolation domains avoids resource redundancy and improves overall resource utilization.

[0036] In some embodiments, the service scheduling method may further include: In response to the load of the first isolation domain exceeding a preset threshold and the pending request being of the first request type, the pending request is routed to the elastic overflow domain; wherein, the elastic overflow domain is an elastic resource area shared by multiple channel parties and different from multiple isolation domains; pending requests of the second request type are routed to the first isolation domain.

[0037] In some embodiments, an elastic overflow domain can be pre-configured. An elastic overflow domain refers to a shared elastic resource area used to temporarily handle non-core requests from a channel when its isolated domain becomes overloaded. Elastic overflow domains are not limited to any channel; every channel can use them.

[0038] In some embodiments, in response to the load of the first isolation domain corresponding to the first channel exceeding a preset threshold, pending requests of the first request type are routed to the elastic overflow domain, and pending requests of the second request type are routed to the first isolation domain. The second request type is a core request, such as a login request or a payment request; the first request type is a non-core request, such as a data reporting request.

[0039] This embodiment of the disclosure uses a dynamic routing strategy. When the load of an isolation domain of a certain channel is close to the limit, some non-core requests of that channel are temporarily diverted to the elastic overflow domain to ensure that the processing efficiency of core requests is not affected.

[0040] Figure 2 This is a flowchart illustrating another service scheduling method provided in this embodiment.

[0041] like Figure 2 As shown, the method may also include the following steps.

[0042] Step S201: Receive resource adjustment instructions from the elastic scheduling layer; the resource adjustment instructions carry the identifier of the channel to be expanded, the service type, and the number of resources.

[0043] In some embodiments, the elastic scheduling layer can achieve predictive scaling up and down of resources based on business characteristic awareness. Specifically, it can collect multi-dimensional business signals, predict traffic in future time periods based on these signals, and generate resource adjustment instructions or resource reclamation instructions based on the traffic in those future time periods. The resource adjustment instructions are used to scale up resources for channel partners, while the resource reclamation instructions are used to scale down resources for channel partners.

[0044] In some embodiments, the channel provider identifier is used to identify the channel provider that needs expansion, i.e., the channel provider with a large business volume in the future time period. Service types include at least one of the following: low-latency high-concurrency, compute-intensive, and batch processing. Low-latency high-concurrency services include, for example, login services and payment services; compute-intensive services include, for example, cloud-based building services and dynamic detection services; and batch processing services include, for example, data backhaul services and report generation services. Different service types have different resource requirements. For example, low-latency high-concurrency services require lightweight instances that can start quickly; compute-intensive services require high-configuration instances that can tolerate longer startup times; and batch processing services can use low-priority elastic resources. The number of resources can be determined based on resource requirements and the resources already occupied by the channel provider currently being expanded.

[0045] Step S202: Match the corresponding service instance from the elastic resource pool according to the service type.

[0046] In some embodiments, the elastic resource pool stores various types of service instances for use by different channel partners. When a channel partner needs to scale up, a service instance corresponding to the service type is matched from the elastic resource pool and injected into the corresponding isolation domain of the channel partner. This enables the injection of service instances based on the required service type, improving resource utilization.

[0047] Step S203: Based on the number of resources, inject the service instance into the second isolation domain corresponding to the channel to be expanded.

[0048] In some embodiments, the channel to be expanded is determined based on the channel identifier carried in the resource adjustment instruction, and a second isolation domain corresponding to the channel to be expanded is determined from multiple isolation domains. Based on the resource quantity carried in the resource adjustment instruction, a corresponding number of service instances are injected into the second isolation domain, achieving precise and on-demand elastic resource deployment for the specified channel.

[0049] In some embodiments, the service scheduling method may further include: receiving a resource reclamation instruction from the elastic scheduling layer; and, in response to a service instance being idle, returning the service instance from the second isolation domain to the elastic resource pool.

[0050] In some embodiments, the elastic scheduling layer can achieve predictive scaling down of resources based on business characteristic awareness. Specifically, it can collect multi-dimensional business signals, predict traffic in future time periods based on these signals, and generate resource reclamation instructions based on the traffic in those future time periods. For example, when traffic drops to a preset value in the future time period, a resource reclamation instruction is generated, which is used to scale down resources for the channel provider.

[0051] In some embodiments, after injecting a service instance into the second isolation domain, the injected service instance is used to process new requests. Once the request processing is complete, the service instance is marked as idle. In response to the service instance being idle, it is returned from the second isolation domain to the elastic resource pool for continued use when scaling up is needed later. By using service instances in the elastic resource pool, resources are replenished promptly when the channel needs to scale up, avoiding reduced processing efficiency when traffic arrives; simultaneously, resources are promptly reclaimed when the channel needs to scale down, avoiding resource redundancy and waste.

[0052] In some embodiments, the service scheduling method may further include: within a first isolation domain, executing each service stage sequentially according to the execution order of multiple service stages in a predefined pipeline; when the first service stage among the multiple service stages fails to execute, marking the first service stage as a stage abnormal state, and continuing execution from the first service stage after repairing the first service stage.

[0053] In some embodiments, key business processes can be abstracted into standardized pipelines, each comprising multiple service stages arranged sequentially. Taking game listing as an example, the game listing process can be divided into pipelines, including service stages such as: submission acceptance, static review, dynamic detection, cloud building, package signing, and multi-platform distribution. Each service stage is handled by an independent service cluster and executed sequentially according to the pipeline order. When a service stage in the pipeline (referred to as the first service stage) fails and is interrupted, the first service stage is marked as being in an abnormal state, without affecting the normal execution of other service stages. After the first service stage is repaired, execution resumes from the first service stage, without needing to restart from the first service stage of the pipeline, thus avoiding the waste of resources and time that would otherwise be required to re-execute the entire pipeline due to the failure of a single stage.

[0054] In some embodiments, the service scheduling method may further include: in response to a transient failure in the first service phase, performing retry processing within the first service phase; wherein the number of retry processing is determined according to the phase type of the first service phase, and the interval between each retry processing increases exponentially.

[0055] In some embodiments, transient failures may include, for example, network jitter or temporary service unavailability. In response to a transient failure occurring at a service stage in the pipeline (referred to as the first service stage), retry processing can be automatically performed within the first service stage. Specifically, the number of retry operations is determined based on the stage type of the first service stage; for example, build-type tasks allow more retries, while payment-type tasks use fewer retries. The retry strategy employs an exponential backoff interval, where the interval between each retry increases exponentially to avoid a retry storm before service recovery. For example, a strategy with an initial interval of 1 second and a backoff factor of 2: after the first failure, wait 1 second to retry; after the second failure, wait 2 seconds; after the third failure, wait 4 seconds, and so on, until the maximum number of retries is reached.

[0056] In some embodiments, the service scheduling method may further include: in response to a failure to repair the first service stage, performing a reverse compensation operation on a service stage in a predefined pipeline prior to the first service stage; wherein the reverse compensation operation includes at least one of the following: releasing allocated resources, withdrawing pushed artifacts, and updating the processing status.

[0057] In some embodiments, when the first service stage in a plurality of service stages fails, the first service stage is marked as an abnormal state and repaired. If the repair fails, at least one of the following operations is performed on the service stages in the predefined pipeline preceding the first service stage: releasing allocated resources, withdrawing pushed artifacts, and updating processing status, to avoid problems such as intermediate data, resource leaks, and status errors.

[0058] As an example, taking game submission as an example, the predefined pipeline includes submission acceptance, static review, dynamic detection, cloud building, package signing, and multi-platform distribution. For instance, if a fix fails during the dynamic detection stage, a reverse compensation operation is triggered, executing sequentially in reverse order (dynamic detection stage, static review stage, submission acceptance stage): First, the processing status of the dynamic detection stage is updated to "detection failed," and the detection report cache is cleared; then, reverse compensation is performed on the static review stage, withdrawing the review record and tagging results, and releasing the review task allocation; finally, reverse compensation is performed on the submission acceptance stage, releasing the pipeline number and resource reservation quota, and reverting the application status to "submitted and pending." After the reverse compensation is completed, all intermediate products and allocated resources are completely released, and the overall pipeline status rolls back to its initial stable state, providing a clean starting environment for the next resubmission of the submission application.

[0059] Figure 3 This is a schematic diagram of the platform architecture for the service scheduling method provided in this embodiment of the disclosure.

[0060] like Figure 3 As shown in the embodiments of this disclosure, the platform architecture may include: a multi-tenant routing layer 301, a service orchestration layer 302, and an elastic scheduling layer 303. The multi-tenant routing layer 301 is used for channel-based isolation and routing of requests, including a unified access gateway, a channel routing engine, and tenant isolation domains. The service orchestration layer 302 is used for pipeline scheduling and anomaly compensation across service stages, including a pipeline orchestrator, a state manager, and a compensation engine. The elastic scheduling layer 303 performs predictive resource scaling up and down based on business characteristic awareness, including a business awareness unit, a resource scheduler, and an elastic resource pool. The multi-tenant routing layer is responsible for routing requests from different channels to their respective isolated service domains, preventing fault contagion between channels; the multi-tenant routing layer ensures service stability through channel-level isolation; the service orchestration layer ensures pipeline consistency through global state management; and the elastic scheduling layer ensures resource utilization efficiency through business awareness. The three layers work together to enable the platform to balance isolation, orchestration capabilities, and resource elasticity in multi-channel parallel service scenarios.

[0061] Figure 4 This is a schematic diagram of a process for routing a request to be processed to a corresponding isolation domain, provided by an embodiment of this disclosure.

[0062] like Figure 4 As shown, the method may include the following steps.

[0063] Step S401: The unified access gateway receives pending requests from different channels; wherein, the pending requests include channel identifiers and application credentials.

[0064] Step S402: The unified access gateway performs authentication and injects channel context.

[0065] In some embodiments, when all requests entering the platform pass through the unified access gateway, the gateway automatically injects a channel context based on information such as the channel identifier and application credentials in the request. The channel context is automatically propagated throughout the subsequent service call chain, allowing each service node to determine the channel to which the current request belongs, without requiring explicit transmission in the business code. This decouples channel identification from business logic, so business services do not need to care which channel the request comes from; routing and isolation decisions are handled uniformly by the infrastructure layer.

[0066] Step S403: The unified access gateway sends a request carrying the channel context to the channel routing engine.

[0067] In step S404, the channel routing engine routes the request from channel A to the channel A isolation domain.

[0068] Step S405, the isolation domain of channel A returns a response.

[0069] Step S406: When the isolation domain is under normal load, the channel routing engine routes the request from channel B to the isolation domain of channel B.

[0070] Step S407, Channel B isolation domain returns a response.

[0071] In step S408, if the isolation domain is overloaded, the channel routing engine will route non-core requests from channel B to the elastic overflow domain.

[0072] Step S409: The elastic overflow domain returns a response.

[0073] Figure 5 This is a schematic diagram of an assembly line provided in an embodiment of this disclosure.

[0074] like Figure 5 As shown, taking games as an example, the complete process from game submission to app store launch involves the orderly collaboration of multiple service stages. The key business processes of games are abstracted into a standardized pipeline. Taking the game app store launch pipeline as an example, it includes the following ordered stages: submission acceptance, static review, dynamic testing, cloud-based construction, package signing, and multi-platform distribution.

[0075] The pipeline can be as follows: 501 Submission Acceptance; 502 Static Review after Submission Acceptance; 503 Dynamic Detection after Static Review Passes; 504 Review Rejection if Static Review Fails; 506 Cloud Building after Dynamic Detection Passes; 505 Manual Review if Issues Exist in Dynamic Detection; 506 Cloud Building if Manual Review Passes; 504 Review Rejection if Manual Review Fails; 506 Package Signing after Cloud Building; 508 Multi-Platform Distribution, thus completing the app store launch.

[0076] The pipeline orchestrator manages the execution order of each stage, data transfer between stages, and dependencies. Each stage is executed by an independent service cluster, and the orchestrator is only responsible for scheduling and coordination, without intervening in the specific business logic of each stage. By centralizing the interconnected collaboration logic scattered within each service under the unified management of the orchestrator, the problem of difficulty in guaranteeing end-to-end consistency caused by the independent operation of each service is solved.

[0077] The orchestrator maintains the global state of each pipeline instance: the current stage, the output of each completed stage, and the overall progress percentage. The execution result of any stage (success, failure, or requiring manual intervention) is persistently recorded through the state manager. When a pipeline is interrupted due to a stage failure, it can be restored and resumed from the failed stage without starting from scratch. This stage-level recovery capability avoids the waste of resources and time of redoing the entire pipeline due to a single stage failure.

[0078] The pipeline supports parallel execution and conditional branching at each stage. For example, in the cloud build stage, when distributing to multiple channels, build tasks can be executed in parallel for different target channels (Channel A, Channel B, and Channel C) simultaneously. After all parallel builds are completed, they converge to enter the next stage. Conditional branching allows the pipeline to determine the subsequent path based on the output of the preceding stage. For instance, if a high-risk rule is detected during static review, all subsequent stages can be skipped and the process terminated directly. If a low-risk alert is detected, the pipeline will proceed to the manual review branch. Parallel execution reduces the total build time for multiple channels, while conditional branching enables the pipeline to flexibly adjust the execution path according to actual conditions. The pipeline supports sequential execution, conditional branching, and parallel stages. The review stage follows different branches based on the results, and the build stage executes multiple channels in parallel before converging, demonstrating the flexibility of the pipeline orchestration.

[0079] Each stage in the pipeline executes within an independent fault domain. An execution anomaly in a stage (such as a build service crash or an audit service timeout) is confined to that stage, preventing it from propagating forward and invalidating the results of completed stages, or from triggering subsequent stages incorrectly. Upon detecting a stage anomaly, the orchestrator marks the pipeline instance as "Stage Anomaly - Awaiting Recovery," without affecting the normal execution of other pipeline instances. This limits the impact of faults to the smallest granularity (single stage), protecting the completed work in the pipeline from being discarded.

[0080] For transient failures (such as network jitter or temporary service unavailability), the orchestrator supports phase-level automatic retries. When a stage in the pipeline fails unrecoverably (e.g., build artifact verification fails), the orchestrator triggers the compensation engine to perform reverse compensation operations on the executed preceding stages. When automatic retries and compensation fail to resolve the issue (e.g., external dependencies are unavailable for an extended period), the orchestrator moves the pipeline instance to a dead-letter queue and generates an alert notification containing complete context (completed stage, failed stage, error details, and relevant log identifiers). Operations personnel can use this context to quickly locate the problem and manually restore the pipeline.

[0081] Figure 6 This is a schematic diagram of the expansion and reduction process provided in an embodiment of the present disclosure.

[0082] like Figure 6 As shown, the method may include the following steps.

[0083] Step S601: The service sensor collects service information.

[0084] The business sensor continuously collects business signals from various dimensions of the platform, including: trends in game submissions (reflecting upcoming demand for build and review resources), real-time trends in API calls across various channels (reflecting runtime service load trends), known channel operation activity calendars (such as promotional activity windows registered in advance by channel partners), and historical traffic patterns (such as holiday effects). These multi-dimensional business signals provide richer and more forward-looking load assessment criteria than single infrastructure metrics, enabling scheduling decisions to be made with advance notice.

[0085] In step S602, the service perceiver pushes predictive scaling suggestions to the resource scheduler.

[0086] Based on multi-dimensional signals provided by the business sensor, the resource scheduler performs capacity expansion in advance before the actual traffic arrives. For example, when it detects a large-scale promotional campaign for pre-registration on a certain channel within 2 hours, the scheduler expands service instances for the login and payment isolation domains of that channel in advance; when it detects an increase in game submissions on a weekday afternoon, it reserves computing resources in advance for the review and build pipeline. Resources are ready before traffic arrives, eliminating the risk of service degradation during the expansion window.

[0087] Step S603: The resource scheduler requests the corresponding resources according to the service type.

[0088] Different types of services have different resource requirements. Login and payment services are low-latency, high-concurrency services that require lightweight instances that can start quickly; cloud-based building and dynamic detection are computationally intensive services that require high-configuration instances but can tolerate longer startup times; data backhaul and report generation are batch processing services that can use low-priority elastic resources. The scheduler matches the corresponding resource strategy according to the service type, optimizing overall resource utilization efficiency so that each type of service receives the most suitable resource configuration.

[0089] Step S604: Allocate resource instances to the Elastic Resource Pool.

[0090] Step S605: Inject the new instance into the target channel isolation domain.

[0091] Step S606: Confirm injection complete.

[0092] Each channel's isolation domain has a guaranteed minimum resource quota (ensuring basic service capabilities) and an elastic cap. When a channel does not use its elastic quota, these resources can be temporarily borrowed by other channels experiencing traffic peaks. This strikes a balance between channel isolation and resource efficiency, avoiding the waste of reserving resources for each channel based on peak traffic, while ensuring that the basic isolation between channels is not affected by borrowing.

[0093] In step S607, the service sensor detects that the traffic has fallen back to the baseline.

[0094] Step S608: The resource scheduler marks redundant instances as pending reclamation.

[0095] Step S609: The channel isolation domain awaits the completion of existing request processing.

[0096] Step S610: The channel isolation domain indicator instance is idle.

[0097] Step S611: The resource scheduler releases idle instances back to the resource pool.

[0098] Step S612, resource recycling complete.

[0099] In some embodiments, each request entering the platform is assigned a globally unique tracing identifier at the unified access gateway. This identifier is automatically propagated throughout the entire request chain, including the routing layer, service orchestration layer, service execution at each stage, and channel callbacks. When an anomaly occurs, operations personnel can use the tracing identifier to query the complete flow record of the request at each layer, quickly locating the faulty link. The tracing identifier extends across the isolation domain boundary, enabling fault location across architectural layers. Operations personnel do not need to investigate layer by layer; they can reconstruct the complete lifecycle of the request using a single identifier.

[0100] In some embodiments, the execution status of each pipeline instance is visible to developers and platform operators, with information such as the current stage, the time spent in each stage, the waiting time between stages, and retry records displayed in real time. Developers can view the processing progress of their submitted games in the platform pipeline in the developer console.

[0101] In some embodiments, the platform maintains a health metric dashboard for each channel's isolated domain, including: request success rate, average response latency, resource utilization, pipeline throughput, etc. When a channel's health metric falls below a threshold, an alarm is automatically triggered and contingency plans are activated (such as temporary capacity expansion, traffic restrictions, etc.). The channel-level health view allows operators to locate and handle issues at the channel level.

[0102] In some embodiments, the platform supports multi-region deployment and proximity-based service scheduling: the unified access gateway routes requests to the nearest service area cluster based on the geographical location of the request source, reducing network latency. For operations requiring cross-regional collaboration (such as a developer submitting a game in region A and needing to distribute it to a channel in region B), the orchestrator coordinates data synchronization and task scheduling across regions. This reduces network latency perceptible to users and supports global business operations through the orchestrator's cross-regional coordination capabilities.

[0103] This disclosure provides a service scheduling device, such as... Figure 7 As shown, the device 700 includes: The receiving module 701 is used to receive pending requests from different channels; wherein, the pending requests include channel identifiers and application credentials; The determining module 702 is used to determine the first channel to which the request to be processed belongs based on the channel identifier and the application credential; Processing module 703 is used to determine the first isolation domain corresponding to the first channel from multiple isolation domains, and to route the request to be processed to the first isolation domain; Each of the isolation domains is independent of the other isolation domains in at least one dimension of thread pool, connection pool, and queue resources.

[0104] In some embodiments, each channel provider corresponds to one or more of the isolation domains, and the number of isolation domains corresponding to each channel provider is determined according to the business volume of the channel provider.

[0105] In some embodiments, the processing module is further configured to route the request to be processed to an elastic overflow domain in response to the load of the first isolation domain exceeding a preset threshold and the request to be processed being a first request type; wherein the elastic overflow domain is an elastic resource area shared by multiple channel parties and different from the multiple isolation domains; the request to be processed being a second request type is routed to the first isolation domain.

[0106] In some embodiments, the receiving module is further configured to: receive a resource adjustment instruction from the elastic scheduling layer; the resource adjustment instruction carries the identifier of the channel to be expanded, the service type, and the resource quantity; the processing module is further configured to: match a corresponding service instance from the elastic resource pool according to the service type; and inject the service instance into the second isolation domain corresponding to the channel to be expanded according to the resource quantity.

[0107] In some embodiments, the receiving module is further configured to: receive a resource reclamation instruction from the elastic scheduling layer; the processing module is further configured to: in response to the service instance being idle, return the service instance from the second isolation domain to the elastic resource pool.

[0108] In some embodiments, the processing module is further configured to: within the first isolation domain, execute each service stage sequentially according to the execution order of multiple service stages in a predefined pipeline; when the first service stage among the multiple service stages fails to execute, mark the first service stage as a stage abnormal state, and after repairing the first service stage, continue execution from the first service stage.

[0109] In some embodiments, the processing module is further configured to: in response to a transient failure occurring in the first service phase, perform retry processing within the first service phase; wherein the number of retry processing is determined according to the phase type of the first service phase, and the interval between each retry processing increases exponentially.

[0110] In some embodiments, the processing module is further configured to: in response to the failure of the first service stage repair, perform a reverse compensation operation on the service stage in the predefined pipeline that precedes the first service stage; wherein the reverse compensation operation includes at least one of the following: releasing allocated resources, withdrawing pushed artifacts, and updating the processing status.

[0111] The apparatus of this disclosure embodiment can execute the method provided in this disclosure embodiment, and its implementation principle is similar, and it has corresponding technical effects. The actions performed by each module in the apparatus of each embodiment of this disclosure correspond to the steps in the method of each embodiment of this disclosure. For a detailed functional description of each module of the apparatus, please refer to the description in the corresponding method shown above, and it will not be repeated here.

[0112] This disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the method provided in any optional embodiment of this disclosure. Compared with related technologies, it can achieve the following: On the one hand, by allocating independent isolation domains to different channels, physical isolation is achieved in at least one dimension of thread pools, connection pools, and queue resources, avoiding the impact of sudden traffic or internal failures of a single channel on other channels, thus improving the stability and fault tolerance of the system; at the same time, this channel isolation mechanism can reduce the overhead caused by multiple channels competing for the same set of resources, thereby improving the overall throughput. On the other hand, routing requests from different channels to their corresponding isolation domains facilitates rapid fault location in case of failure, avoids fault contagion between channels, and improves the reliability of the system.

[0113] In an alternative embodiment, an electronic device, such as Figure 8 As shown, Figure 8 The illustrated electronic device 800 includes a processor 801 and a memory 803. The processor 801 and the memory 803 are connected, for example, via a bus 802. Optionally, the electronic device 800 may further include a transceiver 804, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 804 is not limited to one type, and the structure of this electronic device 800 does not constitute a limitation on the embodiments of this disclosure.

[0114] Processor 801 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with this disclosure. Processor 801 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0115] Bus 802 may include a pathway for transmitting information between the aforementioned components. Bus 802 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 802 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0116] The memory 803 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0117] The memory 803 stores computer programs that execute embodiments of the present disclosure and is controlled by the processor 801. The processor 801 executes the computer programs stored in the memory 803 to implement the steps shown in the foregoing method embodiments.

[0118] The electronic devices may include, but are not limited to: vehicle controllers, domain controllers, vehicle-mounted systems, refrigerator controllers, vehicle terminals, or other devices capable of performing the control method. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0119] This disclosure provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0120] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0121] It should be understood that although arrows indicate various operation steps in the flowcharts of the embodiments of this disclosure, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of the embodiments of this disclosure, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured as required, and the embodiments of this disclosure do not limit this.

[0122] The above description is only an optional implementation method for some implementation scenarios of this disclosure. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this disclosure without departing from the technical concept of this disclosure also fall within the protection scope of the embodiments of this disclosure.

Claims

1. A service scheduling method, characterized in that, include: Receive pending requests from different channels; wherein, the pending requests include channel identifiers and application credentials; Based on the channel identifier and the application credential, the first channel to which the request to be processed belongs is determined; The first isolation domain corresponding to the first channel is determined from multiple isolation domains, and the request to be processed is routed to the first isolation domain; Each of the isolation domains is independent of the other isolation domains in at least one dimension of thread pool, connection pool, and queue resources.

2. The service scheduling method according to claim 1, characterized in that, Each channel provider corresponds to one or more of the isolation domains, and the number of isolation domains corresponding to each channel provider is determined according to the business volume of the channel provider.

3. The service scheduling method according to claim 1 or 2, characterized in that, The method further includes: In response to the load of the first isolation domain exceeding a preset threshold, and the request to be processed being of the first request type, the request to be processed is routed to the elastic overflow domain. The elastic overflow domain is an elastic resource area shared by multiple channel parties and distinct from the multiple isolation domains; The pending request of the second request type is routed to the first isolation domain.

4. The service scheduling method according to claim 1 or 2, characterized in that, The method further includes: Receive resource adjustment instructions from the elastic scheduling layer; the resource adjustment instructions carry the identifier of the channel to be expanded, the service type, and the amount of resources. Based on the service type, a corresponding service instance is matched from the elastic resource pool; Based on the resource quantity, the service instance is injected into the second isolation domain corresponding to the channel to be expanded.

5. The service scheduling method according to claim 4, characterized in that, The method further includes: Receive resource reclamation instructions from the elastic scheduling layer; In response to the service instance being idle, the service instance is returned from the second isolation domain to the elastic resource pool.

6. The service scheduling method according to claim 1, characterized in that, The method further includes: Within the first isolation domain, each service stage is executed sequentially according to the execution order of multiple service stages in the predefined pipeline; When the first service stage among the plurality of service stages fails to execute, the first service stage is marked as a stage exception state. After the first service stage is repaired, execution continues from the first service stage.

7. The service scheduling method according to claim 6, characterized in that, The method further includes: In response to a transient failure in the first service phase, a retry process is performed within the first service phase. The number of retry processes is determined according to the phase type of the first service phase, and the interval between each retry process increases exponentially.

8. The service scheduling method according to claim 6 or 7, characterized in that, The method further includes: In response to the failure of the first service phase repair, a reverse compensation operation is performed on the service phases in the predefined pipeline that precede the first service phase. The reverse compensation operation includes at least one of the following: releasing allocated resources, withdrawing pushed products, and updating processing status.

9. A service scheduling device, characterized in that, include: A receiving module is used to receive pending requests from different channels; wherein, the pending requests include channel identifiers and application credentials; The determination module is used to determine the first channel to which the request to be processed belongs based on the channel identifier and the application credential; The processing module is used to determine the first isolation domain corresponding to the first channel from multiple isolation domains, and to route the request to be processed to the first isolation domain; Each of the isolation domains is independent of the other isolation domains in at least one dimension of thread pool, connection pool, and queue resources.

10. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method of any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 8.

Images