即时消息技术剖析与实战
袁武林
微博研发中心技术专家
立即订阅
6503 人已学习
课程目录
已完结 24 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 搞懂“实时交互”的IM技术,将会有什么新机遇?
免费
基础篇 (8讲)
01 | 架构与特性:一个完整的IM系统是怎样的?
02 | 消息收发架构:为你的App,加上实时通信功能
03 | 轮询与长连接:如何解决消息的实时到达问题?
04 | ACK机制:如何保证消息的可靠投递?
05 | 消息序号生成器:如何保证你的消息不会乱序?
06 | HttpDNS和TLS:你的消息聊天真的安全吗?
07 | 分布式锁和原子性:你看到的未读消息提醒是真的吗?
08 | 智能心跳机制:解决网络的不确定性
场景篇 (4讲)
09 | 分布式一致性:让你的消息支持多终端漫游
10 | 自动智能扩缩容:直播互动场景中峰值流量的应对
11 | 期中实战:动手写一个简易版的IM系统
12 | 服务高可用:保证核心链路稳定性的流控和熔断机制
进阶篇 (10讲)
13 | HTTP Tunnel:复杂网络下消息通道高可用设计的思考
14 | 分片上传:如何让你的图片、音视频消息发送得更快?
15 | CDN加速:如何让你的图片、视频、语音消息浏览播放不卡?
16 | APNs:聊一聊第三方系统级消息通道的事
17 | Cache:多级缓存架构在消息系统中的应用
18 | Docker容器化:说一说IM系统中模块水平扩展的实现
19 | 端到端Trace:消息收发链路的监控体系搭建
20 | 存储和并发:万人群聊系统设计中的几个难点
21 | 期末实战:为你的简约版IM系统,加上功能
22 | 答疑解惑:不同即时消息场景下架构实现上的异同
结束语 (1讲)
结束语 | 真正的高贵,不是优于别人,而是优于过去的自己
即时消息技术剖析与实战
登录|注册

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

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

让消息通道能连得上

要保障消息通道的高可用,最基本的是要让通道能随时连得上。不过你可能会觉得,这看起来好像挺简单的,不就是申请个外网虚拟 IP,把接入层服务器挂上去,然后通过域名暴露出去就行了吗?
但实际上,这个“连得上”有时真正做起来却不是那么容易的,主要原因在于用户的网络情况复杂性高。比如,有的用户走 2G 网络来连,有的通过 HTTP 代理来连,还有的会出现 DNS 解析服务被封的情况,诸如此类。
此外,移动运营商各种比较奇怪的限制也会导致连通性不佳的问题。因此,要想你的通道能让用户随时都连得上,还需要做一些额外的优化。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《即时消息技术剖析与实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

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

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

    2019-09-25
    4
  • Z邦
    希望老师可以出一篇监控的文章。。感谢感谢

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

    2019-09-25
    1
  • 于欣磊
    主要应该是 上行下行 也就是输入输出之间的同步问题 同时如果按照文中的设计 单个 长链接 上行 如何做到上行之间的有序 去重 重发 就会很复杂 这样 输入之间 输入输出之间 就需要考虑更多的问题
    2019-12-04
  • SUNFEI
    两个通道隔离之后,如果消息队列里消息比较多,会不会影响消息的实时性?

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

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

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

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

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

    2019-11-04
  • 唯我天棋
    上下行通道隔离能够隔离保护我们的消息接收和消息发送,那么通道隔离会不会带来一些负面影响呢?

    1.需要维护两个连接,消耗一定客户端性能。

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

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

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

    2019-10-08
  • leslie
    老师在第十课的<自动智能扩缩容:直播互动场景中峰值流量的应对>中提到关于上下隔离的优点"能够隔离各自上行操作,避免下行推送通道产生影响,轻量、独立的长连接服务容易扩容。";坑没踩过,准备等十一长假开始自己写一个IM并在特定范围内试用-到时候就知道有哪些坑了。
          进阶篇已经用到了不少基础篇和场景篇的知识:属于一边学习一边复习过程吧;期待老师的后续分享。
    2019-09-26
  • 云师兄
    HTTP Tunnel在下行通道也会使用吗,如果存在代理的情况,下行通道发送给代理的数据如何再转发给客户端

    作者回复: 我们自己的业务中目前只用于上行短连通道中。理论上也是可以用在下行通道的,因为底层也都是基于TCP的,但是走http代理的问题在于连接一般很难保证不被代理断开,所以维护住一个真正的长连接比较困难。

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

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

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

    作者回复: 1. 在消息下推数据量持续很高时,tcp链路的稳定性会下降,拥塞机制可能会导致消息的发送也被阻塞,另外就是你提到的高并发推送压力下服务端处理能力也容易出现瓶颈。
    2. HTTP Tunnel一般用在短连接发消息的场景里。
    3. 通道和业务隔离可以理解为 维护连接的服务和业务逻辑服务分开,连接映射的维护是在连接层处理的,但不一定就在连接服务里,比如可以维护在中央的资源里,方便其他连接服务集群里的机器来共享使用。

    在同一个通道里也不一定是原子的呀,发送成功了也可能推送失败。通道隔离的一个问题在于如果上行通道通过短连接实现的话,可能会存在发消息时才建立连接的情况(为了简单,没有心跳机制,一段时间不发消息就会强制断开),所以用户体验上会差一些。另外,额外的通道部署上也有额外的维护开销。

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

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

    2019-09-25
    1
收起评论
13
返回
顶部