Middleware service fault recovery method and device, equipment, storage medium and product

Abstract

The invention discloses a middleware service fault recovery method and device, equipment, a storage medium and a product, and relates to the technical field of communication, and the method comprises the steps: starting an SOME / IP service and a daemon process in the SOME / IP service; service state monitoring is carried out on the SOME / IP service through the daemon process; and when the SOME / IP service operation fault is monitored, switching the SOME / IP service to the SOME / IP standby service, and carrying out data transmission and service discovery through the SOME / IP standby service. According to the method, the SOME / IP service and the daemon process are started; service state monitoring is carried out through the daemon process; and when the service operation fault is monitored, the service is switched into the standby service, and data transmission and service discovery are performed through the standby service, so that the situation that the data transmission and service discovery functions cannot be completed due to service failure is avoided.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method, device, equipment, storage medium and product for middleware service failure recovery. Background Art

[0002] SOME / IP (Scalable service-oriented MiddlewarE over IP) is a service-oriented scalable communication middleware protocol based on IP protocol, which is often used in Android system. The main functions of SOME / IP are: middleware based on IP; support for remote procedure call (RPC); support for event notification. The upper layer application obtains the server-side support services through the someipd service and transmits data. The server-side broadcasts the support functions to each client-side through someipd. The someipd service is a SOME / IP protocol service running in the Android system, responsible for monitoring the status of the SOME / IP protocol stack and the service status.

[0003] However, the SOME / IP protocol stack is started by parsing the someipd.rc file through the Android init process. Once the service someipd fails, the entire SOME / IP function fails, and the related data transmission function fails. The Android init process is a key role in the startup process of the Android system. It is responsible for initializing the system and starting other processes to ensure the normal operation of the Android system. The someipd.rc file is a configuration file used to initialize and configure services in the SOME / IP protocol stack. someipd uses the watchdog monitoring mechanism. The watchdog monitoring mechanism is a function in the Android system used to monitor the operating status of the system. It mainly monitors the core services of the Android framework layer to ensure that appropriate measures are taken to maintain the normal operation of the system when problems occur. The purpose of the watchdog is to restore the service. If the service itself has defects or bugs, the watchdog mechanism cannot be restored and will cover up the problems of someipd's internal defects. For some complex failures of someipd, for example, the service is "deadlocked" under certain conditions or some functions fail but not completely crashed, the watchdog cannot effectively detect it. Therefore, how to solve the service function failure caused by someipd operation failure is an urgent problem to be solved. Summary of the invention

[0004] The main purpose of this application is to provide a middleware service fault recovery method, device, equipment, storage medium and product, aiming to solve the technical problem of service function failure caused by someipd operation failure.

[0005] To achieve the above objectives, the present application proposes a method for recovering a middleware service failure, the method comprising:

[0006] Start the SOME / IP service and the daemon process in the SOME / IP service;

[0007] Performing service status monitoring on the SOME / IP service through the daemon process;

[0008] When a running failure of the SOME / IP service is detected, the SOME / IP service is switched to a SOME / IP standby service, and data transmission and service discovery are performed through the SOME / IP standby service.

[0009] In one embodiment, when a SOME / IP service operation failure is detected, the step of switching the SOME / IP service to a SOME / IP backup service and performing data transmission and service discovery through the SOME / IP backup service includes:

[0010] When no normal service operation information fed back by the SOME / IP service is received within a preset time interval, determining that the SOME / IP service operation fails;

[0011] Starting the SOME / IP standby service through the daemon process, and switching the SOME / IP service to the SOME / IP standby service;

[0012] A routing communication channel is established through the SOME / IP backup service and the application program, and data transmission and service discovery are performed with the application program through the routing communication channel.

[0013] In one embodiment, the step of establishing a routing communication channel through the SOME / IP backup service and the application, and performing data transmission and service discovery with the application through the routing communication channel includes:

[0014] Establishing a routing communication channel with the application via the SOME / IP backup service and a preset unique identifier;

