前言

注：本文只是通过充电桩项目log里的服务包名对整体IoT服务进行技术猜想，可能与实际服务差距特别大。就像只知道某地铁站A为已知某节点，去猜测整个地铁线路一样，只是理想状态，实际可能会因为各种需求，做出很多妥协和改变。

目录

对山东某充电桩服务的逆向分析(一) 对山东某充电桩服务的逆向分析(二)

正文

在群里看到甲方某塔丢过来的log记录（已对log进行了处理，连时间都是假的），假设设备终端20万。

2021-04-14 19:11:37.504 [test.proc.CmdRecvBusiProcessor:287] -- [0.0.0.0:8888] response: 「我是心跳包」
2021-04-14 19:14:58.367 [test.server.ServerHandler:59] -- [0.0.0.0:8888] request: 「我要断电!」
2021-04-14 19:14:58.368 [test.service.KafkaProducer:38] -- receiverTcp : 「我要断电JSON!」
2021-04-14 19:14:58.369 [test.proc.CmdRecvBusiProcessor:374] -- [0.0.0.0:8888] response: 「成功断电!」

上面的log除了能看出来用了Kafka服务和TCP通讯，看不出任何有用的信息。那么就围绕这个Kafka进行猜测吧。

猜测1：同时使用TCP和MQTT独立使用

既然设备终端数量20万，那么不存在考虑单台服务器的情况了。猜测的架构图如下：

上面的架构图如果继续细分是比较恐怖的，比如：Kafka做集群，ZooKeeper做服务治理；MySQL做主从、读写分离、分库分表，甚至用不用MySQL都成问题。系统复杂程度成几何倍数上升，运维压力也会比较大。

继续猜测一个简化版：

End

困了，睡觉，明晚继续。