WO2017143981A1 - 服务处理 - Google Patents

服务处理 Download PDF

Info

Publication number
WO2017143981A1
WO2017143981A1 PCT/CN2017/074371 CN2017074371W WO2017143981A1 WO 2017143981 A1 WO2017143981 A1 WO 2017143981A1 CN 2017074371 W CN2017074371 W CN 2017074371W WO 2017143981 A1 WO2017143981 A1 WO 2017143981A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
request
cloud
scheduling
cloud resource
Prior art date
Application number
PCT/CN2017/074371
Other languages
English (en)
French (fr)
Inventor
金小艇
王伟
Original Assignee
新华三技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 新华三技术有限公司 filed Critical 新华三技术有限公司
Publication of WO2017143981A1 publication Critical patent/WO2017143981A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Definitions

  • Cloud computing can take advantage of the high-speed transmission capabilities of the Internet, transfer data processing from personal computers or private servers to large cloud computing centers, and provide computing and storage capabilities to users in a service-oriented manner. Users can purchase and use cloud computing related services. As a cloud computing tenant, businesses or individuals can customize cloud services that meet their daily needs. However, when some enterprises engage in activities or major holidays, the number of corporate visits will increase significantly. This short-term concentrated burst traffic may exceed the processing capacity of the customized cloud services, resulting in network congestion.
  • 1 is a cloud service architecture model in one example in accordance with the present disclosure.
  • FIG. 2 is a flow chart of a service processing method in an example according to the present disclosure.
  • FIG. 3 is a schematic diagram of type identification in an example in accordance with the present disclosure.
  • 4A is a hardware configuration diagram of a service processing device in an example according to the present disclosure.
  • 4B is a flow chart of service processing in an example in accordance with the present disclosure.
  • FIG. 1 illustrates a cloud service architecture model in one example in accordance with the present disclosure.
  • an enterprise can place its own services in the cloud service computing center 11.
  • the cloud service computing center 11 can provide the cloud resource selected for use by the user.
  • the cloud resource may include a storage resource (eg, a memory), a computing resource (eg, a CPU), and the like, and the cloud resource may be provided by a server 12, a server 13, or the like.
  • the user group of the enterprise can access the cloud service computing center 11 through a personal computer or a mobile terminal to obtain the service provided by the enterprise.
  • Figure 1 illustrates only four terminals 14 through 17, which may be more in an actual scenario.
  • the cloud service computing center 11 acts as a service provider for the enterprise and can handle many service requests of the enterprise. For example, when a user accesses an e-commerce website for shopping through a computer, the cloud service computing center 11 can receive an access request from the user, and can process the access according to the service application of the e-commerce arrangement in the cloud service computing center 11. The request, for example, can feed the user's website page of the website.
  • differentiated services can be provided according to different user requirements, and the service response capability of important customers is preferentially guaranteed. For example, when a company does activities or major holidays, when sudden bursts of access traffic increase significantly, priority is given to ensuring that important customer visits are responded in a timely manner; even in normal visits, important customers are given more resources.
  • the cloud service computing center of the example of the present disclosure will perform the following service processing method.
  • the traffic of the service can be distinguished, and the access request of the important customer is distinguished from the access request of the ordinary customer.
  • the method of distinguishing may be determined according to the service characteristics of the enterprise, for example, it may be classified according to a user type (User-type) or a service type (Service-type).
  • an enterprise can set a type A user as a VIP user and a type B user as a normal user.
  • the service request of the received VIP user may be referred to as a "target type” service request; the received service request of the ordinary user may be referred to as a "non-target type”. Service request.
  • the non-target type service request may be sacrificed to preferentially guarantee the target type of service request.
  • the tenant can allocate the cloud resource proportion according to the service request type of the tenant.
  • the service request type may be represented by the type of the user or the type of service requested by the user.
  • Table 1 below exemplifies the resource usage of different service request types by taking the user type as an example.
  • Table 2 exemplifies the resource usage of different service request types by taking the service type as an example.
  • the division of such service request types and the allocation of cloud resource occupancy ratios may be referred to as service scheduling rules.
  • the service scheduling rule can be pre-configured in the cloud service computing center 11, and the tenant can modify the service according to the service characteristics during the service operation.
  • VIP user type User-type1
  • VIP User-type2
  • VP User-type3
  • 4 Resource occupation 45% 35%
  • the proportion of each type of resource may refer to the proportion of the cloud resources purchased by the enterprise to each type of service. For example, for a service of a user of type User-type 1, 45% of the cloud resources can be allocated.
  • VIP Service type Service-type1
  • VIP Service-type2
  • VIP Service-type3
  • Service-type4 Resource occupation 45% 35% 10%
  • the above service scheduling rules can be used as a basis for subsequent scheduling processing of service requests. For example, suppose that a certain number of service requests are received, including four types, Service-type1 and Service-type2. If these services are requested to be randomly scheduled, the VIP service cannot be preferentially responded. It is likely that the large amount of processing of non-VIP services will cause the response speed of the VIP service to decrease when short-term traffic spikes occur. If the service scheduling rules are used, the difference is made in the scheduling process. A relatively large proportion of the cloud resources are used for the service processing of the VIP service, and the priority response of the VIP service can be ensured.
  • the target type and the non-target type can be distinguished by different tags.
  • the target type can be distinguished by adding a "VIP" tag.
  • the priority of each type decreases from left to right.
  • the resource occupancy ratio can be reduced one by one to give priority to the corresponding type.
  • the levels match.
  • the service response speed of the target type service may not be guaranteed, because the cloud resource corresponding to the target type service may be used by multiple users. Therefore, as far as possible, the unit resource occupancy of the target type service is higher than the unit resource occupancy of the non-target type service, so as to ensure the target The priority response of the standard type service.
  • the user type in Table 1 is used as an example to obtain the number of users corresponding to each user type, and calculate the per capita resource occupancy rate according to the number of users.
  • the number may be an estimated number of users corresponding to the type of service, or user statistics obtained by querying the user database.
  • VIP user type User-type1
  • VIP User-type2
  • VP User-type3
  • the per capita resource occupancy rate of the VIP user type is higher than the per capita resource occupancy rate of the common user type. If the per-capita resource usage of the VIP user type is lower than that of the common user type, you can modify the allocation of each type of cloud resources until the per-capita resource usage rate of the high-priority user type is high.
  • the per capita resource occupancy rate of each target type (eg, VIP) is guaranteed to be higher than each non-target.
  • the per capita resource allocation between each target type or the per capita resource allocation between each non-target type may be not limited, and the enterprise may adjust according to its own service experience. .
  • the per capita resource occupancy rate of V1 may be higher than V2, or the per capita resource occupancy rate of V2 may be higher than V1; for example, if the priority of VIP type V1 is higher than V2, then Set the per capita resource occupancy rate of V1 to be higher than V2.
  • the cloud service computing center may perform service processing according to the service scheduling rule.
  • the service processing may include the following steps.
  • step 201 the types of different service requests, including the target type and the non-target type, can be identified.
  • a cloud service computing center when a cloud service computing center receives a service request, it can identify the type of the request. Taking the type shown in Table 1 as an example, it is possible to identify which of User-type 1 to User-type 4 the service request belongs to.
  • the received service request may carry a username.
  • the cloud service computing center can pre-store the correspondence between the user name and the user type. In this way, when receiving the service request, the cloud service computing center can determine the corresponding user type according to the user name in the request. For example, the user who sent the service request is a user type belonging to User-type1. Or, serve The identification of the type of the request may also be based on the correspondence, but based on the predetermined rules. For example, the characteristics of each type of service request may be determined. For example, the feature may be a source address and a source port of the packet, etc. The message type is identified according to the feature.
  • the service request may be added to a request queue corresponding to the identified type.
  • the service request can be added to the request queue 2, waiting to schedule the service request. Perform service processing.
  • a service request of a different request queue may be scheduled according to a service scheduling rule, where the service scheduling rule is used to limit a cloud resource occupation ratio allocated for different types of service requests, so that the target type of service is enabled.
  • the requested unit resource occupancy is higher than the unit resource occupancy of the non-target type service request.
  • the cloud service computing center may perform scheduling processing on the received various types of service requests, for example, may report the requested webpage information to the user terminal for display according to the service request.
  • the cloud service computing center can perform service scheduling according to the service scheduling rule. For example, in one scheduling, each type of service request is read by four request queues (actually reading information carried by the service request to respond to the service request according to the information), and in each queue The ratio between the number of requests read is consistent with the proportion of cloud resources occupied in the service scheduling rules.
  • the proportion of cloud resources occupied by different types of requests can be made different.
  • the request of the important target type occupies more cloud resources for processing, so that the target type request can get a faster response, and the service of the target important traffic is preferentially guaranteed.
  • this example can use the same cloud service purchased, handle both the target type service and the non-target type service, and ensure that the target service is prioritized and the cost is relatively low.
  • the ratio is scheduled. For example, during the peak period, it can be processed according to the ratio defined in the pre-configured service scheduling rules. In the peak traffic period, the proportions defined in the pre-configured service scheduling rules can be adjusted to reduce the non-target type.
  • the occupation ratio is given to prioritize the resource occupancy of the target type, so as to better reflect the priority of the target type.
  • the service processing apparatus 400 can include a processor 401, a non-volatile storage medium 402, a communication interface 403, and an engagement mechanism 404 that joins the processor 401, the non-volatile storage medium 402, and the communication interface 403.
  • a plurality of machine readable instruction modules corresponding to the service processing control logic executed by the processor 401 are stored in the non-volatile storage medium 402.
  • the machine readable instruction module may include: a type identification module 41, a queue management module 43, a user management module 44, a resource management module 45, and a monitoring module 46.
  • a user may access a service disposed in a cloud service computing center through a browser or an APP, and the type identification module 41 may receive a service request from the user.
  • the service request may include information such as a username and password, and the type identification module 41 may extract the username and password in the service request and send the username to the authentication server 42.
  • the authentication server 42 may return a password corresponding to the username and a user type according to the username, for example, the type of the user is User-type 3.
  • the user type corresponding to the authentication server identification service request is taken as an example.
  • the service type or other type may be returned to the type identification module 41.
  • the specific type returned can be determined according to the pre-configured service scheduling rules. If the service scheduling rules are divided by user type, the authentication server 42 can identify the type of user corresponding to a certain service request. If the service scheduling rules are divided by the service type, the authentication server 42 can identify the service type corresponding to a certain service request.
  • the method of identification may be, for example, storing the correspondence between the user name and the user type in the authentication server 42 in advance to identify the type of the service request according to the user name. Alternatively, the predetermined identification rule may be stored in advance, and the type of the corresponding service request is determined according to the feature information carried in the service request.
  • the type identification module 41 can compare the password with the password carried in the service request. If they are not the same, the authentication fails, and the subsequent processing of the service request is abandoned. If the two passwords are the same, the authentication is passed, and the service request and the user type returned by the authentication server 42 are sent to the queue management module 43.
  • the user management module 44 can be queried for the type division in the service scheduling rule, and the corresponding request queue is started according to the type division.
  • the pre-configured service scheduling rules may be stored in the user management module 44, assuming that the four user types of the example shown in Table 1 are determined, the user management module 44 may notify the queue management module 43 of the four user types, the queue. Management module 43 then initiates four request queues. As shown in FIG. 4B, the four request queues respectively correspond to four user types. For example, the request queue 1 corresponds to User-type1, and the request queue 2 corresponds to User-type2.
  • the queue management module 43 may Add a service request to the request queue for the corresponding user type. For example, if the identified user type is User-type1, then the service request is added to request queue 1. Therefore, the queue management module 43 implements queue division for individual service requests.
  • the resource management module 45 can read the service request from each request queue and add the request to the processing queue.
  • the service processing process will continuously read the service request from the processing queue, and use the cloud resource to perform service processing on the service request in the processing queue.
  • the service scheduling rule defines the scheduling ratio of a certain type of service traffic in the tenant's service.
  • the cloud service computing center may add a different number of service requests from each request queue to the processing queue according to the proportion of cloud resource occupation of different request queues defined in the service scheduling rule.
  • the entire cloud resource of the tenant may be used for service processing, which makes the service processing more efficient.
  • different scheduling ratios can achieve different service traffic processing efficiency, and services with a larger scheduling ratio can be processed faster and more.
  • the target type of service request can be queued before the non-target type service request to process the target type of service more quickly.
  • the resource management module 45 can perform multiple rounds of scheduling when reading a service request. For example, in one schedule, a portion of the service requests can be added to the processing queue by each of the four request queues. Then, the second scheduling can be performed, and then each of the four request queues is read and added to the processing queue. Repeat this process until all request queues are empty.
  • the read mode of each round of scheduling (for example, the number of requests read from each request queue each time) may be the same, and the processing of the round scheduling of the resource management module 45 is explained as follows.
  • the resource management module 45 can perform scheduling processing according to three factors: cloud resource usage efficiency, scheduling processing unit, and service scheduling rule.
  • the service scheduling rules are described in the foregoing examples and will not be described in detail.
  • the cloud resource usage efficiency can be understood, for example, as the ratio of the cloud resources currently used to the total purchased cloud resources, and the value may be between 0 and 100%.
  • the cloud resource usage efficiency can represent the system load of the current cloud resource. For example, if the current cloud resource usage efficiency is 85%, it means that the system processing capacity is busy; if the current cloud resource usage efficiency is 60%, it means that the system has more processing capacity and is relatively idle.
  • the scheduling processing unit can indicate the number of service requests processed at one time. For example, the scheduling processing unit may process one service request at a time; or, according to the processing capability of the cloud service system, adjust the scheduling processing unit to process multiple service requests at a time, so that the system processing capability matches the processing granularity.
  • cloud resource usage efficiency represented by R
  • scheduling processing unit represented by min
  • the resource management module 45 can obtain these two parameters from the monitoring module 46 and can obtain service scheduling rules from the user management module 44.
  • both the target type of service request and the non-target type of service request can be processed, but it is necessary to ensure that the target type service request can be compared.
  • More resources occupy rights. For example, taking the resource occupation according to the user type shown in Table 1 as an example, all the resource occupation ratios can be rounded up to obtain Table 4.
  • Table 4 finds the resource occupation after the whole
  • the remaining cloud resources can be divided into 100 parts, each of which can be used as a scheduling processing unit for processing min service requests, which is equivalent to one scheduling process for 100*min users.
  • the ratio shown in Table 4 45 service requests are read by the queue corresponding to User-type1, and 35 service requests are read by the queue corresponding to User-type2, respectively, in the queue corresponding to User-type3 and User-type4.
  • we can continue to calculate the greatest common divisor of these ratios based on Table 4, and calculate the minimum number of users who can read the queue strictly according to the allocation ratio according to the greatest common divisor 5, 100/5 20, get Table 5:
  • each time the scheduling can read the service request from different request queues according to the cloud resource occupancy ratio and the scheduling processing unit defined in the service scheduling rule.
  • the number of service requests read for different request queues at each scheduling corresponds to the product of the cloud resource occupancy ratio and the scheduling processing unit corresponding to the request queue.
  • the number of service requests read for different request queues at each scheduling is equal to the product of the cloud resource occupancy ratio and the scheduling processing unit corresponding to the request queue.
  • the resource management module 45 can read 9*min users from the request queue 1 to join the processing queue at one time, and then read 7*min users from the request queue 2 to join the processing queue after reading, and finish reading.
  • 2*min users are read from the request queue 3 to join the processing queue, and then 2*min users are added from the request queue 4 to the processing queue, so that the round scheduling of the resource management module 45 is completed, and the operation is repeated subsequently.
  • the above reading manner is such that the number of service requests read by different request queues is consistent with the allocation of the cloud resource occupancy ratio. If a queue is polled, the queue is skipped directly, and the proportion of other queues is unchanged. Alternatively, the allocation of the cloud resource occupancy ratio can be re-adjusted between the remaining queues other than the empty queue. The scheduling of the service is performed according to the adjusted allocation ratio.
  • the resource management module 45 can also calculate the scale shown in Table 5. Different from the previous example, the resource management module 45 in the present example can also update the service scheduling rule by reducing the cloud resource occupancy ratio of the non-target type service request defined in the service scheduling rule. For example, set the resource usage ratio of non-VIP user types to zero, as shown in Table 6:
  • the resource occupancy ratio of the common users (User-type 3 and User-type 4) is set to zero, which is only an example. In practice, there may be other multiple manners, for example, only a part of ordinary users may be reduced.
  • the proportion of resources occupied for example, the proportion of User-type3 is 0, and the proportion of User-type4 is still 2; for example, the proportion of User-type3 and User-type4 can be adjusted from 2 to 1, etc. .
  • the resource management module 45 will always read the service request in the VIP queue to the processing queue.
  • different types of service requests may be configured to process different cloud resource proportions, and the unit resource occupancy of the target type request is higher than the unit resource occupancy of the non-target type. In this way, it is possible to prioritize the processing of the target service. This method not only achieves priority service to important traffic of the target, but also has lower cost.
  • the disclosed apparatus and method may be implemented in other manners.
  • the device examples described above are merely illustrative, for example, the division of the cells is just one logic Functional division, there may be additional divisions in actual implementation, for example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some communication interface, device or unit, and may be electrical, mechanical or otherwise.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present example.
  • each functional unit in the example of the present disclosure may be integrated in one processing unit, or each unit may exist physically separately, or two or more units may be integrated in one unit.
  • the functional unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a machine readable storage medium.
  • a machine readable storage medium including several The instructions are for causing a machine device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in the various examples of the present disclosure.
  • the foregoing storage medium includes: a USB disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like, which can store program code. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