[0015] Sending a channel identification message as a first message to the application through the SOME / IP backup service and the routing communication channel, wherein the channel identification message includes the preset unique identifier;

[0016] receiving a control message sent by the application according to the preset unique identifier;

[0017] The SOME / IP standby service performs data transmission and service discovery with the application according to the control message.

[0018] In one embodiment, the step of starting the SOME / IP standby service through the daemon process and switching the SOME / IP service to the SOME / IP standby service includes:

[0019] Sending a restart command to the SOME / IP service through the daemon process;

[0020] Real-time detection of currently running SOME / IP service instances by the daemon process;

[0021] When the SOME / IP service instance is not detected, the SOME / IP standby service is started by the daemon process, and the SOME / IP service is switched to the SOME / IP standby service.

[0022] In one embodiment, the step of monitoring the service status of the SOME / IP service through the daemon process includes:

[0023] Sending a heartbeat monitoring packet to the SOME / IP service at a preset time interval by the daemon process;

[0024] When normal service operation information fed back by the SOME / IP service is received within a preset time interval, it is determined that the SOME / IP service is operating normally.

[0025] In one embodiment, before the step of starting the SOME / IP service and the daemon process in the SOME / IP service, the method further includes:

[0026] Generate SOME / IP backup service source code based on SOME / IP protocol stack and SOME / IP protocol implementation library;

[0027] The SOME / IP backup service source code is compiled according to the Android source code to obtain the SOME / IP backup service.

[0028] In addition, to achieve the above-mentioned purpose, the present application also proposes a middleware service failure recovery device, the middleware service failure recovery device comprising:

[0029] The service startup module is used to start the SOME / IP service and the daemon process in the SOME / IP service;

[0030] A service status monitoring module, used for monitoring the service status of the SOME / IP service through the daemon process;

[0031] The standby service switching module is used to switch the SOME / IP service to the SOME / IP standby service when a SOME / IP service operation failure is detected, and perform data transmission and service discovery through the SOME / IP standby service.

[0032] In addition, to achieve the above objectives, the present application also proposes a middleware service fault recovery device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the middleware service fault recovery method described above.

[0033] In addition, to achieve the above objectives, the present application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the middleware service fault recovery method described above are implemented.

[0034] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the middleware service failure recovery method as described above are implemented.

[0035] The present application provides a method for recovering a middleware service failure, which starts a SOME / IP service and a daemon process in the SOME / IP service; monitors the service status of the SOME / IP service through the daemon process; when a failure in the SOME / IP service is detected, the SOME / IP service is switched to a SOME / IP backup service, and data transmission and service discovery are performed through the SOME / IP backup service. The present application starts a SOME / IP service and a daemon process in the SOME / IP service; monitors the service status of the SOME / IP service through the daemon process; when a failure in the SOME / IP service is detected, the SOME / IP service is switched to a SOME / IP backup service, and data transmission and service discovery are performed through the SOME / IP backup service, thereby avoiding service failure and the inability to complete data transmission and service discovery functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0037] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0038] Figure 1 A flowchart of the first embodiment of the method for recovering a middleware service failure in the present application;

[0039] Figure 2 This is a schematic diagram of the interaction between the various layers when the Android system is started;

[0040] Figure 3 This is the interactive diagram of the improved Android system for this application;

[0041] Figure 4 A flow chart of the second embodiment of the method for recovering a middleware service failure in the present application;

[0042] Figure 5 This is a schematic diagram of the module structure of the middleware service failure recovery device in an embodiment of the present application;

[0043] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the middleware service failure recovery method in the embodiment of the present application.

[0044] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0045] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0046] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0047] Since the SOME / IP protocol stack is started by parsing the someipd.rc file through the Android init process, once the service someipd fails, the entire SOME / IP function fails, and the related data transmission function fails. someipd uses a watchdog monitoring mechanism, the purpose of which is to restore the service. If the service itself has defects or bugs, the watchdog mechanism cannot be restored and will cover up the problem of someipd's internal defects. For some complex failures of someipd, for example, the service is "deadlocked" under certain conditions or some functions fail but not completely crashed, the watchdog cannot effectively detect them. Therefore, how to solve the service function failure caused by someipd operation failure is an urgent problem to be solved.

