网易云信自研大规模传输网核心系统架构剖析

2021年11月22日 阅读数:4
这篇文章主要向大家介绍网易云信自研大规模传输网核心系统架构剖析,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

随着边缘计算及RTC技术的兴起,业务服务器的边缘化能够带来大量收益:一方面就近接入能够优化客户端上下行质量,另外一方面边缘节点能够大幅下降带宽成本。但如何保证相隔千山万水的边缘服务器之间的网络传输质量成了一个难题。本次LiveVideoStackCon 2021北京站,咱们邀请到了网易云信服务端首席架构师——吉奇经过分析网易云信自研大规模分布式传输网(WE-CAN)核心系统的架构对上述问题进行了深刻探讨。算法

文 | 吉奇缓存

整理 | LiveVideoStack安全

图片

你们好,我是吉奇,来自网易云信,今天演讲的主题是网易云信自研大规模传输网核心系统架构剖析。服务器

图片

首先自我介绍一下,我目前在网易云信作服务端架构,原来在美国工做过一段时间,回国以后接触到RTC和通讯行业。我自己的经历是一直在作服务端,在分布式后台、网络传输,包括高并发、传输协议等领域都有必定的经验。网络

1. 云信介绍架构

图片

云信是网易集24年IM以及音视频技术打造的融合通讯云服务专家,稳定易用的通讯与视频PaaS平台。相信大部分同行对云信的IM能力应该是很熟悉,其实咱们的音视频技术也有不少的积累,最近也有很好的发展。包括如今咱们结合网易易盾也有了不少安全方面的一些独到的方案,咱们立志要作全行业最好的融合通讯PaaS平台。最近咱们网易云信也被归入Gartner 2021年《CPaaS 市场指南》研究报告,仍是有很不错的进展的。并发

2. 项目介绍负载均衡

图片

咱们这个WE-CAN项目是云信自研的传输基座,承担的是网易云信全部业务层须要通讯的流量传输的一个大型传输网络。分布式

目前WE-CAN在全球全部主要地区都已经实现节点部署,在国内的话,咱们在每个省份的ISP都有节点,好比你在中国任意一个省份,无论电信、联通仍是移动,均可以就近接到一个与你这个ISP匹配的同省的机房。在国外的话,全部大洲都有节点,在东南亚的主要国家,像新兴市场,一些主要的出海目标国家,每个国家都有可能不止一个节点来作本地覆盖。ide

WE-CAN做为云信的通用传输基座,它自己是彻底独立于业务的,是彻底独立的一个通用传输网络。本次分享主要是从网络分层的角度去剖析WE-CAN的架构,由于WE-CAN是一个很是复杂的系统,它有不少的核心组件和边缘辅助组件。因此本次分享不采起分解服务或者部署架构的角度,而是用这样一个比较抽象的网络分层的角度去讲解,会比较易于理解和抓住WE-CAN的关键设计决策。

3. WE-CAN网络分层

图片

这是WE-CAN的一个分层架构,你们能够看一下。

我把WE-CAN分红了这么几层,核心的固然是网络层、传输层和应用层了,某种程度上对应传统的互联网模型的三层。固然不是严格对照。

在分层架构最底下是基建层,基建层都是咱们网易自研或者说云信自研的一些基础平台。包括数据平台、管控平台即咱们WE-CAN的内部Dashboard、咱们自研的一个全球的分布式的缓存系统即所谓存储平台,还有配置平台。

基建层往上的控制层其实和网络层结合很是紧密,能够看到接入、转发、调度和路由这四块是WE-CAN最核心的模块。再上面的传输层主要是一个协议层,网络层和控制层是作路由的,那么传输层就是作QoS和各类各样的策略层。

最上面的应用层是对传输层和网络层能力的封装,作了不少比较抽象的基础服务。业务层是实际各个业务场景中对应用层能力的使用。

4. 为何要强调网络分层

图片

那么为何要强调网络分层呢?首先WE-CAN自己就是一个overlay,它自己就是基于公共互联网上的一层。而后网络分层作得好,我认为能够作到各个系统模块各司其职,系统边界比较清晰,而且其实各层有各自不一样的传输优化策略,这个后面会展开讲。好比网络层和传输层的优化策略是不同的,能够作的事情不同,甚至一样的优化策略如ARQ,在网络层和传输层的实现方式也是不同的,网络层策略都是转发节点间逐跳的,传输层是接入节点到接入节点之间的。

最后网络分层和解耦作得好,能够支持更多的传输场景。WE-CAN不仅是要支持实时音视频通讯、低延迟媒体流传输,咱们是要作一个通用的传输加速网络,因此分层作得好能够把各层的能力抽象剥离,就能够支持更多的传输场景。

5. 目录

图片

这个是我要讲的顺序,跟刚才的分层顺序有一点调整,把网络层放在前面,控制层放在后面,这样更有利于理解。

6. 网络层

图片

网络层是WE-CAN核心网的入口,WE-CAN的节点数量比较多,报文从边缘节点出来后就直接进入网络层了。

网络层的功能主要就是报文的寻址路由,它会将一个报文从它的上行接入节点投递到目的地下行接入节点去,这是WE-CAN最核心最基础的能力,因此它是架构最复杂、流程最长的一层。

网络层是基于公共互联网提供优质传输能力的。为何要强调公共互联网这几个字呢?由于这个是咱们WE-CAN“软件定义”的特色,意思是咱们走的是公网流量,经过软件路由来保障传输质量,在绝大部分场景下咱们都用不到专线,在传输层面咱们不须要建设大型的中心机房和专门的骨干线路,这些大型基建的建设周期很长而且成本是很高的。

6.1接入

图片

网络层能够分为两部分,一个是接入,一个是转发。

首先在接入部分咱们对比一下两个常见的接入方案,接入节点又叫登陆节点或者边缘节点。WE-CAN作的一个主要的事情是节点的边缘化。在云信采用WE-CAN以前,咱们的节点是比较典型的那种大型中心机房,好比在国内咱们主要有北京、杭州、广州以及中西部贵州节点,在海外全球有少数的那么几个数据中心。这些数据中心规模比较大,而且建设周期比较长,投入比较大。在这种少数中心机房的状况下调度策略很简单,基本上就是看看哪一个节点离用户相对较近,这样作的问题是不少状况下用户仍是会远程接入,比较依赖节点自己的网络质量。但最大的问题是由于要覆盖广地域的各类用户,因此中心节点通常来讲都是采用的BGP资源,BGP资源的带宽成本是很是贵的,跟单线的边缘节点比是数量级上的差距。BGP资源可能要大几十,一两百块钱一兆,单线资源的话便宜的可能就几块钱一兆,这个差距是很是大的。

因此WE-CAN的思路是节点边缘化,首先咱们都是比较小型的节点,就像我刚刚说的,咱们的节点覆盖是很是全面的,好比在全国每个省份都有覆盖,海外咱们目前最重点的区域东南亚每个国家都有覆盖。要作到这一点,咱们每一个节点的规模是不大的,这样的好处是灵活易于调整,实际上节点的规模小不是坏事,实际上是好事。由于咱们内部有一个赛马机制,咱们对节点有一套运营机制,若是某个节点的网络质量很差,当咱们跟供应商沟通无效,查问题也查不出来,那咱们能够直接把它换掉。咱们会有一批储备的资源,实时观察,质量很差了就淘汰,质量好的就会提升优先级或者扩容。

而后在拥有大量的边缘节点以后,就能够作精细的调度优化,能够给用户分配更适合的节点,这样的话就可以作到真正的就近接入,提升Last-mile质量,下降上下行延迟。

最后正由于咱们经过WE-CAN大网组织起了各地的边缘节点,咱们才能够挑选成本最低的单线静态带宽资源,大大下降上下行带宽成本。

6.2 转发


图片

当流量经过接入节点进入WE-CAN网络以后,就来到了咱们的转发网络了。

转发网络是WE-CAN真正的核心。咱们的转发网络是由中转节点组成full-mesh网络,是一个软件定义的实时智能路由网络。咱们的中转节点会探测互相之间的网络质量,而后由控制节点经过数据平台收集到实时的探测网络质量,计算出各个节点之间的路由表,并把路由表下发到各个中转节点。最终由中转节点根据路由表对报文进行转发。

转发网络的原理、模型很是简单,各家的实现都大同小异。可是WE-CAN作了不少独到的优化,好比咱们在路由的时候计算的是Top K的最短路径,不仅是最佳路由。在转发节点会对这Top K的每一条路径实时维护一个动态的权重分值,也就是说报文在决定下一跳往哪走时不必定会去路由算法决定的最短的那条。彻底依赖最短路径的话问题是当网络有抖动的时候,路由切换传输恢复时间较长。正常状况下若是网络有抖动或者节点之间的网络有拥塞,这个拥塞状况会由节点之间的质量探测机制感知到,质量探测结果经过数据链路反馈到控制节点,控制节点更新完路由表下发到中转节点,才会把这个有问题的“前最短路径”切走。可是这个流程比较长,致使全部通过拥塞节点中转的路由都会出现抖动。

为了解决这种问题,咱们的边缘节点如今对路由表自己是有必定的调整能力的,它能够根据当前的网络反馈状况去对这个Top K路径去作动态调整。这种动态调整使得对于丢失的报文,在网络拥塞状况下,在重传的时候能够选一个不同的路径,也许是次优路径,但若是不作这种避免,那重传报文颇有可能仍是丢了。而且这些选择次优路径的决策又会动态影响接下来新的报文对路径的选择。

WE-CAN的转发网络另外一个投入较大、作了深度优化的地方是在多目的地的多播场景下,路由的时候会自动组成树状级联,对中转路径尽量复用。这在大频道或者直播的场景下有很好的应用,当频道比较大,用户分布比较广,接入服务器跨度大数量多的时候,上行的媒体流往外扩散的度会比较大。WE-CAN经过树状级联一是能够最大化路径复用以下降带宽成本,二是能够优化传输质量,下降每一个节点的流量扩散使得节点间能够有余地作冗余策略,固然最根本的一点是树状级联消除了上行节点的出度限制,使得超大频道成为可能。

另外,若是组成一个级联的转发树,那么越上游靠近树根的节点发生故障,影响越大。而WE-CAN的树状级联结构是各个中转节点自动生成的,对于任何一个节点的故障的规避和恢复是很是及时的。

7. 控制层

图片

讲了网络层,下面是控制层。控制层其实就是控制网络层工做的,在传统的CDN或者SDN里就是所谓的控制面,其余都是数据面。

控制层分为两部分,一个是路由,一个是调度。在我跟别人解释WE-CAN的时候经常把它比做一个数据的高速公路,上面有不少节点,路由作的事情是咱们组织一个高速公路,把流量从高速路网的任何一个节点快速地投递到任意另外的一个节点。这里所谓的节点是WE-CAN内部的节点。因此路由解决的是网内传输质量,提升网内传输的到达率,下降延迟。

调度系统的角度不一样,它解决的是上下行Last-mile的质量问题,类比高速公路路网,调度的任务是为你找到一个距离最近,可以最快上高速的入口或说高速公路收费站。由于Last-mile质量相对来讲是比较难解决的一个问题,咱们对Last-mile的控制力度和能够作的事情相对网内传输要少一些,因此调度质量也是咱们极为关注的一个方面。

7.1 调度


图片

WE-CAN的边缘节点调度技术我把它分为两大类,静态调度和动态调度,这个名字是我本身取的,不是标准术语,那么什么是动静态调度,什么是动态调度呢?它的区别就是静态调度是传统的查表调度,有一个静态的IP库,固然这个IP库是常常更新的,天天更新,但整体来讲仍是比较固定的。基本原理是经过查找这个静态IP库,对于每个调度请求,咱们能得到用户的相对准确的地理位置,并分配一个同ISP的状况下地理距离最近的一个节点。固然咱们并不老是单纯地作直线距离就近分配,在实际状况下,咱们会优先考虑用户的区域归属,尤为在一些省份的边界或者国家交界处。好比国内咱们但愿用户到同一个省份的节点去,不必定是最近。在海外不必定有这么细粒度但但愿用户起码能够去同国的节点,也不必定是最近的。但整体来讲所谓静态调度原理是经过查找静态的IP库,就近分配。

动态调度是跟静态调度相对的,它查找的是动态IP库。动态IP库的核心在于它不是预先生成好的,而是依托咱们的业务数据,对实时和历史数据进行分析和汇聚,来产生一个咱们认为对用户来讲最优的选择。

动态调度系统会根据用户历史数据,汇聚成各个维度的质量指标,好比说登陆的成功率,信令连通状况,音视频的卡顿率等等。同时WE-CAN也会针对每个客户端产生一个探测列表,客户端会主动地对这些接入节点作网络探测并上报。根据这些数据的汇聚结果,动态调度系统会产生出调度黑名单和白名单,黑名单就是根据数据分析发现某些客户端IP地址到某些机房质量持续很差,那就避免分配这些机房给这个客户端,即便它是距离最近的。白名单就是根据历史数据,尤为是探测数据判断客户端到某些节点质量很好,那WE-CAN就优先让这个用户去那些机房。

动态调度首先能够大大提升接入质量,最终提高端到端质量,另外有一个好处就是小运营商用户能够不用再固定去一批预留的BGP节点了。由于咱们的边缘节点都是单线静态带宽,因此须要在各地保留少许的BGP节点去覆盖小运营商用户,而在动态调度系统中,对于小运营商用户咱们会下发任务让他们去和附近的单线节点进行网络探测。由于小运营商通常来讲跟大运营商都有一些亲缘关系,若是好比探测结果代表某些用户连电信的服务器质量好,那调度的时候就会让这个用户分配到这个电信的节点去,这样不但能够提升小运营商用户的接入质量,也能够下降BGP带宽消耗。

由于经过数据实时计算产生的IP库我认为它是动态的,因此叫动态调度。这是调度的两个大的模块,调度系统的架构我会在后面再深刻讲。

7.2 路由


图片

调度是解决Last-mile接入的问题,路由就是解决网内传输的质量问题了,它体现的是控制层对于中转节点的控制。

首先中转节点负责探测节点间网络质量,并上报到数据平台。通过数据平台的缘由是一方面能够借助数据平台的计算汇聚能力来辅助路由表生成,另外这些路由原始数据存下来以后能够对它作各类展现和分析。

而后WE-CAN的路由计算是中心化的,也就是说路由表的计算彻底是由中心控制节点完成的。为何不能像好比说BGP协议同样去中心化地计算路由表呢?是由于在WE-CAN这个大型的传输网络里有一个很关键的核心问题就是流量的管控问题或者说是流量分配的问题。若是去中心化地计算路由表,网络是没有办法对全局的流量进行管控和分配的。

若是缺少全局流量管控,首先不少成本优化就没办法作,而且最严重的一个问题是在节点故障路由表切换的时候,尤为是一些流量比较高的重要中转节点网络出现抖动的时候,在从新计算路由表的时候网络天然要绕开这个中转节点,把它上面的现有流量切到别的节点上去。在这个状况下不少流量网网会跑去另外一个“次优节点”,若是网络缺少整体流量管控,这个次优节点很快就会被瞬时流量突增打爆,就会引起雪崩效应进而引发全网大规模故障。并且不仅是故障处理方面,在平常运行的状况下,咱们也但愿可以控制各个节点的流量在相对比较平稳,比较均匀的水平线上。

固然成本优化也是很重要的一个因素,不一样的中转节点的带宽成本是不同的,咱们但愿经过流量分配来避免流量尖峰,而且对不一样的业务场景和服务分级来使用不一样的节点带宽。

8. 传输层

图片

讲完了网络层和控制层,接下来是传输层。若是说网络层是WE-CAN架构最复杂、流程最长的一层,传输层就是WE-CAN协议、代码最复杂的一层。

传输层是基于网络层的路由和转发的能力,为了服务更复杂的应用场景,对网络层作了不少协议、传输场景上的适配。其中最主要的是咱们基于UDP协议自研了一套可靠传输协议,包括重传、排序等等。

相对于网络层原始UDP协议,传输层还有不少其余功能,好比说它对UDP MTU的限制进行了扩充,对大报文进行切片,对小报文聚合发送。对小报文聚合发送,一个是提升效率,下降报文overhead,另外一个方面是咱们在作FEC的时候但愿能把报文尽可能对齐,尽可能靠齐到接近MTU的大小,这样能够下降FEC冗余报文的开销。

另外传输层还负责流量控制、熔断限流等,传输层还有一个重要的做用就是要提供各类提供分级服务策略,提供各类冗余传输能力。传输层的协议是很是复杂的,它有各类力度的冗余传输和QoS的能力和策略。

8.1 协议


图片

这里大概示意一下传输层协议的各个字段,图上列举的是最主要的一些字段,咱们的传输层协议是一个很复杂的二进制协议,和互联网分层同样,WE-CAN传输层有一个传输层的报头,网络层有网络层的报头,网络层的报头相对比较简单,因此就没有展开讲。

传输层协议字段主要有三类,标识字段、寻址字段、策略字段。首先咱们每个报文会有一个惟一的标识,一方面是为了用来作问题调查,报文的链路跟踪。另外一方面标识字段自己有一些功能,好比序列号是用来作排序的,分段号是用来作切片的,其余好比作报文聚合的时候,还有聚合号等。

寻址严格意义上讲不是传输层的事情,主要是在网络层实现的。WE-CAN协议里传输层和网络层在寻址上面的区别是:网络层负责把报文从网络的一个节点传输到另一个节点,核心是路由。而传输层的寻址字段充当的功能有点像端口,到了目的地节点以后我用传输层所带的信息把报文分发给每一个实际的客户端或者说实际的服务器。由于WE-CAN的定位是一个通用的传输服务,它不仅是为云信RTC或者IM作传输。

策略字段相对最复杂,首先咱们的报文会有优先级,不一样的优先级会有不一样的FEC策略,不一样的重传策略,不一样的冗余策略,它是一个综合的字段,不少其余的策略都会参考优先级字段的赋值。另外每种其余策略都会有单独的开关,好比咱们会有多路冗余策略,典型场景是在重要会议的音频能够发两路,这两路咱们要保证它路径不重合,这些都是由传输层透给网络层来保证的。另外还有重传次数、重传等待时间等等。

以前提到过网络层和传输层对提升网内传输质量有不一样的作法,好比说网络层和传输层的重传是不一样的。对于网络层来讲,中转节点到中转节点之间它是有逐跳的重传的,而传输层有传输层的重传,也就是说WE-CAN的两个接入节点之间也有本身的ARQ。而后网络层会有逐跳的FEC,由于逐跳作FEC会比较灵活,比在两个接入节点之间作效率更高。

9. 应用层

图片

下面是讲应用层,应用层是对传输层的协议能力的一个封装,目前最主要的一个应用叫Message Bus。

9.1 Message Bus

图片

Message Bus是一个通用的消息服务,它是对传输层可靠传输协议的一个封装,在消息传输以外提供了一套Topic自动订阅、管理的机制。

Message Bus你能够认为它是一个全球部署的一个分布式的跨地域的消息队列系统,相似分布式的Kafka。因此除了传输以外,它还有状态管理的能力。另外Message Bus的消息投递支持广播的形式,也支持Round Robin的形式,由Message Bus负责轮询和连接状态管理。

Message Bus由WE-CAN核心网络来保证传输的可靠性,目前它最主要的业务场景之一就是承载了RTC服务端的信令。

图片

这个是Message Bus的架构图,画得很简单,由于Message Bus最主要的复杂度是在协议上面。

它的架构中最复杂的是上面这个Topic管理的模块,这是我以前提到的基建层里面的存储平台,是咱们全球分布式的一个缓存系统,会作跨大洲的状态同步和缓存,来保证Topic状态同步的一致性和及时性。

消息服务的传输保证跟媒体是不同的,首先消息须要保证有序到达,另外要保证必定程度上的可靠,在实在没法投递时也要能明确告知发送端投递失败。

9.2 HTTP Proxy


图片

在Message Bus之上咱们封装了另外一个服务叫HTTP Proxy。HTTP Proxy的用意是简单易用,对业务代码侵入性小,好比说REST API要加速,就能够直接上HTTP Proxy,开发工做量很是小。

图片

架构也比较简单,从客户端直接调用咱们这个Proxy Server,经过Message Bus,利用WE-CAN的传输能力,到目的地的Proxy Server,目的地的Proxy Server能够帮你去作HTTP调用,最后把结果经过Message Bus再回传过来,在调用发起方HTTP Proxy转换成HTTP Response。

时序图里,咱们有个比较特别的地方是在作HTTP代替的时候,要把目的地的URL放在请求里面,没有用标准HTTP代理的形式,由于HTTPS若是用标准协议代理的话,握手信息也须要来来回回传输,在跨大洲的状况下延迟会比较高。因此咱们用了这种形式,HTTPS的握手跟咱们的代理服务器去作,到了目的地代理服务器再去和实际的资源作握手,能够下降延迟。

9.3 统一调度


图片

另一个很是重要的应用层的系统叫统一调度,这个其实就是咱们整个调度系统的一个外在表现,是一个高度抽象的通用调度服务。为何要强调“高度抽象”、“通用”呢?是由于WE-CAN能支持不少的应用场景,有不少的下游的业务系统都在用WE-CAN,每个场景、每个应用都要用到咱们的调度服务。对于业务应用来讲,若是接了WE-CAN,那必然要给最终用户选择一个接入节点。

统一调度系统是与实际业务的调度逻辑解耦的,由于实际业务的调度中不必定只是要给用户找一个最好的节点去接入,每每各个业务有本身的附加要求和各类其余业务逻辑。WE-CAN的统一调度系统就提供了一种纯粹的,保证调度质量的服务,在此之上咱们经过管控平台提供了多个维度的定制能力,尽最大可能知足各个业务方的调度需求。实际上在实现中业务方会在统一调度系统之上再加一个业务调度系统,对WE-CAN调度结果再作一次封装,这样能够在咱们挑选出来的结果之上再去使用本身的业务逻辑和各类各样的限制。

统一调度系统在选择最优节点的同时会进行负载均衡,调度系统另外一个重要的概念是资源汇聚,在RTC中就是频道汇聚。好比在音视频通话中若是同一个房间里有一个江苏移动和一个浙江移动的用户,咱们可能就不但愿江苏人接到江苏移动机房去,浙江人接到浙江移动机房去,而是但愿他们汇聚到同一个机房。这样一来能够下降转发带宽成本,另外一方面落到最终端到端传输质量上每每是有提升的。

图片

统一调度的架构很是复杂,图上只是其中的一部分,它封装了WE-CAN的各类各样的能力。首先Message Bus会去帮它作各个节点的负载的收集,客户端会报它本身的负载,咱们叫它custom load,接入节点又会观察收集机器的一些资源使用状况,好比内存、CPU、网络等。这些信息会经过Message Bus发到统一调度系统的控制模块去。控制模块对外提供一个RESTful接口,它自己是一个信息收集汇总的模块,WE-CAN基建层的配置平台,IP库等信息都会汇总到控制模块去,对于每一次调度请求它都会去调用策略模块,由策略模块计算调度的结果。

动态调度系统是经过数据平台的数据经过汇聚、计算,最后把动态IP表更新到策略模块去。咱们会优先考虑使用动态IP表,而后用静态IP库作兜底,由于实际上不必定有这个用户的历史数据,因此不少状况下仍是要有传统的基于地理位置的就近接入来作兜底。

架构图里没画上去的一个重要模块是我以前提到过的资源汇聚系统。

在应用层还有许多其余的服务,好比说咱们有一个全球的时钟同步系统,它是基于WE-CAN的大量节点和中转传输的能力来搭建的,这个系统会保证全部的服务器之间的时钟是能以很是高的进度来达到一致,最终能够同步给客户端,以及一些其余的应用服务系统。

10. 业务层

10.1 RTC

图片

下面来讲一下咱们具体的业务应用,最主要的确定是RTC了,咱们云信的实时音视频服务。

对于RTC来讲,首先WE-CAN最大的好处是能够提升端到端的传输质量,由于用户就近接入了,而网内传输又相对可控。尤为是WE-CAN能够大大优化远距离特别是跨国通话质量,在云信的出海业务中,海外跨国通话或者海外回国等场景下,利用WE-CAN的传输服务就不须要再拉专线或者是用专门的代理加速来保证通话质量,WE-CAN能够保证从全球的任意一个地方到另外任一个地方的通讯质量。

另外RTC用 WE-CAN能够大幅下降节点带宽成本。从BGP机房或者三线机房替换为单线机房,带宽成本是数量级上的一个下降。

图片

这是简化的RTC接入WE-CAN的架构图,你们能够看到有两个不一样颜色的箭头表示,下面是媒体服务器之间直接互相级联,经过WebRTC各类协议直接进行通讯。而接入WE-CAN以后WE-CAN的接入节点跟媒体服务器之间是同机部署的,媒体流经过IPC进入接入节点,而后由WE-CAN负责投递到目的地接入节点去。

10.2 IM

图片

这是IM接入WE-CAN的架构,云信的IM有很长的历史了,而且市场对咱们的承认度很高,咱们的IM系统也很成熟,WE-CAN给IM的架构带来了很大的改变。

原来咱们跟大部分IM系统同样,是相对比较中心化的架构,由于IM有大量的状态须要存储。而有了WE-CAN以后咱们作了一个很重要的改造,就是长连接服务器前置部署。长连接服务器就是登陆服务器或者叫边缘服务器、接入服务器,客户端SDK是直接登录在这个服务器上的,消息最终是经过这个长连接服务器来推给客户端的。

WE-CAN首先能够改善IM上下行的接入质量,这是一个很明显的优点,还有一个重要的好处是广播消息的下推。也就是说咱们IM数据中心产生的消息再也不由数据中心的中心节点去广播或者说扩散给各个客户端了,咱们先扩散到相关的边缘服务器,边缘服务器再扩散到客户端,至关于自然有了一个两层的树状级联模式。这种模式有不少的优点,好比说咱们实际遇到过的一个场景,某个跨国的大频道,国内的消息要发给海外的用户的话,若是没有WE-CAN,首先确定是要走专线加速,专线加速自己就带宽有限并且很昂贵。并且若是消息有一万我的要接收,你就得重复跨国发一万份。如今有了WE-CAN以后,首先再也不须要专线了,WE-CAN会帮保证跨国传输质量,而后这个消息只用跨国发一份,利用WE-CAN发到海外接入节点再去作本地扩散。这对于下降中心机房的带宽压力和提高消息的水平扩展能力有本质的、巨大的改变。

为何说下降中心机房带宽压力可以提高的水平扩展能力的同时还可以下降成本?由于中心机房的成本通常比较高,好比它通常都是BGP节点,而海外的边缘节点的公网带宽成本是很低的。

10.3 直播点播


图片

下一个应用是直播点播,云信如今能够提供低延迟直播服务,这是一个如今比较火的能力。在一些对互动要求比较高的场景下,咱们会经过WE-CAN来代替传统的CDN作音视频的分发,这样最大的好处就是延迟低了,而且经过WE-CAN的各类节约成本的手段,咱们能够接近传统CDN的价格。

图上的全局智能融合调度不是WE-CAN的调度,它决定的是好比一个直播的房间是走WE-CAN仍是走传统CDN 或者是走哪一个CDN的选择。

10.4 数据上报


图片

还有一个应用是数据上报,你们每每会比较忽略数据上报质量,但数据上报实际上是走WE-CAN的一个很好的应用场景,尤为是当业务出海的时候。由于不管你的用户分布在哪,一些监控和打点数据,包括质量数据和事件上报的存储中心通常都会集中在一个地方,在跨国的状况下这些数据的上报成功率是没有办法保证的。而接了WE-CAN数据能够先报给分布在边缘接入节点上的数据收集服务,再由WE-CAN传给数据中心集群。这样一来能够显著提升数据上报成功率和及时性,二来咱们边缘节点自己在传输层作了报文的缓存,缓存时长能够由具体业务调整,这样在数据中心不可用,或者在维护的时候WE-CAN能够将数据缓存一段时间,等数据中心恢复服务的时候再经过流控慢慢发过去。

固然这里所说的数据不涉及到我的信息,单纯地只是一些质量数据,好比说丢包率、卡顿率和一些事件统计等。

目前主要的业务层的应用都讲完了,还有一些好比互动白板等没有在这里展开。

能够看到,这些架构图里都缺失了一个重要的东西——调度。实际上全部的应用都是要用到咱们的统一调度系统的,没画上去是由于篇幅有限,可是WE-CAN的全部接入节点的选择和调度都是由咱们的统一调度系统来完成的。

今天的演讲和分享就到这里,谢谢你们!