​稳健、可靠全真即时通信网的架构与应用

导

语

支撑全真互联网的基础网络包括实时音视频通信网络、即时通信网络和流媒体分发网络。随着社会的进步，人们对低延时即时通信的需求越来越高。本次LiveVideoStackCon 2021上海站大会邀请到了负责腾讯云千亿级底层通信网络的刘然，他为我们分享了稳健、可靠的全真即时通信网的架构与应用实践。

文 / 刘然

整理 / LiveVideoStack

大家下午好，我是来自腾讯云通信的后台研发刘然。刚刚提到全真互联网及“三合一”基础网络RT-ONE™，它具体包括了实时音视频通信网络、即时通信网络和流媒体分发网络。前面薛笛已经为大家介绍了实时音视频通信网络，接下来我给大家分享即时通信网络的一些技术点和应用场景实践。

今天分享将从4个方面展开，包括即时通信网的介绍、核心技术点、融合场景的解决方案以及典型的应用场景。

01

即时通信网简介

即时通信网络可以用来做什么呢？包括信令消息、双人或者多人音视频通话的邀请请求、上下麦的连麦请求、教育白板里的白板轨迹、直播场景下的红包，点赞，送礼等。除此之外，我们还有社交的场景——单聊、群聊、直播大房间，以及图文、语音、视频、自定义消息，在终端方面支持全平台多功能覆盖，支持微信、QQ、支付宝、百度、头条等类似的小程序。从数据上看，腾讯云即时通信IM的月活已经超过QQ的月活，海外也有数千万的用户分布在200多个国家和地区。

上图是腾讯云即时通信的基本架构。SDK层可分为网络连接层、逻辑层、数据层和监控，在此之上是API接口层，再往上是给开发者提供的TUIKIT，这是一种非常方便的aPaaS的能力。除了SDK，后台模块也有很多，除了最上层的接入层，还有业务逻辑层、数据存储层，以及一些和运营系统相关的逻辑。做IM要考虑到很多点，包括高可靠、高性能、高可用、可扩展和安全性等等，另外还有日常的开发运营维护等成本。

如何快速搭建一套IM系统呢？现在只需要集成腾讯云SDK就可以轻松实现，腾讯云提供了全平台、多终端SDK，它和腾讯云后台打通以后，就可以和业务后台进行交互。在疫情中发挥重要的明星产品腾讯会议之所以能够抓住机会，是各方面因素的共同结果，这其中非常重要的一点是腾讯会议的底层运用了我们的全套通信能力，包括实时音视频、IM、PSTN、TPNS等能力，基于这些基础能力的支撑，腾讯会议可以把更多的精力放在核心能力打造上，这也是我们做PaaS服务的初心——基于多年的积累把基础的能力产品化再将其商业化，并开放给开发者，这样除了可以降本增效，还可以加速业务创新。这个能力除了腾讯会议，腾讯公司内部有几十款产品都在使用，并且国内外的开发者和客户多达数十万家。

02

核心技术点分享

前面简单介绍了IM，接下来我将针对其中设计的核心技术点做详细讲解。我们今天的主题是全真互联网，所以不论是IM、音视频流媒体还是实时音视频都离不开网络。

2.1 IM全球加速网络

现在跨国之间的通信有两种，一种是卫星通信，另一种是海底光缆通信。因为卫星通信成本高、带宽低，所以目前的应用还不是十分广泛。因此，大部分的通信方式都是依靠海底光缆。

我国海底光缆现状有三点：首先，国际网络环境复杂，容易抖动丢包。其次，整个中国出口的带宽很小。《CNNIC第47次中国互联网报告》提到整个中国出口带宽大概是11.5T，虽然每年的增长速度很快，但是相比去年全球400T的规模还是非常小的。全球人口总计70多亿，互联网人口只有40多亿，中国可能只占据10多亿。对比可以发现中国人均的带宽非常低，经常出现拥塞问题。最后国际访问经常绕行,直连时延高。在这样的背景之下，IM会有登录慢、断网和消息延时的现象。