[0048] The present application provides a solution, by starting the SOME / IP service and the daemon process in the SOME / IP service; monitoring the service status of the SOME / IP service through the daemon process; when a failure in the SOME / IP service is detected, the SOME / IP service is switched to the SOME / IP backup service, and data transmission and service discovery are performed through the SOME / IP backup service. The present application starts the SOME / IP service and the daemon process in the SOME / IP service; monitoring the service status of the SOME / IP service through the daemon process; when a failure in the SOME / IP service is detected, the SOME / IP service is switched to the SOME / IP backup service, and data transmission and service discovery are performed through the SOME / IP backup service, thereby avoiding service failure and the inability to complete data transmission and service discovery functions.

[0049] It should be noted that the execution subject of the method of this embodiment can be a computing service device with middleware service failure recovery, network communication and program running functions, or a car equipped with the computing service device; it can also be a middleware service failure recovery device with the same or similar functions. This embodiment and the following embodiments will be described by taking the middleware service failure recovery device as an example.

[0050] Based on this, the present application embodiment provides a method for recovering a middleware service failure. Figure 1 , Figure 1 This is a flow chart of the first embodiment of the middleware service failure recovery method of the present application.

[0051] In this embodiment, the middleware service failure recovery method includes steps S10 to S30:

[0052] Step S10: Start the SOME / IP service and the daemon process in the SOME / IP service.

[0053] It should be noted that first refer to Figure 2 The interaction between the various layers in the existing Android system and the position of the communication middleware in it are explained. The Android system consists of a hardware layer, an operating system, an operating system interface, a communication middleware and an application layer. The process of starting the Android system is that the Android starts the init process to parse the someipd.rc file, load libsomeipd.so, and start the SOME / IP protocol stack service someipd; libsomeip.so is a library file compiled into the Android system, which contains the SOME / IP protocol stack implementation and service discovery functions. The Android system does not fully support the PSE51 version of the Portable Operating System Interface (POSIX) standard or the C++ Standard Template Library (C++STL), where C++ is a programming language. The POSIX layer is designed to be compatible with more advanced process management, memory management, functional safety and other functions; the SOME / IP protocol stack exists in the Android system vendor / lib / and vendor / lib64 directories in the form of libsomeip.so and runs as an Android system service. Data transmission is based on the Transmission Control Protocol / Internet Protocol (TCP / IP) and User Datagram Protocol (UDP) network transport layer protocols; TCP / IP and UDP protocols contain SOME / IP upper-layer application data, and the upper-layer application data meets the SOME / IP protocol specifications; libsomeip.so contains communication matrix analysis, client and server interaction, client and server state machine information, and SOME / IP service discovery function; the upper-layer application obtains the server-side support service through the someipd service and transmits data; the server broadcasts support functions to each client through someipd.

[0054] It is worth noting that in order to solve the technical problem of service failure caused by someipd operation failure, the communication middleware layer is improved by adopting the strategy of standby server. The interaction of the improved Android system can refer to Figure 3. Pre-write and generate a backup service someipd_bak, which is the SOME / IP protocol backup service in the Android system. It is a backup service when someipd exits abnormally, and completes the data transmission and service discovery functions. The backup service can be stored in the system at: / vendor / bin / someipd_bak. someipd_bak is not started when the Android system starts.

