Maritime target monitoring system and method based on micro-front-end architecture

Abstract

The invention provides a marine target monitoring system and method based on a micro-front-end architecture, relates to the technical field of marine target monitoring, and solves the problem that an existing system is difficult to develop and maintain. The marine target monitoring system comprises a main application and a plurality of sub-applications with independent technical stacks of a front-end application layer, the corresponding sub-applications are dynamically loaded and rendered, and a data access processing service of the data service layer is configured to access original target data and process and store the original target data in real time; the application service of the data service layer is configured to obtain the processed target data and push the data to the corresponding sub-applications in real time, and the sub-applications are independently deployed and configured to interact with the application service through the unified gateway to receive and display the target data. According to the application, each sub-application can be independently developed and deployed and is easy to develop and maintain, the unnecessary query load of the server is reduced, and the overall resource utilization efficiency of the system is optimized.

Description

Technical Field

[0001] This application relates to the field of marine target monitoring technology, specifically to a marine target monitoring system and method based on a micro-frontend architecture. Background Technology

[0002] With the implementation of the maritime power strategy and the rapid development of the marine economy, the demand for monitoring and information display of maritime targets (such as ships, floating objects, and platforms) is increasing. Currently, maritime target monitoring systems generally adopt a browser / server (B / S) architecture, typically using a monolithic front-end architecture. Developing the various modules within a single project often results in interdependence and coupling between modules, leading to difficulties in development and maintenance, poor system stability, and the inability to independently deploy functions. Summary of the Invention

[0003] This application provides a marine target monitoring system and method based on a micro-frontend architecture that is easy to develop and maintain and has high overall system stability.

[0004] This application provides a marine target monitoring system based on a micro-frontend architecture, comprising: The front-end application layer includes a main application with an independent technology stack and multiple sub-applications. The main application is configured to dynamically load and render the corresponding sub-applications based on the sub-application configuration information. The data service layer includes application services and data access processing services. The data access processing services are configured to access raw target data and process and store the raw target data in real time. The application services are configured to retrieve the processed target data from the data access processing services or persistent storage within the system and push the data to the corresponding sub-application in real time. The sub-application is deployed independently and configured to interact with the application service through a unified gateway to receive and display the target data.

[0005] In one possible implementation of this application, the main application is further configured to provide shared components and application programming interfaces to the sub-application via attribute passing, and to communicate with the sub-application via an event publishing / subscription mechanism.

[0006] In one possible implementation of this application, the sub-application includes at least one of a target display sub-application, a trajectory playback and analysis sub-application, an early warning alarm sub-application, and an optoelectronic video surveillance sub-application.

[0007] In one possible implementation of this application, the system further includes a data storage layer, which includes at least one of a message middleware, a real-time analytics database, an in-memory database, and a search engine.

[0008] In one possible implementation of this application, the data access processing service is specifically configured to receive target data through the message middleware; clean, fuse, and analyze the target data through a real-time stream computing engine; write the processed real-time trajectory coordinate data into the real-time analysis database; and write the real-time warning and analysis result data into the memory database.

[0009] In one possible implementation of this application, the unified gateway supports Hypertext Transfer Protocol Requests and long-lived network socket services that characterize a state transition architecture style.

[0010] On the other hand, this application also provides a method for monitoring maritime targets based on a micro-frontend architecture, including: a main application acquiring sub-application configuration information, and dynamically loading and rendering the corresponding sub-application according to the sub-application configuration information; The original target data is accessed through a data access processing service, and the original target data is processed and stored in real time. The application service retrieves the processed target data from the data access processing service or the persistent storage within the system, and pushes the data to the corresponding sub-application in real time. The sub-application interacts with the application service through a unified gateway to receive and display the target data.

[0011] In one possible implementation of this application, the step of dynamically loading and rendering the corresponding sub-application based on the sub-application configuration information includes: The main application calls the registration method of the micro-frontend framework to register the sub-application; The main application matches and executes the lifecycle hook function of the target sub-application based on the sub-application configuration information, and mounts the target sub-application to the specified document object model container.

