Service calling method, traffic scheduling method and device

文档序号:1538031 发布日期:2020-02-14 浏览:17次 中文

阅读说明:本技术 服务调用方法、流量调度方法及装置 (Service calling method, traffic scheduling method and device ) 是由 王建伟 邢学超 许真恩 朱鹏飞 郭平 于 2018-08-03 设计创作,主要内容包括:本说明书一个或多个实施例提供一种服务调用方法、流量调度方法及装置,该服务调用方法可以包括:根据服务调用方发起的服务调用请求,确定被调用服务对应的服务提供方;根据所述服务调用方的属性标签和服务提供方的属性标签,选取目标服务提供方,以由所述目标服务提供方向所述服务调用方提供服务。(One or more embodiments of the present specification provide a service invocation method, a traffic scheduling method, and an apparatus, where the service invocation method may include: determining a service provider corresponding to the called service according to a service calling request initiated by a service calling party; and selecting a target service provider according to the attribute label of the service caller and the attribute label of the service provider so that the target service provider provides service to the service caller.)

1. A service invocation method, characterized by comprising:

determining a service provider corresponding to the called service according to a service calling request initiated by a service calling party;

and selecting a target service provider according to the attribute label of the service caller and the attribute label of the service provider so that the target service provider provides service to the service caller.

2. The method of claim 1, wherein selecting a target service provider according to the attribute tag of the service caller and the attribute tag of the service provider comprises:

respectively acquiring address information of the service caller and the service provider;

and respectively determining the attribute tags of the service caller and the service provider according to a mapping relation between the pre-configured address information and the attribute tags, so that the attribute tags of the service caller and the attribute tags of the service provider are compared.

3. The method of claim 1, wherein the attribute tags include values in at least one attribute dimension selected from the group consisting of: geographical position, operating environment, whether gray scale is available, and weight value.

4. The method of claim 1,

when a plurality of service providers matched with the service invoker exist, the target service provider is the service provider with the highest matching degree;

or the target service provider comprises all matched service providers, and the service invoker performs screening to enable the screened target service provider to provide services for the service invoker.

5. The method of claim 1, further comprising:

performing a health check against the target service provider;

and when the checking result shows that the target service provider is abnormal, determining the corresponding disaster tolerance service provider according to the disaster tolerance processing rule, so that the target service provider is replaced by the disaster tolerance service provider.

6. The method of claim 1, further comprising:

and when the target service provider cannot be determined according to the attribute label of the service caller and the attribute label of the service provider, determining the corresponding disaster tolerance service provider according to the disaster tolerance processing rule so as to take the disaster tolerance service provider as the target service provider.

7. The method of claim 1, further comprising:

routing the service tune request to the target service provider;

or returning the information of the selected service provider to the service caller.

8. A traffic scheduling method, comprising:

determining a flow processing party corresponding to the scheduled flow according to a flow scheduling request initiated by a flow source party;

and selecting a target flow processing party according to the attribute label of the flow source party and the attribute label of the flow processing party so as to carry out flow processing on the flow source party by the target flow processing party.

9. A service invocation apparatus, characterized by comprising:

the determining unit is used for determining a service provider corresponding to the called service according to the service calling request initiated by the service calling party;

and the selecting unit is used for selecting a target service provider according to the attribute label of the service caller and the attribute label of the service provider so that the target service provider provides service to the service caller.

10. The apparatus according to claim 9, wherein the selecting unit is specifically configured to:

respectively acquiring address information of the service caller and the service provider;

and respectively determining the attribute tags of the service caller and the service provider according to a mapping relation between the pre-configured address information and the attribute tags, so that the attribute tags of the service caller and the attribute tags of the service provider are compared.

11. The apparatus of claim 9, wherein the attribute tag comprises a value in at least one attribute dimension selected from the group consisting of: geographical position, operating environment, whether gray scale is available, and weight value.

12. The apparatus of claim 9,

when a plurality of service providers matched with the service invoker exist, the target service provider is the service provider with the highest matching degree;

or the target service provider comprises all matched service providers, and the service invoker performs screening to enable the screened target service provider to provide services for the service invoker.

13. The apparatus of claim 9, further comprising:

a checking unit that performs a health check for the target service provider;

and the first disaster recovery processing unit determines the corresponding disaster recovery service provider according to the disaster recovery processing rule when the checking result shows that the target service provider is abnormal, so that the target service provider is replaced by the disaster recovery service provider.

14. The apparatus of claim 9, further comprising:

and the second disaster recovery processing unit is used for determining a corresponding disaster recovery service provider according to the disaster recovery processing rule when a target service provider cannot be determined according to the attribute tag of the service calling party and the attribute tag of the service provider, so that the disaster recovery service provider is used as the target service provider.

15. The apparatus of claim 9, further comprising:

a response unit, which routes the service call request to the target service provider; or returning the information of the selected service provider to the service caller.

16. A traffic scheduling apparatus, comprising:

the determining unit is used for determining a traffic processing party corresponding to the scheduled traffic according to a traffic scheduling request initiated by a traffic source party;

and the selecting unit is used for selecting a target traffic processing party according to the attribute label of the traffic source party and the attribute label of the traffic processing party so as to carry out traffic processing on the traffic source party by the target traffic processing party.