上图是腾讯云实测的从广州到雅加达的路由数据，这个数据是绕行的，大概在260ms。正常情况下，通过腾讯云自己的网络，例如从广州到香港或者到新加坡的直连、再到雅加达，大概只有50+ ms，差距很明显。一个好消息是前不久腾讯云在雅加达正式开区了，那里有腾讯自建的数据中心，能将我们的能力更多的覆盖到东南亚地区。

2.2 IM全球网络加速能力

当前腾讯云全球加速能力已经覆盖六大洲的主要国家，包括120个接入点、2100+节点，提供了全球的服务。10或20年前，中国企业更多的是设备厂商出海，例如华为、联想和TCL这样的企业。移动互联网的到来促使了更多的工具类企业出海，猎豹移动就是比较成功的案例，之后包括电商、社交、游戏、短视频相关的出海在不断增加。虽然现在国际形势比较紧张，但是全球化对于中国来说是非常好的机会，希望大家能把握好这个机会，把业务向全球拓展。

2.3 系统架构与加速原理

如果想打造高速的网络，不仅需要了解如何选择一个最近的点，还需要知道如何在路由之间快速地交换以到达自己的源站。有三个核心点——如何选择最优接入、如何选择最快的路由以及如何提升传输速率。

2.3.1 精准IP调度

接入点方面，腾讯云有自己的公网评测平台，对各种加速点的数据进行实时计算，然后生成一个调度平台。当用户接入时，根据调度平台为用户选择一个最优的接入点。同时，因为这个平台是实时的，所以在用户使用中也会进行实时的干预。当发现有最优的路径后，平台会将调度信息推送给用户侧，用户下次使用时会选择最优的路径。

上图右侧是我们实时干预以后的效果展示。在马尼拉的网络出现故障以后，邮件告警即使生成，平台把马尼拉的路径即时屏蔽掉，自动选择其他的路径进行调度，做到对用户侧无感，同时也极大了提升了接入质量和运营效率。

2.3.2 通信协议优化

找到最优接入点后，我们在路由之间做了一些协议改造。用户一开始是以TCP或者UDP的方式传输，接着在路由之间是以QUIC加速的方式进行路由的中转。QUIC的0RTT、连接复用和拥塞控制算法等能力都是非常优秀的。在数据安全方面，客户在做业务时大多都有自己的数据包加密，腾讯云的路由之间也有数据加密，同时会有预建连等技术，这里就不详细介绍了。

2.3.3 最优路由选址

那么如何选择路线呢？比如上图从迪拜到圣保罗可能有两条路径：一条是公网路径，另一条是全球加速路径。如果走公网，虽然看起来距离会短一些，但数据时延为459ms；而通过腾讯云中转，经过伦敦再到迪拜，整个过程只需要304ms。我们将每个加速点都作为一个节点，加速点与加速点之间有一个边连接，根据时延和丢包率计算出一个等比的边，再根据边的长度选择一个最优的路径。同时，如果回来时存在另一条最优的路径，那么会选择这条最优路径，而不是之前的，这样就可以保证回程、去程的双面加速，最后补充下，我们是在公网和专线之间选择一个最优的网络，并不是说一定会走专线。

2.3.4 多路无状态传输

路径选好后，我们需要考虑如何提升传输速率，做法是将大包智能拆分成小包，小包通过多路并行传输，最后到达源站，这种方式可以提升效率，在一些场景下还会有小包合并为大包。两边会有状态，但是在链路中间是无状态的，如果节点之间有抖动可以做到秒级踢出。此外，路径之间还有预建连和连接复用的技术。

上图展现的是实际效果，一些区域的效果是非常明显的——通过腾讯云加速，时延可以从200多ms降低到30多ms。通过测试，全球链路时延不超过300ms，实际验证可以把平均时延降低24%，同时请求成功率提升17%。

