企业官网建设流程全解析

拿一台云服务器去养龙虾，这事听着像个段子，但真有人这么干，而且干完以后发现离不开了。我在塘边蹲过、在机房也蹲过，给你说句实话：小龙虾养殖最需要的不是蛮力，是把水里的数据和设备状态摸清楚。腾讯轻量服务器（轻量应用服务器）在这个场景里扮演的，就是那个“24小时不下班的值班员”——它接收塘边传感器传回来的水温、溶氧、pH值，帮你算清楚什么时候该开增氧机、什么时候水质要出问题，再顺手把预警推到你手机里。

这篇文章完整记录我从零搭一套“小龙虾养殖物联网监控系统”的过程，从硬件选型、传感器接线，到轻量服务器上的 MQTT 消息服务、数据库、可视化面板和自动控制，全部落地可复现。想搞智慧农业项目的人要看，家里有塘的养殖户要看，对物联网有兴趣但一直没找到合适练手场景的技术朋友，更要看。

1. 一句话说清：为什么养龙虾需要一台服务器

先破除一个思维定式：不是让服务器下水替虾干活，而是让服务器替你的眼睛、耳朵和腿干活。

小龙虾是典型的高密度养殖品种，塘里的水环境说变就变。尤其是夏季高温天，半夜溶氧掉下去，增氧机没开，第二天早上起来可能就是满塘浮头、损虾几千块。经验丰富的老师傅能靠看水色、看虾活动判断个大概，但人总有打盹的时候，一打盹就是真金白银的代价。服务器要解决的，就是这种“人不可靠”的问题。

1.1 传统小龙虾养殖的三大痛点

• 水质变化看不见。水温、溶氧、pH、氨氮这些指标，白天黑夜都在波动。按点取样化验，得到的是滞后数据，等你测出来异常，损失已经发生了。
• 设备故障后知后觉。增氧机跳闸、水泵烧毁，塘里电停了，人没在塘边根本不知道。有时候一个晚上就能把一塘虾憋坏。
• 经验无法积累和复用。老塘主凭感觉，新农户无从下手。同一个池塘，每年的数据到底什么样，没有记录，第二年还是从头摸索。

1.2 这套系统能干的事

我在塘里部署了一组传感器：水温探头、溶解氧探头、pH探头、水位计，再加上一个控制箱，里面是继电器和网关设备。传感器每 30 秒采集一次数据，通过无线方式传到轻量服务器。服务器上的程序负责三件事：

• 把数据存进数据库，生成曲线，随时回溯；
• 对比阈值规则，超标的马上触发告警；
• 根据配置自动给控制箱下发指令，比如溶氧低于 3mg/L 时自动开启增氧机。

这套系统上线以后，最直观的变化是半夜终于能睡整觉了。手机收到告警再处理，而不是第二天早起才发现出事。

1.3 为什么选腾讯轻量服务器做核心

市面上做物联网平台的服务一大堆，为什么我最后把核心放在一台轻量服务器上？

第一，它有固定的公网 IP。塘边的采集设备不用做内网穿透，直接通过 IP 就能连上来，少一层中介就少一个故障点。

第二，成本可控。轻量服务器一年几百块，比买成品物联网平台的年费便宜得多，而且软硬件全在自己手里，想改规则就改，不受平台限制。

第三，接入链路短。从传感器到 MQTT 消息服务再到告警逻辑，都在一台机器上完成，延迟低到可以忽略。真要是塘边设备断线，也能马上定位是网络问题还是服务问题。

腾讯轻量服务器本身不是什么神奇硬件，就是一台配置不高但足够稳定的 Linux 主机。但它有公网入口、有防火墙、有快照，这些基础能力对于小规模物联网项目来说，已经绰绰有余了。我自己用的是 2核4G 的配置，跑 MQTT 服务、数据库和可视化面板，CPU 占用率长期在 10% 上下，非常宽裕。

2. 系统整体设计与选型思路