Technical Field

One or more embodiments of the present disclosure relate to the field of network technologies, and in particular, to a service invocation method, a traffic scheduling method, and an apparatus.

Background

With the continuous development of services and the continuous increase of the number of users, the system functions are more and more complex, and the performance of the server can not be met by simply improving the performance of the server. Therefore, in the related art, different services are separated through a distributed technology, and different Service providers respectively provide corresponding services, and Service Discovery (Service Discovery) is a process in which a Service caller finds a corresponding Service provider.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a service invocation method, a traffic scheduling method, and an apparatus.

To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:

according to a first aspect of one or more embodiments of the present specification, there is provided a service invocation method, including:

determining a service provider corresponding to the called service according to a service calling request initiated by a service calling party;

and selecting a target service provider according to the attribute label of the service caller and the attribute label of the service provider so that the target service provider provides service to the service caller.

According to a second aspect of one or more embodiments of the present specification, there is provided a traffic scheduling method, including:

determining a flow processing party corresponding to the scheduled flow according to a flow scheduling request initiated by a flow source party;

and selecting a target flow processing party according to the attribute label of the flow source party and the attribute label of the flow processing party so as to carry out flow processing on the flow source party by the target flow processing party.

According to a third aspect of one or more embodiments of the present specification, there is provided a service invocation apparatus, including:

the determining unit is used for determining a service provider corresponding to the called service according to the service calling request initiated by the service calling party;

and the selecting unit is used for selecting a target service provider according to the attribute label of the service caller and the attribute label of the service provider so that the target service provider provides service to the service caller.

According to a fourth aspect of one or more embodiments of the present specification, there is provided a traffic scheduling apparatus, including:

the determining unit is used for determining a traffic processing party corresponding to the scheduled traffic according to a traffic scheduling request initiated by a traffic source party;

and the selecting unit is used for selecting a target traffic processing party according to the attribute label of the traffic source party and the attribute label of the traffic processing party so as to carry out traffic processing on the traffic source party by the target traffic processing party.

Drawings

Fig. 1 is an architecture diagram of a service invocation system according to an exemplary embodiment.

FIG. 2 is a flow diagram of a method for service invocation provided by an exemplary embodiment.

FIG. 3 is a schematic diagram of a service invocation system provided by an exemplary embodiment.

Fig. 4 is a schematic diagram of a service discovery process provided by an exemplary embodiment.

Fig. 5 is an interaction flow diagram of a service discovery process provided by an exemplary embodiment.

Fig. 6 is a schematic structural diagram of an apparatus according to an exemplary embodiment.

Fig. 7 is a block diagram of a service invocation device according to an exemplary embodiment.

Fig. 8 is a schematic architecture diagram of a traffic scheduling system according to an exemplary embodiment.

Fig. 9 is a flowchart of a traffic scheduling method according to an exemplary embodiment.

Fig. 10 is a schematic structural diagram of another apparatus provided in an exemplary embodiment.

Fig. 11 is a block diagram of a traffic scheduling apparatus according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Fig. 1 is an architecture diagram of a service invocation system according to an exemplary embodiment. As shown in FIG. 1, the system may include a service agent device 11, a network 12, and a plurality of server devices 13-16.

The service mediation device 11 may be a physical server comprising an independent host, or the service mediation device 11 may be a virtual server carried by a cluster of hosts. In operation, the service mediation device 11 may run a program on the service side of an application to implement a service mediation for the service invocation system, thereby assisting a service invoker in the service invocation system to find a corresponding service provider.

The server device 13 may be a physical server comprising an independent host, or the server device 11 may be a virtual server carried by a host cluster; the server devices 14-16 are similar to the server device 13, and are not described in detail here. In the operation process, the server devices 14 to 16 may respectively operate a program on a client side of a certain application to implement a service caller or a service provider of the service call system; in some scenarios, the same server device may be called as a service caller to the service provider, and in other scenarios may be called as a service provider to the service caller.

The network 12 for interaction between the server devices 13-16 and the service intermediary device 11 may include various types of wired or wireless networks. In one embodiment, the Network 12 may include the Public Switched Telephone Network (PSTN) and the Internet.

FIG. 2 is a flow diagram of a method for service invocation provided by an exemplary embodiment. As shown in FIG. 2, the method applied to a service intermediary may comprise the steps of:

step 202, determining a service provider corresponding to the called service according to the service calling request initiated by the service caller.

In one embodiment, the service broker may determine a corresponding service provider according to a service invocation request initiated by a service invoker; the service invocation request may include information of the invoked service, and the service broker records in advance a mapping relationship between information of each service provider and information of the service that the service broker can provide, and determines the service provider corresponding to the invoked service according to the mapping relationship.

In one embodiment, the information of the service provider in the mapping relationship pre-recorded by the service intermediary may include address information (e.g., IP address, etc.) of the service provider, the information of the service recorded in the mapping relationship may include a service name, and the mapping relationship may record "address information-service name" in the form of a key-value pair.

And 204, selecting a target service provider according to the attribute label of the service caller and the attribute label of the service provider, so that the target service provider provides service to the service caller.

In one embodiment, if there is only one service provider, it may be chosen directly as the target service provider.