在一个示例中，提供一种服务处理方法和装置。根据该方法，云服务计算中心识别不同服务请求的类型，所述类型包括：目标类型和非目标类型；将所述服务请求，分别添加到所识别出类型对应的请求队列；根据服务调度规则，对不同请求队列的服务请求进行调度处理，其中，所述服务调度规则用于限定为不同类型服务请求分配的云资源占用比例，使得目标类型服务请求的单位资源占用量高于非目标类型服务请求的单位资源占用量。

Description

服务处理
相关申请的交叉引用
本专利申请要求2016年2月26日提交的、申请号为201610111382.4、发明名称为“一种业务处理方法和装置”的中国专利申请的优先权，该申请的全文以引用的方式并入本文中。
背景技术
云计算可利用互联网的高速传输能力，将数据的处理过程从个人计算机或私有服务器转移到大型的云计算中心，并可将计算能力、存储能力以服务的方式为用户提供。用户能够购买和使用云计算相关的服务。作为云计算的租户，企业或个人可以定制符合日常需求的云服务。但是在一些企业搞活动或者重大节假日的时候，企业访问客流量会大量增加，这种短期集中的突发流量可能会超过所定制的云服务的处理能力，产生网络拥塞。
附图说明
图1是根据本公开的一个例子中的云服务架构模型。
图2是根据本公开的一个例子中的服务处理方法的流程图。
图3是根据本公开的一个例子中的类型识别示意图。
图4A是根据本公开的一个例子中的服务处理装置的硬件结构图。
图4B是根据本公开的一个例子中的服务处理的流程图。
具体实施方式
为了解决短期高峰流量的问题再购买额外更多的云服务，对于租户来说成本较大不经济，因为原有购买的云服务的处理能力对于平峰时期还是能够满足需求。因此，可以基于客户优先级，优先保证重要客户的用户体验，这可以称为保证重要流量的优先响应服务。为了实现该目的，有的租户单独为重要客户购买一套云服务，与普通用户分开服务，这种方式虽然简单，但是成本较高。
图1示例了根据本公开的一个例子中的云服务架构模型。如图1所示，企业可将自己的服务布置在云服务计算中心11。该云服务计算中心11可以提供给用户选择使用的云资源， 例如，云资源可以包括存储资源(如，内存)、计算资源(如，CPU)等，这些云资源可以由服务器12、服务器13等设备提供。该企业的用户群体可以通过个人电脑或者移动终端等访问云服务计算中心11来获取该企业提供的服务。图1仅示例了四台终端14至17，实际场景中可以更多。
云服务计算中心11作为企业的服务提供者，可处理该企业的诸多服务请求。例如，当用户通过电脑访问某个电商网站进行购物时，云服务计算中心11可接收来自用户的访问请求，并可根据该电商布置在云服务计算中心11的服务应用，来处理该访问请求，比如，可向用户反馈该网站的网站页面。
在企业的用户群体中，不同的用户对服务处理能力的实时性要求不同。采用本公开提供的服务处理方法，能够根据不同用户需求提供差别化服务，优先保障重要客户的服务响应能力。例如，当企业做活动或者重大节假日，出现突发的访问流量大幅增加时，优先保证重要客户的访问及时得到响应；即使在平时的访问中，也给予重要客户较多的资源占用权。
本公开示例的云服务计算中心将执行如下服务处理方法。以某个企业的服务访问为例，可以对服务的流量进行区分，将重要客户的访问请求，与普通客户的访问请求区别开来。区分的方式可以根据企业的服务特点来确定，例如，可以按照用户类型(User-type)或者服务类型(Service-type)来划分。
例如，企业可以将A类型的用户设置为VIP用户，将B类型的用户设置为普通用户。本例子中，对于云服务计算中心11来说，可以将接收到的VIP用户的服务请求称为“目标类型”的服务请求；可以将接收到的普通用户的服务请求称为“非目标类型”的服务请求。在企业购买的云服务能力不足时，可以牺牲该非目标类型的服务请求来优先保障目标类型的服务请求。
又例如，企业也可以经营有多种类型的服务，包括重要的服务和普通服务。对于重要服务的流量需要优先保证服务响应，即优先处理上述的“目标类型”的服务请求。对于非重要的普通服务流量，要为重要服务的处理作出让步，即暂缓处理上述的“非目标类型”的服务请求。
租户在购买云服务计算中心11的云资源后，可以根据该租户的服务请求类型为其分配占用的云资源比例。该服务请求类型可以由用户的类型或者该用户所请求服务的服务类型来表示。例如，如下表1示例了以用户类型为例区分不同服务请求类型的资源占用，表2示例了以服务类型为例区分不同服务请求类型的资源占用。
这种服务请求类型的划分以及云资源占用比例的分配，可以称为服务调度规则。该服务调度规则可以预先配置在云服务计算中心11，并且租户可以在服务运作过程中根据服务特点进行修正。
表1各用户类型的资源占用
用户类型 User-type1(VIP) User-type2(VIP) User-type3 User-type4
资源占用 45％ 35％ 10％ 10％
如上的表1所示，包括两种目标类型的重要用户，User-type1和User-type2，还包括两种非目标类型的普通用户User-type3和User-type4。实际应用中，目标类型和非目标类型对应的种类可以有多种。各个类型的资源占用比例，可以指将企业所购买的云资源分配给各个类型的服务的比例。例如，针对类型为User-type1的用户的服务，可分配45％的云资源。
表2各服务类型的资源占用
服务类型 Service-type1(VIP) Service-type2(VIP) Service-type3 Service-type4
资源占用 45％ 35％ 10％ 10％
上述的服务调度规则，可以作为后续对服务请求进行调度处理的依据。例如，假设接收到了一定数量的服务请求，其中包括Service-type1、Service-type2等四个类型。如果对这些服务请求平等的进行随机调度，VIP服务无法被优先响应，很可能出现短期流量突增时非VIP服务的大量处理导致VIP服务的响应速度降低。而如果按照上述服务调度规则，在调度处理时就加以区别，相对较多比例的云资源用于VIP服务的服务处理，将可以保证VIP服务的优先响应。
该服务调度规则在配置时，目标类型与非目标类型可以用不同的标记加以区分。例如，在上述的表1和表2中，目标类型可以附加“VIP”标记进行区别。还可以将各个类型按照优先级的顺序进行排列，例如，以表2为例，各个类型的优先级从左到右逐次下降，相应的，资源占用比例也可以逐次降低，以与对应类型的优先级相匹配。
本例子中，即使设置目标类型的服务占用较多的云资源比例，也不一定能够保证目标类型服务的服务响应速度，因为该目标类型服务对应的云资源可能被多个使用者使用。由此，尽可能使目标类型服务的单位资源占用量高于非目标类型服务的单位资源占用量，以保证目 标类型服务的优先响应。
例如，以表1的用户类型划分为例，可以获取各个用户类型对应的用户数量，并根据用户数量计算人均资源占用率。例如，该数量可以是预估的对应本类型服务的用户数量，或者是由用户数据库查询得到的用户统计数据。
表3人均资源计算结果
用户类型 User-type1(VIP) User-type2(VIP) User-type3 User-type4
资源占用 45％ 35％ 10％ 10％
用户数量 2000 1000 2000 3000
人均资源 0.0225％ 0.035％ 0.005％ 0.0033％
由表3可以看到，VIP用户类型的人均资源占用率高于普通用户类型的人均资源占用率。如果经过计算发现VIP用户类型的人均资源占用率低于普通用户类型的人均资源占用率，可以提示对各个类型的云资源分配进行修正，直至高优先级的用户类型的人均资源占用率较高。
此外，在存在多个目标类型和多个非目标类型(例如，表3有两种type的VIP)的情况下，在保证各个目标类型(如，VIP)的人均资源占用率高于各个非目标类型(如，非VIP)的人均资源占用率的基础上，各个目标类型之间的人均资源分配或者各个非目标类型之间的人均资源分配可以不做限制，企业可以根据自己的服务经验进行调整。例如，VIP类型V1和V2同等重要时，可以V1的人均资源占用率高于V2，也可以V2的人均资源占用率高于V1；又例如，如果VIP类型V1的优先级高于V2，那么可以设置V1的人均资源占用率高于V2。
在配置上述的服务调度规则后，云服务计算中心可以根据该服务调度规则进行服务处理，参见图2所示，服务处理可以包括如下步骤。
在步骤201中，可识别不同服务请求的类型，包括目标类型和非目标类型。
例如，云服务计算中心在接收到一个服务请求时，可以识别该请求的类型。以表1所示的类型划分为例，可以识别服务请求属于User-type1至User-type4中的哪一个。
本步骤中，接收的服务请求可以携带用户名。云服务计算中心可以预先存储用户名与用户类型的对应关系。这样云服务计算中心在接收到服务请求时，可以根据请求中的用户名确定对应的用户类型。例如，发送该服务请求的用户是属于User-type1的用户类型。或者，服 务请求的类型的识别也可以不是依据对应关系，而是根据预定规则进行区分。比如，可确定各个类型的服务请求具有的特征，例如，该特征可以是报文的源地址和源端口等.根据特征识别报文类型。
在步骤202中，可将所述服务请求，分别添加到与所识别类型对应的请求队列。
例如，在识别到服务请求的类型后，可以将其添加到对应该类型的请求队列。参见图3的示例，假设有四个请求队列，如果在步骤201中识别到接收到的服务请求的类型是User-type2，则可将该服务请求添加到请求队列2中，等待调度该服务请求进行服务处理。
在步骤203中，可根据服务调度规则，对不同请求队列的服务请求进行调度处理，其中，所述服务调度规则用于限定为不同类型的服务请求分配的云资源占用比例，使得目标类型的服务请求的单位资源占用量高于非目标类型的服务请求的单位资源占用量。
例如，云服务计算中心可对接收到的各种类型的服务请求进行调度处理，比如可以是根据该服务请求将请求的网页信息反馈至用户终端进行展示。本步骤中，云服务计算中心可以根据服务调度规则进行服务调度。比如可以是，在一次调度中，分别由四个请求队列中读取各个类型的服务请求(实际上是读取该服务请求携带的信息，以根据该信息响应服务请求)，并且，各个队列中读取的请求数量之间的比例与服务调度规则中的云资源占用比例一致。
比如，以表1为例，可以从User-type1对应的请求队列1中读取9个服务请求，从User-type2对应的请求队列2中读取7个服务请求，从User-type3对应的请求队列3中读取2个服务请求，从User-type4对应的请求队列4中读取2个服务请求。以这种方式，完成一轮调度，下一次调度时仍然按照如上方式读取。可以看到，一次调度中这四个请求队列读取的请求数量的比例为：9:7:2:2，这与表1所示的各个类型的资源占用比例是相同的，45:35:10:10＝9:7:2:2。
通过根据服务调度规则进行服务请求的调度处理，可以使得不同类型的请求占用的云资源比例不同。重要的目标类型的请求占用更多的云资源进行处理，从而使得目标类型请求能够得到更快的响应，优先保证目标重要流量的服务。相对于为重要客户单独购买一套云服务来说，本例子可以使用购买的同一套云服务，既处理目标类型服务也处理非目标类型服务，并保证目标服务的优先处理，成本相对较低。
在另一个例子中，在保证目标类型请求的单位资源占用量高于非目标类型请求的单位资源占用量的基础上，不同的应用场景下，还可以对不同类型的请求按照不同的云资源占用比例进行调度。例如，在平峰时期，可以根据预先配置的服务调度规则中限定的比例处理。而在高峰流量时期，可以对预先配置的服务调度规则中限定的比例进行调整，降低非目标类型 的占用比例，以优先保证目标类型的资源占用，从而更好的体现目标类型的优先性。
根据本公开的示例，提出一种服务处理装置400。参见图4A，该服务处理装置400可包括处理器401、非易失性存储介质402、通信接口403和将处理器401、非易失性存储介质402和通信接口403接合的接合机构404。非易失性存储介质402中存储有由处理器401执行的对应于服务处理控制逻辑的多个机器可读指令模块。所述机器可读指令模块可包括：类型识别模块41、队列管理模块43、用户管理模块44、资源管理模块45、监控模块46。
如下结合图4B来对各个模块的功能进行说明。
参见图4B的示例，例如，用户可以通过浏览器或者APP访问布置在云服务计算中心的服务，类型识别模块41可以接收到用户的服务请求。该服务请求中可以包括用户名和密码等信息，类型识别模块41可以提取服务请求中的用户名和密码，并将用户名发送至认证服务器42。认证服务器42可根据用户名，返回与该用户名对应的密码、以及用户类型，例如，该用户的类型是User-type 3。
本例子中，以认证服务器识别服务请求对应的用户类型为例，当然在其他的示例中，还可以是将服务类型或其他类型返回给类型识别模块41。具体返回何种类型，可以根据预先配置的服务调度规则确定。如果服务调度规则是以用户类型划分，那么认证服务器42可以识别某个服务请求对应的用户类型。如果服务调度规则是以服务类型划分，认证服务器42可以识别某个服务请求对应的服务类型。识别的方法可以是，例如，预先在认证服务器42存储用户名与用户类型的对应关系，以根据用户名识别服务请求的类型。或者，可以预先存储预定的识别规则，根据服务请求中携带的特征信息确定对应的服务请求的类型。
类型识别模块41在接收到认证服务器42返回的密码和用户类型后，可以将该密码与服务请求中携带的密码进行比较。如果不相同，则认证不通过，放弃对该服务请求的后续处理。如果两个密码相同，则认证通过，并可将该服务请求以及认证服务器42返回的用户类型，一并送至队列管理模块43。
队列管理模块43启动后可向用户管理模块44查询服务调度规则中的类型划分情况，并根据类型划分启动对应的请求队列。例如，预先配置的服务调度规则，可以是存储在用户管理模块44，假设确定了表1所示例的四个用户类型，用户管理模块44可以将这四个用户类型通知给队列管理模块43，队列管理模块43则启动四个请求队列。如图4B所示例，四个请求队列分别对应四个用户类型，比如，请求队列1对应User-type1，请求队列2对应User-type2。
队列管理模块43在接收到类型识别模块41发送的服务请求及对应的用户类型后，可以 将服务请求添加到对应该用户类型的请求队列。例如，如果识别到的用户类型是User-type1，则将该服务请求添加到请求队列1。因此，队列管理模块43实现了对各个服务请求的队列划分。
资源管理模块45可以由各个请求队列中读取服务请求，并将该请求添加到处理队列。服务处理进程将不断的从该处理队列中读取服务请求，使用云资源对该处理队列中的服务请求进行服务处理。以云服务计算中心的某个租户的服务处理为例，服务调度规则限定的是该租户的服务中某种类型服务流量的调度比例。云服务计算中心可以根据服务调度规则中限定的不同请求队列的云资源占用比例，由各个请求队列中读取不同数量的服务请求添加到处理队列。而在对处理队列进行服务处理时，可以是使用该租户的整体云资源进行服务处理，这种方式使得服务处理的效率较高。并且，调度比例的不同可以实现不同的服务流量处理的效率不同，调度比例较大的服务将可以更快更多的得到处理。此外，在处理队列中排列服务请求时，可以将目标类型的服务请求排在非目标类型的服务请求之前，以更快的处理目标类型的服务。
资源管理模块45在读取服务请求时，可以进行多轮调度。例如，在一次调度中，可分别由四个请求队列中各读取一部分服务请求添加到处理队列。接着可进行第二次调度，再分别由四个请求队列中各读取一部分服务请求添加到处理队列。重复该过程直至所有的请求队列为空。每一轮调度的读取方式(例如，每次从各个请求队列分别读取请求的数量)可以是相同的，如下说明资源管理模块45一轮调度的处理。
例如，资源管理模块45可以根据如下三个因素进行调度处理：云资源使用效率、调度处理单位和服务调度规则。其中，服务调度规则参见前述例子，不再详述。云资源使用效率例如可以理解为当前已经使用的云资源占整体购买的云资源的比例，取值可以在0至100％之间。云资源使用效率可以表示当前云资源的系统负荷。比如，如果当前云资源使用效率是85％，表示系统处理能力繁忙；如果当前云资源使用效率是60％，表示系统处理能力剩余较多，相对比较空闲。
调度处理单位可以表示一次处理的服务请求的数量。例如，该调度处理单位可以是一次处理一个服务请求；或者，还可以根据云服务系统的处理能力，将调度处理单位调整为一次处理多个服务请求，使得系统处理能力与处理粒度匹配。本示例中，云资源使用效率(以R表示)和调度处理单位(以min表示)，可以由监控模块46进行监控获得。资源管理模块45可以从监控模块46获取这两个参数，并可以从用户管理模块44获取服务调度规则。
资源管理模块45可以预设一个阈值，并将由监控模块46得到的云资源使用效率R与该 阈值比较，以判定当前系统的负荷状态。例如，假设该预设阈值是80％，如果R<＝80％，说明系统处理能力剩余较多，如果R>80％，说明系统处理繁忙。
在一个示例中，当R<＝80％，系统处理能力剩余较多时，这种情况下可以既处理目标类型的服务请求也处理非目标类型的服务请求，不过需要确保目标类型服务请求可以有较多的资源占用权利。例如，以表1所示的按照用户类型划分的资源占用为例，可以将所有资源占用比例求整，得到表4。
表4求整后的资源占用
用户类型 User-type1(VIP) User-type2(VIP) User-type3 User-type4
资源占用 45 35 10 10
根据如上的表4，可以将剩余的云资源分成100份，每一份作为一个调度处理单位可以用于处理min个服务请求，相当于一次调度处理100*min个用户。可以按照表4所示的比例，由User-type1对应的队列读取45个服务请求，由User-type2对应的队列读取35个服务请求，分别由User-type3和User-type4对应的队列中读取10个服务请求，完成一次服务调度。但是为了更加精细化的处理，还可以在表4的基础上继续计算这些比例的最大公约数，并根据最大公约数5计算最小的能严格按照分配比例进行队列读取的用户数，100/5＝20，得到表5：
表5精简后的资源占用
用户类型 User-type1(VIP) User-type2(VIP) User-type3 User-type4
资源占用 9 7 2 2
根据表5，每一次调度时可根据服务调度规则中限定的云资源占用比例和调度处理单位从不同的请求队列中读取服务请求。在一示例中，每一次调度时针对不同的请求队列读取的服务请求的数量，与该请求队列对应的云资源占用比例和调度处理单位的乘积相对应。在另一示例中，每一次调度时针对不同的请求队列读取的服务请求的数量，与该请求队列对应的云资源占用比例和调度处理单位的乘积相等。如表5所示，资源管理模块45可以一次从请求队列1读取9*min个用户加入到处理队列，读完之后再从请求队列2读取7*min个用户加入到处理队列，读完后再从请求队列3读取2*min个用户加入处理队列，然后再从请求队列4读取2*min个用户加入处理队列，这样资源管理模块45的一轮调度完成，后续重复这个操作。 上述的读取方式，使得由不同的请求队列中读取的服务请求的数量符合云资源占用比例的分配。如果轮询到某个队列为空，则直接跳过该队列，其他队列的比例不变；或者，还可以在为空的队列之外的剩余队列之间，重新调整云资源占用比例的分配，并按照调整后的分配比例进行服务的调度处理。
在另一个示例中，当R>80％，系统处理繁忙时，这种情况下云资源系统负荷较重，可能负荷已经超出了系统服务能力。此时可以优先保证目标类型的服务请求的处理，可以放弃非目标类型的服务请求来实现上述目的。该示例中，资源管理模块45同样可以计算得到表5所示的比例。与上一个示例不同的是，本例子中的资源管理模块45还可以通过降低服务调度规则中限定的非目标类型的服务请求的云资源占用比例来更新服务调度规则。例如，将非VIP用户类型的资源占用比例设置为零，如表6：
表6调整后的资源占用
用户类型 User-type1-VIP User-type2-VIP User-type3 User-type4
资源占用 9 7 0 0
上述表6中，将普通用户(User-type3和User-type4)的资源占用比例设置为零，只是一种示例，实际实施中还可以有其他多种方式，例如，可以只降低部分普通用户的资源占用比例，比如，User-type3所占比例为0，User-type4所占比例仍为2；又比如，还可以将User-type3和User-type4的所占比例都由2调整为1，等。当采用表6所示的方式时，即普通用户此时得不到调度，资源管理模块45将一直读取VIP队列中的服务请求到处理队列。
通过降低非目标类型服务请求的调度比例，可以将尽可能多的云资源都用于目标类型服务请求的处理，从而优先保证目标类型的服务。资源管理模块45还可以不断监控从监控模块46获得的云资源使用效率R，当R<＝80％时，即系统负荷又重新降低时，资源管理模块45可以重置服务调度规则，将表6又重新恢复至表5，按照表5读取请求队列。服务处理进程将不断从处理队列读取服务请求进行服务处理，直至服务处理完成。
本示例的服务处理方法，可以将不同类型的服务请求配置不同的云资源比例进行处理，且目标类型请求的单位资源占用量高于非目标类型的单位资源占用量。这样，可以使得优先保证目标服务的处理执行。该方式不仅实现了对目标重要流量的优先服务，而且成本较低。
在本公开所提供的几个示例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。以上所描述的装置示例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑 功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本示例方案的目的。
另外，在本公开示例的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个机器可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台机器设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个示例所述方法的全部或部分步骤。而前述的存储介质包括：USB盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅为本公开的示例而已，并不用以限制本公开，凡在本公开的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本公开保护的范围之内。

