这句话会得罪很多人。但我还是要说。

一个真实项目

去年，一个客户找我做技术咨询。他们的车联网平台上了微服务，拆了30多个服务。

我问他：为什么拆这么多？

他说：微服务架构啊，高内聚低耦合，独立部署，技术异构。

我说：你们多少终端？

他说：5000台。

5000台终端，30个微服务。平均每个服务承载166台终端。

微服务在车联网的典型问题

第一，网络开销。

微服务之间通过HTTP或gRPC通信。一次位置上报，网关服务要调用车辆服务、报警服务、存储服务、统计服务。4次RPC调用，每次至少1毫秒，总共4毫秒。加上网络抖动，可能10毫秒。

单机部署，这些调用都是函数调用，纳秒级。

第二，分布式事务。

位置上报要同时写轨迹库、报警库、统计库。微服务架构下，这是分布式事务。要么用TCC，要么用最终一致性。复杂度直线上升。

第三，运维复杂度。

30个服务，30个部署单元，30个日志文件。排查一个问题，要在多个服务之间跳转。没有完善的链路追踪，根本查不下去。

第四，资源浪费。

每个微服务一个JVM，一个JVM至少占200MB内存。30个服务就是6GB，还没算业务逻辑。5000台终端的平台，服务器成本比终端还高。

车联网平台的正确架构

车联网平台的核心是什么？是接入、存储、查询。这三个是IO密集型，不是计算密集型。

IO密集型的系统，适合单体架构。一个进程，处理所有请求。没有网络开销，没有分布式事务，没有运维复杂度。

JTE就是单体架构。核心引擎一个二进制，所有功能在里面。模块化通过代码层面的接口实现，不是通过服务拆分。

go 复制 下载 // 模块化通过接口，不是通过服务 type Storage interface { SavePosition(ctx context.Context, pos Position) error QueryTrack(ctx context.Context, vehicleID string, start, end time.Time) ([]Position, error) } 需要换数据库？换一个实现。需要加AI？加一个模块。都在同一个进程里。

什么时候该拆微服务

如果终端数量超过100万，单机扛不住，可以拆。

拆的时候也不是按业务拆，是按接入层和业务层拆。接入层无状态，可以水平扩展。业务层有状态，按终端分片。

但大多数车联网平台，终端数量在几万到几十万之间。这个量级，单体架构绰绰有余。

为什么微服务在车联网流行

两个原因：

第一，技术跟风。互联网公司用微服务，我们也用。但互联网公司的流量和车联网完全不是一个量级。

第二，KPI驱动。架构师要体现价值，就要搞点“先进”的东西。单体架构显得没技术含量，微服务显得高大上。

结果就是，5000台终端的平台，拆了30个服务，服务器成本翻了三倍，故障率翻了五倍。

总结

架构没有优劣，只有合不合适。车联网平台的核心是稳定、低延迟、好维护。单体架构在这些方面，比微服务有天然优势。

JTE选择单体 + 模块化，不是技术落后，是场景决定。

项目仓库：

Gitee：suoten/jt-engine GitHub：suoten/JTEngine