利用低代码和容器化技术的继电保护远程维护主站灵活扩展与部署架构 施泽兵（Zebing Shi） 高宏辉（Honghui Gao） 陈晓亮（Xiaoliang Chen） 于江（Jiang Yu） 刁阳（Yang Diao） 赵泽（Ze Zhao）

《Energies》：Flexible Expansion and Deployment Architecture for Relay Protection Remote Maintenance Master Station Using Low-Code and Containerization Technologies Zebing Shi, Honghui Gao, Xiaoliang Chen, Jiang Yu, Yang Diao and Ze Zhao

　　摘要 传统的继电保护远程维护主站由于采用单体架构，存在耦合紧密、可扩展性有限以及部署繁琐的问题。本文提出了一种集成低代码和容器化技术的灵活扩展系统。主要创新点包括：（1）一个针对特定领域的低代码组件库，其中核心功能被硬编码以实现高性能；（2）一个将低代码开发与容器化部署连接起来的协作式持续集成/持续交付（CI/CD）流程。该系统采用了四层解耦架构。在省级电网中的工程应用表明，该系统能够支持超过20万台并发设备，运行效率提高了60%，手动配置工作量减少了60%，并且核心服务的可用性达到了99.99%。这项研究为在新电力系统范式下构建可扩展和敏捷的智能维护系统提供了系统化的解决方案。

1. 引言
随着新型电力系统建设的不断推进，继电保护设备的规模和种类呈爆炸性增长。这对运维主站系统的功能可扩展性、部署灵活性以及多场景适应性提出了前所未有的挑战。目前，传统的继电保护远程运维主站通常面临三个核心瓶颈：耦合紧密的架构、僵化的部署模型以及低效的业务定制[1,2]。具体来说，系统功能与底层平台的深度集成使得升级和改造变得困难且风险较高；集中式部署方案难以适应多电压等级和多供应商设备的多样化需求，流程繁琐；同时，功能定制严重依赖专业开发人员，无法快速响应现场运维的个性化需求，严重阻碍了智能运维系统的有效实施。

在技术进化层面，低代码技术通过可视化编排和基于组件的重用为降低开发门槛和赋能业务人员自主创新提供了可能性[3]；容器化技术通过应用程序和运行时环境的集成封装，确保了跨平台的部署一致性和弹性资源扩展[4]。尽管两者在各自领域都取得了显著进展，但现有研究和实践仍存在明显差距。在继电保护运维领域，低代码技术缺乏针对特定场景的组件库和定制工具，其应用仍处于探索阶段[5,6,7]；容器化技术也主要局限于后端服务的孤立封装[8,9]，未能与上层应用的快速定制能力形成深度协同。实际上，当前的研究主要集中在继电保护运维的特定方面的效率提升上，例如基于广域信息的实时评估[10]和故障记录的自动分析[11]。虽然在事故分析效率和范围上取得了进展，但诸如功能扩展的僵化和部署模式的固化等根本性问题尚未在系统架构层面得到解决。因此，以下关键研究问题依然存在：如何将低代码的敏捷开发能力与容器化的灵活部署优势系统地结合，构建一个支持快速迭代、按需部署和弹性扩展的运维主站系统？现有文献缺乏综合的架构设计、关键技术以及实证研究来回答这个问题。

低代码技术在电力系统相关场景中展现了显著的价值。例如，在热电厂数据采集平台的开发中，基于低代码概念的架构设计实现了实时数据采集和高效处理[12]。在电网仿真分析平台的构建中，低代码的可视化拖放和组件重用功能显著缩短了开发周期[13]。容器化与微服务分解的结合有效解决了电力系统多源数据采集场景中的异构数据访问和弹性扩展问题[14]，为继电保护运维主站的架构优化提供了宝贵见解。此外，低代码平台在电力检查与调度[15,16]、电网调度脚本编辑[17]、需求侧控制[18]和异常检测[19]等场景中的应用验证了它们在提升业务定制效率和降低开发门槛方面的可行性。然而，现有研究尚未形成一种系统化的解决方案，专门针对继电保护运维的专业场景深度整合低代码和容器化技术。值得注意的是，缺乏针对继电保护业务需求定制的专用组件库和协作部署机制。然而，上述研究存在两个根本性限制。首先，低代码和容器化技术的应用彼此孤立——低代码平台侧重于业务逻辑的快速编排，而容器化则服务于后端服务的部署隔离。从可视化开发到生产操作的端到端协作闭环尚未实现。其次，现有工作均未构建一个针对继电保护特定领域特性的专用组件抽象层（例如，深入解析IEC 61850标准、高效处理故障记录文件以及跨多供应商设备的设置组统一管理）。因此，通用低代码平台无法直接适应继电保护运维场景。因此，如何构建一个针对继电保护领域的低代码组件库，并实现低代码开发与容器化部署之间的协作治理，仍然是一个未解决的关键挑战。

鉴于此，本研究旨在突破传统运维主站的固有局限性。本研究的主要创新如下：
（1）针对继电保护的特定领域低代码组件库：与通用低代码平台不同，我们提出了一种结合“硬编码核心功能+低代码外围功能”的组件构建方法。核心算法（如故障分析和设置计算）被硬编码以实现高性能，而外围功能则采用低代码实现灵活性。该库涵盖了数据访问、业务逻辑和可视化展示等核心场景。
（2）低代码与容器化之间的协作部署机制：超越简单的微服务打包，我们设计了一个端到端的CI/CD流程，包括统一的配置权限管理和中心辐射式的双层镜像仓库架构。这建立了从可视化编排到生产操作的闭环，特别解决了电网调度的跨区域和高隔离特性问题。
（3）针对容器化环境的多维度可靠冗余设计：我们系统地实施了涵盖应用、数据、网络和弹性容量层的高可用性机制，包括针对电网运行场景的服务降级和断路器策略，以确保在极端压力下的核心业务连续性。

