Service request processing method, electronic equipment, storage medium and program product

Abstract

The invention discloses a service request processing method, electronic equipment, a storage medium and a program product. The method comprises the following steps: in response to a received service request, obtaining an entity type and an entity identifier of a service entity used for executing the service request; in response to the fact that the entity type is the first type, the entity running state of the first system is obtained based on the entity identifier, the first service entity is used for executing the service request, and the entity type of the first service entity is the first type; calling a second service entity from a second system based on the entity identifier in response to the fact that the entity running state is that the first service entity runs abnormally; and executing the service request based on the second service entity. According to the invention, the technical problem of low flexibility of service request processing in the related art is solved.

Description

Technical Field

[0001] The present invention relates to the field of data processing, and in particular, to a method for processing service requests, an electronic device, a storage medium, and a program product. Background Art

[0002] With the iteration and development of technologies, business systems also need to be continuously upgraded and updated. With the completion of a new business system using new technologies, the new and old systems usually run in parallel for a period of time. During this period, the new system will gradually become the main system to start receiving traffic externally and providing services, realizing the control and transfer of user traffic to the new system. Correspondingly, the old system will serve as a backup system to provide emergency support and continue to achieve the continuity of the overall business service when the new system fails. Therefore, how to improve the flexibility during service fallback becomes one of the key points when the new and old systems run in parallel.

[0003] For the above problems, no effective solution has been proposed yet. Summary of the Invention

[0004] Embodiments of the present invention provide a method for processing service requests, an electronic device, a storage medium, and a program product, so as to at least solve the technical problem of low flexibility in processing service requests in related technologies.

[0005] According to one aspect of the embodiments of the present invention, a method for processing service requests is provided, including: in response to receiving a service request, obtaining the entity type and entity identifier of a service entity for executing the service request; in response to the entity type being a first type, based on the entity identifier, obtaining the entity running state of a first service entity in a first system, where the first service entity is used to execute the service request and the entity type of the first service entity is the first type; in response to the entity running state being that the first service entity is running abnormally, calling a second service entity from a second system based on the entity identifier, where there is a transfer operation of service entities between the first system and the second system, the first system is used to receive service entities transferred out from the second system, the second system is used to back up service entities successfully transferred to the first system, the second service entity is used to represent a service entity obtained by backing up the first service entity, and the entity type of the second service entity is the first type; executing the service request based on the second service entity.

[0006] Further, the above method further includes: in response to detecting that the first service entity returns to normal, obtaining the request type of the service request; in response to the request type being a read type, calling the first service entity from the first system based on the entity identifier, and executing the service request based on the first service entity.

[0007] Further, the above method further includes: in response to the request type being a write type, obtaining the request status of the service request; in response to the request status being that no system switch instruction has been received, continuing to execute the service request based on the second service entity; in response to the request status being that the system switch instruction has been received, obtaining the current service execution result of the service request, generating a service execution instruction based on the service execution result, and continuing to execute the service request based on the first service entity according to the service execution instruction.

[0008] Further, after executing the service request based on the second service entity, the above method further includes: obtaining the request type of the service request; in response to the request type being a write type, generating a service deletion instruction based on the second service entity, and sending the service deletion instruction to the consistency guarantee component, where the consistency guarantee component is used to ensure the consistency between the first service entity and the second service entity; in response to the first system resuming normal operation, deleting the first service entity in the first system based on the consistency guarantee component.

[0009] Further, after executing the service request based on the second service entity, the above method further includes: updating the entity types of the first service entity and the second service entity respectively according to the second type to obtain a new first service entity and a new second service entity, where the service entity of the second type is used to represent the service entity existing in the second system waiting for the entity transfer operation.

[0010] Further, the above method further includes: in response to the entity type being the second type, invoking a third service entity from the second system based on the entity identifier, where the third service entity is used to represent the service entity not transferred out in the second system; executing the service request based on the third service entity.

[0011] Further, the above method further includes: in response to the entity running state being that the first service entity is running normally, determining that the access states of the first service entity and the third service entity are the first state, and the access state of the second service entity is the second state, where the service entity in the first state can be invoked, and the service entity in the second state cannot be invoked; in response to the entity running state being that the first service entity is running abnormally, determining that the access states of the second service entity and the third service entity are the first state, and the access state of the first service entity is the second state.

[0012] According to another aspect of the embodiments of the present invention, a service request processing device is further provided, including: a parameter acquisition module, configured to acquire the entity type and entity identifier of a service entity for executing a service request in response to receiving the service request; a status acquisition module, configured to acquire the entity running status of a first service entity in a first system based on the entity identifier in response to the entity type being a first type, where the first service entity is used to execute the service request and the entity type of the first service entity is the first type; a first invocation module, configured to invoke a second service entity from a second system based on the entity identifier in response to the entity running status being that the first service entity runs abnormally, where there is a transfer operation of service entities between the first system and the second system, the first system is used to receive the service entities transferred out from the second system, the second system is used to back up the service entities successfully transferred to the first system, the second service entity is used to represent the service entity obtained by backing up the first service entity, and the entity type of the second service entity is the first type; a request execution module, configured to execute the service request based on the second service entity.

