Service deployment method, device, edge server and computer program product

Abstract

The embodiment of the invention relates to a service deployment method and device, an edge server and a computer program product. The method includes receiving a user input to deploy a service in a roadside system, wherein the roadside system includes a plurality of clusters located at different roadside locations and an edge server for managing the plurality of clusters. The method also includes converting the user input into a manifest file, wherein the manifest file indicates a roadside service to be deployed and deployment information related to the roadside service. In addition, the method further comprises the step of deploying the roadside service by utilizing an orchestration server in the edge server based on the deployment information in the inventory file. Therefore, according to the embodiment of the invention, automatic service deployment can be realized in the roadside system, the defects of manual deployment are avoided, and the deployment efficiency and quality of the roadside service are improved, so that the overall operation efficiency of the roadside service is helped to be improved.

Description

Technical Field

[0001] Embodiments of this disclosure relate to the field of computers, and more specifically, to methods, apparatus, edge servers, and computer program products for service deployment. Background Technology

[0002] Roadside edge computing utilizes edge devices to process and analyze data in real time at intersections, communicating with vehicles through vehicle-to-everything (V2X) technology to provide efficient, low-latency services. Roadside edge computing reduces bandwidth consumption and improves the real-time performance and reliability of services. By installing edge computing devices along roadsides, this technology can process large amounts of data from vehicles, pedestrians, and infrastructure in real time, resulting in faster response times and higher efficiency.

[0003] Roadside edge computing has wide applications in intelligent transportation, autonomous driving, vehicle-to-everything (V2X) systems, and smart cities. It optimizes traffic signal control and flow management by processing and analyzing data in real time, improving traffic safety and efficiency. In autonomous driving, edge computing provides rapid response to ensure driving safety. Simultaneously, in smart city construction, it improves urban operational efficiency and optimizes public services by monitoring environmental data. Summary of the Invention

[0004] Embodiments of this disclosure provide a method, apparatus, edge server, computer program product, and medium for service deployment.

[0005] According to a first aspect of this disclosure, a method for deploying a service is provided. The method includes receiving user input regarding the deployment of a service in a roadside system, wherein the roadside system includes multiple clusters located at different roadside locations and an edge server for managing the multiple clusters, each of the multiple clusters including one or more nodes for performing the roadside service. The method further includes converting the user input into a manifest file, wherein the manifest file indicates the roadside service to be deployed and deployment information associated with the roadside service. Furthermore, the method includes deploying the roadside service using an orchestration server in the edge server based on the deployment information in the manifest file.

[0006] According to a second aspect of this disclosure, an apparatus for service deployment is provided. The apparatus includes a user input receiving module configured to receive user input for deploying a service in a roadside system, wherein the roadside system includes multiple clusters located at different roadside locations and edge servers for managing the multiple clusters, each of the multiple clusters including one or more nodes for performing the roadside service. The apparatus also includes a manifest file conversion module configured to convert the user input into a manifest file, wherein the manifest file indicates the roadside service to be deployed and deployment information associated with the roadside service. The apparatus further includes a service deployment execution module configured to deploy the roadside service using an orchestration server in the edge server based on the deployment information in the manifest file.

[0007] According to a third aspect of this disclosure, an edge server is provided. The electronic device includes at least one processor; and a memory coupled to the at least one processor and having instructions stored thereon, which, when executed by the at least one processor, cause the edge server to perform the steps of the method of the first aspect of this disclosure.

[0008] According to a fourth aspect of this disclosure, a computer program product is provided. The computer program product is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions that, when executed, cause a computer to perform the steps of the method of the first aspect of this disclosure.

[0009] According to a fifth aspect of this disclosure, a machine-readable storage medium is provided. The machine-readable storage medium stores machine-executable instructions, wherein the machine-executable instructions are executed by a processor to implement the steps of the method of the first aspect of this disclosure.

[0010] The summary section is intended to present the chosen concepts in a simplified form, which will be further described in the detailed description below. The summary section is not intended to identify key or principal features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