Claims (15)

  1. 一种服务处理方法，包括：
    云服务计算中心识别不同服务请求的类型，所述类型包括目标类型和非目标类型；
    所述云服务计算中心将所述服务请求，分别添加到所识别出类型对应的请求队列；
    所述云服务计算中心根据服务调度规则，对不同请求队列的服务请求进行调度处理，
    其中，所述服务调度规则用于限定为不同类型的服务请求分配的云资源占用比例，使得目标类型服务请求的单位资源占用量高于非目标类型服务请求的单位资源占用量。
  2. 根据权利要求1所述的方法，其中，所述根据服务调度规则，对不同请求队列的服务请求进行调度处理，包括：
    所述云服务计算中心获取云资源使用效率，所述云资源使用效率表示云资源的系统负荷；
    在所述云资源使用效率低于预设阈值的情况下，
    所述云服务计算中心根据所述服务调度规则中限定的云资源占用比例，对不同请求队列的服务请求进行调度处理。
  3. 根据权利要求1所述的方法，其中，所述根据服务调度规则，对不同请求队列的服务请求进行调度处理，包括：
    所述云服务计算中心获取云资源使用效率，所述云资源使用效率表示云资源的系统负荷；
    在所述云资源使用效率高于预设阈值的情况下，
    所述云服务计算中心通过将所述服务调度规则中限定的非目标类型服务请求的云资源占用比例降低来更新所述服务调度规则，并根据更新的服务调度规则，对不同请求队列的服务请求进行调度处理。
  4. 根据权利要求3所述的方法，其中，所述将所述服务调度规则中限定的非目标类型服务请求的云资源占用比例降低，包括：
    所述云服务计算中心将所述非目标类型服务请求的云资源占用比例设置为零。
  5. 根据权利要求1所述的方法，其中，所述对不同请求队列的服务请求进行调度处理，包括：
    所述云服务计算中心获取调度处理单位，所述调度处理单位表示一次处理的服务请求的数量；
    所述云服务计算中心根据所述服务调度规则中限定的云资源占用比例和所述调度处理单位，从不同请求队列中读取服务请求；
    所述云服务计算中心将读取的服务请求放入处理队列，并使用云资源对所述处理队列中 的服务请求进行处理。
  6. 一种服务处理装置，包括：
    类型识别模块，用于识别不同服务请求的类型，所述类型包括：目标类型和非目标类型；
    队列管理模块，用于将所述服务请求，分别添加到所识别出类型对应的请求队列；
    资源管理模块，用于根据服务调度规则，对不同请求队列的服务请求进行调度处理，
    其中，所述服务调度规则用于限定为不同类型的服务请求分配的云资源占用比例，使得目标类型服务请求的单位资源占用量高于非目标类型服务请求的单位资源占用量。
  7. 根据权利要求6所述的装置，还包括：
    监控模块，用于监控云资源使用效率，所述云资源使用效率表示云资源的系统负荷；以及
    用户管理模块，用于存储所述服务调度规则；
    其中，所述资源管理模块还从所述监控模块获取云资源使用效率，并在所述云资源使用效率低于预设阈值时，根据所述服务调度规则中限定的云资源占用比例，对不同请求队列的服务请求进行调度处理。
  8. 根据权利要求7所述的装置，其中，
    所述资源管理模块还在所述云资源使用效率高于预设阈值时，通过将所述服务调度规则中限定的非目标类型服务请求的云资源占用比例降低来更新所述服务调度规则，并根据更新的服务调度规则，对不同请求队列的服务请求进行调度处理。
  9. 根据权利要求8所述的装置，其中，所述非目标类型服务请求的云资源占用比例设置为零。
  10. 根据权利要求7所述的装置，其中，
    所述资源管理模块还从所述监控模块获取调度处理单位，所述调度处理单位表示一次处理的服务请求的数量；
    所述资源管理模块根据所述服务调度规则中限定的云资源占用比例和所述调度处理单位从不同请求队列中读取服务请求；
    所述资源管理模块将读取的服务请求放入处理队列，并使用云资源对所述处理队列中的服务请求进行处理。
  11. 一种服务处理装置，包括处理器以及存储有用于服务控制逻辑的机器可执行指令的非暂时性存储介质，通过执行所述机器可执行指令，所述处理器被使得：
    识别不同服务请求的类型，所述类型包括：目标类型和非目标类型；
    将所述服务请求，分别添加到所识别出类型对应的请求队列；
    根据服务调度规则对不同请求队列的服务请求进行调度处理，
    其中，所述服务调度规则用于限定为不同类型的服务请求分配的云资源占用比例，使得目标类型服务请求的单位资源占用量高于非目标类型服务请求的单位资源占用量。
  12. 根据权利要求11所述的服务处理装置，其中，在根据服务调度规则对不同请求队列的服务请求进行调度处理时，通过执行所述机器可执行指令，所述处理器还被使得：
    获取云资源使用效率，所述云资源使用效率表示云资源的系统负荷；
    在所述云资源使用效率低于预设阈值的情况下，根据所述服务调度规则中限定的云资源占用比例对不同请求队列的服务请求进行调度处理。
  13. 根据权利要求11所述的服务处理装置，其中，在根据服务调度规则对不同请求队列的服务请求进行调度处理时，通过执行所述机器可执行指令，所述处理器还被使得：
    获取云资源使用效率，所述云资源使用效率表示云资源的系统负荷；
    在所述云资源使用效率高于预设阈值的情况下，
    通过将所述服务调度规则中限定的非目标类型服务请求的云资源占用比例降低来更新所述服务调度规则，并根据更新的服务调度规则对不同请求队列的服务请求进行调度处理。
  14. 根据权利要求13所述的方法，其中，在将所述服务调度规则中限定的非目标类型服务请求的云资源占用比例降低时，通过执行所述机器可执行指令，所述处理器还被使得：
    将所述非目标类型服务请求的云资源占用比例设置为零。
  15. 根据权利要求11所述的方法，其中，在对不同请求队列的服务请求进行调度处理时，通过执行所述机器可执行指令，所述处理器还被使得：
    获取调度处理单位，所述调度处理单位表示一次处理的服务请求的数量；
    根据所述服务调度规则中限定的云资源占用比例和所述调度处理单位从不同请求队列中读取服务请求；
    将读取的服务请求，放入处理队列，并使用云资源对所述处理队列中的服务请求进行处理。