[0012] In one possible implementation of this application, the step of accessing the original target data through a data access processing service and processing and storing the original target data in real time includes: Push the raw target data to the message middleware; The real-time stream computing engine consumes data from the message middleware and performs cleaning, fusion, and computation. The calculated real-time trajectory data is stored in a real-time analysis database, and the early warning analysis results are stored in an in-memory database.

[0013] In one possible implementation of this application, the main application obtains the sub-application configuration information, including: In response to user access, initialize the main application; The main application initiates a Hypertext Transfer Protocol request to the unified gateway, representing a state transition architecture style, to obtain user permissions and the sub-application configuration information.

[0014] This application provides a maritime target monitoring system based on a micro-frontend architecture. Built upon this architecture, the system comprises a main application with an independent technology stack and multiple dynamically loadable sub-applications. This allows each sub-application to be developed and deployed independently, solving the problems of difficult upgrades and replacements caused by technology stack bundling in traditional monolithic frontend architectures, as well as high maintenance complexity and low team collaboration efficiency caused by deep module coupling. When updating a business function or introducing new technologies, only the specific sub-application needs to be updated, without refactoring the entire frontend system, significantly reducing development costs and risks. Furthermore, this application establishes a data service layer including data access processing services and application services, and stipulates that sub-applications interact with the application services through a unified gateway, creating an efficient and standardized front-end and back-end data channel. The data access processing service handles real-time processing of raw data, while the application service serves as a unified data outlet, enabling on-demand, targeted data subscription and real-time accurate push of processed target data to corresponding sub-applications. This significantly improves the real-time performance and smoothness of the display of dynamic maritime target information on the front end, reduces unnecessary server query load, and optimizes the overall system resource utilization efficiency. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of an embodiment of the marine target monitoring system based on a micro-frontend architecture, as described in this application. Figure 2 This is a schematic flowchart of an embodiment of the maritime target monitoring method based on micro-frontend architecture of this application; Figure 3 This is a schematic diagram of an embodiment of the maritime target monitoring method based on a micro-frontend architecture, as described in this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0019] Current maritime target monitoring systems generally adopt a browser / server (B / S) architecture. The back-end server connects to target data from multiple data sources such as radar, Automatic Identification System (AIS), and Beidou, processes, analyzes, and calculates target attribute information and motion trajectory information, and provides data to the front end through service interfaces for rendering and nautical chart display.

[0020] Based on actual business needs, such systems typically include multiple application modules such as target display, trajectory playback, trajectory analysis, and event alarms. However, traditional maritime target monitoring and display systems usually adopt a monolithic front-end architecture, meaning that all functional modules are developed and integrated in a single front-end project. This architecture leads to high interdependence and coupling between modules. When a function needs to be updated, the entire front-end application must be packaged, built, and released, resulting in numerous inconveniences and limitations.

[0021] Based on the analysis of the traditional monolithic front-end architecture, the following technical problems exist: (1) Outdated technology stack and difficulty in upgrading and replacing: The entire system is built on a single front-end technology stack. When it is necessary to introduce a new technology framework with better performance or to expand the functions of the existing system, it is often necessary to carry out a large-scale reconstruction of the front-end and even the overall architecture, resulting in high project costs and high risks.

[0022] (2) High module coupling, difficult to maintain: The code of different functional modules such as target display, trajectory analysis, early warning alarm is tightly coupled. Modification or update of any module can easily trigger a chain reaction and errors in other modules, resulting in poor system stability and low development and maintenance efficiency.

[0023] (3) Low team collaboration efficiency: In large and medium-sized projects, multiple front-end development teams need to work together on the same monolithic codebase, which is very easy to cause code conflicts and dependency management chaos, which seriously restricts parallel development capabilities and project delivery efficiency.

[0024] (4) Deployment dependencies are numerous and the process is complex: Even a minor modification to a single functional module requires rebuilding and deploying the entire front-end application, and simultaneously modifying a large number of related configuration items. This not only affects the efficiency of online release, but also makes it impossible to achieve independent release of a single function and the system's canary release capability.