In one embodiment, there are often multiple service providers for the same invoked service to ensure reliability of the service through redundant configurations. The technical solution based on the present specification may be used as a function that can be implemented by a service intermediary, and the service intermediary may perform on-off control on the function according to a manual on-off command of an administrator or a pre-configured control policy. When the function is closed, the service broker returns the information of all service providers corresponding to the called service to the service caller (i.e. the service providers are all used as target service providers); alternatively, the service broker may filter the service providers according to the processing scheme in the related art, which is not limited in this specification. When the function is turned on, the service intermediary may pick the target service provider based on the attribute tag.

In an embodiment, when the service broker uses the address information as an identifier for distinguishing different service providers, on the one hand, the service broker may record a mapping relationship between the address information and information of services that can be provided by the corresponding service provider, such as the above-mentioned "address information-service name", and on the other hand, the service broker may record a mapping relationship between the address information and an attribute tag of the corresponding service provider. Then, when the service broker receives a service invocation request initiated by a service invoker, the information of the service provider corresponding to the invoked service may be determined according to the information of the invoked service included in the service invocation request and the first mapping relationship, and further, the attribute tag of the service provider corresponding to the invoked service may be determined according to the second mapping relationship. Meanwhile, the service intermediary can also record the mapping relation between the address information of the service calling party and the attribute label of the service calling party, so that the service intermediary can determine the address information of the service calling party according to the service calling request initiated by the service calling party and further determine the attribute label of the service calling party by combining the mapping relation. To sum up, the service broker may obtain address information of the service invoker and the service provider, and determine the attribute tags of the service invoker and the service provider according to a mapping relationship between the address information and the attribute tags configured in advance, so as to select a target service provider according to the attribute tag of the service invoker and the attribute tags of each service provider.

In an embodiment, the service broker may compare the attribute tag of the service invoker with the attribute tags of the service providers, and may select a service provider as a target service provider when the attribute tag of the service invoker matches the attribute tag of the service provider.

In an embodiment, model training may be performed on the attribute tag of the historical service caller, the attribute tag of the historical target service provider, and the like included in the historical service call data through a machine learning method and the like according to the historical service call data, so as to obtain a corresponding prediction model. Then, by inputting the attribute tag of the service caller and the attribute tags of the service providers into the prediction model, the corresponding target service provider can be output by the prediction model.

In one embodiment, the attribute tags may include: attribute dimensions, such as geographical location, operating environment, etc., that can cause quality impacts to the service provided by the service provider to the service invoker. For example, for a geographic location, the quality of service tends to be relatively better when the service provider and the service invoker are in the same geographic region, and the quality of service tends to be relatively worse, such as relatively higher delay, when the service provider and the service invoker are in different geographic regions. For another example, for an operating environment, when a service provider and a service caller are in the same operating environment, the service quality tends to be relatively better, and when the service provider and the service caller are in different operating environments, the service quality tends to be relatively worse, for example, the operating process is relatively more stuttered.

In one embodiment, the attribute tags may include: the attribute dimensionality of management requirements in the service calling process can be met, such as gray level, weight value and the like, so that the requirements of corresponding flow management, disaster recovery management and the like are met. For example, regarding whether to perform gray scale, when a service caller belongs to a gray scale distribution object, the selected service provider (i.e., target service provider) may be applicable to a gray scale distribution scenario, or when a service caller does not belong to a gray scale distribution object, the selected service provider may be applicable to a non-gray scale distribution scenario, thereby implementing traffic management for gray scale distribution. For another example, for the weight value, according to the weight values of the service invoker and the service provider, the service provider with the appropriate weight value may be selected, and the service providers with other weight values are isolated; for example, when there is a large amount of failures in the host device of the service provider and only a part of the host device is operating normally, an appropriate weight value may be set for protecting the service provider so that the service provider is not fed back to the service invoker by the service broker, so as to avoid affecting the normal operation of the service provider, and enable the service provider to provide basic service or emergency service.

In an embodiment, the service provider is determined by matching the attribute tags of the service caller and the service provider, so that the service quality can be improved, and the management and control operation of the service traffic can be flexibly realized by configuring the attribute tags, thereby accurately realizing the traffic control requirement.

In an embodiment, based on the comparison result of the attribute tags or the prediction result of the prediction model, there may be multiple matching service providers at the same time, and the service broker may select the service provider with the highest matching degree as the selected target service provider.

In an embodiment, based on the comparison result of the attribute tags or the prediction result of the prediction model, there may be multiple matching service providers at the same time, and the service broker may select all the matching service providers to use them as the selected target service provider, so that the service invoker may perform screening according to a preset policy.

In an embodiment, the service intermediary may perform a health check (health check) against the target service provider; and when the checking result shows that the target service provider is abnormal, determining the corresponding disaster tolerance service provider through the disaster tolerance processing rule, so that the target service provider is replaced by the disaster tolerance service provider. For example, when the service broker selects a certain service provider based on the matching result of the attribute tags, if the health degree of the service provider does not meet the requirement, the service broker may select a disaster tolerance service provider based on the disaster tolerance processing rule, such as other service providers with similar or relatively low matching degrees of the attribute tags, so that although the service quality may be slightly different, a normal response to the service invoker can be ensured, so that the service invoker can invoke the relevant service normally.

