A lightweight BS architecture offshore monitoring method and related device

Abstract

The application provides a light-weight BS architecture offshore monitoring method and related equipment, and belongs to the technical field of offshore monitoring. The application comprises the following steps: receiving offshore radar and AIS data to obtain offshore fusion target data set; calculating a dynamic threshold based on the number of targets in the offshore fusion target data set and offshore scene load data, triggering container elastic scaling according to the dynamic threshold to obtain resource allocation data adapted to offshore target fluctuations; detecting the running state of microservices to obtain microservice health state data; and scheduling standby node resources according to the resource allocation data and the microservice health state data, and restoring the offshore fusion target data set through cache replication and data snapshot to obtain the restored offshore fusion target data set. The application can accurately identify and track fishing boat and merchant ship targets, and automatically and elastically schedule computing resources according to target quantity fluctuations.

Description

Technical Field

[0001] This application relates to the field of nearshore monitoring technology, and in particular to a lightweight BS architecture nearshore monitoring method and related equipment. Background Technology

[0002] In related technologies, traditional systems require multiple servers to work together, resulting in large hardware investments, complex deployment processes, and long cycles, which cannot meet the needs of small areas with limited resources and rapid deployment.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0004] The main objective of this application is to propose a lightweight BS architecture nearshore monitoring method and related equipment, which can accurately identify and track fishing vessels and merchant ships, and automatically and elastically allocate computing resources according to fluctuations in the number of targets.

[0005] To achieve the above objectives, one aspect of this application proposes a lightweight BS architecture nearshore monitoring method, the method comprising the following steps: Receive near-shore radar and AIS data, and fuse near-shore fishing vessel and merchant ship targets through a multi-dimensional matching algorithm to obtain a near-shore fused target dataset; Based on the number of targets in the nearshore fusion target dataset and the nearshore scenario load data, a dynamic threshold is calculated, and the container is elastically scaled according to the dynamic threshold to obtain resource allocation data that adapts to nearshore target fluctuations. The health check probe periodically detects the running status of microservices, identifies abnormal microservices based on the detection results, and obtains microservice health status data. Based on the resource allocation data and the microservice health status data, a tiered restart is performed on the abnormal microservice, and backup node resources are scheduled to restore the near-shore fusion target dataset through cache replication and data snapshot, thus obtaining the restored near-shore fusion target dataset.

[0006] In some embodiments, the receiving of near-shore radar and AIS data, and the fusion of near-shore fishing vessel and merchant ship targets using a multi-dimensional matching algorithm to obtain a near-shore fused target dataset, includes: Through the target processing service, the radar equipment interface and the AIS equipment interface are connected respectively to receive the nearshore radar data stream and the nearshore AIS data stream, and obtain the raw nearshore radar target set and the raw nearshore AIS target set. The original nearshore radar target set and the original nearshore AIS target set are time-aligned and spatial coordinate transformed to obtain the preprocessed radar target set and the preprocessed AIS target set; Traverse the preprocessed radar target set and the preprocessed AIS target set, and sequentially perform the first dimension MMSI matching, the second dimension latitude and longitude and speed and heading combination matching, and the third dimension ship length and target type combination matching. Merge the successfully matched radar targets and AIS targets to generate a fused target record, and obtain the multi-dimensional matched fused target subset, the unmatched radar target set, and the unmatched AIS target set. For each fusion target record in the multi-dimensional matching fusion target subset, a preset confidence weight is assigned according to the matching method, and a fusion confidence score is calculated. Records whose fusion confidence scores reach a preset confidence threshold are retained to obtain a high-scoring fusion target subset. The confidence weights include MMSI matching weight, latitude and longitude matching weight, speed and heading matching weight, and ship length type matching weight. The high-resolution fusion target subset is merged with the unmatched radar target set and the unmatched AIS target set, and the unmatched targets are assigned a preset temporary identifier to obtain the near-shore fusion target dataset.

[0007] In some embodiments, the step of traversing the preprocessed radar target set and the preprocessed AIS target set, sequentially performing first-dimensional MMSI matching, second-dimensional latitude and longitude and speed / heading combination matching, and third-dimensional ship length and target type combination matching, merges the successfully matched radar targets and AIS targets to generate a fused target record, resulting in a multi-dimensional matched fused target subset, an unmatched radar target set, and an unmatched AIS target set, including: If the MMSI of a radar target and an AIS target are the same, they are determined to be the same target. The targets are merged to generate a fused target record and the matching method is marked as MMSI matching, thus obtaining a subset of MMSI-matched fused targets. If the MMSI is inconsistent, the latitude and longitude difference, speed difference, and heading difference between the radar target and the AIS target are calculated. When the latitude and longitude difference, speed difference, and heading difference are all within their respective preset threshold ranges, they are determined to be the same target. The targets are merged to generate a fused target record and the matching method is marked as latitude and longitude speed and heading matching to obtain a subset of fused targets based on latitude and longitude speed and heading matching. If latitude, longitude, speed and heading matching fails, the length and target type of radar target and AIS target are compared. When the length difference is within the preset threshold range and the target type is the same, they are determined to be the same target. The target records are merged and generated, and the matching method is marked as length type matching to obtain the length type matching fused target subset. The MMSI matching and fusion target subset, the latitude and longitude speed and heading matching and fusion target subset, and the ship length type matching and fusion target subset are merged to obtain a multi-dimensional matching and fusion target subset, and at the same time, an unmatched radar target set and an unmatched AIS target set are obtained.

[0008] In some embodiments, the step of calculating a dynamic threshold based on the number of targets in the nearshore fusion target dataset and the nearshore scenario load data, and triggering container elastic scaling according to the dynamic threshold to obtain resource allocation data adapted to nearshore target fluctuations, includes: The nearshore monitoring load dataset is obtained by collecting hardware resource utilization, the number of targets in the nearshore fusion target dataset, the number of nearshore alarms, and the number of nearshore playback tasks by the monitoring component. The preset scene weights are obtained based on the current monitoring area type to obtain the nearshore scene weight value; the monitoring area types include fishing port areas, fishing ban areas, ordinary port areas and lake and reservoir areas; The dynamic threshold is calculated based on the number of targets in the nearshore monitoring load dataset, the preset baseline number of targets, the current percentage of remaining server resources, and the nearshore scenario weight value. A first duration and a second duration are set; the first duration and the second duration are used to periodically recalculate the dynamic threshold; The target number in the nearshore monitoring load dataset is compared with the dynamic threshold. When the target number exceeds the first multiple of the dynamic threshold for the first duration, an expansion instruction is generated. When the target number is lower than the second multiple of the dynamic threshold for the second duration, a reduction instruction is generated. The expansion instruction and the reduction instruction are used as nearshore monitoring elastic scaling instructions. According to the nearshore monitoring elastic scaling command, the number of containers is increased or decreased through the container orchestration platform. When expanding, nodes with sufficient remaining resources are selected first, and session data is migrated before shrinking to obtain the adjusted container allocation data. Collect resource utilization rate and response delay after expansion or reduction, and use the resource utilization rate and response delay as input to adjust the dynamic threshold calculation parameters for subsequent cycles to obtain resource allocation data adapted to nearshore target fluctuations.

[0009] In some embodiments, the step of periodically detecting the microservice running status through health check probes, identifying abnormal microservices based on the detection results, and obtaining microservice health status data includes: Configure a liveness probe and a readiness probe for each microservice; the liveness probe is used to detect the liveness status of the service process; the readiness probe is used to detect whether the service has the ability to process requests; the liveness probe and the readiness probe are used as health check probes. The survival probe sends detection requests to each microservice according to a first preset period to detect the service port connectivity and core process response status, records the microservices that do not respond or respond abnormally, and obtains a list of abnormal survival microservices. The ready probe sends detection requests to each microservice according to the second preset period to detect service response delay and backend database connection status, and records microservices whose response delay exceeds a preset threshold or whose database connection fails, thus obtaining a list of abnormal ready microservices. The list of live abnormal microservices and the list of ready abnormal microservices are merged and deduplicated, and each abnormal microservice is marked with its abnormality type and occurrence time to obtain the original microservice health status data. The original microservice health status data is statistically analyzed for each microservice, and the number of anomalies and anomaly patterns of each microservice within a preset time window are analyzed to identify microservices that need to be restarted and microservices that need to be migrated, thus obtaining microservice health status data.