[0025] Therefore, in order to solve the above-mentioned technical problems, this application provides a marine target monitoring system and method based on a micro-frontend architecture, which will be described in detail below.

[0026] This application provides a marine target monitoring system based on a micro-frontend architecture, such as... Figure 1 The diagram shown is a structural schematic of an embodiment of a maritime target monitoring system based on a micro-frontend architecture, as described in this application. This micro-frontend architecture-based maritime target monitoring system includes: The front-end application layer 100 includes a main application with an independent technology stack and multiple sub-applications. The main application is configured to dynamically load and render the corresponding sub-applications based on the sub-application configuration information. The data service layer 200 includes application services and data access processing services. The data access processing services are configured to access the raw target data and process and store the raw target data in real time. The application services are configured to retrieve the processed target data from the data access processing services or the persistent storage within the system and push the data to the corresponding sub-applications in real time. The sub-applications are deployed independently and configured to interact with the application service through a unified gateway to receive and display target data.

[0027] In this embodiment, the marine target monitoring system based on micro-frontend architecture (hereinafter referred to as the system) adopts an overall architecture that combines front-end and back-end separation with micro-frontend and service-oriented architecture.

[0028] The front-end application layer 100 is responsible for presenting the user interface and executing business logic.

[0029] The main application is the basic application function of the system. It does not carry specific business functions. It mainly serves as a container and scheduling center, responsible for the routing management, global state management, micro-application integration configuration, basic third-party dependency management of the entire system, and provides the application programming interface (API) for rendering and displaying the system's main interface, general user interface (UI) components, and general front-end elements.

[0030] The main application is configured to dynamically load, mount, and unmount corresponding sub-applications and render their user interfaces based on sub-application configuration information obtained from the backend. In this embodiment, when the system starts or user permissions change, the main application first loads itself and, based on the current user permissions and the obtained sub-application configuration information, matches the sub-applications that need to be activated from the sub-application configuration information, and then dynamically creates them. <script>标签或利用系统提供的加载器等技术，从子应用独立的部署地址（如一个独立的服务器或CDN）动态加载其代码仓库中的代码资源，并在页面中指定的DOM容器内执行和渲染，以实现对应的子应用的动态加载和渲染。

[0031] 其中，子应用配置信息是一组定义了子应用元数据的结构化数据，通常是一个JSON数组，每个元素描述了可用的子应用，由后端的应用服务根据当前用户权限生成，并返回给主应用。在本申请中，子应用配置信息至少包括子应用的唯一标识符（name）、子应用的独立部署入口地址（entry，通常为一个独立的JavaScript或HTML文件URL）、激活规则（activeRule，如路由路径）等，也可以根据需求定义子应用配置信息包含其他信息，这里对此不做具体限定。

[0032] 子应用是承载具体海上目标监测业务功能的微前端应用模块，是完整的、可独立运行的前端应用，每个子应用聚焦于一个特定的业务能力。每个子应用拥有自己独立的代码仓库、开发流程和构建部署流水线，可以被部署到与主应用不同的服务器或内容分发网络节点上。

[0033] 子应用被配置为被加载后，通过统一网关201与应用服务交互，以接收并展示目标数据。

[0034] 在本实施例中，子应用被设计为技术选型、依赖管理、内部状态均独立于主应用和其他子应用，即主应用与各子应用，以及各子应用之间，可以采用不同的前端框架（例如Vue、React、Angular）、不同的版本（例如Vue2与Vue3）以及不同的构建工具进行独立开发和构建，彼此间无编译时依赖。示例性的，主应用可以采用Vue、React等任一前端框架实现，而新开发的某个子应用可以采用React 18开发，也可以根据需求定义采用其他框架开发，这里对此不做具体限定。

[0035] 即在申请中主应用仅通过子应用配置信息中子应用的独立部署入口地址来引用子应用，这使得更新某个子应用时，只需部署该子应用自身的资源，主应用和其他子应用无需重新发布，实现了各个子应用的独立部署和灰度发布能力，解决了传统单体前端架构中因技术栈捆绑导致的升级替换困难，以及因模块深度耦合引发的维护复杂度高、团队协作效率低下等问题。当需要更新某个业务功能或引入新技术时，仅需针对特定子应用进行操作，无需重构整个前端系统，显著降低了开发成本与风险。

