大家好，我是砸锅。一个摸鱼八年的后端开发。熟悉 Go、Lua。今天和大家一起学习 IM 系统😊
复杂网络下消息通道高可用设计
消息的通道主要承载两部分流量：一部分是用户发出的消息或者触发的行为，我们称为上行消息；一部分是服务端主动下推的消息和信令，我们称为下行消息
通过 HttpDNS 来返回多个接入点 IP 来解决连通性问题，失败一个就尝试下一个
让消息通道连接更快的方式：
- 通过解决跨网延迟来避免通道连接过慢。需要有多运营商机房的接入点，避免运营商 DNS 解析转发和 NAT 导致接入 IP 被解析到其他运营商的问题。很多 IDC 机房都支持多线运营商接入
- 通过跑马竞速来选择最快的通道接入。APP 通过对返回的接入点 IP 列表中所有 IP 进行竞速测试，并将测速结果上报到服务端，服务端根据这个测速结果来动态调整接入点 IP 列表的顺序，让用户优先选择最优接入点
让消息通道保持稳定的方式：
-
通道和业务解耦。因为消息收发是严重依赖长连接通道的，所以不能跟着业务变更而不断调整重启，这样会降低消息收发的成功率和用户体验，所以通道层只负责网络连接管理和通用的逻辑处理。将用户与连接的映射维护、通信协议的编解码、建立连接逻辑处理、ACK 包和心跳包处理等放在业务处理层
-
上下行通道隔离。用户上行的消息和行为通过一个短连通道发送到服务端。这样既能避免客户端维护多个长连接的开销，也能解决上行通道被下推消息影响的问题
-
独立多媒体上传下载。单独开辟一条新的连接通道来传输二进制的文件流，保护消息收发的核心通道不受影响，还能缩短上传下载的链路
此文章为3月Day11学习笔记，内容来源于极客时间《即时消息技术剖析与实战》 这门课真的非常好，推荐大家看看