[0011] The above and other objects, features and advantages of this disclosure will become more apparent from the accompanying drawings, in which the same reference numerals generally represent the same parts.

[0012] Figure 1 A schematic diagram of an example environment in which the apparatus and / or methods according to embodiments of the present disclosure may be implemented is shown;

[0013] Figure 2A flowchart illustrating a method for service deployment according to an embodiment of the present disclosure is shown;

[0014] Figure 3 A schematic diagram of the software architecture of a roadside system according to an embodiment of the present disclosure is shown;

[0015] Figure 4 A schematic diagram of the hardware structure of a roadside system according to an embodiment of the present disclosure is shown;

[0016] Figure 5 A schematic diagram illustrating an apparatus for service deployment according to an embodiment of the present disclosure is shown; and

[0017] Figure 6 A schematic block diagram of an example device suitable for implementing embodiments of the present disclosure is shown.

[0018] In the various figures, the same or corresponding labels indicate the same or corresponding parts. Detailed Implementation

[0019] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0020] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects unless explicitly stated. Other explicit and implicit definitions may also be included below.

[0021] As mentioned earlier, roadside edge computing plays an important role in many fields. However, when deploying services for roadside edge computing in roadside systems, engineers need to manually deploy them on each edge device node at each intersection, resulting in a huge workload, low efficiency, and a high risk of errors.

[0022] To address this, embodiments of this disclosure propose a scheme for deploying services in a roadside system, enabling automatic service deployment and avoiding the shortcomings of manual deployment. First, user input for service deployment in the roadside system is received. Then, the user input is converted into a manifest file indicating the roadside services to be deployed and related deployment information. Finally, an orchestration server is used to deploy the roadside services. Thus, embodiments of this disclosure enable automatic service deployment in the roadside system, avoiding the shortcomings of manual deployment, improving the deployment efficiency and quality of roadside services, and thereby helping to improve the overall operational efficiency of roadside services.

[0023] The following is for reference Figures 1 to 6 The present disclosure is provided to illustrate the basic principles and several exemplary implementations. It should be understood that these exemplary embodiments are given only to enable those skilled in the art to better understand and implement the embodiments of the present disclosure, and are not intended to limit the scope of the disclosure in any way.

[0024] Figure 1 An example environment 100 is shown, in which the devices and / or methods of embodiments of this disclosure may be implemented. Embodiments of this disclosure relate to deploying roadside services in roadside systems, also known as roadside edge computing, a computing technology deployed alongside roads to provide real-time, efficient data processing and service support. By bringing computing resources closer to the data source, roadside edge computing enables low-latency, high-response data processing, reduces bandwidth consumption, and improves system reliability and efficiency. This technology has wide applications in intelligent transportation systems (ITS), advanced driver-assistance systems (ADAS / AD), intelligent parking systems, and smart cities. It can monitor and manage traffic flow, environmental data, and public safety in real time, improving road safety and urban management. The distributed architecture of roadside edge computing provides flexible computing power and scalability, enabling dynamic adjustment of resource allocation according to actual needs, making it an important technology for the future development of smart cities and intelligent transportation.

[0025] refer to Figure 1 Example environment 100 may include edge server 110, which may be a machine deployed at an intersection or within a traffic signal control box, and can be used to manage the service deployment of the roadside system. In some embodiments, edge server 110 may also be a node on multiple clusters of roadside services. Figure 1 As shown, edge server 110 can accept user input 120, which can indicate relevant information about service deployment. In embodiments of this disclosure, users only need to provide user input 120 to deploy the target service on the desired cluster and nodes, eliminating the need to manually deploy services one by one on each node or machine at each intersection.