[0010] In some embodiments, the step of performing a tiered restart of abnormal microservices based on the resource allocation data and the microservice health status data, scheduling standby node resources, and restoring the near-shore fusion target dataset through cache replication and data snapshots to obtain the restored near-shore fusion target dataset includes: Based on the microservice health status data, the number of times each abnormal microservice is abnormal within a preset unit of time is counted to obtain microservice abnormal frequency data. The microservice anomaly frequency data is compared with a preset restart threshold. If the number of anomalies does not exceed the restart threshold, a local restart command is generated. If the number of anomalies exceeds the restart threshold, a node migration command is generated. According to the local restart instruction, the current container unit of the abnormal microservice is restarted, and the restart process is monitored to see if it is completed within the preset timeout period, so as to obtain the microservice container unit after local restart. According to the node migration instruction, the backup node resource information is obtained from the resource allocation data, the abnormal microservice is scheduled to the backup node for redeployment and the original node resources are released to obtain the migrated microservice container unit. The most recent timed snapshot and the incremental operation logs after the snapshot are obtained from the historical data warehouse to obtain the data snapshot and incremental logs. Synchronize data from the master node of the cache service using a master-slave replication mechanism to obtain synchronized cache data; After the microservice container unit is restarted locally or after migration, the data snapshot and the incremental log are loaded to restore historical data, and the synchronized cached data is connected to restore dynamic data to obtain the restored near-shore fusion target dataset.

[0011] To achieve the above objectives, another aspect of this application proposes a lightweight BS architecture nearshore monitoring system for implementing the method described above. The system includes: The first module is used to receive near-shore radar and AIS data, and to fuse near-shore fishing vessel and merchant ship targets through a multi-dimensional matching algorithm to obtain a near-shore fused target dataset. The second module is used to calculate a dynamic threshold based on the number of targets in the nearshore fusion target dataset and the nearshore scenario load data, and to trigger the elastic scaling of the container according to the dynamic threshold to obtain resource allocation data that adapts to the fluctuations of nearshore targets. The third module is used to periodically detect the running status of microservices through health check probes, identify abnormal microservices based on the detection results, and obtain microservice health status data. The fourth module is used to perform a step-by-step restart of abnormal microservices based on the resource allocation data and the microservice health status data, schedule standby node resources, and restore the near-shore fusion target dataset through cache replication and data snapshots to obtain the restored near-shore fusion target dataset.

[0012] In some embodiments, the lightweight BS architecture nearshore monitoring system further includes a presentation layer, an application layer, a capability layer, and an access layer; The access layer is used to receive radar data, AIS data, and optoelectronic data, and output raw multi-source nearshore data; the access layer includes a standardized interface module; the standardized interface module connects to radar equipment, AIS equipment, and optoelectronic equipment. The capability layer includes an edge preprocessing unit, a caching unit, and a historical data storage unit; The edge preprocessing unit is connected to the access layer, performs noise reduction and filtering preprocessing on the raw nearshore multi-source data, and outputs the preprocessed nearshore data. The cache unit is connected to the edge preprocessing unit, stores target data, and outputs near-shore target dataset; The historical data storage unit is connected to the edge preprocessing unit, stores historical target data, and outputs a nearshore historical target dataset. The application layer includes target processing service, trajectory processing service and alarm service deployed under a microservice framework; The target processing service connects to the cache unit, processes the nearshore target dataset, and outputs the processed target data; The track processing service connects to the historical data storage unit, performs track analysis on the nearshore historical target dataset, and outputs target track data. The alarm service connects the target processing service and the track processing service, generates alarm information based on the processing results, and outputs nearshore monitoring alarm data. The presentation layer includes a plugin-free browser server architecture front-end; the plugin-free browser server architecture front-end connects to the application layer, receives the processed target data, the target track data and the nearshore monitoring alarm data through a communication protocol, updates the nautical chart and target information, and outputs a nearshore target visualization monitoring interface.

[0013] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described above.

[0015] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the aforementioned method.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a lightweight BS architecture nearshore monitoring method, system, electronic device, storage medium, and program product. This application includes: receiving nearshore radar and AIS data to obtain a nearshore fusion target dataset; calculating a dynamic threshold based on the number of targets in the nearshore fusion target dataset and nearshore scene load data; triggering container elastic scaling according to the dynamic threshold to obtain resource allocation data adapted to nearshore target fluctuations; detecting the microservice running status to obtain microservice health status data; and scheduling standby node resources and restoring the nearshore fusion target dataset through cache replication and data snapshots based on the resource allocation data and microservice health status data to obtain the restored nearshore fusion target dataset. This application can accurately identify and track fishing vessels and merchant ships, and automatically and elastically schedule computing resources according to fluctuations in the number of targets. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the system architecture design provided in the embodiments of this application; Figure 2 This is a flowchart of a lightweight BS architecture nearshore monitoring method provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0021] 1) K3S: A lightweight Kubernetes distribution designed for resource-constrained environments, consuming less memory and CPU resources, and supporting single-node deployment.

[0022] 2) TARS: Tencent's open-source microservice framework, featuring high performance, high availability, cross-language capabilities, and support for service governance, circuit breaking, rate limiting, and other functions.

[0023] 3) B / S architecture (BS architecture): Browser / server architecture, users can access the system through a browser without installing a client.

[0024] 4) PB serialization: short for Protocol Buffers, an efficient binary serialization protocol used for data transmission and storage, reducing data size.

[0025] 5) Information technology application innovation: short for the information technology application innovation industry.

[0026] 6) Redis: An open-source in-memory database used to cache real-time data and provide high-performance read and write capabilities.

[0027] 7) StarRocks: A high-performance columnar storage data warehouse suitable for storing and querying massive amounts of data.

[0028] 8) Edge preprocessing: Denoising and filtering are performed on the raw data at edge nodes (such as photoelectric boxes) to reduce the amount of data transmitted.

[0029] 9) Photoelectric linkage: Guide photoelectric equipment to automatically track targets using radar or AIS target information.

[0030] 10) Containerized deployment: Package applications and their dependencies into containers to achieve environment consistency and rapid deployment.

[0031] 11) Lightweight: refers to the technical characteristics of a streamlined system architecture, low resource consumption, and flexible deployment. This application's embodiment uses K3S instead of the traditional Kubernetes, reducing memory consumption, supporting single-node deployment, and is suitable for resource-constrained nearshore monitoring environments.

[0032] 12) AIS: Automatic Identification System, a communication system used for automatically exchanging information such as ship identity, position, course, and speed between ships and between ships and shore stations. In this application embodiment, AIS data is one of the main data sources for near-shore target fusion.

[0033] 13) MMSI: Maritime Mobile Service Identity, is a unique identifier for a ship’s radio communication system, equivalent to a ship’s “ID number”, and serves as the first dimension matching basis for multi-source data fusion in this application embodiment.

[0034] 14) Prometheus: An open-source system monitoring and alerting toolkit. In this application embodiment, it is used to collect load data such as hardware resource utilization, real-time target count, alarm count, and playback task count at the second level, providing perception layer data support for dynamic resource scheduling.

[0035] 15) Grafana: An open-source data visualization and analysis platform. In this embodiment, it is integrated with Prometheus to display real-time monitoring data such as server resources, service status, and target quantity, enabling operations and maintenance personnel to visually view the system's operating status.

[0036] 16) Pod: The smallest unit of deployment and management in Kubernetes (including K3S). Each Pod contains one or more containers. In the embodiments of this application, microservices run in the form of Pods, and the dynamic scheduling step achieves elastic scaling by increasing or decreasing the number of Pods.

[0037] 17) Namespace: A resource isolation mechanism in Kubernetes used to divide the same physical cluster into multiple virtual clusters. In this embodiment, namespaces are used to isolate resource quotas for different microservices, enabling dynamic resource adjustment.

[0038] 18) Liveness: A liveness probe, a health check mechanism in Kubernetes, used to detect whether a container is running. In this embodiment, the service port connectivity and core process status are checked every 5 seconds; if they fail, the container is restarted.

[0039] 19) Readiness: A readiness probe, a health check mechanism in Kubernetes, used to detect whether a container is ready to process requests. In this embodiment, the service response latency (≤500ms) and database connection availability are checked every 3 seconds; if they fail, requests are stopped from being forwarded to the service.

[0040] 20) TargetPro: Target processing service, one of the core microservices based on the TARS framework in this application embodiment, is responsible for receiving, preprocessing and fusing multi-source target data such as radar and AIS, and outputting fused target dataset.

[0041] 21) AlarmPro: Alarm service, one of the core microservices based on the TARS framework in this application embodiment, is responsible for intelligent early warning rule execution and alarm information generation. It triggers an alarm when a target enters a preset warning area or exhibits abnormal behavior.

