13 | HTTP Tunnel：复杂网络下消息通道高可用设计的思考
该思维导图由 AI 生成，仅供参考
让消息通道能连得上
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文探讨了即时消息系统中消息通道的高可用设计。作者首先提出了保障消息通道高可用的基本要求，包括连得上和连得快。针对这些问题，文章介绍了多端口访问和HTTP Tunnel等优化手段，并提出了解决跨网延迟和跑马竞速的实现方式。此外，为了保持消息通道的稳定性，文章还强调了通道和业务解耦的重要性。通过将变化较大的业务逻辑下沉到后端的业务处理层，可以提高消息通道的稳定性。总的来说，本文从多个方面探讨了保障消息通道高可用的优化手段，包括连得上、连得快和保持稳定。这些优化手段对于即时消息系统的设计和实现具有重要的指导意义。
《即时消息技术剖析与实战》，新⼈⾸单¥59
全部留言(17)
- 最新
- 精选
小可假如现在有用户A和B，以及三个接入节点S1，S2和S3，A给B发消息。A和B都查询最优接入节点，分别对应S1和S2节点。A–＞S1最优没问题，但S2–＞B一定是最优的吗？不一定，上下行通道隔离后，查询最优节点是客户端给节点发消息，代表的是该节点的上行通道是最优的，并不代表节点到客户端的下行通道是最优的。作者回复: 嗯，如果是通道隔离的话，针对上行通道和下行通道都需要进行接入点最优化选择。
2019-09-2514- 饭团老师，有3点不明白！ 1:基于tcp的长链接不是全双工吗？为什么下行会影响上行呢？我的理解是，这里的影响不是通道影响，其实是服务器处理能力的影响，是这样吗？ 2:HTTP Tunnel这个东西确实没用过！如果他是基于http的短链接，那它也没法实现一个完整的即时消息系统呀！比如他们拿不到服务器的推送消息！ 3:在老师说的把通道和业务隔离上，我明白确实需要这样优化！有一点不明白的是，这里的通道和服务是不是可以理解为链接服务和业务逻辑服务！比如链接服务只管链接，链接服务和业务逻辑通过消息队列解耦！但是如果是这样的话，用户的链接映射维护是在链接服务中呀！不在业务层！ 老师的问题，我感觉因为隔离开了，所以就不是“原子”的了，那么就可能存在能发看不到，能看到发不出去的情况
作者回复: 1. 在消息下推数据量持续很高时，tcp链路的稳定性会下降，拥塞机制可能会导致消息的发送也被阻塞，另外就是你提到的高并发推送压力下服务端处理能力也容易出现瓶颈。 2. HTTP Tunnel一般用在短连接发消息的场景里。 3. 通道和业务隔离可以理解为 维护连接的服务和业务逻辑服务分开，连接映射的维护是在连接层处理的，但不一定就在连接服务里，比如可以维护在中央的资源里，方便其他连接服务集群里的机器来共享使用。 在同一个通道里也不一定是原子的呀，发送成功了也可能推送失败。通道隔离的一个问题在于如果上行通道通过短连接实现的话，可能会存在发消息时才建立连接的情况（为了简单，没有心跳机制，一段时间不发消息就会强制断开），所以用户体验上会差一些。另外，额外的通道部署上也有额外的维护开销。
2019-09-2576 
唯我天棋还有个问题，为什么上行通道不直接使用长连接，而要使用长连接。作者回复: 如上面回复：上行通道的连接不需要心跳，连接的保持对系统消耗是非常小的，这也是为什么上行通道没有再维护另一个长连的原因，一种折中的方式。
2019-11-045
时隐时现上下行通道隔离，消息发送方采用短链接，除了基于http tunnel不适合长连接的考量，还有其他因素吗？ 作者提到可避免客户端维护多个长连接的开销，可是单纯的tcp连接应该不会耗费多少资源，和每次都采用短连接相比，还能接受连接不断的创建和关闭的代价。作者回复: 上下行通道分离还可以避免上行发消息操作被下行push消息所影响，比如直播场景中下行消息下推量巨大。维护长连接的开销除了连接保持，还有一系列的比如心跳发送等必备的行为，对于用户流量，电量不是很友好。这里的短连接也不一定是每次都需要重新建连，比如说可以保持idle几分钟，这样即能解决频繁消息发送复用一个连接的问题，也不需要维护一个真正的长连接。
2019-10-083
Z邦希望老师可以出一篇监控的文章。。感谢感谢作者回复: 在后面的课程中会专门降到监控这一块的内容，敬请期待。。
2019-09-252
钢通道隔离的最大问题个人觉得连接断开时机问题，比如A断开，B什么时候断开，要做跟踪记录作者回复: 通道隔离为什么要做跟踪记录呀？实际上通道隔离的一个问题在于如果上行通道通过短连接实现的话，可能会存在发消息时才建立连接的情况（为了简单，没有心跳机制，一段时间不发消息就会强制断开），所以用户体验上会差一些。另外，额外的通道部署上也有额外的维护开销。
2019-09-2522
Sun Fei两个通道隔离之后，如果消息队列里消息比较多，会不会影响消息的实时性？作者回复: 消息的实时性和是否拆分成两个通道关系不是很大，即使是在同一个长连通道里，服务端如果不能及时处理收到的消息，也会消息在服务端堆积，没办法快速投递。所以要解决的还是要提升服务端消息路由分发的能力。
2019-12-031
GeekAmI问题1：短链接怎么idle几分钟呢？http不是无状态的吗？ 问题2：如果上行通道和下行通道隔离，是不是2者对应两个不同的集群呢？作者回复: 1.短连接可以是tcp协议的呀，idle几分钟的主要目的是为了避免发消息这些行为需要每次建连影响体验同时也降低长连维护的开销。 2.一般连接层尽量隔开，因为分成两个连接的目的就是避免互相影响。
2019-11-111
那时刻既然客户端可以通过跑马竞速，选出一个最快ip链接。为什么服务器要返回一个排序IP列表？客户端还依据这个列表顺序进行判断么？作者回复: 实际上不冲突，服务器可以结合自身的压力按不同等级来返回排序的IP列表。客户端优先选择压力等级最小的多个IP进行竞速。
2019-09-2521- 唯我天棋上下行通道隔离能够隔离保护我们的消息接收和消息发送，那么通道隔离会不会带来一些负面影响呢？ 1.需要维护两个连接，消耗一定客户端性能。
作者回复: 上行通道的连接不需要心跳，连接的保持对系统消耗是非常小的，这也是为什么上行通道没有再维护另一个长连的原因，一种折中的方式。
2019-11-04