[0026] Edge server 110 may include coordinator 130, cluster agent 140, and orchestration server 150. In some embodiments, coordinator 130 may be used to receive user input 120 and convert the user input 120 into a manifest file 135. For example, manifest file 135 indicates the roadside services to be deployed and deployment information related to the roadside services. For example, roadside services may include, but are not limited to, intelligent traffic signal control, autonomous vehicle assistance, and traffic image acquisition services. Users can specify which roadside services to deploy in a user-friendly format in user input 130, specify the roadside location where the service should be deployed, and the relevant parameters of the service (e.g., image resolution, machine configuration, etc.). Coordinator 130 can convert user input 120 into manifest file 135, which is in a program-readable form to facilitate service deployment.

[0027] Cluster agent 140 can apply manifest file 135 to orchestration server 150. In some embodiments, cluster agent 140 can apply manifest file 135 to orchestration server 150 by calling application programming interface (API). Orchestration server 150 can deploy roadside services based on the deployment information in manifest file 135. For example, orchestration server 150 can configure the services to be deployed according to the deployment information and then deploy them to one or more nodes specified in the deployment information.

[0028] Figure 1 Clusters 160 and 170 are shown, each located at a different roadside location (e.g., at different intersections), and each cluster has multiple nodes deployed. From a hardware perspective, each cluster can correspond to a chassis installed at each intersection, with multiple edge machines corresponding to nodes, used to execute specific roadside services, and each machine can deploy one or more roadside services. It can be seen that because the machines and services are deployed at the intersections, there are significant advantages during execution, including low latency and high response speed, as data can be processed locally in real time, reducing transmission time and bandwidth consumption, while improving system reliability and stability. Local data processing also enhances privacy and security. It should be understood that only two clusters are shown here as examples, and the roadside system in the embodiments of this disclosure may include more or fewer clusters, and each cluster may include more or fewer nodes; this disclosure does not impose any limitations.

[0029] Therefore, the embodiments of this disclosure achieve automatic deployment of roadside services in the roadside system, avoiding the shortcomings of manual deployment, improving the deployment efficiency and quality of roadside services, and thus helping to improve the overall operational efficiency of roadside services. It should be understood that the architecture and functionality in example environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this disclosure. Embodiments of this disclosure can also be applied to other environments with different structures and / or functionalities.

[0030] The following will combine Figures 2 to 6 The process according to embodiments of this disclosure is described in detail. For ease of understanding, the specific data mentioned in the following description are exemplary and not intended to limit the scope of this disclosure. It is understood that the embodiments described below may also include additional actions not shown and / or actions shown may be omitted, and the scope of this disclosure is not limited in this respect.

[0031] Figure 2 A flowchart of a service deployment method 200 according to an embodiment of the present disclosure is shown. At block 202, user input for deploying a service in a roadside system can be received, wherein the roadside system includes multiple clusters located at different roadside locations and an edge server for managing the multiple clusters, each of the multiple clusters including one or more nodes for performing the roadside service. (In conjunction with...) Figure 1 The edge server 110 can receive user input 120 for deploying services in a roadside system, wherein the roadside system includes multiple clusters (e.g., clusters 160 and 170) located at different roadside locations, and the edge server 110 for managing the multiple clusters, each of the multiple clusters including one or more nodes for performing roadside services.

[0032] At box 204, user input can be converted into a manifest file, which indicates the roadside services to be deployed and deployment information related to those services. Figure 1 The coordinator 130 in the edge server 110 can convert user input 120 into a manifest file 135, which indicates the roadside services to be deployed and deployment information related to the roadside services.

[0033] At box 206, roadside services are deployed using an orchestration server based on deployment information in the manifest file. Combined with... Figure 1 The description states that edge server 110 can deploy roadside services using orchestration server 150 based on deployment information in the manifest file. Therefore, the method 200 according to embodiments of this disclosure enables automated service deployment in the roadside system, avoiding the shortcomings of manual deployment, improving the deployment efficiency and quality of roadside services, and thus helping to improve the overall operational efficiency of roadside services.