[0042] 22) React: A JavaScript library for building user interfaces. In this embodiment, it is used to build a plugin-free B / S front-end for the presentation layer, supporting mainstream and domestically developed browsers, and enabling real-time interactive functions such as nautical chart refresh and target display.

[0043] 23) GB: GB / T 28181, National Standard "Technical Requirements for Information Transmission, Exchange and Control of Public Security Video Surveillance Network System". In this application embodiment, the access layer adapts to the GB protocol for standardized access and control of optoelectronic devices.

[0044] 24) UOS: Uniontech OS, one of the operating systems. In the embodiments of this application, the adaptation steps for the domestic IT innovation environment support the Uniontech UOS operating system.

[0045] 25) Elasticsearch: A distributed search and analysis engine used in this application embodiment to store alarm logs and business operation logs, supporting fast log retrieval and analysis, and providing data support for operation and maintenance monitoring.

[0046] 26) TrackPro: Track processing service, one of the core microservices based on the TARS framework in this application embodiment, is responsible for the calculation, prediction and storage of target trajectory, and supports historical track playback and analysis.

[0047] 27) ClickHouse: An open-source columnar database management system designed for online analytical processing. Like StarRocks, it is a columnar storage engine, with StarRocks being optimized based on the core concepts of ClickHouse.

[0048] 28) Memcached: An open-source, high-performance distributed memory object caching system.

[0049] 29) Zabbix: An open-source enterprise-grade monitoring solution.

[0050] This application considers traditional nearshore monitoring cluster systems, which employ a multi-server cluster deployment model, rely on foreign hardware and software environments, support the access and fusion of multi-source data such as radar, AIS, and photoelectric sensors, and provide functions such as situational awareness, early warning, and playback. While such systems ensure large-scale target processing capabilities through a heavy-duty architecture, they are not optimized for small-area scenarios and suffer from problems such as complex deployment, high resource consumption, and insufficient adaptation to domestic IT innovation. Deficiencies in related technologies: 1. High deployment cost: Traditional systems require multiple servers to work together, resulting in large hardware investments, complex deployment processes, and a cycle of 3-5 days, which cannot meet the needs of small areas with limited resources and rapid deployment. 2. High resource consumption: The service modules are redundant. When deployed on a single server, the CPU and memory usage exceeds 80%, which can easily lead to target processing delays and lag in nautical chart operations. 3. Poor compatibility with domestic IT innovation: It relies on foreign CPUs, operating systems and browsers, making it difficult to run stably in domestic software and hardware environments; 4. Low efficiency of multi-source data fusion: The fusion logic is complex, the latency exceeds 60 seconds, the data transmission is not adapted to the low bandwidth environment at sea, and data loss is likely to occur; 5. High maintenance difficulty: Lack of automated deployment and intelligent monitoring tools, requiring professional personnel for maintenance, high maintenance costs in small-area scenarios, and system availability of less than 95%.

[0051] In view of this, this application provides a lightweight BS architecture nearshore monitoring method and related equipment. This solution can quickly build a containerized microservice cluster through one-click deployment, and accurately identify and track fishing vessels and merchant ships by real-time fusion of multi-source data such as radar and AIS. It can also automatically and elastically schedule computing resources according to the fluctuation of the number of targets, and has the ability to self-heal service failures to ensure high availability of the system.

[0052] This application belongs to the field of nearshore monitoring technology, providing an all-weather real-time intelligent monitoring solution for small-area management scenarios such as lakes, reservoirs, ports, and county-level jurisdictions. With increasingly frequent maritime traffic and operations, the demand for small-area nearshore safety management and target monitoring continues to grow. However, traditional monitoring systems are difficult to adapt to scenarios with limited resources and rapid deployment, necessitating lightweight and highly adaptable technical solutions. Related technological developments show trends towards cloud-native, containerized, and domestically developed technologies. The maturity of technologies such as K3S lightweight container orchestration and TARS microservice architecture provides a technical foundation for lightweight deployment.

[0053] First, we introduce the system architecture used in the lightweight BS architecture nearshore monitoring method of this application. For example... Figure 1 As shown, it adopts a four-layer lightweight architecture of "presentation layer - application layer - capability layer - access layer" and realizes single-node containerized deployment based on the K3S lightweight container orchestration platform, supporting ARM / x86 dual architecture and domestic IT innovation environment.

[0054] The access layer provides standardized interfaces, supporting access from multiple sources such as radar, AIS, and photoelectric devices, and is compatible with GB protocol and SDK to complete the unified collection of raw data. The capability layer adopts an "edge preprocessing + central lightweight fusion" model, where edge nodes denoise and filter the raw data, and the center caches real-time target data through Redis and stores historical trajectory data through StarRocks, achieving two-level data processing. The application layer is based on the TARS microservice framework and is divided into fine-grained microservices such as TargetPro (target processing), TrackPro (track processing), and AlarmPro (alarm service), with efficient communication between services through PB serialization. The presentation layer uses React to build a plugin-free B / S frontend, compatible with mainstream and domestically developed browsers, and uses HTTP / WebSocket to realize interactions such as chart refresh and real-time target tracking, with minimal chart refresh latency.

[0055] This layered architecture leverages the lightweight nature of K3S and the service governance capabilities of TARS to achieve low resource consumption, simple deployment, compatibility with domestic IT innovation, and efficient operation and maintenance, thus meeting the core requirements of nearshore monitoring scenarios for real-time performance and reliability.

[0056] based on Figure 1 The lightweight BS architecture nearshore monitoring method provided in this application embodiment, such as... Figure 2 As shown, the method may include, but is not limited to, steps S101 to S104.

[0057] Step S101: Receive nearshore radar and AIS data through the nearshore monitoring containerized microservice cluster, and fuse nearshore fishing vessel and merchant ship targets through a multi-dimensional matching algorithm to obtain a nearshore fused target dataset. Step S102: Calculate the dynamic threshold based on the number of targets in the nearshore fusion target dataset and the nearshore scenario load data, and trigger the elastic scaling of the container according to the dynamic threshold to obtain resource allocation data adapted to nearshore target fluctuations. Step S103: Periodically check the running status of microservices using health check probes, identify abnormal microservices based on the detection results, and obtain microservice health status data. Step S104: Based on resource allocation data and microservice health status data, perform a step-by-step restart on the abnormal microservice, schedule backup node resources, and restore the near-shore fusion target dataset through cache replication and data snapshot to obtain the restored near-shore fusion target dataset.

[0058] In steps S101 to S104 of the embodiments of this application, a multi-dimensional matching algorithm is used to perform MMSI matching, position and motion matching, and attribute matching on radar and AIS data to achieve high-precision fusion identification of near-shore fishing vessels and merchant ships. A dynamic threshold calculation model generates elastic scaling instructions based on the real-time number of targets and scene weights, automatically adjusting the number of container instances to adapt to fluctuations in the number of near-shore targets. A health check probe periodically detects the running status of microservices to identify abnormal services in real time. A tiered restart and data recovery mechanism performs local restarts or node migrations based on the number of anomalies, and utilizes cache replication and data snapshots to restore the fused target dataset. Ultimately, this achieves lightweight and rapid deployment of the near-shore monitoring system, accurate fusion of multi-source data, elastic adaptation of computing resources, and self-healing recovery from service failures, achieving the technical effects of reducing deployment costs, improving target identification accuracy, optimizing resource utilization, and enhancing system availability.

[0059] As an optional implementation, this application embodiment automatically detects the server architecture and installs a lightweight container orchestration platform through a one-click deployment script to quickly build a nearshore monitoring microservice cluster, including; Set up a one-click deployment script; The system calls system instructions to identify the CPU architecture type by using a one-click deployment script, and then matches the corresponding container orchestration platform installation package based on the identification result to obtain the architecture type identifier. The one-click deployment script reads the system configuration file to identify the operating system type. If it is identified as a domestic operating system, it calls the domestic innovation component library; otherwise, it calls the general component library to obtain the operating system type identifier. Based on the architecture type identifier, install the matching container orchestration platform using a one-click deployment script, configure platform access permissions, and obtain a ready container orchestration platform. Using a ready container orchestration platform, cache services, historical data warehouses, and log storage services are deployed sequentially according to the operating system type identifier, and each service is verified to be ready, resulting in a ready cluster of dependent services. By using a ready container orchestration platform, calling the service addresses in the ready dependency service cluster, deploying the microservice framework, and registering the service addresses of the cache service and historical data warehouse in the microservice framework, a usable microservice framework is obtained. By utilizing the available microservice framework, the cache services and historical data warehouse in the ready-to-use dependency service cluster are invoked, and target processing services, track processing services, and alarm services are deployed to obtain a containerized microservice cluster for nearshore monitoring.

