Micro-service architecture, construction method and device for embedded system development

Abstract

The application discloses a micro-service architecture for embedded system development, comprising a management service module, a hardware service module and a server micro-service architecture; the management service module is used for service monitoring and service configuration; the hardware service module is used for providing an abstract hardware interface and supporting underlying hardware operation; the server micro-service architecture comprises a service process creation unit and a message communication unit; the service process creation unit is used for creating a service process; the message communication unit is used for communication between service messages; wherein, a service process to be created is received; the service process is decomposed into communication service information and service control information; a communication connection is established through the communication service information and a control instruction is issued; the service control information receives the control instruction issued by the communication service information to control the state of a preset external interface corresponding to the service process; the application can decompose complex business into a plurality of relatively simple sub-business units, reduce development difficulty, and improve code maintainability and testability.

Description

Technical Field

[0001] This invention relates to the field of embedded technology, and in particular to a microservice architecture, construction method and apparatus for embedded system development. Background Technology

[0002] Embedded software is software that runs on embedded hardware. Its main functions are to control the hardware and interact with external devices, such as temperature acquisition, image processing, button processing, and wireless communication.

[0003] Conventional embedded software is primarily monolithic, meaning all code is ultimately compiled into a single application and deployed to run on an embedded device. However, when faced with highly complex business requirements, this approach leads to a significant increase in code size as business complexity grows. This increases software complexity considerably, requiring consideration of many aspects such as managing shared memory resources and multi-threaded protection. This places a heavy burden on developers, lengthens project development cycles, and makes later iterations and maintenance a complex and challenging process. Summary of the Invention

[0004] This invention addresses the shortcomings of existing technologies by providing a microservice architecture, construction method, and apparatus for embedded system development.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] A microservice architecture for embedded system development includes a management service module, a hardware service module, and a server-side microservice architecture.

[0007] The management service module is used for service monitoring and service configuration;

[0008] The hardware service module is used to provide abstract hardware interfaces and support underlying hardware operations;

[0009] The server-side microservice architecture includes a service process creation unit and a message communication unit. The service process creation unit is used to create service processes, and the message communication unit is used for communication between service messages. Specifically, it receives the service process to be created, decomposes the service process into communication service information and service control information, establishes a communication connection and issues control commands through the communication service information, and receives the control commands issued by the communication service information. The control commands are used to control the state of the preset external interface corresponding to the service process.

[0010] As one possible implementation, the server-side microservice architecture also includes a custom functional module, a management service module, and a hardware service module;

[0011] The development functional modules include common logs, read / write configuration files, and serialization operation function libraries;

[0012] The management service module is used to manage the status of the service process, including the start status, stop status, and running status.

[0013] The hardware service module is used to provide the underlying hardware with the corresponding operations to perform. The corresponding operations include one or more of reading, writing and control. The underlying hardware includes one or more of GPIO, serial port, CAN bus, 485 bus and NFC.

[0014] As one possible implementation, the development functional module also includes a data type conversion model, a date calculation model, and a debugging tool function model.

[0015] As one possible implementation, the service process creation unit is configured as follows:

[0016] Each service process is independent of the others. When a new service process is added or an existing service process is removed, the working status of other service processes does not change and they can continue to run.

[0017] A method for building a microservice architecture for embedded system development includes the following steps:

[0018] The system receives a service process to be created, decomposes the service process into communication service information and service control information, establishes a communication connection and issues control commands through the communication service information, and receives the control commands issued by the communication service information.

[0019] The control commands control the state of the preset external interface corresponding to the service process.

[0020] As one possible implementation, if each service process is independent of the others, then:

[0021] When a new service process is added or an existing service process is removed, the working status of other service processes remains unchanged and they can continue to run.

[0022] As one possible implementation method, the following steps are also included:

[0023] In response to a server-side request to add service information, the system obtains the service information to be added and maps the service information to the service program library.

[0024] An embedded device clustering architecture construction apparatus includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method steps described above.

[0025] This invention, by adopting the above technical solutions, has significant technical effects:

[0026] This invention can decompose complex business processes into multiple relatively simple sub-business units, reducing development difficulty while also improving code maintainability and testability. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a schematic diagram of the architecture of the present invention;

[0029] Figure 2 This is a schematic diagram of the architecture of a specific embodiment;

[0030] Figure 3 This is a detailed diagram of the service process creation unit;

[0031] Figure 4 This is a diagram illustrating the configuration of different service processes;

[0032] Figure 5 This is a comparative diagram showing the implementation of this invention in JAVA and C++. Detailed Implementation

[0033] The present invention will be further described in detail below with reference to the embodiments. The following embodiments are explanations of the present invention, but the present invention is not limited to the following embodiments.

[0034] Example 1:

[0035] A microservice architecture for embedded system development includes a management service module, a hardware service module, and a server-side microservice architecture.

[0036] The management service module is used for service monitoring and service configuration;

[0037] The hardware service module is used to provide abstract hardware interfaces and support underlying hardware operations;