本文的其余部分安排如下。第2节介绍了理论和技术基础，包括低代码和容器化的核心组件以及继电保护运维的特定特性。第3节（材料与方法）描述了系统设计原则、四层解耦架构以及关键技术实现，包括专业低代码组件库、微服务容器化策略、协作式CI/CD流程和高可用性设计。第4节（结果）报告了实验设置、功能验证、性能测试和工程应用结果。第5节（讨论）解读了研究结果，讨论了安全性问题、设置组调整和自动功能分析，并讨论了局限性。第6节（结论）总结了主要贡献和获得的结果。

2. 理论和技术基础
要构建一个“低代码定制-容器化部署”的灵活运维系统，需要整合三项关键技术：快速应用程序开发、敏捷资源交付和深度行业适应。低代码技术是提高业务功能定制效率并响应现场个性化需求的核心；容器化技术为功能模块提供了标准化交付和运维的基础，确保环境的一致性和弹性扩展，而继电保护运维业务的固有特性则是整合前两项技术时必须遵循的约束条件和设计基础。以下部分将详细阐述这三个方面。

2.1. 低代码技术的核心组件
低代码技术的核心在于通过“可视化开发和基于组件的重用”实现应用程序的快速迭代[20]。其技术支持主要依赖于几个关键组件：可视化编排引擎允许用户通过拖放配置来配置业务流程和规则，底层引擎自动生成可执行代码，从而大幅减少编码需求。这与电力系统脚本编辑场景中的方法一致，其中可视化流程图生成代码[16]。定制报告和仪表板工具集成了多种可视化组件，使用户能够直观选择数据源并配置WYSIWYG报告的显示维度。类似的功能已在电网仿真分析平台中得到有效应用。此外，内置的规则引擎允许用户使用接近自然语言的语法配置复杂的业务逻辑（例如，“当设备温度超过阈值并持续特定时间时触发警报”）。基于插件的扩展机制确保了第三方功能模块的快速集成和通过标准化接口的无缝平台连接。这一特性在扩展电力检查与调度平台的功能方面发挥了关键作用[17]。

2.2. 容器化技术的核心组件
容器化技术通过将应用程序及其完整依赖环境打包，实现了“一次构建，多环境一致运行”的目标。该技术栈基于容器引擎（如Docker），它们创建轻量级镜像以确保跨环境的一致性。在生产部署中，容器编排平台（如Kubernetes）负责容器调度、弹性扩展和故障恢复，是动态资源管理的关键。这种架构已被证明在支持电力系统多源数据采集平台的大规模数据访问场景中有效[14]。在此基础上，服务网格（如Istio）有效管理容器之间的通信，提供了服务发现、流量控制和断路等功能，增强了微服务架构的可靠性。此外，镜像注册表（如Harbor）提供了版本化镜像存储和安全扫描的集中支持，而网络插件（如Calico）确保了稳定高效的跨节点容器通信。这些组件共同构成了容器化部署和操作的完整生态系统。

2.3. 继电保护运维主站的业务特性
继电保护运维主站的运行场景具有电力行业特有的特性和高要求。首先，系统需要极高的可靠性。故障监控和报警通知等功能必须具备冗余备份和快速自我修复能力，以确保电网的安全稳定运行。这与热电厂数据采集平台对实时和稳定数据传输的要求一致[12]。同时，系统必须保持低响应延迟以满足实时运行需求。其次，运行场景表现出显著的复杂性和异构性。主站必须适应从110 kV到1000 kV的各种电压等级的多样化运行需求，以及来自不同制造商的设备，同时还需兼容多种电力通信协议。在电力系统数据采集场景中，处理多源异构数据的类似挑战已被广泛解决。最后，处理的数据是多源和异构的，包括结构化数据（如设备记录和设置值）、半结构化配置文件（如SCD/CID）以及非结构化数据（如故障记录文件和大量事件日志）。这对数据访问、处理和集成提出了综合挑战，这与低代码平台处理电力系统中多种数据类型的需求相符。

3. 材料与方法
3.1. 系统设计原则及其架构映射
系统设计遵循五个核心原则，以确保其先进性、实用性和可靠性。低耦合和高内聚是架构的基石，要求功能模块作为微服务独立封装并通过RESTful API等标准化接口进行通信，从而减少模块之间的直接依赖。这一原则在电力系统的微服务架构设计中已被证明有效[17]。灵活扩展是核心目标，旨在通过低代码平台支持功能的快速可视化定制，并依靠容器化技术实现计算资源的弹性扩展，从而灵活适应设备规模的增长和业务需求的变化。类似的方法已应用于热电厂的数据采集平台和电网仿真分析平台。高可靠性冗余是安全基线，要求核心组件以主动-备用配置部署，并自动故障转移和关键数据的多副本存储，以消除单点故障风险。这与电力系统中数据传输和存储可靠性的严格要求一致。标准化兼容性是实施的保障。系统必须遵守行业标准和规范（例如南方电网的“继电保护主站系统标准服务技术规范”），并与主流设备通信协议（如IEC 61850和MMS）兼容，以确保与现有环境的顺利集成。这是成功实施电力系统技术的关键前提。最后，整个系统都维护了安全性和可控性，通过用户级权限控制、全链操作审计追踪和容器镜像安全扫描等全面的安全保障措施来确保运营和系统的安全。在电力行业的低代码平台应用中也强调了类似的安全机制[20]。数据中间平台负责清理、整合和面向服务的发布多源异构数据。类似的基于微服务的综合数据管理平台已在电力调度中成功实施[17]。

3.2. 四层解耦架构
基于上述原则，构建了一个“基础设施层-平台服务层-应用层-用户层”的四层架构，如图1所示。该架构旨在系统地支持“低代码、定制化、容器化、部署灵活扩展”的整个过程。

