即时消息技术剖析与实战
袁武林
微博研发中心技术专家
24187 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 25 讲
即时消息技术剖析与实战
15
15
1.0x
00:00/00:00
登录|注册

13 | HTTP Tunnel:复杂网络下消息通道高可用设计的思考

开辟新的连接通道传输多媒体消息
拆分隔离上下行通道
业务逻辑下沉到后端处理层
动态调整用户优先连接的接入点IP
HttpDNS
多运营商机房接入点
通过HTTP封装其他协议
解决协议不支持的问题
同时暴露多个端口
80、8080、443、14000端口
端口连通性问题
移动运营商限制
用户网络情况复杂
独立多媒体上传下载
上下行通道隔离
通道和业务解耦
跑马竞速
解决跨网延迟
HTTP Tunnel
多端口访问
申请外网虚拟IP
通道保持稳定
通道连得快
通道连得上
HTTP Tunnel:复杂网络下消息通道高可用设计的思考

该思维导图由 AI 生成,仅供参考

你好,我是袁武林。
第 1 讲“架构与特性:一个完整的 IM 系统是怎样的?”中,我有讲到即时消息系统中非常重要的几个特性:实时性、可靠性、一致性、安全性。实际上,这些特性的实现大部分依赖于通道层的稳定和高可用。
对于即时消息系统来说,消息的通道主要承载两部分流量:一部分是用户发出的消息或者触发的行为,我们称为上行消息;一部分是服务端主动下推的消息和信令,我们称为下行消息
由此可见,消息通道如果不稳定,一来会影响用户发送消息的成功率和体验,二来也会影响消息的下推,导致用户没法实时收到消息。
那么,在面对如何保障消息通道的高可用这一问题时,业界有哪些比较常用的优化手段呢?

让消息通道能连得上

