第二讲：中间件基础概念

各位同学好，我是你们的老朋友。今天咱们聊聊中间件——这个在嵌入式系统里经常被提起，但很多人又说不清楚的概念。

说实话，我刚开始做嵌入式开发那会儿，对中间件也是一头雾水。总觉得这东西是搞IT的才需要，咱们搞硬件的，直接写驱动、调协议不就完了？直到后来做了几个大型项目，才明白中间件到底有多重要。

什么是中间件？

中间件，说白了就是一层“胶水”。它夹在操作系统和应用软件之间，帮两边传递信息、协调工作。

你想想看，一个嵌入式系统里，可能有传感器、执行器、通信模块、人机界面……这些东西各自用不同的协议、不同的数据格式。如果没有中间件，你得自己写一堆代码去处理这些差异。我见过不少项目，光是在协议转换上就耗费了60%的开发时间。

中间件的作用，就是把这些脏活累活包揽下来。它提供统一的接口，让上层应用不用关心底层硬件是谁家的、协议是什么。嗯，这里要注意：中间件不是操作系统，它跑在操作系统之上；中间件也不是应用，它是为应用服务的。

核心定义：中间件是一种位于操作系统和应用软件之间的独立服务程序，它通过标准的编程接口和协议，实现不同应用之间的数据交换和互操作。

中间件在嵌入式系统中的作用

我总结了一下，中间件在嵌入式系统里主要干四件事：

  • 屏蔽异构性——不同芯片、不同操作系统、不同通信协议，中间件帮你统一了。我在一个项目中用过3种MCU，如果没有中间件，光适配就得累死人。
  • 降低耦合度——应用和底层硬件解耦。你想换一个传感器？只要中间件接口不变，应用代码几乎不用改。
  • 提供公共服务——比如日志、时间同步、数据缓存。这些功能每个模块都需要，但没必要每个模块都自己实现。
  • 简化通信——点对点、发布/订阅、请求/响应……中间件把这些通信模式封装好了，你直接调用就行。

我曾经在一个工业网关项目里，因为没选好中间件，后期改架构改得想哭。所以我现在做项目，第一件事就是先把中间件方案定下来。

常见的嵌入式中间件

嵌入式领域常用的中间件，我挑三个最典型的来讲：MQTT Broker、CoAP、DDS。这三个我都实际用过，各有各的脾气。

1. MQTT Broker

MQTT（Message Queuing Telemetry Transport）是一种轻量级的发布/订阅模式的消息协议。它的核心是Broker——一个消息中转服务器。

工作原理很简单：设备A发布一条消息到某个“主题”，设备B订阅了这个主题，Broker就把消息推给设备B。设备A和设备B不需要知道对方的存在。

我在一个智能家居项目里用过MQTT。当时有几十个传感器节点，每个节点每隔几秒上报一次数据。如果用传统的TCP连接，服务器得维护几十个长连接，压力很大。MQTT Broker帮我解决了这个问题——所有节点只连Broker，Broker负责分发。

我的经验：MQTT最适合带宽有限、网络不稳定的场景。它的最小报文只有2个字节，而且支持三种服务质量等级（QoS 0、1、2）。我一般用QoS 1，既保证消息到达，又不会太耗资源。

代码示例——一个简单的MQTT发布端：

#include <MQTTClient.h>

MQTTClient client;
client.begin("broker.emqx.io", 1883);

// 连接到Broker
client.connect("device_001");

// 发布消息到主题
client.publish("sensor/temperature", "25.6");

// 循环处理
while(client.connected()) {
    client.loop();
}

2. CoAP

CoAP（Constrained Application Protocol）是专门为资源受限设备设计的。它基于UDP，而不是TCP。你想想看，有些传感器只有几KB的RAM，跑TCP太奢侈了。

CoAP的设计思路和HTTP很像——有GET、POST、PUT、DELETE方法。但它比HTTP轻量得多。一个CoAP报文头部只有4个字节。

我记得有一次做环境监测项目，用的是8位单片机，只有2KB RAM。MQTT跑不动，DDS更别想了。最后选了CoAP，完美适配。每个节点每5分钟上报一次温湿度数据，运行了两年没出过问题。

注意：CoAP基于UDP，所以消息可能丢失。它通过“确认报文”和“重传机制”来保证可靠性。但如果你需要严格的消息顺序和事务支持，CoAP可能不是最佳选择。

代码示例——CoAP服务器端：

#include <coap.h>

coap_context_t *ctx;
coap_resource_t *resource;

// 创建上下文
ctx = coap_new_context(NULL);

// 注册资源
resource = coap_resource_init("temperature");
coap_register_handler(resource, COAP_REQUEST_GET, handle_get);
coap_add_resource(ctx, resource);

// 处理GET请求
void handle_get(coap_context_t *ctx, coap_resource_t *resource,
                coap_session_t *session, coap_pdu_t *request,
                coap_binary_t *token, coap_pdu_t *response) {
    unsigned char buf[4];
    buf[0] = 25; // 温度值
    coap_add_data(response, 1, buf);
}

3. DDS

DDS（Data Distribution Service）是这三个里面最“重”的，但也是功能最强的。它采用数据为中心的发布/订阅模型，支持实时、高可靠、高性能的数据分发。

DDS的核心概念是“全局数据空间”。所有参与者都连接到这个空间，发布者往里面写数据，订阅者从里面读数据。DDS负责数据的发现、传输、排序、过滤。

我在一个自动驾驶项目里用过DDS。当时需要多个传感器（激光雷达、摄像头、毫米波雷达）的数据实时融合，延迟要求小于10毫秒。MQTT做不到，CoAP更不行。DDS的实时QoS策略帮了大忙。

特性 MQTT CoAP DDS
传输协议 TCP UDP UDP/TCP
通信模式 发布/订阅 请求/响应 发布/订阅
资源消耗 中等 低 高
实时性 一般 一般 强
适用场景 物联网、智能家居 资源受限设备 实时系统、自动驾驶

选型建议：如果你的设备资源紧张，选CoAP；如果网络不稳定、需要简单可靠的消息传递，选MQTT；如果对实时性和可靠性要求极高，选DDS。我个人的习惯是：先看硬件资源，再看通信需求，最后定中间件。

代码示例——DDS发布者：

#include <dds/dds.h>

dds_entity_t participant;
dds_entity_t topic;
dds_entity_t writer;

// 创建参与者
participant = dds_create_participant(DDS_DOMAIN_DEFAULT, NULL, NULL);

// 创建主题
topic = dds_create_topic(participant, &SensorData_desc, "SensorData", NULL, NULL);

// 创建写入者
writer = dds_create_writer(participant, topic, NULL, NULL);

// 写入数据
SensorData data = {.id = 1, .value = 25.6};
dds_write(writer, &data);

小结

好了，这一讲的内容就到这里。中间件不是什么神秘的东西，它就是帮你省事的工具。选对了中间件，项目开发效率能提升一大截；选错了，后期改起来真要命。

下一讲我会深入讲MQTT Broker的架构设计，包括如何做高可用、如何做消息持久化。到时候我会分享一个我踩过的坑——Broker挂了之后消息丢失的问题。嗯，那真是血的教训。

今天就到这儿，有问题随时交流。

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