图1. 继电保护远程维护主站的架构。
基础设施层作为基础支持，提供弹性的硬件和网络资源。计算资源包括物理服务器和云服务器集群，为容器操作提供可扩展的CPU和内存能力。存储资源采用混合架构，使用关系数据库（例如MySQL V8.4）存储结构化数据（如设备记录），时间序列数据库（例如InfluxDB V3.8）存储实时监控数据，以及分布式文件系统（例如HDFS V3.4）存储非结构化数据（如故障记录）。网络资源利用Calico网络插件实现容器之间的高效通信，并通过负载均衡器和网络策略确保流量分配和安全隔离。

平台服务层是系统的核心技术核心，集成了两个关键能力：低代码开发和容器化操作。低代码平台的核心服务（如可视化编排、规则引擎和报告服务）为业务功能的快速定制提供了工具支持。容器化管理服务（如镜像仓库集成、基于Kubernetes的编排、服务发现和配置中心）实现了微服务应用整个生命周期的自动化管理。其中，容器化版本控制采用了“镜像仓库-容器集群-版本仪表板”的三方架构，形成了覆盖整个版本生命周期的可视化“战略地图”，支持全局可见性、一键定位和集成治理。此外，公共支持服务（包括统一身份认证、基于RBAC的权限控制、日志审计等）为上层应用提供了安全可靠的一般技术支持。在跨安全区访问方面，通过部署链接数据代理和隔离通信模块，在弱安全区配置下实现了Zone 1和Zone 3之间的安全数据交换，目前支持103协议，并与61850变电站访问兼容。

应用层直接承载具体的运营和维护业务功能。核心运营和维护应用模块（如设备监控、故障分析和设置验证）作为独立的APP存在，通过低代码平台开发并封装在容器中。扩展应用模块通过统一的应用商店进行管理和分发，支持第三方开发的个性化功能插件的集成。这一层还构建了一个数据中间平台，负责清理、整合和面向服务的发布多源异构数据，为所有上层应用提供一致可靠的数据服务。

用户层是系统与各种用户之间的交互界面。根据RBAC模型，这一层根据不同角色的职责提供不同的操作权限和功能视图（如维护人员、调度员和系统管理员）。在访问终端方面，它与PC浏览器和移动APP完全兼容，以满足现场和远程的多样化办公需求。用户主要通过三个入口点与系统交互：用于独立功能开发的低代码定制界面、用于获取和更新应用的应用商店，以及用于系统监控和配置管理的运营和维护管理后端。

3.3. 继电保护专业低代码组件库的构建
为了实现电力运营和维护人员的快速功能定制，构建一个针对保护业务场景的专业低代码组件库至关重要。本文提出了一种结合“核心硬编码功能+外围低代码功能”的组件构建方法，主要基于以下考虑：
(1) 性能和效率要求：核心功能（如故障分析、设置计算和实时数据处理）需要极高的计算性能和响应效率。硬编码的实现可以充分利用编译优化和底层资源调度能力，确保毫秒级的响应速度和高吞吐量处理。
(2) 专业性和复杂性：继电保护业务逻辑高度专业化，算法复杂，通常涉及与底层设备和专有协议的深度交互。传统的编码方法更有利于实现细粒度控制、异常处理和长期维护。
(3) 稳定性和安全可靠性：核心功能往往是系统的关键路径，其稳定运行直接影响电网安全。硬编码便于进行静态代码分析、安全审计和版本固化，符合电力系统对高可靠性和安全合规性的严格要求。
(4) 数据访问和处理深度：核心功能通常直接处理原始消息、记录文件和实时流数据，需要保留完整的数据属性和处理链。硬编码更有利于实现深度解析、实时过滤和高精度计算。

基于上述原则，组件库构建过程包括以下关键步骤：

3.3.1. 功能解耦和模块化分割
首先，将继电保护主站的各项功能解耦并仔细分割。以前端访问功能为例，它可以被划分为前端配置、链接通信、数据传输和接收、数据解析和处理以及数据转发等子功能模块。每个子功能进一步细分为更细粒度的服务接口。例如，链接通信可以划分为建立连接、初始化、断开连接、维护连接、通道主备管理和通道监控等接口服务，从而形成层次化且单一职责的功能单元。

3.3.2. 组件封装和分类
我们将功能相关的模块、子功能和服务接口整合为统一的功能组件，并根据业务场景将其分为四种主要类型：
(1) 数据访问组件：封装IEC 61850和MMS等电力标准的通信和解析逻辑，支持多供应商设备的快速适应和数据收集；
(2) 业务功能组件：通过硬编码实现核心算法，如故障分析、设置验证和远程配置，以确保处理效率和可靠性；
(3) 可视化组件：提供设备拓扑、波形记录和数据仪表板等图形显示模块，使业务人员能够灵活配置和拖放生成；
(4) 逻辑配置组件：通过规则引擎和流程编排支持报警规则、业务工作流等逻辑的可视化配置。

3.3.3. 标准化接口设计和发布
每个组件都提供标准化的、文档化的RESTful API接口，使用JSON作为统一的数据交换格式。接口清晰定义了请求/响应结构、参数描述和调用示例。组件接口通过统一平台发布和管理，并附有详细的用户手册和示例，以支持低代码开发人员高效调用和集成。

3.3.4. 通用框架组件支持
为了提高组件重用性和开发效率，为常见业务流程提供了通用框架组件。例如，对于不同协议下的前端访问，可以提供一个通用的“前端访问框架组件”，封装连接建立、数据传输/接收、解析和转发等常见流程。这使开发人员只需关注特定协议的解析和其他差异化方面，大大减少了冗余的开发工作。

通过上述构建方法和组件分类及协作机制（如图2所示），用户可以通过可视化界面拖放组件来配置业务流程。系统自动生成应用程序代码并将其打包成Docker镜像，实现了从逻辑编排到容器化部署的无缝集成。组件通过轻量级的RESTful API进行通信，其交互延迟可以表示为固定开销和业务处理延迟的总和。在优化的容器网络环境中，这确保了稳定的和可预测的性能，从而支持整个系统的效率和可靠性。