[0013] Further, the above device further includes: a first type acquisition module, configured to acquire the request type of the service request in response to detecting that the first service entity returns to normal; a first execution module, configured to invoke the first service entity from the first system based on the entity identifier and execute the service request based on the first service entity in response to the request type being a read type.

[0014] Further, the above device further includes: a request status acquisition module, configured to acquire the request status of the service request in response to the request type being a write type; a second execution module, configured to continue to execute the service request based on the second service entity in response to the request status being that no system switching instruction is received; a third execution module, configured to acquire the current service execution result of the service request and generate a service execution instruction based on the service execution result, and continue to execute the service request based on the first service entity according to the service execution instruction in response to the request status being that the system switching instruction is received.

[0015] Further, the above device further includes: a second type acquisition module, configured to acquire the request type of the service request; an instruction sending module, configured to generate a service deletion instruction based on the second service entity and send the service deletion instruction to a consistency guarantee component in response to the request type being a write type, where the consistency guarantee component is used to ensure the consistency between the first service entity and the second service entity; an entity deletion module, configured to delete the first service entity in the first system based on the consistency guarantee component in response to the first system resuming normal operation.

[0016] Further, the above device further includes: an entity update module, configured to update the entity types of the first service entity and the second service entity respectively according to the second type, to obtain a new first service entity and a new second service entity, where the service entity of the second type is used to represent the service entity existing in the second system and waiting for an entity transfer operation.

[0017] Further, the above production further includes: a third call module, configured to, in response to the entity type being the second type, call a third service entity from the second system based on the entity identifier, where the third service entity is used to represent the service entity not transferred out in the second system; a service execution module, configured to execute a service request based on the third service entity.

[0018] Further, the above production further includes: a first determination module, configured to, in response to the entity running state being that the first service entity is running normally, determine that the access states of the first service entity and the third service entity are the first state, and the access state of the second service entity is the second state, where the service entity in the first state can be called, and the service entity in the second state cannot be called; a second determination module, configured to, in response to the entity running state being that the first service entity is running abnormally, determine that the access states of the second service entity and the third service entity are the first state, and the access state of the first service entity is the second state.

[0019] According to another aspect of the embodiments of the present invention, there is also provided an electronic device, including: a memory storing an executable program; a processor configured to run the program, where when the program runs, it executes the methods in the various embodiments of the present invention.

[0020] According to another aspect of the embodiments of the present invention, there is also provided a computer-readable storage medium, where the computer-readable storage medium includes a stored executable program, and when the executable program runs, it controls the device where the computer-readable storage medium is located to execute the methods in the various embodiments of the present invention.

[0021] According to another aspect of the embodiments of the present invention, there is also provided a computer program product, including a computer program, where the computer program, when executed by a processor, implements the methods in the various embodiments of the present invention.

[0022] According to another aspect of the embodiments of the present invention, there is also provided a computer program product, including a non-volatile computer-readable storage medium, where the non-volatile computer-readable storage medium stores a computer program, and the computer program, when executed by a processor, implements the methods in the various embodiments of the present invention.

[0023] According to another aspect of the embodiments of the present invention, there is also provided a computer program, where the computer program, when executed by a processor, implements the methods in the various embodiments of the present invention.

[0024] In an embodiment of the present invention, in response to receiving a service request, the entity type and entity identifier of a service entity for executing the service request are obtained; in response to the entity type being the first type, based on the entity identifier, the entity running status of the first service entity in the first system is obtained; in response to the entity running status being that the first service entity is running abnormally, based on the entity identifier, the second service entity is called from the second system; based on the manner in which the second service entity executes the service request, by using the backup service entity stored in the second system that has a data transfer relationship with the first system, namely the above-mentioned second service entity, to continue executing the received service request when the first service entity fails, the waiting time and processing time for processing the service request can be reduced, thereby improving the flexibility of executing the service request, and further solving the technical problem of low flexibility in processing service requests in the related art. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings described herein are used to provide a further understanding of the present invention, and constitute a part of this application. The illustrative embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0026] Figure 1 is a flowchart of a method for processing a service request according to an embodiment of the present invention;

[0027] Figure 2 is a schematic diagram of a service entity transfer system according to an embodiment of this application;

[0028] Figure 3 is a schematic diagram of a process for a status control component to meet the standards according to an embodiment of this application;

[0029] Figure 4 is a schematic diagram of a synchronization process of a backup synchronization component according to an embodiment of this application;

[0030] Figure 5 is a schematic diagram of an entity automatic fallback process according to an embodiment of this application;

[0031] Figure 6 is a block diagram of a structure of a service request processing device according to an embodiment of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0032] To enable those skilled in the art to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0033] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged under appropriate circumstances so that the embodiments of the present invention described herein can be implemented in an order different from those illustrated or described herein. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0034] According to an embodiment of the present invention, an embodiment of a method for processing a service request is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0035] Figure 1 is a flowchart of a method for processing a service request shown according to an embodiment of the present invention. As Figure 1 shown, the method includes the following steps:

[0036] Step S102, in response to receiving a service request, obtain the entity type and entity identifier of the service entity for executing the service request.

