文章探讨了基于旧版DCOS Marathon平台的物联网平台在处理长连接服务时面临的挑战。由于使用Marathon-lb（基于HAProxy）进行服务暴露，容器变动时HAProxy配置更新导致旧连接持续存在，造成资源浪费。作者寻求针对物联网设备TCP长连接场景的架构优化建议，并提出C++或Golang编写的宿主机服务搭配负载均衡的理想方案。

📡 现有物联网平台基于十年前的DCOS Marathon平台构建，使用Marathon-lb（HAProxy）对外提供服务。

🔄 Marathon-lb在容器集群变动时自动更新配置，更新过程会保留旧的TCP连接，导致HAProxy进程增多。

💡 作者认为物联网设备的长连接需求并不必要，希望优化当前架构。

🤔 作者设想使用C++或Golang编写长连接服务，直接运行在宿主机上，并通过负载均衡进行访问。

目前，有一套物联网平台，采用的是十年前的 dcos marathon 平台。如果想从外界访问容器内部服务，可以通过 marathon-lb 。marathon-lb 是 haproxy 改装的，支持 http 以及 tcp 服务，长连接也可以。但是，每次容器集群内部有变动，marathon-lb 会自动从 dcos master 节点获取信息，并自动更新自己的配置。如果集群里面有长连接服务。在 marathon-lb 因容器服务重启或者其他变更导致变动时，会重新应用一个 haproxy 配置，但是老的连接还可以继续保持。这种策略会造成随着时间的推移，会有更多的 haproxy 进程出现，虽然只是会保持老的 tcp 连接。

可是，在物联网平台场景下，物联网设备通过 tcp 与服务器建立长连接是不需要使用的。

想了解下，大家有没有类似场景，提醒一下笨笨的我，你们是怎么做的架构。

我想，理想中的长连接服务可能是采用 c++或者 golang 编写，直接运行在宿主机吧。前边可以采用 lb 一下。

请大神赐教。