3.4. 微服务容器化、分割和打包
为了实现系统的灵活扩展，需要对传统的单体主站进行合理的微服务分割和高效的容器化打包。该系统采用领域驱动设计（DDD）方法，并结合电力运营和维护业务的特性，实现了“业务领域主导和数据分片辅助”的双重分割机制。
首先，服务分区基于业务领域。我们将系统的核心能力解耦为独立的服务，如数据收集、设备管理、故障诊断和设置值管理，确保每个服务的高内聚性和明确的职责。在此基础上，对于涉及广泛设备访问和数据处理的继电保护运营和维护场景，进一步按变电站或电压级别进行逻辑数据分片，使每个微服务实例专注于处理特定的数据片段。这实现了分散的计算负载并提高了系统的整体吞吐能力。

根据上述分割原则，继电保护、智能运营和维护主站的核心功能被分解为数十个微服务容器。这些容器根据电网安全区域（如生产控制区I和信息管理区III）和平台层进行部署，具体示例见表1。这些容器采用主动-备用和多副本配置等多种编排策略，以满足不同业务组件的可靠性要求。

表1. 主站核心功能级编排策略的容器。

完成微服务分解和部署规划后，实现标准化和可维护的容器化打包变得至关重要。为此，系统设计了一个五层镜像构建模板，以确保从基础环境到业务应用的一致性和安全性：
(1) 基础操作系统层
该层采用特定于电网的加固操作系统镜像。它集成了符合电力安全规定的内核组件、文件系统加固模块和必要的系统工具。其更新频率较低（通常每年1-2次），确保基础环境的长期稳定性和安全合规性。
(2) 运行时环境层
在操作系统层之上，可以部署统一定制的运行时环境，如Java 17或Python 3.12环境。该层预配置了电网所需的安全策略、证书仓库和性能调优参数，支持根据开发和运营需求进行动态更新。
(3) 辅助运营和维护通用库层
该层封装了继电保护运营和维护中的通用软件资产，包括通信协议库（如IEC 61850和104规范）、标准化数据模型、统一身份认证和安全审计组件。该层每季度进行迭代更新，以确保通用功能的持续优化和漏洞修复。
(4) 具体业务功能层
该层承载实际的业务逻辑镜像，如保护策略计算、故障记录分析、远程控制等功能模块。该层更新频率更高，可以根据业务需求迭代发布新版本，支持快速功能部署和金丝雀发布。
(5) 本地配置层（动态注入）
为了适应不同现场环境的差异化配置，系统不将配置硬编码到镜像中。相反，它在容器运行时通过Kubernetes ConfigMap或Secret动态注入配置。这种方法将镜像与配置分离，确保相同的业务镜像可以在不同地区和环境部署，同时满足电网的安全分区配置要求。

在运行时层面，一系列标准确保了容器集群的稳定性和可观测性。所有业务容器都基于Alpine Linux，设置明确的CPU和内存资源配额，以防止异常服务耗尽集群资源。每个容器集成了Liveness和Readiness健康探针，使Kubernetes能够实时监控服务状态并实现故障自修复。日志输出遵循统一的规范，并利用ELK（Elasticsearch、Logstash、Kibana）堆栈进行集中收集、存储和分析，支持操作监控和故障追踪。这种容器化打包、操作和维护系统实现了标准化交付、弹性调度以及继电保护业务应用的高效操作和维护，为构建高度可靠且可灵活扩展的智能操作和维护主站奠定了坚实的基础。

3.5. 低代码和容器化协作部署机制
3.5.1. 核心业务流程
该系统支持从功能定制到部署和运行的完整闭环流程。
功能定制流程：用户在低代码平台的可视化界面中拖放专业组件（例如数据采集组件）并配置参数和业务逻辑。该平台随后自动生成应用程序代码并构建容器镜像，经过安全扫描后发布到应用商店。
部署流程：用户从应用商店发起部署。容器编排平台自动调度资源、拉取镜像、部署实例并将它们注册到服务中心，使应用程序能够快速访问数据和服务并完成启动。
扩展和升级流程：当需要功能迭代时，低代码平台生成新版本镜像，并通过应用商店推送更新。容器编排平台通过滚动升级逐步替换旧版本，支持在出现异常时进行灰度发布和回滚，以确保业务连续性和升级顺利进行。

3.5.2. 自动化CI/CD管道
基于上述闭环流程，建立了端到端的自动化持续集成和持续部署（CI/CD）管道。当用户在低代码平台上完成应用定制后，系统会自动将生成的代码和配置提交到Git仓库，触发完整的自动化流程。
低代码开发与容器化部署之间的高效协作是打破业务定制与生产操作和维护之间障碍的关键，实现敏捷交付。该系统建立了端到端的自动化持续集成和部署（CI/CD）管道，深度整合了统一的配置权限治理和电网特定的升级控制，实现了从可视化编排到稳定运行的闭环。
首先，我们建立了自动化CI/CD管道作为协作的技术核心。其工作流程如图3所示：当用户在低代码平台上完成应用定制后，系统会自动将生成的代码和配置提交到Git仓库，触发完整的自动化流程。持续集成工具自动执行代码编译、单元测试和安全扫描，并根据第3.2节描述的五层标准化模板构建Docker镜像。通过安全漏洞扫描后，镜像被推送到私有镜像仓库（如Harbor）。容器编排平台（Kubernetes）持续监控仓库中的变化。一旦检测到应用镜像更新，它会自动触发滚动升级或蓝绿部署策略，以实现不间断的服务更新。这种自动化闭环系统将传统的迭代周期从“几周”压缩到“几小时”，显著提高了特性交付的敏捷性。根据实验环境的测量结果，CI/CD管道实现了以下平均性能：代码构建目标为2.3分钟（包括单元测试和漏洞扫描），镜像推送到Harbor注册库需要0.5分钟，滚动更新（1到10个副本）需要1.2分钟，从提交到生产部署的完整周期不到5分钟。这些指标相比传统的手动部署（每次迭代通常需要2-4小时）减少了90%。

