An edge device service processing system and method

Abstract

This invention discloses an edge device service processing system and method. The system includes: a gateway, a container registry, a container orchestration server, and worker nodes. The gateway receives service requests from cluster devices and temporarily stores them in a message queue. The container registry stores the microservice code corresponding to the service processing containers. The container orchestration server retrieves the service processing container image from the microservice code and deploys it to a created virtual machine. The worker nodes retrieve service requests from the message queue and process them based on the deployed service processing containers in the virtual machine. This invention, by simulating different edge device cluster service scenarios, enables service application management through software, overcoming hardware limitations and meeting the service processing needs of massive numbers of devices, thereby reducing development difficulty and maintenance costs.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an edge device business processing system and method. Background Technology

[0002] Unlike traditional dispatching services that feature large-capacity equipment, long-term planning, and continuous operation, the dispatching of edge devices such as small hydropower clusters mainly involves accessing the power grid through the distribution network end, and its business model focuses more on short-term adjustments and real-time management.

[0003] However, the existing distribution network system adopts a monolithic application architecture, which tightly couples all hardware devices and software functions into a single unit, making it impossible to meet the business processing needs of a massive number of devices. At the same time, the distribution network system based on the monolithic application architecture requires the configuration of a corresponding number of distribution network systems for multiple business applications and multiple terminal small hydropower cluster monitoring and control devices, which will greatly increase the development difficulty and operation and maintenance costs. Summary of the Invention

[0004] This invention provides an edge device business processing system and method that simulates business scenarios of different edge device clusters, enabling business application management to be implemented through software, freeing it from hardware limitations, meeting the business processing needs of massive devices, thereby reducing development difficulty and operation and maintenance costs.

[0005] According to one aspect of the present invention, an edge device service processing system is provided. The system includes: a gateway, a container registry, a container orchestration server, and worker nodes; wherein,

[0006] The gateway is used to receive service requests sent by cluster devices and temporarily store the service requests in a message queue;

[0007] The container registry is used to store the microservice code corresponding to the business processing container;

[0008] The container orchestration server is used to obtain the business processing container image from the microservice code and send it to the created virtual machine for deployment of the business processing container based on the container image.

[0009] The worker node is used to retrieve the business request from the message queue and perform business processing on the business request based on the business processing container deployed in the virtual machine.

[0010] According to another aspect of the present invention, an edge device service processing method is provided. The method includes:

[0011] The gateway receives service requests sent by cluster devices and temporarily stores the service requests in a message queue.

[0012] The microservice code corresponding to the business processing container is stored in the container registry;

[0013] The business processing container image is obtained from the microservice code through the container orchestration server, and then sent to the created virtual machine for deployment of the business processing container based on the container image.

[0014] The service request is obtained from the message queue by the worker node, and the service request is processed based on the service processing container deployed in the virtual machine.

[0015] The technical solution of this invention involves receiving service requests sent by cluster devices through a gateway and temporarily storing the service requests in a message queue; storing the microservice code corresponding to the service processing container through a container registry; obtaining the service processing container image from the microservice code through a container orchestration server and sending it to an already created virtual machine for deployment of the service processing container based on the container image; and obtaining the service request from the message queue through a worker node and performing service processing on the service request based on the service processing container deployed in the virtual machine. This achieves the goal of simulating business scenarios of different edge device clusters, enabling business application management to be implemented through software, thus overcoming hardware limitations, meeting the business processing needs of massive devices, and reducing development difficulty and operation and maintenance costs.

[0016] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0018] Figure 1 This is a comprehensive diagram of the edge device service processing system provided in Embodiment 1 of the present invention;

[0019] Figure 2 This is a structural diagram of an edge device service processing system provided in Embodiment 1 of the present invention;

[0020] Figure 3 This is a structural diagram of a container orchestration server provided according to Embodiment 1 of the present invention;