[0036] 数据服务层200，为上述前端主应用和子应用提供标准数据信息接口，是系统的业务逻辑核心，为前端应用层100提供稳定、高效、统一的数据服务。进一步的，数据服务层200划分为应用服务和数据接入处理服务。

[0037] 数据接入处理服务，是系统的数据总线入口，用于负责与各类外部数据源对接，被配置为接入原始目标数据，并对原始目标数据进行实时处理与存储。

[0038] 示例性的，数据接入处理服务通过TCP / UDP Socket、专用API接口等方式，接入来自雷达（Radar）、自动识别系统（AIS）、北斗等设备的原始目标数据。这些数据通常是未经处理的、包含目标经纬度、航速、航向、识别码等信息的原始报文。在本实施例中，数据接入处理服务不仅负责接入，还负责实时处理与存储，例如对数据进行初步解析、校验，并将其发布到消息中间件（如Kafka）中进行缓冲和分发，为后续的流式处理做好准备。其"存储”行为是暂存和中转，而非最终持久化。

[0039] 应用服务，是面向前端应用层100、提供业务能力聚合的API服务层，通常基于Spring Boot、Go等框架实现，被配置为从数据接入处理服务或系统内的持久化存储中获取处理后的目标数据，并实时将数据推送至对应的子应用。

[0040] 应用服务作为数据查询的聚合点，从所述数据接入处理服务的实时输出流中，或者从系统内的持久化存储（如关系数据库、分析型数据库、缓存等）中，获取处理后的目标数据。

[0041] 在本实施例中，子应用配置为通过统一网关与应用服务交互，以接收并展示目标数据。统一网关支持表征状态转移架构风格的超文本传输协议请求和网络套接字长连接服务。

[0042] 其中，统一网关是连接前端与后端的关键基础设施，是所有网络请求的单一入口。前端子应用与后端应用服务的所有交互，无论是主动查询还是接收推送，都通过统一网关进行。在本实施例中，统一网关对外提供两种标准化的网络协议支持，以适配前端不同类型的交互需求：表征状态转移架构风格的超文本传输协议请求：即RESTful HTTP / HTTPS API。这是前端进行主动查询、提交命令、管理操作的主要方式。例如，子应用需要查询某个区域的历史轨迹、用户修改系统配置、提交一个分析任务等，都会向统一网关发起标准的HTTP请求（GET / POST / PUT / DELETE）。网关负责将其路由到后端对应的应用服务实例。

[0043] 网络套接字长连接服务：即Web Socket协议。这是实现服务端向客户端实时推送数据的关键。当"目标展示子应用”启动时，它会通过统一网关与后端的应用服务（或专门的Web Socket服务）建立一个Web Socket连接。当应用服务从Redis等渠道获取到新的目标位置或报警信息时，便通过这条已经建立的、全双工的网络套接字长连接，将数据消息主动、即时地"推送”到前端子应用。这种方式相比前端定时轮询（Polling），极大地降低了延迟，减少了无效请求，并节省了服务器资源。

[0044] 即应用服务还作为数据推送的发起方，通过统一网关建立的Web Socket长连接，实时将目标数据推送至对应的子应用进行展示。

[0045] 示例性的，当一艘船舶的位置更新时，应用服务会立即将这个更新消息通过统一网关推送给当前正在前端运行的、负责海图展示的目标展示子应用（具体释义见下文），而不会推送给未运行或未订阅此类消息的其他子应用。

[0046] 因此，本申请通过设立包含数据接入处理服务和应用服务的数据服务层200，并规定子应用通过统一网关与应用服务交互，建立了一套高效、标准化的前后端数据通道。数据接入处理服务用于原始数据的实时处理，应用服务则作为统一的数据出口，实现了处理后的目标数据向对应子应用的按需、定向的数据订阅与实时精准推送，显著提升了海上目标动态信息在前端展示的实时性和流畅性，并减轻了服务器不必要的查询负载，优化了系统整体资源利用效率。