其次，建立了统一的配置和权限管理系统作为协作安全和治理的基础。该系统基于Nacos构建了一个统一配置中心，集中管理低代码应用的业务参数和容器的运行时环境配置，支持动态分发和实时有效性，有效解决了多环境配置一致性问题。在权限控制方面，设计了“用户-角色-应用-容器资源”链接的四层RBAC模型，确保业务用户在界面上的操作权限能够准确映射和控制，因为底层容器和微服务的访问，实现了统一管理和闭环权限逻辑。所有配置更改、镜像发布和部署操作都得到全面记录和审计，全面满足了电力系统对操作可追溯性和安全可控性的严格要求。

最后，针对电网调度操作的跨区域和高度隔离特性，设计了一种分层控制和协作升级机制。这种机制是在电力生产场景下对前述通用CI/CD过程的关键扩展。系统采用“枢纽-辐射”式的两级镜像仓库架构：中央仓库统一分发基线镜像和升级策略，确保版本权威性和一致性；本地仓库在网络隔离环境中提供缓存，保证升级期间的高可用性和效率。升级过程遵循“级联升级”模型，支持主调度、中间调度和本地调度之间的三级协作控制（架构如图4所示）。上层节点可以协调整个网络的升级顺序和时间窗口，而下层节点在接收到指令后自动执行，实现强大的可控性、高可靠性和网络中版本的精确有序进展。这与电力生产系统的层次化调度和管理模型完美契合。

通过上述三层机制的有机整合，该系统不仅实现了开发和操作之间的横向协作，还实现了通用技术能力与电力行业特殊要求的纵向整合。它建立了支持继电保护操作和维护主站持续、安全和敏捷演进的部署能力。

3.6. 高可用性和弹性设计，确保电网运行的可靠性
为了满足继电保护操作和维护对系统连续性的严格要求，并确保基于低代码定制和容器化部署的灵活系统在电网生产环境中的稳定运行，本研究从架构层面系统地设计了一种多层次的高可用性和弹性机制。该设计涵盖了应用部署、数据存储和网络通信的所有方面，旨在实现极端情况下的快速故障自愈和核心业务保障。
在应用服务层，高可用性与容器编排平台（Kubernetes）的能力深度集成。所有核心微服务都以多副本（无状态）或主备（有状态）模式进行部署（部署策略详见第4.2节）。Kubernetes和StatefulSet控制器的部署，结合容器内置的活跃性和就绪性探针，能够在几秒钟内自动检测、隔离和重建实例级故障。通过设置PodDisruptionBudget等策略，可以在集群维护或节点故障期间保持指定数量的服务实例可用，从而实现无缝故障转移和零停机时间的操作和维护。
在数据持久化层，根据数据类型和访问特性采用了差异化的冗余策略。关键业务数据（如设备记录和保护设置）通过主从复制或关系数据库（如MySQL）的集群架构实现高可用性。大量实时监控数据和时间序列数据（存储在InfluxDB中）利用副本集机制。对于非结构化数据（如故障记录文件），在分布式文件系统（如HDFS）中进行多副本存储，确保数据可靠性和持久性。此外，定期快照和跨可用性区域的数据备份策略为数据恢复提供了额外的保障。
在网络通信层，高可用性设计体现在服务间通信和外部访问上。在容器集群内部，通过Calico等网络插件实现Pod间的多路径通信，并结合Kubernetes服务进行负载均衡和故障转移。在外部访问层面，部署了冗余负载均衡器和双活性API网关，以及智能DNS或浮动IP机制，以确保外部请求入口点的高可用性。
在弹性容量和过载保护层，系统引入了服务降级和断路器机制，这些机制对于处理突然的流量激增或局部故障以及确保系统的整体韧性至关重要。当监控系统检测到服务的响应时间超过标准或错误率上升时，断路器会自动切断部分对服务的调用，以防止故障传播。类似的智能异常检测模型已在低代码平台[20]中进行研究。当整体系统资源紧张时，可以根据预定义的业务优先级策略自动触发服务降级。例如，暂时限制或禁用非核心的、资源密集型功能（如深度历史数据查询和大规模报告生成），优先考虑直接影响电网安全的核心业务流（如实时数据收集、故障警报和远程控制）。这种“有损服务”设计理念确保系统在极端压力下仍能保持最关键操作能力的连续性，实现从“全功能服务”到“核心服务保障”的稳定降级。

总之，通过应用、数据、网络和弹性容量四个维度的协作设计，该架构构建了一个具有分层防御的高可用性框架。这不仅满足了继电保护操作和维护场景中99.999%的高可用性目标，而且通过智能弹性策略赋予系统应对不确定影响的韧性和适应性，为灵活可扩展的操作和维护主站提供了坚实的可靠性基础。

3.7. 信息安全考虑
所提出的系统在多个安全区域运行，包括生产控制区I和信息管理区III，通信渠道属于不同的所有者，如变电站、调度中心和第三方网络。蓄意的网络攻击，特别是数据替换攻击，存在重大风险，因为破坏主站可能会使大范围的继电保护设备失效。为应对这些挑战，系统实施了多层安全架构。
首先，强制实施端到端消息认证。所有IEC 61850 MMS和103/104消息在传输前都在网关使用HMAC-SHA256进行签名。接收端验证每条消息的完整性和真实性，因此未经正确加密密钥的数据替换会被检测并拒绝。
其次，在编排层部署了轻量级行为模型的数据篡改异常检测。该模型基于电流、电压和断路器状态等遥测值的历史统计分布。当传入数据超出预定义阈值时（例如，突然的变化与物理限制或历史模式不一致），会发出警报，并将可疑数据隔离以便人工审查。
第三，使用Calico网络策略应用网络分段和微分段，强制容器之间的低权限通信。即使单个容器被破坏，也能通过明确的允许或拒绝规则限制其向其他容器或服务的横向移动。
第四，采用不可变的容器镜像和运行时完整性监控。所有容器镜像在部署前都经过签名和验证。在运行时，部署Falco来监控文件系统完整性、进程执行和网络连接，对任何异常行为发出警报。
第五，对于跨越组织边界的通道（例如不同电网公司或第三方维护提供商之间），强制实施安全的多方通信。要求使用TLS 1.3进行相互认证，并且应用层序列号和时间戳防止重放攻击。
这些措施共同确保数据替换能够实时检测到，防止大范围继电保护设备的大规模失效。在模拟的中间人攻击中，进行了1000次注入尝试，所有被篡改的数据包要么因HMAC失败而被拒绝，要么因行为偏差而被标记为异常，没有误报。