PCT/CN2017/074371 2016-02-26 2017-02-22 服务处理 WO2017143981A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610111382.4 2016-02-26
CN201610111382.4A CN107135241A (zh) 2016-02-26 2016-02-26 一种业务处理方法和装置

Publications (1)

Publication Number Publication Date
WO2017143981A1 true WO2017143981A1 (zh) 2017-08-31

Family

ID=59685850

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/074371 WO2017143981A1 (zh) 2016-02-26 2017-02-22 服务处理

Country Status (2)

Country Link
CN (1) CN107135241A (zh)
WO (1) WO2017143981A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107888660A (zh) * 2017-10-13 2018-04-06 杭州朗和科技有限公司 云服务资源调配方法、介质、装置和计算设备
CN107948095A (zh) * 2017-11-21 2018-04-20 中国银行股份有限公司 一种资源控制方法、装置及总线系统服务器
CN112231146A (zh) * 2020-10-22 2021-01-15 浪潮云信息技术股份公司 基于cinder-backup的备份服务质量的实现方法、存储介质
CN112988390A (zh) * 2021-03-22 2021-06-18 上海超级计算中心 一种算力资源分配方法及装置

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108768886A (zh) * 2018-05-30 2018-11-06 无锡知更鸟网络科技有限公司 一种SaaS数据访问质量提升方法
CN109634754A (zh) * 2018-11-14 2019-04-16 彩讯科技股份有限公司 一种业务投递方法、装置、设备及计算机存储介质
CN109684092B (zh) * 2018-12-24 2023-03-10 新华三大数据技术有限公司 资源分配方法及装置
CN109857595A (zh) * 2019-02-28 2019-06-07 新华三信息安全技术有限公司 一种备份存储空间分配方法和装置
CN112667392B (zh) * 2020-12-09 2024-01-23 南方电网数字电网研究院有限公司 云计算资源分配方法、装置、计算机设备和存储介质
CN113395291B (zh) * 2021-06-30 2023-03-17 北京爱奇艺科技有限公司 流量控制方法、装置、电子设备及存储介质
CN113535360B (zh) * 2021-07-23 2023-07-28 中国科学技术大学苏州高等研究院 软件定义云中基于租户粒度的请求调度方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103369041A (zh) * 2013-07-09 2013-10-23 北京奇虎科技有限公司 基于云计算的资源分配方法及装置
CN103713956A (zh) * 2014-01-06 2014-04-09 山东大学 应用于云计算虚拟化管理环境中的智能加权负载均衡方法
US20140115598A1 (en) * 2012-10-24 2014-04-24 Dell Products L.P. System and method for controlled sharing of consumable resources in a computer cluster

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103220797B (zh) * 2006-07-27 2016-08-03 华为技术有限公司 一种调度传输资源的方法和系统
CN103179048B (zh) * 2011-12-21 2016-04-13 中国电信股份有限公司 云数据中心的主机QoS策略变换方法及系统
CN104053183B (zh) * 2014-05-07 2017-11-24 华东师范大学 一种lte系统的网络资源管理方法
CN105117284B (zh) * 2015-09-09 2020-09-25 厦门雅迅网络股份有限公司 一种基于优先级比例队列的工作线程的调度方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140115598A1 (en) * 2012-10-24 2014-04-24 Dell Products L.P. System and method for controlled sharing of consumable resources in a computer cluster
CN103369041A (zh) * 2013-07-09 2013-10-23 北京奇虎科技有限公司 基于云计算的资源分配方法及装置
CN103713956A (zh) * 2014-01-06 2014-04-09 山东大学 应用于云计算虚拟化管理环境中的智能加权负载均衡方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107888660A (zh) * 2017-10-13 2018-04-06 杭州朗和科技有限公司 云服务资源调配方法、介质、装置和计算设备
CN107888660B (zh) * 2017-10-13 2021-06-18 杭州朗和科技有限公司 云服务资源调配方法、介质、装置和计算设备
CN107948095A (zh) * 2017-11-21 2018-04-20 中国银行股份有限公司 一种资源控制方法、装置及总线系统服务器
CN107948095B (zh) * 2017-11-21 2021-11-02 中国银行股份有限公司 一种资源控制方法、装置及总线系统服务器
CN112231146A (zh) * 2020-10-22 2021-01-15 浪潮云信息技术股份公司 基于cinder-backup的备份服务质量的实现方法、存储介质
CN112988390A (zh) * 2021-03-22 2021-06-18 上海超级计算中心 一种算力资源分配方法及装置