[0047] 在本申请的一个实施例中，主应用还被配置为通过属性传递方式向子应用提供共享组件与应用程序编程接口，并通过事件发布 / 订阅机制与子应用进行通信。

[0048] 在本实施例中，为了在主应用与子应用之间实现高效、解耦的协作，定义了一套交互机制：主应用通过配置文件暴露通用组件和API，在加载并挂载子应用时，可以通过属性（Props）参数，将一些系统级的共享资源通过属性传递方式传递给子应用，子应用在初始化时接收这些props并可在其内部直接使用。其中，系统级的共享资源至少包括：（1）共享组件：如统一的用户头像组件、公司徽标组件、日期选择器组件等，避免子应用重复实现；（2）应用程序编程接口（API）：如封装的全局用户信息获取函数、系统日志记录函数、统一的HTTP请求客户端等。

[0049] 此外，定义事件发布 / 订阅（Event Emitter）机制，实现主应用与子应用之间的事件监听与交互。具体的，系统建立了一个全局的事件发射器实例，或利用框架自带的事件总线，事件发布 / 订阅机制允许主应用和任何子应用进行松耦合通信，即无论主应用或子应用，都可以发布一个事件，并携带相关数据，任何其他应用都可以订阅感兴趣的事件。

[0050] 示例性的，主应用可以发布（emit）一个名为"map:zoom-change”的事件，并附带新的缩放级别数据；而关注地图缩放的目标展示子应用可以预先订阅（on）此事件，并在事件触发时执行回调函数来更新自身视图。反之，子应用也可以发布一个名为"alarm:triggered”的事件，由主应用或其他子应用订阅并响应。当用户在光电视频监控子应用（具体释义见下文）中切换了摄像头，它可以发布一个名为"camera:switched”事件，而"目标展示子应用”如果订阅了此事件，就可以在回调函数中获取到新的摄像头指向坐标，并自动将电子海图视角平移至该位置。这种机制避免了应用间直接的方法调用或深度耦合的状态依赖，极大地提升了系统的可维护性和可扩展性。

[0051] 在本申请的一个实施例中，子应用包括目标展示子应用、轨迹回放与分析子应用、预警报警子应用、光电视频监控子应用中的至少一种。

[0052] 海上目标监测业务复杂，功能模块多样。本系统通过微前端架构，将这些功能拆分为高内聚、松耦合的子应用。在本实施例中，子应用具体至少可包含以下类型：目标展示子引用，用于实时渲染海上目标的位置与状态信息，并支持目标信息查询和分析。目标展示子应用作为核心可视化模块。示例性的，目标展示子应用可用于负责在Web电子海图（如基于OpenLayers，Cesium，Leaflet）上，实时、动态地渲染所有监控海域内目标（船舶、浮标、平台等）的图标、航向线、尾迹。提供目标列表、详细信息面板、目标筛选与搜索等功能。

[0053] 轨迹回放与分析子应用，用于对指定海上目标的历史轨迹进行展示或回放，并支持轨迹数据的分析计算。轨迹回放与分析子应用专注于历史数据分析。示例性的，轨迹回放与分析子应用允许用户查询特定目标在历史某段时间内的航行轨迹，并控制其进行动画回放。此外，集成轨迹分析功能，如计算两点间航行时间、平均航速、航行距离，以及进行区域停留分析、疑似违规行为（如偏离航线）分析等。

[0054] 预警报警子应用，用于基于预设规则对海上目标行为进行实时分析，并在发现异常时生成报警信息。预警报警子应用作为实时风险监控模块。示例性的，预警报警子应用内置或连接预警规则引擎，对实时流入的目标数据（如位置、航速）进行研判，一旦发现目标进入禁航区、航速异常、两船碰撞风险过高等情况，立即生成报警事件。该子应用负责报警信息的可视化（弹出告警窗、声音提示）、报警列表管理及报警处置状态跟踪。

