CN116208470A - Service calling method, device and medium - Google Patents

Service calling method, device and medium Download PDF

Info

Publication number
CN116208470A
CN116208470A CN202310177240.8A CN202310177240A CN116208470A CN 116208470 A CN116208470 A CN 116208470A CN 202310177240 A CN202310177240 A CN 202310177240A CN 116208470 A CN116208470 A CN 116208470A
Authority
CN
China
Prior art keywords
service
unit
call failure
determining
target standby
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310177240.8A
Other languages
Chinese (zh)
Inventor
关海超
夏龙飞
颜高飞
李剑
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Industrial and Commercial Bank of China Ltd ICBC
Original Assignee
Industrial and Commercial Bank of China Ltd ICBC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Industrial and Commercial Bank of China Ltd ICBC filed Critical Industrial and Commercial Bank of China Ltd ICBC
Priority to CN202310177240.8A priority Critical patent/CN116208470A/en
Publication of CN116208470A publication Critical patent/CN116208470A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The application provides a service calling method, service calling equipment and a service calling medium. The method comprises the following steps: receiving service call failure information, wherein the service call failure information comprises a failed service call request; determining a call failure unit corresponding to the service call failure information; determining a target standby unit corresponding to the call failure unit from a plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit; and forwarding the service call request to the target standby unit so that the target standby unit can complete the corresponding service call again according to the service call request. The method improves the success rate of re-calling after the primary calling of the service fails.

Description

