Progressive service framework based on Nodejs

Abstract

The invention discloses a Nodejs-based progressive service framework, and relates to the technical field of computers, and the Nodejs-based progressive service framework comprises a double-layer architecture layer which is used for separating extended functions of core functions; the double-layer architecture layer comprises a core package and a framework template, the core package comprises operation architecture codes and general functions, the framework template appoints a system file structure and a function writing mode, the core package pre-integrates Modbus, SNMP and MQTT protocol analysis engines, and the plug-and-play equipment access capability is achieved through the standardized adaptation layer; an API (Application Program Interface) service framework and a communication management and data processing component are arranged in the core packet; the equipment access layer is used for automatically identifying the type of equipment when the equipment is dynamically or statically accessed, and carrying out conversion and access through the protocol adaptation layer; an operation and maintenance management layer; a modular design layer; an extension layer; according to the invention, a common equipment protocol analysis engine is preset in the core packet, and the equipment access process is simplified through the standardized adaptation layer, so that the complexity of development and integration is reduced.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, specifically relating to a progressive service framework based on Node.js. Background Technology

[0002] Progressive service frameworks are software development frameworks that gradually build and expand system functions through modular and phased integration. They provide developers with a flexible, efficient, and scalable development model that can meet the rapid development needs of small projects as well as support the long-term evolution of large and complex applications. Currently, service frameworks designed specifically for IoT and monitoring systems include Node-RED, ThingsBoard, and Grafana. These platforms can provide functions such as device data acquisition, monitoring, display, and analysis, and manage devices and data streams through a graphical interface. Among them, Node-RED is a web-based visual programming tool that allows users to build data streams by dragging and dropping nodes, such as protocol conversion, database storage, and dashboard display. It supports protocols such as Modbus and MQTT and can be connected to platforms such as Alibaba Cloud and Tencent Cloud. ThingsBoard provides a full-chain tool for device management, rule engine, and data visualization, supporting protocols such as MQTT and HTTP. It implements business logic, such as alarms and data routing, through the rule chain. Grafana connects to various data sources, such as InfluxDB and Prometheus, through plugins, providing real-time dashboards and alerting functions, and supporting multi-user permission management; However, due to the wide variety of devices in the monitoring industry and the use of different communication protocols such as Modbus, SNMP, and MQTT, existing service frameworks designed for IoT and monitoring systems lack default support for IoT devices and traditional hardware devices, such as default support for protocols like Modbus, SNMP, and MQTT in traditional hardware devices. This makes it difficult to efficiently support the needs of large-scale deployment and multi-device access, and increases development and maintenance costs. Summary of the Invention

[0003] The purpose of this invention is to provide a progressive service framework based on Node.js, which simplifies the device access process and reduces development and maintenance costs by using the adaptation interface of the core package's preset protocol, thereby solving the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: A progressive service framework based on Node.js includes: a two-tier architecture layer for separating extended functions of core functionality; The two-tier architecture includes a core package containing runtime architecture code and general functions, as well as a framework template that defines the system file structure and function writing methods. The core package pre-integrates Modbus, SNMP, and MQTT protocol parsing engines, and achieves plug-and-play device access capabilities through a standardized adaptation layer. Furthermore, the core package has built-in API service framework, communication management, and data processing components, forming a unified infrastructure operating environment. The framework template is used to define a standardized system file structure and functional development specifications, and to break down data acquisition, alarm and storage functions into independent modular units, allowing users to dynamically enable and customize modules through configuration or code; The device access layer automatically identifies the device type when the device is dynamically or statically connected, and converts and connects it through the protocol adaptation layer; The operations and maintenance management layer is used for real-time monitoring, log management, and fault tracing of the system. The modular design layer adopts a microservice architecture to divide the system functions into multiple independent modules, each with clear functional boundaries and standardized interfaces. The extension layer provides open protocol development interfaces based on the preset industrial protocols, supporting customized access to HTTP, WebSocket, and OPC_UA protocols.

[0005] Preferably, the standardized adaptation layer adopts a one-protocol-one-module encapsulation approach for commonly used Modbus, SNMP, and MQTT protocols, with each independent module having built-in complete protocol parsing logic, communication flow control, and data format conversion capabilities; the standardized adaptation layer defines the methods that all independent modules must implement through abstract interface classes, forcing a unified interface format.

