用TCP/IP连接上万个充电桩并实时监控运行状态!

qq_37350066 2018-01-26 09:22:33
每个桩有自己的独立IP ,系统通过TCP/IP去连接每个电桩
我没做过类似的项目,开始想着用WCF 去做,但几万个桩,我不可能做几W个连接,看过一些文章类似说可以用端口去实现,但也没具体点的思路和例子,并且中间还有很多性能上的考虑和并发的存在(桩还会接受预约充电),希望高手大师们给小白点思路,指引下,谢谢了!
...全文
2831 17 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
17 条回复
切换为时间正序
请发表友善的回复…
发表回复
生财 2019-03-30
  • 打赏
  • 举报
回复
这个想法很清奇,用一个服务器向几万个设备发信息?光数据传递的各种异常情况,都不一般人能搞定的
  • 打赏
  • 举报
回复
技术本来百无禁忌,问题是要了解每一个人所处的技术的层面、知道其方案出发点。如果你对原理描述不充分,那么就会产生歧义。 所谓“几万个充电桩、我做几万个 WCF" 服务这并没有什么。只不过是 WCF 服务是个低效的、复杂的、冗余的东西,既然是充电桩设备中要提供服务,那么使用普通的 http post 服务就行了,不用考虑 WCF。那么更重要地是你怎么在充电桩中实现服务,这要看你的已知的技术基础,而不是靠 csdn。你如果对于充电桩厂家厂家的文档"吃透",或者你就是充电桩厂家,会写一个标准的技术文档,那么这中开发能力就不成问题。否则你就不会用你的上位机访问充电桩,你只会说充电桩要访问服务器。
  • 打赏
  • 举报
回复
引用 13 楼 拜一刀 的回复:
我为什么要访问充电桩,ip随时变,设备随时增加,肯定是设备往服务器发啊
这不是问题。只要人有架构设计,充电桩可以访问一次某个登录服务,这样就知道在线充电桩的 IP 了。这根本不是问题。 问题是,架构设计到底是什么呢?这里有设计师没有?还是只有一个初学?
胡萝卜白 2019-01-19
  • 打赏
  • 举报
回复
引用 2 楼 wanghui0380 的回复:
前置采集(采集,数据清洗,限流发布)---分布缓存(redis)--数据处理(spark)--mq事件通知(设备状态迁移,异常事件报警)---最后是应用层(展示数据,处理事件报警,处理业务指令,处理报警预案调度)
用Spark 觉得有点大材小用了
Jock Chen 2018-10-23
  • 打赏
  • 举报
回复
可以使用DTU的方式来实现,数据上传。
拜一刀 2018-10-23
  • 打赏
  • 举报
回复
我为什么要访问充电桩,ip随时变,设备随时增加,肯定是设备往服务器发啊
JimCarter 2018-10-23
  • 打赏
  • 举报
回复
6楼正解, 先了解下基本的物联网通信协议,如MQTT
luofuxian 2018-03-22
  • 打赏
  • 举报
回复
设备一般是客户端,自己的程序是服务端;
by_封爱 2018-01-26
  • 打赏
  • 举报
回复
你是服务端还是客户端你都不知道.. 所以根本没有继续深入的必要.. 你先看下你所谓的"设备"的工作模式吧.. 正常来说.这么多的东西 怎么可能给他们每个设备配置一根独立网线? 不存在的.. 那得多浪费资源. 所以基本上 他们是"客户端".可以通过电脑配置访问"服务端"的地址.以及周期以及工作模式. 比如是应答模式 还是主动上报模式 周期是多少 服务器IP端口是多少 采用tcpip还是udp. 所以你要开发的.是"服务端" 来接收这些设备上报的数据...
wanghui0380 2018-01-26
  • 打赏
  • 举报
回复
https://cloud.baidu.com/solution/iot/index.html?track=cp:nsem|pf:pc|pp:iot|pu:brand|ci:|kw:108715
wanghui0380 2018-01-26
  • 打赏
  • 举报
回复
其实,你可以去百度申请IOT账号,试用一下。看看人家百度iot都有那些方案给你。然后你就知道从哪里下手了 ps:iot模块各大云服务提供商都有完整解决方案,微软云,百度云,阿里云,腾讯云,谷歌云----都有IOT成品套件组。虽然你不一定用他们的,但是看看人家都怎么做的,也是好事
ghostalker 2018-01-26
  • 打赏
  • 举报
回复
我也觉得应该是你的充电桩主动上报 自己的情况 给服务端。 各个超市 银行 不都这样么 有时你会发现那些机器网络不通 那是那些机器主动上报 发现网络不通 报警
  • 打赏
  • 举报
回复
服务端主动去询问太耗性能了吧,不应该是充电桩主动发请求给服务么
wanghui0380 2018-01-26
  • 打赏
  • 举报
回复
上面是正常的完整设计,根据情况你可以自己删减。比如只要 采集+mq+应用,其实也可以玩
wanghui0380 2018-01-26
  • 打赏
  • 举报
回复
前置采集(采集,数据清洗,限流发布)---分布缓存(redis)--数据处理(spark)--mq事件通知(设备状态迁移,异常事件报警)---最后是应用层(展示数据,处理事件报警,处理业务指令,处理报警预案调度)
  • 打赏
  • 举报
回复
这里你把自己的定义弄反了所以你才头疼。 首先你不是服务器端,或者说你不是传统意义上的服务器端,你是一个集中操作端和集中记录端,具体实际的服务端在充电桩上。 搞清楚定义就好办了: 1、你需要掌握充电桩的状态,这个状态应该是循环访问充电桩获取心跳信息,如果充电桩有心跳功能能够访问你当然更好了,你只需要被动收集充电桩状态即可。 2、使用你的服务端统一记录充电桩状态log等,并在你的服务端生产一张充电桩状态表。 3、用户访问你的时候根据充电桩状态表(心跳+你服务端预约)返回给用户充电桩状态表,接受用户预约,预约后写入你的充电桩状态表。 4、根据新的需求可能开发充电桩开关控制等相关功能,这其实就是给ip发送指令的操作。
  • 打赏
  • 举报
回复
引用 楼主 qq_37350066 的回复:
每个桩有自己的独立IP ,系统通过TCP/IP去连接每个电桩
基本的通讯协议在哪里?你是否研究了充电桩厂商的编程文档了?

17,748

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术 .NET Framework
社区管理员
  • .NET Framework社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