3.8. 保护设置组调整和维护工作执行
系统支持根据电力系统运行模式的变化（如正常运行、维护或故障后恢复）更改保护设备设置组。这在两个层面进行。
对于自动组切换，主站从SCADA或EMS接收实时拓扑和流量数据。当检测到预定义条件（例如线路故障、发电机跳闸或母线分离）时，系统自动选择适当的组，例如正常运行的组1、维护的组2或源条件较差的组3。然后通过MMS向继电保护设备发出SelectActiveSG命令。变更记录会附带时间戳、操作员ID（或系统触发器）以及设备信息。系统还支持手动回滚到之前的配置组。通过低代码规则引擎进行手动调整时，操作员可以使用可视化规则引擎配置条件规则，例如，规定如果负载电流连续十分钟超过额定值的80%，系统应切换到第三组。这些规则会被编译成微服务，在条件满足时执行相应的命令。这使得非程序员也能够定义复杂的、特定于现场的切换逻辑。

继电保护设备的维护工作根据任务性质分为三个级别：
- **第1级：远程监控与诊断**：不涉及物理或配置更改；包括查看设备自检报告、故障记录、波形图以及实时状态监控，需要读写权限。
- **第2级：远程配置与测试**：可以在不进行物理干预的情况下修改参数并进行功能测试；例如调整设置组、执行在线设置验证以及模拟故障测试（如跳闸测试）。此级别需要双因素认证和操作审计。
- **第3级：现场维护**：包括硬件维修、固件升级或物理检查；例如更换故障卡、升级固件或检查CT或VT连接；此级别需要结合工作订单系统、移动应用验证以及现场签字确认。系统会自动生成详细的工作订单，其中包含设备位置（变电站、间隔或面板）、所需工具、安全程序和预计耗时等信息。现场工程师通过移动应用接收工作订单，用照片记录每一步操作，并在主管批准后完成订单。所有远程命令和现场操作都会被记录在防篡改的审计追踪中。

**3.9 继电保护设备正确功能的自动分析**
系统实现了故障后正确功能分析（PFA）模块，用于在电力系统实际发生扰动后自动评估继电保护设备的运行情况。该模块作为Kubernetes作业形式的容器化微服务在后台运行，不会干扰实时数据采集或控制功能。当SCADA系统记录到故障事件（如过电流、距离保护或差动保护动作）时，该模块会自动启动。
分析过程中，模块首先从受影响区域检索所有相关数据，包括主保护和备用保护设备的故障记录、COMTRADE扰动记录文件、状态变化日志（断路器位置和保护动作标志）以及每个设备的当前设置组。对于每个保护阶段（如距离区1、2和3），模块会通过比较测量阻抗或电流与设置区边界来检查保护是否正确启动，并验证保护是否在预期时间延迟内动作（允许±20毫秒的误差范围），同时评估选择性——即是否正确跳开了断路器以及备用保护是否不必要的动作。
模块还会将实际动作量与从当前设置组得出的预期值进行比较。超出预设容忍度（例如电流±5%、阻抗±10%）的情况会触发“设置不匹配”警报。分析完成后，系统会生成结构化报告，列出正常工作的设备、故障设备或未动作的设备，并提供具体的纠正建议，如重新校准保护参数、检查CT电路或更新设置组。在省级电网中对50个历史故障的测试表明，该模块正确识别了98%的事件，发现了12个之前操作员未注意到的隐藏设置不匹配问题，并将平均故障分析时间从45分钟缩短至3分钟。核心算法是硬编码的以保证性能，但模块的接口通过低代码平台开放，允许工程师自定义报告格式和添加新的分析规则。

**4. 结果**
为了全面评估本文提出的“低代码+容器化”灵活扩展和部署系统的有效性，本章从四个维度进行了实证研究：实验环境构建、核心功能验证、系统性能测试和实际工程应用。通过定量比较和模拟故障测试，客观证明了该系统在提高运营效率、增强系统弹性和确保服务可靠性方面的显著优势。

**4.1 实验环境设置**
实验建立了一个与生产环境高度相似的模拟测试平台。硬件环境由四台高性能物理服务器组成（配置有32核CPU、64GB RAM和1TB硬盘），其中一台服务器作为Kubernetes控制平面节点负责集群调度和管理，其余三台作为工作节点托管业务容器。客户端测试环境包括配置有16核CPU和32GB RAM的Linux工作站，以及Android 12和iOS 16移动设备。
软件栈实现了自主技术和可控技术组件的全面集成。低代码平台为前端-后端分离架构自开发而成：前端使用Vue.js V2.7实现可视化交互，后端采用Spring Cloud Alibaba微服务框架提供编排引擎、规则引擎等服务。其中，Nacos 2.2用于服务注册、发现和配置管理，Sentinel 1.8提供流量控制功能。容器化环境使用iSulad 2.0作为容器运行时环境，通过Kubernetes 1.24结合KubeSphere 4.0构建编排集群，选择Kube-OVN 1.10提供容器网络服务，并部署Harbor 2.8作为私有镜像仓库。数据存储层根据数据类型采用差异化选择：openGauss 3.0存储结构化关系数据（如设备记录）；TDengine 3.0处理高性能的实时时间序列监控数据写入和查询；JuiceFS 1.0分布式文件系统用于存储非结构化数据（如故障记录文件），同时支持HDFS接口。服务治理方面，引入Higress 1.0作为API网关进行流量控制。此外，Nightingale Monitoring 6.0作为可观测性平台，实现监控指标、日志和追踪的集中收集和可视化分析。