[0034] Figure 3 A schematic diagram of the software architecture 300 of a roadside system according to an embodiment of the present disclosure is shown. Figure 3 As shown, the software architecture 300 may include an edge server 302, which includes a monitor 304, a coordinator 306, a cluster agent 308, and an orchestration server 310. As previously described, the edge server 302 is used to manage the cluster and its nodes in the roadside service. In some embodiments, the edge server 302 may utilize the coordinator 306 to receive user input 312. User input, also known as user intent, is provided by the user (e.g., an engineer or operator) when deploying the roadside service, and the service deployment can be automated. In some embodiments, the user input 312 may be a structured data file describing the cluster (i.e., a grouping of nodes), the nodes within the cluster (also called members or hosts), the services running within the cluster, and the relevant attributes and parameters of each service instance. In some embodiments, the user may define the user input 312 based on a reference template for the structured data file, which can further reduce the user's workload.

[0035] In some embodiments, the coordinator 306 in edge server 302 can read the mirror address and deployment information of the roadside service to be deployed in the mirror repository on the edge server from user input 312. The deployment information may include the deployment cluster, deployment nodes, and service parameters associated with the roadside service. In some embodiments, a manifest file can be generated based on the mirror address, deployment cluster, deployment nodes, and service parameters. The manifest file can be applied to orchestration server 310. For example, orchestration server 310 can read parameter information from the generated manifest file from cluster agent 308. The mirror repository can be installed on edge server 302 (not shown) or on redundant server 320, such as mirror repository 322.

[0036] An image repository is a component used to store, manage, and distribute container images. Developers can push their created image services to the image repository, and operations personnel and automation systems can pull the required virtualized image services from the repository for deployment. An image address is an identifier pointing to a specific image service, typically including the image repository address, namespace, image name, and image tag. An image service is a lightweight, standalone executable package containing everything needed to run software, including code, runtime, libraries, environment variables, and configuration files. By packaging all necessary roadside services into an image service and storing it within the image, the required roadside services can be automatically pulled from the image repository during roadside service deployment, avoiding the need to manually obtain services from other sources.

[0037] In some embodiments, a mirror service corresponding to a roadside service can be obtained from a mirror address in a mirror repository. For example, if a user (engineer or operator) needs to deploy a traffic image acquisition service, they can obtain a mirror service for that service from the corresponding mirror address in the mirror repository. In some embodiments, the mirror service can be configured based on service parameters. For example, service parameters are included in the manifest file, and the obtained mirror service can be configured based on these parameters, such as the resolution of the images in the traffic image acquisition service and the acquisition time interval.

[0038] In some embodiments, the image acquisition service can be deployed as a roadside service to the deployment nodes via an orchestration agent on the deployment nodes in the deployment cluster. For example, a user may instruct in user input 312 to deploy the traffic image acquisition service to a chassis (i.e., a deployment cluster) at one or more intersections, and to deploy one or more machines (i.e., deployment nodes) in the chassis at those intersections. For example, orchestration server 310 can deploy the traffic image acquisition service on the node where orchestration agent 332 resides via orchestration agent 332, wherein orchestration server 310 can provide the control plane for the service on the management node.

[0039] In some embodiments, the image service can be deployed as a roadside service to multiple backup deployment nodes in the deployment cluster. For example, cluster 330 may include backup nodes, and when node 332 fails, the service of node 332 can be run on the backup nodes. This achieves redundancy of the roadside service and improves the security and reliability of the roadside system during operation.

[0040] In some embodiments, the roadside system further includes a plurality of backup edge servers, wherein each backup edge server includes a mirror library and a backup orchestration server synchronized with the orchestration server. (Reference) Figure 3 The diagram illustrates a backup edge server 320, also known as a redundant edge server. The backup edge server 320 may include a mirror repository 322 and an orchestration server 324, and the orchestration server 324 is synchronized with the orchestration server 310. When edge server 302 fails, the backup edge server 320 can replace it, thereby improving the security and reliability of the roadside system's services. In some embodiments, one edge server and two redundant edge servers may be configured simultaneously to further enhance the security and reliability of the roadside system.