养龙虾的系统方案，核心是四个字：链路优先。先把“传感器到确认收到”这条路走通，再去折腾花哨的功能，否则全是在沙滩上盖楼。

2.1 四层架构：从传感器到手机通知

整个系统拆成四层来看，心里就特别清楚。

感知层：塘里的传感器，负责采集水温、溶氧、pH、水位等模拟量或数字量信号。

传输层：采集网关（我用的 ESP32 开发板加 RS485 转接板），把各传感器的数据汇总，再通过 Wi-Fi 或 4G 模块以 MQTT 协议发布到服务器的指定主题。

平台层：腾讯轻量服务器。上面运行三块服务——EMQX 作为 MQTT 消息代理、TDengine 或 MySQL 存数据、Node-RED 负责业务规则编排，比如告警判断和自动控制。

应用层：手机端和电脑端。最轻量的模式是直接用浏览器看 Grafana 面板，告警通过微信或邮件推送。

这套架构的好处是每一层都能独立替换。传感器坏了只影响感知层，服务器挂了重新拉起 Docker 容器就恢复，不会牵一发动全身。

2.2 硬件采集端选型：别一上来就买数万块的监测仪

一说水质监测，很多人第一反应是买那个带大屏的一体化监测浮标，手指一戳就显示溶氧数据，两万多。我没选它，原因有两个：贵，且封闭。

我的方案是分开买传感器自己组装。溶氧探头选的是荧光法 RS485 输出，相关仪表大约千把块；水温探头用 PT100 或者 DS18B20，几十块到一百多块；pH 电极选工业级 RS485 的，六百以内能拿下。全套硬件下来不到三千，而且以后哪个传感器坏了，单独换哪个就行，不像一体机坏了整机返厂。

采集网关我用的 ESP32，带 WiFi 和蓝牙，价格便宜，开发资料又多。ESP32 通过 TTL 转 RS485 模块去轮询各传感器，拿到数据后打包成 JSON，通过 MQTT 发出去。

这里有个关键心得：传感器不一定非要全部上 RS485。如果是自己玩，水温这种简单的量，用 DS18B20 直接接 ESP32 也行，省一个 Modbus 地址。但正式搞塘口，我还是推荐统一走 RS485 Modbus RTU，因为现场布线长，差分信号抗干扰强，而且后面换传感器不用改网关代码。

2.3 服务器端软件选型

服务器上的软件栈我一开始就定了调：能容器化就容器化，能开源就开源。最后跑起来的内存占用是这样的：

• EMQX（MQTT Broker）：约 300MB；
• Node-RED（规则引擎）：约 150MB；
• TDengine（时序数据库）：约 400MB；
• Grafana（可视化）：约 200MB。

全部加起来不到 1.5GB，轻量服务器 2核4G 跑得轻轻松松。这套组合全部用 Docker Compose 编排，一个命令就能把环境全部拉起来，重装系统以后恢复服务只需要几分钟。

还有一点提醒：别把业务逻辑硬塞进 EMQX 的规则引擎里。EMQX 自带的规则引擎能做简单的消息转发，但复杂的业务判断（比如连续三次低溶氧再告警，避免误报）写起来很别扭。我用 Node-RED 接住原始数据做判断，逻辑清晰，可视化编辑，现场改规则不用重启服务，体验好得多。

3. 采集端搭建：传感器与网关怎么接

这一节是硬核动手环节。下塘布线之前，先把原理和容易踩的坑说清楚，免得你大热天在塘边白折腾一整天。

3.1 传感器清单与接口常识

我的塘口配置如下表，你可以直接抄作业：

买传感器时务必确认一个细节：是支持 Modbus RTU 协议，还是只输出模拟量（4-20mA 或 0-5V）。Modbus 的接在 RS485 总线上就行，一个总线最多能挂 32 个设备，以后扩展氨氮、浊度传感器都不用重新布线。模拟量的需要额外加采集模块，麻烦不少。

3.2 ESP32 网关怎么采集 Modbus 数据

