Service management method, system and device based on automobile SOA (Service Oriented Architecture) and medium

Abstract

The invention discloses a service management method, system and device based on an automobile SOA framework and a medium, and the method comprises the steps: reading corresponding service configuration information when a service instance is started, and initiating a service registration request to a service registration center according to the service configuration information; the service configuration information is written into a registry through the service registration center, and the service instance is marked as a healthy state; in response to a service query request of the client, generating an available service list through the service registration center according to the service instances in the healthy state, and returning the available service list to the client; and determining a target service instance according to the service instance list through the client, and initiating service calling to the target service instance. The service reliability and the system stability under the automobile SOA architecture are improved, and the method can be widely applied to the technical field of automobile software design.

Description

Technical Field

[0001] The present invention relates to the technical field of automobile software design, and in particular to a service management method, system, device and medium based on an automobile SOA architecture. Background Art

[0002] Currently, SOA (Service-Oriented Architecture) typically uses a layered development model consisting of upper-layer applications, middle-layer operating systems, and underlying hardware to decouple software and hardware. The different functional units of the upper-layer applications are modularized and defined as different services. Services are discoverable software entities that can access each other through service interfaces. Typical in-vehicle services are divided into the following three layers:

[0003] Basic services: provide the most basic functions of the vehicle, which are closely related to electronic and electrical hardware;

[0004] Extended services: These are relatively complex and require the invocation of multiple basic services, such as data fusion from different sensors.

[0005] Application services: These are generally user-perceivable functions that are strongly related to vehicle scenarios. The implementation of application services depends on one or more extended services.

[0006] However, existing SOA solutions have the following shortcomings:

[0007] 1) Insufficient service monitoring and fault detection

[0008] Limited monitoring scope: SOA services have an incomplete monitoring mechanism, which makes it impossible to detect and handle service failures in a timely manner. The limited monitoring scope may prevent services from being detected quickly when failures occur, thereby extending the time for failure recovery.

[0009] Inaccurate fault detection: It is impossible to accurately identify all types of service faults. False positives or missed positives may cause unnecessary system downtime or service interruptions, affecting user experience and system stability.

[0010] 2) Imperfect service recovery mechanism

[0011] Weak automatic recovery capabilities: SOA services lack automatic recovery mechanisms. When a service fails, manual intervention is required to repair it. This not only increases operation and maintenance costs, but also may prolong fault recovery time and affect system availability.

[0012] 3) Service dependency management is complex

[0013] Unclear dependencies: In a SOA architecture, services have complex dependencies. If these dependencies are not effectively managed and maintained, a service failure can trigger a chain reaction, causing multiple services to fail simultaneously. Summary of the Invention

[0014] The purpose of the present invention is to solve one of the technical problems existing in the prior art to at least a certain extent.

[0015] Therefore, an object of an embodiment of the present invention is to provide a service management method based on an automotive SOA architecture, which improves the reliability of services and the stability of the system under the automotive SOA architecture.

[0016] Another object of an embodiment of the present invention is to provide a service management system based on an automotive SOA architecture.

[0017] In order to achieve the above technical objectives, the technical solutions adopted by the embodiments of the present invention include:

[0018] In a first aspect, an embodiment of the present invention provides a service management method based on an automotive SOA architecture, comprising the following steps:

[0019] When a service instance is started, it reads the corresponding service configuration information and initiates a service registration request to the service registration center based on the service configuration information;

[0020] Writing the service configuration information into a registry through the service registration center and marking the service instance as healthy;

[0021] In response to a service query request from a client, generating an available service list according to the service instance in a healthy state through the service registration center, and returning the available service list to the client;

[0022] The client determines a target service instance according to the service instance list and initiates a service call to the target service instance.

[0023] Furthermore, in one embodiment of the present invention, the reading of the corresponding service configuration information and initiating a service registration request to a service registration center according to the service configuration information specifically includes:

[0024] Reading the service configuration information corresponding to the service instance through the service providing ECU, wherein the service configuration information includes the service name, IP address, port number and service instance metadata of the service instance;

[0025] Generate service registration request data according to the service configuration information, and send the service registration request data to the service registration center.

[0026] Furthermore, in one embodiment of the present invention, generating an available service list according to the service instance in a healthy state by the service registration center and returning the available service list to the client specifically includes:

[0027] Determine, through the service registration center, that the service instance in a healthy state is an available service instance, and obtain the service configuration information corresponding to the available service instance from the registration table;

[0028] Generate an available service list according to the service configuration information corresponding to the available service instance, and return the available service list to the client.

[0029] Furthermore, in one embodiment of the present invention, determining the target service instance according to the service instance list by the client and initiating a service call to the target service instance specifically includes:

[0030] Selecting the target service instance to be called from the service instance list through the client, and obtaining target service configuration information corresponding to the target service instance;

[0031] A target service providing ECU and service calling parameters are determined according to the target service configuration information, and service calling request data is generated according to the service calling parameters, and then the service calling request data is sent to the target service providing ECU.

[0032] Furthermore, in one embodiment of the present invention, the service management method further includes the following steps:

[0033] Sending a heartbeat signal to the service registration center at a preset time interval through a registered service instance, or detecting the port of the registered service instance at a preset time interval through the service registration center to obtain a detection result;

[0034] Determine whether the heartbeat of the corresponding service instance has timed out according to the heartbeat signal or the detection result;

[0035] When it is determined that the heartbeat has timed out, the corresponding service instance is removed from the available service list and marked as unhealthy, and the client is notified.

[0036] Furthermore, in one embodiment of the present invention, the service management method further includes the following steps:

[0037] When the service instance marked as unhealthy resumes heartbeat, the corresponding service instance is added back to the available service list and marked as healthy, and then the client is notified.

[0038] Furthermore, in one embodiment of the present invention, the service management method further includes the following steps:

[0039] When a service deregistration request is received for a registered service instance, or when the heartbeat timeout of a registered service instance reaches a preset threshold, the service registration center deletes the corresponding service configuration information from the registration table and sends a service change notification to the client, so that the client updates the local service list.

[0040] In a second aspect, an embodiment of the present invention provides a service management system based on an automotive SOA architecture, including:

[0041] The registration request module is used to read the corresponding service configuration information when the service instance is started, and initiate a service registration request to the service registration center according to the service configuration information;

[0042] A service registration module is used to write the service configuration information into a registry through the service registration center and mark the service instance as healthy;

[0043] A service query module is configured to respond to a service query request from a client, generate an available service list based on the service instances in a healthy state through the service registration center, and return the available service list to the client;

[0044] The service calling module is used to determine the target service instance according to the service instance list through the client and initiate a service call to the target service instance.

[0045] In a third aspect, an embodiment of the present invention provides a service management device based on an automotive SOA architecture, comprising:

[0046] at least one processor;

[0047] at least one memory for storing at least one program;

[0048] When the at least one program is executed by the at least one processor, the at least one processor implements the above-mentioned service management method based on the automobile SOA architecture.

[0049] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium storing a program executable by a processor, wherein the program executable by the processor is used to execute the above-mentioned service management method based on the automotive SOA architecture when executed by the processor.

[0050] The advantages and benefits of the present invention will be described in part in the following description and will become apparent from the following description or learned through practice of the present invention:

[0051] In an embodiment of the present invention, when a service instance is started, the corresponding service configuration information is read, and a service registration request is initiated to a service registration center based on the service configuration information. The service registration center writes the service configuration information into the registry and marks the service instance as healthy. In response to a service query request from a client, the service registration center generates an available service list based on the service instance in a healthy state and returns the available service list to the client. The client determines the target service instance based on the service instance list and initiates a service call to the target service instance. In an embodiment of the present invention, through dynamic registration and discovery of service instances, a newly started service instance can be automatically registered with the service registration center, supporting elastic scaling and optimizing resource utilization. At the same time, the client can obtain the latest available instance list in real time without manual intervention. This is suitable for scenarios where the vehicle network fluctuates and service instances are dynamically scaled. A heartbeat detection mechanism automatically marks a service instance with a heartbeat timeout as an unhealthy instance and removes it from the available service list, allowing the client to only request service nodes in a healthy state, thereby improving system availability and avoiding system avalanches due to single point failures. After the heartbeat is restored, the service can be automatically restored without manual intervention, thereby improving the reliability of services and the stability of the system under the automotive SOA architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following introduction is made to the drawings required for use in the embodiments of the present invention. It should be understood that the drawings introduced below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative work.

[0053] Figure 1 A flowchart of a service management method based on an automotive SOA architecture provided by an embodiment of the present invention;

[0054] Figure 2 A schematic diagram of the interaction of service registration provided by an embodiment of the present invention;

[0055] Figure 3 A schematic diagram of the interaction of service discovery provided by an embodiment of the present invention;

[0056] Figure 4 A schematic diagram of the interaction of service keep-alive provided by an embodiment of the present invention;

[0057] Figure 5 A schematic diagram of the interaction for service deregistration provided by an embodiment of the present invention;

[0058] Figure 6 A structural diagram of a service management system based on an automotive SOA architecture provided by an embodiment of the present invention;

[0059] Figure 7 This is a structural block diagram of a service management device based on an automotive SOA architecture provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0060] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and are not to be construed as limiting the present invention. The step numbers in the following embodiments are provided for ease of explanation only and do not limit the order of the steps. The order of execution of the steps in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0061] In the description of the present invention, "a plurality" means two or more. The terms "first" and "second" are used solely to distinguish technical features and are not to be construed as indicating or implying relative importance, or as implicitly indicating the number of the indicated technical features, or as implicitly indicating the order of the indicated technical features. Furthermore, unless otherwise defined, all technical and scientific terms used herein have the same meanings as commonly understood by those skilled in the art.

[0062] Reference Figure 1 The embodiment of the present invention provides a service management method based on the automotive SOA architecture, which specifically includes the following steps:

[0063] S101. When a service instance is started, the corresponding service configuration information is read and a service registration request is initiated to the service registration center according to the service configuration information.

[0064] S102. Write the service configuration information into the registry through the service registration center and mark the service instance as healthy;

[0065] S103. In response to the service query request from the client, the service registration center generates an available service list based on the service instances in a healthy state, and returns the available service list to the client;

[0066] S104: The client determines a target service instance according to the service instance list and initiates a service call to the target service instance.

[0067] The embodiment of the present invention enables newly started service instances to be automatically registered with the service registration center through dynamic registration and discovery of service instances, supports elastic scaling, and optimizes resource utilization. At the same time, the client can obtain the latest list of available instances in real time without manual intervention. It is suitable for scenarios with vehicle network fluctuations and dynamic scaling of service instances. Through the heartbeat detection mechanism, service instances with heartbeat timeouts are automatically marked as unhealthy instances and removed from the list of available services, so that the client can only request service nodes in a healthy state, thereby improving system availability and avoiding system avalanches due to single point failures. After the heartbeat is restored, the service can be automatically restored without manual intervention, thereby improving the reliability of services and the stability of the system under the automotive SOA architecture.

[0068] As an optional implementation method, the corresponding service configuration information is read, and a service registration request is initiated to the service registration center according to the service configuration information, which specifically includes:

[0069] S1011. Read the service configuration information corresponding to the service instance through the service provision ECU. The service configuration information includes the service name, IP address, port number, and service instance metadata of the service instance.

[0070] S1012: Generate service registration request data according to the service configuration information, and send the service registration request data to the service registration center.