2.4 可靠的消息系统

对于IM来说，完成选路以后，无论是信令消息还是其他普通消息，保证可靠性都是至关重要的，接下来和大家分享腾讯云消息系统的机制。大家从网上可能了解到QQ和微信的一些做法，微信是使用写扩散的方式，但不管是写扩散还是读扩散，都是在一定业务场景之下来考虑的。

腾讯云选择的是读扩散的模式。从上图可以看到，对于收件人来说，以收件人为维度来储存消息；对于群来说，是以群为维度储存消息。消息的状态一共有三种——已确认、未确认和待下发。收消息采用推拉结合的方式，当一个消息出现，会把消息内容和通知发给接收端，接收端再上传把消息拉回来。这里面会有sequence或者腾讯云自己的cookie控制时序的问题。对于群聊，目前是通过读扩散的模型。如果群比较小，写扩散确实比较方便，但当群的数量越来越大，比如微信群的数量上限是500人，可以使用写扩散，而微信的视频号和直播要使用写扩散的模式是行不通的，很多都已经改成了读扩散的模式。腾讯云不仅可以支持500人的群，2000人乃至万人的大群都能支持。

上图是我们自研消息存储引擎，分为索引层和数据层，这是基本的拉消息的机制。目前腾讯云自己的能力已经可以支持多拷贝的存储，索引全部存在内存里，数据会分为冷、热数据。热数据会存在SSD盘里，冷数据会继续下沉到云硬盘。此外，腾讯云还支持数据加密，同时我们在拉取数据方面也会更加灵活，支持指定SEQ拉取、指定时间区段拉取。

2.5 亿级别状态系统

对于IM来说，状态系统也是非常重要的一点。举个例子来理解状态系统，比如上下线——最开始的PC端QQ是否在线的状态。当需要消息PUSH的时候，首先要查在线还是不在线，在线状态才能走自己的PUSH通道，如果不在线就要通过厂商的离线PUSH通道。对于状态系统，采用分SHARD的模式，通过uin，做一致性哈希，分成一个个SHARD。SHARD支持水平扩展，对于每一个SHARD，也可支持垂直扩展，比如现在有三台机器，随着不断增长的业务量，可以扩展成4台或者5台，扩容是非常高效的。除了在单地域，腾讯云可以多AZ或跨Region同步状态实施。例如为了提升系统稳定性，可以在上海和广州各部署一台，消息真正扩散的时候，并不是去远程查询（常规的做法是状态存在Redis里，通过RPC的方式进行查询）。腾讯云会分成多个SHARD，每一块只负责某一个区段的帐号，当把信息请求过来时，只需要本地查询就能将消息下发下去，非常高效。

在做微信视频号的时候，有提到如果把一亿个人拉到一个群里会怎样？这一定需要读扩散的模式，写扩散是完全不行的，这也是腾讯云即时通信IM的一个特色——无人数上限的直播群，很多客户都会用到。这是一个基本的交互逻辑，看起来只是比较简单的系统收发，里面其实存在多级扩散。当收到消息后，经过逻辑层的扩散，将其存储到一个类似数据存储层的结构里——这个数据存储层可以储存2分钟或者5分钟的一段时间内全部的消息，当用户来拉取的时候，会按照就近的方式拉取。我们这里对消息采取一写多读的方式，具体的消息是一个环形的BUFFER，会记录消息的偏移量，直播大群的群号、群ID、群消息的范围也在里面。另外，网络通信会有抖动和丢包，所以我们做了一个兜底的策略，将消息保存在高保障可靠存储系统，当发现消息的SEQ出现断层，可以补拉，从而保证消息的高可靠。