[0041] In some embodiments, the hardware status corresponding to a node among multiple nodes and the service status of roadside services performed on multiple nodes can be obtained through probes set in the nodes, and the hardware status and service status can be displayed in the user interface. Figure 3As shown, probes 334 are deployed to each node (i.e., machine) of cluster 330 and the roadside service to collect critical data on system operation. For example, probes 334 can collect information including hardware status (such as CPU utilization, memory usage, temperature, etc.) and service status (such as service running status, log information, etc.). Probes 334 can transmit the collected data to the monitor 304 of the edge server 302. The user interface can graphically display the operating status of the roadside system, including various hardware and software performance indicators. In some embodiments, the user interface is web-based and bound to the monitor 304, and the monitor 304 issues alerts to the user when hardware and / or service status indicate a fault. For example, when CPU utilization exceeds a predetermined threshold, an alert can be issued to the user via a web-based user interface, SMS, or telephone.

[0042] In some embodiments, a monitor in an edge server stores hardware and service status in a database. The time-series data, including the hardware and service status, can then be queried from the database and displayed in a user interface. For example, monitor 304 can store data received from a probe in a database, and when a user needs to query the data, it can display time-series data that reflects not only the current service status but also its historical status.

[0043] In some embodiments, when the monitor indicates that the roadside service has failed, the roadside service can be restarted on the deployment node, started on one of a plurality of backup deployment nodes, or the roadside service can be migrated from the deployment node to another node in the deployment cluster. For example, refer to Figure 3 When monitor 304 detects a failure in the roadside service on node 342 in cluster 340 via probe 344, it can restart the roadside service on node 342, start the roadside service on a standby node, or migrate the roadside service from node 342 to another node in cluster 340. Furthermore, the roadside service can also be migrated between clusters, for example, from cluster 330 to cluster 340, that is, from the roadside location corresponding to cluster 330 to the roadside location corresponding to cluster 340.

[0044] In some embodiments, users can write intent files based on provided templates as user input, and then input the intent files into the coordinator. The coordinator can generate manifest files that meet the requirements of the intent files based on the user's intents. The cluster agent applies these manifests to the cluster, and all services run on multiple nodes in the cluster. In addition, users can also access the system status through a web-based graphical user interface (GUI).

[0045] Figure 4A schematic diagram of the hardware structure 400 of a roadside system according to an embodiment of the present disclosure is shown. Figure 4 As shown, the hardware structure 400 may include router 402, intersection chassis 404, router 412, intersection chassis 414, router 422, and intersection chassis 424. For example, router 402 and intersection chassis 404 are located at a roadside location for the roadside service, and intersection chassis 404 may include multiple nodes (i.e., host machines). Routers are used to connect all hosts in intersection chassis at different intersections, ensuring communication between intersections. Furthermore, each intersection chassis also includes a switch (not shown) for connecting all hosts in intersection chassis within the same intersection, ensuring interconnectivity of devices within the intersection. The hosts in the intersection chassis execute the deployed roadside services and are the computing units of the roadside system.

[0046] In some embodiments, environmental information is acquired by sensors installed at the roadside location of each cluster, and this environmental information is provided to multiple nodes in the cluster for roadside services. For example, a camera is installed at the roadside location of the intersection chassis 404 to capture image information of the surrounding environment, and the image information is sent to the host in the intersection chassis 404 to perform relevant roadside services.

[0047] Figure 5 A schematic diagram of an apparatus 500 for service deployment according to an embodiment of the present disclosure is shown. The apparatus 500 includes a user input receiving module 502 configured to receive user input for deploying a service in a roadside system, wherein the roadside system includes multiple clusters located at different roadside locations and edge servers for managing the multiple clusters, each of the multiple clusters including one or more nodes for performing the roadside service. The apparatus 500 also includes a manifest file conversion module 504 configured to convert the user input into a manifest file, wherein the manifest file indicates the roadside service to be deployed and deployment information associated with the roadside service. The apparatus 500 further includes a service deployment execution module 506 configured to deploy the roadside service using an orchestration server in the edge servers based on the deployment information in the manifest file.