[0037] The above service request may refer to an operation request input by a user through an operation interface, and may include, but is not limited to: requests such as information query, product subscription, and function management. The above entity type can be used to reflect whether the service entity currently to be obtained is a service entity transferred from an old system to a new system. If the entity type is a service entity that has been transferred to the new system, it means that the service entity can be called from the new system; if the entity type is a service entity that has not been transferred to the new system, it means that the service entity can be called from the old system.

[0038] In an alternative solution of this embodiment, when receiving a service request, the service request processing system (processing system) may first determine the service entity that can execute the service request, and obtain the entity type of the service entity to determine whether the service entity can be invoked from the new system or the old system. At the same time, the entity identifier of the service entity can be further obtained, so that after determining the service system that can invoke the service entity, the processing system can invoke the service entity from the corresponding system according to the entity identifier.

[0039] Step S104, in response to the entity type being the first type, based on the entity identifier, obtain the entity running status of the first service entity in the first system.

[0040] Wherein, the first service entity is used to execute the service request, and the entity type of the first service entity is the first type.

[0041] The above-mentioned first type may refer to the service entity that has been transferred from the old system to the new system.

[0042] In an alternative solution of this embodiment, when the new and old systems run in parallel, usually the new system is used as the main system to process service requests. Therefore, when it is determined that the entity type of the first service entity is the first type, the processing system may first determine, according to the obtained entity identifier, the first service entity in the new system, that is, the above-mentioned first system, that can process the received service request, and obtain the entity running status of the first service entity. If the entity running status is that the first service entity is running normally, it means that invoking the first service entity in the first system can accurately execute the received service request; if the entity running status is that the second service entity is running abnormally, it means that invoking the first service entity in the first system cannot accurately execute the received service request.

[0043] Step S106, in response to the entity running status being that the first service entity is running abnormally, invoke the second service entity from the second system based on the entity identifier.

[0044] Wherein, there is a transfer operation of the service entity between the first system and the second system. The first system is used to receive the service entity transferred out from the second system, the second system is used to back up the service entity that has been successfully transferred to the first system, the second service entity is used to represent the service entity obtained by backing up the first service entity, and the entity type of the second service entity is the first type.

[0045] In an alternative solution of this embodiment, when it is determined that the entity running state of the first business entity is abnormal operation of the first business entity, in order to continue to execute the service request, the processing system may obtain the backup file of the first business entity from the old system, that is, the second system above, according to the obtained entity identifier, that is, call the second business entity above, so that the processing system can execute the business system based on the second business entity.

[0046] Generally, when the new and old systems are running in parallel and there are still business entities in the old system that have not been transferred to the new system, there is usually data transfer between the new and old systems. Correspondingly, corresponding entity files can be created in the new system to receive the business entities transferred from the old system. In order to ensure that when the business entities used in the new system fail, the processing system can still stably process the service requests, corresponding entity files can also be created in the old system. After the new system successfully receives the business entities transferred from the old system, a backup business entity file is generated for the received business entities and sent to the old system. Correspondingly, the old system can synchronize the received backup business entity file to the newly created entity file to implement the operation of backing up the business entity. At the same time, backing up the business entities received by the new system to the old system can also avoid the situation where the old system cannot be synchronized after the staff modifies the business entities received by the new system. Thus, when the business entities in the new system fail, the processing system can use the backup business system stored in the old system to quickly and stably execute the received service requests. Based on this, considering that the first business entity has been transferred from the old system to the new system, and there may still be untransferred business entities in the old system. Therefore, in order to distinguish the second business entity that matches the first business entity backed up in the old system from other untransferred business entities, the processing system can also set the entity type of the second business entity to the first type. Correspondingly, when the processing system detects that the entity type of the business entity is the first type, it can determine that the business entity can be called in both the new system and the old system. Correspondingly, when it is detected that the business entity fails in the new system, the processing system can directly continue to call the corresponding backup business entity from the old system instead of being unable to process the received service request, thereby improving the flexibility of the processing system to process the received service requests.

[0047] Step S108, execute the service request based on the second business entity.

[0048] After obtaining the second business entity, the processing system can use the second business entity to execute the received service request.

[0049] In an embodiment of the present invention, in response to receiving a service request, obtain the entity type and entity identifier of a service entity for executing the service request; in response to the entity type being the first type, based on the entity identifier, obtain the entity running state of the first service entity in the first system; in response to the entity running state being that the first service entity is running abnormally, call a second service entity from the second system based on the entity identifier; by using the backup service entity stored in the second system that has a data transfer relationship with the first system, that is, the above-mentioned second service entity, to continue executing the received service request when the first service entity fails, the waiting time and processing time for processing the service request can be reduced, thereby improving the flexibility of executing the service request, and further solving the technical problem of low flexibility in processing service requests in the related art.

[0050] Further, the above method further includes: in response to detecting that the first service entity returns to normal, obtain the request type of the service request; in response to the request type being a read type, call the first service entity from the first system based on the entity identifier, and execute the service request based on the first service entity.