要保障消息通道的高可用,最基本的是要让通道能随时连得上。不过你可能会觉得,这看起来好像挺简单的,不就是申请个外网虚拟 IP,把接入层服务器挂上去,然后通过域名暴露出去就行了吗?
但实际上,这个“连得上”有时真正做起来却不是那么容易的,主要原因在于用户的网络情况复杂性高。比如,有的用户走 2G 网络来连,有的通过 HTTP 代理来连,还有的会出现 DNS 解析服务被封的情况,诸如此类。
此外,移动运营商各种比较奇怪的限制也会导致连通性不佳的问题。因此,要想你的通道能让用户随时都连得上,还需要做一些额外的优化。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文探讨了即时消息系统中消息通道的高可用设计。作者首先提出了保障消息通道高可用的基本要求,包括连得上和连得快。针对这些问题,文章介绍了多端口访问和HTTP Tunnel等优化手段,并提出了解决跨网延迟和跑马竞速的实现方式。此外,为了保持消息通道的稳定性,文章还强调了通道和业务解耦的重要性。通过将变化较大的业务逻辑下沉到后端的业务处理层,可以提高消息通道的稳定性。总的来说,本文从多个方面探讨了保障消息通道高可用的优化手段,包括连得上、连得快和保持稳定。这些优化手段对于即时消息系统的设计和实现具有重要的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《即时消息技术剖析与实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(17)

  • 最新
  • 精选
  • 小可
    假如现在有用户A和B,以及三个接入节点S1,S2和S3,A给B发消息。A和B都查询最优接入节点,分别对应S1和S2节点。A–>S1最优没问题,但S2–>B一定是最优的吗?不一定,上下行通道隔离后,查询最优节点是客户端给节点发消息,代表的是该节点的上行通道是最优的,并不代表节点到客户端的下行通道是最优的。

    作者回复: 嗯,如果是通道隔离的话,针对上行通道和下行通道都需要进行接入点最优化选择。

    2019-09-25
    14
  • 饭团
    老师,有3点不明白! 1:基于tcp的长链接不是全双工吗?为什么下行会影响上行呢?我的理解是,这里的影响不是通道影响,其实是服务器处理能力的影响,是这样吗? 2:HTTP Tunnel这个东西确实没用过!如果他是基于http的短链接,那它也没法实现一个完整的即时消息系统呀!比如他们拿不到服务器的推送消息! 3:在老师说的把通道和业务隔离上,我明白确实需要这样优化!有一点不明白的是,这里的通道和服务是不是可以理解为链接服务和业务逻辑服务!比如链接服务只管链接,链接服务和业务逻辑通过消息队列解耦!但是如果是这样的话,用户的链接映射维护是在链接服务中呀!不在业务层! 老师的问题,我感觉因为隔离开了,所以就不是“原子”的了,那么就可能存在能发看不到,能看到发不出去的情况

    作者回复: 1. 在消息下推数据量持续很高时,tcp链路的稳定性会下降,拥塞机制可能会导致消息的发送也被阻塞,另外就是你提到的高并发推送压力下服务端处理能力也容易出现瓶颈。 2. HTTP Tunnel一般用在短连接发消息的场景里。 3. 通道和业务隔离可以理解为 维护连接的服务和业务逻辑服务分开,连接映射的维护是在连接层处理的,但不一定就在连接服务里,比如可以维护在中央的资源里,方便其他连接服务集群里的机器来共享使用。 在同一个通道里也不一定是原子的呀,发送成功了也可能推送失败。通道隔离的一个问题在于如果上行通道通过短连接实现的话,可能会存在发消息时才建立连接的情况(为了简单,没有心跳机制,一段时间不发消息就会强制断开),所以用户体验上会差一些。另外,额外的通道部署上也有额外的维护开销。

    2019-09-25
    7
    6
  • 唯我天棋
    还有个问题,为什么上行通道不直接使用长连接,而要使用长连接。

    作者回复: 如上面回复:上行通道的连接不需要心跳,连接的保持对系统消耗是非常小的,这也是为什么上行通道没有再维护另一个长连的原因,一种折中的方式。

    2019-11-04
    5
  • 时隐时现
    上下行通道隔离,消息发送方采用短链接,除了基于http tunnel不适合长连接的考量,还有其他因素吗? 作者提到可避免客户端维护多个长连接的开销,可是单纯的tcp连接应该不会耗费多少资源,和每次都采用短连接相比,还能接受连接不断的创建和关闭的代价。

    作者回复: 上下行通道分离还可以避免上行发消息操作被下行push消息所影响,比如直播场景中下行消息下推量巨大。维护长连接的开销除了连接保持,还有一系列的比如心跳发送等必备的行为,对于用户流量,电量不是很友好。这里的短连接也不一定是每次都需要重新建连,比如说可以保持idle几分钟,这样即能解决频繁消息发送复用一个连接的问题,也不需要维护一个真正的长连接。

    2019-10-08
    3
  • Z邦
    希望老师可以出一篇监控的文章。。感谢感谢

    作者回复: 在后面的课程中会专门降到监控这一块的内容,敬请期待。。

    2019-09-25
    2
  • 通道隔离的最大问题个人觉得连接断开时机问题,比如A断开,B什么时候断开,要做跟踪记录

    作者回复: 通道隔离为什么要做跟踪记录呀?实际上通道隔离的一个问题在于如果上行通道通过短连接实现的话,可能会存在发消息时才建立连接的情况(为了简单,没有心跳机制,一段时间不发消息就会强制断开),所以用户体验上会差一些。另外,额外的通道部署上也有额外的维护开销。

    2019-09-25
    2
    2
  • Sun Fei
    两个通道隔离之后,如果消息队列里消息比较多,会不会影响消息的实时性?

    作者回复: 消息的实时性和是否拆分成两个通道关系不是很大,即使是在同一个长连通道里,服务端如果不能及时处理收到的消息,也会消息在服务端堆积,没办法快速投递。所以要解决的还是要提升服务端消息路由分发的能力。

    2019-12-03
    1
  • GeekAmI
    问题1:短链接怎么idle几分钟呢?http不是无状态的吗? 问题2:如果上行通道和下行通道隔离,是不是2者对应两个不同的集群呢?

    作者回复: 1.短连接可以是tcp协议的呀,idle几分钟的主要目的是为了避免发消息这些行为需要每次建连影响体验同时也降低长连维护的开销。 2.一般连接层尽量隔开,因为分成两个连接的目的就是避免互相影响。

    2019-11-11
    1
  • 那时刻
    既然客户端可以通过跑马竞速,选出一个最快ip链接。为什么服务器要返回一个排序IP列表?客户端还依据这个列表顺序进行判断么?

    作者回复: 实际上不冲突,服务器可以结合自身的压力按不同等级来返回排序的IP列表。客户端优先选择压力等级最小的多个IP进行竞速。

    2019-09-25
    2
    1
  • 唯我天棋
    上下行通道隔离能够隔离保护我们的消息接收和消息发送,那么通道隔离会不会带来一些负面影响呢? 1.需要维护两个连接,消耗一定客户端性能。

    作者回复: 上行通道的连接不需要心跳,连接的保持对系统消耗是非常小的,这也是为什么上行通道没有再维护另一个长连的原因,一种折中的方式。

    2019-11-04
收起评论
显示
设置
留言
17
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部