In an embodiment, when the target service provider cannot be determined according to the attribute tag of the service caller and the attribute tag of the service provider, the service broker may determine whether the disaster tolerance processing rule is triggered; if the disaster tolerance processing rule is triggered, it indicates that there is a matched service provider, but the service provider is in an abnormal state, and the corresponding disaster tolerance service provider can be determined through the disaster tolerance processing rule, and the disaster tolerance service provider can bear the service traffic of the service provider in the abnormal state, so that the service intermediary can use the disaster tolerance service provider as the target service provider, and the disaster tolerance service provider provides service to the service invoker.

In one embodiment, the service intermediary may route the service invocation request to the target service provider, which responds to the service invocation request by the target service provider, i.e., providing the associated service to the service invoker.

In an embodiment, the service broker may return the information of the selected service provider to the service invoker, and the service invoker selects an appropriate time or scene according to its own requirements to access the target service provider, so as to implement corresponding service invocation.

FIG. 3 is a schematic diagram of a service invocation system provided by an exemplary embodiment. As shown in fig. 3, assume that the service invocation system includes a service broker and several service parties, namely, service party 1, service party 2, service party 3 … …, service party n, etc. In the service calling process, the service side 1 to the service side n can realize two roles: a service caller and a service provider; the service caller initiates a service call request to the service broker, and the service broker returns information of the service provider to the service caller, so that the service caller can call the relevant service to the service provider. Each of the servant 1 to the servant n can be used as a service caller or a service provider, depending on the requirements of an actual scene; of course, it is not excluded that some of the servers may only be service invokers or service providers, and this specification does not limit this.

The service side 1 to the service side n can provide API service through the respective configured ports 1 to n, the IP addresses of the ports 1 to n are the service addresses of the service side 1 to the service side n, for example, the IP address of the service side 1 is IP address 1, the IP address of the service side 2 is IP address 2, the IP address of the service side 3 is IP address 3, the IP address of the service side n is IP address n, and the like, and the corresponding service side 1 to service side n can be called based on the IP addresses 1 to n.

The service providers 1 to n register with the service broker, respectively, so that the service broker records the service address of each service provider and the services that can be provided by the service provider. For example, the service intermediary may record in the form of a key-value pair; the key is a service address of each service party, that is, the IP address 1 to the IP address n, and the value is a service name corresponding to a service that can be provided by each service party, for example, the record information corresponding to the service party 1 may be "IP address 1-service a", the record information corresponding to the service party 2 may be "IP address 2-service B", and the like.

The service intermediary is also configured to record attribute tags for each of the service parties. The attribute tags may include one or more attribute dimensions, such as geographic location, operating environment, gray level, weight value, etc., which are not limited by this specification. When each IP address is allocated to a corresponding service party, the attribute tag of the service party can be determined, or the attribute tag can be modified subsequently, which is not limited in this specification. The service intermediary can record the attribute labels of each service party in a key-value key value pair mode; the key is the service address of each service party, i.e. the above IP address 1 to IP address n, the value is the attribute label of each service party, and the case of "geographic location + operating environment" is taken as an example, for example, the record information corresponding to the service party 1 may be "IP address 1-beijing-production environment", and the record information corresponding to the service party 2 may be "IP address 2-shanghai-development environment", and the like.

Based on the service invocation system shown in fig. 3, fig. 4 is a schematic diagram of a service discovery process provided by an exemplary embodiment, and fig. 5 is an interaction flow diagram of a service discovery process provided by an exemplary embodiment; as shown in fig. 4-5, the service discovery process may include the following steps:

in step 501, the server 1 receives a web browsing request initiated by the user equipment 40.

In one embodiment, assuming that a user wishes to browse a web page of a certain website on the user device 40, the user device 40 may initiate a web browsing request to the service 1 to obtain contents such as pictures, videos and the like contained in the web page.

In an embodiment, the user device 40 may include any type of electronic device, such as a mobile phone, a PC, a laptop, a tablet, smart glasses, and the like, which is not limited by the present description.

In one embodiment, it is assumed that the server 1 responds to the web browsing request; in other embodiments, other user devices or other requests initiated by the user device 40 may be responded to by other service parties, and the description is not limited thereto.

In step 502, the service party 1 requests the service broker to invoke the picture service and the video service.

In an embodiment, it is assumed that the service provider 1 is not capable of providing the picture service and the video service, and therefore, for the contents such as the pictures and the videos in the web page, the service provider 1 needs to initiate a service invocation request to the service intermediary, so that the service intermediary informs the service provider 1 of the information of the service provider capable of providing the relevant service, that is, service discovery is implemented.

In one embodiment, when the service provider 1 requests the service intermediary to invoke the picture service and the video service, the service provider 1 plays a role of a service invoker, and the other service providers play a role of service providers, and the service intermediary determines the service provider capable of responding to the service provider 1, so that the service provider 1 can provide related services, such as the picture service, the video service, and the like.

The service intermediary determines the source IP and the destination IP, step 503.

In an embodiment, after the service broker 1 initiates a service invocation request to the service broker, the service broker may obtain an IP address of the service broker 1 to serve as a source IP of the service invocation at this time; for example, when the port of the server 1 is configured as IP address 1, the source IP is IP address 1.