[0055] 光电视频监控子应用，用于集成并展示与目标数据相关联的实时视频监控画面，目标数据包括来自雷达和自动识别系统的数据源。光电视频监控子应用作为实现"陆海空天”一体化监控的关键模块。示例性的，当用户在海图上关注某个特定目标时，可通过此子应用，调用与目标地理位置关联的岸基光电、船载摄像头或无人机视频流，实现视频画面的实时调取与展示，做到"图上有点，屏上有像”。

[0056] 在本实施例中，用户通过主应用的导航菜单，可以动态激活上述一个或多个子应用，灵活组合成符合当前监控任务需求的专属工作台，有效提升系统整体灵活性。

[0057] 在本申请的一个实施例中，系统还包括数据存储层300，数据存储层300包括消息中间件、实时分析数据库、内存数据库和搜索引擎中的至少一种。

[0058] 为支撑海量、多源、异构的海上目标数据的高效处理与查询，本系统还包括数据存储层300，用于负责系统数据的持久化存储。在本实施例中，数据存储层300采用"多模数据库”理念，根据数据的不同特性，例如实时性、查询模式、数据量等，选用最合适的存储组件，包括但不限于：消息中间件，用于缓存实时接入的目标数据。示例性的，消息中间件可选用ApacheKafka，扮演"数据高速公路”的角色。数据接入处理服务将原始数据快速写入Kafka主题，实现了数据的缓冲、解耦和顺序保证，为后续的异步流处理提供了可靠的数据源。

[0059] 实时分析数据库，用于存储经处理后的实时目标轨迹坐标数据。示例性的，实时分析数据库可选用Star Rocks，Click House，Apache Doris。这类大规模并行处理（MPP）数据库擅长处理高速写入和海量即时分析查询，支持对当前及近期目标位置进行毫秒级的多维聚合查询。

[0060] 内存数据库，用于存储实时预警与分析结果数据。示例性的，内存数据库可选用Redis。利用其极高的读写性能，预警信息产生后存入Redis，可被应用服务和前端报警子应用近乎实时地获取，确保报警的及时性。它也常用于存储热点目标信息、用户会话等。

[0061] 搜索引擎，用于存储历史目标与轨迹数据以供查询。示例性的，搜索引擎可选用Elasticsearch。强大的全文检索和复杂聚合分析能力，使其非常适合存储历史目标与轨迹数据以供查询。用户可以通过它进行灵活的条件组合查询例如"查找过去一月内，所有进入某区域且船名为‘XX’的船舶”。

[0062] 在本实施例中，数据存储层300除了包括上述的目标相关信息存储组件Kafka、Star Rocks、Redis、Elasticsearch外，还包括存储系统通用业务数据的数据库MySql，文件数据存储SeaseedFS。还可以根据需求设置系统的数据存储层300包含其他具备存储功能的存储组件，本实施例对数据存储层300不做具体限定。

[0063] 在本申请的一个实施例中，数据接入处理服务具体被配置为通过消息中间件接收目标数据；通过实时流计算引擎对目标数据进行清洗、融合与分析计算；并将处理后的实时轨迹坐标数据写入实时分析数据库，将实时预警与分析结果数据写入内存数据库。

[0064] 在海上目标监测场景中，数据具有高并发、强实时、多类型的特点。传统单体架构常采用数据库直接写入或简单的消息队列，难以兼顾数据吞吐量、处理延迟与复杂分析需求。

[0065] 本实施例中，数据接入处理服务采用分层式实时数据处理，利用消息中间件接收目标数据，以应对数据接入的突发性和峰值压力；利用实时流计算引擎实现毫秒级延迟的数据清洗、融合与即时分析；并依据数据用途进行分类优化存储，将处理后的实时轨迹坐标数据写入实时分析数据库，将实时预警与分析结果数据写入内存数据库。确保了在海量数据涌入时数据不丢失，并为前端子应用提供了稳定、实时、精准的数据供给。

[0066] 本申请提供了一种基于微前端架构的海上目标监测方法，如图2和图3所示，为本申请实施例中基于微前端架构的海上目标监测方法的一个实施例流程示意图，该基于微前端架构的海上目标监测方法包括以下步骤：S101、主应用获取子应用配置信息，并根据子应用配置信息动态加载对应的子应用并渲染。