[0051] In an alternative solution of this embodiment, when it is detected that the first service entity returns to normal, it indicates that the user can switch back to the new system at this time to use the first service entity to execute the current service request. Considering that if the request type of the service request currently being executed by the user is a read type, for example, the user is only consulting materials or watching videos, directly switching the system will not affect the service request currently being executed by the user. For example, it will not affect the progress of the user's consulting materials or watching videos, and at the same time, it can also enable the user to experience the system optimization of the new system compared to the old system, thereby improving the user experience. Therefore, when it is detected that the first service entity returns to normal and the request type of the service request is a read type, the processing system can call the first service entity from the first system according to the entity identifier and continue to execute the service request using the first service entity. It should be noted that directly switching to the first service entity to continue executing the service request is only an option when executing a read-type service request. If the user wants to continue using the old system according to their own habits, the processing system can still continue to use the second service entity to execute the service request at this time without performing the operation of switching the service entity, so as to meet the user's needs as much as possible.

[0052] Further, the above method further includes: in response to the request type being a write type, obtaining the request status of the service request; in response to the request status being that no system switch instruction has been received, continuing to execute the service request based on the second service entity; in response to the request status being that the system switch instruction has been received, obtaining the current service execution result of the service request, generating a service execution instruction based on the service execution result, and continuing to execute the service request based on the first service entity according to the service execution instruction.

[0053] In an alternative solution of this embodiment, correspondingly to the read type, when it is detected that the first service entity has returned to normal and the type of the service request is a write type, the processing system may further obtain the request status of the service request, where the request status may be used to reflect whether the user needs to continue to execute the current service request in the new system. Generally, in order to improve system performance, the operation methods of service requests by users in the new system and the old system may be different, and different users usually prefer to use different systems. Therefore, when the first service entity recovers, that is, when the user can switch the use of the service system, the processing system may send a prompt message to the user. The user can choose whether to switch the currently used system according to the prompt message, and the corresponding processing system may generate the above request status according to the user's choice. When the request status is that no system switch instruction has been received, the processing system may continue to use the second service entity to execute the service request, so as to avoid that suddenly switching the service system will affect the service request currently being carried out by the user; when the request status is that the system switch instruction has been received, the processing system can obtain the current service execution result of the service request to determine the current execution situation of the service request, and then generate a corresponding service execution instruction according to the service execution result, and then continue to execute the service request according to the first service entity according to the generated service execution instruction, so that the user does not need to re-execute the service request, thereby improving the user experience.

[0054] Further, after executing the service request based on the second service entity, the above method further includes: obtaining the request type of the service request; in response to the request type being a write type, generating a service deletion instruction based on the second service entity, and sending the service deletion instruction to the consistency guarantee component, where the consistency guarantee component is used to ensure the consistency between the first service entity and the second service entity; in response to the first system resuming normal operation, deleting the first service entity in the first system based on the consistency guarantee component.

[0055] In an alternative solution of this embodiment, since the service requests of the read type do not affect the attributes of the service entity, and thus do not affect the migration process of the service entity, which may lead to the situation that the first service entity migrated in the new system does not match the second service entity backed up in the old system. However, the service requests of the write type will affect the attributes of the service entity. That is, after executing the service request using the second service entity, the configuration parameters of the second service entity may change. Correspondingly, when the first service entity resumes normal operation, the configuration parameters of the first service entity will be different from those of the second service entity. When the same type of service request appears again, the processing system may not be able to accurately execute the service request using the first service entity. Therefore, in order to ensure that the service request can be executed smoothly, the processing system can use the consistency guarantee component to keep the configuration parameters of the first service entity and the second service entity consistent in real time. Considering that a large amount of data comparison and data writing operations are required during data synchronization, directly updating the configuration parameters of the first service entity after the configuration parameters of the second service entity change may take a long time. Therefore, after executing the service request using the second service entity, to improve the consistency of the service entities in the new and old systems, the processing system can first obtain the request type of the service request, and when the request type is the write type, generate a corresponding service deletion instruction according to the second service entity, and send the service deletion instruction to the consistency guarantee component. After the first system resumes normal operation, the consistency guarantee component directly deletes the first service entity in the first system, so that the second system can use the second service entity after executing the service request as the new entity to be transferred and transfer it to the first system, thereby ensuring the consistency of the corresponding service entities in the first system and the second system.

[0056] Further, after executing the service request based on the second service entity, the above method further includes: updating the entity types of the first service entity and the second service entity respectively according to the second type to obtain a new first service entity and a new second service entity, where the service entity of the second type is used to represent the service entity existing in the second system that is waiting for the entity transfer operation.

[0057] In an alternative solution of this embodiment, as described above, in order to facilitate the distinction between untransferred business entities and those that have been transferred and backed up, after the second business entity is used to execute a service request, the processing system can also update the entity type of the first business entity in the first system according to the above-mentioned second type with the entity type of the second business entity in the second system, so as to obtain a new first business entity and a new second business entity. At this time, the entity type of the new first business entity is different from that of other business entities in the first system, and it can be determined that the new first business entity is a business entity that needs to be deleted. The new second business entity is different from other backup business entities in the second system, and it can be determined that the new second business entity is a business entity that needs to have its data transferred. Correspondingly, after the new second business entity is re-transferred to the first system, the processing system can delete the new second business entity in the second form, and construct a corresponding backup business entity for the business entity newly transferred to the first system.