[0071] Specifically, if Figure 2 The figure shows an interactive diagram of service registration provided by an embodiment of the present invention. When a service (such as a navigation service or voice service) is started, it reads its own configuration information (service name, IP address, port number, metadata, etc.) and sends a registration request to the service registration center. The registration center stores the service information in a distributed database or memory, marks it as "healthy", and returns a successful registration to the service provider ECU, at which time the service enters a discoverable state. The specific process is as follows:

[0072] 1) Obtaining service configuration information

[0073] The ECU needs to read the configuration information of the service instance through the built-in interface or protocol. The specific process is as follows:

[0074] Service name: Usually defined based on the ECU functional module (such as the power control module is named powertrain-service), which can be obtained through the AUTOSAR service layer metadata interface.

[0075] IP address and port number: need to be extracted from the ECU's network communication module (such as TCP / IP protocol stack configuration), which can be obtained by reading the preset DID identifier through the 22 service (ReadDataByIdentifier).

[0076] Metadata: including service version, health check path, etc., can be stored through custom DID (data identifier) and read using the 22 service of the UDS protocol.

[0077] 2) Service registration request generation: Encapsulate the configuration information into a format supported by the registration center (such as JSON).

[0078] 3) Registration request sending and processing

[0079] Communication protocol selection: If the registration center supports HTTP, the ECU sends a POST request through the built-in TCP / IP module; if it is within the vehicle network, the data frame can be encapsulated and transmitted through a diagnostic protocol (such as UDS service 31).

[0080] Security mechanism: Security authentication must be completed through the 27 service (SecurityAccess) to ensure the legitimacy of the registration request.

[0081] Response processing: Receive the response from the registry (such as HTTP 201Created). If it fails, retry or record the error log (read the DTC status through service 19).

[0082] As an optional implementation, the service registration center generates an available service list based on the service instances in a healthy state and returns the available service list to the client, which specifically includes:

[0083] S1031. Determine, through the service registration center, that a service instance in a healthy state is an available service instance, and obtain service configuration information corresponding to the available service instance from the registration center;

[0084] S1032: Generate an available service list according to the service configuration information corresponding to the available service instance, and return the available service list to the client.

[0085] As an optional implementation, the client determines the target service instance according to the service instance list and initiates a service call to the target service instance, which specifically includes:

[0086] S1041. Selecting a target service instance to be called from a service instance list through the client, and obtaining target service configuration information corresponding to the target service instance;

[0087] S1042: Determine the target service providing ECU and service call parameters according to the target service configuration information, generate service call request data according to the service call parameters, and then send the service call request data to the target service providing ECU.

[0088] Specifically, if Figure 3The following is a schematic diagram of the service discovery interaction provided by an embodiment of the present invention. When a client needs to call a service, it sends a query request to the service registry. The registry returns a list of all healthy service instances. The client then sends a request to the selected service instance via a communication protocol. The specific process is as follows:

[0089] 1) Filtering Available Service Instances: The registry filters available service instances from the registry based on those marked as healthy. Only healthy service instances are included in the available list. The registry also considers other filtering criteria, such as service version and service tags, to further narrow the list of available service instances.

[0090] 2) Service discovery request processing: When a client initiates a service discovery request to the registry, the registry receives the request and obtains the service name and other filtering conditions required by the client. Based on this information, the registry searches for a matching service instance from the filtered list of available service instances.

[0091] 3) Returning a list of available service instances: The registry organizes the available service instances it matches into a list, typically including the service instance's IP address, port number, and other information. Finally, the registry returns this list to the client, which can then use this information to call the corresponding service using the appropriate communication protocol.

[0092] As an optional implementation, the service management method further includes the following steps:

[0093] S201, sending a heartbeat signal to a service registration center at a preset time interval through a registered service instance, or detecting a port of a registered service instance at a preset time interval through the service registration center to obtain a detection result;

[0094] S202, determining whether the heartbeat of the corresponding service instance has timed out according to the heartbeat signal or the detection result;