[0021] Figure 4 This is a structural diagram of a working node provided according to Embodiment 1 of the present invention;

[0022] Figure 5 This is a schematic diagram of the edge device service processing method according to Embodiment 2 of the present invention.

[0023] Figure 6 This is a schematic diagram of an electronic device that implements Embodiment 3 of the present invention. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] Example 1

[0027] Figure 1 A comprehensive diagram of the edge device service processing system is provided. Figure 2 A structural diagram of an edge device service processing system is provided. This embodiment is applicable to situations where service scenarios of edge devices are being simulated. Figure 1 and 2 As shown, the system may include: a gateway 101, a container registry 102, a container orchestration server 103, and worker nodes 104. Among them,

[0028] The gateway 101 is used to receive service requests sent by cluster devices and temporarily store the service requests in a message queue; the container registry 102 is used to store the microservice code corresponding to the service processing container; the container orchestration server 103 is used to obtain the service processing container image from the microservice code and send it to the created virtual machine for deployment of the service processing container based on the container image; the worker node 104 is used to obtain the service request from the message queue and perform service processing on the service request based on the service processing container deployed in the virtual machine.

[0029] Here, cluster devices can refer to edge cluster devices such as small hydropower clusters. Microservice code can refer to business code deployed in business containers.

[0030] Specifically, the gateway 101 connects to external cluster devices through an external interface, can receive service requests sent by the cluster devices, and temporarily store these service requests in the message queue of the gateway 101.

[0031] It should be noted that the number of service requests in the message queue is determined by the number of gateway 101 ports and the total simulation time. This is achieved by establishing a distribution network service time model, which includes message queue vectors and simulation time. The parameters of this model are definable and it is a component of resource management. The specific modeling is shown below:

[0032]

[0033]

[0034]

[0035]

[0036] In the formula: This is a service request matrix, representing N service requests received over T clock cycles, where T = T e / T o N represents the number of gateway 101 ports. T o T is the clock period. e The total simulation time is expressed in seconds (s). Let N be the number of service requests received in the x-th clock cycle, where x = t / T°. Let M be the message queue vector, where M = N × T is the total number of service requests read during the total simulation time, and b i Let b be the number of the i-th service request. i =(000) B This indicates that no business request was received. i =(001)B This represents the first type of business request, and so on. x and b i The element is the business type.

[0037] The container registry 102 can connect to the development end via the container image registration API, and is responsible for storing the encapsulated microservice code corresponding to the business processing container. During business processing, it provides the system with the required business processing container image. The container orchestration server 103 is used to obtain the business processing container image from the microservice code, and can deploy the business processing container in the created virtual machine according to the business timing information in the configuration file and the container image, and perform lifecycle management of the business processing container. The worker node 104 is used to obtain the business request from the message queue, and perform business processing on the business request based on the business processing container deployed in the virtual machine.

[0038] Business requests sent to cluster devices are implemented by the cluster business model, which is built on the declarative API principle in cloud-native technology. It consists of a configuration file creation algorithm, a set of microservice resource requirements, a set of microservice processing times, a set of configuration files, and a vector for configuring virtual machine resources. The parameters on it can be customized, and it is the second component of resource management.

[0039]

[0040]

[0041]

[0042] In the formula: Formula (5) For the set of microservice resource requirements, Let be the microservice resource configuration requirement vector corresponding to the q-th business type, where each element represents the resource configuration requirement of the data collection, analysis, and control microservices, in MHz. Formula (6) For microservices to handle timed collections, Let be the microservice processing timing vector corresponding to the q-th business type, where each element represents the processing time of the data collection, analysis, and control microservices, measured in seconds. Formula (7) For a collection of configuration files, This is the configuration file corresponding to the q-th business type, whose elements are the business sequence logic and business type of the microservices for data collection, analysis, and control, respectively. represent The first to third digits indicate the time sequence of the microservice. represent The fourth to sixth digits represent the business type corresponding to the microservice.