[0058] Further, the above method further includes: in response to the entity type being the second type, invoking a third business entity from the second system based on the entity identifier, where the third business entity is used to represent the business entity that has not been transferred out in the second system; and executing the service request based on the third business entity.

[0059] In an alternative solution of this embodiment, as described above, in addition to the first type, the entity type of the business entity can also include the above-mentioned second type. Correspondingly, when it is detected that the entity type is the second type, the processing system can directly determine that the business entity to be invoked currently is the business entity that has not been transferred out in the second system. Based on this, the processing system can quickly invoke the corresponding third business entity from the second system according to the entity identifier of the business entity, so as to execute the received service request using the third business entity. The third business entity includes the updated second business entity mentioned above.

[0060] Further, the above method further includes: in response to the entity running state being that the first business entity is running normally, determining that the access states of the first business entity and the third business entity are the first state, and the access state of the second business entity is the second state, where the business entity in the first state can be invoked, and the business entity in the second state cannot be invoked; in response to the entity running state being that the first business entity is running abnormally, determining that the access states of the second business entity and the third business entity are the first state, and the access state of the first business entity is the second state.

[0061] In an alternative solution of this embodiment, to avoid affecting the efficiency of processing service requests, in addition to using the aforementioned entity rollback operation to execute the received service requests using the backup second service entity when the first service entity fails, the processing system can also determine the access status of the service entities included in the second system, namely the second service entity and the third service entity, as the first status, that is, the status that can be accessed and called, when the running status of the entity service is that the first service entity is running abnormally, while the access status of the faulty first service entity in the first system is the second status, that is, the status that cannot be accessed and called. Correspondingly, when the first service entity is running normally, to avoid errors during the interaction operation between the new and old systems, the processing system can determine the access status of the service entities in the first system, including the aforementioned first service entity, and the service entities that have not been successfully transferred in the second system, namely the third service entity, as the aforementioned first status, and at the same time determine the access status of the backup service entities in the second system, including the aforementioned second service entity, as the second status, to avoid the situation where the first service entity is not updated correspondingly after using the second service entity to execute the service request, or wasting too much time updating the first service entity.

[0062] For ease of understanding, Figure 2 is a schematic diagram of a service entity transfer system shown according to an embodiment of the present application, as Figure 2 shown, the service entity transfer system may include an old system, a new system, an access control component, a status control component, a backup synchronization component, a change sensing component, an automatic rollback component, and a consistency guarantee component.

[0063] Among them, the status control component can be used to determine the entity types of different service times in the new and old systems, and configure different entity tags for different entity types. For example, for the service entities of the first type, the corresponding entity tag can be "transfer entity", and for the service entities of the second type, the corresponding entity tag can be "rollback entity". In addition, the status control component can also determine its own component status in real time according to the running status of the service entities that need to be called in the first system, so as to judge whether an entity rollback operation is required according to the component status. Correspondingly, when the running status is that the service entity is running normally, the component status can be determined as the "normal running status" at this time, and when the running status is that the service entity is abnormal and the backup service entity in the old system needs to be used, the component status can be determined as the "fault rollback status" at this time.

[0064] The backup synchronization component can be used to synchronously back up the service entities with the entity tag of "transfer entity" in the new system to the old system in real time for backup, so that the corresponding backup service entities can be deployed in the old system, and the entity tag of the backup service entities can also be "transfer entity".

[0065] The access control component can be used to control the user access of the service transfer system, set the access status of different business entities in the new and old systems, and execute different access policy controls according to different current operating states, so as to achieve the access control of the "transfer entity" and the "reverted entity".

[0066] The change sensing component can be used to sense whether the business entity marked as "transfer entity" in the old system has changed due to user operations. Among them, under the component state of "normal operation state" of the state control component, the corresponding backed-up business entity in the old system will not generate user operation changes under the restriction of the access control component. Only in the "fault reversion state", the corresponding business entity in the old system will generate user operation changes. This change sensing component is to monitor and capture these user operation changes to further trigger the reversion operation of these business entities.

[0067] The automatic reversion component can be used to perform an automatic reversion operation on the specified fine-grained business entity, and automatically change the entity mark of the changed business entity in the old system from "transfer entity" to "reverted entity";

[0068] The consistency guarantee component can be used to control that the corresponding "transfer entity" in the new system no longer provides services when a business entity undergoes reversion. This function can be achieved by changing the business entity in the new system from "transfer entity" to "reverted entity" as well. In order to maintain the data consistency between the new and old systems, when a business entity undergoes reversion, the original "transfer entity" data of this business entity in the new system needs to be cleared. However, since the new system is unavailable during the fault, the data cleaning may not be executed immediately. Therefore, this consistency guarantee component needs to be introduced to record all the business entities that have undergone reversion, so that when the new system resumes operation, these reverted business entities can be cleared in the new system immediately.

[0069] Specifically, through Figure 2 the shown service entity transfer system, the following operations can be achieved:

[0070] Define fine-grained state marks for all business entities in the service transfer system. This mark can have two values: "transfer entity" and "reverted entity"; The business entities that have been transferred to the new system for operation are all marked as "transfer entity", while the business entities that still remain in the old system for operation are marked as "reverted entity".

[0071] When the business transfer system is running normally, it is determined that the status control component is set to the "normal operation state", and the access control is completed by this status control component. The business entities marked as "transfer entities" can only be accessed in the new system and cannot be accessed in the old system; the business entities marked as "rollback entities" can only be accessed in the old system and cannot be accessed in the new system; when the new system fails and cannot provide services, the status control component switches the operation state from the "normal operation state" to the "fault rollback state".

[0072] In the fault rollback state, the access rights of users to the old backup system are fully opened, that is, users can now access the updated "transfer entities" in the old system without restriction. At this time, users can directly operate on the corresponding business entities on the old backup system according to current needs, and the automatic rollback of the business entity is directly triggered by the user's update operation (write operation) on the entity; when a business entity undergoes an automatic rollback, the status control component marks the rollback business entity and marks the business entity as a "rollback entity".

[0073] At the same time, in the fault rollback state, the business entities that users have not accessed in the old backup system still remain in the new system (the mark remains "transfer entity" unchanged). Once the new system resumes normal operation, these unrolled-back business entities can immediately provide services normally in the new system; when the fault is recovered, the status control component switches the operation state from the fault rollback state to the normal operation state.

[0074] In the normal operation state, the status control component resumes normal access control, that is, "transfer entities" can only be accessed in the new system, while "rollback entities" can only be accessed in the old system. Therefore, the business entities whose automatic rollback is triggered by user operations in the fault rollback state, since they have changed from "transfer entities" to "rollback entities", these business entities are allowed to continue to be operated in the old system until the expiration of the survival period of the business entity and it is cleared from the system, while the business entities that still maintain the "transfer entity" mark unchanged will continue to be operated and processed in the new system.

[0075] Figure 3 It is a schematic diagram of the process of a status control component meeting the standard shown in the embodiments of the present application. As Figure 3 shown, when configuring corresponding entity marks for different business entities, it can be jointly achieved by the status control component and the backup synchronization component. Specifically, the status control component can adopt a set of KEY-VALUE key-value pair sets to record and save the marks of all business entities in the business transfer system. The definition can be as follows:

[0076] {[KEY:VALUE],[KEY:VALUE],[KEY:VALUE]..........[KEY:VALUE]}.

[0077] Among them, each KEY corresponds to a business entity, and the value of VALUE is "transfer entity" or "return entity". Taking the stowage business system as an example, a sample set of marked parts of a possible business entity is as follows:

[0078] {[Flight A: transfer entity], [Flight B: transfer entity]......... [Flight X: return entity]}.

[0079] Based on this, the construction implementation logic of the marked part of the business entity is as follows:

[0080] First, the state control component listens for all new business entity creation events in the new system and the old system.

[0081] Next, for the business entities newly created in the new system, mark them as 'transfer entity', and notify the backup synchronization component to synchronously create 'transfer entity' (backup) for the newly created business entity in the old system.

[0082] Then, for the business entities newly created in the old system, mark them as'return entity'; for such business entities, there is no need to establish corresponding business entities in the new system.

[0083] In addition, according to the component status of the state control component determined by the running status of the business entities in the new system, it can correspondingly include the aforementioned: "normal running state" and "fault rollback state". The definition of the component status systemStatus can be as follows:

[0084] systemStatus = [normal running state | fault rollback state].

[0085] Figure 4 It is a schematic diagram of the synchronization process of a backup synchronization component shown in an embodiment of the present application. As described above and Figure 4 shown, the main function of the backup synchronization component is to synchronously back up the "transfer entity" data in the new system to the old system in real time, so that the corresponding "transfer entity" (backup) data in the old system is always kept consistent with the new system.

[0086] Therefore, the construction implementation logic of the backup synchronization component is as follows:

[0087] First, the state control component listens for all business entity change events in the new system and discovers the business entities with data changes.

[0088] Then, the status control component invokes the backup synchronization component to perform data synchronization on the business entity, synchronizing its data in the new system to the old system to keep the data in the two systems consistent.

[0089] Among them, the instruction for triggering data backup can be sent by the status control component.

[0090] In addition, in the above business entity transfer system:

[0091] The implementation logic of the access control component can be as follows:

[0092] First, all operation requests of the user for the business entity are controlled by the access control component.

[0093] Next, for the user's access to the business entity in the new system, the access control component makes a determination of whether to allow access or restrict access by querying the status control component. The determination logic is: if the operation object is a transfer entity, access is allowed; if the operation object is a rollback entity, access is denied.

[0094] Then, for the user's access to the business entity in the old backup system, the access control component makes a determination of whether to allow access or restrict access by querying the status control component. The determination logic is:

[0095] i. If the overall status of the current device is "normal operation state", then if the operation object is a transfer entity, access is denied; if the operation object is a rollback entity, access is allowed;

[0096] ii. If the overall status of the current device is "fault rollback state", then regardless of whether the operation object is a transfer entity or a rollback entity, access is allowed.

[0097] The change sensing component only needs to monitor and respond to entity change events in the old system.