ESP32 本身没有 RS485 接口，需要外接一个 TTL 转 RS485 模块，比如 MAX3485 或者 SP3485。接线方式很固定：ESP32 的 UART 串口（我用的是 GPIO16/17）接模块的 TX/RX，模块的 A/B 接 RS485 总线的 A/B，传感器也并联到这条 A/B 总线上。注意总线上 A 和 B 之间要接一个 120 欧姆的终端电阻，不然数据传远了容易乱码。

做一个简单动作：把所有传感器设备地址设置好。Modbus 设备出厂默认地址通常是 1，多个设备都是 1 就冲突了。我用串口工具挨个改：水温设 1、溶氧设 2、pH 设 3，然后在代码里读写不同的寄存器地址。

这是 ESP32 读取溶氧传感器的代码框架，把协议字节流发出去，读到返回帧后解析成物理量：

#include <WiFi.h> #include <ModbusRTU.h> ModbusRTU mb; uint16_t reg[8]; void setup() { Serial.begin(115200); WiFi.begin("your_ssid", "your_pwd"); mb.begin(Serial2, 2); // 串口2，从机地址2为溶氧探头 mb.client(); } void loop() { if (!mb.slave()) { mb.readHreg(2, 0x0000, reg, 2, []() { // 溶氧值原始码在reg[0]，量程换算 float do_mgL = reg[0] * 0.01; Serial.printf("DO: %.2f mg/L\n", do_mgL); }); } delay(30000); // 30秒采一次 }

每种传感器的寄存器地址和量程系数不一样，买的时候问客服要 Modbus 寄存器表，这是一个关键步骤。

3.3 数据走 MQTT 上传，为什么比 HTTP 稳

我从一开始就坚持用 MQTT 而不是 HTTP，这里分享一点实际感受。MQTT 是发布/订阅模式，设备把数据“丢”到某个主题上就完事了，不需要服务端立即应答。网络抖动时，消息会留在代理端，网络恢复后自动补发；而 HTTP 请求一旦超时，数据就丢了。

主题设计也很有讲究，我按这个结构组织：

lobster/{pond_id}/sensor/water_temperature lobster/{pond_id}/sensor/do lobster/{pond_id}/sensor/ph lobster/{pond_id}/device/pump_1/status

每个主题代表一个数据维度，后面接思谋警规则时，可以用通配符订阅一组主题，非常灵活。发布的时候，ESP32 把数据打包成 JSON，比如：

{"value": 26.4, "timestamp": 1691234567890}

发出去的时间戳用毫秒级别，后面画曲线和统计时不会乱。

4. 轻量服务器端部署全流程

到这一步，你的轻量服务器要正式上岗了。整个部署过程我踩过的坑不少，下面按顺序整理，照着做基本能一次跑通。

4.1 服务器选购与登录安全第一课

腾讯轻量服务器的地域就选离塘口最近的城市，延迟越低越好，国内地域没有明显差别。配置方面，2核4G 已经绰绰有余，要便宜的话 2核2G 也能跑，只不过 TDengine 和 Grafana 同时开时内存会紧巴巴。系统镜像选 Ubuntu 22.04 LTS，长期支持，软件源也稳定。

拿到服务器第一件事不是装环境，而是把登录安全做好。我踩过一次教训：服务器刚开三天，尝试 SSH 登录的日志刷了几百条，全是暴力破解扫描。下面三件事必须立刻做：

• 修改 SSH 端口，把 22 改成 6022，能挡掉九成扫描；
• 用密钥登录并关闭密码登录，参考下面命令；
• 装 fail2ban，连续失败三次封 IP 一小时。

# 在本地生成密钥后，把公钥复制到服务器 ssh-copy-id -p 6022 root@your_server_ip # 关闭密码登录 sudo sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config sudo systemctl restart sshd

注意：改完 SSH 配置后不要马上断开当前连接。先开一个新终端，确认密钥能登录，再退出旧会话，不然把自己锁外面就麻烦了。