[0055] It is understandable that the stage of integrating the SOME / IP protocol service someipd and the protocol stack libsomeip.so into the Android system is explained. First, download the vsomeip source code and Android compilation dependencies boost_1_85 and cmake-3.22.1. Compile the protocol stack content libsomeip.so and SOME / IP service someipd based on the Android source code. The storage locations of libsomeip.so in the system are: / vendor / lib / libsomeip.so and / vendor / lib64 / libsomeip.so, and the storage location of someipd in the system is: / vendor / bin / someipd. Write the someipd.rc file, which is stored in the system location: / vendor / etc / init / someipd.rc, and configure the file system and network operations and other related permissions required for someipd startup. Configure the selinux permissions required for the normal operation of someipd and libsomeip.so, and add a separate domain for someip-related operations in the Android source code to facilitate the unified declaration and configuration of SOME / IP-related permissions, improve readability and portability. The specific permissions include someipd execution permissions, application (Application, app) and socket-related mandatory access control (Security-Enhanced Linux, selinux) permissions.

[0056] It should be understood that after the above download and configuration are completed, the SOME / IP service and the daemon process someipd in the SOME / IP service can be started in the onboot phase of the Android system startup sequence. The Android init process pulls up the someipd service, and the command ps-A|grep someipd can be used to detect that the someipd service is running. At this time, data transmission and service discovery are carried out between the SOME / IP service and the application.

[0057] In a feasible implementation, step S10 may include steps S01 to S02:

[0058] Step S01, generating SOME / IP standby service source code according to the SOME / IP protocol stack and the SOME / IP protocol implementation library.

[0059] It is understandable that before starting the SOME / IP service, the backup service is configured first to ensure that after the SOME / IP service is started and running, the service is switched to the SOME / IP backup service in time when an abnormality occurs in the service. Here, the stage of integrating the SOME / IP backup service someipd_bak into the Android system is explained. First, the backup service someipd_bak source code is written according to the SOME / IP protocol stack and the SOME / IP protocol implementation library. The implementation method adopts its own implementation. The protocol content does not need to be changed, and the libsomeip.so content is used. Among them, the implementation library of the SOME / IP protocol is mainly used for service discovery and message transmission in network communication systems. The implementation library of the SOME / IP protocol can be the vsomeip library, CommonAPI, and GENIVI project, etc.

[0060] Step S02, compile the SOME / IP standby service source code according to the Android source code to obtain the SOME / IP standby service.

[0061] It should be understood that the SOME / IP backup service someipd_bak is compiled based on the Android source code, and the backup service is stored in the system at: / vendor / bin / someipd_bak, and someipd_bak is not started when the Android system is started.

[0062] Step S20: monitoring the service status of the SOME / IP service through the daemon process.

[0063] It can be understood that the SOME / IP service monitoring is implemented internally by the daemon process someipd, and the monitoring is based on periodically sending heartbeat detection to monitor the online service of the SOME / IP service.

[0064] In a feasible implementation, step S20 may include steps S201 to S202:

[0065] Step S201: sending a heartbeat monitoring packet to the SOME / IP service at a preset time interval through the daemon process.

[0066] It is understandable that in order to reduce resource consumption while monitoring the service status in real time, a time interval can be set in advance, and the daemon process someipd sends a heartbeat monitoring package to the SOME / IP service at the preset time interval to monitor the running status of the SOME / IP service through the heartbeat monitoring package.

[0067] Step S202: when receiving the normal operation information of the service fed back by the SOME / IP service within a preset time interval, determining that the SOME / IP service is operating normally.

[0068] It should be understood that if the normal operation information of the service fed back by the SOME / IP service can be received within each preset time interval, it can be determined that the SOME / IP service is operating normally and there is no need to switch to a backup service. The normal operation information of the service can be a heartbeat feedback packet or a response message with a return code indicating that the request is successfully processed. The return code in the SOME / IP protocol is used to indicate whether the request is successfully processed.

[0069] Step S30: when a SOME / IP service operation failure is detected, the SOME / IP service is switched to a SOME / IP standby service, and data transmission and service discovery are performed through the SOME / IP standby service.

