技术挑战
难点：
协议层
- 三方通信，网络层面无法保证消息必达 【可靠性】
- 没有全局时钟，确定唯一顺序，且是符合因果顺序的 【时序性】
- 多客户端发送消息/多服务端接受消息/多线程多协程处理消息，顺序难以确定 【时序性】
- 分布式ID生成 【架构】
- 容灾设计
- 弱网环境处理
接入层
- 客户端如何选择网关IP地址，才能降低延迟，保证连接可靠，负载均衡？
- 网关服务如何接受客户端的消息，获得最大的并发度，获得消息的高吞吐，低延迟？
- 为了能使用长连接收发消息，需要维护哪些状态，如何使其占用更少的内存，单机承载更多的连接？
- 业务层是怎么感知到连接在哪一台网关机器，并把消息分发下去的呢？如何降低网络请求的扇出？
- 客户端进入地铁/切换基站/连接wifi等情况下导致连接断开，如何能快速重连，而不影响用户体验？
- 如何尽可能等减少长连接服务的崩溃/重启次数，做到永不宕机？
- 长连接服务如何做限流/熔断/降级策略？实现对网关的过载保护，提高可靠性？
- 长连接服务如何做到通用性，灵活对接各种业务场景？
- 如何多数据中心部署长连接网关？
- 如何解决业务层回调长连接网关时消息扇出的问题
- 如何保证长连接本身的可靠性，降低其断线的影响
- 如何提高长连接服务故障恢复的速度
- 长连接服务如何做限流/熔断/降级策略