[0006] Preferably, when the access device is connected, the standardized adaptation layer automatically detects and identifies the protocol from multiple dimensions, including port characteristics, data frame characteristics, and handshake signal characteristics. If the protocol still cannot be identified after multi-dimensional detection, the standardized adaptation layer will return a protocol mismatch prompt and manually specify the protocol type through the configuration file to ensure compatibility in extreme scenarios. The standardized adaptation layer realizes on-demand dynamic loading of independent modules through a protocol loader based on the Node.js modular mechanism.

[0007] Preferably, the framework template includes: a functional module division unit, which divides the system functions of data acquisition, alarm processing, and data storage into independent modules, each of which has a complete functional boundary; Units can be enabled and edited as needed, allowing users to dynamically enable or disable independent modules through configuration files or code, or customize independent modules according to the needs of adjusting data acquisition frequency or modifying alarm rules; The inter-module decoupling unit enables communication between independent modules through predefined standardized interfaces, ensuring that modifications to any independent module do not affect the operation of other independent modules.

[0008] Preferably, the device access layer performs the following device identification and access process: A1. Through the protocol recognition engine of the standardized adaptation layer, three-dimensional protocol detection is triggered based on the configured protocol type to determine the protocol type used by the device; A2. Automatically load the corresponding protocol's adapter module through the protocol loader to complete the precise binding between the protocol and the independent module; A3. Trigger the device access process, establish stable communication with the device, and complete the closed-loop operation of access and registration; A4. After the device is successfully connected, the data acquisition process is automatically triggered according to the interval time in the acquisition configuration, and the conversion between raw data and standard data is completed through the standardized adaptation layer. A5. Transmit the converted standard data to the operation and maintenance management team for real-time monitoring and fault tracing.

[0009] Preferably, the operation and maintenance management layer includes: a built-in monitoring module that collects indicators of system load, device status and network traffic in real time, and displays them visually through the management platform; The log management module collects system operation logs in real time and supports multi-dimensional querying, filtering, and analysis by time, device address, and module name; The fault tracking and alarm module detects faults based on preset thresholds and pushes detailed fault information via email, SMS or API when a fault occurs, while triggering an automatic recovery mechanism.

[0010] Preferably, the microservice architecture is based on domain-driven design, which divides the system into independent modules according to business domains. Each independent module follows the single responsibility principle and contains only the logic, data model and interface required by the corresponding business function.

[0011] Preferably, the standardized interface uses OpenAPI to define the interaction interface between independent modules, confirms the request or response data format, calling protocol and error code specifications, and decouples custom plugins from the core system logic with the help of the plugin loading engine. When adding a new device or functional module, the access is completed through configuration file updates or incremental code deployment.

[0012] Preferably, the extension layer allows users to extend new protocol adaptation logic through an abstract protocol adaptation interface, and enables multilingual modules to interact with the system core using language communication components.

[0013] Preferably, it also includes an intelligent fault tolerance layer, which includes a redundant deployment and dynamic coordination unit for closed-loop processing from fault detection to service recovery, and a traffic allocation system unit for intelligent decision-making from load perception to request routing. The redundant deployment and dynamic coordination unit includes a primary and backup node cluster, a shared storage system for real-time data synchronization, and a heartbeat detection module for real-time sending of detection signals and monitoring of the primary node status.

[0014] The progressive service framework based on Node.js proposed in this invention has the following advantages compared with existing technologies: 1. This invention reduces the complexity of development and integration by pre-setting common device protocol parsing engines in the core package and simplifying the device access process through a standardized adaptation layer. Enterprises can quickly connect different types of devices to the system without having to write the protocol adaptation layer from scratch, which significantly shortens the time for device access and system integration and lowers the technical threshold. At the same time, the pre-set support of this protocol makes the system more versatile and scalable, and can be adapted to diverse device and protocol requirements. 2. This invention modularizes system functions and provides a mechanism for enabling and customizing functions on demand through framework templates. Users can enable or edit each independent module according to actual needs without large-scale reconstruction of the entire system, making the system more flexible and scalable, and able to cope with rapidly changing business needs. For the increasing number of new devices or new monitoring needs in the monitoring industry, the system can quickly adapt through modular expansion without the need for a full update, avoiding the high cost of frequent reconstruction in traditional systems. 3. This invention enables real-time monitoring, log management, and fault tracking of the system through the operation and maintenance management layer, avoiding the trouble of relying on third-party tools or custom development in the traditional framework. Enterprises do not need to integrate third-party monitoring tools. The built-in monitoring and log management functions track the system status, equipment operation status, and fault information in real time, reducing operation and maintenance costs. 4. This invention supports dynamic device access and smooth system expansion through the cooperation of the extension layer and the device access layer. When adding new devices, they can be seamlessly connected without restarting the system. This allows enterprises to smoothly expand the system as the number of devices increases and business expands, reducing the impact of device access on the operation of the existing system and improving the stability and reliability of the system. Especially in environments where devices are frequently updated or added, it can reduce the expansion problems faced by traditional monitoring systems. Attached Figure Description