[0043] The configuration file creation algorithm is used to simulate the interaction process between the development team and the system. The specific algorithm is as follows:

[0044]

[0045] The technical solution of this invention involves receiving service requests sent by cluster devices through gateway 101 and temporarily storing the service requests in a message queue; storing the microservice code corresponding to the service processing container through container registry 102; obtaining the service processing container image from the microservice code through container orchestration server 103 and sending it to the created virtual machine for deployment based on the container image; and obtaining the service request from the message queue through worker node 104 and performing service processing on the service request based on the service processing container deployed in the virtual machine. This achieves the goal of simulating business scenarios of different edge device clusters, enabling business application management to be implemented through software, eliminating hardware limitations, meeting the business processing needs of massive devices, and thus reducing development difficulty and operation and maintenance costs.

[0046] Figure 3 This is a structural diagram of a container orchestration server. For example, as shown... Figure 3 As shown, the container orchestration server 103 further includes: a declarative API 201, a configuration file library 202, an API server 203, a control manager 204, and a scheduler 205; wherein,

[0047] The declarative API 201 is used to filter container configuration files edited in human language; the configuration file library 202 is used to store the filtered container configuration files; the API server 203 is used to obtain the container image from the microservice code; the control manager 204 is used to manage the container lifecycle state of the business processing container according to the container configuration file; and the scheduler 205 is used to deploy the business processing container in the virtual machine based on the container lifecycle state and the container image.

[0048] The container configuration file can refer to the deployment file corresponding to the business processing container to be deployed. The lifecycle state can be used to set the container state of the business processing container, which can include creation state, running state, and termination state.

[0049] Specifically, the declarative API 201 is connected to the development end and is used to filter and allow container configuration files edited in human language to pass through, and send the container configuration files to the configuration file library 202; the configuration file library 202 receives the container configuration files sent by the declarative API 201 and stores the filtered container configuration files; the API server 203 can extract data from the configuration file library 202 and create container metadata, and can also obtain the container image from the microservice code; the control manager 204 is used to manage the container lifecycle state of the business processing container according to the container configuration file; the scheduler 205 is used to deploy the business processing container in the virtual machine based on the container lifecycle state and the container image. After deployment, the scheduler 205 will also lock the containers on the virtual machine according to the configuration information inside the configuration file to ensure that the containers can be isolated from each other. It should be noted that the container orchestration server 103 is the technical embodiment of the declarative API 201, container orchestration and immutable infrastructure in the cloud-native technology architecture.

[0050] Figure 4 This is a structure diagram of the working nodes. Optionally, such as... Figure 4 As shown, the worker node 104 further includes: a worker node component 301, a virtual resource pool component 302, and a management program component 303; wherein, the worker node component 301 is used to obtain the service request from the message queue and send the service request to the virtual resource pool component 302; the management program component 303 is used to create the virtual machine according to the node resources; the virtual resource pool component 302 is used to manage and schedule the node resources of the worker node 104, and perform service processing on the service request according to the service processing container deployed in the virtual machine.

[0051] Specifically, worker node 104 consists of at least a hypervisor component 303, a virtual resource pool component 302, and a worker node component 301. The virtual resource pool component 302 is created by the hypervisor 303 through resource virtualization. Worker node component 301 provides an interface for mounting business requests from outside worker node 104, constructs the microservice-to-microservice business timing logic within worker node 104, and sends the business requests to the virtual resource pool component 302. The virtual resource pool component 302 manages and schedules the node resources of worker node 104 and processes the business requests according to the business processing containers deployed in the virtual machine.

[0052] It should be noted that virtual resource pool 302 is part of worker node 104, and its parameters are definable. It is the third component of resource management, and the modeling elements considered include the resources g that worker node 104 can call. Q Work node 104 Total resources g o The modeling content for API server 203, control manager 204, and scheduler 205 consists of container metadata. (This includes resource configuration vectors for worker nodes 104, container resource configuration vectors, and hardware / software separation algorithms.)