[0095] S203: When it is determined that the heartbeat has timed out, the corresponding service instance is removed from the available service list and marked as unhealthy, and the client is notified.

[0096] As an optional implementation, the service management method further includes the following steps:

[0097] S204: When the service instance marked as unhealthy resumes its heartbeat, the corresponding service instance is added back into the available service list and marked as healthy, and then the client is notified.

[0098] Specifically, if Figure 4The figure shows an interactive diagram of service keepalive provided by an embodiment of the present invention. A registered service instance periodically sends a heartbeat signal (HTTP heartbeat packet or TCP long connection keepalive) to the registration center, or the registration center actively detects the port or API endpoint of the service instance to verify whether the service is alive; the registration center maintains the "last heartbeat time" of each service instance. If the heartbeat timeout exceeds a certain number of times in a row, the service is marked as "unhealthy" and removed from the available list, and the client is notified that the current service is unavailable; if the service instance resumes heartbeating, it is re-marked as "healthy" and re-added to the available list, and the client is notified that the current service has been restored. The specific process is as follows:

[0099] 1) Two modes of heartbeat detection and health detection

[0100] (1) Active heartbeat mode (initiated by the client)

[0101] The client sends heartbeat packets regularly: the registered service instance starts a scheduled task (for example, the Nacos client sends a heartbeat every 5 seconds by default) and sends a heartbeat signal to the registration center through HTTP requests or specific protocols (such as UDS). The heartbeat packet contains metadata about the service instance (such as IP, port, and service name).

[0102] The server records the heartbeat time: After receiving the heartbeat, the registration center updates the last heartbeat timestamp of the corresponding service instance (such as Nacos updates it through Instance.setLastBeat()).

[0103] (2) Passive detection mode (initiated by the server)

[0104] The registration center actively detects ports: The service registration center regularly verifies the connectivity of service instances through preset detection strategies (such as TCP port detection and HTTP health check interface calls) (such as Consul detecting health status through HTTP requests).

[0105] Probe result processing: Determine the instance status based on the probe response status code (such as HTTP 200 for healthy) or port connectivity results.

[0106] 2) Heartbeat timeout judgment logic

[0107] (1) Timeout threshold setting: The registration center presets the timeout period (e.g. Nacos defaults to marking a connection as unhealthy if no heartbeat is received within 15 seconds and removes it after 30 seconds). In detection mode, if multiple consecutive detections fail (e.g. 3 TCP connection timeouts), it is considered unhealthy.

[0108] (2) Timeout detection process

[0109] Scheduled scanning task: The registration center starts a background thread (such as Nacos's ClientBeatCheckTask), periodically traverses all service instances, and calculates the difference between the current time and the last heartbeat time / last detection time.

[0110] Status flag: If the difference exceeds the threshold, the instance health status is set to false (such as Nacos through Instance.setHealthy(false)) and the timeout event log is recorded.

[0111] 3) Service instance removal and status synchronization

[0112] (1) Remove from the available list

[0113] Registry update: The registration center removes the timed-out service instance from the memory registry (such as the ConcurrentHashMap structure of Nacos) and updates the local cache of the service instance list.