**4.2 功能验证**
- **低代码定制效率验证**
针对运营和维护中的常见功能定制需求，选择了“设备健康综合报告”和“复杂故障报警规则配置”两个典型场景进行对比验证。在传统开发模式下，完成“设备健康综合报告”需要需求分析、UI设计、后端接口开发、前端-后端集成和测试等步骤，整个周期约为7个工作日。“复杂故障报警规则配置”涉及多条件逻辑判断，开发和测试大约需要5个工作日。然而，使用本研究开发的低代码平台，运维人员无需编码即可完成任务。通过拖放预构建的可视化组件（如数据表和趋势图）并将其链接到相关数据源，报告可在4小时内自动设计和发布。通过图形化规则引擎，以类似自然语言的方式配置报警条件和动作，大约需要2小时即可完成并激活规则。定量计算显示，低代码定制模型将功能交付效率提高了90%以上，成功赋予了一线运维人员定制能力，实现了从“技术驱动”向“业务驱动”的转变。
- **容器化部署灵活性验证**
为了验证容器化部署的敏捷性，实验测试了从应用分发到弹性扩展的整个过程。测试人员从内部应用商店选择了“固定值在线验证”微服务应用并触发部署命令。后端Kubernetes集群自动完成资源调度，从Harbor镜像仓库拉取镜像，初始化容器实例并将其注册到服务网格中。整个过程仅耗时8分钟，应用即可使用。进一步测试弹性扩展能力时，通过设置Horizontal Pod Autoscaler策略，当应用容器的平均CPU利用率持续超过70%的阈值时，Kubernetes在30秒内自动将实例数量从1扩展到10个以分散负载。当负载降至30%以下时，系统会自动逐步减少实例数量。这一过程充分验证了“即插即用”能力和动态资源优化。

**4.3 性能验证**
- **系统可扩展性验证**
为了评估系统支持大规模设备访问的能力，使用模拟数据注入测试了不同设备规模下的服务响应性能，并与传统的单体架构进行了对比。结果如表2所示。在测试过程中，当连接1000个模拟继电保护设备时，系统核心业务操作（如设备状态查询和实时数据检索）的响应时间保持在较低水平。随着模拟设备数量逐渐增加到10,000个，基于变电站的数据分片策略和容器化微服务的弹性扩展机制，系统响应时间仅从45毫秒增加到210毫秒（增加了4.7倍），没有明显下降。相比之下，传统单体系统的响应时间在5000个设备时从48毫秒增加到680毫秒，之后超时。在整个压力测试过程中，所提出的系统没有出现请求超时或服务不可用的情况，展现了出色的可扩展性和服务稳定性。

**4.4 工程案例分析**
该系统已成功应用于某省级电网公司继电保护运维主站的升级项目中。该项目要求整合3200个异构继电保护设备的远程操作和维护功能，覆盖110 kV至500 kV的全省电压等级。实施后的结果包括：
- 在功能定制效率方面，低代码平台实现了可视化流程编排，并将功能封装为独立的微服务应用，整个过程仅用时3天完成（相比传统的外包开发模型约缩短了2周）。
- 在资源利用方面，通过容器化封装和Kubernetes细粒度调度，平均服务器CPU利用率从原始虚拟化架构的45%提升至85%，大幅减少了硬件投资，同时保持了相同的运营工作负载。
- 在运维模型方面，约75%的报告生成和报警规则调整任务通过低代码平台转移给了运维人员，大幅减少了对后端开发的依赖。业务需求响应周期从“每周一次”压缩到了“每小时一次”。
- 在系统稳定性方面，核心监控和报警服务在6个月的连续生产环境运行中实现了99.99%的可用性，没有因平台故障导致业务中断。
- 系统目前支持3200个异构设备连接，并具备处理≥200,000个设备的架构可扩展性，有力支持了电网运维的安全、高效和稳健发展。

如表3所示，该系统在省级电网主站升级项目中取得了显著的综合效益：在效率方面，功能定制周期大幅压缩；在资源方面，容器化调度降低了硬件投资成本；在运维模型方面，成功赋予了一线人员定制能力，实现了从“技术驱动”向“业务驱动”的转变；最后，系统的高可用性设计确保了长期稳定运行。这些定量指标共同证明了该系统在工程实践中的可行性和优越性。

**5. 讨论**
第4节的结果表明，所提出的低代码和容器化架构在部署敏捷性、可扩展性和故障恢复能力方面显著优于传统的单体式主站。响应时间的近似线性扩展（从1000个设备增加到10,000个设备仅增加了4.7倍）归因于两个因素：一是按变电站进行的数据分片，限制了每个微服务实例的工作负载；二是Kubernetes的Horizontal Pod Autoscaler在高负载下动态增加副本。相比之下，单体式系统的响应时间呈指数级增长（增加了38.5倍），这是由于共享数据库锁和单线程处理瓶颈所致。
在生产环境中实现的99.99%的可用性验证了跨应用、数据、网络和弹性能力层的多层冗余设计。故障注入测试确认无状态服务在1.8秒内恢复，满足了电网运行的严格要求，其中非关键功能通常可容忍不到五秒的延迟，而关键警报则要求恢复时间小于秒。关键数据的恢复点目标为零，确保设置记录或事件日志不会丢失。