In an embodiment, the service invocation request from the service intermediary 1 includes the service name of the invoked service, and the service intermediary may determine the IP address corresponding to the service name as the destination IP according to the pre-recorded "IP address-service name" mapping relationship described above. For example, when the service name is a picture service, if the recorded mapping relationship is "IP address i-picture service", it indicates that the service party i with the IP address as IP address i provides the picture service; for another example, when the service name is video service, if the recorded mapping relationship is "IP address j-video service", it indicates that video service is provided by the server j whose IP address is IP address j. Therefore, the destination IP corresponding to the picture service is IP address i, and the destination IP corresponding to the video service is IP address j.

Step 504, the service intermediary obtains the attribute labels corresponding to the source IP and the destination IP, respectively, and compares the attribute labels.

In an embodiment, for each service requested to be invoked by the service provider 1, the service intermediary often searches a plurality of corresponding IP addresses, and the service providers corresponding to the IP addresses can provide corresponding services, so that the service intermediary may perform screening from a plurality of service providers capable of providing the same service, and finally determine a service provider for providing the service provider 1 with the relevant service.

In an embodiment, the service intermediary may determine the attribute label corresponding to the source IP and each destination IP respectively according to the pre-recorded "IP address-attribute label" mapping relationship; then, for each service requested to be called by the service party 1, comparing the attribute label of the source IP with the attribute labels of the destination IPs, and determining the service party for providing the service party 1 with the relevant service according to the matching condition between the attribute labels.

Take the attribute tag as "geographic location + operating environment" as an example. Suppose that for picture service, a source IP determined by a service intermediary is IP address 1, and a destination IP is IP address 2, IP address 3 and IP address 4; according to the mapping relation of the IP address-attribute label pre-recorded by the service intermediary, the mapping relation corresponding to the source IP is determined to be IP address 1-Beijing-production environment, namely the attribute label of the source IP is Beijing + production environment, and the mapping relation corresponding to the target IP is determined to be IP address 2-Beijing-development environment, IP address 3-Beijing-production environment and IP address 4-Shanghai-production environment respectively, namely the attribute label of the target IP is ' Beijing + development environment ', Beijing + production environment ' and Shanghai + production environment respectively. Therefore, by comparing the above attribute tags, it can be determined that the IP address 1 matches the attribute tag of the IP address 3, and the IP address 1 does not match the attribute tags of the IP addresses 2 and 4, so that the IP address 3 can be selected, so that the corresponding service party 3 provides the picture service to the service party 1.

For video services or other types of services, the matching process of the attribute tags is similar to the matching process of the picture services, and details are not repeated here.

In one embodiment, when only one destination IP exists for a service, the service intermediary may omit step 504 and select the destination IP directly without performing an attribute tag matching operation.

Step 505, the service intermediary performs health check on the service party corresponding to the selected destination IP.

In an embodiment, it is assumed that the service intermediary selects the IP address i corresponding to the picture service and the IP address j corresponding to the video service respectively through step 504, that is, selects the server i to provide the picture service for the server 1 and selects the server j to provide the video service for the server 1. As an optional step, the service intermediary may perform a health check on server i and server j, respectively.

The service intermediary determines 506 the service provider.

In one embodiment, when only one destination IP exists for a service, the service intermediary may determine that the service provider for the service is the destination IP if the service provider corresponding to the destination IP passes the health check.

In an embodiment, when there are multiple destination IPs matching the source IP (i.e. the attribute tag corresponding to the destination IP matches the attribute tag corresponding to the source IP) for a certain service, the service intermediary may select a destination IP according to a preset policy (e.g. randomly selecting, selecting the smallest IP address, selecting the largest IP address, etc.) and perform a health check on the selected destination IP in step 504.

In an embodiment, when there are a plurality of destination IPs matching the source IP for a certain service, the service intermediary may select the destination IPs and perform health check on the corresponding service providers, so as to select the service provider with the best health degree as the service provider.

In an embodiment, when there are a plurality of destination IPs matching the source IP for a certain service, the service broker may select the destination IPs and perform health check on corresponding service providers respectively, thereby selecting all service providers that pass the health check as service providers, and the service invoker subsequently selects a desired service provider.

In an embodiment, if none of the servers corresponding to the destination IP selected by the service broker passes the health check, the disaster recovery processing logic for the health check may be triggered, the disaster recovery server corresponding to the server is determined, and the disaster recovery server is used as the service provider.

It should be noted that: if the service intermediary may not find a destination IP corresponding to a certain service in step 503, the service intermediary may determine whether to trigger the disaster recovery processing logic, that is, whether the reason why the destination IP is not found is abnormal due to the related service parties or whether there is no service party capable of providing the service; if it is determined that the related service party is abnormal, determining a corresponding disaster recovery service party based on the disaster recovery processing logic, and going to step 505; if it is determined that there is no service provider capable of providing the service, call failure information may be directly returned to the service provider 1.

Step 507, the service intermediary returns the IP list 1 corresponding to the picture service and the IP list 2 corresponding to the video service to the service party 1.

