有请 Rust 方辩手登场 曾经做过 lorawan, 我们使用的是 mqtt + go + nats 组建的核心网. 当时选择使用 go 也是因为其网络能力强一些, 当然如果但是 rust 成熟些, 我们可能就选用 rust 了, 因为 leader 是 C 出身...... iot 用 java 需要大量 netty 的相关技能, 如果研发水平参差不齐的话, 建议用 go另外用 node 是图啥... 10W 在线量一个 go wbesocket server 实例就够了. 我们最近在跑百万连接压测: https://github.com/lesismal/go-websocket-benchmark go 用 go 吧。 多协议兼容也很方便。 性能也没啥问题 go ，绝对是 go toB 我建议你用 Java, Netty 有大量现成协议支持. mqtt 什么的也有现成方案.当然 10w 的量级,你说的这几个任何一个都可以完成.. 关于量级：大项目会私有化部署，不会走我们的云平台。云平台上能做到 10W 的话我们项目也有几千万的体量的了，到时候领导就会重视起来，研发投入就不会再是个问题。 非常感谢各位的解答🙏 楼主限定了几种语言，我肯定用 C#，其实几十万同时在线这种需求对于现在有协程 /异步 IO 的开发语言压力都不大，工业物联网这个.NET 成熟和开源的项目蛮多了，基本支持各种协议和驱动，包括一些 PLC 、串口设备都支持。举个例子： https://github.com/iioter/iotgateway 我推荐 swoole 物联网绝对 go 必须 go 请问下 MQTT Broker 的选型是哪个？我司目前用的是 EMQX 开源版，同时在线数量是 3.5 w 。 必然用协程模型，开发最方便的就是 go 了 推荐用 go ，做过类似的物联网项目，服务端对接不同设备，解析二进制协议用 go 比较方便，客户端如果是带 OS 的，用 go 编译出多架构的程序也比较方便 都能实现那建议用自己熟练且相对热度不高的，既然有决定权不背锅，技术就掌握在自己手上。 看来用 dot net core 的只有我一个？ @INCerry #11 WOW ，看来我井还没有没落，没太仔细读回帖就先莽了建议不要太过于 “迷信”(🤔?) Task/async/await 的调度机制，到头来可能还不如自己撸线程来的快 :p @smallmin97 请教一下，请问你们用的什么中间件存储数据呀🥹 用 ceo cio cto 最擅长的… go 可以用 tinygo 这个嵌入式编译器 https://tinygo.org/ erlang/elixir ?? 推荐个最近发现的物联网开源的项目。https://github.com/jetlinks/jetlinks-community支持统一物模型管理,多种设备,协议适配(TCP,MQTT,UDP,CoAP,HTTP),都很全。 go 需要超高的并发性能 @zhuangzhuang1988 #23总感觉现在只有游戏服务器用 erlang 了。。其他好像很少听到有用 erlang 的项目。 c10k 你上个 python 都没问题......... @coder001 除了纯 CPU 密集的东西---撇开 TPL 这套不谈---可能自己用线程会更好，其它的场景下还有默认调度器劣于手动线程的么？ 纯 php 的 workerman 也可以，甚至提供了用于轻松实现分布式架构的框架 gatewayworker ，轻松通过加机器来处理大流量。 拿 go 写简单点 建议 Golang ，不考虑成本直接上 Rust 。 go 开发简单，性能到位 K8s 原生，Go 写的物联网开发平台不考虑一下？https://github.com/Edgenesis/shifu 物联网都是有系统的吗？怎么动态语言都能用 @yazinnnn node 擅长的就是 IO 密集型任务。 同建议 go 物联网，建议上 Erlang 。实时性比较好。 没人提 C# 么... 做 IoT C# 简直不要更合适好吧... mqtt 十万台毛毛雨了吧 @yazinnnn netty 框架封装了，做起来反而容易。go 啥都得自己亲力亲为。。 性能这些语言都不在话下，主要看哪个出问题了能修问题 @hhjswf 大多数 spring boy 写不了 netty @liuhan907 #28吾辈在 TCP 异步 Socket 高并发的情况下滥用了异步回调处理收到的数据，响应时间拉长到无法接受，排查发现是调度延迟。后来在 SocketAsyncEventArgs 回调把要处理的东西封装成工作项，放进自己维护的线程，用线程安全队列排队处理，这才扛得起来。这算 CPU 密集吗🤔 (不过这倒是和主题的物联网沾上边了 中间件用 go ，平台化业务用 Javassr 和 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 @coder001 aspnetcore 的代码可真是不容易看懂，稍有些绕。这个自定义处理 Tcp 我还是在 SignalR 的源码里翻出来的 (不过后来我就直接用 ws 了 @liuhan907 能用 ws 是我的梦想，一直在做梦，苦于设备目前只支持 TCP 接入如果走 ws 就不需要专门开一种 TCP 服务端了，做好高可用使劲加 Web 服务器就成） @liuhan907 另外，我看 Kestrel 源代码时注意到监听是单线程异步，这可能会 accept 不过来，经验告诉我如果几万 TCP 同时打进去，能进去的可能会只有几千个https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Transport.Sockets/src/SocketConnectionListener.cs#LL67C64-L67C64 @coder001 以我对 IOCP 的认知，Windows 上应该不会发生这个问题。因为 Accept 慢主要是慢在创建 Socket 上，而 IOCP 创建是系统内核在处理这个问题，不会拖慢应用。至于 Linux 上，鉴于我对 epoll 的熟悉程度不如 IOCP ，所以我不是很确定。但是曾经读过 devblog 的文章，里面表示 Linux 上的实现是 epoll + 线程池，所以我觉得可能也没有你担心的问题，可能。 @liuhan907 压测了一下 Kestrel 的 TCP 服务端，花了几秒钟来 accept 两万 TCP ，虽然有部分重连，但还是全都连上了看来以后可以用它，妈妈再也不用担心我维护不好 Socket 和 SAE 了，乐。 熟悉哪个选哪个。不用担心，99.99%情况下， 语言不会成为瓶颈；0.01%情况下业务增长到那个程度早重构了。 @coder001 说不定你再改改配置和 GC 选项，连重连都没了（ @liuhan907 回来报喜正经项目换 kestrel 重构之后，目前压测连接承载能力摸到 3 万了，需要花一点时间来 accept ，问题不大～