[0053]

[0054]

[0055]

[0056] In the formula: Configure the resource vector for worker node 104, where β represents the number of CPU cores inside the terminal, and its internal element is MHz. The container metadata vector is used to collect microservice-like, analysis-like, and control-like microservices. Its internal elements are 1+m bit binary sequences. It represents the state of a container and is also a manifestation of immutable infrastructure. This indicates that the container is idle. This indicates that the container is busy. Indicates the business number. Configure a vector for container resources, with elements in MHz. A hardware / software separation algorithm is used to calculate the callable resource g of worker node 104. Q The total resources of worker node 104 and the metadata for building the container are used to simulate the hardware resource virtualization process. The specific algorithm is as follows:

[0057]

[0058]

[0059] Worker node component 301 is used to store microservice metadata and container mount timing vectors:

[0060]

[0061]

[0062] In the formula: This is for microservice metadata, capable of storing metadata for M business requests. i Each element is also a binary sequence. Υ 1,6 (d i The meaning of the binary sequence of ) and Consistent. Υ7(d) i ) is the mount bit, Y7(d) is initialized during this process. i ) = 0, after the microservice is mounted to the container, Υ7(d i ) = 1. Υ8(d i ) is the microservice termination bit, initialized with Y8(d i ) = 0, after the microservice processing is completed, Υ8(d) i ) = 1. Mount the timing vector to the container. Before the algorithm runs, all metadata elements need to be initialized to an eight-bit binary sequence with all eight bits set to zero.

[0063] Every change to microservice metadata and container metadata requires setting corresponding performance metrics for observation. Therefore, this invention also includes a microservice queuing initiation matrix. Microservice processing start timing matrix Microservice processing completion timing matrix Container resource configuration vector The specific details of the first three are elaborated in the container orchestration algorithm, while the container resource configuration vector has been initialized in Algorithm 2 (step 6).

[0064] Optionally, the worker node component 301 further includes: a service discovery mechanism and a service mesh mechanism; wherein, the service discovery mechanism is used to create microservice metadata according to the business request; and the service mesh mechanism is used to send the microservice metadata to the business processing container in the virtual machine.

[0065] Specifically, the worker node component 301 is internally configured with a service mesh mechanism and a service discovery mechanism. The service discovery mechanism provides an interface for mounting business requests from outside the worker node 104 and creates microservice metadata based on the business requests. The service discovery mechanism is used to construct the business sequence logic between microservices within the worker node 104 and send the microservice metadata to the business processing container in the virtual machine.

[0066] It should be noted that during business processing, the various elements within the system collaborate in an orderly manner through established cloud-native organizational relationships to achieve multi-time-sequence network configuration business processing. To study the internal business processing and resource configuration processes of the system at the granular level using microservices and containers, this invention employs microservice metadata and container metadata as research media, respectively set in the service discovery component and API server 203. Each change in metadata generates a performance parameter for business processing or resource configuration.

[0067] Optionally, the microservice metadata includes data acquisition microservice metadata, analysis microservice metadata, and control microservice metadata.

[0068] It should be noted that before business processing, the system needs to receive the container image and configuration file from the development end and store them in the container registry 102 and configuration file library 202, respectively. For the configuration file, considering the timing logic of small hydropower cluster business, the microservice needs to be divided into acquisition microservices, analysis microservices, and control microservices according to business functions, with each microservice having its own independent configuration file. The acquisition microservice is responsible for obtaining message information from the edge monitoring and control device and performing data preprocessing, and is located at the beginning of the business timing logic. The analysis microservice integrates specific scheduling algorithms and is located in the middle of the distribution network business timing logic. The control microservice is responsible for converting the results of data analysis into remote control and remote adjustment signals, and is located at the end of the business timing logic. This business timing logic information will be uploaded to the edge device terminal in configuration file format, received by the edge device terminal's declarative API 201, and stored in the configuration file library 202.