[0015] Figure 1 This is a block diagram of the progressive service framework of the present invention; Figure 2 This is a framework template diagram of the present invention; Figure 3 This is a flowchart illustrating the device identification and access process of the present invention. Figure 4 This is a block diagram of the operation and maintenance management layer of this invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The specific embodiments described herein are merely used to explain the present invention and are not intended to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] This invention provides, for example Figure 1-4 The example shown is a progressive service framework based on Node.js, which includes a two-layer architecture layer, a device access layer, an operation and maintenance management layer, a modular design layer, an extension layer, and an intelligent fault tolerance layer. The two-layer architecture layer is used to separate the extended functions of the core functions. The two-tier architecture includes a core package containing runtime architecture code and general functions, as well as a framework template that defines the system file structure and function writing methods. The core package pre-integrates Modbus, SNMP, and MQTT protocol parsing engines, and achieves plug-and-play device access capabilities through a standardized adaptation layer. Furthermore, the core package has built-in API service framework, communication management, and data processing components, forming a unified infrastructure operating environment. The standardized adaptation layer adopts a one-protocol-one-module encapsulation approach for commonly used Modbus, SNMP, and MQTT protocols, with each independent module having built-in complete protocol parsing logic, communication flow control, and data format conversion capabilities. The standardized adaptation layer defines the methods that all independent modules must implement through abstract interface classes, forcing a unified interface format.

[0018] When a device is connected, the standardized adaptation layer automatically detects and identifies the protocol from multiple dimensions, including port characteristics, data frame characteristics, and handshake signal characteristics. If the protocol still cannot be identified after multi-dimensional detection, the standardized adaptation layer will return a protocol mismatch prompt and manually specify the protocol type through the configuration file to ensure compatibility in extreme scenarios. The standardized adaptation layer implements on-demand dynamic loading of independent modules through a protocol loader based on the Node.js modular mechanism. The core package is based on the principles of minimizing core functions and standardized encapsulation. It encapsulates the protocol adaptation and basic services necessary for the operation of the enterprise-level monitoring system into independent units and decouples them from the upper-layer extended functions. The protocol adaptation layer is designed through abstract interfaces to ensure that when adding new protocols, only the adaptation module needs to be extended without affecting the stability of the core architecture. The framework template is used to define a standardized system file structure and functional development specifications, and to break down data acquisition, alarm and storage functions into independent modular units, allowing users to dynamically enable and customize modules through configuration or code; The framework template includes a functional module division unit, an on-demand activation and editing unit, and a module decoupling unit. The functional module division unit is used to split the system functions of data acquisition, alarm processing, and data storage into independent modules, and each independent module has a complete functional boundary. The on-demand enable and edit unit allows users to dynamically enable or disable independent modules through configuration files or code, or customize independent modules according to the needs of adjusting data acquisition frequency or modifying alarm rules. The inter-module decoupling unit is used to enable communication between independent modules through a predefined standardized interface, so that modifications to any independent module do not affect the operation of other independent modules; The framework template is based on the principle of convention over configuration, defining a unified system file structure and functional development specifications. It decouples extended functions from core functions through modular encapsulation and interface standardization. With the help of a dynamic configuration mechanism, it allows users to flexibly combine modules according to business needs, avoiding the resource waste caused by the full loading of traditional frameworks.