上图是实际的补拉机制。补拉除了分钟粒度维护索引之外，消息也会分优先级。一个百万人或者千万人直播群的消息量是非常大的，消息里面可以设置优先级，比如把红包设置为高优先级消息，点赞、送礼、弹幕设置为低优先级消息，这样可以保证红包不会因为消息过多而丢失。腾讯云对此有一个淘汰机制，高优先级消息会全量保存，这样当客户来拉消息是可以跳过非关键的弹幕数据，直接把高优先级数据合并后发给用户端，保证用户体验。

03

融合场景的解决方案

前面介绍了腾讯云的三个核心能力。对于IM来说，很多情况下不是单独使用的，而是和其他一些能力结合使用。

上图是腾讯云底层能力。通信层我们有IM、移动推送、实时音视频、直播、点播、cdn的能力，面向教育、电商、金融、政企等各个行业的客户提供服务。服务主要分为三类：一是企业内部员工办公、二是企业和客户之间、三是用户和用户之间。此外，腾讯云还有PSTN、一键登录、云呼叫中心和短信等其他通信能力。从行业来看目前腾讯云已经是全国最大的综合通信服务商。

3.1 直播解决方案

上图是IM和其他业务场景的一些结合，包括TRTC、直播、点播等，这是用于低延时互动直播的，也支持各个端进行多人音视频通话、低延时直播和PK连麦等类似的场景。

3.2 在线课堂解决方案

上图是和教育白板相关的在线互动课堂解决方案。其中用到了腾讯云实时音视频、IM、CDN和白板的能力。1对1小班课或者1对多大班课，乃至10万人的直播课都可以结合腾讯云的通信PaaS以及白板能力，很快的开发出在线课堂的产品。

04

典型应用场景

最后我将和大家简单介绍一些使用IM的典型场景。

4.1 企业内部场景

腾讯会议底层已经深度使用腾讯云通信的能力，包括主持人管理、消息和文件分享等等。在疫情期间，平安保险内训也是通过直播的方式把腾讯云的IM集成进去。钉钉、企业微信提供的是标准化的SaaS产品，但是很多客户因为业务场景原因会有更多的诉求和定制化的需求，为满足这些诉求，需要把腾讯云的IM、TRTC集成进去，基于业务场景灵活开发产品，例如企业内通信的场景。

4.2 企业与用户场景

企业和用户之间最常见的场景是客服。之前的客服模式是每个公司有专门的客服团队，通过客服团队来服务公司所有的产品，随着互联网红利的消息，业务增长有拉新转向存量客户运营。未来客服会是非常重要的一环，同时场景将更加分散，不再局限于某一个部门，每个产品都可能组建自己的小客服团队，要搭建这样一个呼叫中心和客服系统是很复杂的。腾讯云的云呼叫中心可以很方便的为客户打造一个客服系统。

在金融方面，不论是虚拟营业厅、证券还是保险都和直播互动结合得越来越紧密，因此会存在私密付费群，存在互动和推送的场景。

此外除了前面提到的腾讯云在线教育方案，医疗也是一个很好的方向，医疗问诊、实时的音视频沟通、病例上传分享都是很不错的使用场景。

4.3 用户与用户场景

用户与用户之间的场景会更多，像线上社交直播、电商直播带货等等。电商直播会更多需要无人数上限的直播间，会有优惠券、抽奖、送礼、货物上下架、加购物车的诉求。陌生人社交场景会有附近的人、陌生人通信、精准匹配、个性装扮等等诉求。另外在游戏互动方面也有很多应用场景。其实无论是直播、电商、陌生人社交还是游戏，都存在一个趋势：以前只是提供一个产品给客户使用就可以了，但是未来更多的产品会做社区，以此来维护和客户的关系，通过腾讯云的IM和TRTC可以很方便的把社区的通信能力搭建起来。

以上是我今天的全部内容，感谢大家聆听。

原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/117308754?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165918469516781790777876%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=165918469516781790777876&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~times_rank-10-117308754-null-null.nonecase&utm_term=%E9%A6%99%E6%B8%AFcdn