[0060] In this embodiment, maintenance personnel execute a one-click deployment script on a domestically produced server at the nearshore monitoring station. The script automatically calls the `uname -m` command to identify the CPU as Phytium 2000+ (ARM architecture), reads ` / etc / os-release` to identify the operating system as Kylin V10, automatically matches the K3S installation package for ARM architecture, and performs silent installation. Subsequently, the `kubectl apply -f` command is used to deploy the Redis caching service, StarRocks historical data warehouse, and TARS microservice framework in sequence. Finally, business microservices such as TargetPro (target processing service), TrackPro (track processing service), and AlarmPro (alarm service) are deployed. The one-click script automatically completes the entire process of architecture identification, platform installation, and dependency deployment, shortening the traditional deployment cycle of several days to a few hours, without the need for professional maintenance personnel. It automatically adapts to the domestic IT innovation environment, allowing the system to run stably on domestic CPUs and operating systems. Single-node K3S deployment replaces multi-server clusters, reducing hardware costs and enabling the lightweight and rapid deployment of the nearshore monitoring system.

[0061] In some embodiments, step S101 may include, but is not limited to, steps S111 to S115: Step S111: Through the target processing service in the nearshore monitoring containerized microservice cluster, connect to the radar device interface and the AIS device interface respectively, receive the nearshore radar data stream and the nearshore AIS data stream, and obtain the nearshore original radar target set and the nearshore original AIS target set. Step S112: Perform time alignment and spatial coordinate transformation on the original nearshore radar target set and the original nearshore AIS target set to obtain the preprocessed radar target set and the preprocessed AIS target set; Step S113: Traverse the preprocessed radar target set and the preprocessed AIS target set, and sequentially perform the first dimension MMSI matching, the second dimension latitude and longitude and speed and heading combination matching, and the third dimension ship length and target type combination matching. Merge the successfully matched radar targets and AIS targets to generate a fused target record, and obtain the multi-dimensional matched fused target subset, the unmatched radar target set, and the unmatched AIS target set. Step S114: For each fusion target record in the multi-dimensional matching fusion target subset, assign a preset confidence weight according to the matching method, calculate the fusion confidence score, and retain the records whose fusion confidence scores reach the preset confidence threshold to obtain the high-scoring fusion target subset; the confidence weight includes MMSI matching weight, latitude and longitude matching weight, speed and heading matching weight, and ship length type matching weight. Step S115: Merge the high-resolution fusion target subset with the unmatched radar target set and the unmatched AIS target set, and assign a preset temporary label to the unmatched targets to obtain the near-shore fusion target dataset.

[0062] In steps S111 to S115 of this embodiment, near-shore radar data streams and AIS data streams are received in real time through a target processing service, and time alignment and coordinate transformation are performed on the two types of data. The preprocessed target set is traversed, and the MMSI field is compared first. If they match, they are directly fused; if they do not match, the differences in latitude and longitude, speed, and heading between the radar target and the AIS target are calculated. When all three differences are within a preset threshold, they are determined to be the same target. If this still fails, the ship length and target type are compared. When the ship length difference is ≤20% and both are fishing vessels, they are determined to be the same target. A confidence score is calculated based on weights assigned according to the matching method, and records with a score ≥80 are retained as fused targets. This progressive matching method solves the target identity confusion problem in mixed near-shore fishing vessel and merchant vessel scenarios, reduces fusion latency, and improves accuracy. Temporary identifiers are assigned to unmatched targets to prevent the loss of single-source radar and AIS data. The high-confidence fused target dataset provides a reliable data foundation for subsequent resource scheduling and alarm services.

[0063] In some embodiments, step S113 may include, but is not limited to, steps S131 to S134: Step S131: If the MMSI of the radar target and the AIS target are consistent, they are determined to be the same target. The fused target record is merged and the matching method is marked as MMSI matching to obtain the MMSI matching fused target subset. Step S132: If the MMSI is inconsistent, calculate the latitude and longitude difference, speed difference, and heading difference between the radar target and the AIS target. When the latitude and longitude difference, speed difference, and heading difference are all within their respective preset threshold ranges, they are determined to be the same target. Merge and generate a fused target record and mark the matching method as latitude and longitude speed and heading matching to obtain a subset of fused targets based on latitude and longitude speed and heading matching. Step S133: If latitude, longitude, speed and heading matching fails, compare the length and target type of the radar target and the AIS target. When the length difference is within the preset threshold range and the target type is consistent, they are determined to be the same target. Merge and generate fused target records and mark the matching method as length type matching to obtain a subset of fused targets with matching length type. Step S134: Merge the MMSI matching and fusion target subset, the latitude and longitude speed and heading matching and fusion target subset, and the ship length type matching and fusion target subset to obtain the multi-dimensional matching and fusion target subset, and at the same time obtain the unmatched radar target set and the unmatched AIS target set.

[0064] In steps S131 to S134 of this embodiment, precise MMSI matching in step S231 enables second-level determination of ships equipped with AIS devices using their unique identification codes, achieving fusion of similar targets. Step S232, combining latitude, longitude, speed, and heading, performs multi-condition joint determination of spatial position and motion state based on ship motion characteristics when MMSI is missing or inconsistent, effectively eliminating random errors. Step S233, matching ship length and target type attributes, utilizes ship static characteristics as supplementary determination criteria when the first two levels of matching fail, maximizing the discovery of fusionable targets. Step S234, merging the results, integrates the three-level matching results to form a complete fusion target set, while retaining unmatched single-source targets as supplementary data. This embodiment achieves progressive fusion from strong features to weak features, reducing fusion latency and improving accuracy in near-shore environments with dense targets and complex identities. It avoids resource waste caused by multi-source data redundancy while ensuring no loss of single-source data, providing a data foundation for subsequent target tracking, alarm analysis, and resource scheduling.

[0065] In some embodiments, step S102 may include, but is not limited to, steps S201 to S207: Step S201: Collect hardware resource utilization, number of targets in nearshore fusion target dataset, nearshore alarm quantity and nearshore playback task quantity through monitoring components to obtain nearshore monitoring load dataset; Step S202: Obtain the preset scene weights based on the current monitoring area type to get the nearshore scene weight value; the monitoring area types include fishing port areas, fishing ban areas, ordinary port areas and lake and reservoir areas; Step S203: Calculate the dynamic threshold based on the number of targets in the nearshore monitoring load dataset, the preset baseline number of targets, the current percentage of remaining server resources, and the nearshore scenario weight value. Step S204: Set a first duration and a second duration; the first duration and the second duration are used to periodically recalculate the dynamic threshold; Step S205: Compare the number of targets in the nearshore monitoring load dataset with a dynamic threshold. When the number of targets exceeds the first multiple of the dynamic threshold for a first consecutive duration, an expansion command is generated. When the number of targets is lower than the second multiple of the dynamic threshold for a second consecutive duration, a reduction command is generated. The expansion command and the reduction command are used as nearshore monitoring elastic scaling commands. Step S206: According to the nearshore monitoring elastic scaling command, increase or decrease the number of containers through the container orchestration platform. When expanding, first select nodes with sufficient remaining resources, migrate session data before scaling down, and obtain the adjusted container allocation data. Step S207: Collect the resource utilization rate and response delay after expansion or reduction, and use the resource utilization rate and response delay as inputs to adjust the dynamic threshold calculation parameters for subsequent cycles, so as to obtain resource allocation data adapted to nearshore target fluctuations.

[0066] In steps S201 to S207 of this embodiment, the Prometheus monitoring component collects data such as current CPU utilization, real-time target count (currently 3500), and alarm count every second. The system identifies the current area as a fishing port (scene weight 1.5) and calculates the dynamic threshold T = 2000 × (current remaining resource percentage 40% × 1.2) × 1.5 = 2000 × 0.48 × 1.5 = 1440. The real-time target count of 3500 has exceeded T × 1.2 (1728) for 2 consecutive minutes, triggering a scaling instruction. The number of new Pods is calculated as ceil((3500-1440) / 2000) = 2, and 2 new Pods are added on nodes with ≥40% remaining resources to process the target data. The system uses a dynamic threshold model to detect real-time fluctuations in the number of nearshore targets. During the fishing moratorium, when targets are scarce, it automatically reduces capacity to release resources and automatically expands capacity to ensure processing capabilities when targets surge during the fishing season. The server CPU / memory utilization rate is kept stable below 60% to avoid resource waste or overload and lag. The weighted round-robin algorithm ensures load balancing across service instances, resulting in smooth and lag-free nautical chart operations.