[0098] The implementation logic of the automatic rollback component can be as follows:

[0099] First, once the change sensing component monitors a user operation change event for the "transfer entity" in the old backup system, it will immediately invoke the automatic rollback component to initiate a rollback operation on the "transfer entity".

[0100] Second, since in the old backup system, the data of the "transfer entity" has actually been kept consistent with the corresponding "transfer entity" data in the new system via the backup synchronization component, in this link, the automatic rollback component only needs to notify the status control component to change the mark of the business entity from the original "transfer entity" to "rollback entity".

[0101] Then, the automatic rollback component finally notifies the consistency guarantee component to record the rollback entity, so as to clear the entity data in the new system immediately after the new system is restored, in order to ensure data consistency between the new and old systems during business transfer.

[0102] The implementation logic of the consistency guarantee component can be shown as follows:

[0103] First, after receiving the cleanup notice, immediately attempt to clear the specified business entity in the new system;

[0104] Second, if the specified business entity cleanup cannot be completed immediately due to various reasons such as new system failures, record the business entity to be cleaned up and enter the timed cleanup mode: The consistency guarantee component sets a timer with a customizable time interval. This timer starts at fixed intervals and attempts to clean up all the business entities to be cleaned up that have been saved in the new system.

[0105] Figure 5 FIG. is a schematic diagram of an entity automatic rollback process shown according to an embodiment of the present application. As Figure 5 shown, the automatic rollback process can be jointly triggered by the access control component, the new and old systems, the change sensing component, the automatic rollback component, the consistency guarantee component, and the status control component. For example, when the new system fails and the corresponding business entity cannot be normally called, the background operation and maintenance personnel need to set the component operation status of the status control component to "fault rollback state". At this time, the access control rules for the old system by the access control component change. In the fault rollback state, users are allowed to operate on all entities in the host loading system as needed. When the change sensing component monitors a user operation change event of "transfer entity" in the old system, it can immediately call the automatic rollback component to perform a rollback operation on the transfer entity. Correspondingly, the automatic rollback component can notify the status control component to change the marked status of the entity from "transfer entity" to "rollback entity", and notify the consistency guarantee component to clean up the entity in the open loading system. After receiving the notice, the consistency guarantee component can immediately attempt to clean up the data of the rolled-back entity in the new system. If it fails, it can record the business entity and continuously attempt to clear the entity in the subsequent jobs started regularly until the cleanup is successfully completed.

[0106] According to an embodiment of the present invention, an embodiment of an apparatus for processing a business request is provided. It should be noted that this apparatus can be used to execute the method for processing a business request described above. Figure 6 FIG. is a structural block diagram of a business request processing apparatus shown according to an embodiment of the present application. As Figure 6 shown, the apparatus may include: a parameter acquisition module 602, a status acquisition module 604, a first call module 606, and a request execution module 608.

[0107] Among them, the parameter acquisition module 602 is configured to obtain the entity type and entity identifier of the business entity for executing the business request in response to receiving the business request; the status acquisition module 604 is configured to obtain the entity running status of the first business entity in the first system based on the entity identifier in response to the entity type being the first type, where the first business entity is used to execute the business request and the entity type of the first business entity is the first type; the first invocation module 606 is configured to invoke the second business entity from the second system based on the entity identifier in response to the entity running status being an abnormal operation of the first business entity, where there is a transfer operation of the business entity between the first system and the second system, the first system is used to receive the business entity transferred out from the second system, the second system is used to back up the business entity successfully transferred to the first system, the second business entity is used to represent the business entity obtained by backing up the first business entity, and the entity type of the second business entity is the first type; the request execution module 608 is configured to execute the business request based on the second business entity.

[0108] Further, the above device further includes: a first type acquisition module, configured to obtain the request type of the business request in response to detecting that the first business entity returns to normal; a first execution module, configured to invoke the first business entity from the first system based on the entity identifier and execute the business request based on the first business entity in response to the request type being a read type.

[0109] Further, the above device further includes: a request status acquisition module, configured to obtain the request status of the business request in response to the request type being a write type; a second execution module, configured to continue to execute the business request based on the second business entity in response to the request status being that no system switch instruction is received; a third execution module, configured to obtain the current business execution result of the business request and generate a business execution instruction based on the business execution result, and continue to execute the business request according to the business execution instruction based on the first business entity in response to the request status being that the system switch instruction is received.

[0110] Further, the above device further includes: a second type acquisition module, configured to obtain the request type of the business request; an instruction sending module, configured to generate a business deletion instruction based on the second business entity and send the business deletion instruction to the consistency guarantee component in response to the request type being a write type, where the consistency guarantee component is used to ensure the consistency between the first business entity and the second business entity; an entity deletion module, configured to delete the first business entity in the first system based on the consistency guarantee component in response to the first system resuming normal operation.

[0111] Further, the above-mentioned device further includes: an entity update module, configured to update the entity types of the first service entity and the second service entity respectively according to the second type to obtain a new first service entity and a new second service entity, where the service entity of the second type is used to represent the service entity existing in the second system that is waiting for an entity transfer operation.

