本文探讨了基于旧版dcos marathon平台的物联网平台在处理长连接服务时面临的挑战。由于marathon-lb在容器集群变动时会更新配置，导致haproxy进程增多。文章作者希望了解其他架构的实践经验，并提出了采用C++或Golang编写长连接服务，直接运行在宿主机的方案。文章旨在寻求更优的架构设计，解决物联网平台中长连接服务的性能和管理问题。

💡 现有物联网平台采用dcos marathon平台，通过marathon-lb提供服务访问。

⚠️ marathon-lb基于haproxy，支持HTTP和TCP服务，但集群变动时会更新配置。

💣 集群内长连接服务重启或变更时，marathon-lb会重新应用配置，导致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 一下。

请大神赐教。