[0067] In some embodiments, step S103 may include, but is not limited to, steps S301 to S305: Step S301: Configure liveness probes and ready probes for each microservice in the nearshore monitoring containerized microservice cluster; liveness probes are used to detect the liveness status of service processes; ready probes are used to detect whether the service has the ability to process requests; liveness probes and ready probes are used as health check probes. Step S302: Send detection requests to each microservice through the liveness probe according to the first preset period to detect the service port connectivity and core process response status, record the microservices that do not respond or respond abnormally, and obtain a list of liveness abnormal microservices. Step S303: Send detection requests to each microservice through the ready probe according to the second preset period to detect service response delay and backend database connection status, record microservices whose response delay exceeds the preset threshold or whose database connection fails, and obtain a list of ready abnormal microservices. Step S304: Merge and deduplicate the list of live abnormal microservices and the list of ready abnormal microservices, and mark the abnormal type and occurrence time of each abnormal microservice to obtain the original microservice health status data. Step S305: Statistically analyze the original microservice health status data for each microservice, analyze the number of anomalies and anomaly patterns of each microservice within a preset time window, identify the microservices that need to be restarted and the microservices that need to be migrated, and obtain the microservice health status data.

[0068] In steps S301 to S305 of this embodiment, a liveness probe (checking port 8080 connectivity every 5 seconds) and a readiness probe (checking the response latency of the / api / health interface and Redis connection status every 3 seconds) are configured for the TargetPro microservice. If, at a certain moment, the readiness probe detects a response latency of 800ms (exceeding the preset threshold of 500ms) and three consecutive detections fail, the system marks the service as readiness-abnormal, recording the exception type as "response timeout" and the exception time as "14:23:15". This dual-probe mechanism provides second-level awareness of the microservice's running status; the liveness probe prevents process freezes, and the readiness probe avoids forwarding requests to faulty services. Accurate identification of exception types and times provides a basis for decision-making in tiered restarts, avoiding blind restarts that could lead to business interruptions.

[0069] In some embodiments, step S104 may include, but is not limited to, steps S401 to S407: Step S401: Based on the microservice health status data, count the number of times each abnormal microservice is abnormal within a preset unit time to obtain microservice abnormal frequency data. Step S402: Compare the microservice exception frequency data with the preset restart threshold. If the number of exceptions does not exceed the restart threshold, generate a local restart command. If the number of exceptions exceeds the restart threshold, generate a node migration command. Step S403: Perform a restart operation on the current container unit of the abnormal microservice according to the local restart command, and monitor whether the restart process is completed within the preset timeout period to obtain the microservice container unit after local restart. Step S404: According to the node migration instruction, obtain the backup node resource information from the resource allocation data, schedule the abnormal microservice to the backup node for redeployment and release the original node resources to obtain the migrated microservice container unit. Step S405: Obtain the most recent timed snapshot and the incremental operation logs after the snapshot from the historical data warehouse to obtain the data snapshot and incremental logs; Step S406: Synchronize data from the master node of the cache service through the master-slave replication mechanism to obtain synchronized cache data; Step S407: After the microservice container unit is restarted locally or after migration, load the data snapshot and incremental log to restore historical data, and connect the synchronized cached data to restore dynamic data, thus obtaining the restored near-shore fusion target dataset.

[0070] In steps S401 to S407 of this embodiment, the system counts TargetPro as having 4 anomalies within 1 minute (exceeding the restart threshold of 3), and generates a node migration command. Backup node information is obtained from resource allocation data, TargetPro is scheduled to the backup node for redeployment, and the original node resources are released. After the new Pod starts, the latest real-time target data is synchronized from the Redis master node, and the most recent 5-minute snapshot and incremental logs are pulled from StarRocks to restore historical trajectory data. The entire process takes 45 seconds, and the consistency error between the restored target data and the data before the anomaly is ≤100 meters. Through a tiered restart mechanism, minor faults can be quickly recovered locally (≤30 seconds), and severe faults can be automatically migrated to avoid repeated crashes; core services are configured with anti-affinity to prevent single points of failure; cache replication and data snapshots provide dual protection to ensure data is not lost and is traceable. This embodiment can improve system availability, reduce maintenance manpower costs, and meet the 24 / 7 stable operation requirements of nearshore monitoring.

[0071] This application also provides a lightweight BS architecture nearshore monitoring system for implementing the aforementioned method. The system includes: The first module is used to receive near-shore radar and AIS data through a containerized microservice cluster for near-shore monitoring, and to fuse near-shore fishing vessel and merchant ship targets through a multi-dimensional matching algorithm to obtain a near-shore fused target dataset. The second module is used to calculate dynamic thresholds based on the number of targets in the nearshore fusion target dataset and the nearshore scenario load data, and to trigger the elastic scaling of containers according to the dynamic thresholds to obtain resource allocation data that adapts to the fluctuations of nearshore targets. The third module is used to periodically detect the running status of microservices through health check probes, identify abnormal microservices based on the detection results, and obtain microservice health status data. The fourth module is used to perform a tiered restart of abnormal microservices based on resource allocation data and microservice health status data, schedule standby node resources, and restore the near-shore fusion target dataset through cache replication and data snapshots to obtain the restored near-shore fusion target dataset.

[0072] In some embodiments, the lightweight BS architecture nearshore monitoring system further includes a presentation layer, an application layer, a capability layer, and an access layer; The access layer is used to receive radar data, AIS data, and optoelectronic data, and output raw multi-source nearshore data; the access layer includes a standardized interface module; the standardized interface module connects radar equipment, AIS equipment, and optoelectronic equipment; The capability layer includes an edge preprocessing unit, a caching unit, and a historical data storage unit; The edge preprocessing unit connects to the access layer, performs noise reduction and filtering preprocessing on the raw multi-source nearshore data, and outputs the preprocessed nearshore data. The cache unit connects to the edge preprocessing unit, stores target data, and outputs a nearshore target dataset. The historical data storage unit is connected to the edge preprocessing unit to store historical target data and output a nearshore historical target dataset. The application layer includes target processing service, trajectory processing service, and alarm service deployed under a microservice framework; The target processing service connects to the cache unit to process the nearshore target dataset and outputs the processed target data. The track processing service connects to the historical data storage unit, performs track analysis on the nearshore historical target dataset, and outputs target track data. The alarm service connects to the target processing service and the track processing service, generates alarm information based on the processing results, and outputs nearshore monitoring alarm data. The presentation layer includes a plugin-free browser server architecture front-end; the plugin-free browser server architecture front-end connects to the application layer, receives processed target data, target track data and nearshore monitoring alarm data through communication protocols, updates nautical charts and target information, and outputs a nearshore target visualization monitoring interface.

[0073] As an optional implementation method, this application proposes an innovative lightweight architecture of "K3S single node + TARS microservice". It achieves single-server deployment through layered design and shortens the deployment cycle to 2 hours with a one-click automated deployment tool. It also innovatively adopts the "edge preprocessing + central lightweight fusion" mode, combined with PB serialization and incremental transmission technology, to achieve a multi-source data fusion latency of ≤30 seconds. It is fully compatible with domestic CPUs, operating systems and browsers.

[0074] The server resource utilization rate is stabilized below 60% through a dynamic resource scheduling strategy. The core of the dynamic scheduling strategy is a closed-loop mechanism of "perception-decision-execution-feedback", and the role of each layer is as follows: 1) The perception layer uses Prometheus + Grafana to collect hardware resources, business load (number of targets, number of alarms, playback tasks) and scenario-based load prediction data in seconds; 2) The decision-making level prioritizes business tasks, triggers elastic scaling based on thresholds and predictions, and uses a weighted round-robin algorithm to allocate resources evenly. 3) The execution layer relies on K3S to achieve targeted scheduling and elastic scaling of Pods, and dynamically adjusts resource quotas through namespace isolation and storage sharding; 4) The feedback layer uses indicators such as resource utilization and response latency, combined with reinforcement learning for adaptive optimization, and triggers service degradation and fault tolerance mechanisms when anomalies occur, to ensure that resource usage is kept below 60% and system availability reaches 99.9%.

