Java Go Node 哪种语言最适合做物联网平台开发

性能这些语言都不在话下，主要看哪个出问题了能修问题

@hhjswf 大多数 spring boy 写不了 netty

@liuhan907 #28

吾辈在 TCP 异步 Socket 高并发的情况下滥用了异步回调处理收到的数据，响应时间拉长到无法接受，排查发现是调度延迟。
后来在 SocketAsyncEventArgs 回调把要处理的东西封装成工作项，放进自己维护的线程，用线程安全队列排队处理，这才扛得起来。

这算 CPU 密集吗🤔 (不过这倒是和主题的物联网沾上边了

中间件用 go ，平台化业务用 Java
ssr 和 bff 用 node

好全用上了🐶

@coder001

> WOW ，看来我井还没有没落，没太仔细读回帖就先莽了 建议不要太过于 “迷信”(🤔?) Task/async/await 的调度机制，到头来可能还不如自己撸线程来的快 :p

协程主要是为了 IO 密集场景，用异步代替阻塞，用更少的线程做更多的事，IO 密集场景收益肯定更大的。对于单个 task 有延迟的问题肯定是客观存在的，毕竟线程数量更少了 ，任务多了线程任务队列就堆积了，解决方案也可简单，适当提升线程池线程数量，避免线程池饥饿就可以了，很多项目都会设置 MinThread 。

用 Java 的 Vertx ，容易写好多，和 Go 和 JS 差不多，
写 Vertx 就一种写 JS 的感觉，太舒服了。而且性能和 Netty 一样都是顶尖水平

@INCerry #45
当然尝试设置最小线程数量，但收效甚微，而且 CPU 使用率显著上升

网络应用是 go 的主场。

微软刚出了个 DeviceScript ，TypeScript 的子集，专门用于物联网开发。

@coder001 我对于这块比较有经验，如果后面有遇到类似的问题，可以抓个 trace 和 dump ，一起分析下，总得来说那块应该不会有很大问题。

@coder001
我比较好奇你的场景使用了多少连接数和 PPS ，还有吞吐量。或者说你对延迟的需求很高？

go 可以的,相对简单,并发用协程

@INCerry #50
@liuhan907 #51
先谢过两位

目前用若干个绑定了队列的线程，每次有回调就挑队列长度最短的分配工作项，压测看起来数据没这么难看了
压测用 5 万个 TCP 同时打进去，PPS 没测量，几乎所有 PDU 都小于 1400 ，姑且按 PDU 计算的话，极端状况下往返加起来可能会达到（ x4 ） 20 万 PDU 每秒。
协议超时时间是 30 秒，但超过 10 秒就会被称为数据不好看

@coder001
怎么说呢，只有 5W 连接的情况下这个数据感觉有点奇怪。你的原始测试代码还有留存么？

@liuhan907
目前性能数据已经可以接受，就不放出来丢人现眼了 _(:з)∠)_

@coder001
我只是好奇为什么数据会这么差，因为和我之前压测的数据比差的不少。
学习一下，以后避坑（

@liuhan907
那就简单来说说 (＾ o ＾)ﾉ

测试环境是 linux k8s 集群，所在节点 4 核 16G （后来加到了 8 核），非独占，还有一些其他东西跑，但不占太多 CPU

最开始的版本是图省事，嫌复杂懒得用 SocketAsyncEventArgs （ SAE ），监听开单线程阻塞，接收就用 Socket.Select 方法批量轮询，把筛出来的 Socket 滥用 Task.Run 处理接收和协议解析，可以想象线程池会有多窘迫，再多的 MinThread 也处理不过来，只会徒增 CPU 使用率。

单线程阻塞监听真是太天真了，大量 TCP 同时发起的时候根本 accept 不过来，后来改用 SAE 监听，一上来就安排 1024 个躺在端口前迎接，回调不直接处理，而是放进自己创建的工作线程排队创建应用层会话，加入会话管理器。这下几乎没有连不进去的了。

后来多几次改进调优就变成完全 SAE 了，监听和接收还有发送全都走 SAE ，只是 SAE 的回调依旧信不过，不在这里做过多的处理，而是自己开线程排队，也能观测一下队列数量来评估性能。

总算是稍微拯救了一下这难看的数据。

要问为什么自己撸 Socket 而不用现成框架，我不想回忆被 SuperSocket 折磨的那些年 _(:з)∠)_
辩解：协议单一，而且相对简单，可以自己来❌

@coder001
搞明白了。Select 这个就不多说效率没眼看。至于 SAE 那个确实是专用 IO 线程更好。
我建议你看一下 asp.net core 现在使用的那个抽象模式以及实现。我认为应该是目前比较好的答案了。
主要代码在 aspnetcore 项目 src\Servers\Kestrel\Transport.Sockets\src 下面。

我看大家都在说并发用 go 的协程.. 其实 go 的协程在 socket 量级 10w 这种, 如果你每个 socket 都开 2 个 goroutine, 20w 个协程, go 的调度压力很大的, 这种情况下不太适合有栈协程, 所以你看 go 里也有许多框架封装后就是 netty 的线程模型的样子. 几个 goroutine 就能处理所有 socket 的 IO.

每个 socket 开两个协程, 写写玩具, 量不大的应用可以, 量上去了就不是这样玩的了.


还是选择自己擅长的. 稳就对了.

@liuhan907 #58
源代码看起来有点枯燥，倒是发现原来 core 内置的 K 服务还能处理自定义 TCP 这就有意思了，正好有个新的小规模项目可以走这条路整整😋

https://github.com/davidfowl/MultiProtocolAspNetCore/tree/master/KestrelTcpDemo