[0019] The device access layer is used to automatically identify the device type when the device is dynamically or statically connected, and to convert and connect it through the protocol adaptation layer; The device access layer performs the following device identification and access process: A1. Through the protocol recognition engine of the standardized adaptation layer, three-dimensional protocol detection is triggered based on the configured protocol type to determine the protocol type used by the device; For example, the protocol identification engine reads port (502) in networkConfig and matches it with the protocol-port mapping table preset by the core packet, such as 502→ModbusTCP, 161→SNMP, 1883→MQTT, and initially determines that the device may be a Modbus protocol device; A2. Automatically load the corresponding protocol's adapter module through the protocol loader to complete the precise binding between the protocol and the independent module; Based on the identification results, such as Modbus TCP, the protocol loader locates the Modbus protocol adapter module (file: modbus-adapter.js) in the / protocol-adapters / directory preset by the core package. It dynamically loads the module using the require() function in Node.js and instantiates the adapter class, such as const modbusAdapter = new ModbusAdapter(). Then, it automatically injects the networkConfig and protocolConfig parameters from device-config.json into the adapter class instance, such as passing register address 0x0001 and data rate 0.01 to modbusAdapter, thus completing the initialization of the adapter module. Users do not need to manually write parameter passing code. The loader verifies whether the adapter module implements the five core interfaces defined by the standardized adapter layer, namely connect(), readData(), writeData(), disconnect(), and getProtocolInfo(), to ensure that the module conforms to the framework interface specification and avoid upper-layer call exceptions. If the verification fails, an error log is recorded and the access is terminated.

[0020] A3. Trigger the device access process, establish stable communication with the device, and complete the closed-loop operation of access and registration; For example, the adapter module calls the connect() method, and initiates a TCP connection request based on the IP (192.168.1.105) and port (502) in networkConfig. If the connection is successful, it returns {isConnected:true}, the adapter layer updates the device status to "online", and submits the device information (deviceId, protocol, IP, etc.) to the framework's "device registry". If the connection times out / fails, it triggers the retry mechanism set in the configuration (2 retries), with a 1-second interval between each retry. If the retry fails, it returns {isConnected:false,error:"connection timeout"}, updates the device status to "offline", and sends a "device offline" alarm through the operation and maintenance management layer. The device registry synchronizes the access status to the monitoring module of the operation and maintenance management layer in real time. Users can view the device's "connected" flag, as well as access details such as connection time and protocol version through the management platform, such as "ModbusTCPV1.1, connection time 80ms".

[0021] A4. After the device is successfully connected, the data acquisition process is automatically triggered according to the interval time in the acquisition configuration, and the conversion between raw data and standard data is completed through the standardized adaptation layer. For example, the adapter module calls the readData() method, and sends a formal data acquisition message to the device based on the register address (e.g., 0x0001) and data length (e.g., 2) in protocolConfig. The device returns a raw data frame, such as 0x01 0x03 0x04 0x09 0xC4 0x17 0x70. The adapter module parses the data according to the Modbus protocol rules and extracts the data segments: 0x09C4 (temperature register value) and 0x1770 (humidity register value). The data ratio is applied as follows: 0x09C4=2500→2500×0.01=25.00℃; 0x1770=6000→6000×0.01=60.00%. The adapter module encapsulates the parsed results into the globally unified StandardDataModel format. The converted data is pushed to the upper-layer modules through a standardized interface, such as the data storage module writing it to the database and the alarm module determining whether to trigger a threshold alarm.

[0022] A5. Transmit the converted standard data to the operation and maintenance management team for real-time monitoring and fault tracing; For example, the monitoring module of the operation and maintenance management layer pulls the device status (online / offline), collection success rate (e.g., "100%, 5 seconds / time, 100 consecutive collections without anomalies") and communication latency (e.g., "average 30ms") of the adaptation layer every second, and displays them visually on the management platform. If a device suddenly goes offline (e.g., network disconnection), the adaptation layer detects the TCP connection disconnection and automatically triggers the retry mechanism (3 retries). After the retry fails, the status is updated to "offline" and an alarm is pushed. If the collected data exceeds the reasonable range, such as temperature = -50℃, exceeding the sensor range of -20~80℃, the adaptation layer marks the data as "abnormal", records the original data and the reason for the abnormality, such as "data exceeds reasonable threshold", and continues to collect the next round of data to avoid interrupting the overall process due to a single abnormal data. If the Modbus adaptation module crashes abnormally, the framework's fault tolerance mechanism automatically restarts the module and re-executes the "load-initialize-connect" process to restore data collection. The restart process does not affect the operation of other devices.