[0070] It is understandable that when the SOME / IP service is detected to have an error or unexpected offline operation, the someipd_bak backup service is notified to start, and the SOME / IP service is switched to the SOME / IP backup service. The someipd_bak backup service takes over the corresponding function of someipd, that is, the application layer data transmission and service discovery are performed through the SOME / IP backup service. Through the command ps-A|grep someip, it can be seen that the someipd_bak service is online and the someipd service has been offline.

[0071] Here is an explanation of the test process of sending data from an application to the other end through the SOME / IP protocol stack. Write a test case hello_someip application based on SOME / IP protocol data transmission; the application sends data through the someip protocol stack libsomeip.so; the Android system executes the command adb shell to enter the Android shell command line; after the command line executes the su command, check the someipd service pid: ps-elf|grep someipd. Manually kill the someipd service through kill-9+someip's pid, where pid (Process Identifier) ​​refers to the process ID of the someipd service; the backup service someipd_bak is pulled up by someipd, and the application layer data transmission is not affected by the above actions, ensuring the normal operation of the SOME / IP function.

[0072] The present embodiment provides a method for recovering a middleware service failure, by starting a SOME / IP service and a daemon process in the SOME / IP service; monitoring the service status of the SOME / IP service through the daemon process; when a running failure of the SOME / IP service is detected, the SOME / IP service is switched to a SOME / IP standby service, and data transmission and service discovery are performed through the SOME / IP standby service. The present embodiment starts a SOME / IP service and a daemon process in the SOME / IP service; monitoring the service status of the SOME / IP service through the daemon process; when a running failure of the SOME / IP service is detected, the SOME / IP service is switched to a SOME / IP standby service, and data transmission and service discovery are performed through the SOME / IP standby service, thereby avoiding service failure and failure to complete data transmission and service discovery functions.

[0073] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 4 , step S30, the middleware service failure recovery method further includes steps S301 to S303:

[0074] Step S301: when no normal service operation information fed back by the SOME / IP service is received within a preset time interval, it is determined that the SOME / IP service has an operation failure.

[0075] It is understandable that if no normal service operation information fed back by the SOME / IP service is received within a preset time interval, it means that the SOME / IP service heartbeat stops or operates abnormally, and an operation failure occurs.

[0076] Step S302: starting the SOME / IP standby service through the daemon process, and switching the SOME / IP service to the SOME / IP standby service.

[0077] It is understandable that when someipd does not receive a heartbeat packet within a specified time, someipd starts the someipd_bak backup service, switches the SOME / IP service to the SOME / IP backup service, and replaces the original someipd function.

[0078] In a feasible implementation manner, step S302 may further include steps S3021 to S3023:

[0079] Step S3021: Send a restart command to the SOME / IP service through the daemon process.

[0080] It is understandable that when the heartbeat signal of the SOME / IP service is detected to stop, the daemon process can take corresponding measures, such as sending a restart command to try to restart the SOME / IP service, or notifying the administrator to restart the SOME / IP service.

[0081] Step S3022: Detect the currently running SOME / IP service instance in real time through the daemon process.

[0082] It should be understood that in order to ensure that the system has only one SOME / IP service in an active state, the daemon process can query the currently running SOME / IP service instance through a specific command line tool or script to determine whether the SOME / IP service is successfully restarted. If the restart is successful, there is no need to switch to the backup service. These tools or scripts can help administrators quickly understand the operating status of the system and take action when necessary.

[0083] Step S3023: when the SOME / IP service instance is not detected, starting the SOME / IP standby service through the daemon process, and switching the SOME / IP service to the SOME / IP standby service.

[0084] It should be understood that if the SOME / IP service instance is detected, it means that the original SOME / IP service has been successfully restarted and there is no need to switch to the backup service. If the SOME / IP service instance is not detected, it means that the restart has failed. In order to ensure the normal operation of the function, the SOME / IP backup service needs to be started and the SOME / IP service needs to be switched to the SOME / IP backup service.

[0085] Step S303: establishing a routing communication channel through the SOME / IP standby service and the application program, and performing data transmission and service discovery with the application program through the routing communication channel.