[0048] In some embodiments, the manifest file conversion module includes: a user input reading module configured to read from the user input the mirror address of the roadside service to be deployed in the mirror library of the edge server and the deployment information, wherein the deployment information includes at least the deployment cluster, deployment node and service parameters associated with the roadside service; and a manifest file generation module configured to generate the manifest file based on the mirror address, the deployment cluster, the deployment node and the service parameters.

[0049] In some embodiments, the service deployment execution module includes: an image service acquisition module configured to acquire an image service corresponding to the roadside service from the image address in the image library; an image service configuration module configured to configure the image service based on the service parameters; and a roadside service deployment module configured to deploy the image service as the roadside service to the deployment node through an orchestration agent on the deployment node in the deployment cluster.

[0050] In some embodiments, the apparatus 500 further includes a backup service deployment module configured to deploy the image service as the roadside service to multiple backup deployment nodes in the deployment cluster.

[0051] In some embodiments, the roadside system further includes a plurality of backup edge servers, each of the plurality of backup edge servers including a mirror library and a backup orchestration server synchronized with the orchestration server.

[0052] In some embodiments, the apparatus 500 further includes a server replacement module configured to replace the edge server with a backup edge server from among the plurality of backup edge servers in response to a failure of the edge server.

[0053] In some embodiments, the device 500 further includes: a status information acquisition module configured to acquire, via probes disposed in the nodes, the hardware status corresponding to the nodes among the plurality of nodes and the service status of roadside services performed on the plurality of nodes; and a status information display module configured to display the hardware status and the service status in a user interface.

[0054] In some embodiments, the device 500 further includes: a status information storage module configured to store the hardware status and the service status in a database via a monitor in the edge server; and a time series display module configured to display the time series data in a user interface by querying time series data protecting the hardware status and the service status from the database.

[0055] In some embodiments, the user interface is web-based and linked to a monitor in the edge server that alerts the user when the hardware status and / or service status indicate a failure.

[0056] In some embodiments, in response to the monitor indicating that the roadside service has failed, the apparatus 500 further includes one of the following: a roadside service restart module configured to restart the roadside service on the deployment node; a backup service startup module configured to start the roadside service on one of the plurality of backup deployment nodes; or, a roadside service migration module configured to migrate the roadside service from the deployment node to another node in the deployment cluster.

[0057] In some embodiments, the apparatus 500 further includes: an environmental information acquisition module configured to acquire environmental information by means of sensors installed at the roadside location where each cluster is located; and an environmental information providing module configured to provide the environmental information to a plurality of nodes of the cluster for use in the roadside service.

[0058] In some embodiments, the plurality of nodes on each cluster are connected to each other via a switch, and the plurality of clusters are connected to each other via a router.

[0059] Figure 6 A schematic block diagram of an example device 600 suitable for implementing embodiments of the present disclosure is illustrated. As shown, device 600 includes a processor 601 that can perform various appropriate actions and processes based on computer program instructions loaded into random access memory (RAM) 603 according to computer program instructions stored in read-only memory (ROM) 602. Various programs and data required for operation of device 600 may also be stored in RAM 603. The processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0060] The various methods and processes described above can be executed by processor 601. For example, in some embodiments, the various methods and processes described above can be implemented as computer software programs tangibly contained in a machine-readable medium. In some embodiments, part or all of the computer program can be loaded and / or installed on device 600 via ROM 602. When the computer program is loaded into RAM 603 and executed by processor 601, one or more actions of the methods and processes described above can be performed.

[0061] This disclosure can be a method, apparatus, system, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of this disclosure.

