单体架构在工业软件领域曾长期占据主导地位。SCADA、MES、ERP系统多以单体方式构建，所有功能模块编译为一个WAR包或可执行文件，部署在应用服务器上。这种模式在系统规模较小时效率不低——开发简单、部署直接、调试方便。当工业互联网平台的接入设备数从数百台扩展到数万台、数据维度从几十个标签扩展到数百万个标签时，单体架构的结构性缺陷开始显现。
单体架构的瓶颈
部署耦合是第一个问题。工业平台的OT模块（设备采集、协议解析）和IT模块（报表、权限、工作流）打包在同一制品中，发布时整体替换。OT模块需要频繁更新以适配新设备协议，而IT模块稳定运行不需要迭代。每次OT模块更新都触发整体重新部署，IT模块的运行被中断。
扩展困难是第二个问题。单体应用只能整体水平扩展——复制整个实例。但实际负载分布不均匀：数据采集模块CPU密集（协议解析），报表模块IO密集（查询数据库），告警模块内存密集（规则匹配缓存）。整体扩展意味着CPU密集型模块需要多少实例，IO密集型模块就被迫跟着复制多少实例，资源浪费显著。
技术栈锁定是第三个问题。单体应用通常统一技术栈（Java或.NET），而工业平台有混合需求——协议解析用C/C++（性能敏感），数据分析用Python（生态丰富），实时计算用Go（并发优势）。单体架构下，技术栈必须统一妥协。
微服务拆分原则
拆分不是越细越好。工业数据平台的微服务拆分应遵循两条原则：按业务能力划分边界，按数据所有权确定服务职责。
按业务能力拆分，将平台分解为五个核心服务群：
采集服务群负责设备数据接入，内部按协议拆分为OPC UA Adapter、MQTT Adapter、Modbus Adapter等子服务。每个Adapter独立部署，新设备接入只需扩展对应Adapter实例，不影响其他协议。
存储服务群处理数据写入和查询。写入服务和查询服务分离——写入是高频写操作，查询是分析型读操作，两者的资源特征完全不同。写入服务需要高吞吐（每秒百万级数据点），查询服务需要复杂聚合能力。
分析服务群包含流处理引擎和批处理引擎。流处理做实时异常检测和窗口聚合，批处理做历史数据挖掘和模型训练。
告警服务群管理规则引擎和通知分发。规则引擎将设备数据与阈值规则匹配，触发告警事件；通知分发将告警路由到短信、邮件、工单系统。
可视化服务群提供大屏渲染、报表生成和API聚合。这是最靠近用户侧的服务群，需要灵活迭代而不影响后端数据链路。
按数据所有权拆分要求每个服务独占自己的数据存储，不共享数据库。采集服务的数据缓冲在自身管理的Kafka Topic中，存储服务的数据写入TDengine集群，告警服务的规则配置存在独立的关系数据库中。数据所有权清晰后，服务间无共享状态，任何服务故障不会导致数据层面连锁影响。
服务通信模式
微服务通信方式的选择，取决于数据特征和一致性要求。
通信模式 | 延迟特征 | 适用场景 | 工业典型用例 |
gRPC（同步） | 1-5ms | 高频低延迟调用 | 设备控制指令下发 |
REST（同步） | 5-50ms | 管理类操作 | 设备注册、配置修改 |
Kafka（异步） | 10-100ms | 事件流、削峰填谷 | 设备数据采集→存储 |
事件驱动 | 10-200ms | 松耦合通知 | 告警触发→通知分发 |
同步通信适合需要即时响应的场景。设备控制指令从API层到采集层，要求毫秒级响应，gRPC的HTTP/2长连接和Protobuf序列化提供了低延迟通道。管理类操作（设备注册、用户配置）频率低但需要事务保证，REST API的事务语义更清晰。
异步通信适合数据流和事件通知。设备数据从采集服务到存储服务，经过Kafka解耦——采集服务只管写入Kafka Topic，存储服务按消费能力拉取数据，消费速度与采集速度解耦。当设备数据突发增长时，Kafka缓冲削峰，存储服务不会被打垮。
事件驱动架构（EDA）在告警场景中优势明显。告警服务发布事件（设备过温、产量异常），订阅者（通知服务、工单系统、分析服务）各自处理。事件发布者不关心谁消费、消费结果如何，服务间解耦彻底。
数据一致性：Saga与事件溯源
跨服务事务是微服务架构的经典难题。工业场景中，"设备注册+采集配置+告警规则"需要原子性——注册设备时同时创建采集配置和默认告警规则，三者要么全成功要么全回滚。单体架构下一个数据库事务搞定，微服务架构中三个服务各自独立存储，需要分布式事务协调。
Saga模式将长事务拆分为一系列本地事务，每个本地事务有对应的补偿事务。设备注册Saga的流程：注册设备（补偿：删除设备）→创建采集配置（补偿：删除配置）→创建告警规则（补偿：删除规则）。如果第三步失败，Saga协调器依次执行前两步的补偿事务，回滚到初始状态。Saga牺牲了ACID的隔离性，但保证了最终一致性。
事件溯源（Event Sourcing）将状态变更记录为不可变事件序列。设备状态不是"当前值"而是"所有变更事件的回放结果"。这种方式天然适配工业数据特征——设备状态本身就是连续变化的，事件溯源的模型与物理世界一致。但事件溯源增加了系统复杂度，快照机制（Snapshot）是必需的——定期将事件回放结果存为快照，避免每次查询都从初始事件回放。
服务发现与配置管理
服务实例的动态创建和销毁是微服务架构的常态。采集服务在设备接入高峰期自动扩容，在低峰期缩容。服务消费者需要知道实例的当前IP和端口，硬编码地址不可行。
服务发现分客户端发现和服务端发现两种模式。Nacos和Consul同时支持两种模式。客户端发现模式下，消费者从注册中心拉取服务实例列表，在本地做负载均衡（Round Robin/加权轮询/最少连接）。服务端发现模式下，消费者请求经过负载均衡器（如Nginx/Kong），由负载均衡器查询注册中心并转发请求。
工业场景推荐客户端发现模式——减少一跳网络延迟，对实时性敏感的采集和告警服务更友好。健康检查是关键配置：TCP探针验证端口可用，HTTP探针验证业务就绪（/health返回200）。Nacos支持主动探测和被动上报两种健康检查模式，主动探测适合稳定性高的服务，被动上报适合注册频率高的服务。
配置管理需解决多环境配置隔离问题。同一平台在开发、测试、生产环境的数据库地址、MQ地址、设备连接参数完全不同。集中配置中心（Apollo/Nacos Config）将配置与代码分离，配置变更不重新部署即可生效——调整告警阈值、修改采集频率等操作通过配置中心下发，热生效。
TDengine在微服务架构中定位为数据层服务。它自身可作为独立微服务部署，通过标准API暴露查询和写入能力，其他服务通过gRPC或REST接口访问。无需引入额外中间件做数据中转——采集服务直接通过原生连接写入TDengine，分析服务直接通过SQL查询读取数据。数据层的服务边界清晰，不与采集层或分析层产生存储共享冲突。
结语
从单体到微服务的演进，核心收益不是"拆分"本身，而是获得了独立迭代、独立扩展和混合技术栈的能力。工业数据平台的服务化拆分按数据流而非组织结构，通信模式按数据特征而非统一标准，一致性策略按业务容忍度选择最终一致而非强求ACID。
服务发现和配置管理的工程成熟度决定了微服务架构的运维可行性——缺乏服务发现能力，微服务退化为分布式单体；缺乏配置中心，环境管理成为发布瓶颈。在数据层，原生支持标准接口的数据平台可以消除不必要的数据中转中间件，使微服务间的数据流动更加直接高效。