[0069] Optionally, the container lifecycle states include creation state, running state, and termination state; wherein, the API server 203 is further configured to extract container data information from the container configuration file and create container metadata based on the container data information;

[0070] The control manager 204 is specifically configured to: determine the container lifecycle state of the business processing container as the creation state when the container metadata is created; determine the container lifecycle state of the business processing container as the running state when the business processing container is deployed; and determine the container lifecycle state of the business processing container as the termination state when the container lifecycle duration is longer than a preset period duration.

[0071] Specifically, once the container metadata is created, the control manager 204 retrieves the container metadata from the API server 203 and sets the container lifecycle state of the business processing container to the creation state. After retrieving the container metadata, the scheduler 205 allocates the container to the corresponding virtual machine based on the descriptive information of the container metadata and locks the virtual machine. The virtual machine locates the required container image from the container metadata and pulls the container image from the container registry 102 to complete the container deployment. Once the business processing container is deployed, the control manager 204 sets the container lifecycle state of the business processing container to the running state. At this time, the virtual machine can expose the external worker node component 301, allowing business requests to run on the virtual machine through service discovery and service mesh. If the container lifecycle duration exceeds the preset period, the control manager 204 sets the container lifecycle state of the business processing container to the terminated state.

[0072] Optionally, the API server 203 is further configured to: delete the created container metadata when the container lifecycle state is detected to be in an terminated state. The scheduler 205 is further configured to: lock the virtual machine to prevent data sharing among the business processing containers when the deployment of the business processing container in the virtual machine is detected to be complete; and unlock the virtual machine to release the business processing container resources when the container lifecycle state is detected to be in an terminated state. The management program 303 component is further configured to: delete the virtual machine when the container lifecycle state is detected to be in an terminated state.

[0073] Specifically, API server 203 deletes the container metadata after detecting the termination of a business processing container. Scheduler 205, upon completion of deployment in the virtual machine, locks the virtual machine to prevent data sharing among the business processing containers, thereby protecting business data. Scheduler 205 unlocks the virtual machine and releases container resources after detecting the termination of a business processing container. Hypervisor 303 deletes the virtual machine after detecting the termination of a business processing container.

[0074] It's important to note that when a business request is uploaded to the system, the service discovery mechanism constructs microservice metadata for each request and stores the container metadata within it, enabling the service discovery mechanism to locate the relevant container. Each time a microservice finishes processing, the microservice metadata replaces the container metadata for the next time sequence with the container metadata for that time sequence. At this point, the service discovery mechanism can locate the business processing container for the next time sequence, and the service mesh mechanism routes the microservice data to that container. This process continues until the microservice metadata can no longer read the container metadata for the next time sequence, indicating that the business processing has ended.