4.2 用 Docker 快速部署 EMQX

Docker 是我在服务器上最依赖的工具。装好 Docker 之后，整个 EMQX 的部署就是一行命令的事。我先写一个 docker-compose.yml，把所有服务统一管理：

version: '3' services: emqx: image: emqx/emqx:5.6.1 container_name: emqx restart: always ports: - "1883:1883" - "8083:8083" - "8084:8084" - "18083:18083" environment: EMQX_DASHBOARD__DEFAULT_USERNAME: admin EMQX_DASHBOARD__DEFAULT_PASSWORD: "your_password" mysql: image: mysql:8.0 container_name: mysql restart: always environment: MYSQL_ROOT_PASSWORD: "your_root_pwd" TZ: Asia/Shanghai volumes: - mysql_data:/var/lib/mysql volumes: mysql_data:

启动以后，EMQX 的 Dashboard 在 18083 端口，用环境变量里设置的账号密码登录。进去以后第一件事是创建一个专门给设备用的用户名密码，别用管理员账号做设备认证，这是基本的隔离意识。

然后给 MQTT 开认证。轻量服务器的公网 IP 被扫是常态，MQTT 默认 1883 端口又是不加密的，如果连认证都不开，别人可以直接往你的主题里灌垃圾数据。在 Dashboard 的“认证”里加一个用户名密码，ESP32 连接时带着这两个字段去连，服务端校验通过才放行。

4.3 数据库选 MySQL 还是 TDengine

设备数据存哪，我一直建议分阶段看。

初期传感器少、数据量小，MySQL 完全够用。建一张表，字段就是时间、塘口、水温、溶氧、pH。查询的时候按时间筛选，画曲线没问题。但跑过两三个月以后，你会发现查询越来越慢，因为原始采集数据的量级已经上来了，而且这种“指标+时间”型数据本来就不适合关系型数据库。

中期直接上 TDengine，它是专门为时序数据设计的。同样的查询，在 TDengine 里走超级表，按池塘打标签（tag），按时间自动分片，秒级响应。我用 Docker 部署 TDengine，然后建一张超级表：

CREATE STABLE sensor_data (ts TIMESTAMP, water_temp FLOAT, do_value FLOAT, ph_value FLOAT) TAGS (pond_id INT);

以后每个塘口的设备插入数据时，带上 pond_id 这个 tag，查询按塘口过滤就走索引，速度非常快。告警联动、曲线展示，全部走 TDengine 的 REST API 或者连接器，稳定性很好。

4.4 Node-RED 编排告警与控制逻辑

Node-RED 是这套系统里最灵活的部分，我把它比作“胶水”：左边接数据，右边接动作，中间画一条条连线就是业务逻辑。

我插一条 MQTT in 节点，订阅主题lobster/+/sensor/do，收到溶氧数据后就进入 Function 节点做判断。判断逻辑不复杂：

• 如果溶氧值小于 3mg/L，持续三分钟未恢复，触发告警；
• 告警动作有两个：发微信通知给养殖户（通过企业微信机器人 Webhook），同时给继电器控制节点下发“开”指令。

控制节点的实现方式很直接。ESP32 上挂了三个继电器，Node-RED 往主题lobster/pond1/cmd/pump1发一条{"cmd":"on"}，ESP32 收到消息后拉高对应 GPIO，继电器吸合，增氧机通电。整个过程从发出指令到设备执行，服务器的日志记录清清楚楚，还能回溯每次开机的历史记录。

Node-RED 的可视化画布上手很快，逻辑修改不需要改代码。有一次我发现高温天溶氧跌得快，原来 3mg/L 的阈值太低了，直接在界面上改成 4mg/L，保存部署，30 秒内生效。

4.5 可视化面板展示与告警

数据存进去了，规则也在跑，最后一步是让数据“看得到”。我选用 Grafana 接 TDengine 数据源。Grafana 的社区插件里有一个 TDengine 数据源，装好以后配置连接，就能在面板上拖出趋势图。

