6.4 工程小结与延伸阅读
6.4.1 工程收束：从原型到生产的关键决策
把一台设备连上网、将数据发到服务端，一天就能跑通。但这条路扩到三百台设备、七个工厂、以及凌晨两点必须响起的告警——考验的不是对单个协议或框架的熟练度，而是做取舍的能力。
本章的代码片段、架构图和检查清单，最终都指向同一组问题：在哪个节点、用什么技术、做多深。下面把这三层决策的核心判断标准拎出来，不另讲新的例子，而是给出一张可以贴在工位上的对照表。
语言选型。Python 让原型阶段的效率最大化——一个脚本就能读串口、用 paho-mqtt 推数据到 Broker、调 REST API。设备、网关、服务端都用同一种语言，团队在早期不必分批招募不同技术栈的人。但产线系统一旦要求多租户隔离、长连接管理、每秒千级别并发，Java 的 JVM 调优工具和 Spring Cloud 生态的生产就绪特性就补上了 Python 单体在运维阶段的短板。实际中常见的分工是：Python 做协议驱动原型与验证，Java 做核心数据服务与集群管理，各取所需。少数场景——边缘网关上的高并发 I/O——会用到 Go，这一分支本章未展开，但值得知道它在那里。
通信协议选型。把 MQTT、REST、gRPC 当作“哪个更好”来比较，方向就错了。它们在物联网系统中各有专责：MQTT 适合设备或网关与 Broker 之间的异步消息；RESTful API 适合第三方系统、Web 前端和手机 App 等北向集成；gRPC 适合服务间的强类型调用与流式通信。gRPC 与 REST 的吞吐和延迟谁更优，取决于负载大小、连接复用、代理链路和实现，不能脱离基准测试下定论。“南向 MQTT、北向 REST、内部 gRPC”是一种常见组合，不是所有系统必须照搬的分层。
架构选型。微服务不是起点。设备类型少、日数据量有限、团队规模较小时，单体架构通常有更高开发效率。关键是在单体内部保持明确的代码边界——用 package 切分协议适配、数据清洗、业务处理等职责，并通过架构测试强制禁止 import 循环。当某个模块需要独立扩缩容，或不同团队需要各自部署维护时，才按领域边界剥离成独立服务。IoT DC3 当前以 Gateway、Auth、Manager、Data、Agentic 和协议 Driver 组成微服务架构；位号命令属于 Data，经 RabbitMQ 投递到 Driver，并不存在独立命令服务。
三者之间的相互制约：语言与运行时会影响并发模型和运维方式。Python 可以通过异步 I/O、多进程或原生扩展承载并发，Java/Netty、Go 和 Rust 也各有适用边界，不能只用 GIL 给语言能力下结论。协议选型会改变接入边界，但设备协议应由 Driver 或专用接入服务终止；IoT DC3 的 Gateway 统一承接平台 HTTP 入口，并不代理所有南向协议。架构选型则决定各组件能否独立扩缩容。三个维度需要结合真实负载、故障模型和团队能力一起验证。
服务网格与 GitOps 的成熟度定位。可以把云原生工具链的演进看作一条成熟度阶梯：部署侧从手写脚本、CI/CD 流水线，走到以 Git 仓库为唯一事实源的声明式 GitOps；服务治理侧从各服务内建的 SDK 能力、网关统一治理，走到服务网格。IoT DC3 当前停在“流水线 + 网关与 SDK 治理”这一档，对它的规模已经自洽。经验法则是：只有当服务数量与团队数量增长到治理规则靠升级 SDK 已经推不动——比如多语言写成的驱动需要统一 mTLS 与流量策略——服务网格的收益才开始覆盖控制面的常驻成本；只有当部署环境多到变更审计必须以 Git 提交记录为唯一事实时，才值得引入 GitOps。它们是规模化之后的增强项，不是从单体出发的必选项；提前引入的代价是多一条常驻的控制面链路要养，收益却兑现在未来。
延伸阅读推荐
- 项目源码：IoT DC3 开源项目（AGPL-3.0，GitHub: pnoker/iot-dc3）。它把本章讨论的 MQTT 驱动、Spring Cloud Gateway、gRPC 服务调用、RabbitMQ 消息集成到了同一个代码库，适合作为工程化学习的参照物。建议从
dc3-driver子模块看起，那是协议适配的实物集。 - 书籍：Sam Newman Building Microservices（第二版，O'Reilly 2021），第 2 章讲服务边界的确定，第 10 章讲从监控走向可观测性，跟本章检查清单直接对应。
- 协议标准：最新版 OASIS MQTT 规范、gRPC 官方文档中关于 protobuf 服务定义的风格指南。如果想写一个只能跑一次的协议适配器，读规范就够了；如果想让它跑一年不出问题，需要读规范旁边的“常见陷阱”和“错误码解释”附录——这些资料通常从规范的 GitHub issues 中才能找到。
最后一项建议：打开你上周刚写完的代码，找到最常被调用的那个 MQTT 回调函数，检查它是否处理了网络重连时的重复消息，以及 QoS 2 四阶段交互（PUBLISH → PUBREC → PUBREL → PUBCOMP）中任一确认丢失后的恢复。QoS 1 才使用 PUBACK，不能把两套状态机混为一谈。处理重连、退避、重试、报文标识符和业务幂等的这些代码，才是软件从原型走向生产的分水岭。
第 6 章把前五章的设备与数据底座变成了可构建、可部署、可观察的软件系统。下一章引入 Agent 时，这些工程边界不会消失：模型只能通过明确的 Tool 和数据接口使用平台能力，重试、幂等、权限与回执仍由确定性代码负责。
对四个词而言，本章铺开的是“推理”的运行面：没有可部署、可伸缩、可观测的底座，再好的模型也只能活在演示里。