第三章 常见架构模式：分层架构、事件驱动架构、微服务架构、管道-过滤器模式在工控中的应用

聊到工控软件的架构，我脑子里第一个蹦出来的词就是「模式」。

不是设计模式那种细颗粒度的东西，而是更宏观的架构模式。说白了，就是软件的整体骨架怎么搭。

我在工控这行摸爬滚打十几年，见过太多项目因为架构选型失误，后期改得痛不欲生。今天咱们就把四种最常见的架构模式掰开揉碎，看看它们在工控场景下到底该怎么用。

3.1 分层架构：工控软件的「老黄牛」

分层架构，你想想看，是不是最熟悉？

从早期的PLC编程到现在的SCADA系统，分层无处不在。我个人习惯把工控软件分成三层：

  • 表示层：HMI界面、Web仪表盘、移动端APP
  • 业务逻辑层：控制算法、报警处理、数据聚合
  • 数据访问层：OPC UA客户端、Modbus驱动、数据库接口

为什么分层架构在工控领域这么流行？

因为它符合人的认知习惯。每一层只关心自己的事，上层调用下层，下层不知道上层是谁。

核心要点：分层架构的核心是「依赖倒置」。上层依赖抽象接口，而不是具体实现。

我在项目中遇到过一个问题：某产线的HMI需要同时支持WinCC和Web两种界面。如果表示层直接调用OPC驱动，那换界面就得重写驱动层。后来我们加了一个业务逻辑层，把数据聚合和界面渲染彻底分开。嗯，这个改动虽然前期多花了三天，但后面省了三个月的维护时间。

我的建议：分层架构适合控制逻辑相对稳定、界面变化频繁的场景。比如一个标准的SCADA项目，用分层架构准没错。

3.2 事件驱动架构：让系统「活」起来

分层架构有个毛病——太死板。

你想想，一个传感器报警了，需要同时触发声光报警、记录日志、发送短信、调整PID参数。如果用分层架构，你得在业务逻辑层写一堆if-else，耦合度极高。

这时候，事件驱动架构就派上用场了。

事件驱动架构的核心思想很简单：

  • 事件生产者只管发事件
  • 事件消费者只管收事件
  • 中间有个事件总线（Event Bus）负责路由

我曾经在一个大型水处理项目中用过这种模式。现场有上千个传感器，每个传感器状态变化都会产生事件。我们用RabbitMQ做事件总线，各个子系统（报警、报表、控制）都是独立的消费者。

// 伪代码示例：事件驱动架构
// 传感器事件生产者
class Sensor {
    void onValueChanged(float newValue) {
        EventBus.publish(new SensorEvent("TANK_101_LEVEL", newValue));
    }
}

// 报警消费者
class AlarmConsumer {
    @EventHandler
    void handle(SensorEvent event) {
        if (event.value > HIGH_LIMIT) {
            alarmService.trigger(event.sensorId);
        }
    }
}

// 日志消费者
class LogConsumer {
    @EventHandler
    void handle(SensorEvent event) {
        logService.record(event.sensorId, event.value, System.currentTimeMillis());
    }
}

避坑指南：我曾经在一个项目中把所有事件都丢到同一个队列里，结果高并发时队列爆了，报警延迟了整整两分钟。后来我学乖了——关键事件（如急停、超限）用独立的高优先级队列，普通事件（如状态变化）用低优先级队列。

事件驱动架构的优点是松耦合、可扩展。但缺点也很明显——调试困难。你很难追踪一个事件到底经过了哪些消费者。我的经验是：一定要加事件追踪ID，否则出问题你根本不知道锅该谁背。

3.3 微服务架构：工控界的「双刃剑」

微服务架构，这几年被炒得很火。

但说实话，在工控领域，微服务不是万能的。我见过太多人为了微服务而微服务，结果把简单问题搞复杂了。

微服务架构在工控中的典型应用场景：

  • 数据采集服务：独立部署，支持多种协议（Modbus、Profinet、EtherCAT）
  • 报警服务：独立运行，不依赖其他服务
  • 历史数据服务：专门处理数据存储和查询
  • 报表服务：按需生成报表，不影响实时控制
架构模式 适用场景 不适用场景
微服务 大型分布式系统、多站点管理 实时性要求极高的控制回路
分层架构 中小型SCADA、HMI项目 需要频繁变更业务逻辑的系统
事件驱动 报警处理、数据流处理 强一致性要求的场景

我个人习惯：如果系统需要部署在多个物理位置，或者需要独立扩展某个功能模块，微服务是个好选择。但如果只是一个单机运行的工控系统，别折腾微服务了，分层架构更实在。

我的经验：微服务之间的通信，我建议用gRPC而不是REST。为什么？因为工控场景下延迟敏感，gRPC的二进制协议比JSON快一个数量级。我在一个半导体项目中做过对比，同样的数据量，gRPC比REST快了将近5倍。

3.4 管道-过滤器模式：数据流的「流水线」

管道-过滤器模式，说白了就是把数据处理拆成一个个独立的步骤。

每个步骤是一个过滤器，数据在管道中流动，经过一个个过滤器处理。

这种模式在工控中太常见了：

  • 原始数据 → 数据清洗 → 单位转换 → 滤波 → 存储
  • 传感器信号 → 去噪 → 特征提取 → 模式识别 → 报警判断

我记得在一个钢铁厂的项目中，我们需要处理热轧钢板的温度数据。原始数据噪声很大，需要经过：

  1. 中值滤波（去除异常点）
  2. 滑动平均（平滑曲线）
  3. 温度补偿（根据环境温度修正）
  4. 阈值判断（是否超限）

如果用传统的if-else写法，代码会变得又臭又长。用管道-过滤器模式，每个过滤器独立测试，出了问题也容易定位。

// 管道-过滤器模式示例
class DataPipeline {
    private List<Filter> filters = new ArrayList<>();
    
    void addFilter(Filter filter) {
        filters.add(filter);
    }
    
    double process(double rawData) {
        double data = rawData;
        for (Filter filter : filters) {
            data = filter.apply(data);
        }
        return data;
    }
}

// 具体过滤器
class MedianFilter implements Filter {
    double apply(double input) {
        // 中值滤波逻辑
    }
}

class MovingAverageFilter implements Filter {
    double apply(double input) {
        // 滑动平均逻辑
    }
}

注意：管道-过滤器模式虽然灵活，但每个过滤器都会引入延迟。如果实时性要求极高（比如1ms以内的控制周期），过滤器数量不能太多。我曾经在一个伺服控制项目中用了5个过滤器，结果总延迟超过了控制周期，电机开始抖动。后来我把两个过滤器合并了，问题才解决。

3.5 如何选择？我的「三板斧」

说了这么多，到底该怎么选？

我总结了一个简单的判断方法：

  • 系统规模小、逻辑稳定 → 分层架构
  • 需要处理大量异步事件 → 事件驱动架构
  • 系统需要独立扩展、分布式部署 → 微服务架构
  • 数据处理链路长、步骤清晰 → 管道-过滤器模式

但说实话，实际项目中很少只用一种模式。我最近做的一个项目就是分层架构为主，内部嵌入了事件驱动来处理报警，数据采集部分用了管道-过滤器模式。架构模式是工具，不是教条。

最后说一句：架构设计没有银弹。最好的架构，是能让你在三个月后还能看懂、能修改的架构。别为了炫技而过度设计，工控系统稳定第一。

← 上一章 📖 返回目录 下一章 →