[0086] It is understandable that after someipd_bak takes over the functions of someipd, the application needs to re-establish the routing communication channel with someipd_bak in the same way as someipd.

[0087] In a feasible implementation, step S303 may include steps S3031 to S3034:

[0088] Step S3031: Establish a routing communication channel with the application program through the SOME / IP backup service and a preset unique identifier.

[0089] It is understandable that the specific steps for establishing a routing communication channel between the application and someipd_bak are described here. The SOME / IP backup service someipd_bak establishes a routing communication channel with the application through a preset unique identifier.

[0090] Step S3032: Send a channel identification message as the first message to the application through the SOME / IP backup service and the routing communication channel, wherein the channel identification message includes the preset unique identifier.

[0091] Step S3033: Receive a control message sent by the application according to the preset unique identifier.

[0092] Step S3034: Perform data transmission and service discovery with the application according to the control message through the SOME / IP standby service.

[0093] It can be understood that after the communication channel is established, the someipd_bak daemon sends the Channel_Id message (channel identification message) as the first message, which contains the unique identifier assigned to the established routing communication channel. The application needs the channel identifier to send a control message to someipd_bak so that someipd_bak can identify that the received control message is applicable to the corresponding routing communication channel, thereby satisfying data transmission and service discovery.

[0094] In this embodiment, a routing communication channel is established through a unique identifier through the application and the backup service someipd_bak. After the communication channel is established, someipd_bak sends a channel identification message as the first message, which contains the unique identifier assigned to the established routing communication channel. The application needs the channel identifier to send a control message to someipd_bak so that someipd_bak can recognize that the received control message is applicable to the corresponding routing communication channel, thereby satisfying data transmission.

[0095] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the middleware service fault recovery method of the present application. More simple transformations based on this technical concept are all within the protection scope of the present application.

[0096] This application also provides a middleware service failure recovery device, please refer to Figure 5 , the middleware service failure recovery device comprises:

[0097] A service startup module 10 is used to start the SOME / IP service and the daemon process in the SOME / IP service;

[0098] A service status monitoring module 20, configured to monitor the service status of the SOME / IP service through the daemon process;

[0099] The standby service switching module 30 is used to switch the SOME / IP service to the SOME / IP standby service when a SOME / IP service operation failure is detected, and perform data transmission and service discovery through the SOME / IP standby service.

[0100] The middleware service failure recovery device provided by the present application adopts the middleware service failure recovery method in the above embodiment to solve the technical problem. Compared with the prior art, the beneficial effects of the middleware service failure recovery device provided by the present application are the same as the beneficial effects of the middleware service failure recovery method provided by the above embodiment, and other technical features in the middleware service failure recovery device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0101] The present application provides a middleware service fault recovery device, which includes: at least one processor; and a memory that is communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the middleware service fault recovery method in the above-mentioned embodiment one.

[0102] Reference below Figure 6, which shows a schematic diagram of the structure of a middleware service fault recovery device suitable for implementing the embodiment of the present application. The middleware service fault recovery device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The middleware service fault recovery device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0103] like Figure 6 As shown, the middleware service fault recovery device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. Various programs and data required for the operation of the middleware service fault recovery device are also stored in the RAM 1004. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems may be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 may allow the middleware service fault recovery device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a middleware service fault recovery device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0104] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0105] The middleware service failure recovery device provided by the present application adopts the middleware service failure recovery method in the above embodiment, which can solve the technical problem of middleware service failure recovery. Compared with the prior art, the beneficial effects of the middleware service failure recovery device provided by the present application are the same as the beneficial effects of the middleware service failure recovery method provided by the above embodiment, and other technical features in the middleware service failure recovery device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0106] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0107] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0108] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the middleware service failure recovery method in the above-mentioned embodiment.

[0109] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0110] The computer-readable storage medium may be included in the middleware service failure recovery device; or may exist independently without being assembled into the middleware service failure recovery device.