[0112] Further, the above-mentioned production further includes: a third invocation module, configured to, in response to the entity type being the second type, invoke a third service entity from the second system based on the entity identifier, where the third service entity is used to represent the service entity that has not been transferred out in the second system; a service execution module, configured to execute a service request based on the third service entity.

[0113] Further, the above-mentioned production further includes: a first determination module, configured to, in response to the entity running state being that the first service entity is running normally, determine that the access states of the first service entity and the third service entity are the first state, and the access state of the second service entity is the second state, where the service entity in the first state can be invoked, and the service entity in the second state cannot be invoked; a second determination module, configured to, in response to the entity running state being that the first service entity is running abnormally, determine that the access states of the second service entity and the third service entity are the first state, and the access state of the first service entity is the second state.

[0114] An embodiment of the present application further provides an electronic device, including: a memory storing an executable program; a processor configured to run the program, where when the program runs, it executes the methods in the various embodiments of the present invention.

[0115] An embodiment of the present application further provides a computer-readable storage medium, where the computer-readable storage medium includes a stored executable program, and when the executable program runs, it controls the device where the computer-readable storage medium is located to execute the methods in the various embodiments of the present invention.

[0116] An embodiment of the present application further provides a computer program product, including a computer program, where when the computer program is executed by a processor, it implements the methods in the various embodiments of the present invention.

[0117] An embodiment of the present application further provides a computer program product, including a non-volatile computer-readable storage medium, where the non-volatile computer-readable storage medium is used to store a computer program, and when the computer program is executed by a processor, it implements the methods in the various embodiments of the present invention.

[0118] An embodiment of the present application further provides a computer program, where when the computer program is executed by a processor, it implements the methods in the various embodiments of the present invention described above.

[0119] In the above embodiments of the present invention, each embodiment is described with its own emphasis. For the parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0120] In several embodiments provided by the present application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of units can be a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces. The indirect coupling or communication connection of units or modules can be in an electrical or other form.

[0121] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place, or can be distributed to multiple units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0122] In addition, in each embodiment of the present invention, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0123] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the methods in each embodiment of the present invention. The foregoing storage medium includes: USB flash drives, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), mobile hard disks, magnetic disks or optical disks and other various media that can store program codes.

[0124] The above are only the preferred embodiments of the present invention. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present invention, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present invention.

Claims

1. A method for processing a service request, characterized in that, including: Upon receiving a service request, obtain the entity type and entity identifier of the service entity for executing the service request; In response to the entity type being the first type, based on the entity identifier, obtain the entity running status of the first service entity in the first system, where the entity type of the first service entity is the first type; In response to the entity running status being that the first service entity is running abnormally, based on the entity identifier, call a second service entity from the second system, where there is a transfer operation of the service entity between the first system and the second system, the first system is used to receive the service entity transferred out from the second system, the second system is used to back up the service entity successfully transferred to the first system, the second service entity is used to represent the service entity obtained by backing up the first service entity, and the entity type of the second service entity is the first type; Execute the service request based on the second service entity.

2. The method according to claim 1, wherein The method further includes: In response to detecting that the first service entity has returned to normal, obtain the request type of the service request; In response to the request type being a read type, based on the entity identifier, call the first service entity from the first system and execute the service request based on the first service entity.

3. The method according to claim 2, wherein The method further includes: In response to the request type being a write type, obtain the request status of the service request; In response to the request status being that no system switch instruction has been received, continue to execute the service request based on the second service entity; In response to the request status being that the system switch instruction has been received, obtain the current service execution result of the service request, generate a service execution instruction based on the service execution result, and continue to execute the service request based on the first service entity according to the service execution instruction.

4. The method according to claim 1, wherein After executing the service request based on the second service entity, the method further includes: Obtain the request type of the service request; In response to the request type being a write type, generate a service deletion instruction based on the second service entity and send the service deletion instruction to a consistency guarantee component, where the consistency guarantee component is used to ensure the consistency between the first service entity and the second service entity; In response to the first system resuming normal operation, delete the first service entity in the first system based on the consistency guarantee component.

5. The method according to claim 1, wherein After executing the service request based on the second service entity, the method further includes: Update the entity types of the first service entity and the second service entity respectively according to the second type to obtain a new first service entity and a new second service entity, where the service entity of the second type is used to represent the service entity waiting for an entity transfer operation in the second system.

6. The method according to claim 1, wherein The method further includes: In response to the entity type being the second type, based on the entity identifier, call a third service entity from the second system, where the third service entity is used to represent the service entity that has not been transferred out in the second system; Execute the service request based on the third service entity.

7. The method according to claim 6, wherein The method further includes: In response to the entity running status indicating that the first service entity is running normally, determine that the access status of the first service entity and the third service entity is the first status, and the access status of the second service entity is the second status, where a service entity in the first status can be invoked, and a service entity in the second status cannot be invoked; In response to the entity running status indicating that the first service entity is running abnormally, determine that the access status of the second service entity and the third service entity is the first status, and the access status of the first service entity is the second status.

8. An electronic device, characterized in that, It includes: A memory storing an executable program; A processor for running the program, where when the program runs, it executes the method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, where when the executable program runs, it controls the device where the storage medium is located to execute the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images