Service resource processing method and apparatus, electronic device, and computer readable medium
By obtaining the request source identifier and tag of business requests and adjusting routing rules in combination with load assessment metrics, the problems of delayed container scaling decisions and inaccurate resource allocation were solved, and efficient utilization of service resources was achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING WODONG TIANJUN INFORMATION TECH CO LTD
- Filing Date
- 2026-04-28
- Publication Date
- 2026-07-31
AI Technical Summary
The existing reliance on indirect indicators for container scaling leads to delayed and inaccurate decision-making, requires a large amount of manual intervention, and cannot finely allocate service resources, resulting in low utilization of service resources.
By obtaining the request source identifier in the business request, matching the corresponding business tag, and determining the service resource operation type based on real-time load assessment metrics and preset thresholds, the routing rules of the basic tag pool and the public tag pool are adjusted, and server containers are dynamically allocated.
It enables real-time, accurate, dynamic, and automated fine-grained allocation of service resources, maximizing resource utilization.
Smart Images
Figure CN122489208A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a service resource processing method, apparatus, electronic device, and computer-readable medium. Background Technology
[0002] Currently, with the increasing prevalence of microservice architectures and containerized deployments, enterprises typically package applications into containers and deploy them on container management platforms. To cope with peak and trough business requests and ensure service stability and resource utilization, elastic management of the number of deployed containers is necessary. Existing technical solutions rely on indirect indicators such as CPU utilization for container scaling, which leads to decision-making delays, inaccuracies, the need for significant manual intervention, and the inability to finely allocate service resources, resulting in low service resource utilization. Summary of the Invention
[0003] In view of this, embodiments of this application provide a service resource processing method, apparatus, electronic device, and computer-readable medium, which can solve the problems of existing methods that rely on indirect indicators for container scaling, resulting in delayed and inaccurate decision-making, the need for a large amount of manual intervention, the inability to finely allocate service resources, and low service resource utilization.
[0004] To achieve the above objectives, according to one aspect of the embodiments of this application, a service resource processing method is provided, comprising: In response to receiving a business request, obtain the request source identifier from the business request; If the request source identifier is not empty, match the corresponding business tag to the request source identifier; In response to a non-empty business tag, obtain the real-time load assessment metric value corresponding to the business tag, and determine the service resource operation type for the business tag based on the load assessment metric value and a preset threshold. The routing rules for the basic tag pool and the public tag pool are adjusted based on the service resource operation type. The basic tag pool is configured with the minimum number of server containers to meet the off-peak business request processing needs corresponding to the business tag, while the public tag pool is configured with server containers that are not exclusive to any business tag. Allocate server containers for business requests based on the request source identifier, business tag, and adjusted routing rules.
[0005] Optionally, the service resource operation type for a business tag is determined based on load assessment metric values and preset thresholds, including: Determine the number of server containers configured in the basic tag pool corresponding to the business tag, and calculate the load assessment index value of a single server container based on the load assessment index value and the number. In response to a single server container load assessment metric value exceeding a first preset threshold, the service resource operation type for the business tag is determined to be expansion; In response to a single server container load assessment metric value being less than a second preset threshold, the server resource operation type for the business tag is determined to be scaling down. The second preset threshold is less than the first preset threshold.
[0006] Optionally, the routing rules for the basic tag pool and the public tag pool can be adjusted based on the service resource operation type, including: The routing weights are adjusted based on the service resource operation type and assigned to the basic tag pool corresponding to the public tag pool and the business tag; or The number of business requests allocated to the basic tag pool corresponding to the public tag pool and the business tag is adjusted based on the service resource operation type.
[0007] Optionally, the routing weights allocated to the basic tag pools corresponding to the public tag pool and the business tag are adjusted based on the service resource operation type, including: In response to the service resource operation type being expansion, the route weight allocated to the public tag pool is increased, while the route weight allocated to the basic tag pool corresponding to the business tag is decreased. In response to a service resource operation type of scaling down, remove or reduce the route weight allocated to the public tag pool, and increase the route weight allocated to the basic tag pool corresponding to the business tag.
[0008] Optionally, the number of business requests allocated to the basic tag pool corresponding to the public tag pool and the business tag is adjusted based on the service resource operation type, including: In response to the service resource operation type being expansion, the number of business requests allocated to the public tag pool is increased, and the number of business requests allocated to the basic tag pool corresponding to the business tag is decreased. In response to the service resource operation type being scale-down, the number of business requests allocated to the public tag pool is gradually reduced, while the number of business requests allocated to the basic tag pool corresponding to the business tag is increased.
[0009] Optionally, a server container is allocated for business requests, including: In response to an empty request source identifier or an empty business tag, the business request is assigned to a server container in the common tag pool.
[0010] Optionally, the preset threshold is determined as follows: Obtain the historical load assessment metrics values before and after capacity expansion corresponding to the business tags; The machine learning model outputs the optimal single-server container load assessment index value corresponding to the business label based on the load assessment index values before and after historical expansion, which serves as the preset threshold for the business label.
[0011] In addition, this application also provides a service resource processing apparatus, including: The acquisition unit is configured to acquire the request source identifier in the business request in response to receiving a business request. The business tag matching unit is configured to match the corresponding business tag to the request source identifier in response to the request source identifier being non-empty. The operation type determination unit is configured to, in response to a non-empty business tag, obtain the real-time load assessment index value corresponding to the business tag, and determine the service resource operation type for the business tag based on the load assessment index value and a preset threshold. The routing rule adjustment unit is configured to adjust the routing rules for the basic tag pool and the public tag pool based on the service resource operation type. The basic tag pool is configured with the minimum number of server containers that meet the off-peak business request processing needs corresponding to the business tags, while the public tag pool is configured with server containers that are not exclusive to any business tag. The allocation unit is configured to allocate server containers for business requests based on the request source identifier, business tag, and adjusted routing rules.
[0012] Optionally, the operation type determination unit is further configured to: Determine the number of server containers configured in the basic tag pool corresponding to the business tag, and calculate the load assessment index value of a single server container based on the load assessment index value and the number. In response to a single server container load assessment metric value exceeding a first preset threshold, the service resource operation type for the business tag is determined to be expansion; In response to a single server container load assessment metric value being less than a second preset threshold, the server resource operation type for the business tag is determined to be scaling down. The second preset threshold is less than the first preset threshold.
[0013] Optionally, the routing rule adjustment unit is further configured to: The routing weights are adjusted based on the service resource operation type and assigned to the basic tag pool corresponding to the public tag pool and the business tag; or The number of business requests allocated to the basic tag pool corresponding to the public tag pool and the business tag is adjusted based on the service resource operation type.
[0014] Optionally, the routing rule adjustment unit is further configured to: In response to the service resource operation type being expansion, the route weight allocated to the public tag pool is increased, while the route weight allocated to the basic tag pool corresponding to the business tag is decreased. In response to a service resource operation type of scaling down, remove or reduce the route weight allocated to the public tag pool, and increase the route weight allocated to the basic tag pool corresponding to the business tag.
[0015] Optionally, the routing rule adjustment unit is further configured to: In response to the service resource operation type being expansion, the number of business requests allocated to the public tag pool is increased, and the number of business requests allocated to the basic tag pool corresponding to the business tag is decreased. In response to the service resource operation type being scale-down, the number of business requests allocated to the public tag pool is gradually reduced, while the number of business requests allocated to the basic tag pool corresponding to the business tag is increased.
[0016] Optionally, the allocation unit is further configured to: In response to an empty request source identifier or an empty business tag, the business request is assigned to a server container in the common tag pool.
[0017] Optionally, the preset threshold is determined as follows: Obtain the historical load assessment metrics values before and after capacity expansion corresponding to the business tags; The machine learning model outputs the optimal single-server container load assessment index value corresponding to the business label based on the load assessment index values before and after historical expansion, which serves as the preset threshold for the business label.
[0018] In addition, this application also provides a service resource processing electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the service resource processing method described above.
[0019] In addition, this application also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the service resource processing method described above.
[0020] To achieve the above objectives, according to another aspect of the embodiments of this application, a computer program product is provided.
[0021] A computer program product according to an embodiment of this application includes a computer program that, when executed by a processor, implements the service resource processing method provided in the embodiment of this application.
[0022] One embodiment of the above invention has the following advantages or beneficial effects: In response to receiving a business request, this application obtains the request source identifier from the business request; in response to the request source identifier being non-empty, it matches the corresponding business tag to the request source identifier; in response to the business tag being non-empty, it obtains the real-time load assessment index value corresponding to the business tag, and determines the service resource operation type for the business tag based on the load assessment index value and a preset threshold; it adjusts the routing rules for the basic tag pool and the public tag pool based on the service resource operation type, wherein the basic tag pool is configured with the minimum number of server containers to meet the off-peak business request processing needs corresponding to the business tag, and the public tag pool is configured with server containers not belonging to any specific business tag; and it allocates server containers to the business request according to the request source identifier, the business tag, and the adjusted routing rules. Based on the real-time load assessment index value and the request source identifier, it achieves real-time, accurate, dynamic, and automated fine-grained allocation of service resources, thereby maximizing resource utilization.
[0023] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description
[0024] The accompanying drawings are provided to better understand this application and do not constitute an undue limitation thereof. Wherein: Figure 1 This is a schematic diagram of the main flow of a service resource processing method according to an embodiment of this application; Figure 2 This is a schematic diagram of the main flow of a service resource processing method according to an embodiment of this application; Figure 3 This is a schematic diagram of the main flow of a service resource processing method according to an embodiment of this application; Figure 4 This is a schematic diagram illustrating the mixed deployment of a public tag pool and a basic tag pool corresponding to a business tag in a service resource processing method according to an embodiment of this application; Figure 5 This is a schematic diagram of the main units of a service resource processing apparatus according to an embodiment of this application; Figure 6 This is an exemplary system architecture diagram to which embodiments of this application can be applied; Figure 7 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers in the embodiments of this application. Detailed Implementation
[0025] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solutions of this application comply with relevant national laws and regulations. It should also be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions. The collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in the technical solutions of this application all comply with relevant laws and regulations, are used for legal and reasonable purposes, do not violate public order and good morals, are not shared, disclosed, or sold outside of these legal uses, and are subject to supervision and management by regulatory authorities. Necessary measures should be taken to prevent unauthorized access to user personal information, safeguard user personal information security, cybersecurity, and national security, and ensure that those authorized to access personal information comply with relevant laws and regulations. Once this user personal information is no longer needed, risks should be minimized by restricting or even prohibiting data collection and / or deleting the data.
[0026] When used, including in certain relevant applications, data is deidentified to protect user privacy, for example by removing specific identifiers, controlling the amount or specificity of stored data, controlling how data is stored, and / or other methods.
[0027] The following are explanations of some terms that may be used in this application: Containers: A lightweight, portable software packaging and runtime technology that packages applications and their dependencies together for rapid deployment in isolation from the environment.
[0028] Scaling up and down: refers to dynamically increasing (expanding) or decreasing (shrinking) the number of application instances based on changes in business load.
[0029] RPC: Remote Procedure Call. A computer communication protocol that allows a program running on one computer to call a subroutine on another computer; it is a core technology for building microservice architectures.
[0030] JSF: Java Service Framework, a distributed RPC framework used for efficient calls between services.
[0031] QPS: Queries Per Second, used to indirectly reflect or estimate real-time business traffic. It measures the number of requests a specific service processes per unit of time (per second) and is a core metric for measuring system throughput.
[0032] Tag routing: A microservice governance capability that distributes requests to server containers with specific tags based on request metadata (such as parameters and originating application) and preset routing rules.
[0033] JIMDB: A high-performance distributed caching database based on the Redis protocol, featuring high performance, high concurrency, and massive distributed capabilities.
[0034] Preset threshold: The critical value that must be reached to trigger a certain operation.
[0035] Graceful shutdown: Before terminating a service instance, it is deregistered from the service discovery component to stop accepting new requests. At the same time, it waits for all received requests to be processed before completely stopping the process to ensure uninterrupted service.
[0036] Serverless computing: A cloud computing execution model in which cloud service providers dynamically manage the allocation of machine resources. The logical scaling in this application achieves a similar effect.
[0037] Figure 1 This is a schematic diagram of the main flow of a service resource processing method according to an embodiment of this application, as shown below. Figure 1 As shown, the service resource processing method mainly includes the following steps S101-S105.
[0038] Step S101: In response to receiving a business request, obtain the request source identifier in the business request.
[0039] In this embodiment, when the execution subject of the service resource processing method (e.g., the server) receives a business request, it can obtain the request source identifier carried in the business request, such as request source identifier 1-1, request source identifier 1-2, request source identifier 2-1, request source identifier 2-2, ..., request source identifier n-1, request source identifier n-2.
[0040] Step S102: In response to the request source identifier being non-empty, match the corresponding business tag for the request source identifier.
[0041] Upon receiving a business request, the system first checks if the request carries a request source identifier. If it does, the identifier is not empty, and the system can match the corresponding business tag to the request source identifier based on a pre-configured mapping. For example, the request source identifiers might be Request Source Identifier 1-1, Request Source Identifier 1-2, Request Source Identifier 2-1, Request Source Identifier 2-2, ..., Request Source Identifier n-1, Request Source Identifier n-2. Request Source Identifier 1-1 and Request Source Identifier 1-2 match business tag 1; Request Source Identifier 2-1 and Request Source Identifier 2-2 match business tag 2; and Request Source Identifier n-1 and Request Source Identifier n-2 match business tag n. For example, business tag 1 could be a search tag, business tag 2 could be a recommendation tag, and business tag n could be an installment tag.
[0042] Step S103: In response to the business tag not being empty, obtain the real-time load assessment index value corresponding to the business tag, and determine the service resource operation type for the business tag based on the load assessment index value and the preset threshold.
[0043] If a business tag (e.g., business tag 1, business tag 2, ..., business tag n) corresponding to the request source identifier in the received business request can be found based on the pre-configured mapping relationship, then it is determined that the business tag is not empty. Real-time load assessment metric values (e.g., real-time total QPS for business tag 1, real-time total QPS for business tag 2, ..., real-time total QPS for business tag n) corresponding to the business tag (e.g., business tag 1, business tag 2, ..., business tag n) can be read from the high-performance distributed cache. Based on the load assessment metric values (e.g., real-time total QPS for business tag 1, real-time total QPS for business tag 2, ..., real-time total QPS for business tag n), the load assessment metric values (e.g., single-server container QPS) under the corresponding business tag are calculated and compared with a preset threshold. Based on the comparison result, the service resource operation type for the corresponding business tag is determined, such as scaling up or scaling down.
[0044] Specifically, the preset threshold is determined as follows: obtain the load assessment index values before and after historical expansion corresponding to the business tag; output the best single server container load assessment index value corresponding to the business tag based on the load assessment index values before and after historical expansion using a machine learning model, and use it as the preset threshold value corresponding to the business tag.
[0045] For example, the load assessment metrics for this business tag before and after scaling can be continuously recorded, such as QPS, RT (average response time), CPU, etc. The machine learning model can then automatically calibrate and update the optimal single-server container load assessment metrics for this business tag based on the recorded data, thereby enabling the machine learning model to evolve itself.
[0046] Step S104: Adjust the routing rules for the basic tag pool and the public tag pool based on the service resource operation type. The basic tag pool is configured with the minimum number of server containers that meet the off-peak business request processing needs corresponding to the business tags, while the public tag pool is configured with server containers that are not exclusive to any business tag.
[0047] Specifically, the routing rules for the basic tag pool and the public tag pool are adjusted based on the service resource operation type. This includes: adjusting the routing weights allocated to the public tag pool and the basic tag pool corresponding to the business tag based on the service resource operation type, for example, basic tag pool: 50% weight, public tag pool: 50% weight; or adjusting the number of business requests allocated to the public tag pool and the basic tag pool corresponding to the business tag based on the service resource operation type, for example, forcing 10% of business requests to be routed to the public tag pool and 90% of business requests to be routed to the basic tag pool corresponding to the business tag.
[0048] Specifically, the routing weights allocated to the public tag pool and the basic tag pool corresponding to the business tag are adjusted based on the service resource operation type. This includes: in response to a service resource operation type of scaling up, increasing the routing weight allocated to the public tag pool (e.g., from 0 to 50%) and decreasing the routing weight allocated to the basic tag pool corresponding to the business tag (e.g., from 100% to 50%); in response to a service resource operation type of scaling down, removing or decreasing the routing weight allocated to the public tag pool (e.g., adjusting the routing weight allocated to the public tag pool from 50% to 0), and increasing the routing weight allocated to the basic tag pool corresponding to the business tag (e.g., increasing the routing weight allocated to the basic tag pool corresponding to the business tag from 50% to 100%). This allows for the allocation of resources from the public tag pool to different business tags on demand for scaling up and down by adjusting routing rules, achieving serverless scaling and maximizing resource utilization.
[0049] Specifically, the number of business requests allocated to the public tag pool and the basic tag pool corresponding to the business tag is adjusted based on the service resource operation type. This includes: in response to the service resource operation type being expansion, increasing the number of business requests allocated to the public tag pool (e.g., gradually increasing from 0 to 10% of the total number of business requests, specifically from 0 to 3%, then to 6%, then to 9%, and finally to 10%), and decreasing the number of business requests allocated to the basic tag pool corresponding to the business tag (e.g., gradually decreasing from 100% to 90% of the total number of business requests, specifically from 100% to 97%, then to 94%, then to 91%, and finally to 10%). (90% of the total number of business requests); In response to the service resource operation type being scaling down, the number of business requests allocated to the public tag pool is gradually reduced (for example, gradually reduced from 10% of the total number of business requests to 0, specifically from 10% to 7%, then to 4%, then to 1%, and finally to 0, to achieve a smooth traffic transition), while the number of business requests allocated to the basic tag pool corresponding to the business tag is increased (for example, gradually increased from 90% to 100% of the total number of business requests, specifically from 90% to 93%, then to 96%, then to 99%, and finally to 100%, to achieve a smooth traffic transition).
[0050] Step S105: Allocate server containers for business requests based on the request source identifier, business tag, and adjusted routing rules.
[0051] Specifically, allocating server containers for business requests includes: in response to an empty request source identifier or an empty business tag, allocating the business request to a server container in a common tag pool.
[0052] When the request source identifier is empty or the business tag corresponding to the request source identifier is empty, the subsequent routing rule adjustment steps are not executed. Instead, the received business request is directly assigned to the server container in the public tag pool to obtain request processing as soon as possible, realize real-time decision-making, and improve the response speed of business requests.
[0053] If the request source identifier is not empty and the business tag corresponding to the request source identifier is not empty, the subsequent routing rule adjustment steps are executed. The received business requests can be reasonably allocated to the server container according to the adjusted routing rules for the basic tag pool and the public tag pool corresponding to the request source identifier and the business tag corresponding to the request source identifier.
[0054] This embodiment, in response to receiving a business request, obtains the request source identifier from the business request; in response to the request source identifier being non-empty, matches the corresponding business tag to the request source identifier; in response to the business tag being non-empty, obtains the real-time load assessment metric value corresponding to the business tag, and determines the service resource operation type for the business tag based on the load assessment metric value and a preset threshold; adjusts the routing rules for the basic tag pool and the public tag pool based on the service resource operation type, wherein the basic tag pool is configured with the minimum number of server containers to meet the off-peak business request processing needs corresponding to the business tag, and the public tag pool is configured with server containers not belonging to any specific business tag; and allocates server containers to the business request according to the request source identifier, the business tag, and the adjusted routing rules. Based on the real-time load assessment metric value and the request source identifier, real-time, accurate, dynamic, and automated fine-grained allocation of service resources is achieved, thereby maximizing resource utilization.
[0055] Figure 2 This is a schematic diagram of the main flow of a service resource processing method according to an embodiment of this application, such as... Figure 2 As shown, the service resource processing method mainly includes the following steps S201-S208.
[0056] Step S201: In response to receiving a business request, obtain the request source identifier in the business request.
[0057] Step S202: In response to the request source identifier being non-empty, match the corresponding business tag for the request source identifier.
[0058] For example, the following mapping relationships are configured: Request source identifier 1-1, Request source identifier 1-2, ..., Request source identifier 1-n are mapped to business label 1; Request source identifier 2-1, Request source identifier 2-2, ..., Request source identifier 2-n are mapped to business label 2; Request source identifier n-1, Request source identifier n-2, ..., Request source identifier nn are mapped to business label n.
[0059] The mapping relationship configured above can be used to match the corresponding business tag to the request source identifier in the received business request.
[0060] Step S203: In response to the business tag not being empty, obtain the real-time load assessment metric value corresponding to the business tag.
[0061] If a business tag (e.g., business tag 1, business tag 2, ..., business tag n) corresponding to the request source identifier in the received business request can be found based on the pre-configured mapping relationship, then it is determined that the business tag is not empty. The real-time load assessment metric value (e.g., real-time total QPS for business tag 1, real-time total QPS for business tag 2, ..., real-time total QPS for business tag n) corresponding to the business tag (e.g., business tag 1, business tag 2, ..., business tag n) can be read from the high-performance distributed cache.
[0062] Step S204: Determine the number of server containers configured in the basic tag pool corresponding to the business tag, and calculate the load assessment index value of a single server container based on the load assessment index value and the number.
[0063] A basic tag pool is configured for each business tag. For example, basic tag pool 1 is configured for business tag 1, and basic tag pool 1 contains the minimum number (e.g., 2) of server containers required to meet the off-peak business request processing needs corresponding to business tag 1; basic tag pool 2 is configured for business tag 2, and basic tag pool 2 contains the minimum number (e.g., 2) of server containers required to meet the off-peak business request processing needs corresponding to business tag 2; ...; basic tag pool n is configured for business tag n, and basic tag pool n contains the minimum number (e.g., 2) of server containers required to meet the off-peak business request processing needs corresponding to business tag n.
[0064] The ratio of the obtained load assessment metric value (e.g., real-time total QPS for business label 1, real-time total QPS for business label 2, ..., real-time total QPS for business label n) to the number of server containers configured in the basic label pool corresponding to the business label is calculated, and this ratio is determined as the load assessment metric value of a single server container under the corresponding business label (e.g., single server container QPS).
[0065] Step S205: In response to the single server container load assessment index value being greater than the first preset threshold, the service resource operation type for the business tag is determined to be expansion.
[0066] If the load assessment metric value of the single server container corresponding to the business tag corresponding to the obtained load assessment metric value (e.g., total QPS) is greater than the first preset threshold (e.g., 1000 QPS), then the service resource operation type for the business tag is determined to be expansion.
[0067] Step S206: In response to the single server container load assessment index value being less than the second preset threshold, determine that the server resource operation type for the business tag is scaling down, wherein the second preset threshold is less than the first preset threshold.
[0068] If the load assessment metric value (e.g., total QPS) of the obtained load assessment metric value (e.g., total QPS) is less than the second preset threshold (e.g., 500 QPS), then the service resource operation type for the business tag is determined to be expansion.
[0069] Step S207: Adjust the routing rules for the basic tag pool and the public tag pool based on the service resource operation type. The basic tag pool is configured with the minimum number of server containers that meet the off-peak business request processing needs corresponding to the business tags, while the public tag pool is configured with server containers that are not exclusive to any business tag.
[0070] The routing weights allocated to the public tag pool and the basic tag pool corresponding to the business tag are adjusted based on the service resource operation type. For example, the basic tag pool has a weight of 50%, and the public tag pool has a weight of 50%. Alternatively, the number of business requests allocated to the public tag pool and the basic tag pool corresponding to the business tag are adjusted based on the service resource operation type. For example, 10% of the business requests are forcibly routed to the public tag pool, and 90% of the business requests are routed to the basic tag pool corresponding to the business tag.
[0071] Step S208: Allocate server containers for business requests based on the request source identifier, business tag, and adjusted routing rules.
[0072] If the request source identifier is not empty and the corresponding business tag is not empty, the subsequent routing rule adjustment steps are executed. Based on the adjusted routing rules for the basic tag pool and the common tag pool corresponding to the request source identifier and its corresponding business tag, the received business requests are appropriately distributed to the server containers. Based on real-time load assessment metrics and the request source identifier, real-time, accurate, dynamic, and automated fine-grained allocation of service resources is achieved, thereby maximizing resource utilization.
[0073] Figure 3 This is a schematic diagram of the main flow of a service resource processing method according to an embodiment of this application. Figure 3As shown, in response to receiving a business request, the execution entity obtains the request source identifier from the business request; if the request source identifier is not empty, it matches the corresponding business tag for the request source identifier; if the matched business tag is not empty, it obtains the real-time load assessment metric value corresponding to the business tag (e.g., QPS, used to indirectly reflect or estimate real-time business traffic; request queue length; average response time, etc., one or more), and determines the service resource operation type (e.g., scaling up or scaling down) for the business tag based on the load assessment metric value and the preset threshold corresponding to the business tag; it adjusts the routing rules for the basic tag pool and the public tag pool corresponding to the business tag based on the service resource operation type, wherein the basic tag pool is configured with the minimum number of server containers to meet the off-peak business request processing needs corresponding to the business tag, and the public tag pool is configured with server containers that are not exclusive to any business tag; and it allocates server containers for the business request according to the request source identifier, the business tag, and the adjusted routing rules.
[0074] Figure 4 This is a schematic diagram illustrating the mixed deployment of a public tag pool and a basic tag pool corresponding to business tags in a service resource processing method according to an embodiment of this application. Figure 4As shown, when multiple business requests arrive simultaneously, the request source identifiers from the multiple business requests are obtained. Based on the pre-configured mapping relationship between request source identifiers and business tags (for example, request source identifier 1-1, request source identifier 1-2, ..., request source identifier 1-n are mapped to business tag 1; request source identifier 2-1, request source identifier 2-2, ..., request source identifier 2-n are mapped to business tag 2; request source identifier n-1, request source identifier n-2, ..., request source identifier nn are mapped to business tag n), the corresponding business tags are matched for the obtained request source identifiers from the multiple business requests (for example, request source identifier 1-1, request source identifier 1-2, request source identifier 2-1, request source identifier 2-2, ..., request source identifier n-1, request source identifier n-2). For example, request source identifiers 1-1 and 1-2 match business tag 1; request source identifiers 2-1 and 2-2 match business tag 2; and request source identifiers n-1 and n-2 match business tag n. Furthermore, a basic tag pool is configured for each business tag. For instance, basic tag pool 1 is configured for business tag 1, containing the minimum number (e.g., 2) of server containers needed to handle off-peak business requests corresponding to business tag 1; basic tag pool 2 is configured for business tag 2, containing the minimum number (e.g., 2) of server containers needed to handle off-peak business requests corresponding to business tag 2; and so on; basic tag pool n is configured for business tag n, containing the minimum number (e.g., 2) of server containers needed to handle off-peak business requests corresponding to business tag n. In addition, a common tag pool is configured, which includes all server containers other than those configured in the basic tag pools (e.g., ...). Figure 4 As shown, the server containers configured in the public tag pool are only examples; the actual number of server containers configured may be more than that. Figure 4 The number of server containers shown in the diagram is configured in a public tag pool. The public tag pool is a dynamic, shared pool of backup service resources that does not belong to any specific business tag. When a business request arrives, the server containers in the corresponding basic tag pool are used first. Only when a business tag experiences a surge in business requests will the server containers in the public tag pool be temporarily lent to that business tag by adjusting the routing rules, in order to help handle the business requests that the business tag cannot handle and maximize the utilization of service resources.
[0075] This application addresses scenarios where business requests exhibit tidal characteristics and diverse sources. Based on real-time business traffic (which can be indirectly reflected or estimated using QPS) and the business tags of the call source, it achieves precise, dynamic, and automated scheduling of server resources, thereby maximizing service resource utilization. Specifically, this application dynamically scales up and down service resources based on Remote Procedure Call (RPC) tag routing and real-time load assessment metrics (e.g., QPS) statistics. This allows it to serve all request sources (i.e., callers). By combining tag routing functionality with refined load assessment metrics (e.g., QPS statistics), it achieves dynamic scaling of the service provider. The specific implementation steps are as follows: For example, service grouping and tagging (resource pooling): To maximize resource utilization, a hybrid deployment approach of "basic tag pool + public tag pool" is adopted. First, define business tags: Different business tags can be defined based on business lines, callers, or interface types. For example, server containers can be divided into tags such as search, recommendation, and installment. Each tag corresponds to a logical server container group used to handle requests from a specific source. Secondly, allocate basic capacity and build a basic tag pool: allocate the minimum number of server containers to each business tag to meet its daily off-peak business request processing needs. For example, allocate 2 containers to the search tag and put them into the basic tag pool corresponding to the search tag; allocate 2 containers to the recommendation tag and put them into the basic tag pool corresponding to the recommendation tag; allocate 2 containers to the installment tag and put them into the basic tag pool corresponding to the installment tag. These are the service resources to ensure the basic operation of each business. Then, build a public tag pool: mark all other server resources (i.e., server containers) as public tags. This public tag pool is a dynamic, shared backup resource pool that does not belong to any specific business tag. The goal is to prioritize the use of resources in each "basic tag pool". Only when a business tag experiences a traffic surge (i.e., a business request surge) will resources in the public tag pool be dynamically lent to that business tag by adjusting the routing rules. Real-time load assessment metrics (e.g., QPS) statistics based on business tags: In order to perceive the real-time load of each business tag (i.e., corresponding to each business line), high-performance, low-latency statistics are required. For example, to collect QPS data: Deploy a QPS collector to listen for RPC calls. When requests from caller A and caller B pass through the RPC framework, the collector parses the request source identifier in the request parameters, such as the systemKey (e.g., the system identifier). Aggregate and store data by business tag: The collector matches the parsed systemKey (e.g., the system identifier) with a pre-configured mapping (e.g., systemKey=100x). (Mapped to search tags). Then, in a high-performance distributed cache, the current total QPS value is accumulated and stored in real time, with the search tag (i.e., a business tag) as the dimension. For example, a high-performance distributed cache would record real-time data such as search tag: 23 QPS, recommendation tag: 53 QPS. Utilizing the high-performance characteristics of the high-performance distributed cache, it can support large-scale, high-concurrency real-time counting requirements. Dynamic scheduling decision and execution: For example, the dynamic scheduling controller periodically reads the real-time load assessment index value (e.g., QPS) of each business tag from the high-performance distributed cache and makes decisions in combination with preset strategies. Preset strategy: A high-load expansion threshold (i.e., the preset threshold of this application) is set for each business tag (such as the search tag). For example, it is usually represented by the optimal single-server container load assessment index value corresponding to the business tag, such as the target QPS capacity of a single server container under the business tag. For example, the target QPS capacity of a single server container for the search tag is set to 1000 QPS. The scaling threshold for the entire search tag is calculated as: number of server containers configured for the current search tag × 1000 QPS. Real-time decision-making: For example, the controller reads the current total real-time QPS of the search tag from a high-performance distributed cache, for example, 2500 QPS. It then obtains the number of server containers currently configured for the search tag, for example, 2. The current single-server container load assessment metric is calculated as: 2500 QPS / 2 = 1250 QPS > 1000 QPS (preset threshold). Dynamic scaling execution (traffic scheduling): When the search tag load is determined to be too high, new server containers are not immediately created; instead, routing rules are modified. Specifically, the dynamic scheduling controller can notify the routing rule engine to add or modify a routing rule (e.g., increase the routing weight pointing to the public tag pool): When the systemKey (e.g., system identifier) of a business request matches a search tag, some business requests are allocated to server containers in the original search tag's basic tag pool, and other business requests are allocated to server containers in the public tag pool. Subsequent business requests from search tags will be distributed according to the new routing rules (e.g., basic tag pool: 50% weight, public tag pool: 50% weight). This effectively "temporarily expands" the server containers in the public tag pool for use by the corresponding business requests for search tags. Dynamic scaling down (resource reclamation): When a low-traffic period arrives, for example, the total QPS of search tags drops to 1000 QPS, and the load assessment metric of a single server container drops to 500 QPS. Once the controller detects the decrease and subsequent stabilization of the single server container load assessment metric, it notifies the routing rule engine to remove or reduce the route weight pointing to the public tag pool. The server resources in the public tag pool are released and returned to the public tag pool, waiting to provide scaling services for other business tags experiencing a surge in business requests.Throughout the process, no server containers were created or destroyed; instead, logical scaling of computing resources was achieved through dynamic adjustments to tag routes. This enabled smooth transitions and graceful shutdowns: Traffic smoothing: When adjusting route weights, a gradual approach was adopted, such as progressively switching traffic back to the basic tag pool over several minutes to avoid traffic fluctuations. Graceful shutdown: When deciding to scale down a server container in the public tag pool from business requests corresponding to search tags, the route weight assigned to the public tag pool was first reduced to 0 at the routing level, ensuring that new business requests were no longer sent to the server container in that public tag pool. After a period of time (waiting for existing business requests to complete), the server container automatically returned to the public tag pool. The entire process was completely transparent to the request source (i.e., the caller).
[0076] This application's technical solution implements a fine-grained QPS statistics and dynamic scheduling mechanism based on business tags, refining monitoring granularity to the business tag level. By parsing the request source identifier (e.g., systemKey, specifically a system identifier) in RPC business requests, it utilizes a high-performance distributed cache to aggregate QPS in real time by business tag, thereby accurately perceiving the real-time load pressure of each subdivided business line. It achieves a hybrid deployment based on a "basic tag pool + public tag pool" and serverless scaling through tag routing. A guaranteed "basic tag pool" is allocated to each business tag, while elastic resources are uniformly placed in the "public tag pool." The core of scaling is no longer "creating / destroying containers," but rather dynamically modifying RPC tag routing rules to dynamically and temporarily "lend" server container resources in the public tag pool to high-load businesses. This method achieves resource scaling at the second level, avoiding the latency and overhead of physical server container startup and shutdown. By dynamically adjusting RPC tag routing rules, it realizes a scaling method that allocates resources from the public tag pool to different business tags on demand. A closed-loop control system is implemented based on real-time business tag QPS and preset threshold judgment, and routing weight adjustment. A complete feedback loop is constructed: QPS is counted by business tag → the average load assessment index value of the tag group is calculated → compared with the preset threshold → the decision to adjust the routing weight pointing to the public tag pool is made → business requests are allocated according to the new routing rules → QPS is recounted. This closed loop directly affects the traffic scheduling layer, realizing real-time response to changes in business load.
[0077] In this application, in addition to the systemKey (e.g., system identifier), statistics and business tagging can be performed based on finer-grained dimensions such as interface method name, caller application ID, or even user ID hash, enabling more refined resource isolation and scheduling. Besides statistically analyzing real-time business tag QPS, load assessment metrics such as request queue length and average response time (RT) can be combined to comprehensively determine the load on a single server container. For example, only when QPS exceeds a threshold and RT also increases significantly is it considered a true overload, triggering scaling. When adjusting routing rules, for example, when the QPS of a search tag > a preset threshold, 10% of business requests can be forcibly routed to the public tag pool. For non-RPC scenarios (such as HTTP calls), dynamic DNS service discovery components (such as Nacos, Consul) can be used to dynamically register server containers in the public tag pool to the list of server containers corresponding to the search tag, achieving a similar scaling effect. Local aggregation + remote storage can also be implemented: local QPS aggregation can be performed based on each business tag, and then periodically reported to the central controller, reducing write pressure on the central storage. It can also continuously record data such as QPS, RT, and CPU for different business tags before and after expansion, and automatically calibrate and update the optimal single-server container load assessment index value for each business tag through machine learning models, thereby realizing the self-evolution of machine learning models.
[0078] Figure 5 This is a schematic diagram of the main units of a service resource processing apparatus according to an embodiment of this application. Figure 5 As shown, the service resource processing device 500 includes an acquisition unit 501, a service tag matching unit 502, an operation type determination unit 503, a routing rule adjustment unit 504, and an allocation unit 505.
[0079] The acquisition unit 501 is configured to acquire the request source identifier in the business request in response to receiving a business request.
[0080] The business tag matching unit 502 is configured to match the corresponding business tag to the request source identifier in response to the request source identifier being non-empty.
[0081] The operation type determination unit 503 is configured to, in response to a non-empty business tag, obtain the real-time load assessment index value corresponding to the business tag, and determine the service resource operation type for the business tag based on the load assessment index value and a preset threshold.
[0082] The routing rule adjustment unit 504 is configured to adjust the routing rules for the basic tag pool and the public tag pool based on the service resource operation type. The basic tag pool is configured with the minimum number of server containers that meet the off-peak business request processing requirements corresponding to the business tags, while the public tag pool is configured with server containers that are not exclusive to any business tag.
[0083] Allocation unit 505 is configured to allocate server containers for business requests based on the request source identifier, business tag, and adjusted routing rules.
[0084] In some embodiments, the operation type determination unit 503 is further configured to: determine the number of server containers configured in the basic tag pool corresponding to the service tag, and calculate the load assessment index value of a single server container based on the load assessment index value and the number; in response to the load assessment index value of a single server container being greater than a first preset threshold, determine that the service resource operation type for the service tag is expansion; in response to the load assessment index value of a single server container being less than a second preset threshold, determine that the server resource operation type for the service tag is reduction; wherein, the second preset threshold is less than the first preset threshold.
[0085] In some embodiments, the routing rule adjustment unit 504 is further configured to: adjust the routing weights allocated to the basic tag pools corresponding to the public tag pool and the business tag based on the service resource operation type; or adjust the number of business requests allocated to the basic tag pools corresponding to the public tag pool and the business tag based on the service resource operation type.
[0086] In some embodiments, the routing rule adjustment unit 504 is further configured to: in response to a service resource operation type of expansion, increase the routing weight allocated to the public label pool and decrease the routing weight allocated to the basic label pool corresponding to the service label; in response to a service resource operation type of shrinkage, remove or decrease the routing weight allocated to the public label pool and increase the routing weight allocated to the basic label pool corresponding to the service label.
[0087] In some embodiments, the routing rule adjustment unit 504 is further configured to: in response to the service resource operation type being expansion, increase the number of service requests allocated to the public label pool and decrease the number of service requests allocated to the basic label pool corresponding to the service label; in response to the service resource operation type being shrinkage, progressively decrease the number of service requests allocated to the public label pool and increase the number of service requests allocated to the basic label pool corresponding to the service label.
[0088] In some embodiments, the allocation unit 505 is further configured to: allocate the service request to a server container in the public tag pool in response to the request source identifier being empty or the service tag being empty.
[0089] In some embodiments, the preset threshold is determined as follows: obtain the load assessment index values before and after historical expansion corresponding to the business tag; output the best single server container load assessment index value corresponding to the business tag based on the load assessment index values before and after historical expansion using a machine learning model, and use it as the preset threshold value corresponding to the business tag.
[0090] It should be noted that the service resource processing method and service resource processing device in this application are related in terms of specific implementation content, so repeated content will not be described again.
[0091] Figure 6 An exemplary system architecture 600 is shown that can be applied to the service resource processing method or service resource processing apparatus of the embodiments of this application.
[0092] like Figure 6 As shown, system architecture 600 may include terminal devices 601, 602, and 603, a network 604, and a server 605. Network 604 serves as the medium for providing communication links between terminal devices 601, 602, and 603 and server 605. Network 604 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.
[0093] Users can use terminal devices 601, 602, and 603 to interact with server 605 via network 604 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 601, 602, and 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).
[0094] Terminal devices 601, 602, and 603 can be various electronic devices with service resource processing screens and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.
[0095] Server 605 can be a server providing various services, such as a backend management server supporting business requests submitted by users using terminal devices 601, 602, and 603 (this is just an example). The backend management server can respond to a received business request by obtaining the request source identifier from the request; if the request source identifier is not empty, it matches the corresponding business tag to the request source identifier; if the business tag is not empty, it obtains the real-time load assessment metric value corresponding to the business tag, and determines the service resource operation type for the business tag based on the load assessment metric value and a preset threshold; it adjusts the routing rules for the basic tag pool and the public tag pool based on the service resource operation type, where the basic tag pool is configured with the minimum number of server containers to meet the off-peak business request processing needs corresponding to the business tag, and the public tag pool is configured with server containers not specific to any business tag; and it allocates server containers to the business request according to the request source identifier, the business tag, and the adjusted routing rules. Based on the real-time load assessment metric value and the request source identifier, it achieves real-time, accurate, dynamic, and automated fine-grained allocation of service resources, thereby maximizing resource utilization.
[0096] It should be noted that the service resource processing method provided in this application embodiment is generally executed by server 605, and correspondingly, the service resource processing device is generally set in server 605.
[0097] It should be understood that Figure 6 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.
[0098] The following is for reference. Figure 7 It shows a schematic diagram of the structure of a computer system 700 suitable for implementing a terminal device according to the embodiments of this application. Figure 7 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0099] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the computer system 700. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.
[0100] The following components are connected to I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 710 as needed so that computer programs read from it can be installed into storage section 708 as needed.
[0101] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs the functions defined above in the system of this application.
[0102] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0104] The units described in the embodiments of this application can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including an acquisition unit, a service label matching unit, an operation type determination unit, a routing rule adjustment unit, and an allocation unit. The names of these units do not necessarily limit the specific unit itself.
[0105] In another aspect, this application also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to, in response to receiving a service request, obtain a request source identifier from the service request; in response to the request source identifier being non-empty, match a corresponding service tag for the request source identifier; in response to the service tag being non-empty, obtain a real-time load assessment index value corresponding to the service tag, and determine the service resource operation type for the service tag based on the load assessment index value and a preset threshold; adjust the routing rules for the basic tag pool and the public tag pool based on the service resource operation type, wherein the basic tag pool is configured with a minimum number of server containers to meet the off-peak service request processing needs corresponding to the service tag, and the public tag pool is configured with server containers not belonging to any specific service tag; and allocate server containers for the service request according to the request source identifier, the service tag, and the adjusted routing rules.
[0106] The computer program product of this application includes a computer program that, when executed by a processor, implements the service resource processing method in the embodiments of this application.
[0107] According to the technical solution of this application embodiment, based on real-time load assessment index values and request source identifiers, real-time, accurate, dynamic, and automated fine allocation of service resources is achieved, thereby maximizing resource utilization.
[0108] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A service resource processing method, characterized by, include: In response to receiving a service request, obtain the request source identifier in the service request; In response to the request source identifier being non-empty, a corresponding business tag is matched for the request source identifier; In response to the fact that the service tag is not empty, the real-time load assessment index value corresponding to the service tag is obtained, and the service resource operation type for the service tag is determined based on the load assessment index value and a preset threshold. The routing rules for the basic tag pool and the public tag pool are adjusted based on the service resource operation type. The basic tag pool is configured with the minimum number of server containers to meet the off-peak service request processing needs corresponding to the service tag. The public tag pool is configured with server containers that are not exclusive to any service tag. Based on the request source identifier, the service tag, and the adjusted routing rules, a server container is allocated for the service request.
2. The method according to claim 1, characterized in that, The process of determining the service resource operation type for the business tag based on the load assessment metric value and a preset threshold includes: Determine the number of server containers configured in the basic tag pool corresponding to the business tag, and calculate the load assessment index value of a single server container based on the load assessment index value and the number. In response to the single server container load assessment index value being greater than a first preset threshold, the service resource operation type for the business tag is determined to be expansion; In response to the fact that the single server container load assessment index value is less than the second preset threshold, the server resource operation type for the business tag is determined to be scaling down; Wherein, the second preset threshold is less than the first preset threshold.
3. The method according to claim 1, characterized in that, The adjustment of routing rules for the basic tag pool and the public tag pool based on the service resource operation type includes: The routing weights are adjusted based on the service resource operation type to the public tag pool and the basic tag pool corresponding to the service tag; or The number of service requests allocated based on the service resource operation type is adjusted to the number allocated to the public tag pool and the basic tag pool corresponding to the service tag.
4. The method according to claim 3, characterized in that, The routing weights allocated based on the service resource operation type to the public tag pool and the basic tag pool corresponding to the service tag include: In response to the service resource operation type being expansion, the routing weight allocated to the public tag pool is increased, and the routing weight allocated to the basic tag pool corresponding to the service tag is decreased. In response to the service resource operation type being scaling down, the route weight allocated to the public tag pool is removed or reduced, and the route weight allocated to the basic tag pool corresponding to the service tag is increased.
5. The method according to claim 3, characterized in that, The number of service requests allocated based on the service resource operation type to the public tag pool and the basic tag pool corresponding to the service tag includes: In response to the service resource operation type being expansion, the number of service requests allocated to the public tag pool is increased, and the number of service requests allocated to the basic tag pool corresponding to the service tag is decreased. In response to the service resource operation type being scaling down, the number of service requests allocated to the public tag pool is gradually reduced, while the number of service requests allocated to the basic tag pool corresponding to the service tag is increased.
6. The method according to claim 1, characterized in that, The process of allocating a server container for the service request includes: In response to the request source identifier being empty or the business tag being empty, the business request is assigned to a server container in the public tag pool.
7. The method according to claim 1, characterized in that, The preset threshold is determined in the following way: Obtain the historical load assessment index values before and after capacity expansion corresponding to the business tag; The machine learning model outputs the optimal single-server container load assessment index value corresponding to the business label based on the load assessment index values before and after the historical expansion, and uses it as the preset threshold corresponding to the business label.
8. A service resource processing device, characterized in that, include: The acquisition unit is configured to acquire the request source identifier in the business request in response to receiving a business request; The business tag matching unit is configured to match the corresponding business tag for the request source identifier in response to the request source identifier being non-empty. The operation type determination unit is configured to, in response to the business tag not being empty, obtain the real-time load assessment index value corresponding to the business tag, and determine the service resource operation type for the business tag based on the load assessment index value and a preset threshold. The routing rule adjustment unit is configured to adjust the routing rules for the basic tag pool and the public tag pool based on the service resource operation type. The basic tag pool is configured with a minimum number of server containers to meet the off-peak service request processing needs corresponding to the service tag. The public tag pool is configured with server containers that are not exclusive to any service tag. The allocation unit is configured to allocate a server container for the service request based on the request source identifier, the service tag, and the adjusted routing rules.
9. A service resource processing electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.
10. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.
11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.