5.2 实际应用和行业影响
该省级电网部署涵盖了从110 kV到500 kV的各种电压等级的3200个异构设备，彻底改变了维护工作流程。以前依赖开发人员来处理报告或规则变更的一线工程师现在可以使用低代码平台独立创建自定义仪表板和警报规则。这将平均需求响应周期从五天缩短到了四小时。容器化部署还使得新设备类型（如智能故障记录器）的集成在三天内完成，而以前需要两周时间。

定量改进进一步证明了所提出架构的价值。新功能的部署时间减少了96%，在传统的单体系统中需要两到四小时，而在新架构中仅需不到五分钟。新报告的定制工作量减少了93%，从七天的编码时间缩短到了四小时的拖放配置时间。系统的可扩展性也翻了一番，新架构支持超过10,000个设备而不会超时，而单体系统在5,000个设备时就会超时。这些数据表明，所提出的架构不仅是一个渐进式的改进，更是主站设计的一次根本性转变。对于电网运营商来说，这意味着总拥有成本降低、更快适应新设备和法规，以及升级过程中人为错误的风险减少。

5.3 解决安全问题、设置组管理和功能分析
关于安全问题，故意的网络攻击，特别是数据替换，仍然是一个关键问题。第3.7节中描述的基于HMAC-SHA256的消息认证和行为异常检测已经针对模拟的中间人攻击进行了测试。在1000次注入尝试中，所有被篡改的数据包要么因HMAC验证失败而被拒绝，要么因行为异常被标记，没有出现任何误报。然而，逐渐改变数据值的复杂攻击（有时称为“低速攻击”）更难以检测。未来的工作将结合时间序列预测模型（如LSTM）来识别这种隐蔽的篡改行为。

在设置组调整方面，第3.8节中描述的机制已在12次实时模式更改中成功应用，例如在计划停电期间。由于规则引擎的验证检查（例如确保新组与当前的CT和VT比率兼容），没有发生错误的切换。系统会记录每次组更改的完整审计轨迹，包括时间戳和操作员身份。

在故障后功能正确性分析方面，第3.9节中描述的PFA模块已在50个历史故障事件上进行了测试。它正确识别了98%的保护故障，并提供了可操作的改进建议。在两个案例中，它发现了隐藏的设置不匹配问题，例如Zone 2的设置值低了15%，而操作员之前并未注意到这些问题。故障分析时间从45分钟缩短到3分钟，使工程师能够专注于根本原因分析和预防措施，而不是手动数据收集。

5.4 局限性和未来方向
尽管取得了这些成功，当前系统仍存在一些局限性。组件库的覆盖范围还不完整，因为并非所有的继电保护场景（如带有谐波阻断的变压器差动保护或带有负载侵入的距离保护）都已有现成的硬编码组件。添加新组件需要开发核心算法，目前每个组件需要两到四周的时间。

I区的容器安全性也是一个限制。使用像iSulad这样的通用Linux容器可能不足以防范高级持续性威胁。虽然第3.7节中的安全措施提供了深度防御，但应评估更强的隔离机制，如Kata Containers或gVisor。

跨区域同步延迟也是一个挑战。中心辐射式的两级镜像存储库架构会导致版本传播到远程调度中心的延迟长达15分钟。对于时间敏感的安全补丁来说，这种延迟可能是不可接受的。将来将研究使用Dragonfly这样的点对点分发协议。

最后，人工智能集成仍处于早期阶段。当前的PFA模块使用基于规则的逻辑。下一步是将深度学习集成到故障分类和预测性维护中。使用基于变压器的模型进行的初步实验在故障类型分类上达到了92%的准确率，但推理延迟约为50毫秒，需要进一步优化。

5.5 开放性研究问题
除了眼前的工作之外，还有一些更广泛的研究问题。其中一个问题是如何正式验证低代码编排的工作流程是否违反了电网安全约束，例如意外跳闸命令或错误的设置组切换。可以适应模型检查或运行时验证技术来解决这个问题。

另一个问题是关于硬编码组件和低代码组件之间的最佳权衡。硬编码组件提供更好的性能和安全性，而低代码组件则提供灵活性和敏捷性。对于不同的继电保护功能，需要基于重要性和更新频率的系统性决策框架。

第三个问题是如何实现无状态服务的亚秒级恢复时间目标而不丢失数据。无状态服务（如前端协议数据访问容器）尤其具有挑战性。使用无冲突复制数据类型的主动-主动地理分布式集群是未来研究的一个有前景的方向。

6. 结论
本文提出了一种灵活的扩展和部署系统，用于继电保护远程维护主站，集成了低代码和容器化技术。本研究的主要结果总结如下：
- 四层解耦架构结合了特定领域的低代码组件库和硬编码的核心功能，既保证了性能，又实现了低代码外围功能，将功能定制周期从几周缩短到了几小时。
- 协同的CI/CD流程实现了不到五分钟的完整周期部署，比传统的手动部署提高了90%的效率。
- 在可扩展性方面，该系统支持超过10,000个模拟设备，10,000个设备时的响应时间稳定在210毫秒，而单体系统在5,000个设备时就会超时。该省级电网部署目前支持3200个异构设备，并具有支持200,000个或更多设备的架构能力。
- 在可靠性方面，系统在六个月的运行中实现了99.99%的核心服务可用性。
- 故障注入测试旨在实现无状态服务的1.8秒恢复时间和关键数据的零恢复点目标，通过同步复制实现。
- 在运营效率方面，系统将运营和配置效率提高了60%，主站和变电站的手动配置工作量分别减少了60%。
- 在安全和高级功能方面，系统实现了基于HMAC-SHA256的消息认证和针对数据替换攻击的行为异常检测。基于SCADA或EMS数据的设置组调整机制实现了根据电网运行模式自动切换。
- 故障后功能正确性分析模块在50个历史故障事件中正确识别了98%的保护故障，并减少了故障分析时间，从45分钟缩短到了3分钟。

这些结果证实，所提出的系统有效解决了传统运营和维护主站在可扩展性、敏捷性和可靠性方面的挑战，为新的电力系统提供了系统和行业验证的解决方案。