[0075] It is worth noting that, in order to simulate the interaction process of discrete digital information between internal system architectures, this invention utilizes discrete binary sequences to simulate digital signals and employs an encoding-decoding method to simulate the interaction process of digital information. (...) B Represents a binary sequence and defines a bitwise extraction function Υ. i,j (.), used to extract the i-th to j-th bits, for example, Υ 1,3 [(001000) B ]=[(001) B The process by which the system reads a non-binary number and constructs a binary sequence according to predetermined rules using bitwise functions and direct mapping is called encoding. The process by which system components read a binary sequence and extract data with predetermined meaning using bitwise functions and direct mapping is called decoding. All predetermined rules set in this invention serve the technical requirements of cloud-native technologies.

[0076] It is important to emphasize that the container orchestration server 103 relies on a container orchestration algorithm. This algorithm consists of a hardware / software separation algorithm, a service discovery algorithm, a microservice processing algorithm, and a service mesh algorithm. Each mathematical criterion within this algorithm may update microservice metadata or container metadata; therefore, corresponding performance metrics need to be set for monitoring.

[0077] The service discovery algorithm simulates the process by which worker node component 301 locates the target container for a business request. Microservice metadata is created by the service discovery algorithm. However, each container can only host one business request; therefore, microservice metadata enters a waiting queue immediately after creation. The service discovery algorithm is as follows:

[0078]

[0079]

[0080] In Algorithm 3, step 1 is used to traverse the business request numbers, steps 4-5 are used to enter the configuration file into the microservice metadata, and step 9 is used to initialize the microservice metadata corresponding to the empty business request.

[0081] The microservice processing algorithm consists of a container mounting algorithm and a microservice termination algorithm, used to simulate the entire process of containerized microservice processing. During this process, the microservice queuing start matrix is ​​updated. Microservice processing start timing matrix Microservice processing completion timing matrix And used as a performance analysis metric:

[0082]

[0083]

[0084] Algorithm 4 is a container mounting algorithm, the details of which are as follows:

[0085]

[0086] In Algorithm 4, step 1 iterates through the business request numbers. Step 2 is the container mounting criterion, consisting of three criteria: 1. The microservice metadata mounting bit is empty; 2. The microservice metadata is a non-empty business request; 3. The container metadata mounting bit is empty. Steps 3-5 are used to update the microservice metadata mounting bit, record the business request number mounted to the container, and the container metadata mounting bit, respectively.

[0087] Algorithm 5 is a microservice termination algorithm, the details of which are as follows:

[0088]

[0089] Steps 2-3 of Algorithm 5 iterate through the container mounting timer vector; when the timer ends, it indicates the microservice processing has ended. Steps 4-6 set the mounting locations of the container metadata, microservice metadata, and container mounting timer to zero, respectively.

[0090] After the data collection microservice terminates, worker node component 301 routes the data to the analysis container using a service mesh algorithm, and so on. The service mesh algorithm is as follows:

[0091]

[0092]

[0093] Step 1 of Algorithm 6 iterates through the business request numbers. Steps 2-3 are the microservice termination and timing criteria; if a microservice terminates, its timing is not the last timing. Steps 4-6 are used to enter the configuration file for the next timing into the microservice metadata. The service mesh routes business requests to the target container based on the microservice metadata until the container mounting algorithm starts.

[0094] Based on all the above modeling elements, Algorithm 7 demonstrates the container orchestration algorithm proposed in this invention.

[0095]

[0096]

[0097] In the technical solution of this invention, algorithms 2-7 are built on cloud-native architecture and cannot be modified. Furthermore, this invention also allows for the customization of virtual resource pool 302, small hydropower cluster scheduling services, and small hydropower cluster service events to simulate different small hydropower cluster service scenarios and determine the service processing performance of different terminals.

[0098] Example 2

[0099] Figure 5 This is a flowchart illustrating a service processing method for an edge device according to Embodiment 2 of the present invention. Figure 5 As shown, the method includes:

[0100] S401. Receive service requests sent by cluster devices through the gateway and temporarily store the service requests in the message queue.

[0101] S402. Store the microservice code corresponding to the business processing container through the container registry.

[0102] S403. Obtain the business processing container image from the microservice code through the container orchestration server, and send the container image to the created virtual machine for deployment of the business processing container.

[0103] S404. Obtain the business request from the message queue through the worker node, and perform business processing on the business request based on the business processing container deployed in the virtual machine.

[0104] The technical solution of this invention involves receiving service requests sent by cluster devices through a gateway and temporarily storing the service requests in a message queue; storing the microservice code corresponding to the service processing container through a container registry; obtaining the service processing container image from the microservice code through a container orchestration server and sending it to an already created virtual machine for deployment of the service processing container based on the container image; and obtaining the service request from the message queue through a worker node and performing service processing on the service request based on the service processing container deployed in the virtual machine. This achieves the goal of simulating business scenarios of different edge device clusters, enabling business application management to be implemented through software, thus overcoming hardware limitations, meeting the business processing needs of massive devices, and reducing development difficulty and operation and maintenance costs.

[0105] Example 3

[0106] Figure 6 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0107] like Figure 6 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0108] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0109] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as edge device business processing.