[0114] Cluster synchronization: In a distributed scenario, state changes are synchronized to other nodes through a consistency protocol (such as Nacos's Distro protocol or Raft protocol) to ensure data consistency.

[0115] (2) Client notification mechanism

[0116] Active push: The registration center notifies the client subscribing to the service to update the local service list through long polling or event push (such as Nacos's ServiceChangeEvent).

[0117] Client cache update: The client periodically pulls the latest service list (for example, the Nacos client pulls it every 10 seconds by default), or receives changes in real time through a monitoring mechanism (such as Zookeeper's Watcher mechanism).

[0118] As an optional implementation, the service management method further includes the following steps:

[0119] S205. When a service deregistration request is received from a registered service instance, or when the heartbeat timeout of a registered service instance reaches a preset threshold, the service registration center deletes the corresponding service configuration information from the registration table and sends a service change notification to the client, so that the client updates the local service list.

[0120] Specifically, if Figure 5The figure shows an interactive diagram of service deregistration provided by an embodiment of the present invention. Before the service instance is normally closed, a deregistration request is sent to the registration center to deregister the service. At the same time, the registration center automatically cleans up invalid instances through the heartbeat timeout mechanism; the registration center pushes change notifications to all clients subscribed to the service, triggering the client to update the local service list.

[0121] The above describes the method steps of the embodiment of the present invention. It is understandable that the embodiment of the present invention enables newly started service instances to be automatically registered with the service registration center through dynamic registration and discovery of service instances, supports elastic scaling, optimizes resource utilization, and at the same time, the client can obtain the latest list of available instances in real time without manual intervention. It is suitable for scenarios where the vehicle network fluctuates and service instances are dynamically scaled. The heartbeat detection mechanism automatically marks the service instance with a heartbeat timeout as an unhealthy instance and removes it from the list of available services, so that the client can only request service nodes in a healthy state, thereby improving system availability and avoiding system avalanches due to single point failures. After the heartbeat is restored, the service can be automatically restored without manual intervention, thereby improving the reliability of services and the stability of the system under the automotive SOA architecture.

[0122] Reference Figure 6 The embodiment of the present invention provides a service management system based on the automotive SOA architecture, including:

[0123] The registration request module is used to read the corresponding service configuration information when the service instance is started, and initiate a service registration request to the service registration center based on the service configuration information;

[0124] The service registration module is used to write service configuration information into the registry through the service registration center and mark the service instance as healthy;

[0125] The service query module is used to respond to the service query request of the client, generate a list of available services based on the service instances in a healthy state through the service registration center, and return the list of available services to the client;

[0126] The service call module is used to determine the target service instance according to the service instance list through the client and initiate a service call to the target service instance.

[0127] The contents of the above method embodiments are all applicable to the present system embodiments. The functions specifically implemented by the present system embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0128] Reference Figure 7 The embodiment of the present invention provides a service management device based on the automobile SOA architecture, including:

[0129] at least one processor;

[0130] at least one memory for storing at least one program;

[0131] When the at least one program is executed by the at least one processor, the at least one processor implements the service management method based on the automotive SOA architecture.

[0132] The contents of the above method embodiments are all applicable to the present device embodiments. The functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0133] An embodiment of the present invention further provides a computer-readable storage medium storing a program executable by a processor. When the program is executed by the processor, it is used to execute the above-mentioned service management method based on the automotive SOA architecture.

[0134] A computer-readable storage medium according to an embodiment of the present invention can execute a service management method based on an automotive SOA architecture provided by an embodiment of the method according to the present invention, can execute any combination of implementation steps of the embodiment of the method, and has the corresponding functions and beneficial effects of the method.

[0135] The embodiment of the present invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs Figure 1 The method shown.

[0136] In some optional embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the above-mentioned boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided in an exemplary manner for the purpose of providing a more comprehensive understanding of the technology. The disclosed method is not limited to the operation and logic flow presented herein. Optional embodiments are contemplated in which the order of the various operations is changed and the sub-operations described as a part of a larger operation are performed independently.

[0137] In addition, although the present invention is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the above-mentioned functions and / or features can be integrated into a single physical device and / or software module, or one or more functions and / or features can be implemented in separate physical devices or software modules. It is also understood that a detailed discussion of the actual implementation of each module is not necessary for understanding the present invention. More specifically, given the properties, functions, and internal relationships of the various functional modules in the devices disclosed herein, the actual implementation of the module will be understood within the routine skills of an engineer. Therefore, a person skilled in the art can implement the present invention set forth in the claims using ordinary skills without undue experimentation. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.

[0138] If the above functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the above methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program code.

[0139] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0140] More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic devices), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable media on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, deciphering, or processing in another suitable manner as necessary, and then stored in a computer memory.