Service calling method, device and medium
Technical Field
The present invention relates to the field of big data, and in particular, to a service calling method, device, and medium.
Background
The deployment of multiple places and multiple rooms is a necessary development direction of an internet system, and can solve the problems of flow allocation, data splitting, time delay and the like.
In the prior art, unitized application service equipment is commonly used for deployment of multiple places and multiple machine rooms. A unit (i.e., a deployment unit of a unitized application service device) refers to a self-contained set that can perform all business operations, including all services required for all business, and data assigned to the unit. Generally, after receiving a service call request sent by a control unit of the unitized application service device, the unit calls a corresponding service to complete a corresponding business operation. There are typically multiple services in a unit, and each service also typically has multiple operational bits to meet the different service needs of multiple users. However, the unit may fail to call the service due to a failure or full service operation bit, and the unit may recall the corresponding data service in order to ensure normal operation of the service. In the prior art, if the service call fails, the unit will re-perform the random service call, but because the random service call is easy to be random to the unit which is originally failed or has full service operation bit, the success rate of the service re-call is low, thereby causing the service operation failure.
Therefore, a service call scheme with high success rate is required for re-invoking after service invocation failure.
Disclosure of Invention
The application provides a service calling method, equipment and medium, which are used for solving the technical problem of low success rate of recall after primary service call failure in the prior art.
In a first aspect, the present application provides a service invocation method applied to a unitized application service device, where the unitized application service device includes multiple sets of processing units that are mutually backup, where services in two processing units that are mutually backup are the same, and the method includes:
receiving service call failure information, wherein the service call failure information comprises a failed service call request;
determining a call failure unit corresponding to the service call failure information;
determining a target standby unit corresponding to the call failure unit from a plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit;
and forwarding the service call request to the target standby unit so that the target standby unit can complete corresponding service call again according to the service call request.
In a possible implementation manner, the determining the call failure unit corresponding to the service call failure information specifically includes:
Determining a call failure unit corresponding to the service call failure information according to the failure unit identification in the service call failure information;
or alternatively, the process may be performed,
determining a failed service identifier in the service call failure information; and determining a call failure unit corresponding to the service call failure information according to the processing unit where the failure service identifier is located.
In one possible implementation manner, the determining, from the plurality of processing units, the target standby unit corresponding to the call failure unit specifically includes:
and determining the target standby unit corresponding to the call failure unit from a plurality of processing units according to the corresponding relation among the preset standby units.
In a possible implementation manner, the forwarding the service call request to the target standby unit specifically includes:
determining whether the communication type of the unitized application service equipment is a communication closed type, wherein the communication closed type is a type which does not allow communication between different processing units;
if yes, forwarding the service call request to the target standby unit according to a preset transmission protocol, wherein the preset transmission protocol is a transmission protocol for communication between different processing units;
If not, forwarding the service call request to the target standby unit according to the point-to-point communication.
In a possible implementation manner, the forwarding the service call request to the target standby unit according to the point-to-point communication specifically includes:
determining a service identifier of a service to be called in the service call request;
determining a corresponding communication receiving point in the target standby unit according to the service identifier of the service to be invoked;
and forwarding the service call request to the target standby unit according to the communication receiving point.
In a possible implementation manner, the determining, according to the service identifier of the service to be invoked, a corresponding communication receiving point in the target standby unit specifically includes:
determining a service operation position corresponding to the service identifier of the service to be called in the target standby unit;
according to a load balancing strategy, determining available service operation bits to be communicated from service operation bits corresponding to the service identification; or, determining available service operation bits to be communicated from the service operation bits corresponding to the service identifiers at random;
and determining a corresponding communication receiving point in the target standby unit according to the available service operation bit to be communicated.
In one possible implementation manner, after receiving the service invocation failure information, the method further includes:
outputting service call failure prompt information, wherein the service call failure prompt information comprises one or more of text information, sound information, graphic information and lamplight information.
In a second aspect, the present application provides a unitized application service device, including multiple sets of processing units that are mutually backup, where services in two processing units that are mutually backup are the same, and the unitized application service device further includes:
the receiving module is used for receiving service call failure information, wherein the service call failure information comprises a failed service call request;
the processing module is used for determining a call failure unit corresponding to the service call failure information; determining a target standby unit corresponding to the call failure unit from the plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit; and forwarding the service call request to the target standby unit so that the target standby unit can complete corresponding service call again according to the service call request.
In a third aspect, the present application provides a unitized application service device, comprising: a processor, and a memory communicatively coupled to the processor;
The memory stores computer-executable instructions;
the processor executes the computer-executable instructions stored in the memory to implement the methods described above.
In a fourth aspect, the present application provides a computer-readable storage medium having stored therein computer-executable instructions for performing the method described above when executed by a processor.
In a fifth aspect, the present application provides a computer program product comprising a computer program which, when executed by a processor, implements the method described above.
The service call method, the device and the medium can receive service call failure information, wherein the service call failure information comprises a service call request; determining a call failure unit corresponding to the service call failure information; determining a target standby unit corresponding to the call failure unit from a plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit; and forwarding the service call request to the target standby unit so that the target standby unit can complete the corresponding service call again according to the service call request. According to the method, after the corresponding call failure unit is determined according to the service call failure information, the target standby unit corresponding to the call failure unit can be determined. Due to the characteristics of a group of processing units which are mutually backed up in the unitized application service equipment, the services in the two processing units which are mutually backed up are the same, namely the target standby unit is the same as the service in the call failure unit. Therefore, after the call failure unit fails to call the service for the first time, the service call request can be forwarded to the target standby unit, so that the target standby unit can complete the corresponding service call again according to the service call request. After the primary calling of the service fails, the processing unit is not selected randomly to perform the service re-calling, but the standby processing unit corresponding to the calling failure unit is utilized to perform the service re-calling, so that the calling failure unit which is failed or the service operation position is full at random during the re-calling can be avoided through the setting, the success rate of the service re-calling can be ensured by utilizing the characteristics of the standby processing unit, and the success of the service calling is ensured, so that the subsequent service operation is facilitated.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.
FIG. 1 is a schematic diagram of a prior art process for intra-cell service invocation of a unitized application service device;
FIG. 2 is a schematic diagram illustrating a process of intercell service invocation for a unitized application service device according to the prior art;
FIG. 3 is a flow chart of a service invocation method according to an embodiment of the present application;
FIG. 4 is a schematic diagram illustrating a process of intra-cell service invocation of a unitized application service device according to one embodiment of the present application;
FIG. 5 is a schematic diagram illustrating a process of inter-element service invocation of a unitized application service device according to one embodiment of the present application;
FIG. 6 is a flow chart of a service invocation method according to another embodiment of the present application;
FIG. 7 is a schematic structural diagram of a unitized application service device according to one embodiment of the present application;
fig. 8 is a schematic structural diagram of a unitized application service device according to another embodiment of the present application.
Specific embodiments thereof have been shown by way of example in the drawings and will herein be described in more detail. These drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the accompanying claims.
A unit (i.e., a deployment unit of a unitized application service product layer) refers to a self-contained collection of all business operations that contains all the services required for all the business, as well as the data assigned to the unit.
The unitized architecture is to use units as basic units for deployment, deploy a plurality of units in all machine rooms of a total station, wherein the number of units in each machine room is not fixed, any unit deploys all applications required by the system, and the data is a part of the total data after being divided according to a certain dimension.
It should be noted that the service calling method, device and medium of the present application may be used in the big data field. And can be used in any field except the big data field. The application fields of the service calling method, the device and the medium are not limited.
It should be further noted that, the user information (including, but not limited to, user equipment information, user personal information, etc.) and the data (including, but not limited to, data for analysis, stored data, presented data, etc.) referred to in the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data is required to comply with the related laws and regulations and standards of the related country and region, and is provided with a corresponding operation entry for the user to select authorization or rejection.
In the prior art, unitized application service equipment is commonly used for deployment of multiple places and multiple machine rooms. A unit (i.e., a deployment unit of a unitized application service device) refers to a self-contained set that can perform all business operations, including all services required for all business, and data assigned to the unit. Generally, after receiving a service call request sent by a control unit of the unitized application service device, the unit calls a corresponding service to complete a corresponding business operation. There are typically multiple services in a unit, and each service also typically has multiple operational bits to meet the different service needs of multiple users. However, the unit may fail to call the service due to a failure or full service operation bit, and the unit may recall the corresponding data service in order to ensure normal operation of the service.
For example, fig. 1 is a schematic diagram of a process of invoking a service in a unit of a certain unitized application service device in the prior art, as shown in fig. 1, after receiving a service operation request sent by a user terminal, the unit 1 determines, according to the service operation request, that a related service to be invoked is a service a of the unit, and sends a service invocation request to an operation bit of the service a of the unit, so as to invoke the service a at will from operation bits of a plurality of service a. If unit 1 fails at this time or the operation bit of service a is full, unit 1 cannot complete the call of service a. At this time, the unit 1 randomly calls the service a from the operation bits of the plurality of services a again to perform the service readjustment.
Illustratively, fig. 2 is a schematic diagram illustrating a procedure of inter-unit service call of a unitized application service device in the prior art, where the unitized application service device includes four units, namely, unit 1, unit 2, unit 3, and unit 4. As shown in fig. 2, after receiving a service operation request sent by a user terminal, the unit 1 determines that the service a in the unit 2 needs to be invoked according to the service operation request, and sends a service invocation request to an operation bit of the service a in the unit 2. If unit 2 fails at this time or the operation bit of service a of unit 2 is full, unit 1 cannot complete the call of service a. At this time, the unit 1 randomly selects and calls the service a of any one of the units 2, 3 and 4 to perform the readjustment of the service.
However, since such random service calls are easily random to units that have failed or are full of service operation bits, the success rate of service recall is low, resulting in failure of service operation. When the call is in the unit shown in fig. 1, if the unit 1 fails to call the service a therein, this indicates that the unit 1 itself fails, or the operation bit of the service a in the unit 1 is full, and when the call is readjusted, even if the unit 1 randomly calls a certain operation bit of the service a therein again, the success rate is not high, unless the unit 1 is just repaired at this time, or the service a just vacates the operation bit. In the case of call between units shown in fig. 2, if the unit 1 fails to call the service a of the unit 2, it means that the unit 2 itself fails, or the operation bit of the service a in the unit 2 is full, and the call is random when being re-tuned, so that there is a high probability that the call will be random to the unit 2 which fails originally.
Based on the technical problem, the invention concept of the application is as follows: how to provide a service calling method with high success rate after service calling failure.
Specifically, service call failure information may be received, where the service call failure information includes a service call request; determining a call failure unit corresponding to the service call failure information; determining a target standby unit corresponding to the call failure unit from a plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit; and forwarding the service call request to the target standby unit so that the target standby unit can complete the corresponding service call again according to the service call request. According to the method, after the corresponding call failure unit is determined according to the service call failure information, the target standby unit corresponding to the call failure unit can be determined. Due to the characteristics of a group of processing units which are mutually backed up in the unitized application service equipment, the services in the two processing units which are mutually backed up are the same, namely the target standby unit is the same as the service in the call failure unit. Therefore, after the call failure unit fails to call the service for the first time, the service call request can be forwarded to the target standby unit, so that the target standby unit can complete the corresponding service call again according to the service call request. After the primary calling of the service fails, the processing unit is not selected randomly to perform the service re-calling, but the standby processing unit corresponding to the calling failure unit is utilized to perform the service re-calling, so that the calling failure unit which is failed or the service operation position is full at random during the re-calling can be avoided through the setting, the success rate of the service re-calling can be ensured by utilizing the characteristics of the standby processing unit, and the success of the service calling is ensured, so that the subsequent service operation is facilitated.
The following describes the technical solutions of the present application and how the technical solutions of the present application solve the above technical problems in detail with specific embodiments. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.
Example 1
Fig. 3 is a flowchart of a service calling method provided in an embodiment of the present application, where an execution body is a processing unit of a unitized application service device to describe the service calling method, and the unitized application service device includes multiple groups of processing units that are mutually backup, where services in two processing units that are mutually backup are the same. As shown in fig. 3, the service invocation method may include the steps of:
s101: and receiving service call failure information, wherein the service call failure information comprises a failed service call request.
In this embodiment, after a user consumes or orders a certain product, a user terminal sends a service operation request to a unitized application service device, and after a processing unit in the unitized application service device that processes the user service receives the service operation request, a relevant service to be invoked is determined according to the service operation request, and a service invocation request is sent to an operation position of the service to be invoked, so that the service is invoked to perform a corresponding service operation. If the service fails to be called due to unit failure or the operation bit is full, the operation bit of the service to be called can send service call failure information to the processing unit so as to prompt the processing unit to perform service readjustment.
In this embodiment, the unitized application service device may include a plurality of processing units, and each two of the processing units are combined to form a group that is mutually backed up, that is, one processing unit corresponds to only one standby unit, and services in two processing units that are mutually backed up are the same.
In one possible embodiment, after receiving the service invocation failure information in the step S101, the method may further include: outputting service call failure prompt information, wherein the service call failure prompt information comprises one or more of text information, sound information, graphic information and lamplight information.
In this embodiment, the service call failure prompt information may include a unit identifier of the call failure unit, so that an operator or an operation and maintenance person overhauls the call failure unit in time according to the unit identifier.
In this embodiment, after receiving the service call failure information, the control module of the processing unit may output a service call failure prompt message to prompt an operator or an operation and maintenance person to check the processing unit with the service call failure in time, and determine whether a failure occurs, so as to process in time, thereby avoiding that the service operation cannot be processed in time.
S102: and determining a call failure unit corresponding to the service call failure information.
In this embodiment, since the service call may be an intra-unit call or an inter-unit call, it is also necessary to determine a call failure unit corresponding to the service call failure information.
In one possible implementation manner, the determining, in step S102, the call failure unit corresponding to the service call failure information may include: and determining a calling failure unit corresponding to the service calling failure information according to the failure unit identification in the service calling failure information.
In this embodiment, the unit identifier may be flexibly set by a person skilled in the art, for example, the unit identifier may be a text identifier or a graphic identifier, or may be any other identifier, as long as the unit identifier can distinguish different units.
In this embodiment, the service call failure information may include a failed unit identifier of a service call failure, and according to a preset correspondence between the unit identifier and the processing unit, a call failure unit corresponding to the failed unit identifier, that is, a call failure unit corresponding to the service call failure information, may be simply and accurately determined.
In one possible embodiment, the determining, in step S102, the call failure unit corresponding to the service call failure information may further include: determining a failed service identifier in the service call failure information; and determining a call failure unit corresponding to the service call failure information according to the processing unit where the failed service identifier is located.
In this embodiment, the service identifier may be flexibly set by a person skilled in the art, for example, the service identifier may be a text identifier or a graphic identifier, or may be any other identifier, as long as the service identifier can distinguish different services in different processing units.
In this embodiment, the service call failure information may include a failed service identifier of a service call failure, and according to a preset correspondence between the service identifier and the processing unit, a call failure unit where the failed service identifier is located, that is, a call failure unit corresponding to the service call failure information, may be simply and accurately determined.
S103: and determining a target standby unit corresponding to the call failure unit from the plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit.
In a possible implementation manner, the determining, from the multiple processing units in step S103, the target standby unit corresponding to the call failure unit may include: and determining a target standby unit corresponding to the call failure unit from the plurality of processing units according to the corresponding relation among the preset standby units.
In this embodiment, the correspondence relationship between the standby units may be each set of processing units that are preset in the unitized application service device and are mutually backed up. An even number of processing units are usually disposed in the unitized application service device, and the processing units are mutually standby, for example, a unitized application service device includes four units, namely, unit 1, unit 2, unit 3 and unit 4, where unit 1 and unit 3 are standby units, and unit 2 and unit 4 are standby units.
In this embodiment, the target standby unit corresponding to the call failure unit can be simply and accurately determined by using the correspondence between the standby units preset in the unitized application service device.
S104: and forwarding the service call request to the target standby unit so that the target standby unit can complete the corresponding service call again according to the service call request.
In this embodiment, the specific implementation of forwarding the service call request to the target standby unit in step S104 is described in detail in embodiment two.
In this embodiment, after the service call request is forwarded to the target standby unit, the target standby unit calls the corresponding service according to the service call request, and sends the service to the processing unit, so that the processing unit completes the related business operation according to the service.
Fig. 4 is a schematic process diagram of intra-unit service call of a unitized application service device according to an embodiment of the present application, where the unitized application service device includes four units, namely, unit 1, unit 2, unit 3, and unit 4, and unit 1 and unit 3 are mutually standby, and unit 2 and unit 4 are mutually standby. As shown in fig. 4, after receiving a service operation request sent by a user terminal, the unit 1 determines, according to the service operation request, that a related service to be invoked is a service a of the unit, and sends a service invocation request to an operation bit of the service a of the unit, so as to invoke the service a at will from a plurality of operation bits of the service a. If unit 1 fails at this time or the operation bit of service a is full, unit 1 cannot complete the call of service a. At this time, the unit 1 determines that the target standby unit corresponding to the call failure unit is the unit 3, and forwards the service call request to the unit 3, so as to complete the call of the service a.
Fig. 5 is a schematic process diagram of an inter-unit service call of a unitized application service device according to an embodiment of the present application, where the unitized application service device includes four units, namely, a unit 1, a unit 2, a unit 3, and a unit 4, and the unit 1 and the unit 3 are mutually standby, and the unit 2 and the unit 4 are mutually standby. As shown in fig. 5, after receiving a service operation request sent by a user terminal, the unit 1 determines that the service a in the unit 2 needs to be invoked according to the service operation request, and sends a service invocation request to an operation bit of the service a in the unit 2. If the unit 2 fails at this time or the operation bit of the service a of the unit 2 is full, the operation bit of the service a in the unit 2 sends service call failure information to the unit 1. After the unit 1 receives the call failure unit corresponding to the service call failure information is determined to be the unit 2, and the target standby unit corresponding to the unit 2 is determined to be the unit 4 according to the corresponding relation between the preset standby units. Unit 1 forwards the service invocation request to unit 4 to complete the invocation of service a.
In this embodiment, service call failure information may be received, where the service call failure information includes a service call request; determining a call failure unit corresponding to the service call failure information; determining a target standby unit corresponding to the call failure unit from a plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit; and forwarding the service call request to the target standby unit so that the target standby unit can complete the corresponding service call again according to the service call request. According to the method, after the corresponding call failure unit is determined according to the service call failure information, the target standby unit corresponding to the call failure unit can be determined. Due to the characteristics of a group of processing units which are mutually backed up in the unitized application service equipment, the services in the two processing units which are mutually backed up are the same, namely the target standby unit is the same as the service in the call failure unit. Therefore, after the call failure unit fails to call the service for the first time, the service call request can be forwarded to the target standby unit, so that the target standby unit can complete the corresponding service call again according to the service call request. After the primary calling of the service fails, the processing unit is not selected randomly to perform the service re-calling, but the standby processing unit corresponding to the calling failure unit is utilized to perform the service re-calling, so that the calling failure unit which is failed or the service operation position is full at random during the re-calling can be avoided through the setting, the success rate of the service re-calling can be ensured by utilizing the characteristics of the standby processing unit, and the success of the service calling is ensured, so that the subsequent service operation is facilitated.
The following describes in detail the specific implementation manner of forwarding the service call request to the target standby unit in step S104 of the first embodiment with the second embodiment.
Example two
Fig. 6 is a flowchart of a service calling method provided in an embodiment of the present application, where an execution body is a unitized application service device for explaining the service calling method, and the unitized application service device includes multiple groups of processing units that are mutually backup, where services in two processing units that are mutually backup are the same. As shown in fig. 6, the service invocation method may include the steps of:
s201: it is determined whether the communication type of the unitized application service device is a communication closed type, which is a type that does not allow communication between different processing units.
In this embodiment, the communication types of the unitized application service device may be classified into a communication closed type that only allows internal communication of the unit, and a communication open type that does not allow communication between different processing units, and that allows communication between both the unit and the different processing units.
S202: if yes, forwarding the service call request to the target standby unit according to a preset transmission protocol, wherein the preset transmission protocol is a transmission protocol for communication among different processing units.
In this embodiment, if the communication type of the unitized application service device is a communication closed type, that is, communication between different processing units is not allowed, in order to implement a special case of communication between different processing units, a corresponding transmission protocol is preset, so as to implement communication between different processing units.
S203: if not, the service call request is forwarded to the target standby unit according to the point-to-point communication.
In this embodiment, if the communication type of the unitized application service device is a communication open type, the peer-to-peer communication between different processing units is directly required.
In a possible implementation manner, forwarding the service call request to the target standby unit according to the peer-to-peer communication in the step S203 may include: determining a service identifier of a service to be called in a service call request; determining a corresponding communication receiving point in the target standby unit according to the service identifier of the service to be invoked; and forwarding the service call request to the target standby unit according to the communication receiving point.
In this embodiment, the service identifier may be flexibly set by a person skilled in the art, for example, the service identifier may be a text identifier or a graphic identifier, or may be any other identifier, as long as the service identifier can distinguish different services in different processing units.
In this embodiment, when peer-to-peer communication is performed, the communication transmitting point is known, and it is also necessary to determine the communication receiving point, that is, the service to be invoked in the target standby unit. According to the service identification of the service to be called in the service call request, the service to be called in the target standby unit can be determined, so that the communication receiving point is simply and accurately determined, and further the forwarding of the service call request is realized.
In one possible implementation manner, determining the corresponding communication receiving point in the target standby unit according to the service identifier of the service to be invoked may include: determining a service operation position corresponding to a service identifier of a service to be called in a target standby unit; according to the load balancing strategy, determining available service operation bits to be communicated from service operation bits corresponding to the service identification; and determining a corresponding communication receiving point in the target standby unit according to the available service operation bit to be communicated.
In this embodiment, the number of times that the operation bit of the service to be invoked is invoked may be averaged by using the load balancing policy, so that a certain operation bit is not always invoked but a certain operation bit is always invoked.
In this embodiment, when determining the corresponding communication receiving point in the target standby unit, all service operation bits corresponding to the service identifier of the service to be invoked may be first determined, and then the most suitable available service operation bits may be selected from the service operation bits by using a load balancing policy. Through the arrangement, the utilization rate of each service operation position of the service to be called in the target standby unit can be fully considered, the available service operation position which is idle and most likely to be realized can be found, and the success rate of service readjustment is further improved.
In another possible implementation manner, determining the corresponding communication receiving point in the target standby unit according to the service identifier of the service to be invoked may include: determining a service operation position corresponding to a service identifier of a service to be called in a target standby unit; randomly determining available service operation bits to be communicated from service operation bits corresponding to the service identification; and determining a corresponding communication receiving point in the target standby unit according to the available service operation bit to be communicated.
In this embodiment, when determining the corresponding communication receiving point in the target standby unit, all service operation bits corresponding to the service identifier of the service to be invoked may be first determined, and then one of the operation bits is randomly selected as the available service operation bits to be communicated, which is simple and convenient to operate.
In this embodiment, forwarding the service call request from the unit to the target standby unit can only be communication between different units, and in order to achieve this, it is first necessary to determine the communication type of the unitized application service device, and further determine a specific communication manner. The communication types of the unitized application service equipment can be divided into a communication closed type and a communication open type, wherein the communication closed type only allows the internal communication of the unit and does not allow the communication between different processing units, and the communication open type allows the internal communication of the unit and also allows the communication between different processing units. If the communication type of the unitized application service equipment is a communication closed type, that is, communication between different processing units is not allowed, in order to realize the special condition of communication between different processing units, a preset transmission protocol is required to be used for forwarding a service call request to a target standby unit; if the communication type of the unitized application service equipment is not the communication closed type, the service call request is directly forwarded to the target standby unit according to the point-to-point communication. Through the arrangement, a proper communication mode can be selected according to the specific communication type of the unitized application service equipment, so that the success of communication among different processing units is ensured, and the service call request is forwarded from the unit to the target standby unit.
The service invocation method of the present application is described in a specific embodiment below.
Example III
In a specific embodiment, a user orders a product in a bank by using a bank APP in a mobile phone, after the product ordering is successful, the bank APP generates a service operation request according to product ordering related information, and sends the service operation request to a unitized application service device corresponding to the bank, and after a processing unit (unit 1) for processing the user service in the unitized application service device receives the service operation request, a service a in the unit needs to be called according to the service operation request, and a specific service calling process is as follows:
first, the unit 1 sends a service call request to an operation bit of the service a in the unit, where the operation bit of the service a in the unit is full and cannot be called, and the operation bit of the service a sends service call failure information to the unit 1, where the service call failure information includes a failed service call request. After the unit 1 receives the call failure prompt information of the service is output.
And secondly, determining the call failure unit corresponding to the service call failure information as a unit 1 by the unit 1 according to the failure unit identification in the service call failure information, and determining the target standby unit corresponding to the unit 1 as a unit 3 according to the corresponding relation between the preset standby units.
Thirdly, the unit 1 determines that the communication type of the unitized application service equipment is a communication closed type, and forwards the service call request to the unit 3 according to a preset transmission protocol.
Fourth, the unit 3 invokes the service a after receiving it and sends it to the unit 1, so that the unit 1 completes the relevant business operation according to the service a.
Fig. 7 is a schematic structural diagram of a unitized application service device according to an embodiment of the present application, where the unitized application service device includes multiple groups of processing units that are mutually backup, and services in two processing units that are mutually backup are the same, as shown in fig. 7, and the unitized application service device further includes: a receiving module 71, configured to receive service call failure information, where the service call failure information includes a service call request; a processing module 72, configured to determine a call failure unit corresponding to the service call failure information; determining a target standby unit corresponding to the call failure unit from a plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit; and forwarding the service call request to the target standby unit so that the target standby unit can complete the corresponding service call again according to the service call request. In one embodiment, the description of the specific implementation function of the unitized application service device may refer to steps S101 to S104 in the first embodiment and steps S201 to S203 in the second embodiment, which are not described herein.
Fig. 8 is a schematic structural diagram of a unitized application service device according to an embodiment of the present application, as shown in fig. 8, where the unitized application service device includes: a processor 101, and a memory 102 communicatively coupled to the processor 101; memory 102 stores computer-executable instructions; the processor 101 executes computer-executable instructions stored in the memory 102 to implement the steps of the service invocation method in the method embodiments described above.
The unitized application service device may be stand alone or be part of a server, and the processor 101 and memory 102 may employ existing hardware of the server.
In the above-described unitized application service device, the memory 102 and the processor 101 are electrically connected directly or indirectly to realize transmission or interaction of data. For example, the elements may be electrically connected to each other via one or more communication buses or signal lines, such as through a bus connection. The memory 102 stores therein computer-executable instructions for implementing a data access control method, including at least one software functional module that may be stored in the memory 102 in the form of software or firmware, and the processor 101 executes the software programs and modules stored in the memory 102 to thereby perform various functional applications and data processing.
The Memory 102 may be, but is not limited to, random access Memory (Random Access Memory, RAM), read Only Memory (ROM), programmable Read Only Memory (PROM), erasable Read Only Memory (Erasable Programmable Read-Only Memory, EPROM), electrically erasable Read Only Memory (Electric Erasable Programmable Read-Only Memory, EEPROM), etc. The memory 102 is used for storing a program, and the processor 101 executes the program after receiving an execution instruction. Further, the software programs and modules within the memory 102 may also include an operating system, which may include various software components and/or drivers for managing system tasks (e.g., memory management, storage device control, power management, etc.), and may communicate with various hardware or software components to provide an operating environment for other software components.
The processor 101 may be an integrated circuit chip with signal processing capabilities. The processor 101 may be a general-purpose processor, including a central processing unit (Central Processing Unit, abbreviated as CPU), a network processor (Network Processor, abbreviated as NP), and the like. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
An embodiment of the present application further provides a computer-readable storage medium, where computer-executable instructions are stored, where the computer-executable instructions, when executed by a processor, are configured to implement the steps of the method embodiments of the present application.
An embodiment of the present application also provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the method embodiments of the present application.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims (10)