Also Published As

Publication number Publication date
CN107135241A (zh) 2017-09-05

Similar Documents

Publication Publication Date Title
WO2017143981A1 (zh) 服务处理
WO2019085405A1 (zh) 客服会话分配方法、电子装置及计算机可读存储介质
US11336583B2 (en) Background processes in update load balancers of an auto scaling group
US20210218842A1 (en) Method, device, server and storage medium of agent allocation
US9391749B2 (en) System and method for distributed data management in wireless networks
US9112809B2 (en) Method and apparatus for controlling utilization in a horizontally scaled software application
WO2019205371A1 (zh) 服务器、消息分配的方法及存储介质
US11321118B2 (en) System and method for controlled sharing of consumable resources in a computer cluster
CN107590002A (zh) 任务分配方法、装置、存储介质、设备及分布式任务系统
WO2019041738A1 (zh) 客户资源获取方法、装置、终端设备及存储介质
US20200348977A1 (en) Resource scheduling methods, device and system, and central server
US20220174103A1 (en) System and method for thought object sequencing in a communication environment
CN107888660B (zh) 云服务资源调配方法、介质、装置和计算设备
US9817698B2 (en) Scheduling execution requests to allow partial results
US11539636B1 (en) Quota-based resource scheduling
WO2017096842A1 (zh) 内容分发任务的提交方法及系统
CN106303112B (zh) 一种话务均衡方法及装置
WO2019096046A1 (zh) 数据处理系统、方法及令牌管理方法
CN110708256A (zh) Cdn调度方法、装置、网络设备及存储介质
US20170161669A1 (en) Method and system for submitting content delivery tasks
CN112395075A (zh) 资源的处理方法、装置以及资源调度系统
US11709707B2 (en) Low latency distributed counters for quotas
CN111371848A (zh) 一种请求处理方法、装置、设备及存储介质
CN105357239A (zh) 提供服务的方法和装置、获取服务的方法及装置
CN112995058B (zh) 一种令牌的调整方法及装置

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17755810

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17755810

Country of ref document: EP

Kind code of ref document: A1