In one embodiment, the service intermediary may determine the service party for providing the picture service, and the IP list 1 includes the IP address of the service party; if only one service party for providing the picture service is determined, the IP list 1 includes an IP address of the service party, such as an IP address i corresponding to the service party i; if a plurality of service providers for providing the picture service are determined, the IP list 1 may include a plurality of IP addresses respectively corresponding to the service providers. Similarly, the IP list 2 includes IP addresses of one or more service providers providing video services, such as an IP address j corresponding to the service provider j.

In step 508A, server 1 calls a picture service to server i.

In step 509A, the service part 1 receives the picture data returned by the service part i, and returns the picture data to the user equipment 40.

In an embodiment, assuming that the IP list 1 includes an IP address i of the service party i, the service party 1 may call the picture service to the service party i based on the IP address i, so as to obtain corresponding picture data, and this process may refer to a service call process in the related art, which is not described herein again.

In step 508B, server 1 invokes the video service to server j.

In step 509B, server 1 receives the video data returned by server j and returns the video data to user equipment 40.

In an embodiment, assuming that the IP list 1 includes the IP address j of the server j, the server 1 may call the video service to the server j based on the IP address j, so as to obtain corresponding video data, and this process may refer to a service call process in the related art, which is not described herein again.

In an embodiment, the service 1 may return the picture data and the video data to the user equipment 40 respectively, for example, the service 1 first receives the picture data returned by the service i, then returns the picture data to the user equipment 40, and then returns the video data to the user equipment 40 after receiving the video data subsequently. In another embodiment, the service part 1 may return the picture data and the video data to the user equipment 40 after receiving the picture data and the video data, respectively, which is not limited in this specification.

FIG. 6 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 6, at the hardware level, the apparatus includes a processor 602, an internal bus 604, a network interface 606, a memory 608 and a non-volatile memory 610, but may also include hardware required for other services. The processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs the computer program, thereby forming a service invocation means on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 7, in a software implementation, the service invocation device may include:

a determining unit 71, configured to determine, according to a service invocation request initiated by a service invoker, a service provider corresponding to an invoked service;

the selecting unit 72 selects a target service provider according to the attribute tag of the service caller and the attribute tag of the service provider, so that the target service provider provides a service to the service caller.

Optionally, the selecting unit 72 is specifically configured to:

respectively acquiring address information of the service caller and the service provider;

and respectively determining the attribute tags of the service caller and the service provider according to a mapping relation between the pre-configured address information and the attribute tags, so that the attribute tags of the service caller and the attribute tags of the service provider are compared.

Optionally, the attribute tag includes a value in at least one attribute dimension: geographical position, operating environment, whether gray scale is available, and weight value.

Alternatively to this, the first and second parts may,

when a plurality of service providers matched with the service invoker exist, the target service provider is the service provider with the highest matching degree;

or the target service provider comprises all matched service providers, and the service invoker performs screening to enable the screened target service provider to provide services for the service invoker.

Optionally, the method further includes:

a checking unit 73 that performs a health check for the target service provider;

and when the checking result indicates that the target service provider is abnormal, the first disaster recovery processing unit 74 determines a corresponding disaster recovery service provider according to the disaster recovery processing rule, so that the target service provider is replaced by the disaster recovery service provider.

Optionally, the method further includes:

when the target service provider cannot be determined according to the attribute tag of the service caller and the attribute tag of the service provider, the second disaster recovery processing unit 75 determines the corresponding disaster recovery service provider according to the disaster recovery processing rule, so as to use the disaster recovery service provider as the target service provider.

Optionally, the method further includes:

a response element 76 that routes the service call request to the target service provider; or returning the information of the selected service provider to the service caller.

Fig. 8 is a schematic architecture diagram of a traffic scheduling system according to an exemplary embodiment. As shown in FIG. 8, the system may include a schedule agent 81, a network 82, and a plurality of server devices 83-86.

The scheduling mediation device 81 may be a physical server that contains an independent host, or the scheduling mediation device 81 may be a virtual server that is hosted by a cluster of hosts. In the operation process, the scheduling mediation device 81 may operate a program on a server side of a certain application to implement a scheduling mediation of the traffic scheduling system, so as to assist a traffic source party in the traffic scheduling system to find a corresponding traffic handler.

The server device 83 may be a physical server comprising a separate host, or the server device 81 may be a virtual server carried by a cluster of hosts; the server devices 84-86 are similar to the server device 83 and are not described in detail here. In the operation process, the server side devices 84 to 86 may respectively operate a client side program of a certain application to realize as a traffic source side or a traffic processing side of the traffic scheduling system; in some scenarios, the same server device may be called as a traffic source and called as a traffic handler, and in other scenarios, the same server device may be called as a traffic handler and called as a traffic source.

The network 82 for interaction between the server devices 83-86 and the schedule agent device 81 may include various types of wired or wireless networks. In one embodiment, the Network 82 may include the Public Switched Telephone Network (PSTN) and the Internet.

Fig. 9 is a flowchart of a traffic scheduling method according to an exemplary embodiment. As shown in fig. 9, the method applied to a scheduling intermediary may comprise the steps of:

step 902, determining a traffic handler corresponding to the scheduled traffic according to the traffic scheduling request initiated by the traffic source.

In an embodiment, the scheduling broker may determine a corresponding traffic handler according to a traffic scheduling request initiated by a traffic source; the traffic scheduling request may include information of scheduled traffic, and the scheduling broker records in advance a mapping relationship between information of each traffic handler and information of the traffic that can be scheduled by the scheduling broker, and determines a traffic handler corresponding to the scheduled traffic according to the mapping relationship.

In an embodiment, the information of the traffic handler in the mapping relationship pre-recorded by the scheduling intermediary may include address information (e.g., IP address, etc.) of the traffic handler, the information of the traffic recorded in the mapping relationship may include a service name corresponding to the traffic, and the mapping relationship may record "address information-service name" in the form of a key-value pair.

Step 904, selecting a target traffic processing party according to the attribute label of the traffic source party and the attribute label of the traffic processing party, so that the target traffic processing party performs traffic processing on the traffic source party.

In one embodiment, if there is only one traffic handler, it may be chosen directly as the target traffic handler.

In one embodiment, there are often multiple traffic handlers for the same scheduled traffic to ensure the reliability of traffic scheduling through redundancy configuration. The technical solution based on the present specification may be used as a function that can be implemented by a scheduling intermediary, and the scheduling intermediary may perform on-off control on the function according to a manual on-off command of an administrator or a pre-configured control policy. When the function is closed, the scheduling broker returns the information of all traffic handlers corresponding to the scheduled traffic to the traffic source (i.e. all traffic handlers are used as target traffic handlers); alternatively, the scheduling intermediary may screen the traffic handlers according to the processing scheme in the related art, which is not limited in this specification. When this function is turned on, the scheduling intermediary may select a target traffic handler based on the attribute tag.

In one embodiment, when the scheduling intermediary uses the address information as the identifier for distinguishing different traffic handlers, on one hand, the scheduling intermediary may record a mapping relationship between the address information and information of the traffic that can be scheduled by the corresponding traffic handler, such as the above-mentioned "address information-service name", and on the other hand, the scheduling intermediary may record a mapping relationship between the address information and the attribute tag of the corresponding traffic handler. Then, when the scheduling intermediary receives the traffic scheduling request initiated by the traffic source, the information of the traffic handler corresponding to the scheduled traffic may be determined according to the information of the scheduled traffic included in the traffic scheduling request and the first mapping relationship, and further the attribute tag of the traffic handler corresponding to the scheduled traffic may be determined according to the second mapping relationship. Meanwhile, the scheduling intermediary can also record the mapping relationship between the address information of the traffic source party and the attribute label of the traffic source party, so that the scheduling intermediary can determine the address information of the traffic source party according to the traffic scheduling request initiated by the traffic source party and further determine the attribute label of the traffic source party by combining the mapping relationship. In summary, the scheduling intermediary may obtain address information of the traffic source and the traffic processor, and determine the attribute tags of the traffic source and the traffic processor according to a mapping relationship between the pre-configured address information and the attribute tags, so as to select a target traffic processor according to the attribute tag of the traffic source and the attribute tags of each traffic processor.

In an embodiment, the scheduling intermediary may compare the attribute tag of the traffic source party with the attribute tags of the traffic processors, respectively, and when the attribute tag of the traffic source party matches the attribute tag of a certain traffic processor, the traffic processor may be selected as the target traffic processor.

In an embodiment, according to historical traffic scheduling data, model training may be performed on an attribute tag of a historical traffic source side and an attribute tag of a historical target traffic processing side, which are included in the historical traffic scheduling data, in a machine learning manner or the like, so as to obtain a corresponding prediction model. Then, by inputting the attribute tag of the traffic source side and the attribute tag of each traffic handler into the prediction model, the corresponding target traffic handler can be output by the prediction model.

In one embodiment, the attribute tags may include: attribute dimensions, such as geographical location, operating environment, etc., that can cause quality impact on traffic scheduled by a traffic handling party to a traffic source party. For example, for a geographic location, the processing quality tends to be relatively better when the traffic handler and the traffic source are in the same geographic region, and the processing quality tends to be relatively worse, such as relatively higher latency, when the traffic handler and the traffic source are in different geographic regions. For another example, for an operating environment, when the traffic processor and the traffic source are in the same operating environment, the processing quality tends to be relatively better, and when the traffic processor and the traffic source are in different operating environments, the processing quality tends to be relatively worse, for example, the operation process is relatively more stuttered.

In one embodiment, the attribute tags may include: the attribute dimensionality of management requirements in the flow scheduling process can be met, such as gray level, weight value and the like, so that the corresponding requirements of flow management, disaster recovery management and the like are met. For example, regarding whether to perform gray scale, when the traffic source side belongs to a gray scale distribution object, the selected traffic handler (i.e., the target traffic handler) may be applicable to a gray scale distribution scenario, or when the traffic source side does not belong to a gray scale distribution object, the selected traffic handler may be applicable to a non-gray scale distribution scenario, thereby implementing traffic management for gray scale distribution. For another example, for the weight value, according to the weight values of the traffic source side and the traffic processing side, the traffic processing side with the appropriate weight value may be selected, and the traffic processing sides with other weight values are isolated; for example, when there is a large amount of failures in the host device of the traffic handler and only a portion of the host device is operating normally, an appropriate weight value may be set for protecting the traffic handler so that the traffic handler is not fed back to the traffic source by the scheduling intermediary, so as to avoid affecting the normal operation of the traffic handler, and enable the traffic handler to provide basic service or emergency service.

