Detailed Description
The scheme provided by the specification is described below with reference to the accompanying drawings.
The embodiment of the specification is mainly applied to a process of cross-domain service between a first system and a second system. The first system and the second system are two mutually independent systems, for example, the first system is an online payment platform (such as a treasure payment network), the second system is an online shopping platform (such as a treasure panning network), and the cross-domain service may pay for the service (such as payment for a transaction behavior in the online shopping platform through the payment platform), and the like. To more clearly illustrate the aspects of the embodiments of the present description, the background of the application of the embodiments of the present description is first presented.
Fig. 1 is a sequence diagram of normal interactions between a second system and a first system in the case where a user initiates a service 1 associated with the first system through the second system. As shown in fig. 1, in a normal case, the second system first sends a processing request of service 1 to the first system at time t. The first system receives the processing request of the service 1, can directly process the service 1, or can store the processing request into a cache first, and process the service 1 according to the service priority arrangement. When the first system processes the service 1, the first system may record the service 1, process the service 1, and record a processing result. The processing result may include processing success, processing failure, and the like. At time T, which has a predetermined time interval (e.g., 30 seconds) from time T, the second system sends a query request for service 1 to the first system. The first system queries the processing result of the service 1 and feeds back the processing result to the second system. In the process of processing the service 1, the first system may modify the database according to the processing condition, for example, the service 1 is a payment service for making a payment for a transaction in the second system, and the first system may subtract the relevant value from the account balance of the consumer in the database, and may also add the relevant value to the corresponding account balance of the merchant. At this time, the second system may perform the subsequent process by inquiring the first system about the service 1 processing condition. For example, for payment transaction processing, an order may be formed according to the returned query result of successful processing. It is noted that if the first system does not receive the service 1 processing request, the unreceived query result may be returned. If the first system is abnormal, busy or processing the service 1, the corresponding result can be returned, at this time, the second system can circularly send the query request of the service 1 until receiving the information of the query result corresponding to the successful processing, the failed processing, the unreceived processing and the like.
Referring to fig. 2, it is assumed that a processing request of service 1 sent by the second system at time T has not been received by the first system at time T due to a network or hardware device failure. And at time T, the second system sends a query request for service 1 to the first system. The first system returns query results that are not received or not present, etc. And the second system continues the subsequent flow according to the query result and the processing failure of the service 1. Such as resending the transfer request numbered service 2, etc. Then, the first system receives the processing request of the service 1, and processes the service 1, for example, subtracting a relevant value from the account balance corresponding to the user, and records the processing result. That is, the first system continues the subsequent flow in accordance with the normal processing for service 1. In this case, the processing result records of the service 1 by the first system and the second system are no longer consistent. In practical applications, a large time interval is set between time T and time T to avoid this situation as much as possible. However, on one hand, a larger time interval is set between the time T and the time T, which affects the efficiency of service interaction, and on the other hand, under the influence of an uncertain factor, it is difficult to find a better time interval, which ensures that the first system does not obtain the processing request of the service 1 after the time T and process the service 1.
In the above background, fig. 3 shows a schematic implementation scenario of an embodiment disclosed in this specification. In fig. 3, when the second system transmits a processing request of the service 1 to the first system, the processing request may include a processing time condition for processing the processing request. When the first system obtains the processing request, it may first detect whether a processing time condition is satisfied. And determining whether the processing request is valid according to the detection result, and acquiring a processing result of the processing request according to whether the processing request is valid. In one embodiment, the processing request is determined to be valid if the processing time condition is satisfied. And if the processing request is valid, the processing result is the result obtained by the first system processing the service 1 normally. In another embodiment, the processing request is determined to be invalid if the processing time condition is not satisfied. If the processing request is invalid, the processing result may be determined to be a processing failure. On the other hand, the second system may send the inquiry request to the first system according to the processing time condition described above. That is, the inquiry request is sent again at a time other than when the processing time condition is satisfied. For example, the second system sends a processing request of service 1 to the first system at time t, where the processing time condition included in the processing request is t + H, that is, only at time t + H, the first system may determine that service 1 is valid and process the service, otherwise, determine that service 1 is invalid. And the second system sends a query request to the first system after time t + H. Therefore, the first system can be ensured not to process the processing request of the same cross-domain service after returning the query result.
To further clarify the beneficial effects of the embodiments of the present specification in the above scenarios, please refer to fig. 3. Assuming the problem shown in fig. 2 still occurs, the query request arrives at the first system before the processing request. As shown in fig. 3, the second system transmits a processing request of the service 1 to the first system at time t, and unlike fig. 1 and 2, the processing request transmitted in fig. 3 includes a processing time condition for processing the service 1, for example, processing before time t + H. Assume that the first system does not receive the processing request before time t + H. And at the time T, the second system sends the query request of the service 1 to the first system, wherein the time T is not earlier than the time T + H (T is more than or equal to the time T + H). The first system returns the query result to the second system, e.g., the processing request was not received. Suppose that at a time T + S (T + S ≧ T + H) after time T, the first system receives the processing request for service 1 and wants to process the service. The first system first determines whether the time T + S meets the processing time condition according to the processing time, that is, the service 1 is processed before the time T + H. And if the T + S time is later than the T + H time, the processing request can be determined to be invalid, so that the processing result of processing failure of the processing request is obtained. In this way, in the first system and the second system, the processing result is kept consistent for the service 1. For example, if the service 1 is the payment service, the first system does not actually make payment, and the result of the processing failure obtained by the second system is consistent.
In this way, when the second system sends the processing request of the cross-domain service to the first system, by adding the processing time condition to the processing request: on one hand, the second system determines whether the processing request is valid according to the processing time condition, processes the relevant cross-domain service to obtain a processing result for the valid processing request, determines invalidity for the processing request exceeding the time range limited by the processing time condition, and obtains a processing result of the processing failure of the cross-domain service; on the other hand, after the processing request is sent, the first system determines the query start time according to the processing time condition, so as to avoid sending the query request within the time when the processing request is valid, which causes the situation shown in fig. 2. Therefore, the possible time sequence disorder condition in the cross-domain service can be avoided, and the effectiveness of the cross-domain service is improved.
As can be seen from the above description, the method for processing a cross-domain service request and a request for a cross-domain service according to the embodiments of the present disclosure is particularly suitable for two servitization systems with independent functions. The two servitization systems can communicate through a certain protocol and a certain interface. It will be appreciated that since the interface is independent of the hardware platform, operating system and programming language in which the service is implemented, this allows services built into a wide variety of systems to interact in a uniform and versatile manner. For example, for a service-oriented architecture SOA, the two systems may be two functional units of the same service platform, such as a financing unit (e.g. a balance treasured) and a payment unit (e.g. a money transfer) in one payment platform, or may be functional units under different types of service platforms, such as a computing unit under a hydropower management platform and a payment unit under a bank asset management platform, and so on. It can be understood that, since the first system and the second system may provide different services, after one system initiates a processing request of a cross-domain service to the other system, the processing condition of the cross-domain service needs to be queried again to ensure consistency of service states recorded by the cross-domain service between the two systems.
The specific implementation of the above scenario is described below.
FIG. 4 illustrates a flow diagram of a method of processing a cross-domain service request, according to one embodiment. The cross-domain service is a service occurring between two systems, such as a payment service occurring between an online shopping platform and an online payment platform, a deposit and withdrawal service occurring between a front subsystem and an accounting subsystem of a certain banking system, and the like. Here, the online shopping platform and the online payment platform are two systems, for example, a first system and a second system shown in fig. 1 to 3, respectively. The execution subject of the method may be the first system shown in fig. 1 to 3, and the like. The first system may be any system, device, apparatus, platform, or server having computing, processing capabilities.
As shown in fig. 4, the method may include the steps of: step 41, at a first time, acquiring a processing request for the cross-domain service from the second system, wherein the processing request includes a processing time condition for processing the cross-domain service; step 42, detecting whether the first time meets the processing time condition; step 43, obtaining a processing result of the cross-domain service based on the detection result, wherein: under the condition that the first time meets the processing time condition, processing the cross-domain service to obtain a processing result; and determining that the processing result of the cross-domain service comprises processing failure under the condition that the processing time condition is not met at the first time.
First, a processing request for a cross-domain service from a second system is obtained at a first time, via step 41. It will be appreciated that the processing request for the cross-domain service is sent by the second system, and may be processed immediately or put into a cached task sequence waiting for processing. Therefore, the first time point here may be a time point when the first system receives the processing request of the cross-domain service, or a time point when the first system executes the processing request of the cross-domain service according to the order of the tasks in the cache.
The processing request of the cross-domain service may further include a processing time condition for processing the processing request. The processing time condition may be used to define a validity time limit for processing the request. The processing time condition may take various forms. For example, in one embodiment, the processing time condition may be 30 seconds, which represents that the first system is allowed to normally process the cross-domain service only 30 seconds after the time (e.g., 09:20:10 to 09:20:40) from the time when the second system initiates the processing request to the first system (e.g., 09:20:10 seconds at 9 am). Those skilled in the art will readily understand that the time when the second system initiates the processing request to the first system may be obtained by a timestamp in the processing request, and will not be described herein again. For another example, in another embodiment, the processing time condition may be a deadline (e.g., 09:20:40) indicating a latest time at which the first system can normally process the cross-domain service. In practice, the processing time condition may also be a condition expressed by various other ways, which are not illustrated here.
Next, in step 42, it is checked whether the first time meets the processing time condition. It will be appreciated that since the processing time condition may be used to determine a validity time limit for the processing request, it may be determined whether the processing request is valid by whether the processing time condition is satisfied at the first time.
In one embodiment, detecting whether the first time meets the processing time condition may be performed by determining whether the first time falls within a time range defined by the processing time condition. For example, in the case where the processing time condition is that the first system is allowed to process the corresponding cross-domain service within 30 seconds from the transmission of the processing request from the second system, the time range for processing the cross-domain service may be determined to be 09:20:10 to 09:20:40, depending on the time instant of the transmission of the processing request from the second system, such as 09:20:10, and the processing time condition. At this time, it may be detected whether the first time falls within the time range 09:20:10 to 09:20: 40. If the time difference falls into the first time, the detection result is that the processing time condition is met at the first time, otherwise, the detection result can be that the processing time condition is not met.
In another embodiment, detecting whether the first time meets the processing time condition may be performed by determining whether the first time falls within a latest processing time defined by the processing time condition. At this time, a latest time (e.g. 09:20:40) allowing the cross-domain service to be processed may be determined according to the processing time condition, then the first time (e.g. 09:20:35) is compared with the latest time, and if the first time is earlier than the latest time, it is determined that the first time satisfies the processing time condition, otherwise, it is determined that the first time does not satisfy the processing time condition.
In other embodiments, detecting whether the first time meets the processing time condition may also be performed in other reasonable manners, which is not described herein again. It should be noted that, in the above specific example, the time is calculated in the unit of the minimum of seconds, and in practice, in order to make the processing time condition more accurate, the time may also be calculated in the unit of milliseconds, microseconds, and the like, which is not limited in the embodiment of the present specification.
Further, it is possible to determine whether the processing request is valid or not based on the above detection result. In general, a processing request is determined to be valid in a case where the processing time condition is satisfied at the first timing, and the processing request is determined to be invalid in a case where the processing time condition is not satisfied at the first timing. However, depending on the setting of the process time conditions, the opposite conclusion may also be reached. For example, if the processing time condition is "later than 09:20:40, the cross-domain service is not processed any more", in the case where the processing time condition "later than 09:20: 40" is satisfied at the first time, it is determined that the processing request is invalid.
Then, in step 43, a processing result of the cross-domain service is obtained according to the detection result. It is understood that if the processing request is valid, the first system may process the cross-domain service related to the processing request normally, otherwise, the cross-domain service is not processed any more.
On one hand, in the case that the processing request is valid, the processing result occurring in the normal processing of the cross-domain service may include: process success or process failure. For example, when the cross-domain service is a payment service, the first system needs to increase or decrease the account balance corresponding to each account in the database by a corresponding value. If the database is operated normally, the processing result may be processing success, but if the conditions such as the database being inaccessible and the account balance corresponding to the user being decreased by the corresponding value becomes a negative value occur, the processing result may be processing failure.
On the other hand, in the case where the processing request is invalid, the first system may not process the cross-domain service. At this time, it may be determined that the result of the processing of the cross-domain service includes a processing failure. It should be noted that the processing failure may be expressed in various ways, such as a deduction failure, an expiration of a request, and the like.
Therefore, when acquiring the processing request of the cross-domain service, the first system can firstly judge whether the processing request is valid according to the processing time condition contained in the processing request, and acquire the processing result of the cross-domain service according to whether the processing request is valid, thereby avoiding the situations of processing request receiving lag and indefinite processing caused by network or hardware equipment.
According to one embodiment, the method for processing a cross-domain service request may further include the steps of:
receiving a query request aiming at the cross-domain service from the second system at a second time, wherein the query request is sent from the second system at a third time which is later than the latest time allowed to process the cross-domain service and is limited by a processing time condition; and acquiring a query result of the cross-domain service processing condition, and feeding back the query result to the second system.
It can be understood that, at a third time after a certain time interval after the second system sends the processing request for the cross-domain service to the first system, the second system may also send an inquiry request for the cross-domain service to the first system to determine the processing condition of the cross-domain service, and perform subsequent data processing according to the processing condition of the cross-domain service. Wherein, in order to ensure that the first system starts to process the cross-domain service within the effective time limit of processing the request and can obtain the corresponding processing result for querying, the third time may be a time which is not within the effective time limit. For example, the third time may be later than the latest time allowed to process the cross-domain service defined by the processing time condition.
And at the second moment, the first system receives the query request sent by the second system, and at the moment, the first system can query the cross-domain service. Specifically, the method comprises the following steps:
on one hand, if the second time is earlier than the first time, that is, the first system has not processed the cross-domain service and has not recorded the processing result of the cross-domain service, the first system may return information such as request timeout, no received related service request, no processing or waiting for processing, processing failure and the like to the second system as the query result;
on the other hand, in the case that the second time is later than the first time, if the processing request is valid, and the first system has already processed the cross-domain service and obtained a processing result, which may be a processing success or a processing failure, the first system may return the processing result of the processing request to the second system as a query result. If the processing request is valid, but the first system is still processing the cross-domain service, the first system may return a query result, such as in-process. The first system may also return query results, such as processing failures, to the second system if the processing request is invalid.
In some implementations, if the query result is a certain processing result, such as processing success, processing failure, non-reception, etc., the second system may terminate the query, and if the query result is processing, etc., the second system may continue to send the query request to the first system until the certain processing result is queried.
The query request is sent by the second system after the effective time limit of the request processing, so that the phenomenon of data confusion caused by processing the cross-domain service after the processing request is received after the determined processing result is queried can be further avoided.
FIG. 5 illustrates a flow diagram of a method for requesting a cross-domain service, according to one embodiment. The cross-domain service is a service occurring between two systems, such as a payment service occurring between an online shopping platform and an online payment platform, a deposit and withdrawal service occurring between a front subsystem and an accounting subsystem of a certain banking system, and the like. Here, the online shopping platform and the online payment platform are two systems, for example, a first system and a second system shown in fig. 1 to 3, respectively. The execution subject of the method may be the second system shown in fig. 1 to 3, and the like. The second system may be any system, device, apparatus, platform, or server having computing, processing capabilities. It should be clear that the process of querying the cross-domain service is applicable to a process in which after a predetermined time interval (e.g., 30 seconds) elapses after the second system sends a request for processing a certain cross-domain service to the first system, the second system queries the processing state of the cross-domain service to the first system.
As shown in fig. 5, the method comprises the steps of: step 51, sending a processing request of the cross-domain service to the first system, wherein the processing request comprises a processing time condition for processing the cross-domain service; step 52, determining an inquiry starting time for the cross-domain service based on the processing time condition, wherein the inquiry starting time is not earlier than the latest time which is determined by the processing time condition and allows the first system to process the cross-domain service; and 53, sending a query request to the first system according to the query starting time to obtain a query result of the first system on the cross-domain service processing condition.
First, in step 51, a request for processing a cross-domain service is sent to a first system, where the request includes a processing time condition for processing the cross-domain service. In this embodiment, when the second system sends a processing request of the cross-domain service to the first system, a processing time condition may be included in the processing request, so that the first system determines the validity time limit of the processing request. For example, the first system may determine an effective time limit or a latest time for processing the cross-domain service according to the processing time condition.
When sending a processing request of a cross-domain service to the first system, the second system may first obtain the cross-domain service, determine a processing time condition according to a preset processing time condition generation rule (for example, adding 30 seconds to the current time as the latest processing time, etc.), or artificially specify the processing time, and generate the processing request of the cross-domain service by using the cross-domain service and the processing time condition. The processing request may be various request messages in a format agreed by a determined communication protocol between network devices, for example, an HTTP request, an android-HTTP asynchronous request, and the like, which is not limited in this embodiment of the present specification.
Next, at step 52, a query start time for the cross-domain service is determined based on the processing time condition. It is understood that the query start time is the time at which the query is started. That is, the query for the cross-domain service may be one time or multiple times, and the query start time may be the time when the query request is first initiated. It can be appreciated that, in order to ensure that the first system does not start processing the corresponding cross-domain service after receiving the query request sent by the second system, the second system may first determine that the query start time for initiating the query request is not earlier than the latest time for allowing the first system to process the cross-domain service.
Then, in step 53, a query request is sent to the first system according to the query start time, so as to obtain a query result of the first system for the cross-domain service processing condition. Wherein the query result can be used for the progress status of the cross-domain service. For example, in the case that the first system does not receive a processing request of the corresponding cross-domain service, the query result may be that no processing request is received. In a case where the first system receives a processing request of a corresponding cross-domain service, the query result may be a processing result of the cross-domain service, which is obtained by the first system according to a processing time condition. At this time, the processing result may be a processing success or a processing failure. For example, if the first system acquires a processing request of the corresponding cross-domain service, and determines that the acquisition time does not meet the processing time condition, the processing request is invalid, and the first system may determine that the processing result of the corresponding cross-domain service is a processing failure. If the obtaining time meets the processing time condition through judgment, the processing request is valid, and the first system processes the cross-domain service. In the process of processing the cross-domain service by the first system, if the processing is successfully completed, the processing result may be a processing success, otherwise (for example, a database operation fails, etc.), the processing result may be a processing failure.
In one embodiment, when the query request arrives at the first system, the first system may also be processing corresponding cross-domain traffic, at which point the query result may also be a result such as "processing," "data exception," "server busy," and so on.
According to one embodiment, the second system sends the query request only once. The query may be stopped after receiving any query results. If a query result that the first system is processing the corresponding cross-domain service is received, a request for service termination may also be sent to the first system.
According to another embodiment, the second system may send the query request multiple times. For example, a query request may be sent to the first system in a loop starting from a query start time until a predetermined query result for a cross-domain service is received. The predetermined query result may be, for example, a query result of processing success, processing failure, non-receipt, or the like. In this way, in the event that a query result such as "in progress" is received, cross-domain traffic may continue to be processed by the first system until processing is complete.
It is to be understood that the query result or the processing result such as "processing success", "processing failure", "processing" in this specification embodiment is only one expression of the result status, and other expressions may be used in practice, and this is not limited in this specification embodiment.
It is noted that the embodiment shown in fig. 4 and the embodiment shown in fig. 5 are adapted to a first system and a second system, respectively, where cross-domain traffic occurs. The second system and the first system are respectively used as one end for requesting and processing the cross-domain service, and some information interaction is realized in the process of completing the cross-domain service in a matching way, so some concepts and processes can be mutually adapted or supplemented.
It should be noted that the processing module for processing the cross-domain service and the query module for processing the query request by the first system may be disposed together or separately. For example, the processing module may write the processing results to a database, the query system only queries against a database, and so on.
Reviewing the above procedure, for cross-domain traffic occurring between the first system and the second system, by setting a processing time condition at the time of sending a processing request: on one hand, when a party receiving the processing request obtains the processing request, whether the processing request is effective is detected according to the processing time condition, and a processing result is obtained according to whether the processing request is effective; on the other hand, the side sending the processing request can determine the query starting time for starting sending the query request according to the processing time condition, so as to avoid the result query of the cross-domain service to the other side under the condition that the processing request is still effective, and the results of the two sides are inconsistent. Therefore, the phenomenon of time sequence confusion possibly occurring in the cross-domain service can be avoided, and the service state records of the cross-domain service in the first system and the second system are consistent. Further, the effectiveness of cross-domain services is improved.
According to another aspect of the embodiment, a device for processing cross-domain service request is also provided. Cross-domain services include services that occur between a first system and a second system. Fig. 6 shows a schematic block diagram of an apparatus for handling a cross-domain service request according to one embodiment. The apparatus 600 may be adapted to the first system shown in fig. 1-3.
As shown in fig. 6, the apparatus 600 for processing a cross-domain service request includes: the acquiring unit 61 is configured to acquire, at a first time, a processing request for the cross-domain service from the second system, where the processing request includes a processing time condition for processing the processing request, and the processing time condition is used to determine an effective time limit of the processing request; a detection unit 62 configured to detect whether the first timing satisfies a processing time condition; the processing unit 63 is configured to obtain a processing result of the cross-domain service according to the detection result, wherein the cross-domain service is processed to obtain the processing result when the first time meets a processing time condition; and under the condition that the processing time condition is not met at the first moment, determining that the cross-domain service processing fails.
According to an embodiment, the detection unit 62 may further be configured to: determining the latest time allowed to process the cross-domain service according to the processing time condition; comparing the first time with the latest time; determining that the first time meets a processing time condition under the condition that the first time is earlier than the latest time; otherwise, determining that the first time does not satisfy the processing time condition.
According to one possible design, the apparatus 600 further includes a query unit (not shown). The query unit may be configured to: receiving a query request aiming at the cross-domain service from the second system at a second time, wherein the query request is sent from the second system at a third time which is later than the latest time allowed to process the cross-domain service and is limited by a processing time condition; and acquiring a query result of the cross-domain service, and feeding back the query result to the second system.
According to one implementation, in the case that the second time is earlier than the first time, the query result obtained by the query unit may include one of the following: the corresponding processing request is not received; the processing fails; wait for processing
According to another implementation, in the case that the second time is later than the first time, if the processing request is valid and the processing unit 63 has processed the cross-domain service and obtained the processing result, the processing result may be a processing success or a processing failure. If the processing request is valid, but processing unit 63 is still processing the cross-domain service, the first system may return a query result such as in-process. The querying unit may also obtain a processing result such as a processing failure determined by the processing unit 63 as a query result if the processing request is invalid.
It should be noted that the apparatus 600 shown in fig. 6 is an apparatus embodiment corresponding to the method embodiment shown in fig. 4, and the corresponding description in the method embodiment shown in fig. 4 is also applicable to the apparatus 600, and is not repeated herein.
According to an embodiment of another aspect, the present specification further provides a query device for cross-domain services. Cross-domain services include services that occur between a first system and a second system. Fig. 7 shows a schematic block diagram of a querying device for cross-domain services according to one embodiment. The apparatus 700 may be adapted to the second system shown in fig. 1-3.
As shown in fig. 7, the query device 700 for cross-domain services includes: a sending unit 71, configured to send a processing request of a cross-domain service to a first system, where the processing request includes a processing time condition for processing the cross-domain service; a determining unit 72 configured to determine a query start time for the cross-domain service based on the processing time condition, wherein the query start time is not earlier than a latest time for allowing the first system to process the cross-domain service determined by the processing time condition; the sending unit 71 is further configured to send a query request to the first system according to the query start time, so as to obtain a query result of the first system for the cross-domain service.
In one embodiment, the query result may include a processing result of the cross-domain service acquired by the first system according to the processing time condition.
In another embodiment, the query result may include a result that the first system does not receive the request for processing the cross-domain service.
According to one possible design, the sending unit 71 may be further configured to: and circularly sending the query request to the first system from the query starting time until receiving a preset query result of the cross-domain service.
It should be noted that the apparatus 700 shown in fig. 7 is an apparatus embodiment corresponding to the method embodiment shown in fig. 5, and the corresponding description in the method embodiment shown in fig. 5 is also applicable to the apparatus 700, and is not repeated herein.
With the above apparatuses 600 and 700, respectively provided in the two systems shown in fig. 1 to 3, a processing time limit is defined for the cross-domain service based on the setting of the processing time condition. Therefore, the cross-domain service is not processed outside the processing time limit, and the query to the cross-domain service is not sent out within the processing time limit. Therefore, the service time limit is orderly managed, two systems with cross-domain services are kept consistent, and the effectiveness of cross-domain service processing is improved.
According to an embodiment of another aspect, there is also provided a computer-readable storage medium having stored thereon a computer program which, when executed in a computer, causes the computer to perform the method described in connection with fig. 4 or 5.
According to an embodiment of yet another aspect, there is also provided a computing device comprising a memory and a processor, the memory having stored therein executable code, the processor, when executing the executable code, implementing the method described in connection with fig. 4 or fig. 5.
Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the present invention should be included in the scope of the present invention.