[0038] The server-side microservice architecture includes a service process creation unit and a message communication unit. The service process creation unit is used to create service processes, and the message communication unit is used for communication between service messages. Specifically, it receives the service process to be created, decomposes the service process into communication service information and service control information, establishes a communication connection and issues control commands through the communication service information, and receives the control commands issued by the communication service information. The control commands are used to control the state of the preset external interface corresponding to the service process.

[0039] The server-side microservice architecture also includes custom functional modules, management service modules, and hardware service modules;

[0040] The development functional modules include common logs, read / write configuration files and serialization operation function libraries, as well as data type conversion models, date calculation models and debugging tool function models;

[0041] The management service module is used to manage the status of the service process, including the start status, stop status, and running status.

[0042] The hardware service module is used to provide the underlying hardware with the corresponding operations to perform. The corresponding operations include one or more of reading, writing and control. The underlying hardware includes one or more of GPIO, serial port, CAN bus, 485 bus and NFC.

[0043] In existing technologies, embedded software runs on embedded hardware. Its functions generally include hardware control and interaction with external devices, such as temperature acquisition, image processing, button handling, and wireless communication. Conventional embedded software is mainly monolithic, meaning all code is ultimately compiled into a single software and deployed to the embedded device for execution. However, when facing highly complex business requirements, this approach results in a significant increase in code size as business complexity grows, greatly increasing software complexity. Many aspects, such as controlling shared memory resources and multi-threaded protection, need to be considered, placing a heavy burden on developers, lengthening project development cycles, and making later iterations and maintenance a complex and difficult process. The architecture of this invention can not only manage business services within the entire system and provide developers with hardware operation interfaces for the current system, but also facilitate data transfer between services. A service process creation module allows for the rapid creation of a service program. This reduces code complexity and clarifies the logical structure, decomposing complex business processes into multiple relatively simple sub-business units, reducing development difficulty, and improving code maintainability and testability. It allows developers to decompose complex business processes into multiple business service modules, replacing a single monolithic software to handle business processes. This reduces software complexity without changing the overall functionality. Furthermore, within each of the decomposed service modules, technical solutions can be flexibly used according to the business they are responsible for, without affecting each other.

[0044] Reduce code complexity: The server-side microservice architecture will provide some functional interfaces. Developers only need to implement the corresponding new functions according to the framework's interface rules. Each service only needs to focus on one business. For example, if you want to control the opening and closing of an automatic door, you don't need to worry about the function of communicating with the server. Moreover, there is no direct coupling between the code of services. Once the developer's code is embedded in the framework, the subsequent activities will be managed by the framework.

[0045] To improve development efficiency, some code in general software is unrelated to business logic and is often implemented in the same way. Therefore, developers sometimes need to rewrite this kind of code in new projects. However, by using a framework, which encapsulates the common parts, developers can reduce the writing of common code and reduce debugging time by using a mature development framework, allowing them to focus on business logic development.

[0046] At the same time, one person can be responsible for the development of one service. The code between services is not coupled. They can choose their preferred development standards and technical methods without affecting each other, which also improves development efficiency.

[0047] One service is one process. Upgrading, adding, or removing a single service does not affect other services. A service is actually an independent process in the system. Processes communicate with each other through the message module provided by the framework. When a service is upgraded or deleted, causing it to temporarily malfunction, other service processes will not be affected and will not terminate or crash.

[0048] Reduce traffic during terminal device upgrades and lower product data traffic costs; by decomposing business functions and using a framework, the monolithic software is broken down into multiple services. When the system needs to be upgraded, only a few related services need to be upgraded, instead of all service programs, thereby saving traffic, reducing system bandwidth pressure, and saving costs in various aspects.

[0049] Example 2:

[0050] A method for building a microservice architecture for embedded system development includes the following steps:

[0051] S100: Receive the service process to be created, decompose the service process into communication service information and service control information, establish a communication connection and issue control commands through the communication service information, and receive the control commands issued by the communication service information.

[0052] S200: Control the state of the preset external interface corresponding to the service process through the control command.

[0053] More specifically, each service process is independent of the others. When a new service process is added or an existing service process is removed, the working status of other service processes does not change and they can continue to run.

[0054] Step S100 further includes the following steps:

[0055] In response to the server's request to add service information, the service information to be added is obtained;

[0056] Mapping the service information to be added to the service program library is a step that can be referred to in the appendix. Figure 4 As shown.

[0057] The following is a specific embodiment:

[0058] The overall design employs an internal function call mechanism to process server-side commands and invoke the LED control function when issuing control commands to the LEDs, ultimately turning the LEDs on or off. This is achieved through an embedded microservice approach (task decomposition).

[0059] The entire requirement is broken down into two services: communication service information and LED service control information. The communication service information is only responsible for establishing and maintaining the server connection and receiving commands. The LED service control information is only responsible for controlling the LED to turn on and off.

[0060] Process description:

[0061] The server sends a command to control the LED to turn on or off;

[0062] Upon receiving this instruction, the communication service information sends an instruction to the LED service control information.

[0063] LED service control information notification hardware service module sets external interface to high or low level;

[0064] The hardware service module calls the operating system interface to set the external interface to a high or low level.

[0065] The LED lights are turned on or off; therefore, it can be seen that there is no code coupling between the LED service control information, the communication service information does not contain code for turning the LED on or off, and the instructions to control the LED switch are transmitted through inter-process messages; (mono-software consists of function calls, and the communication function calls the LED control function, which creates coupling, increases software complexity, and makes it difficult to maintain).

[0066] Improved development efficiency: Two services can be easily assigned to two people, with no code coupling between them, ensuring no interference during development; at the same time, the framework eliminates a lot of repetitive code (this part requires code examples for explanation); (the code for monolithic software is stored together. If multiple people are developing simultaneously, collaboration issues such as technology, standards, and development schedules must be considered, otherwise problems such as communication function calls to LED control functions may occur.)

[0067] One service, one process. Upgrading, adding, or removing a single service does not affect other services: When adding an air conditioning control service, existing communication and LED service control information do not need to be stopped or restarted and continue to run; when removing LED service control information, existing communication and air conditioning service control information do not need to be stopped or restarted and continue to run. (Monolithic software requires a complete upgrade, including shutdown, updates, and restarts, during which time the system is in an inoperable state.)

[0068] Reduce data traffic during terminal device upgrades and lower product data traffic costs: When adding a new air conditioning service control information, only a separate service upgrade package needs to be downloaded for the device; (mono-software upgrades are done as a whole, including all code, and the program upgrade package is larger, which is especially noticeable in scenarios where the device relies on SIM card communication).

[0069] Developed using C / C++, suitable for embedded systems. Cannot use server-side Java due to high performance requirements and poor portability on Java devices. (Code developed from scratch). See attached file. Figure 5 .

[0070] Furthermore, it should be noted that the shapes and names of the parts and components described in the specific embodiments described in this specification may differ. All equivalent or simple variations made to the structure, features, and principles described in this patent concept are included within the protection scope of this patent. Those skilled in the art to which this invention pertains may make various modifications or additions to the described specific embodiments or use similar methods to substitute them, as long as they do not depart from the structure of this invention or exceed the scope defined in these claims, all of which should fall within the protection scope of this invention.

Claims

1. A microservice architecture for embedded system development, characterized in that, This includes a management service module, a hardware service module, and a server-side microservice architecture; The management service module is used for service monitoring and service configuration; The hardware service module is used to provide abstract hardware interfaces and support underlying hardware operations; The server-side microservice architecture includes a service process creation unit and a message communication unit. The service process creation unit is used to create service processes, and the message communication unit is used for communication between service messages. The service process creation unit is also used to receive a service process to be created, and decompose the service process into communication service information and service control information. The communication service information is used to establish a communication connection and issue control commands, and the service control information receives the control commands issued by the communication service information. The communication service information and the service control information are independent service processes. The control instructions are transmitted between them by the message communication unit through inter-process messages. The communication service information does not contain the hardware control code corresponding to the service control information. The control commands control the state of the preset external interface corresponding to the service process.

2. The microservice architecture for embedded system development according to claim 1, characterized in that, The server-side microservice architecture also includes a development function module, a management service module, and a hardware service module; The development functional modules include common logs, read / write configuration files, and serialization operation function libraries; The management service module is used to manage the status of the service process, including the start status, stop status, and running status. The hardware service module is used to provide the underlying hardware with the corresponding operations to perform. The corresponding operations include one or more of reading, writing and control. The underlying hardware includes one or more of GPIO, serial port, CAN bus, 485 bus and NFC.

3. The microservice architecture for embedded system development according to claim 2, characterized in that, The development functional modules also include a data type conversion model, a date calculation model, and a debugging tool function model.

4. The microservice architecture for embedded system development according to claim 2, characterized in that, The service process creation unit is configured as follows: Each service process is independent of the others. When a new service process is added or an existing service process is removed, the working status of other service processes does not change and they can continue to run.

5. A method for constructing a microservice architecture for embedded system development, applied to the microservice architecture for embedded system development as described in any one of claims 1-4, characterized in that, Includes the following steps: The system receives a service process to be created and decomposes the service process into independent communication service information and service control information. The communication service information is used to establish communication connections and issue control commands, and the service control information is used to receive control commands issued by the communication service information. The communication service information does not contain the hardware control code corresponding to the service control information. The control commands are transmitted between the communication service information and the service control information via inter-process messaging. The control commands control the state of the preset external interface corresponding to the service process.

6. The method for constructing a microservice architecture for embedded system development according to claim 5, characterized in that, Each service process is independent of the others. When a new service process is added or an existing service process is removed, the working status of other service processes does not change and they can continue to run.

7. The method for constructing a microservice architecture for embedded system development according to claim 5, characterized in that, It also includes the following steps: In response to the server's request to add service information, the service information to be added is obtained; The service information to be added is mapped to the service program library.

8. An apparatus for constructing an embedded device clustered operation architecture, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 5 to 7.

Images