In an embodiment, the attribute tags of the traffic source party and the traffic processing party are matched to determine the traffic processing party, so that the quality of processing traffic can be improved, and the operation of controlling traffic is flexibly realized through the configuration operation of the attribute tags, thereby accurately realizing traffic scheduling and processing.

In an embodiment, based on the comparison result of the attribute tags or the prediction result of the prediction model, there may be multiple matching traffic handlers at the same time, and the scheduling intermediary may select the traffic handler with the highest matching degree as the selected target traffic handler.

In an embodiment, based on the comparison result of the attribute tags or the prediction result of the prediction model, there may be multiple matching traffic handlers at the same time, and the scheduling broker may select all the matching traffic handlers to serve as the selected target traffic handlers, so that the traffic source may perform screening according to a preset policy.

In an embodiment, the scheduling intermediary may perform a health check (health check) against the target traffic handler; and when the checking result shows that the target traffic processing party is abnormal, determining a corresponding disaster recovery traffic processing party through a disaster recovery processing rule, so that the target traffic processing party is replaced by the disaster recovery traffic processing party. For example, when the scheduling intermediary selects a certain traffic handler based on the matching result of the attribute tags, if the health degree of the traffic handler does not meet the requirement, the scheduling intermediary may select a disaster-tolerant traffic handler based on the disaster-tolerant processing rule, such as other traffic handlers with similar or relatively low matching degree of the attribute tags, so that although the processing quality may be slightly different, the scheduling intermediary can ensure normal response to the traffic source side, so that the traffic can be smoothly scheduled and processed.

In an embodiment, when a target traffic handler cannot be determined according to the attribute tag of the traffic source and the attribute tag of the traffic handler, the scheduling broker may determine whether the disaster recovery processing rule is triggered; if the flow is triggered, it indicates that there is a matched flow processing party, but the flow processing party is in an abnormal state, the corresponding disaster recovery flow processing party can be determined through the disaster recovery processing rule, and the disaster recovery flow processing party can bear the service flow of the flow processing party in the abnormal state, and the scheduling intermediary can use the disaster recovery flow processing party as the target flow processing party, and the flow provided by the flow source party is processed by the disaster recovery flow processing party.

In one embodiment, the scheduling intermediary may route the service dispatch request to the target traffic handler, which responds to the traffic dispatch request by handling the relevant traffic provided by the traffic source.

In an embodiment, the scheduling intermediary may return the information of the selected traffic handler to the traffic source, and the traffic source may select an appropriate time or scene according to its own requirement, and provide the relevant traffic to the target traffic handler for processing by the target traffic handler.

FIG. 10 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 10, at the hardware level, the apparatus includes a processor 1002, an internal bus 1004, a network interface 1006, a memory 1008, and a non-volatile memory 1010, although it may also include hardware required for other services. The processor 1002 reads a corresponding computer program from the non-volatile memory 1010 into the memory 1008 and then runs the computer program to form a traffic scheduler on a logical level. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 11, in a software implementation, the traffic scheduling apparatus may include:

a determining unit 1101, configured to determine a traffic handler corresponding to a scheduled traffic according to a traffic scheduling request initiated by a traffic source;

the selecting unit 1102 selects a target traffic handler according to the attribute tag of the traffic source and the attribute tag of the traffic handler, so that the target traffic handler performs traffic processing on the traffic source.

Optionally, the selecting unit 1102 is specifically configured to:

respectively acquiring address information of the traffic source party and the traffic processing party;

and respectively determining the attribute tags of the traffic source party and the traffic processing party according to a mapping relation between the pre-configured address information and the attribute tags, so that the attribute tags of the traffic source party and the attribute tags of the traffic processing party are compared.

Optionally, the attribute tag includes a value in at least one attribute dimension: geographical position, operating environment, whether gray scale is available, and weight value.

Alternatively to this, the first and second parts may,

when a plurality of traffic processing parties matched with the traffic source party exist, the target traffic processing party is the traffic processing party with the highest matching degree;

or, the target traffic handler includes all matched traffic handlers, so that the traffic source performs screening, so that the screened target traffic handler processes the traffic provided by the traffic source.

Optionally, the method further includes:

a checking unit 1103 that performs a health check for the target traffic handler;

and a first disaster recovery processing unit 1104, when the check result indicates that the target traffic handler is abnormal, determining a corresponding disaster recovery traffic handler according to a disaster recovery processing rule, so that the target traffic handler is replaced by the disaster recovery traffic handler.

Optionally, the method further includes:

the second disaster recovery processing unit 1105, when the target traffic processing party cannot be determined according to the attribute tag of the traffic source party and the attribute tag of the traffic processing party, determines the corresponding disaster recovery traffic processing party according to the disaster recovery processing rule, so as to use the disaster recovery traffic processing party as the target traffic processing party.

Optionally, the method further includes:

a response unit 1106, which routes the service to the target traffic handler; or returning the information of the selected flow processing party to the flow source party.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

22页详细技术资料下载
上一篇:一种医用注射器针头装配设备
下一篇:组播业务处理方法、装置、云平台、设备及可读存储介质

网友询问留言

已有0条留言

还没有人留言评论。精彩留言会获得点赞!

精彩留言,会给你点赞!