1. A service invocation method, applied to a unitized application service device, where the unitized application service device includes multiple sets of processing units that are mutually backup, where services in two processing units that are mutually backup are the same, the method includes:
receiving service call failure information, wherein the service call failure information comprises a failed service call request;
determining a call failure unit corresponding to the service call failure information;
determining a target standby unit corresponding to the call failure unit from a plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit;
and forwarding the service call request to the target standby unit so that the target standby unit can complete corresponding service call again according to the service call request.
2. The method according to claim 1, wherein the determining the call failure unit corresponding to the service call failure information specifically includes:
determining a call failure unit corresponding to the service call failure information according to the failure unit identification in the service call failure information;
or alternatively, the process may be performed,
determining a failed service identifier in the service call failure information; and determining a call failure unit corresponding to the service call failure information according to the processing unit where the failure service identifier is located.
3. The method according to claim 2, wherein the determining, from the plurality of processing units, the target standby unit corresponding to the call failure unit specifically includes:
and determining the target standby unit corresponding to the call failure unit from a plurality of processing units according to the corresponding relation among the preset standby units.
4. A method according to claim 3, characterized in that said forwarding said service call request to said target standby unit comprises in particular:
determining whether the communication type of the unitized application service equipment is a communication closed type, wherein the communication closed type is a type which does not allow communication between different processing units;
if yes, forwarding the service call request to the target standby unit according to a preset transmission protocol, wherein the preset transmission protocol is a transmission protocol for communication between different processing units;
if not, forwarding the service call request to the target standby unit according to the point-to-point communication.
5. The method of claim 4, wherein forwarding the service invocation request to the target standby unit in accordance with point-to-point communication, comprises:
Determining a service identifier of a service to be called in the service call request;
determining a corresponding communication receiving point in the target standby unit according to the service identifier of the service to be invoked;
and forwarding the service call request to the target standby unit according to the communication receiving point.
6. The method according to claim 5, wherein the determining the corresponding communication receiving point in the target standby unit according to the service identifier of the service to be invoked, specifically includes:
determining a service operation position corresponding to the service identifier of the service to be called in the target standby unit;
according to a load balancing strategy, determining available service operation bits to be communicated from service operation bits corresponding to the service identification; or, determining available service operation bits to be communicated from the service operation bits corresponding to the service identifiers at random;
and determining a corresponding communication receiving point in the target standby unit according to the available service operation bit to be communicated.
7. The method according to any one of claims 1-6, further comprising, after receiving the service invocation failure information:
outputting service call failure prompt information, wherein the service call failure prompt information comprises one or more of text information, sound information, graphic information and lamplight information.
8. A unitized application service device, comprising a plurality of sets of processing units that are backup to each other, wherein services in two processing units that are backup to each other are the same, the unitized application service device further comprising:
the receiving module is used for receiving service call failure information, wherein the service call failure information comprises a failed service call request;
the processing module is used for determining a call failure unit corresponding to the service call failure information; determining a target standby unit corresponding to the call failure unit from a plurality of processing units, wherein the target standby unit is the same as the service in the call failure unit; and forwarding the service call request to the target standby unit so that the target standby unit can complete corresponding service call again according to the service call request.
9. A unitized application service device comprising a processor and a memory communicatively coupled to the processor;
the memory stores computer-executable instructions;
the processor executes computer-executable instructions stored in the memory to implement the method of any one of claims 1 to 7.
10. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method of any one of claims 1 to 7.
CN202310177240.8A 2023-02-28 2023-02-28 Service calling method, device and medium Pending CN116208470A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310177240.8A CN116208470A (en) 2023-02-28 2023-02-28 Service calling method, device and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310177240.8A CN116208470A (en) 2023-02-28 2023-02-28 Service calling method, device and medium