我的面板分了三个区块：第一块是实时数据，当前各塘口的水温、溶氧、pH，大红大绿一眼看出状态；第二块是过去 24 小时曲线，看有没有异常的尖峰或断崖；第三块是设备状态，各个采集点在不在线、继电器开还是关。

告警这部分，Grafana 本身也有一套告警功能，但我实际用下来更喜欢 Node-RED 那边处理，因为可以实现“连续 N 次超标才告警”这种防抖逻辑。Grafana 的告警适合做“面板数据很久没更新”这种系统层面的兜底，两边的分工就清楚了。

一个习惯分享：每一条告警都附带上当前数据和阈值。比如“塘口1溶氧 2.8mg/L，低于 3mg/L，已自动开启增氧机”。养殖户收到消息不用再打开手机翻半天，处理效率高很多。

5. 核心功能实现：告警与控制一例

空谈架构没用，我挑“溶氧告警与自动增氧”这条链路完整拆解一遍，因为这就是整套系统价值最集中的体现。

5.1 水质数据看板怎么搭

先看数据怎么到看板。ESP32 每次发布消息，EMQX 把消息转发给 Node-RED，Node-RED 解析 JSON 后，通过 TDengine 的 RESTful API 插入数据库。数据链路全通以后，Grafana 每秒刷新一次查询最新一条数据，渲染成大数字卡片。

这个看板实际上不光是给你看的，它更大的作用是我离开塘口时，能随时掏出手机确认“塘里没事”。我甚至设置了定时截图推送到群里，到点主动汇报，比让家人去塘边跑一圈省事太多。

5.2 溶氧告警规则设计与参数计算

溶氧设备的阈值不能拍脑袋定，得结合小龙虾的习性来算。小龙虾蜕壳高峰期对溶氧敏感，低于 5mg/L 开始生理应激，低于 3mg/L 有窒息风险。夏季闷热天，水体溶氧消耗快，所以我设置了三档规则：

另外，溶氧值还有一个特点：不同时间点的正常范围不同。凌晨 4 点到 7 点是一天中溶氧最低谷，这时候报警阈值我会稍微调低一点，避免一晚上不停误报吵醒人。规则引擎里我把设备的“实时溶氧”和“所处时段”组合判断，实现这一层动态阈值。

5.3 远程控制增氧机的完整链路

控制链路的完整流程走一遍：

1. Node-RED 的 Function 节点发出{"cmd":"on"}；
2. 这JSON被发到lobster/pond1/cmd/pump1主题；
3. ESP32 在循环中订阅这个主题，收到消息后解析 JSON；
4. 如果cmd是on，就digitalWrite(relayPin, LOW)让继电器吸合；
5. ESP32 同时发布一条状态消息lobster/pond1/device/pump_1/status，内容是{"state":"on"}；
6. Node-RED 收到状态回执后记录到数据库，并在 Grafana 上显示增氧机当前状态。

注意增氧机不能靠“开”指令撑一辈子。我加了一个看门狗逻辑：开启 30 分钟后，主动查询溶氧有没有恢复到 4.5mg/L 以上，恢复就自动关机，没恢复则再发一条告警，提醒可能是设备故障或水质恶化。否则增氧机开一晚上，虾没死，电费先把你心疼死。

5.4 手机离线时也能收到通知的几种姿势

告警推送到手机上，最省事的是企业微信机器人：创建一个群，加一个 Webhook 机器人，Node-RED 往那个 Webhook 地址 POST 一段文本，就能让群里所有成员收到消息。优点是免费、配置快，缺点是你得用企业微信。

如果要求手机装个普通 App 就能收，可以接“Server酱”，它提供一个 URL，你往里面塞内容，它推送到你的微信。配置比企业微信还简单，适合单人的系统。我个人建议先用企业微信，等有需要再扩展。

