寻找支持HTTP流轮询、消息缓冲的Webhook服务，无需托管HTTP服务器

• 服务端架构成本更低：webhook基于无状态短连接实现，服务商不需要为每一个客户维持长连接会话，无需处理心跳保活、断连重连、会话状态同步等复杂逻辑，服务端资源开销、架构复杂度、运维成本都远低于长连接方案，更适配数十万级客户的To B服务场景
• 通用性更强：webhook基于标准HTTP协议，无需客户绑定特定语言的SDK，不管是用什么技术栈开发，甚至是用无服务器函数服务都可以快速对接，适配范围远高于和特定语言绑定的长连接SDK方案
• 普适性运维成本更低：对绝大多数普通客户而言，托管公网HTTP接口的门槛和运维成本远低于维护高可用的长连接会话，长连接在网络波动、客户端重启时很容易出现断连、消息丢失问题，普通客户的运维能力很难保障消息投递可靠性，webhook的自动重试、幂等校验逻辑对普通用户更友好
• 问题排查效率更高：webhook的所有请求日志、状态码、返回结果都可以标准化统计，客户和服务商排查回调失败、消息丢失等问题的效率远高于长连接场景，不需要针对每一个客户端的会话状态做单独排查。

你提到的主动发起长连接/主动拉取的对接方式完全可以实现，目前有两种成熟的落地路径：

• 直接使用服务商的主动拉取接口：包括Twilio、Telnyx在内的绝大多数短信服务商都提供了入站消息查询API，你可以在内网服务中定期主动调用该接口拉取未处理的短信记录，仅需要你的服务具备公网出站访问能力即可，全程不需要暴露任何入站TCP端口，拉取间隔可根据你的延迟需求设置为几秒到数分钟不等
• 使用webhook中转服务的长连接推送能力：很多webhook中转服务支持客户端主动发起WebSocket或Server-Sent Events连接接收事件，你只需要把短信服务商的webhook回调地址配置为中转服务分配的公网地址，再在内网中运行对应客户端主动和中转服务建立长连接即可接收推送，全程不需要你的内网暴露任何入站端口。

内容的提问来源于stack exchange，提问作者Mike