[0062] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium can be, for example—but not limited to—an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), and any suitable combination thereof. The computer-readable storage medium as used herein is not to be construed as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0063] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0064] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0065] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0066] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0067] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0068] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0069] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method (200) of service deployment, comprising: receiving (202) a user input of deploying a service in a roadside system, wherein the roadside system comprises a plurality of clusters located at different roadside locations and an edge server for managing the plurality of clusters, each of the plurality of clusters comprising one or more nodes for executing a roadside service; converting (204) the user input into a manifest file, wherein the manifest file indicates a roadside service to be deployed and deployment information related to the roadside service; and deploying (206) the roadside service with an orchestration server in the edge server based on the deployment information in the manifest file. 2.The method (200) of claim 1, wherein converting the user input into the manifest file comprises: reading, with a coordinator in the edge server, from the user input an image address of a mirror image of the roadside service to be deployed in a mirror image repository in the edge server and the deployment information, wherein the deployment information comprises at least a deployment cluster, a deployment node and service parameters associated with the roadside service; and generating the manifest file based on the image address, the deployment cluster, the deployment node and the service parameters. 3.The method (200) of claim 2, wherein deploying the roadside service with the orchestration server comprises: acquiring, from the image address in the mirror image repository, a mirror image service corresponding to the roadside service; configuring the mirror image service based on the service parameters; and deploying the mirror image service as the roadside service to the deployment node through an orchestration agent on the deployment node in the deployment cluster. 4.The method (200) of claim 3, further comprising: deploying the mirror image service as the roadside service to a plurality of backup deployment nodes in the deployment cluster. 5.The method (200) of claim 1, wherein the roadside system further comprises a plurality of backup edge servers, each of the plurality of backup edge servers comprising a mirror image repository and a backup orchestration server synchronized with the orchestration server. 6.The method (200) of claim 5, further comprising: replacing the edge server with a backup edge server in the plurality of backup edge servers in response to a failure of the edge server. 7.The method (200) of claim 1, further comprising: acquiring, with a probe disposed in a node, a hardware status corresponding to the node in the plurality of nodes and a service status of a roadside service executed on the plurality of nodes; and displaying the hardware status and the service status in a user interface. 8.The method (200) of claim 7, further comprising: storing, with a monitor in the edge server, the hardware status and the service status into a database; and displaying, in the user interface, time series data comprising the hardware status and the service status by querying the time series data from the database. ​ ​ ​ 9. The method (200) of claim 8, wherein the user interface is web-based and tied to the monitor, the monitor alerting a user when the hardware status and / or the service status indicates a failure.

10. The method (200) of claim 9, further comprising, in response to the monitor indicating that the roadside service has failed, performing one of: restarting the roadside service on the deployment node; starting the roadside service on one of the plurality of backup deployment nodes; or migrating the roadside service from the deployment node to another node in the deployment cluster.

11. The method (200) of claim 1, further comprising: obtaining environmental information via sensors installed at the roadside locations where each cluster is located; and providing the environmental information to the plurality of nodes of the cluster for use by the roadside service.

12. The method (200) of claim 11, wherein the plurality of nodes on each cluster are connected via a switch and the plurality of clusters are connected via a router.

13. An apparatus for service deployment, comprising: a user input receiving module configured to receive a user input to deploy a service in a roadside system, wherein the roadside system includes a plurality of clusters located at different roadside locations and an edge server for managing the plurality of clusters, each of the plurality of clusters including one or more nodes for executing a roadside service; a manifest file converting module configured to convert the user input into a manifest file, wherein the manifest file indicates a roadside service to be deployed and deployment information related to the roadside service; and a service deployment executing module configured to deploy the roadside service with an orchestration server in the edge server based on the deployment information in the manifest file.

14. An edge server, comprising: at least one processor; and a memory coupled to the at least one processor and having stored thereon instructions that, when executed by the at least one processor, cause the edge server to perform the method of any one of claims 1-12.

15. A computer program product tangibly stored on a non-transitory computer- readable medium and comprising machine-executable instructions for performing the method of any one of claims 1-12.

Images