有些养殖户习惯听电话，那可以加一步：Node-RED 调用云商的语音通知接口，检测到危险溶氧就自动打电话。考虑到电话费比微信消息贵，这个我放在第二级告警里，只有连续两次微信告警没被点击确认时才触发。

6. 实测中遇到的坑与排查手册

这一段是我认为全文含金量最高的部分。方案文档到处都是，踩坑经验只有下过水的人才有。

6.1 设备掉线与数据中断

跑了一个多月，塘口设备偶尔会“失联”，看板上的曲线突然断掉。排查路径我总结了三条：

• 先看 ESP32 的板载 LED 状态。如果板子都没亮，电源出问题了，塘边的 12V 适配器在潮湿环境容易先挂。
• 再看 Wi-Fi 信号。ESP32 在室外空旷地方还行，装进防水盒以后信号衰减严重，最好外接一个天线，或者干脆用 4G DTU 模块。
• 最后看 MQTT 心跳。EMQX Dashboard 里能看到每个客户端的连接状态和最后活跃时间。如果显示断开，大概率是网络问题导致长连接被踢了。

ESP32 程序里要写自动重连的逻辑，不能断了就死等。我的代码里每 5 秒检查一次 WiFi 状态，断开就WiFi.reconnect()，MQTT 断开就重新发起连接。上线至今，除了停电，没再出现过一次需要手动折腾的失联。

6.2 MQTT 连接被服务器防火墙拦了

这个坑极其经典。本地测试 MQTT 连接一切正常，一换到塘口的 4G 网络就连不上服务器。查了半天，是腾讯轻量服务器控制台的防火墙规则没放行 1883 端口。

这里提醒大家，轻量服务器有两层“防火墙”：一层是腾讯云控制台里的防火墙规则，得把 1883、8083、8084、18083 这些端口显式放行；另一层是 Ubuntu 系统自带的 ufw，如果没关或者没放行，同样的端口还是不通。两个地方都查一遍，速度比我当时快得多。

6.3 时间序列数据越存越慢

MySQL 跑了一个月，查询曲线开始变慢，原因是数据量涨上来以后没有索引优化。后来切到 TDengine，查询速度问题彻底解决。

如果你不想换库，也有补救方法：在 MySQL 里按天分表，或者定期把 30 天前的数据归档到另一张冷表。不过我还是劝你一步到位用 TDengine，养龙虾这项目后面只会越接越多传感器，与其以后搬数据，不如一开始就用对工具。

6.4 服务器被扫端口暴力破解

开头讲的安全三件套不是吓唬人。我的服务器曾经在不到三天时间里收到几千次 SSH 密码尝试，密码从 "123456" 到 "root" 各种组合都有。后来我把端口改成 6022、禁用密码登录、装好 fail2ban，扫描日志瞬间少了一个数量级。

另外提醒：EMQX 和 Grafana 的 Web 管理界面，不要用默认的 admin/admin。所有暴露到公网的服务，第一件事就是改默认账号密码。别图省事，听到这句话的人都是过来人。

我觉得这套系统的核心价值，是让“经验养殖”往“数据养殖”迈了一小步。传统老师傅的判断依然重要，但数据给了他一个客观的参考系：今天的水温曲线是什么样的，昨天的溶氧谷值出现在几点，这些信息比“水有点浑”准确得多。

跑了一年下来，最让我感慨的不是技术本身，而是养殖户态度的转变。最开始他们觉得这玩意儿是花架子，直到有一回设备在夜里 3 点发出溶氧过低报警，自动开了增氧机，第二天一塘虾完好无损，隔壁没装系统的塘浮头了一角。从那以后，连隔壁塘的农户都跑来问怎么装。

如果你也想动手做，我的建议是别一上来就追求全套传感器。先拿一个最简单的组合跑通闭环：一个水温传感器 + 一台轻量服务器 + 微信告警。数据能上来了，再慢慢加溶氧、加 pH、加自动控制。最小可行系统跑通了，后面每加一个部件，都只是锦上添花的事情。