[0067] 在本实施例中，主应用获取子应用配置信息，具体包括：响应于用户访问，初始化主应用；主应用向统一网关发起表征状态转移架构风格的超文本传输协议请求，以获取用户权限与子应用配置信息。

[0068] 具体的，用户通过浏览器访问系统，浏览器加载并执行主应用的代码，完成主应用的初始化，此时，主应用响应于用户访问，初始化主应用容器。示例性的，主应用容器通过微前端技术qiankun实现，具体引入qiankun的npm依赖，通过统一网关Http请求应用服务端查询用户权限和系统微应用配置信息，该请求经过认证后，由后端应用服务返回当前用户有权访问的子应用列表及其配置。

[0069] 在本实施例中，根据子应用配置信息动态加载对应的子应用并渲染，包括：主应用调用微前端框架的注册方法注册子应用；主应用根据子应用配置信息，匹配并执行目标子应用的生命周期钩子函数，将目标子应用挂载至指定的文档对象模型容器。

[0070] 具体的，主应用在自定义的主项目中调用register Micro Apps方法注册子应用，并调用start方法开启，主应用获取上述信息通过前端动态脚本加载方式从独立的服务地址获取目标微前端模块代码并执行。示例性的，框架根据当前浏览器URL匹配配置中的激活规则，找到目标子应用，然后从其独立部署的地址（配置中的entry）异步加载JavaScript资源，执行子应用暴露的生命周期钩子函数，在本实施例中，可以是各子应用通过在对应配置文件中加入bootstrap、mount、unmount三个生命周期方法来实现主应用调用访问子应用，最终将其视图渲染到主应用页面指定的DOM容器中，实现动态加载对应的子应用及渲染。

[0071] S102、通过数据接入处理服务接入原始目标数据，并对原始目标数据进行实时处理与存储。

[0072] 在本实例中，通过数据接入处理服务接入原始目标数据，并对原始目标数据进行实时处理与存储，具体包括：将接入的原始目标数据推送至消息中间件；通过实时流计算引擎消费消息中间件中的数据，进行清洗、融合与计算；将计算产生的实时轨迹数据存入实时分析数据库，将预警分析结果存入内存数据库。

[0073] 在动态加载对应的子应用并渲染的同时，在系统的后端，通过数据接入处理服务接入原始目标数据，该服务作为常驻进程，从雷达、AIS等设备接口持续读取数据报文。并对原始目标数据进行实时处理与存储，包括对数据进行解析、校验，并发布到消息中间件Kafka的消息队列，由实时流计算引擎Flink流计算作业进行后续的清洗、融合、分析计算，并将结果写入实时分析数据库StarRocks和内存数据库Redis。

[0074] S103、通过应用服务从数据接入处理服务或系统内的持久化存储中获取处理后的目标数据，并实时将数据推送至对应的子应用。

[0075] 在本实施例中，通过应用服务从数据接入处理服务或系统内的持久化存储中获取处理后的目标数据，应用服务扮演数据聚合和分发的角色。对于实时数据，它可以监听实时流计算引擎Flink的输出或内存数据库Redis的频道；对于历史数据，它查询实时分析数据库StarRocks或搜索引擎Elasticsearch。并实时将数据推送至对应的子应用，对于需要实时更新的子应用，例如，目标展示子应用，应用服务通过已建立的WebSocket连接，将数据消息推送给它们；对于响应查询请求的子应用，则以HTTP响应形式返回数据。

[0076] S104、子应用通过统一网关与应用服务交互，接收并展示目标数据。

[0077] 在前端，子应用通过统一网关与应用服务交互，无论是发送HTTP查询请求还是接收WebSocket推送消息，都经由统一网关。最终，子应用接收并提取数据并局部更新UI，以完成各自模块前端渲染，实现海上目标位置的运动轨迹平滑移动和信息监控展示。示例性的，将目标位置绘制到海图上，将报警信息显示在列表中，实现对整个监控海域态势的实时、动态感知。