[0075] The integration of Grafana and Prometheus enables intelligent monitoring and service self-healing mechanisms. The implementation of these self-healing mechanisms primarily involves three aspects: 1) K3S health check strategy: Configure liveness probes and readiness probes for each microservice. The liveness probe checks the service port connectivity and core process status every 5 seconds, and the readiness probe checks the service response latency (≤500ms) and database connection availability every 3 seconds. If the test fails, it is marked as abnormal and the self-healing process is triggered.

[0076] 2) Restart strategy: A "tiered restart" mechanism is adopted. If a single service experiences ≤3 anomalies within 1 minute, the Pod will be automatically restarted (restart timeout ≤30 seconds); if it exceeds 3 anomalies, it will be scheduled to be deployed on a backup node, and the resources of the original node will be released at the same time; the core services (TargetPro, AlarmPro) are configured with Pod anti-affinity to avoid single point of failure.

[0077] 3) Data consistency recovery: Real-time target data is synchronized through Redis master-slave replication, and StarRocks timed snapshots (every 5 minutes) + logs ensure the traceability of historical data; after the service restarts, the latest snapshot and incremental logs are automatically pulled, and data is quickly restored through PB serialization. The data consistency error is ≤100 meters and the recovery time is ≤1 minute.

[0078] The above strategies ensure that system availability is increased to 99.9%, addressing the core pain points of traditional systems, such as complex deployment, high resource consumption, insufficient adaptation to domestic IT innovation, and high maintenance difficulty.

[0079] The solutions of this application embodiment will be described in detail and explained below with reference to specific application examples: 1.Reference Figure 1System architecture design: A layered, lightweight architecture of "Presentation Layer - Application Layer - Capability Layer - Access Layer" is adopted, based on K3S single-node containerized deployment, supporting both ARM and x86 architectures. The presentation layer is a plugin-free B / S frontend built with React, compatible with mainstream and domestically developed browsers such as Chrome and UnionTech Browser, achieving real-time interaction via HTTP / WebSocket, with a chart refresh latency of ≤2 seconds. The application layer is based on the TARS framework, splitting into fine-grained microservices such as TargetPro and TrackPro, with inter-service communication via PB serialization. The capability layer adopts a two-level data processing of "edge-center," with edge nodes preprocessing radar / AIS data, and the center caching real-time targets through Redis and storing historical data through StarRocks. The access layer provides standardized interfaces, supporting access from radar, AIS, optoelectronic devices, etc., and is compatible with the GB protocol and SDK.

[0080] 2. Lightweight Deployment Solution: Utilizing K3S instead of traditional Kubernetes reduces memory usage by 40%; a one-click deployment script is developed to automatically complete environment detection, component installation, and parameter configuration, with deployment time ≤ 2 hours; Pod resource allocation is dynamically adjusted based on the target number of Pods. Core formula: Threshold T = Baseline target number T0 × Resource elasticity coefficient K × Scenario weight W (T0 defaults to 2000).

[0081] K = Current remaining server resource percentage × 1.2 (range 0.8-1.5, real-time data collection and calculation), W is determined by the scenario (fishing port / fishing ban period 1.5, ordinary port area 1.0, lake / reservoir 0.8).

[0082] T is recalculated every 30 seconds. Scaling is triggered when the real-time target number is ≥ T × 1.2 for 2 consecutive minutes, and scaling down is triggered when it is ≤ T × 0.6 for 5 consecutive minutes. The number of Pods added in a single scaling up operation is calculated as ceil ((real-time target number - T) / T0), with a maximum of ≤ 100. The number of Pods reduced in a single scaling down operation is calculated as floor ((T - real-time target number) / T0), with a minimum of ≥ 3. Scaling up prioritizes nodes with ≥ 40% remaining resources. Session data is migrated before scaling down to ensure a seamless experience for businesses.

[0083] Automatic expansion during photoelectric linkage, resource release during idle periods, server CPU / memory utilization stabilized below 60%, and the number of Pods per node limited to ≤100.

[0084] 3. Data Processing and Transmission Optimization: A fast fusion algorithm is designed, prioritizing precise MMSI matching. If the radar and AIS target MMSIs match, they are directly identified as the same target, with a fusion delay ≤10 seconds. If MMSI matching fails, an alternative strategy is used, triggering secondary matching based on "latitude / longitude + speed and heading" and "ship length + target type" sequentially. Latitude / longitude matching is centered on the target location, with an error tolerance range ≤100 meters (based on radar positioning accuracy ±50 meters, AIS positioning error ±30 meters, with a 20-meter redundancy). Matching is determined when the speed error is ≤2 knots and the heading error is ≤15°. If matching still fails, supplementary matching is performed using a ship length error ≤20% + a target type that matches (e.g., both are fishing vessels). Multi-dimensional matching is performed using MMSI, latitude and longitude (error ≤ 100 meters), speed and heading. Confidence level = (MMSI matching score × 0.6 + latitude and longitude matching score × 0.2 + speed and heading matching score × 0.1 + ship length type matching score × 0.1). A score ≥ 80 indicates successful fusion, ensuring an accuracy ≥ 90%. Fusion time ≤ 30 seconds, accuracy ≥ 90%. A PB serialization + incremental transmission strategy is adopted (establishing a local cache and transmission status table to record the identifier and verification information of transmitted data. The status table is verified before transmission, and only untransmitted or changed data is sent; a "request-confirmation" mechanism is used, updating the status table after successful transmission feedback from the receiving end, and retransmitting if no confirmation is received within a timeout (maximum 3 times); for high-frequency changing data (such as real-time trajectory), a minimum transmission interval (≤ 1 second) is set to avoid repeated transmission within a short period). Data compression ratio ≥3:1, suitable for low-bandwidth maritime environments; data is stored in layers based on data popularity, with real-time data stored in Redis (≤5000 records) and historical data stored in StarRocks (≤1 year), and query response time ≤5 seconds.

[0085] 4. Compatibility with domestic IT innovation environments: Supports domestic CPUs (Huawei Kunpeng 920, Phytium 2000+), operating systems (Kylin V10, Tongxin UOS), and browsers (Tongxin, Red Lotus National Cryptography). All dependent components are selected from the domestic IT innovation directory.

[0086] 5. Optimized Operations and Monitoring: Integrates Grafana + Prometheus monitoring system to monitor server resources and service status in real time; enables service self-healing through K3S health checks, backs up critical data regularly, and automatically alerts to anomalies.

[0087] This application focuses on the lightweight and automated deployment requirements of nearshore monitoring systems. It constructs a one-click deployment system based on K3S lightweight container orchestration technology, achieving seamless adaptation across hardware architectures and operating systems, and fully automated execution of the entire process. The solution integrates key steps such as environment detection, container platform installation, dependent component deployment, business microservice deployment, and system parameter configuration through pre-set scripts. No manual intervention is required; simply starting the script completes the entire deployment chain from environment verification to system availability. It is also compatible with ARM / x86 dual-CPU architectures and domestic and non-domestic operating systems such as Kylin and UnionTech UOS, ensuring stable deployment in different hardware and software environments and significantly reducing deployment barriers and operational complexity.

[0088] The process of this application embodiment includes: 1. Intelligent Environment Detection: After the deployment script starts, it first executes an environment detection process, automatically calling system commands to obtain CPU architecture information (identified as aarch64 / ARM architecture or x86_64 / x86 architecture via the uname -m command), and matching the corresponding K3S installation package version (ARM architecture is adapted to arm64 version, x86 architecture is adapted to amd64 version). If an unsupported CPU architecture is detected, the deployment will be terminated directly and an error message will be displayed. At the same time, the system configuration file ( / etc / os-release) is read to detect the operating system type, accurately identifying domestic operating systems such as Kylin and UnionTech UOS and automatically enabling the domestic innovation component adaptation mode. If no domestic operating system is detected, a warning message will be output and the compatibility deployment mode will be started to ensure the feasibility of deployment in non-standard environments.

[0089] 2. K3S Platform Installation: Based on the architecture version determined by environment detection, the corresponding K3S container platform installation package is pulled through the specified URL. A silent installation method is used to perform the deployment operation, while configuring the kubeconfig file permissions to 644 to ensure subsequent access permissions. After the installation command is executed, wait 30 seconds to allow sufficient time for the K3S service to start. Then, verify the node status using the `kubectl get nodes` command. If the command executes successfully, the K3S installation is confirmed to be complete; if it fails, an error message is output and the entire deployment process is terminated, ensuring the successful setup of the container platform's basic environment.