[0023] The device protocol type is identified by the feature parameters of the preset protocol, including the port number and data frame format, and the corresponding adaptation module is called. With the help of the lightweight configuration interface, the device access process is abstracted into standardized steps of configuration, verification and initialization, avoiding hard-coding development and solving the problem that traditional frameworks require restarting when adding new devices. It adapts to the dynamic expansion needs of thousands of devices in scenarios such as smart factories and smart cities.

[0024] The operations and maintenance management layer is used for real-time monitoring, log management, and fault tracing of the system; The operation and maintenance management layer includes a built-in monitoring module, a log management module, and a fault tracing and alarm module. The built-in monitoring module is used to collect indicators of system load, device status, and network traffic in real time and display them visually through the management platform. The built-in monitoring module uses the OpenTelemetry standard to unify the semantics of metrics, defining basic dimensions such as device status (online / offline) and performance metrics (response time, throughput). It combines active agent data retrieval with passive device reporting. Active agent data retrieval is achieved through timed crawling via Prometheus, while passive device reporting is achieved through MQTT message push. This covers more than 99% of monitoring scenarios. Grafana dynamic dashboards render data in real time and support drill-down analysis, such as clicking on device icons to view real-time logs and historical trends, improving the efficiency of operation and maintenance decision-making. The log management module is used to collect system operation logs in real time, and supports multi-dimensional querying, filtering and analysis by time, device address and module name; During log management, Filebeat is used to monitor log files, automatically identify new logs and transmit them to Logstash. Multi-tenant log isolation is supported, such as bucketing logs from different business lines. Pre-trained NLP models are used to parse unstructured logs, such as error stack information, and extract key parameters, such as error codes and the module in which they occurred. The parsing accuracy is over 95%. KibanaLens provides SQL-like query capabilities and supports correlation analysis between log data and monitoring metrics, such as cross-comparing high CPU utilization with error logs for the corresponding time period. The fault tracking and alarm module detects faults based on preset thresholds and pushes detailed fault information via email, SMS or API when a fault occurs, while triggering an automatic recovery mechanism. When the fault tracking and alarm module performs closed-loop fault handling, it combines static thresholds and dynamic baselines. Static thresholds include memory usage >90%, while dynamic baselines are determined based on the 3σ rule of historical data to reduce the false alarm rate to below 5%. Alarms are sent through three channels: WeChat robot, email, and SMS. Critical faults are accompanied by a description of the scope of the fault's impact, such as "Affects 3 business interfaces, it is recommended to handle within 5 minutes." After the fault is handled, a health check is automatically triggered, such as calling the device heartbeat interface and simulating business requests. After verification, the alarm work order is closed, forming a closed-loop processing record.

[0025] The modular design layer adopts a microservice architecture to divide the system functions into multiple independent modules, each with clear functional boundaries and standardized interfaces. The microservice architecture is based on domain-driven design, which divides the system into independent modules according to business domains. Each independent module follows the single responsibility principle and contains only the logic, data model and interface required by the corresponding business function. For example, the order service only handles the processes of order creation and status change, and does not involve payment logic, ensuring that the module functions are highly cohesive.

[0026] The standardized interface uses OpenAPI to define the interaction interface between independent modules, confirms the request or response data format, calling protocol and error code specifications, and decouples custom plugins from the core system logic with the help of the plugin loading engine. When adding a new device or functional module, the integration is completed through configuration file updates or incremental code deployment. For example, the user service exposes the / user / login interface, the request body follows the JWT authentication format, and the response uniformly includes code (status code), message (error message) and data (user token) fields, ensuring that the caller can quickly integrate without knowing the internal implementation.

[0027] When adding a new module, dependencies are declared through configuration files (YAML / JSON), such as adding routing rules for a new service in the Nacos configuration center; blue-green deployment / canary release mode is used to update modules, and traffic mirroring technology is used to verify the compatibility of the new version; for example, when upgrading a user service, 10% of traffic is first routed to the new version, and after monitoring the success rate, latency and other indicators to ensure that they meet the standards, a full switch is gradually implemented to ensure that the upgrade process does not affect existing business. The modular design layer ensures high cohesion internally through single responsibility design. For example, the log module is only responsible for log collection, formatting, and storage. Externally, coupling is reduced through interface abstraction. For example, the log module only exposes the log(data) interface, and the caller does not need to know whether the log storage medium is Elasticsearch or Kafka. Dependencies follow the unidirectional principle to avoid circular dependencies, such as the unidirectional call chain of product service → order service → payment service. Data is shared through Redis caching to reduce direct database dependencies. The extension layer provides open protocol development interfaces based on preset industrial protocols, supporting customized access to HTTP, WebSocket, and OPC_UA protocols. The extension layer allows users to extend new protocol adaptation logic through abstract protocol adaptation interfaces, and enables multi-language modules to interact with the system core through language communication components.