Publications (1)

Publication Number Publication Date
CN116208470A true CN116208470A (en) 2023-06-02

Family

ID=86512519

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310177240.8A Pending CN116208470A (en) 2023-02-28 2023-02-28 Service calling method, device and medium

Country Status (1)

Country Link
CN (1) CN116208470A (en)

Similar Documents

Publication Publication Date Title
CN109802986B (en) Equipment management method, system, device and server
CN110730472B (en) Communication certificate state detection method and server
CN111552568A (en) Cloud service calling method and device
EP2442487B1 (en) Location processing method
CN108810835B (en) Method and device for associating one number with multiple terminals, terminal and storage medium
CN112637338B (en) Method, device, equipment and storage medium for managing node service of Internet of things
CN111159298B (en) Service request processing method and device, electronic equipment and storage medium
CN116208470A (en) Service calling method, device and medium
CN114006911B (en) Data processing method and device, terminal equipment and storage medium
CN110784510A (en) Method for accessing target service node to bus and information interaction method of service node
CN113660121B (en) Information management method and device based on distributed system and computer storage medium
CN111385167B (en) Network connection recovery method, device, computer device and storage medium
CN114500237A (en) Communication method and system
CN112616143B (en) Method and device for distributing communication numbers, electronic equipment and storage medium
CN113676894B (en) Service processing method and equipment
CN111049938B (en) Message notification method and device, electronic equipment and readable storage medium
CN113568669A (en) Service board card starting method based on orthogonal architecture, service board card and orthogonal equipment
CN109981796B (en) Connection method and device
CN113873523A (en) Method and device for removing vehicle binding relationship and related equipment
CN112532509A (en) Cross-application communication method and related device
CN115175165B (en) Auxiliary card number network transfer control method, equipment and storage medium of user identification card
CN115102749B (en) Resource interaction method, device, equipment and storage medium
CN113660288B (en) User number binding method and system based on block chain system
US20230262167A1 (en) Method for processing a request from a communication terminal
CN112866414B (en) Data information pushing method and device, computer equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination