融合通信技术趋势和演进方向

网易数智

于 2021-11-09 17:25:05 发布

阅读量1.3k

点赞数 2

文章标签：网络传输网络通信 im

本文链接： https://blog.csdn.net/netease_im/article/details/121231412

版权

导读：2021年10月21日，「QCon 全球软件开发大会」在上海举办，网易智企技术 VP 陈功作为出品人发起了「AI 时代下的融合通信技术」专场，邀请到多位技术专家与大家一起分享相关技术话题。

从本期开始，我们会针对四个演讲专题逐一进行介绍与分享，本期是我们的第一期，融合通信技术趋势和演进方向。

嘉宾介绍：曹佳俊，网易云信资深服务器开发工程师，毕业于中国科学院，硕士毕业后加入网易，负责网易云信 IM/RTC 信令等业务的服务器开发。专注于即时通信、RTC 信令以及相关中间件等技术，是云信开源项目 Camellia 的作者。

前言

近年来通信技术呈现成熟的趋势，与人工智能和5G 紧密结合，在新冠疫情的催动下，已应用于各行各业中。定位在一站式融合通信云服务的网易云信，为业务层面带来了新的气象。本次 QCon2021云信专场将为大家带来融合通信技术的前沿探索和落地实践。

本次分享的内容如下，首先介绍融合通信的概念，其次介绍融合通信的技术演进方向以及云信在技术架构演进过程中做的一些技术探索，最后介绍网易云信在融合通信多行业场景下的落地实践经验。

融合通信的概念

融合通信的概念最早阐述为企业办公场景下的统一通信。统一通信指的是传统通信技术（如短信、传真、电子邮件等）和互联网技术融合后产生的一种新的通信方式，统一通信的核心概念是指可以在任意时间和任意地点，通过任意的网络和任意的设备获取到我们想要的信息，比如文本、图片、声音、视频等等。随着通信技术的发展，融合通信的概念也在不断的扩展。目前已经逐渐形成了以 IM 和 RTC 为核心的，融合多种通信方式的，内容非常丰富的概念。

对于融合通信来说，它的核心概念当然是融合。对于融合，我们可以从两个方面来理解。首先是业务的融合，对于一款应用来说，不管是娱乐社交也好或者是金融也好，业务逻辑的实现往往依赖一些底层的通信技术的融合。其次是技术的融合，我们只有做好了技术的融合，打通底层的技术，这样业务方才能够更轻易更高效的通过我们融合通信的技术去实现自己的业务逻辑。

融合通信具体的内容包括哪些呢？从网易云信或者融合通信云服务商的角度来说，融合通信可以划分为六个方面：

首先是业务场景。所谓的业务场景指的是，在线教育、音乐教学、企业办公等场景。我们会提供各种各样针对各行各业的一站式解决方案，用来降低客户的接入成本。
其次是应用组件层。应用组件可以理解成对通用的场景化解决方案的进一步升华。通用的业务场景比如说视频会议等，网易云信会提供从客户端到服务器的一站式完整的组件服务，通过屏蔽一些底层的技术细节，来降低客户接入的成本，提升研发效率。
第三层是客户端层。网易云信提供了全平台覆盖的 SDK，并且我们的 SDK 致力于提供一致的功能以及一致的体验。
第四层是服务层。我简单划分了几个类型，包括即时通讯、RTC、直播、运营商能力等。对于服务模块来说这不是简单的功能划分，而是包含了深度融合的过程。

举个例子，比如对于即时通讯和 RTC 来说，即时通讯给 RTC 提供了信令的能力；RTC 和直播点播的融合则带来了互动直播、低延时直播这样融合通信的能力；再比如运营商能力和 RTC 能力的融合，通过底层能力的打通再结合即时通讯的能力，在音视频呼叫场景下可以有效提高呼叫的成功率。
服务层之下是我们的核心能力层，这里的核心能力层我特别提一下 AI 这部分，网易云信组建了专门的 AI 算法团队来负责 AI 算法在各个业务服务场景的落地。

以运营商里面的呼叫中心为例，其中可能包含了智能机器人，这依赖于底层 AI 的 NLP 算法能力；再比如说今年网易云信推出了重磅产品安全通，安全通是一个面向融合通信的一站式内容安全解决方案，通过安全通，我们可以在享受融合通信技术便利的同时，加上一道内容安全的保障。
最后是基础设施。其中包括网易和网易云信自研的组件和平台，同时也包括开源项目的引入，此外对于一些底层的通用能力，网易云信也在计划做一些开源来回馈技术社区，后续可以关注我们的微信公众号、技术博客、技术社区等，我们会第一时间发布相关信息。

融合通信的技术演进方向

本次分享的核心内容是融合通信的技术演进方向。单独看这个话题有点大，我这里列了一些关键词，比如5G、AI 的技术发展显然带动了融合通信技术进一步的发展；比如物联网技术，随着智能硬件的兴起，物联网成为了融合通信新的技术舞台。而本次分享将围绕全球化和单元化这两个关键词，介绍网易云信在融合通信技术架构演进过程中的一些技术探索。

为什么要做单元化和全球化

对于这个问题，这里列了三个关键词，可以部分解答这个问题。

首先是容量。随着融合通信整个市场规模的扩大，网易云信的规模也在持续增长，随着系统规模的不断扩大，单一的机房甚至单一的城市都可能成为限制系统水平扩展能力的瓶颈，对于该问题，单元化和全球化是一个很好的解决方法。
其次是风险。同样随着系统规模的不断扩大，覆盖的终端覆盖的群体越来越大，如果我们这个系统产生任意的抖动，它的影响是非常大的。比如今年国庆期间，不知道大家有没有关注，facebook 旗下的业务全站宕机了六小时以上，影响非常大。对于这种全局性的风险，单元化是很好的策略，可以避免单点故障，而且能防止故障蔓延到整个系统。
最后是质量。对于通信服务来说，能否更快的送达，是我们衡量一个通信服务质量的重要的指标之一。终端和终端之间的通讯，如果是跨国的或者距离很遥远的，物理距离实际上是一个很难克服的问题。对于这个问题，单元化提供了一种非常好的解决方案，既然无法克服，那就离你更近一点。

说完痛点，那单元化和全球化具体有哪些优势呢？

提升系统整体的承载能力。在单元化的架构下，多单元的水平扩展能力将有效提升系统整体的承载能力。
能够分散风险。单元化架构的设计原则之一就是单元之间要保持逻辑的独立甚至是物理的隔离。单元化的架构，可以有效的避免单点风险，并且可以避免风险在整个系统里面的蔓延，假如这个单元宕机了，那么把它切走就可以了。
异地容灾能力。在单元化的架构下，我们通过单元互备的方式，提供了异地容灾能力，从而提升了服务的整体可用性。
优化最后一公里。只有单元化的架构才能做到真正的就近接入。

单元化和全球化的前置条件

具体要怎么做单元化、全球化的通信服务，在讲这个问题之前，我先讲一下我认为很关键的两个点，或者说是做好单元化、全球化的前置条件。

首先是传输通信网。在一个单元化的架构下，我们遍布全球的边缘节点以及布在各大洲的数据中心，它们之间的网络传输问题将直接影响到整个通信网络的传输质量。

其次是服务质量监控系统。在一个单元化全球化的通信系统里面，终端遍布全球并且是海量的。服务器也是遍布全球，如何去搜集来自海量终端以及世界各地服务节点的数据，对监控和改善我们整个服务的质量非常重要。

传输网络

关于传输网络，网易云信构建了一个全球实时传输网络——WE-CAN。WE-CAN 是一个架设在公共互联网上的，通过对各种资源智能调度来实现提高数据传输质量、降低数据传输成本目标的复杂网络系统。下图是 WE-CAN 简单的架构图。

为了让大家理解它的工作原理，举一个简单的例子。图上的左边是一个终端，右边也是一个终端，比如从上海发到新加坡，假设需要传输一个报文，它的传输路径是怎么样的呢？

首先客户端需要通过统一调度系统 dispatcher 去获取到边缘加速节点，我们叫他 edge，edge 获取到报文后，会传输给同机房或者同一个单元内的 delay 节点，随后经过一条或者多条的路由到达新加坡对端的边缘 edge 节点，最终再传输给目标终端。

整个传输过程可以分为两部分，一部分是终端到 edge，我们叫最后一公里。主要是通过前面说的调度系统，配合 edge 的心跳负载信息来实现最佳接入；第二部分是网内传输，也就是 relay 节点之间的智能路由，这个主要依赖于 contrller 服务，该服务会收集 relay 节点间的网络探测数据，形成一份动态的智能路由表。

WE-CAN的设计原则和目标可以归纳成几句话：

Faster than CDN
Checker than SD-WAN
More versatile than RTN

前两个比较好理解，最后一个是什么意思呢，什么叫多功能，这其实也是 WE-CAN 区别于一般的 RTN 网络的地方，WE-CAN 大网不仅可以传输流媒体的媒体数据，同时还可以提供一种可靠传输的模式，我们叫 msgbus。所谓的可靠传输，首先是保证消息必达，其次保证消息传递的有序性，msgbus 已经广泛应用在云信的消息、数据、信令等的传输。

针对单元化和全球化场景，WE-CAN 解决了两个关键的问题，一个是网络加速和动态路由的问题，通过 WE-CAN 内部的智能节点调度，可以帮助我们选择节点和节点之间，就是边缘节点和中心机房之间的边缘路径，并且可以对网络上的单点故障做一个自动避障功能。

还有就是最后一公里的问题，WE-CAN 通过静态配置以及参考动态的负载信息的上报来实现就近接入，提高服务的接入质量，此外在一些特殊场景下，比如一个 RTC 的大型房间，调度系统还会有节点汇聚的功能来减少跨节点的网络传输，从而减少成本。

服务质量监控系统

在全球化的架构下，建设服务质量监控系统时有一个点很重要，也可以说是难点，就是如何去实时搜集遍布全世界的终端和服务器的数据。下图是整个架构简图。

左边展示的是数据源，一类是 SDK，还有我们的服务器，包括边缘节点也包括异地的数据中心。

对于 SDK 来说我们会根据数据的类型和特点的不同，选择 http 或者 websocket 协议进行数据的上报，服务器主要是通过日志+agent 的方式进行采集，随后通过 websocket 协议进行上报。

对于数据源来说，在上报之前会先请求调度系统获取到边缘收集集群的接入地址，数据到达边缘收集集群后，再通过 WE-CAN 的 msgbus 把数据路由到中心集群，随后经过数据清洗，分流到不同的数据处理单元。比如进入我们的指标计算系统，实时计算相关数据的指标，并对接到我们的监控报警系统；其他的还包括一些离线和在线的系统进行数据分析和问题定位。

通过服务质量监控系统，我们可以实时的了解到我们整个通信系统的健康状态，就和跑车的仪表盘一样，可以让我们很直观的了解到系统运行状态，什么时候该加油，什么时候该转弯，都能一目了然。

IM/RTC 服务器单元化/全球化方案

说完了单元化和全球化的两大前置条件，下面介绍我们具体怎么构建一个单元化和全球化的系统，我会分别介绍 RTC 和 IM 两类通信系统的单元化/全球化的架构。

RTC服务器单元化

首先是 RTC 服务器的单元化，我会通过单元化部署架构和容灾方案两部分展开。

单元化部署架构

这是一个 RTC 服务器架构的简图，对于它的部署架构，右边这三个关键词可以非常形象的描述它的整体设计理念。

首先是分层解耦。整个 RTC 服务器可以划分成三个层次，首先是信令接入层，这是整个 RTC 服务器的入口。其次是媒体信令层，这层是 RTC 服务器的控制中心，会和底下的媒体服务层进行大量的信令交互。

对于每个服务层来说，可以看到都是支持多单元的部署的。对于信令接入层来说，它的主要功能包括客户端请求的鉴权，以及一些全局或者说应用级别的的配置的下发等，信令接入层的单元划分是应用级别的，也就是说每个应用只会被一个信令接入单元处理，信令接入层收到请求后，会根据请求的一些参数信息（如客户端 ip 等）将请求转发给某个合适的媒体信令单元，媒体信令单元是以房间维度做的单元划分，主要功能包括房间管理、流管理、调度分配等，每个媒体信令单元有都一个媒体单元一一对应，对于媒体来说，各个媒体单元逻辑独立，但是物理资源是共享的。

其次是数据的隔离和同步。对于媒体信令和媒体服务来说，单元都是以房间维度做的数据隔离，而对于信令接入层来说，因为是请求的入口，还涉及到数据的同步和转发。

数据的同步包括2种类型，首先是全局和应用级别的一些配置信息的同步，采用了一写多读的方式，保证各个单元间数据的一致性；其次是房间相关数据的同步，主要是房间的一些鉴权信息以及每个房间到媒体信令单元的一一映射关系，这些数据是两两同步，每个单元都有一个逻辑上的备份单元；

此外，信令接入层还涉及到数据的转发，通过请求转发来保证每个应用的请求只会被一个单元处理。

最后是单元的互备。可以看到，每个服务层均支持单元化的部署，通过单元间的互备，可以避免单点的故障影响全局。

单元化容灾方案

对于 RTC 服务器，包括三个层次的容灾，分别是信令层、媒体层和链路灾害。

信令层可以细分为信令接入层和媒体信令层。对于媒体信令层来说，因为它是房间维度的单元划分，因此在某个单元不可用时，信令接入层会直接屏蔽到该单元，所有的新请求都不再转发给该单元，从而快速恢复；

对于信令接入层来说，每个单元都有逻辑上的备份单元，当一个单元不可用时，通过切换请求入口（包括网关配置、dns 等），并且配合数据的变更来把切换信息快速扩散给所有单元，从而进行单元的灾备切换；

对于媒体服务层来说，每个媒体服务器都会定时上报心跳信息给媒体信令服务，当出现某个节点故障时，媒体信令服务会快速的检测到并自动下线该节点。

最后是链路的灾备，对于一个通信系统来说，你的所有服务节点可能都没问题，但是网络链路挂了，对于链路故障的情况，我们主要是通过 WE-CAN 大网的智能路由来感知和处理这种 case。

举个实际的例子，我们有一个机房，它所在的省份的某个运营商的骨干网故障了，导致所有外地的该运营商的机房和终端都无法连接到该机房，在 WE-CAN 之前这可能就是一个大事故，但是 WE-CAN 的智能路由自动感知到了这种情况，并通过其他三线机房的路由，通过其他运营商的线路绕回来，避免了事故的发生。

IM服务器单元化

说完了 RTC，接下来我们聊聊 IM，不同于 RTC，IM 更加依赖数据中心，因此其单元化的架构也会有一些不同，我会分三部分展开，首先是如何构建一个全球的即时通讯网络，其次是在全球通信网络基础如何支持多数据中心，最后是如何进行灾备和冗余。

全球通信网络

在 IM 全球通信网络里，我们的服务可以划分为两类，一类是边缘节点，上面主要部署了我们的长连接服务器，我们叫 link，link 可以部署在多个单元，通过调度系统就近分配；另一类是我们的数据中心，承载了即时通讯的核心能力。

边缘节点和数据中心通过 WE-CAN 大网互联，当 link 服务器收到来自客户端的一个请求后，会通过 WE-CAN 的 msgbus 路由到中心机房的 bridge 集群，随后转发给我们的协议路由服务，最后路由到我们的服务集群，包括消息服务、推送服务等等。

这样一个架构有什么好处呢？首先通过长连接的前置部署，可以有效的改善接入的质量；其次是通过广播消息下推给边缘 link 节点，可以降低中心机房的带宽压力，提升系统的水平扩展能力，这个在超大型的聊天室场景或者超大群场景中，效果特别明显。

多数据中心支持

在这样一个全球即时通讯网络的架构下怎么支持多数据中心？

在这个架构里面，为了支持多数据中心的要求，我们抽离出了两个专门的服务，其中一个租户服务，内容主要是一些全局的配置信息、应用级别的配置信息和开关等，每个数据中心以及每个边缘机房都会部署租户服务，当一个客户端请求到达某个 link 节点时，link 服务会访问就近的租户服务，获取到该请求所属的应用归属的单元，随后通过 WE-CAN 的 msgbus 的 topic 机制，来路由到正确的数据中心；

还有一个是 lbs 服务，lbs 服务同样会多机房部署，并且通过统一的配置信息来进行统一资源的分配和调度。

在多数据中心的架构里面，有一个很重要的点是单元隔离。

可以从两方面理解，首先每个应用都会归属于一个单元，也就是说一个应用的请求只会路由到某一个数据中心，所以各个数据中心的数据是归属于不同的应用的，做到了数据的隔离。

还有一个是数据的全局唯一，以发消息为例，每条消息都有一个全局唯一的消息 id，这个唯一性不仅仅是单个数据中心内部的唯一，还需要保证全局的唯一，这样的好处是未来进行单元的拆分和合并时不会产生数据的冲突。

灾备和冗余

在多数据中心的架构下，如何实现灾备和冗余呢。最关键的是数据的同步，在我们的架构里，每个应用都归属于一个数据中心，而实际上，每个应用还有一个逻辑上的备份单元，主备单元之间会有一个数据的同步，这样才可以进行切换。

数据同步我们采用了两种策略，根据数据的类型、特点，采取不同的策略。首先是双写同步，这个主要是处理一些有时效性的数据，比如在线状态、漫游、缓存等等，双写的逻辑是通过 proxy 服务来进行的，以便减少对业务的侵入，对于一个写请求会被 proxy 转发给 msgbus，最终路由到备份单元进行双写同步；

其次，是针对持久化数据的同步，主要通过 dts 订阅 binlog 的方式，进行跨单元的复制，为了减少延迟，可以看到 binlog 的订阅是异地的，而同步操作则是在目标单元内部进行的。

目前我们的同步都是单向同步配合自动化的脚本进行切换，后续会改造成双向同步的模式，那样将会进一步降低整个运维操作的成本和复杂度。

IM/RTC 服务器单元化架构的好处

整个网易云信的 IM 和 RTC 服务器单元化的架构具体有哪些好处？

优化最后一公里。对于 RTC 来说，不管是信令还是媒体，全流程的就近接入，将显著的降低延迟，比如可以提升首屏的速度；对于 IM 来说，不管是接入节点还是数据中心，单元化方案下，将可以更靠近终端，从而有效降低消息的延迟。
提升可用性。单元化/全球化的架构，可以有效的提升整个通信网络应对机房，甚至城市级别的抗风险能力。
数据隔离和风险隔离。各单元间逻辑独立，物理隔离，可以降低风险，避免故障蔓延；特别的，单元间数据的隔离，某些情况下还可以避免政策风险。

融合通信的落地实践经验

说完了单元化/全球化的技术架构，那么有哪些落地实践呢？

以大型直播活动解决方案为例，该方案融合了多种通信方式，在单元化的架构下，直播服务通过多机房的部署，确保了直播稳定高可用；对于连麦互动的场景，通过全球化的节点可以做到全球多地实时互动；而对于弹幕互动，在单元化的架构下，通过分散接入节点，云信最高可以支撑千万级的在线。

下图展示的是去年8月底的活动，这网易云音乐 TFBOYS 七周年演唱会，云信提供了底层的通信能力，最高同时在线人数达78.6万，打破线上付费演唱会吉尼斯记录，可以说充分验证了单元化/全球化架构的水平扩展能力和稳定性。