[0028] The intelligent fault-tolerant layer includes a redundant deployment and dynamic coordination unit for closed-loop processing from fault detection to service recovery, and a traffic allocation system unit for intelligent decision-making from load perception to request routing. The redundant deployment and dynamic coordination unit includes a primary and backup node cluster, a shared storage system for real-time data synchronization, and a heartbeat detection module for real-time sending of detection signals and monitoring of the primary node status. Primary and backup node cluster: Deploy at least two servers with identical configurations. The primary node carries real-time services, while the backup node synchronizes data and stands by. It supports multi-machine mutual backup or primary and backup mode. Shared storage systems use SAN / NAS or distributed storage to achieve real-time data synchronization, ensuring strong data consistency between primary and backup nodes, supporting block-level difference synchronization and full verification, and avoiding data loss during failover. The heartbeat detection module sends detection signals in real time through an independent network link to monitor the status of the master node, supports millisecond-level fault detection, and avoids misjudgment caused by network fluctuations; In the closed-loop processing of fault detection and service recovery, the redundant deployment and dynamic collaboration unit sends a detection signal every 500ms via a heartbeat line. The primary node responds with a heartbeat packet containing information such as CPU / memory usage and service process status. If no heartbeat response is received for three consecutive times (the number of times is configurable), the primary node is deemed to have failed, triggering the failover process. At the same time, maintenance personnel are notified through multiple channels such as SMS or email. The standby node automatically obtains a virtual IP address, such as the VRRP protocol, mounts shared storage, and starts the primary node's business processes, such as web services and database instances. The entire switchover process is controlled within 20 seconds. After the switchover is completed, the standby node acts as the new primary node to provide services. After the original primary node recovers, it repairs data differences through incremental synchronization. After passing the health check, it manually / automatically switches back to the initial state. Through seamless primary-standby node switching, the single fault interruption time is compressed to less than 30 seconds, and the annual downtime is less than 5 minutes, meeting the zero-interruption requirements of critical businesses such as finance and healthcare. Based on the real-time synchronization mechanism of shared storage, such as MySQL Binlog real-time replication and Redis master-slave synchronization, transaction integrity is ensured during the switchover, avoiding distributed transaction inconsistency issues.

[0029] The traffic allocation system unit collects resource data from each node through an agent, cleans and denoises it using Flink streaming computation, and generates a real-time load matrix containing node performance scores. Then, it dynamically adjusts the load matrix using an adaptive algorithm, supporting trend prediction based on historical data. The load balancer distributes requests according to weights, such as using a consistent hashing algorithm to evenly distribute requests to virtual nodes, reducing traffic migration overhead when nodes change. When a node response time exceeds 500ms, a circuit breaker mechanism is triggered, such as Hystrix, which rejects 80% of requests within 10 seconds. If a node continues to fail, it is automatically removed from the service registry (such as Eureka), and a scaling process is triggered to add new nodes. Through real-time metric collection, dynamic load balancing, and error compensation, refined traffic management is achieved.