[0090] 3. Dependency Component Deployment: Once the K3S platform is ready, the script automatically executes the core dependency component deployment process, deploying three key components sequentially via the Kubernetes command (kubectl apply -f): First, it pulls the Redis Stack deployment file from the specified open-source address to complete the Redis caching service deployment (used to store real-time target data and ensure high-concurrency access performance); second, it loads the corresponding version of the StarRocks deployment file (starrocks-deploy-$K3S_ARCH.yaml) according to the CPU architecture to deploy a high-performance columnar storage data warehouse (used for long-term storage of historical trajectory data); and third, it loads the Elasticsearch deployment file to deploy a log storage service (used to store alarm logs and business operation logs). After the component deployment command is executed, it waits 60 seconds to ensure that all dependent services have started and reached a ready state, providing stable support for subsequent business service deployments.

[0091] 4. Microservice Deployment: After the dependent components are ready, the business microservice deployment phase begins. First, the TARS microservice framework is installed using the deployment file (tars-deploy.yaml) to build the basic environment for microservice operation. Then, the core business services of the system are deployed in sequence, including TargetPro target processing service (responsible for receiving and processing multi-source target data such as radar and AIS), TrackPro trajectory processing service (responsible for calculating and storing target trajectories), AlarmPro alarm service (responsible for executing intelligent early warning rules and generating alarm information), and CCTV-service optoelectronic service (responsible for accessing optoelectronic devices and forwarding control commands). All microservices are deployed in batches using Kubernetes commands. After deployment, a prompt message is output to ensure that all business function modules are online.

[0092] 5. System Parameter Configuration: After the microservice deployment is complete, the script automatically executes the core parameter configuration process. It enters the TargetPro service container under the TARS namespace through the kubectl exec command, writes the maximum target quantity threshold (MAX_TARGET=5000) to the application configuration file ( / config / application.properties), and limits the total target quantity processed by the system in real time. At the same time, it copies the default data fusion rule configuration file (fusion-rule-default.yaml) to the effective path ( / config / fusion-rule.yaml) to ensure that the system completes multi-source data fusion processing according to the preset rules. There is no need to manually configure core business parameters, ensuring that the system can run according to standard logic after deployment.

[0093] 6. Deployment Completion Output: After all deployment steps are completed, the script automatically calculates the total deployment time (by calculating the number of seconds the script runs and converting it to minutes), and obtains the server IP address using the hostname -I command, generating a standardized system access address (http: / / server IP:8080). The time information and access address are then output to the user simultaneously, allowing the user to directly access the nearshore monitoring system through this address. The entire deployment process is now complete.

[0094] Technical effects of the embodiments of this application: 1. Significantly reduced deployment costs: Single-server deployment replaces multi-server clusters, reducing hardware costs by 70%, and one-click deployment tools shorten the deployment cycle from 3-5 days to 2 hours, eliminating the need for professional maintenance personnel; 2. Resource utilization optimization: Fine-grained microservices + dynamic scheduling keep CPU / memory utilization stable below 60%, supports processing ≤5000 real-time targets, and ensures smooth nautical chart operations; 3. Comprehensive adaptation to domestic IT innovation: Full-stack compatibility with domestic software and hardware, and stable operation in environments such as Huawei Kunpeng and Kirin OS; 4. Improved data fusion efficiency: Fusion latency ≤30 seconds, accuracy ≥90%, PB serialization + incremental transmission adapts to low bandwidth environments, and data transmission is lossless; 5. Significantly improved operation and maintenance efficiency: Intelligent monitoring and service self-healing reduce operation and maintenance manpower costs by 80% and increase system availability to 99.9%, meeting the long-term stable operation needs of small areas.

[0095] The technical solutions in this application embodiment can be substituted in the following ways: 1. Container orchestration platform: K3S can be replaced by other lightweight Kubernetes distributions (such as MicroK8s), but the core requirements must be single-node deployment and low resource consumption. 2. Microservice framework: TARS can be replaced by mainstream microservice frameworks such as Spring Cloud, but service decoupling and high availability must be guaranteed; 3. Storage components: StarRocks can be replaced with high-performance columnar storage such as ClickHouse, and Redis can be replaced with in-memory databases such as Memcached, provided that the corresponding storage performance metrics are met; 4. Monitoring components: Grafana+Prometheus can be replaced with monitoring systems such as Zabbix, which must implement resource monitoring and anomaly alarm functions.

[0096] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0097] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0098] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0099] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0100] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0101] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0102] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0103] This application provides a lightweight B / S architecture nearshore monitoring method, system, electronic device, storage medium, and program product. It automatically detects the server CPU architecture and operating system type through a one-click deployment script, installs a matching lightweight container orchestration platform, and deploys caching services, historical data warehouses, and microservice frameworks to quickly build a containerized microservice cluster for nearshore monitoring. The target processing service within the containerized microservice cluster receives nearshore radar and AIS data in real time, executes multi-dimensional matching algorithms, sequentially performing MMSI matching, latitude / longitude and speed / heading combination matching, and ship length and target type combination matching. Based on confidence weights, it calculates a fusion score to achieve high-precision fusion identification of nearshore fishing vessels and merchant ships, obtaining a nearshore fused target dataset. The monitoring component collects hardware resource occupancy and data from the fused target dataset. The system calculates a dynamic threshold based on the real-time target number and near-shore scenario weights, generates expansion or contraction instructions based on the dynamic threshold, and automatically adjusts the number of container units through a container orchestration platform to achieve dynamic adaptation of computing resources to fluctuations in the number of near-shore targets. By configuring liveness probes and ready probes for each microservice, the system periodically detects the service's running status, identifies abnormal microservices and counts the number of anomalies, performs local restarts for microservices that have not exceeded the restart threshold, and schedules microservices that have exceeded the restart threshold to standby nodes for redeployment. The system also restores the fused target dataset through master-slave replication of the cache service and periodic snapshots of the historical data warehouse to achieve self-healing recovery of service failures. This embodiment of the application runs the entire stack under a domestic CPU, domestic operating system, and domestic browser environment, and all components are selected from the near-shore monitoring domestic innovation catalog, realizing a lightweight and highly available near-shore monitoring system.

[0104] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0105] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0106] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0108] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application 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 this application 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 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.

[0109] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0110] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0111] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0112] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0113] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0114] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for offshore monitoring with a lightweight BS architecture, the method comprising: The method includes the following steps: Receive near-shore radar and AIS data, and fuse near-shore fishing vessel and merchant ship targets through a multi-dimensional matching algorithm to obtain a near-shore fused target dataset; Based on the number of targets in the nearshore fusion target dataset and the nearshore scenario load data, a dynamic threshold is calculated, and the container is elastically scaled according to the dynamic threshold to obtain resource allocation data that adapts to nearshore target fluctuations. The health check probe periodically detects the running status of microservices, identifies abnormal microservices based on the detection results, and obtains microservice health status data. Based on the resource allocation data and the microservice health status data, a tiered restart is performed on the abnormal microservice, and backup node resources are scheduled to restore the near-shore fusion target dataset through cache replication and data snapshot, thus obtaining the restored near-shore fusion target dataset.

2. The method of claim 1, wherein, The received near-shore radar and AIS data are fused using a multi-dimensional matching algorithm to obtain a near-shore fused target dataset, including: Through the target processing service, the radar equipment interface and the AIS equipment interface are connected respectively to receive the nearshore radar data stream and the nearshore AIS data stream, and obtain the raw nearshore radar target set and the raw nearshore AIS target set. The original nearshore radar target set and the original nearshore AIS target set are time-aligned and spatial coordinate transformed to obtain the preprocessed radar target set and the preprocessed AIS target set; Traverse the preprocessed radar target set and the preprocessed AIS target set, and sequentially perform the first dimension MMSI matching, the second dimension latitude and longitude and speed and heading combination matching, and the third dimension ship length and target type combination matching. Merge the successfully matched radar targets and AIS targets to generate a fused target record, and obtain the multi-dimensional matched fused target subset, the unmatched radar target set, and the unmatched AIS target set. For each fusion target record in the multi-dimensional matching fusion target subset, a preset confidence weight is assigned according to the matching method, and a fusion confidence score is calculated. Records whose fusion confidence scores reach a preset confidence threshold are retained to obtain a high-scoring fusion target subset. The confidence weights include MMSI matching weight, latitude and longitude matching weight, speed and heading matching weight, and ship length type matching weight. The high-resolution fusion target subset is merged with the unmatched radar target set and the unmatched AIS target set, and the unmatched targets are assigned a preset temporary identifier to obtain the near-shore fusion target dataset.

