4. 协议转换引擎实现：规则引擎设计

协议转换引擎，说白了就是整个网关的大脑。我见过不少团队，一上来就写死转换逻辑，结果后期维护成本高得吓人。今天咱们聊聊怎么把这块做灵活、做安全。

4.1 规则引擎设计：JSON 规则配置

我个人习惯把规则和代码彻底分离。规则引擎的核心，就是让非开发人员也能通过配置文件来定义“怎么转”。JSON 格式是最自然的选择——结构清晰，解析方便，也容易版本管理。

来看一个实际的规则配置示例：

{
  "ruleId": "modbus_tcp_to_mqtt_001",
  "name": "Modbus TCP 数据转 MQTT JSON",
  "priority": 10,
  "conditions": [
    {
      "type": "protocol",
      "source": "modbus_tcp",
      "functionCode": 3,
      "registerStart": 0,
      "registerCount": 10
    },
    {
      "type": "schedule",
      "cron": "*/5 * * * * *"
    }
  ],
  "actions": [
    {
      "type": "transform",
      "targetProtocol": "mqtt",
      "topic": "sensors/temperature",
      "qos": 1
    },
    {
      "type": "map",
      "fields": [
        {"source": "register[0]", "target": "temp_value", "convert": "uint16_to_float"},
        {"source": "register[1]", "target": "humidity", "convert": "uint16_to_float"}
      ]
    }
  ]
}

这里要注意几个坑。我曾经在项目里把 priority 字段忘了配，结果规则执行顺序全乱套了。嗯，规则引擎的优先级一定要显式声明，默认值很容易出问题。

4.2 协议适配器模式

适配器模式，说白了就是给每个协议穿一件“马甲”。不管底层是 Modbus、MQTT 还是 HTTP，到了引擎这里，都统一成一个接口。

我一般这样定义适配器接口：

public interface ProtocolAdapter {
    // 协议初始化
    boolean init(Map<String, Object> config);
    
    // 接收原始数据
    byte[] receive();
    
    // 发送转换后的数据
    boolean send(byte[] data);
    
    // 协议心跳检测
    boolean heartbeat();
    
    // 资源释放
    void destroy();
}

每个协议实现这个接口就行。比如 Modbus TCP 适配器：

public class ModbusTcpAdapter implements ProtocolAdapter {
    private Socket socket;
    private int timeout = 5000;
    
    @Override
    public boolean init(Map<String, Object> config) {
        // 解析配置，建立 TCP 连接
        String host = (String) config.get("host");
        int port = (int) config.get("port");
        // ... 连接逻辑
        return true;
    }
    
    @Override
    public byte[] receive() {
        // 读取 Modbus 帧
        // 注意处理粘包问题
        byte[] frame = new byte[256];
        // ... 读取逻辑
        return frame;
    }
    
    // 其他方法实现...
}

4.3 数据映射与转换

数据映射是协议转换里最琐碎、也最容易出错的环节。字节序、数据类型、精度，哪个不对都能让你排查半天。

4.3.1 字节序处理

不同协议对字节序的偏好不一样。Modbus 喜欢大端，某些工业协议偏爱小端。我习惯写一个工具类统一处理：

public class ByteOrderUtil {
    // 大端转小端
    public static byte[] bigToLittle(byte[] data) {
        byte[] result = new byte[data.length];
        for (int i = 0; i < data.length; i++) {
            result[i] = data[data.length - 1 - i];
        }
        return result;
    }
    
    // 读取指定字节序的 16 位整数
    public static int readInt16(byte[] data, int offset, boolean isBigEndian) {
        if (isBigEndian) {
            return ((data[offset] & 0xFF) << 8) | (data[offset + 1] & 0xFF);
        } else {
            return ((data[offset + 1] & 0xFF) << 8) | (data[offset] & 0xFF);
        }
    }
}

4.3.2 数据类型映射表

不同协议的数据类型千差万别。我整理了一张常用映射表：

源协议类型	目标协议类型	转换规则	精度损失
uint16 (Modbus)	int32 (MQTT JSON)	直接赋值，高位补0	无
float32 (IEEE754)	double (JSON)	类型提升	无
int32 (二进制)	string (HTTP)	数字转字符串	无
BCD 码	int	BCD 解码	无
uint64 (大端)	BigInteger (Java)	字节数组转大整数	无

4.4 动态加载协议插件

系统上线后，难免要新增协议。总不能每次都重启网关吧？动态加载就是干这个的。

我常用的方案是基于 Java 的 SPI 机制，或者用 OSGi。这里给个简单的 SPI 示例：

// 1. 定义插件接口
public interface ProtocolPlugin {
    String getProtocolName();
    ProtocolAdapter createAdapter(Map<String, Object> config);
}

// 2. 实现插件
public class MqttPlugin implements ProtocolPlugin {
    @Override
    public String getProtocolName() {
        return "mqtt";
    }
    
    @Override
    public ProtocolAdapter createAdapter(Map<String, Object> config) {
        return new MqttAdapter(config);
    }
}

// 3. 插件加载器
public class PluginLoader {
    private Map<String, ProtocolPlugin> plugins = new HashMap<>();
    
    public void loadPlugins(String pluginDir) {
        // 扫描目录下的 jar 包
        File dir = new File(pluginDir);
        for (File jar : dir.listFiles((d, name) -> name.endsWith(".jar"))) {
            URLClassLoader loader = new URLClassLoader(
                new URL[]{jar.toURI().toURL()},
                this.getClass().getClassLoader()
            );
            // 通过 SPI 加载实现类
            ServiceLoader<ProtocolPlugin> serviceLoader = 
                ServiceLoader.load(ProtocolPlugin.class, loader);
            for (ProtocolPlugin plugin : serviceLoader) {
                plugins.put(plugin.getProtocolName(), plugin);
                System.out.println("Loaded plugin: " + plugin.getProtocolName());
            }
        }
    }
    
    public ProtocolAdapter getAdapter(String protocol, Map<String, Object> config) {
        ProtocolPlugin plugin = plugins.get(protocol);
        if (plugin == null) {
            throw new IllegalArgumentException("Unsupported protocol: " + protocol);
        }
        return plugin.createAdapter(config);
    }
}

下面这张图，把整个协议转换引擎的架构串起来了：

你想想看，这套架构跑起来之后，新增一个协议只需要三步：写适配器、配映射规则、打成 jar 包扔进插件目录。完全不用改核心代码。

嗯，这里要注意一点——插件目录的权限一定要收死。我曾经在客户现场发现有人把恶意 jar 包丢进去，还好沙箱隔离生效了，不然整个系统都得瘫痪。