[0078] 本申请通过该基于微前端架构的海上目标监测方法，完成海上目标数据的获取、分析、展示监测，将以往前端展示方式由整体消息推送和查询，改进为各个模块和后台服务数据的单点交互查询和信息推送；能根据需求可动态调整不同展示模块，可更有针对性的进行数据查询和分析计算，提升查询交互效率，优化系统资源利用。

[0079] 以上对本申请实施例所提供的一种基于微前端架构的海上目标监测系统及方法进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。< / script>

Claims

1. A marine target monitoring system based on a micro-frontend architecture, characterized in that, include: The front-end application layer includes a main application with an independent technology stack and multiple sub-applications. The main application is configured to dynamically load and render the corresponding sub-applications based on the sub-application configuration information. The data service layer includes application services and data access processing services. The data access processing services are configured to access raw target data and process and store the raw target data in real time. The application service is configured to retrieve processed target data from the data access processing service or persistent storage within the system, and push the data to the corresponding sub-application in real time. The sub-application is deployed independently and configured to interact with the application service through a unified gateway to receive and display the target data.

2. The marine target monitoring system based on a micro-frontend architecture as described in claim 1, characterized in that, The main application is also configured to provide shared components and application programming interfaces to the sub-applications via attribute passing, and to communicate with the sub-applications via an event publish / subscribe mechanism.

3. The marine target monitoring system based on a micro-frontend architecture as described in claim 1, characterized in that, The sub-applications include at least one of the following: target display sub-application, trajectory playback and analysis sub-application, early warning and alarm sub-application, and photoelectric video surveillance sub-application.

4. The marine target monitoring system based on a micro-frontend architecture as described in claim 1, characterized in that, The system also includes a data storage layer, which includes at least one of message middleware, real-time analytics database, in-memory database, and search engine.

5. A marine target monitoring system based on a micro-frontend architecture as described in claim 4, characterized in that, The data access and processing service is specifically configured to receive target data through the message middleware; clean, fuse, and analyze the target data through a real-time stream computing engine; write the processed real-time trajectory coordinate data into the real-time analysis database; and write the real-time early warning and analysis result data into the memory database.

6. A marine target monitoring system based on a micro-frontend architecture as described in claim 5, characterized in that, The unified gateway supports Hypertext Transfer Protocol Requests and long-lived network socket connections, which represent a state transition architecture style.

7. A method for monitoring maritime targets based on a micro-frontend architecture, characterized in that, include: The main application obtains the sub-application configuration information and dynamically loads and renders the corresponding sub-application based on the sub-application configuration information; The original target data is accessed through a data access processing service, and the original target data is processed and stored in real time. The application service retrieves the processed target data from the data access processing service or the persistent storage within the system, and pushes the data to the corresponding sub-application in real time. The sub-application interacts with the application service through a unified gateway to receive and display the target data.

8. The method for monitoring maritime targets based on a micro-frontend architecture as described in claim 7, characterized in that, The step of dynamically loading and rendering the corresponding sub-application based on the sub-application configuration information includes: The main application calls the registration method of the micro-frontend framework to register the sub-application; The main application matches and executes the lifecycle hook function of the target sub-application based on the sub-application configuration information, and mounts the target sub-application to the specified document object model container.

9. The maritime target monitoring method based on a micro-frontend architecture as described in claim 8, characterized in that, The step of accessing the original target data through a data access processing service and processing and storing the original target data in real time includes: Push the raw target data to the message middleware; The real-time stream computing engine consumes data from the message middleware and performs cleaning, fusion, and computation. The calculated real-time trajectory data is stored in a real-time analysis database, and the early warning analysis results are stored in an in-memory database.

10. The maritime target monitoring method based on a micro-frontend architecture as described in claim 7, characterized in that, The main application obtains the sub-application configuration information, including: In response to user access, initialize the main application; The main application initiates a Hypertext Transfer Protocol request to the unified gateway, representing a state transition architecture style, to obtain user permissions and the sub-application configuration information.

Images