3. The method of claim 2, wherein, The process involves traversing the preprocessed radar target set and the preprocessed AIS target set, sequentially performing first-dimensional MMSI matching, second-dimensional latitude / longitude and speed / heading combination matching, and third-dimensional ship length and target type combination matching. Successfully matched radar targets and AIS targets are merged to generate a fused target record, resulting in a multi-dimensional matched fused target subset, an unmatched radar target set, and an unmatched AIS target set, including: If the MMSI of a radar target and an AIS target are the same, they are determined to be the same target. The targets are merged to generate a fused target record and the matching method is marked as MMSI matching, thus obtaining a subset of MMSI-matched fused targets. If the MMSI is inconsistent, the latitude and longitude difference, speed difference, and heading difference between the radar target and the AIS target are calculated. When the latitude and longitude difference, speed difference, and heading difference are all within their respective preset threshold ranges, they are determined to be the same target. The targets are merged to generate a fused target record and the matching method is marked as latitude and longitude speed and heading matching to obtain a subset of fused targets based on latitude and longitude speed and heading matching. If latitude, longitude, speed and heading matching fails, the length and target type of radar target and AIS target are compared. When the length difference is within the preset threshold range and the target type is the same, they are determined to be the same target. The target records are merged and generated, and the matching method is marked as length type matching to obtain the length type matching fused target subset. The MMSI matching and fusion target subset, the latitude and longitude speed and heading matching and fusion target subset, and the ship length type matching and fusion target subset are merged to obtain a multi-dimensional matching and fusion target subset, and at the same time, an unmatched radar target set and an unmatched AIS target set are obtained.

4. The method of claim 1, wherein, The process of calculating a dynamic threshold based on the number of targets in the nearshore fusion target dataset and the nearshore scenario load data, and triggering container elastic scaling according to the dynamic threshold to obtain resource allocation data adapted to nearshore target fluctuations, includes: The nearshore monitoring load dataset is obtained by collecting hardware resource utilization, the number of targets in the nearshore fusion target dataset, the number of nearshore alarms, and the number of nearshore playback tasks by the monitoring component. The preset scene weights are obtained based on the current monitoring area type to obtain the nearshore scene weight value; the monitoring area types include fishing port areas, fishing ban areas, ordinary port areas and lake and reservoir areas; The dynamic threshold is calculated based on the number of targets in the nearshore monitoring load dataset, the preset baseline number of targets, the current percentage of remaining server resources, and the nearshore scenario weight value. A first duration and a second duration are set; the first duration and the second duration are used to periodically recalculate the dynamic threshold; The target number in the nearshore monitoring load dataset is compared with the dynamic threshold. When the target number exceeds the first multiple of the dynamic threshold for the first duration, an expansion instruction is generated. When the target number is lower than the second multiple of the dynamic threshold for the second duration, a reduction instruction is generated. The expansion instruction and the reduction instruction are used as nearshore monitoring elastic scaling instructions. According to the nearshore monitoring elastic scaling command, the number of containers is increased or decreased through the container orchestration platform. When expanding, nodes with sufficient remaining resources are selected first, and session data is migrated before shrinking to obtain the adjusted container allocation data. Collect resource utilization rate and response delay after expansion or reduction, and use the resource utilization rate and response delay as input to adjust the dynamic threshold calculation parameters for subsequent cycles to obtain resource allocation data adapted to nearshore target fluctuations.

5. The method of claim 1, wherein, The process involves periodically detecting the operational status of microservices using health check probes, identifying abnormal microservices based on the detection results, and obtaining microservice health status data, including: Configure a liveness probe and a readiness probe for each microservice; the liveness probe is used to detect the liveness status of the service process; the readiness probe is used to detect whether the service has the ability to process requests; the liveness probe and the readiness probe are used as health check probes. The survival probe sends detection requests to each microservice according to a first preset period to detect the service port connectivity and core process response status, records the microservices that do not respond or respond abnormally, and obtains a list of abnormal survival microservices. The ready probe sends detection requests to each microservice according to the second preset period to detect service response delay and backend database connection status, and records microservices whose response delay exceeds a preset threshold or whose database connection fails, thus obtaining a list of abnormal ready microservices. The list of live abnormal microservices and the list of ready abnormal microservices are merged and deduplicated, and each abnormal microservice is marked with its abnormality type and occurrence time to obtain the original microservice health status data. The original microservice health status data is statistically analyzed for each microservice, and the number of anomalies and anomaly patterns of each microservice within a preset time window are analyzed to identify microservices that need to be restarted and microservices that need to be migrated, thus obtaining microservice health status data.

6. The method of claim 1, wherein, The process involves performing a tiered restart of abnormal microservices based on the resource allocation data and the microservice health status data, scheduling backup node resources, and restoring the near-shore fusion target dataset through cache replication and data snapshots. The restored near-shore fusion target dataset includes: Based on the microservice health status data, the number of times each abnormal microservice is abnormal within a preset unit of time is counted to obtain microservice abnormal frequency data. The microservice anomaly frequency data is compared with a preset restart threshold. If the number of anomalies does not exceed the restart threshold, a local restart command is generated. If the number of anomalies exceeds the restart threshold, a node migration command is generated. According to the local restart instruction, the current container unit of the abnormal microservice is restarted, and the restart process is monitored to see if it is completed within the preset timeout period, so as to obtain the microservice container unit after local restart. According to the node migration instruction, the backup node resource information is obtained from the resource allocation data, the abnormal microservice is scheduled to the backup node for redeployment and the original node resources are released to obtain the migrated microservice container unit. The most recent timed snapshot and the incremental operation logs after the snapshot are obtained from the historical data warehouse to obtain the data snapshot and incremental logs. Synchronize data from the master node of the cache service using a master-slave replication mechanism to obtain synchronized cache data; After the microservice container unit is restarted locally or after migration, the data snapshot and the incremental log are loaded to restore historical data, and the synchronized cached data is connected to restore dynamic data to obtain the restored near-shore fusion target dataset.

7. A lightweight BS architecture offshore monitoring system for implementing the method according to any one of claims 1 to 6, characterized in that, The system includes: The first module is used to receive near-shore radar and AIS data, and to fuse near-shore fishing vessel and merchant ship targets through a multi-dimensional matching algorithm to obtain a near-shore fused target dataset. The second module is used to calculate a dynamic threshold based on the number of targets in the nearshore fusion target dataset and the nearshore scenario load data, and to trigger the elastic scaling of the container according to the dynamic threshold to obtain resource allocation data that adapts to the fluctuations of nearshore targets. The third module is used to periodically detect the running status of microservices through health check probes, identify abnormal microservices based on the detection results, and obtain microservice health status data. The fourth module is used to perform a step-by-step restart of abnormal microservices based on the resource allocation data and the microservice health status data, schedule standby node resources, and restore the near-shore fusion target dataset through cache replication and data snapshots to obtain the restored near-shore fusion target dataset.

8. The system of claim 7, wherein, The system also includes a presentation layer, an application layer, a capability layer, and an access layer; The access layer is used to receive radar data, AIS data, and optoelectronic data, and output raw multi-source nearshore data; the access layer includes a standardized interface module; the standardized interface module connects to radar equipment, AIS equipment, and optoelectronic equipment. The capability layer includes an edge preprocessing unit, a caching unit, and a historical data storage unit; The edge preprocessing unit is connected to the access layer, performs noise reduction and filtering preprocessing on the raw nearshore multi-source data, and outputs the preprocessed nearshore data. The cache unit is connected to the edge preprocessing unit, stores target data, and outputs near-shore target dataset; The historical data storage unit is connected to the edge preprocessing unit, stores historical target data, and outputs a nearshore historical target dataset. The application layer includes target processing service, trajectory processing service and alarm service deployed under a microservice framework; The target processing service connects to the cache unit, processes the nearshore target dataset, and outputs the processed target data; The track processing service connects to the historical data storage unit, performs track analysis on the nearshore historical target dataset, and outputs target track data. The alarm service connects the target processing service and the track processing service, generates alarm information based on the processing results, and outputs nearshore monitoring alarm data. The presentation layer includes a plugin-free browser server architecture front-end; The plugin-free browser server architecture is connected to the application layer at the front end. It receives the processed target data, the target track data, and the nearshore monitoring alarm data through a communication protocol, updates the nautical chart and target information, and outputs a nearshore target visualization monitoring interface.

9. An electronic device, comprising: The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

Images