[0111] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the middleware service fault recovery device, the middleware service fault recovery device: starts the SOME / IP service and the daemon process in the SOME / IP service; monitors the service status of the SOME / IP service through the daemon process; when a running failure of the SOME / IP service is detected, switches the SOME / IP service to a SOME / IP backup service, and performs data transmission and service discovery through the SOME / IP backup service.

[0112] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0113] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0114] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0115] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned middleware service failure recovery method, and can solve the technical problem. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the middleware service failure recovery method provided by the above-mentioned embodiment, and will not be repeated here.

[0116] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned middleware service failure recovery method when executed by a processor.

[0117] The computer program product provided by the present application can solve the technical problem. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the middleware service failure recovery method provided by the above embodiment, which will not be described in detail here.

[0118] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for recovering a middleware service failure, characterized in that: The method includes: Start the SOME / IP service and the daemon process in the SOME / IP service; Performing service status monitoring on the SOME / IP service through the daemon process; When a running failure of the SOME / IP service is detected, the SOME / IP service is switched to a SOME / IP standby service, and data transmission and service discovery are performed through the SOME / IP standby service.

2. The method according to claim 1, characterized in that The step of switching the SOME / IP service to a SOME / IP standby service when a SOME / IP service operation failure is detected, and performing data transmission and service discovery through the SOME / IP standby service comprises: When no normal service operation information fed back by the SOME / IP service is received within a preset time interval, determining that the SOME / IP service operation fails; Starting the SOME / IP standby service through the daemon process, and switching the SOME / IP service to the SOME / IP standby service; A routing communication channel is established through the SOME / IP backup service and the application program, and data transmission and service discovery are performed with the application program through the routing communication channel.

3. The method according to claim 2, characterized in that The step of establishing a routing communication channel through the SOME / IP backup service and the application, and performing data transmission and service discovery with the application through the routing communication channel comprises: Establishing a routing communication channel with the application via the SOME / IP backup service and a preset unique identifier; Sending a channel identification message as a first message to the application through the SOME / IP backup service and the routing communication channel, wherein the channel identification message includes the preset unique identifier; receiving a control message sent by the application according to the preset unique identifier; The SOME / IP standby service performs data transmission and service discovery with the application according to the control message.

4. The method according to claim 2, characterized in that The step of starting the SOME / IP standby service through the daemon process and switching the SOME / IP service to the SOME / IP standby service comprises: Sending a restart command to the SOME / IP service through the daemon process; Real-time detection of currently running SOME / IP service instances by the daemon process; When the SOME / IP service instance is not detected, the SOME / IP standby service is started by the daemon process, and the SOME / IP service is switched to the SOME / IP standby service.

5. The method according to claim 1, characterized in that The step of monitoring the service status of the SOME / IP service through the daemon process comprises: Sending a heartbeat monitoring packet to the SOME / IP service at a preset time interval by the daemon process; When normal service operation information fed back by the SOME / IP service is received within a preset time interval, it is determined that the SOME / IP service is operating normally.

6. The method according to claim 1, characterized in that Before the step of starting the SOME / IP service and the daemon process in the SOME / IP service, the method further includes: Generate SOME / IP backup service source code based on SOME / IP protocol stack and SOME / IP protocol implementation library; The SOME / IP backup service source code is compiled according to the Android source code to obtain the SOME / IP backup service.

7. A middleware service failure recovery device, characterized in that: The middleware service failure recovery device comprises: The service startup module is used to start the SOME / IP service and the daemon process in the SOME / IP service; A service status monitoring module, used for monitoring the service status of the SOME / IP service through the daemon process; The standby service switching module is used to switch the SOME / IP service to the SOME / IP standby service when a SOME / IP service operation failure is detected, and perform data transmission and service discovery through the SOME / IP standby service.

8. A middleware service failure recovery device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the middleware service failure recovery method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the middleware service failure recovery method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the middleware service failure recovery method according to any one of claims 1 to 6 are implemented.

Images