[0030] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A Nodejs-based progressive service framework, characterized in that: include: A two-tier architecture layer is used to separate extended functions of the core functionality; The two-tier architecture includes a core package containing runtime architecture code and general functions, as well as a framework template that defines the system file structure and function writing methods. The core package pre-integrates Modbus, SNMP, and MQTT protocol parsing engines, and achieves plug-and-play device access capabilities through a standardized adaptation layer. Furthermore, the core package has built-in API service framework, communication management, and data processing components, forming a unified infrastructure operating environment. The framework template is used to define a standardized system file structure and functional development specifications, and to break down data acquisition, alarm and storage functions into independent modular units, allowing users to dynamically enable and customize modules through configuration or code; The device access layer automatically identifies the device type when the device is dynamically or statically connected, and converts and connects it through the protocol adaptation layer; The operations and maintenance management layer is used for real-time monitoring, log management, and fault tracing of the system. The modular design layer adopts a microservice architecture to divide the system functions into multiple independent modules, each with clear functional boundaries and standardized interfaces. The extension layer provides open protocol development interfaces based on the preset industrial protocols, supporting customized access to HTTP, WebSocket, and OPC_UA protocols. 2.The Nodejs-based progressive service framework according to claim 1, characterized in that: The standardized adaptation layer adopts a one-protocol-one-module encapsulation approach for commonly used Modbus, SNMP, and MQTT protocols, with each independent module having built-in complete protocol parsing logic, communication flow control, and data format conversion capabilities. The standardized adaptation layer defines the methods that all independent modules must implement through abstract interface classes, forcing a unified interface format. 3.The Nodejs-based progressive service framework according to claim 2, characterized in that: When a device is connected, the standardized adaptation layer automatically detects and identifies the protocol from multiple dimensions, including port characteristics, data frame characteristics, and handshake signal characteristics. If the protocol still cannot be identified after multi-dimensional detection, the standardized adaptation layer will return a protocol mismatch prompt and manually specify the protocol type through the configuration file to ensure compatibility in extreme scenarios. The standardized adaptation layer implements on-demand dynamic loading of independent modules through a protocol loader based on the Node.js modular mechanism.

4. The Nodejs-based progressive service framework according to claim 3, characterized in that: The framework template includes: a functional module division unit, which divides the system functions of data acquisition, alarm processing and data storage into independent modules, each of which has a complete functional boundary; Units can be enabled and edited as needed, allowing users to dynamically enable or disable independent modules through configuration files or code, or customize independent modules according to the needs of adjusting data acquisition frequency or modifying alarm rules; The inter-module decoupling unit enables communication between independent modules through predefined standardized interfaces, ensuring that modifications to any independent module do not affect the operation of other independent modules.

5. The Nodejs-based progressive service framework of claim 4, characterized in that: The device access layer performs the following device identification and access process: A1. Through the protocol recognition engine of the standardized adaptation layer, three-dimensional protocol detection is triggered based on the configured protocol type to determine the protocol type used by the device; A2. Automatically load the corresponding protocol's adapter module through the protocol loader to complete the precise binding between the protocol and the independent module; A3, trigger device access process, establish stable communication with the device, and complete the closed-loop operation of access and registration; A4, after the device access is successful, the data acquisition process is automatically triggered according to the interval time in the acquisition configuration, and the conversion of raw data and standard data is completed through the standardized adaptation layer; A5, the converted standard data is transmitted to the operation and maintenance management layer for real-time monitoring and fault tracking.

6. The Nodejs-based progressive service framework of claim 5, characterized in that: The operation and maintenance management layer includes: a built-in monitoring module that collects system load, device status and network traffic indicators in real time, and visualizes them through a management platform; A log management module that collects system operation logs in real time, supports multi-dimensional query, filtering and analysis by time, device address and module name; A fault tracking and alarm module that detects faults based on preset thresholds and pushes detailed fault information through email, SMS or API when a fault occurs, while triggering an automatic recovery mechanism.

7. The Nodejs-based progressive service framework of claim 6, wherein: The microservice architecture is based on domain-driven design, which divides the system into independent modules according to business domains. Each independent module follows the single responsibility principle and only contains the logic, data model and interface required for the corresponding business function.

8. The Nodejs-based progressive service framework of claim 7, wherein: The standardized interface uses OpenAPI to define the interaction interface between independent modules, confirms the request or response data format, calling protocol and error code specification, and decouples custom plugins from the system core logic through a plugin loading engine. When new devices or functional modules are added, access is completed through configuration file updates or incremental code deployment. 9.The Nodejs-based progressive service framework of claim 8, characterized in that: The extension layer allows users to extend new protocol adaptation logic through an abstract protocol adaptation interface, and interacts with the system core through a language communication component.

10. The Nodejs-based progressive service framework according to any one of claims 1-9, characterized in that: It also includes an intelligent fault tolerance layer, which includes a redundant deployment and dynamic coordination unit for closed-loop processing from fault detection to service recovery, and a traffic distribution system unit for intelligent decision-making from load sensing to request routing. The redundant deployment and dynamic coordination unit includes a master-slave node cluster, a shared storage system for real-time data synchronization, and a heartbeat detection module for sending detection signals and monitoring the status of the master node in real time.

Images