[0110] In some embodiments, the method edge device service processing may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the method edge device service processing described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the method edge device service processing by any other suitable means (e.g., by means of firmware).

[0111] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0112] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0113] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0114] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0115] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0116] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0117] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0118] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An edge device service processing system, characterized in that, The system includes: a gateway, a container registry, a container orchestration server, and worker nodes; wherein... The gateway is used to receive service requests sent by cluster devices and temporarily store the service requests in a message queue; The container registry is used to store the microservice code corresponding to the business processing container; The container orchestration server is used to obtain the business processing container image from the microservice code and send it to the created virtual machine for deployment of the business processing container based on the container image. The worker node is used to retrieve the business request from the message queue and perform business processing on the business request based on the business processing container deployed in the virtual machine.

2. The system according to claim 1, characterized in that, The container orchestration server further includes: a declarative API, a configuration file library, an API server, a control manager, and a scheduler; wherein, The declarative API is used to filter container configuration files edited in human language; The configuration file library is used to store the filtered container configuration files; The API server is used to obtain the container image from the microservice code; The control manager is used to manage the container lifecycle state of the business processing container according to the container configuration file. The scheduler is used to deploy the business processing container in the virtual machine based on the container lifecycle state and the container image.

3. The system according to claim 1, characterized in that, The worker node further includes: a worker node component, a virtual resource pool component, and a management program component; wherein... The worker node component is used to retrieve the service request from the message queue and send the service request to the virtual resource pool component; The management program component is used to create the virtual machine based on node resources; The virtual resource pool component is used to manage and schedule the node resources of the worker nodes, and to process the business requests according to the business processing containers deployed in the virtual machine.

4. The system according to claim 3, characterized in that, The worker node component also includes: a service discovery mechanism and a service mesh mechanism; wherein... The service discovery mechanism is used to create microservice metadata based on the business request; The service mesh mechanism is used to send the microservice metadata to the business processing container in the virtual machine.

5. The system according to claim 4, characterized in that, The microservice metadata includes data acquisition-type microservice metadata, analysis-type microservice metadata, and control-type microservice metadata.

6. The system according to claim 2, characterized in that, The container lifecycle states include creation state, running state, and termination state; wherein... The API server is also used to extract container data information from the container configuration file and create container metadata based on the container data information; The control manager is specifically used for: Once the container metadata has been created, the container lifecycle state of the business processing container will be determined as the creation state. Once the business processing container is deployed, the container lifecycle state of the business processing container is determined to be the running state. If the container lifecycle duration is longer than the preset period duration, the container lifecycle status of the business processing container will be determined as the terminated state.

7. The system according to claim 6, characterized in that, The API server is also used for: If the container's lifecycle state is detected to be in an terminated state, delete the metadata of the container that has been created.

8. The system according to claim 2, characterized in that, The scheduler is also used for: If the deployment of the business processing container in the virtual machine is detected to be complete, the virtual machine will be locked to prevent the business processing containers from sharing data. If the container lifecycle state is detected to be in an terminated state, the virtual machine will be unlocked, releasing the business processing container resources.

9. The system according to claim 3, characterized in that, The management program component is also used for: If the container's lifecycle state is detected to be in an terminated state, the virtual machine will be deleted.

10. A method for processing services on an edge device, characterized in that, The method includes: The gateway receives service requests sent by cluster devices and temporarily stores the service requests in a message queue. The microservice code corresponding to the business processing container is stored in the container registry; The business processing container image is obtained from the microservice code through the container orchestration server, and then sent to the created virtual machine for deployment of the business processing container based on the container image. The service request is obtained from the message queue by the worker node, and the service request is processed based on the service processing container deployed in the virtual machine.

Images