[0141] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0142] In the above description of this specification, reference to the terms "one embodiment / example," "another embodiment / example," or "certain embodiments / examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0143] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the claims and their equivalents.

[0144] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A service management method based on automobile SOA architecture, characterized in that: The following steps are involved: When a service instance is started, it reads the corresponding service configuration information and initiates a service registration request to the service registration center based on the service configuration information; Writing the service configuration information into a registry through the service registration center and marking the service instance as healthy; In response to a service query request from a client, generating an available service list according to the service instance in a healthy state through the service registration center, and returning the available service list to the client; The client determines a target service instance according to the service instance list and initiates a service call to the target service instance.

2. The service management method based on automobile SOA architecture according to claim 1, characterized in that: The reading of the corresponding service configuration information and initiating a service registration request to the service registration center according to the service configuration information specifically includes: Reading the service configuration information corresponding to the service instance through the service providing ECU, wherein the service configuration information includes the service name, IP address, port number and service instance metadata of the service instance; Generate service registration request data according to the service configuration information, and send the service registration request data to the service registration center.

3. The service management method based on automobile SOA architecture according to claim 1, characterized in that: Generating an available service list according to the service instance in a healthy state through the service registration center and returning the available service list to the client specifically includes: Determine, through the service registration center, that the service instance in a healthy state is an available service instance, and obtain the service configuration information corresponding to the available service instance from the registration table; Generate an available service list according to the service configuration information corresponding to the available service instance, and return the available service list to the client.

4. The service management method based on automobile SOA architecture according to claim 1, characterized in that: The determining, by the client, a target service instance according to the service instance list, and initiating a service call to the target service instance specifically includes: Selecting the target service instance to be called from the service instance list through the client, and obtaining target service configuration information corresponding to the target service instance; A target service providing ECU and service calling parameters are determined according to the target service configuration information, and service calling request data is generated according to the service calling parameters, and then the service calling request data is sent to the target service providing ECU.

5. The service management method based on automobile SOA architecture according to claim 1, characterized in that: The service management method further comprises the following steps: Sending a heartbeat signal to the service registration center at a preset time interval through a registered service instance, or detecting the port of the registered service instance at a preset time interval through the service registration center to obtain a detection result; Determine whether the heartbeat of the corresponding service instance has timed out according to the heartbeat signal or the detection result; When it is determined that the heartbeat has timed out, the corresponding service instance is removed from the available service list and marked as unhealthy, and the client is notified.

6. The service management method based on automobile SOA architecture according to claim 5, characterized in that: The service management method further comprises the following steps: When the service instance marked as unhealthy resumes heartbeat, the corresponding service instance is added back to the available service list and marked as healthy, and then the client is notified.

7. The service management method based on automobile SOA architecture according to claim 5, characterized in that: The service management method further comprises the following steps: When a service deregistration request is received for a registered service instance, or when the heartbeat timeout of a registered service instance reaches a preset threshold, the service registration center deletes the corresponding service configuration information from the registration table and sends a service change notification to the client, so that the client updates the local service list.

8. A service management system based on automobile SOA architecture, characterized in that: include: The registration request module is used to read the corresponding service configuration information when the service instance is started, and initiate a service registration request to the service registration center according to the service configuration information; A service registration module is used to write the service configuration information into a registry through the service registration center and mark the service instance as healthy; A service query module is configured to respond to a service query request from a client, generate an available service list based on the service instances in a healthy state through the service registration center, and return the available service list to the client; The service calling module is used to determine the target service instance according to the service instance list through the client and initiate a service call to the target service instance.

9. A service management device based on automobile SOA architecture, characterized in that: include: at least one processor; at least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the service management method based on the automobile SOA architecture as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium storing a program executable by a processor, characterized in that: The processor-executable program is used to execute the service management method based on the automobile SOA architecture as claimed in any one of claims 1 to 7 when executed by the processor.

Images